Windows: can't start from SLIME REPL

[mobius-eng]

I've encountered a mysterious issue. On Windows, qt-libs, qtools and everything installs fine. Furthermore, I can run everything from command line. But I cannot start Qt app from SLIME. There is no error. Just nothing happens. SLIME REPL becomes unresponsive. But I still can input expressions into inferior-lisp buffer and see its responses. In REPL buffer, however can't interrupt with C-c C-c. The only way to get out of this is to kill inferior-lisp buffer (it hangs on (QUIT)).

Just to be safe, I've tried it with hellowolrd example from qtools/examples.

System: Windows 10 (64 bit), SBCL 1.3.9 64-bit.

PS. I do have Qt installed via MSYS2/MINGW64 in their directory, which is a part of PATH. But PATH is the same in Emacs as in cmd.

[Shinmera]

I can't confirm this. When running (qtools-helloworld:main) a new window pops up (although in the back). Closing it returns to the REPL as usual.

This was tested on Win10 64x SBCL 1.3.5 64x.

[mobius-eng]

I've tried it with SBCL 1.3.6 and had the same issue. Wanted to try with 1.3.5 - but my internet was so slow, qt-libs archive wouldn't download.

Had to focus on my work, so re-booted into Ubuntu for now. Will try again later.

In meantime, maybe something is wrong with the way my SLIME is set up? For one, I have SLIME from MELPA, but Quicklisp in QUICKLISP-SLIME-HELPER has its own SLIME (of different version), have no idea which one is actually loaded.

It's a bit outdated, but here is my SLIME setup

[Shinmera]

The way I tested was using Portacle and cloning qt-libs and qtools to its projects folder.

[Shinmera]

Is this still an issue?

[mobius-eng]

Well, it is in my setup... but it needs to be tested with a clean system installation, as it might be something peculiar for my system or my Emacs setup.

[Shinmera]

Closing for now due to lack of reproducibility and feedback. Reopen if the issue persists.

[robotjunkyard]

I don't know if I should post in this issue or open in a new one since I'm in Linux and not Windows, but this is the same problem as the OP's anyway, when trying to run qtools-helloworld:main in Linux x64 via sbcl 1.3.10. It just hangs there; no Qt window, no new REPL line; if I try to ALT-. over 'qtools-helloworld:main' symbol in the buffer, then SLIME (or SBCL) completely freezes; sometimes, it also freezes emacs (or it does until I 'killall -9 sbcl), or emacs will respond to keypresses but attempting to re-start SLIME from emacs via slime-restart-inferior-lisp results in SBCL dropping to the debugger.

[phoe]

@robotjunkyard does the issue persist on a newer SBCL?

[robotjunkyard]

Yes, it does. Just now plopped SBCL 1.3.20 into my environment and switched to that, and it still reproduces.

Maybe this anecdote might (hopefully) be helpful in some way: I also just remembered a similar event I ran into in the past. Even though it wasn't with QTools (it was the SDL2 package), it was the same issue in which, when running via an emacs+SLIME environment, Lisp would freeze when attempting to open a window. I think SWANK was the specific culprit, if my memory serves.

But anyway, in that, I had to use something sdl2 provided called sdl2:make-this-thread-main, and a macro using it looked like:

(defmacro with-main (&body body)
  `(sdl2:make-this-thread-main
    (lambda ()
      ,@body)))

(and that docstring doesn't correspond to what that macro actually does, I think I originally pasted something over from somewhere else and forgot to remove that. Editing that out now :))

And then, in the body of main, it wrapped everything within that macro. Perhaps whatever thread-manipulating-magic sdl2 does might also be able to be implemented here, if there isn't already something like that.

[Shinmera]

There is stuff to run things in the main thread to accommodate OS X, but that shouldn't be necessary on Linux. At least it never has been on any of the systems and configurations I've tested on. Anyway, to eliminate Slime as a problem vector, can you try launching things from a terminal instead?