[slime-devel] mp::startup-idle-and-top-level-loops blocks SLIME REPL
I use CMUCL 18e with GNU Emacs 20.7.2 and the latest SLIME CVS sources under Debian Woody. If I evaluate this form in *slime-repl*: (mp::startup-idle-and-top-level-loops) the cursor advances to []: CL-USER> (mp::startup-idle-and-top-level-loops) [] and *slime-repl* blocks, i.e it no longer accepts input. If I press ENTER in *slime-repl*, I get this message in the minibuffer: Lisp is not ready for requests from REPL Only *inferior-lisp* remains active. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso writes:
I use CMUCL 18e with GNU Emacs 20.7.2 and the latest SLIME CVS sources under Debian Woody. If I evaluate this form in *slime-repl*:
(mp::startup-idle-and-top-level-loops) [...] and *slime-repl* blocks, i.e it no longer accepts input. If I press
A workaround is to evaluate the form from *inferior-lisp*. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Paolo Amoroso <amoroso@mclink.it> writes:
Paolo Amoroso writes:
I use CMUCL 18e with GNU Emacs 20.7.2 and the latest SLIME CVS sources under Debian Woody. If I evaluate this form in *slime-repl*:
(mp::startup-idle-and-top-level-loops) [...] and *slime-repl* blocks, i.e it no longer accepts input. If I press
A workaround is to evaluate the form from *inferior-lisp*.
This is a bit difficult. mp::startup-idle-and-top-level-loops starts a new thread and then enters an infinite loop. The main thread becomes the "idle" thread that does the actual scheduling, but blocks the communication with Slime. Slime is currently not prepared for multithreaded operation and asynchronous "stuff", like multithreading or fd-handlers, may cause unexpected behavior. Suggestions to improve the situation are most welcome. Helmut.
participants (2)
-
Helmut Eller -
Paolo Amoroso