[slime-devel] Asynchronous debugging

[Helmut Eller]

Daniel Barlow <dan at telent.net> writes:

> More on yesterday's experiments.  The attached patch 

Where is it? :)

> (1) adds :debug as a valid state transition from the idle state

Perhaps a different name for the event, e.g, :async-debug, would be
better.  There is a certain risk that this transition hides
(unrelated) bugs, if we use the same name.  We might also consider to
make this an out-of-band event.

> (2) adds SLIME-DEBUGGER-FUNCTION.  This expects to be run in an
>     environment in which the slime streams are available (e.g. from 
>     *slime-repl* or, I think, with C-c :) and returns a function that
>     can be used for *debugger-hook* or *invoke-debugger-hook*
> 
>     Note that (setf sb-debug::*invoke-debugger-hook* (slime-debugger-function))
>     doesn't actually work from *slime-repl* because the hook has
>     already been bound so you're not setting the global value.
>     Answers on a postcard.

I assume you would like the set *invoke-debugger-hook*, so that it is
used in your asynchronous handlers.  We could modify the swank-server
and enter an infinite loop instead of using fd-handlers for request
processing.  This "slime-loop" (idle-loop? break-loop?) would be
similar to the sldb-loop.  Assignments to special variables would then
be visible as long as you are in the dynamic extend of the slime-loop.
Is it acceptable that all your handlers run in the dynamic extend of
the this loop?

Another idea is that we allow support multiple sessions with multiple
tcp connections (each session a dedicated connection).  A
asynchronous handler could then initiate a new session.

> (3) Changes eval-string to use *invoke-debugger-hook* instead of 
>     ordinary *debugger-hook* - because it's safe for BREAK, and also 
>     so it doesn't conflict with my existing (notionally portable)
>     *debugger-hook* use in Araneida
> 
>     If I culd figure out an appropriate place to put it, I'd want to 
>     make this a (with-debugging-hooked ...) macro, but I think that
>     needs build order frobbing

Until now we worked around this problem and used functions like
call-with-debugging-hooked.  The function is then defined later.
Perhaps we should split the files again, so that the build order would
be like: swank-early, swank-sbcl-early, swank, swank-sbcl.  The
*-early files contain the macro definitions a non portable package
frobbing.

Helmut.