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
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
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.
-
Helmut Eller -
Paolo Amoroso