Greetings all,
I'm giving SLIME a spin, and I fetched a FAIRLY-STABLE version from CVS yesterday. M-x slime worked fine, and I had a REPL buffer. Unfortunately, whenever I drop into the OpenMCL debugger and choose a restart (like ABORT or ABORT-BREAK), all further attempts to interact with the REPL result in a "Lisp is not ready for requests from the REPL" message, and I have to restart SLIME. ABORT-BREAK actually gave me a CL-USER prompt, but with the same error message.
Do I simply misunderstand what's going on? Is this an OpenMCL issue? Some kind of threading issue? I tried searching on gmane for this error, but it looks like people generally run into it when trying to do several things at once. I just evaluated (error "test error") on the Lisp prompt; I expect to just enter the debugger and choose a restart.
Many thanks, CV
Constantine Vetoshev gepardcv@yahoo.com writes:
Greetings all,
I'm giving SLIME a spin, and I fetched a FAIRLY-STABLE version from CVS yesterday. M-x slime worked fine, and I had a REPL buffer. Unfortunately, whenever I drop into the OpenMCL debugger and choose a restart (like ABORT or ABORT-BREAK), all further attempts to interact with the REPL result in a "Lisp is not ready for requests from the REPL" message, and I have to restart SLIME. ABORT-BREAK actually gave me a CL-USER prompt, but with the same error message.
Do I simply misunderstand what's going on?
The intended behavior is that errors pop up a debugger buffer (the sldb buffer) and you should then be able to select a restart in that buffer with the keys 0-9 or by hitting Return on the restart[*].
In FAIRLY-STABLE and older versions it is/was not possible to enter input requests in the REPL when SLIME was in the "debugging state". The current state should be indicated in the modeline. However, C-c C-: and most other commands can also be used in the debugging state. And of course, the REPL is supposed to work again if you return from the debugger.
This restriction has been removed in newer versions and it is now possible to send requests from the REPL even if the debugger is active.
Is this an OpenMCL issue? Some kind of threading issue?
I'm not sure. I only have access to OpenMCL-0.12 on a very oldish Linux and don't see the problems you describe. We didn't do much with threads in FAIRLY-STABLE, so unless you use threads in your code it is probably not a threading issue.
If you don't get the sldb buffer, it is probably some bug in SLIME's OpenMCL backend. Marco or Alan know probably more about OpenMCL issues.
Some people reported output buffering problems with SLIME/OpenMCL and perhaps you see something similar. I think this is fixed in the newest SLIME (but it could be done more elegantly with OpenMCL's autoflush feature as Gary Byers suggested).
It would be nice if you could try the latest CVS version.
Helmut.
[*] A few bits of documentation are here: http://www.cliki.net/SLIME%20Features
Helmut Eller <e9626484 <at> stud3.tuwien.ac.at> writes:
In FAIRLY-STABLE and older versions it is/was not possible to enter input requests in the REPL when SLIME was in the "debugging state". The current state should be indicated in the modeline. However, C-c C-: and most other commands can also be used in the debugging state. And of course, the REPL is supposed to work again if you return from the debugger.
Thank you for the information. I tried the non-FAIRLY-STABLE version of SLIME out of CVS, and everything works like a charm. I suppose this means OpenMCL does not play well with FAIRLY-STABLE.
-
Constantine Vetoshev -
Helmut Eller