-----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