Daniel Barlow dan@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.