Peter Seibel <peter@javamonkey.com> writes:

Peter Seibel <peter@javamonkey.com> writes:

...

I can swear I had this working great the other day but I don't remember doing anything special to make it happen. Anyway, here it is: I'm using AllegroServe and when one of the server threads drops into the debugger I want--of course--to be in an sldb debugger. I've given AllegroServe the magic incantation (net.aserve::debug-on :notrap) which causes it to let unhandled errors drop us into the debugger but I'm just getting to Allegro's debugger in *inferior-lisp*. I've got:

#+allegro(tpl:setq-default *debugger-hook* #'swank:swank-debugger-hook)

In my ~/.swank.lisp for whatever that's worth. What am I spacing on?

So, setting *debugger-hook* in *inferior-lisp* seems to help. If I signal an error while handling a request in AllegroServe I get an *sldb* debugger. But when I abort (via Q) from that then I end up in the Allegro debugger in the *inferior-lisp* buffer. I'm totally confused.

More chaos: I put some FORMAT expressions in my .swank.lisp such as: (format t "Yo! Loading ~a in ~a~%" *load-pathname* mp:*current-process*) (format t "Yo! *debugger-hook*: ~a; tpl::*debugger-hook*: ~a~%" *debugger-hook* tpl::*debugger-hook*) so I can see in *inferior-lisp* after starting slime (via M-x slime): Yo! Loading /home/peter/.swank.lisp in #<PROCESS Initial Lisp Listener> Yo! *debugger-hook*: #<Function SWANK-DEBUGGER-HOOK>; tpl::*debugger-hook*: #<Function SWANK-DEBUGGER-HOOK> However after slime has started if I eval *debugger-hook* and tpl::*debugger-hook* at the REPL in *inferior-lisp* I get NIL for both. Does anyone know who the heck is resetting them? (Or are they bound by LOAD or something goofy like that? A simple test with SLIME out of the picture says no.) -Peter -- Peter Seibel peter@javamonkey.com Lisp is the red pill. -- John Fraser, comp.lang.lisp