REPL Crash on Second Start

[hamzashahid-blit]

REPL Crash on Second Start

[hamzashahid-blit]

You mean AMD Ryzen CPU with builtin GPU?

Yes

I'm using CEPL on nVidia GPUs on several computers and it works fine.

Oh.

I suspect that the issue has more to do with the OS and the versions of the packages it has installed (X11 and such).

Ah, yes, that makes more sense.

Anyway, I wish you success with setting it up, so you can use CEPL.

Thank you. When I will start working on the OpenGL project again, I will be sure to use it (if it works) :)

[metayan]

Which OS and Lisp implementation are you using?

I just tested with SLIME/SBCL on macOS and here it works fine.
Replaced your line 6 with (load (compile-file "examples/game-of-life.lisp")).
Also, note that I have all the CEPL systems cloned in quicklisp/local-projects/.

The Lisp can be restarted with ,rest in the REPL – both in SLIME and SLY.

[hamzashahid-blit]

Oh I forgot to mention that, I am using Linux, and SBCL here is the details:

$ uname -a:
Linux Sabas-Zbook15 5.13.19_1 #1 SMP Sat Sep 18 18:18:26 UTC 2021 x86_64 GNU/Linux
$ sbcl --version
SBCL 2.1.9

I didn't know about the ,rest feature, that helps me alot. The replacement of line 6 doesn't make a difference on my machine. That was just a formal replacement for running C-c C-k on the buffer in Emacs. I also didn't know about the cloning on quicklisp.

Thanks for the reply.

[hamzashahid-blit]

Just making it clear that it still doesn't work as expected. :)

[metayan]

Thanks for clarifying that it's still not working. I wasn't sure. :)

1. It's still not completely clear to me what the actual issue is. What do you mean with "the REPL averses"?

2. Do you have something in ~/.swank.lisp or ~/.slynk.lisp?

3. I'm mostly using SLIME, so it might help if you can use that while trying to fix this.

Note:
It might be easier to help with the issue if you supply "Steps to reproduce" that you actually use.

The replacement of line 6 doesn't make a difference on my machine. That was just a formal replacement for running C-c C-k on the buffer in Emacs.

Everything makes a difference. We're dealing with computers here. ;)
Plus, line 6 could not possibly work.

CEPL is relying on quite many things in the system to work.
It's brilliant, and very much worth the effort to get it running well, but it might need some special attention.
I'm using it on both Linux and macOS, and it's much easier to get running on Linux, so I'm pretty sure we can get it running on your system as well. 🚀

[hamzashahid-blit]

Thanks for replying.

1. (a) The actual issue is elaborated on the Let me explain section but here goes:
   I create a project, it works as expected. I open up the project again the next day after a restart of everything. On running (cepl:repl) a window appears which is not responding. I don't have any control of the REPL anymore, meaning when I type anything into the repl, it just gives me a REPL is busy message. The only option is to run xkill and terminate the application.

2. (b) "the REPL averses" means that I loose all control of the REPL and have to terminate it.

3. I don't have a ~/swank.lisp nor a ~/slynk.lisp. I do have a ~/.sbclrc though: http://ix.io/3Cpw

4. Okay, I will use Slime from now on but I have tried it on SLIME too and it has the exact same results.

In your Note:

It might be easier to help with the issue if you supply "Steps to reproduce" that you actually use.

I actually used those steps. I copied from the REPL and double checked it by restarting and typing in those same steps. I tried both, C-c C-k AND Step 6 (Note the new one typed below). It doesn't make a difference. I am having the same problem.

Plus, line 6 could not possibly work.

Yes here is the new Step 6:
6. (load (compile-file "examples/game-of-life.lisp"))
I updated my original comment to the correct step 6.

I totally agree with the last paragraph and most of my projects depend severely on CEPL. I love it too much.

Thanks for cooperating. :)

[hamzashahid-blit]

Just another reminder that my problem isn't fixed. Am I not giving some information, please say so, I am sorry if that is the case. If my problem is fixed I will definitely state it. Thanks for your cooperation and I hope I am not a trouble.

[metayan]

No trouble. Pardon the delay. I'm still using macOS mainly, so couldn't test on Linux yet.

Do you have the CEPL repositories cloned locally, or are you using the ones that Quicklisp downloads automagically?
Asking because of the NOTE at the bottom of https://github.com/cbaggers/cepl.examples . Not sure how relevant it is anymore, but it could influence something.

Anyway, I would first test the system this way to make sure it works without SLIME:

cd ~/quicklisp/local-projects/
git clone https://github.com/cbaggers/cepl.examples
sbcl --eval '(ql:register-local-projects)' --quit

While in ~/quicklisp/local-projects/ , it might be good to

grep cepl.examples system-index.txt

and check that cepl.examples only appears once. (I've seen repositories that contain duplicate systems in subdirectories, and that can cause very strange errors.)

Now

cd ~/quicklisp/local-projects/cepl.examples/
sbcl --no-sysinit --no-userinit \
  --load ~/quicklisp/setup.lisp \
  --eval '(ql:quickload :cepl.examples)' \
  --load examples/game-of-life.lisp \
  --eval '(cepl:repl)' \
  --eval '(cepl.examples::run-loop)' \
  --quit

should run the example fine. Twice. ;)
(Starting SBCL this way to make sure that no init files introduce unexpected behavior.)

This is also a useful test:

sbcl --no-sysinit --no-userinit \
  --load ~/quicklisp/setup.lisp \
  --eval '(ql:quickload :cepl.examples)' \
  --load pre-release-run.lisp \
  --eval '(cepl:repl 800 600)' \
  --eval '(cepl.examples::run-em-all)'

To try to expose your issue, I would run this twice.

If that works – and can be run twice without problems – the next step would be to try with init-files:

sbcl \
  --eval '(ql:quickload :cepl.examples)' \
  --load examples/game-of-life.lisp \
  --eval '(cepl:repl)' \
  --eval '(cepl.examples::run-loop)'

and

sbcl \
  --eval '(ql:quickload :cepl.examples)' \
  --load pre-release-run.lisp \
  --eval '(cepl:repl 800 600)' \
  --eval '(cepl.examples::run-em-all)'

If all this works, then I'd start SLIME and hopefully it will work the same. Also twice.

[hamzashahid-blit]

Do you have the CEPL repositories cloned locally, or are you using the ones that Quicklisp downloads automagically?
Asking because of the NOTE at the bottom of https://github.com/cbaggers/cepl.examples . Not sure how relevant it is anymore, but it could influence something.

I used quicklisp and didn't clone it locally.

cd ~/quicklisp/local-projects/
git clone https://github.com/cbaggers/cepl.examples
sbcl --eval '(ql:register-local-projects)' --quit

This ran successfully.

Here is the grep output:

$ pwd
/home/saba/quicklisp/local-projects
$ grep cepl.examples system-index.txt
cepl.examples/cepl.examples.asd

Runnning:

cd ~/quicklisp/local-projects/cepl.examples/
sbcl --no-sysinit --no-userinit \
  --load ~/quicklisp/setup.lisp \
  --eval '(ql:quickload :cepl.examples)' \
  --load examples/game-of-life.lisp \
  --eval '(cepl:repl)' \
  --eval '(cepl.examples::run-loop)' \
  --quit

Gave me a CEPL:REPL window that showed up again not drawing anything and having the same symptoms as before. Although we have new information in the terminal, this shows up:

Running it a second time, yielded successfull results. A window running the game-of-life example as it should! This was the last time I saw anything properly rendered onto the CEPL:REPL screen. I ran all of the examples after that atleast 3-4 times. All of them produced the same output and the same window as shown in the picture above (They didn't work).

Atleast we now (hopefully) know a bit more about the issue.

Thanks.

Regards,
Hamza Shahid

[metayan]

(When there's text output, it's nice to paste only the text, because then one can copy from it.)

Looks like it's neither CEPL nor SBCL causing the problem.
Searching for xcb_xlib_threads_sequence_lost found these:
https://github.com/avafinger/libx11_1.6.4/blob/6f5c84b2cf20aa5a43d7c26078d8e6f7693f7af1/README.md
linuxmint/muffin#583
https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/1808710
https://gitlab.freedesktop.org/xorg/lib/libx11/-/merge_requests/34

Apparently the problem appears quite randomly for others as well.

Seems to be time for a system upgrade. ;)
It might be useful to post the current contents of your /etc/os-release and the current version of libx11 here as well for future reference.

When running in SLIME, the error is probably also shown in the *inferior-lisp* buffer. Just mentioning it as another place to look for clues.

Time to enjoy some CEPL!

[hamzashahid-blit]

(When there's text output, it's nice to paste only the text, because then one can copy from it.)

Sorry, will keep that in mind for next time.

$ cat /etc/os-release 
NAME="void"
ID="void"
DISTRIB_ID="void"
PRETTY_NAME="void"

Here is my version of libX11 and it's deps (dependencies):

$ xbps-query libX11
architecture: x86_64
automatic-install: yes
filename-sha256: 817a48f06f4b524a808a0ed905d72d634e3a0f026815287abf34f646bf89b9d3
filename-size: 1318KB
homepage: http://xorg.freedesktop.org/
install-date: 2021-07-31 14:50 PKT
installed_size: 6909KB
license: MIT
maintainer: Leah Neukirchen <[email protected]>
metafile-sha256: d51441be21283779e09302200b568f1166b3fb8501b2c8544c386b9a56e8f06f
pkgname: libX11
pkgver: libX11-1.7.2_3
repository: https://alpha.de.repo.voidlinux.org/current
run_depends:
        libxcb>=1.2_1
        glibc>=2.32_1
shlib-provides:
        libX11.so.6
        libX11-xcb.so.1
shlib-requires:
        libxcb.so.1
        libdl.so.2
        libc.so.6
short_desc: Base X libraries from Xorg
source-revisions: libX11:6acfca310e
state: installed

I updated my system, restarted it and it still produces the same result. libX11 and deps are the same version meaning they aren't updated. Maybe I have to wait for it to be the latest version on Void Linux or I could build from source?

So still no time to enjoy CEPL... :(

[hamzashahid-blit]

Hello, Hope you are well,
I see that the version of libX11 I have is the latest version. Arch Linux, Void Linux, GitHub, all have libX11 version 1.7.2_3. I have searched more for this problem without any fix. Although, I went into the LDB Debugger and typed in backtrace which produces this output:

ldb> backtrace
Backtrace:
   0: fp=0x7fb0a388eea8 pc=0x7fb0a373cf81 Foreign function gsignal
ldb> 

Maybe this is of help to you?

Thanks for the help and I hope we could solve this together,as if we don't, I will have to use cl-opengl and create my projects from scratch with that, which is quite a bigger pain since I know that CEPL exists.

Regards,
Hamza Shahid :)

[metayan]

I have a suspicion that cl-opengl might behave the same way if libX11 is the culprit.
If the latest libX11 still has problems, I would downgrade it to the one that worked.
Or maybe it's mesa that is the problem and a fix seems to be on its way:
https://gitlab.freedesktop.org/mesa/mesa/-/issues/4763
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/12006

Might be an idea to run the SDL2 tests from https://github.com/libsdl-org/SDL .

mkdir build; cd build; cmake .. -DSDL_TEST=1; make

to build the tests. On my system I had to add

C_INCLUDES = -I../include

in build/CMakeFiles/SDL2_test.dir/flags.make to get rid of

src/test/SDL_test_assert.c:28:10: fatal error: 'SDL_config.h' file not found

Most likely we can rule out both CEPL and SBCL as the cause.

[hamzashahid-blit]

Wow, all of the SDL Examples/tests work perfectly fine!

I tried the CEPL examples again and they produced the exact same results as before. Which means, the problem is in CEPL... Ooor cl-opengl?

To test cl-opengl, I first git cloned https://github.com/3b/cl-opengl, then went to the examples directory. After I ran

(ql:quickload :cl-opengl)
(ql:quickload :cl-glut)
(ql:quickload :cl-glu)

I did a C-c C-k on the examples/redbook/movelight.lisp file. On running the command (rb-movelight), this showed up:

Yay! It worked! I tried this on almost all examples, all of the ones I tried, worked flawlessly. What can we rule down?

1. cl-opengl
2. an OpenGL issue
3. my Hardware
4. my OS/Software
5. libX11 (atleast for the above examples we can rule this out)
6. SBCL
7. SLY
8. SLIME (I tested it on SLIME too, aside from a small package issue it worked the same as SLY)

Would you look at that, we narrowed CEPL down as the verdict (atleast as far as I can think).

This session boosted my motivation a little further as atleast I could see a window popup. Now the question would be where CEPL is going wrong.

Thanks for your cooperation.
Regards,
Hamza Shahid

[metayan]

I can try with a Funtoo Linux system later. I'm planning to switch to it from macOS at some point, so have to make sure that the graphics things – especially CEPL – work well. It has worked flawlessly on that system in the past.

It's good if you take note of any error messages that appear.

[metayan]

All the CEPL examples run fine on Funtoo Linux here.
cepl.examples in local-projects, dependencies directly from quicklisp.
libX11 1.6.9 - libX11.so.6.3.0 installed 2021-08-17
mesa 20.2.4

[hamzashahid-blit]

Maybe you could try Void Linux at some point?
I have used Gentoo in the past but not Funtoo. Things run pretty well on that distro, except when you forget to maintain it (Gentoo).

[hamzashahid-blit]

Also, that version of libX11 is really old. Maybe try it with a newer version? Even on Funtoo.

[hamzashahid-blit]

Hello. Any update trying it on Void Linux? It certainly works with other distros.

[hamzashahid-blit]

Tried on Artix Linux. Same results.

[metayan]

I have also encountered the problem when using Funtoo, and have a solution in sight.

[hamzashahid-blit]

Yayyyyy, hope to hear from you soon! I hope I can reward everyone's effort with my application!

Thanks, for cooperation.

Regards.

[hamzashahid-blit]

Any update? My project is still held up. Thanks for your effort.

[baggers-br]

@metayan thanks so much for looking into this in my absence. Feel free to braindump your findings on me and I'll try to continue your excellent work
@hamzashahid-blit Hi! thanks for reporting this. I only have an ubuntu laptop with me on my Christmas vacation, so I'm not in a great place to be swapping out distros. However I'll try replicate this issue when I'm back in Norway after the 28th.
Unfortunately the issue does not occur for me on Ubuntu 20.04.1 LTS with SBCL 2.0.4 (Yeah, I'm rather out of date right now)

[hamzashahid-blit]

Hello, @baggers-br,
Thank you for looking into my issue! I will try my hardest to find anything I can! For now though, I am trying to work with cl-opengl. When the problem is fixed, I will try to port my code to CEPL. Thanks again :D

Regards,
Hamza Shahid

[metayan]

My investigations led me to the value of :everything in
https://github.com/lispgames/cl-sdl2/blob/master/src/sdl2.lisp#L31
which might be causing trouble under certain conditions in
https://github.com/cbaggers/cepl.sdl2/blob/master/cepl.sdl2.lisp#L10
as well as with the cl-sdl2 examples.

When the issue appeared on my Linux system, I tried to only set a few of the bits in :everything, and got both CEPL and the cl-sdl2 examples to start and run fine. I was trying different combinations of the flags to find the real culprit, but had to interrupt the search before reaching a clear solution.

At the moment I can't reproduce the issue on my Linux system - both CEPL and the cl-sdl2 examples run fine here.

It's still a mystery to me what underlying circumstances cause the issue to appear. An idea is the version of the installed SDL2. I have tried both 2.0.10 and 2.0.18.1 (fresh build) now, but I'm somewhat sure that both were causing trouble before, but not 100% certain.

@hamzashahid-blit : If you still have the issue with your system, I suggest trying to tweak the definition of :everything.
Maybe replacing :everything with something(!) like

(logior sdl2-ffi:+sdl-init-events+
        sdl2-ffi:+sdl-init-timer+
        sdl2-ffi:+sdl-init-audio+
        sdl2-ffi:+sdl-init-video+
        ;; sdl2-ffi:+sdl-init-gamecontroller+
        ;; sdl2-ffi:+sdl-init-joystick+
        ;; sdl2-ffi:+sdl-init-haptic+
        ;; sdl2-ffi:+sdl-init-sensor+
        )

and playing around with different combinations.

[hamzashahid-blit]

Hello!
@metayan Thanks for your reply. I tried cloning sdl-2 to my local-projects and the cl-sdl-2 examples worked perfectly fine. The CEPL ones didn't budge. Since I am not too proficient with lisp, I don't understand how to change or tweak the definition of :everything. I tried replacing the occurance of :everything in https://github.com/lispgames/cl-sdl2/blob/master/src/sdl2.lisp#L31 from:

(autowrap:define-bitmask-from-constants (sdl-init-flags)
  sdl2-ffi:+sdl-init-timer+
  sdl2-ffi:+sdl-init-audio+
  sdl2-ffi:+sdl-init-video+
  sdl2-ffi:+sdl-init-joystick+
  sdl2-ffi:+sdl-init-haptic+
  sdl2-ffi:+sdl-init-gamecontroller+
  sdl2-ffi:+sdl-init-noparachute+
  '(:everything . #x0000FFFF))

To:

(autowrap:define-bitmask-from-constants (sdl-init-flags)
  sdl2-ffi:+sdl-init-timer+
  sdl2-ffi:+sdl-init-audio+
  sdl2-ffi:+sdl-init-video+
  ;; sdl2-ffi:+sdl-init-joystick+
  ;; sdl2-ffi:+sdl-init-haptic+
  ;; sdl2-ffi:+sdl-init-gamecontroller+
  sdl2-ffi:+sdl-init-noparachute+
  '((logior sdl2-ffi:+sdl-init-events+
        sdl2-ffi:+sdl-init-timer+
        sdl2-ffi:+sdl-init-audio+
        sdl2-ffi:+sdl-init-video+
        ;; sdl2-ffi:+sdl-init-gamecontroller+
        ;; sdl2-ffi:+sdl-init-joystick+
        ;; sdl2-ffi:+sdl-init-haptic+
        ;; sdl2-ffi:+sdl-init-sensor+
        ) . #x0000FFFF))

I ripgrepped for :everything and couldn't find the definition. I had some errors after that. Could you please tell me a little more specifically what to change? (steps would be highly appreciated).

Thanks a lot!

Regards,
Hamza Shahid

[metayan]

Oh, I wrote it a bit cryptically I see now.
You almost got it, just the other way round. ;)
No worries.
As it is now, :everything is set to #x0000FFFF ,but all those #xFFFF bits are not really used by the underlying SDL.

You can first try

(autowrap:define-bitmask-from-constants (sdl-init-flags)
  sdl2-ffi:+sdl-init-timer+
  sdl2-ffi:+sdl-init-audio+
  sdl2-ffi:+sdl-init-video+
  sdl2-ffi:+sdl-init-joystick+
  sdl2-ffi:+sdl-init-haptic+
  sdl2-ffi:+sdl-init-gamecontroller+
  sdl2-ffi:+sdl-init-noparachute+
  '(:everything . #.sdl2-ffi:+sdl-init-everything+))

This sets :everything to the actual used bits. I haven't analysed how libSDL2 reacts to superfluous bits, so that might not be the cause of the issue.

Which brings us to what I had to do to make it work when I had the issue:

(autowrap:define-bitmask-from-constants (sdl-init-flags)
  sdl2-ffi:+sdl-init-timer+
  sdl2-ffi:+sdl-init-audio+
  sdl2-ffi:+sdl-init-video+
  sdl2-ffi:+sdl-init-joystick+
  sdl2-ffi:+sdl-init-haptic+
  sdl2-ffi:+sdl-init-gamecontroller+
  sdl2-ffi:+sdl-init-noparachute+
  '(:everything .
    #.(logior
       sdl2-ffi:+sdl-init-events+
       sdl2-ffi:+sdl-init-timer+
       sdl2-ffi:+sdl-init-audio+
       sdl2-ffi:+sdl-init-video+
       ;; sdl2-ffi:+sdl-init-gamecontroller+
       ;; sdl2-ffi:+sdl-init-joystick+
       ;; sdl2-ffi:+sdl-init-haptic+
       ;; sdl2-ffi:+sdl-init-sensor+
       ))) ; these hanging parens are considered bad style. Just sayin'.

Since I cannot reproduce the issue anymore, it's up to you to try different combinations by commenting out and adding flags inside the logior form until you find a working combination. The one I posted here is what worked for me, but I didn't test it extensively.

Can you, by the way, post the error message that you get as text here? Before you make any changes.

Wishing you success and great enjoyment with CEPL. It's truly awesome.

EDIT: I strongly suggest to restart SBCL before each try.

[hamzashahid-blit]

Hey!
I did a LOT of tests, with different tweaks and changes. I ran different configurations and SBCL Flags. Here are my Results:

(autowrap:define-bitmask-from-constants (sdl-init-flags)
  sdl2-ffi:+sdl-init-timer+
  sdl2-ffi:+sdl-init-audio+
  sdl2-ffi:+sdl-init-video+
  sdl2-ffi:+sdl-init-joystick+
  sdl2-ffi:+sdl-init-haptic+
  sdl2-ffi:+sdl-init-gamecontroller+
  sdl2-ffi:+sdl-init-noparachute+
  '(:everything .
    #.(logior
       sdl2-ffi:+sdl-init-events+
       sdl2-ffi:+sdl-init-timer+
       sdl2-ffi:+sdl-init-audio+
       sdl2-ffi:+sdl-init-video+
       ;; sdl2-ffi:+sdl-init-gamecontroller+
       ;; sdl2-ffi:+sdl-init-joystick+
       ;; sdl2-ffi:+sdl-init-haptic+
       ;; sdl2-ffi:+sdl-init-sensor+
       ))) ; these hanging parens are considered bad style. Just sayin'.

The above code worked flawlessly when ran like this in the terminal:

sbcl --no-userinit
--load ~/quicklisp/setup.lisp
--eval '(ql:quickload :cepl.examples)'
--load examples/game-of-life.lisp
--eval '(cepl:repl)'
--eval '(cepl.examples::run-loop)'
--quit

That is, it worked consistently with the "game-of-life.lisp" example. With other flags:

W/O "--no-userinit" (any other flags like "--no-sysinit" make no difference) "game-of-life.lisp":
Works 1 Every 5 Times Or 20%

With other Examples:

ANY FLAGS W/ "compute.lisp":
Works 1 Every 5 Times Or 20%

ANY FLAGS W/ "triangle.lisp":
Works 1 Every 5 Times Or 20%

Another interesting fact is that the percentage working with the "compute.lisp" example drops signifacantly when commenting out the "no-parachute" line. I tried this with the "game-of-life.lisp" and that flag with many others made no difference. Whereas I did not try with other examples.

Yes, It's that random. The above "Works 20% of the time" was with changing out flags in the "logior" thing and with different sbcl flags. I roughly linked this with the fact that the error contains something about threads, which could be unorthodox. Although the consistency with the GOL example is really interesting. I don't understand which part of the code could trigger this randomness and why the flags given to SBCL would matter in the context of randomness.

I hope this was atleast of some help for your debugging. If there is anyway I could give access to my system in a way where you could debug this problem (Maybe something involving Virtual Machines?), I would love to cooperate. I thank you sincerely.

Regards,
Hamza Shahid

[metayan]

I might have not been clear enough in my explanation.
Did you replace the form at
https://github.com/lispgames/cl-sdl2/blob/master/src/sdl2.lisp#L23-L31
with the one from my previous message?

A way to make sure that the change is made to the correct file is to:
start SLIME and load sdl2 with
(ql:quickload :sdl2)
enter
sdl2::sdl-true-p
in the REPL - without pressing Enter - and pressing M-. or Esc-. to jump to the definition.

The form under that is to be replaced.
(Maybe that is what you have done - just making sure.)

Also, only the lines after the logior are to be commented out or included for this test.

Can you also copy the error messages that you get and paste them in a code block (inside three backquotes) here?

[hamzashahid-blit]

Hello,
I have done everything correctly as you have mentioned. I have checked with your method, and it is the correct file. I further confirmed this by checking the output of:

(ql:where-is-system :sdl2)

Can you also copy the error messages that you get and paste them in a code block (inside three backquotes) here?

The errors were only of invalid syntax. Not of any real problems, the invalid syntax was of trying to tweak the definition of :everything. That problem is fixed since you explained what you meant with that message.

Basically: I have done everything correctly and there are no errors you need to worry about except for the main problem at hand; The XInitThreads one which opened this issue in the first place.

Regards,
Hamza Shahid

[metayan]

Alright. Just making sure we're playing the same game. ;)

By the way, found
https://bugzilla.mozilla.org/show_bug.cgi?id=1743551
https://bugzilla.mozilla.org/show_bug.cgi?id=1743142

Could be useful to try on an X11 system:
https://tronche.com/gui/x/xlib/event-handling/protocol-errors/synchronization.html
https://github.com/smcv/workaround-shadow-tactics

Putting them here, so I find them later, when running Linux again.

Also the original error message:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
sbcl: xcb_io.c:269: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

[hamzashahid-blit]

Alright, just so you know, according to X Synchronization Docs, If _Xdebug is set to a non zero value, it forces synchronous behaviour. If I set this value to 1, the GOL (Game Of Life) example doesn't work. If set to 0 the GOL example works as before.

[hamzashahid-blit]

Hello @baggers-br!
I hope you had an amazing holiday. I couldn't find anymore insight on the issue till date. If you have any solutions in sight, or any logs you want to have, please be sure ask me, and I will try my best to provide. Thanks.

Regards,
Hamza Shahid

[hamzashahid-blit]

Okay I now own a new PC. Maybe the issue is resolved here?
I will post all the specs and everything when I get around to testing if CEPL actually works. Just for a small note: This computer has an AMD Ryzen APU. The other one had a NVIDIA, so maybe thats the issue? We will see.

[metayan]

You mean AMD Ryzen CPU with builtin GPU?
For your information, I'm using CEPL on nVidia GPUs on several computers and it works fine.
I suspect that the issue has more to do with the OS and the versions of the packages it has installed (X11 and such).
Anyway, I wish you success with setting it up, so you can use CEPL.