[slime-devel] Slime lockup after returning from SLDB
I am running the CVS of SLIME as of 27-Oct-2005 in GNU Emacs 21.3.1 on Windows XP using CLISP 2.35 as the backend. After aborting an error that throws me into the SLDB I get no prompt in the SLIME REPL. If I try to evaluate a form or variable (or even a blank line), I get the following in the mini-buffer: ;pipelined request... (swank:listener-eval "form I evaluated") If I try to evaluate a form in another buffer I get a similar response: ;pipelined request... (swank:interactive-eval "form I evaluated") The inferior-lisp buffer seems to still be working perfectly when I evaluate a test form in it. I've discovered that if I use "M-x slime" I can get SLIME to break out of this lockup, but this is definitely non-optimal. Any help with this would be appreciated. Jonathan Lee (format t "~A@~A.~A" '2jlee 'earthlink 'net)
Jonathan Lee <2jlee@earthlink.net> writes:
I am running the CVS of SLIME as of 27-Oct-2005 in GNU Emacs 21.3.1 on Windows XP using CLISP 2.35 as the backend.
After aborting an error that throws me into the SLDB I get no prompt in the SLIME REPL. If I try to evaluate a form or variable (or even a blank line), I get the following in the mini-buffer:
;pipelined request... (swank:listener-eval "form I evaluated")
The "pipelined request" message is printed when SLIME issues a new request before the previous one is answered. Sounds like the Abort to SLDB has not really aborted. Does this happen for all errors, e.g. (error "foo")? Just to check if it's an error in a restart handler.. I wonder if there is some SIGINT-like way to force CLISP to enter the debugger on Windows? It would be good to know where it is stuck.
Luke Gorrie wrote:
Jonathan Lee <2jlee@earthlink.net> writes:
I am running the CVS of SLIME as of 27-Oct-2005 in GNU Emacs 21.3.1 on Windows XP using CLISP 2.35 as the backend.
After aborting an error that throws me into the SLDB I get no prompt in the SLIME REPL. If I try to evaluate a form or variable (or even a blank line), I get the following in the mini-buffer:
;pipelined request... (swank:listener-eval "form I evaluated")
The "pipelined request" message is printed when SLIME issues a new request before the previous one is answered. Sounds like the Abort to SLDB has not really aborted.
Does this happen for all errors, e.g. (error "foo")? Just to check if it's an error in a restart handler..
I wonder if there is some SIGINT-like way to force CLISP to enter the debugger on Windows? It would be good to know where it is stuck.
_______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Aborting from the SDBL after evaluating (error "foo") does the same thing. Unfortunately, I am a semi-newbie with Lisp and especially with CLISP in particular so I can't answer that question.
On 10/29/05, Jonathan Lee <2jlee@earthlink.net> wrote:
Luke Gorrie wrote:
Jonathan Lee <2jlee@earthlink.net> writes:
I am running the CVS of SLIME as of 27-Oct-2005 in GNU Emacs 21.3.1 on Windows XP using CLISP 2.35 as the backend.
After aborting an error that throws me into the SLDB I get no prompt in the SLIME REPL. If I try to evaluate a form or variable (or even a blank line), I get the following in the mini-buffer:
;pipelined request... (swank:listener-eval "form I evaluated")
The "pipelined request" message is printed when SLIME issues a new request before the previous one is answered. Sounds like the Abort to SLDB has not really aborted.
Does this happen for all errors, e.g. (error "foo")? Just to check if it's an error in a restart handler..
I wonder if there is some SIGINT-like way to force CLISP to enter the debugger on Windows? It would be good to know where it is stuck.
I've experienced the lock up you describe if I hit Abort instead of Abort Slime request. It didn't used to do that so it's a new thing but seems to be avoided by never using the Abort.
Justin Heyes-Jones wrote:
<snipped>
I've experienced the lock up you describe if I hit Abort instead of Abort Slime request.
It didn't used to do that so it's a new thing but seems to be avoided by never using the Abort.
I believe that I am using the sldb-abort when I press the <a> key (at least that's what the SLIME manual PDF file states). When I try using the listed "abort" option by clicking on it then pressing the <ENTER> key, it locks up just the same though.
* Jonathan Lee [2005-10-30 03:20+0100] writes:
I believe that I am using the sldb-abort when I press the <a> key (at least that's what the SLIME manual PDF file states). When I try using the listed "abort" option by clicking on it then pressing the <ENTER> key, it locks up just the same though.
Yes, that's true. The problem is that the `abort' restart is established by CLISP's native REPL and is "below" the SLIME event loop. So if you invoke the restart, you jump out of the loop and SLIME stops responding to events. The usual way to exit from SLDB is with `q' which to invokes the `abort-request' restart. I added some cleanup code in the CVS version, so that the connection gets closed when the event loop terminates. Emacs will then display a message saying that the connection is closed. Helmut.
Helmut Eller wrote:
* Jonathan Lee [2005-10-30 03:20+0100] writes:
I believe that I am using the sldb-abort when I press the <a> key (at least that's what the SLIME manual PDF file states). When I try using the listed "abort" option by clicking on it then pressing the <ENTER> key, it locks up just the same though.
Yes, that's true. The problem is that the `abort' restart is established by CLISP's native REPL and is "below" the SLIME event loop. So if you invoke the restart, you jump out of the loop and SLIME stops responding to events.
The usual way to exit from SLDB is with `q' which to invokes the `abort-request' restart.
I added some cleanup code in the CVS version, so that the connection gets closed when the event loop terminates. Emacs will then display a message saying that the connection is closed.
Helmut.
That worked. Thank you. You might want to note in the SLIME documentation that the <q> command is the preferred abort restart and that the <a> command will kill SLIME as well.
Helmut Eller <heller@common-lisp.net> writes:
The problem is that the `abort' restart is established by CLISP's native REPL and is "below" the SLIME event loop. So if you invoke the restart, you jump out of the loop and SLIME stops responding to events.
Is this a recent change? I've been using 'a' to abort from sldb for a long time, and only noticed these hanging problems recently.
The usual way to exit from SLDB is with `q' which to invokes the `abort-request' restart.
What's the use of providing the 'a'/abort restart when it produces surprising, disruptive behavior? I keep hitting 'a', finding SLIME unresponsive to subsequent evaluation requests, and having to kill and restart CLISP. The names seem backward, too. I would expect "quit" to imply what abort is currently doing -- killing the CL session. It seems more natural to me to "abort" from problematic evaluations that invoke the debugger and to "quit" SLIME when I don't want to interact with my CL session any longer. -- Steven E. Harris
* Steven E. Harris [2005-10-31 03:20+0100] writes:
Is this a recent change? I've been using 'a' to abort from sldb for a long time, and only noticed these hanging problems recently.
The change is a month old or so.
The usual way to exit from SLDB is with `q' which to invokes the `abort-request' restart.
What's the use of providing the 'a'/abort restart when it produces surprising, disruptive behavior? I keep hitting 'a', finding SLIME unresponsive to subsequent evaluation requests, and having to kill and restart CLISP.
`abort' is a standard restart and it can be useful to have it on key. It's also used to exit from say SDBL level 2 to level 1. I added an extra abort restart so that you can press `a' if you like.
The names seem backward, too. I would expect "quit" to imply what abort is currently doing -- killing the CL session. It seems more natural to me to "abort" from problematic evaluations that invoke the debugger and to "quit" SLIME when I don't want to interact with my CL session any longer.
`q' is the key to exit from the Emacs debugger, so it pretty natural to use the same key for the same purpose in SLDB. Helmut.
On Mon, 31 Oct 2005, Helmut Eller wrote:
`q' is the key to exit from the Emacs debugger, so it pretty natural to use the same key for the same purpose in SLDB.
Besides, it's the key used throughout Slime to kill pop-up windows (like Connections, Threads, Inspector, etc). So I think it's crucial that it does what it's always been doing in SLDB. Andras
Helmut Eller <heller@common-lisp.net> writes:
The change is a month old or so.
Ah, it had been about two months since I had last used SLIME for any debugging.
`abort' is a standard restart and it can be useful to have it on key. It's also used to exit from say SDBL level 2 to level 1.
Regarding this jumping from level 2 to level 1, does this mean that the abort restart only kills the Lisp implementation if used at SLDB level 1? I just know that hitting 'a' was ingrained in muscle memory, so apparently it used to do what I expected.
I added an extra abort restart so that you can press `a' if you like.
Thanks. Last night after posting my admittedly hot-tempered message, I consciously tried using 'q' instead and did find the similarity described both by you and in Andras Simon's follow message to be nice and logical.
`q' is the key to exit from the Emacs debugger, so it pretty natural to use the same key for the same purpose in SLDB.
Got it. I just need to unlearn the impulse to hit 'a'. -- Steven E. Harris
participants (6)
-
Andras Simon -
Helmut Eller -
Jonathan Lee -
Justin Heyes-Jones -
Luke Gorrie -
Steven E. Harris