At the protocol level, I don't quite see why :DEBUG and :DEBUG-ACTIVATE do what they do. For a quick recap, Swank sends :DEBUG, and slime calls sldb-setup. Swank then sends :DEBUG-ACTIVATE, for that level of debug, Slime sends back :DEBUGGER-INFO-FOR-EMACS 0 10. When that returns sldb-setup is called again (with the same info it just got?)
So it looks to me like there is some redundancy here, could somebody please enlighten me about how :DEBUG and :DEBUG-ACTIVATE work?
Cheers Brad
* Brad Beveridge [2006-11-05 21:36+0100] writes:
At the protocol level, I don't quite see why :DEBUG and :DEBUG-ACTIVATE do what they do. For a quick recap, Swank sends :DEBUG, and slime calls sldb-setup. Swank then sends :DEBUG-ACTIVATE, for that level of debug, Slime sends back :DEBUGGER-INFO-FOR-EMACS 0 10. When that returns sldb-setup is called again (with the same info it just got?)
The Swank server does looks something like this:
(send (:debug <debug-info>) <emacs>) (loop (send (:debug-activate <level>) <emacs>) (send (eval (receive <emacs>)) <emacs>)) ; recursion possible (send (:debug-return <level>) <emacs>)
So it looks to me like there is some redundancy here, could somebody please enlighten me about how :DEBUG and :DEBUG-ACTIVATE work?
The original indent of sending :debug-activate on each iteration was to simplify the handling of situations like "return from debug level 3 to debug level 2". I guess it could also be detected with the :debug-return alone, but not as conveniently (consider switching from level 4 to level 1).
Also note that Emacs requests :debug-info-for-emacs only if the level indicated by :debug-activate differs from the level in the current sldb buffer. Usually, the :debug message includes enough information to set up the sldb buffer and :debug-activate will just display the buffer. Yes, :debug is redundant, but it saves a round-trip (i.e. :debug-info-for-emacs message and reply) in the common case, in which the user presses q shortly after entering the sldb buffer.
Helmut.
On 06/11/06, Helmut Eller heller@common-lisp.net wrote:
- Brad Beveridge [2006-11-05 21:36+0100] writes:
At the protocol level, I don't quite see why :DEBUG and :DEBUG-ACTIVATE do what they do. For a quick recap, Swank sends :DEBUG, and slime calls sldb-setup. Swank then sends :DEBUG-ACTIVATE, for that level of debug, Slime sends back :DEBUGGER-INFO-FOR-EMACS 0 10. When that returns sldb-setup is called again (with the same info it just got?)
The Swank server does looks something like this:
(send (:debug <debug-info>) <emacs>) (loop (send (:debug-activate <level>) <emacs>) (send (eval (receive <emacs>)) <emacs>)) ; recursion possible (send (:debug-return <level>) <emacs>)
So it looks to me like there is some redundancy here, could somebody please enlighten me about how :DEBUG and :DEBUG-ACTIVATE work?
The original indent of sending :debug-activate on each iteration was to simplify the handling of situations like "return from debug level 3 to debug level 2". I guess it could also be detected with the :debug-return alone, but not as conveniently (consider switching from level 4 to level 1).
Also note that Emacs requests :debug-info-for-emacs only if the level indicated by :debug-activate differs from the level in the current sldb buffer. Usually, the :debug message includes enough information to set up the sldb buffer and :debug-activate will just display the buffer. Yes, :debug is redundant, but it saves a round-trip (i.e. :debug-info-for-emacs message and reply) in the common case, in which the user presses q shortly after entering the sldb buffer.
I'd missed that Slime doesn't do the extra call for info when the levels are the same. It does make more sense to me now. This basically means that the Slime side only needs to keep one set of debugging information, and as the level is transitioned it regets the info. I was planning on making a class to hold all the information about a debug level and use debug activate to just change the active level. I think I'll stick to what Slime does though, and re call for info on level change.
Cheers Brad