Although it makes perfect sense, I find it irritating that the number for the [abort-request] restart in SLDB depends on how many other restarts are active. For clarity's sake, here is a list of restarts:
Restarts: 0: [RETRY] Retry performing #<LOAD-OP NIL #x84F81F6> on #<SYSTEM "cl-containers" #x84E8EE6>. 1: [ACCEPT] Continue, treating #<LOAD-OP NIL #x84F81F6> on #<SYSTEM "cl-containers" #x84E8EE6> as having been successful. 2: [ABORT-REQUEST] Abort handling SLIME request. 3: [ABORT-BREAK] Reset this process 4: [ABORT] Kill this process
In this case, I should type '2' to give up on this request and try something else. In other cases, however, I might need to type '7' or '5' or whatever. This means that I have to look and see what to type every single time I hit an error (and, hey, I hit a lot of errors in my code!). It also scares me that I could misread and type the key for [abort-break] or [abort] by accident. Here is my suggestion as to what the list of restarts might look like:
Restarts: 4: [RETRY] Retry performing #<LOAD-OP NIL #x84F81F6> on #<SYSTEM "cl-containers" #x84E8EE6>. 3: [ACCEPT] Continue, treating #<LOAD-OP NIL #x84F81F6> on #<SYSTEM "cl-containers" #x84E8EE6> as having been successful. 2: [ABORT-REQUEST] Abort handling SLIME request. 1: [ABORT-BREAK] Reset this process 0: [ABORT] Kill this process
or
Restarts: 0: [RETRY] Retry performing #<LOAD-OP NIL #x84F81F6> on #<SYSTEM "cl-containers" #x84E8EE6>. 1: [ACCEPT] Continue, treating #<LOAD-OP NIL #x84F81F6> on #<SYSTEM "cl-containers" #x84E8EE6> as having been successful. A: [ABORT-REQUEST] Abort handling SLIME request. R: [ABORT-BREAK] Reset this process K: [ABORT] Kill this process
In both cases, the three 'always there' restarts will always have the same keyboard binding. In the later example, they are non-numeric.
I'm willing to figure out how to implement this _if_ the general opinion is that this is a good idea. What is the general opinion?
thanks,
Gary King gwking@metabang.com writes:
Although it makes perfect sense, I find it irritating that the number for the [abort-request] restart in SLDB depends on how many other restarts are active. For clarity's sake, here is a list of restarts:
Restarts: 0: [RETRY] Retry performing #<LOAD-OP NIL #x84F81F6> on #<SYSTEM "cl-containers" #x84E8EE6>. 1: [ACCEPT] Continue, treating #<LOAD-OP NIL #x84F81F6> on #<SYSTEM "cl-containers" #x84E8EE6> as having been successful. 2: [ABORT-REQUEST] Abort handling SLIME request. 3: [ABORT-BREAK] Reset this process 4: [ABORT] Kill this process
In this case, I should type '2' to give up on this request and try something else. In other cases, however, I might need to type '7' or 5' or whatever. This means that I have to look and see what to type every single time I hit an error (and, hey, I hit a lot of errors in my code!). It also scares me that I could misread and type the key for [abort-break] or [abort] by accident. Here is my suggestion as to
Isn't q bound to ABORT-REQUEST for just this reason?
It may not be immediately obvious from the documentation that it is equivalent, but it indeed is. Maybe just the documentation needs to be improved?
Cheers,
-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."
On May 31, 2006, at 4:15 AM, Nikodemus Siivola wrote:
Gary King gwking@metabang.com writes:
Although it makes perfect sense, I find it irritating that the number for the [abort-request] restart in SLDB depends on how many other restarts are active. For clarity's sake, here is a list of restarts:
Isn't q bound to ABORT-REQUEST for just this reason?
It may not be immediately obvious from the documentation that it is equivalent, but it indeed is. Maybe just the documentation needs to be improved?
Wow, that is handy. If it is in the documentation then I missed it too.
Michael
+ Michael Price ectospheno@gmail.com:
| > Isn't q bound to ABORT-REQUEST for just this reason? | > | > It may not be immediately obvious from the documentation that it | > is equivalent, but it indeed is. Maybe just the documentation needs to | > be improved? | | Wow, that is handy. If it is in the documentation then I missed it too.
In the documentation? Try hitting C-h m while in the debugger.
- Harald
Isn't q bound to ABORT-REQUEST for just this reason?
Surprisingly enough, I learned that 'q' was bound to [abort-request] almost immediately after writing this post (it must be the cosmic unconscious). I know I'd feel better if the menu looked like:
Restarts: 0 : [RETRY] Retry performing #<LOAD-OP NIL #x84F81F6> on #<SYSTEM "cl-containers" #x84E8EE6>. 1 : [ACCEPT] Continue, treating #<LOAD-OP NIL #x84F81F6> on #<SYSTEM "cl-containers" #x84E8EE6> as having been successful. Q, 2: [ABORT-REQUEST] Abort handling SLIME request. 3 : [ABORT-BREAK] Reset this process 4 : [ABORT] Kill this process
I'd feel ever better if I couldn't kill the process without a confirmation... any thoughts on these two ideas?
On May 31, 2006, at 11:30 AM, Gary King wrote:
I'd feel ever better if I couldn't kill the process without a confirmation... any thoughts on these two ideas?
In my environment, for openmcl, I remove those restarts, as I don't think it is appropriate to kill the lisp from the sldb window. I've been meaning to make swank-compute-restarts a defimplementation, but never seem to get around to it. If you do decide to prompt to kill the lisp, it would be nice to get rid of the sldb window when doing so, since the lisp isn't around to talk about it with slime after it's been killed in this context.
#+openmcl (defun debug-in-emacs (condition) (let ((*swank-debugger-condition* condition) (*sldb-restarts* (swank-compute-restarts condition)) ;<--- swank-compute-restarts vs. compute-restarts (*package* (or (and (boundp '*buffer-package*) (symbol-value '*buffer-package*)) *package*)) (*sldb-level* (1+ *sldb-level*)) (*swank-state-stack* (cons :swank-debugger-hook *swank-state- stack*)) (*print-readably* nil)) (force-user-output) (call-with-debugging-environment (lambda () (sldb-loop *sldb-level*)))))
#+openmcl (defun swank-compute-restarts (condition) (butlast (compute-restarts condition) 2))
-Alan
-----Original Message----- From: slime-devel-bounces@common-lisp.net [mailto:slime-devel- bounces@common-lisp.net] On Behalf Of Gary King Subject: Re: [slime-devel] Re: On the numbering of restarts in SLDB
[...] I know I'd feel better if the menu looked like:
Restarts: 0 : [RETRY] Retry performing #<LOAD-OP NIL #x84F81F6> on #<SYSTEM "cl-containers" #x84E8EE6>. 1 : [ACCEPT] Continue, treating #<LOAD-OP NIL #x84F81F6> on #<SYSTEM "cl-containers" #x84E8EE6> as having been successful. Q, 2: [ABORT-REQUEST] Abort handling SLIME request. 3 : [ABORT-BREAK] Reset this process 4 : [ABORT] Kill this process
I'd feel ever better if I couldn't kill the process without a confirmation... any thoughts on these two ideas?
I kind of like the idea of showing which restart q is bound to, except that I would probably prefer "2, Q" so that the numbers still line up.
Not sure about confirming the abort restart, just need to make sure that any code for it doesn't stop me from actually killing it if is in a really unstable state (and therefore might not do well at running the confirmation code).
Is there a way to bind 'q', set a particular restart as the default 'exit' restart? When I'm hacking on UCW there is no "Abort handling SLIME request."
A database error occurred: NIL / 23000 [blah blah blah, yes I know..] Restarts: 0: [SHOW-BACKTRACE] Send the client a backtrace page. 1: [SERVER-ERROR] Send the client an internal server error page. 2: [GENERATE-BACKTRACE-FOR-EMACS] Generate a bug report in Emacs. 3: [FAIL-MISERABLY] Pretend this request never happend and fail. 4: [TRY-AGAIN] Play this request over from the top. 5: [TERMINATE-THREAD] Terminate this thread (#<THREAD "an httpd worker 0" {BD6A939}>)
I'm thinking 'fail-miserably which just closes all the streams and shuts down would be a good one to bind.
I looked around a little bit, it doesn't look like this is currently available. Q invokes slime's sldb-quit, which calls swank:throw-to-toplevel. Maybe add a new parameter that defaults to 'abort-request, but could be dynamically rebound to name a different restart before UCW invokes the swank-debugger? Swank:throw-to-toplevel would use the parameter to invoke the correct restart.
Any objections/much better ideas?
Nathan Bird
I looked around a little bit, it doesn't look like this is currently available. Q invokes slime's sldb-quit, which calls swank:throw-to- toplevel. Maybe add a new parameter that defaults to 'abort-request, but could be dynamically rebound to name a different restart before UCW invokes the swank-debugger? Swank:throw-to-toplevel would use the parameter to invoke the correct restart.
Any objections/much better ideas?
Patch attached that does the above. It works just fine for me!
New parameter named *sldb-quit-restart*, i.e. the restart used by sldb-quit.
I looked a bit about adding 'q' to the label of the sldb-quit restart, but the numbers are actually added late in the game in slime.el (sldb-insert-restarts). So a bit more code would be needed than I had hoped. We could add the *sldb-quit-restart* to the package of info that debugger-info-for-emacs sends, but it looks like by the time it gets to emacs it is no longer dealing with symbols, but entirely strings. Maybe swank:format-restarts-for-emacs could add an optional third element to the list it returns indicating if the restart is the sldb-quit-restart? Any other information about restarts that might need to be sent along?
Nathan
Patch attached that does the above. It works just fine for me!
New parameter named *sldb-quit-restart*, i.e. the restart used by sldb-quit.
it would be cool if that var was a list. i'm working a lot with UCW and when az error happens theres a fail miserably restart that closes the network stream and ignores the request. it's a major PITA to always find that restart...
but thanks for this improvement, too!
- attila
(alias 101 on irc &no 'its not lisp code :)
Gary King gwking@metabang.com writes:
Although it makes perfect sense, I find it irritating that the number for the [abort-request] restart in SLDB depends on how many other restarts are active. [...]
In both cases, the three 'always there' restarts will always have the same keyboard binding. In the later example, they are non-numeric.
I'm willing to figure out how to implement this _if_ the general opinion is that this is a good idea. What is the general opinion?
Do you know about the command SLDB-QUIT that is bound to `q'?
-T.
-
Alan Ruttenberg -
Attila Lendvai -
Gary King -
Harald Hanche-Olsen -
Michael Price -
Nathan Bird -
Nikodemus Siivola -
Tobias C. Rittweiler