Debug repls for eval-in-frame

[anlsh]

When I'm trying to evaluate expressions in debug frames, I've often been annoyed that I have to type my expressions into the minibuffer (where some of the minor modes / keybinds I like are disabled). A related annoyance is that larger output from eval-in-frame gets shunted off to another buffer/window which, depending on where emacs decides to drop it, might replace an important buffer on my screen.

Personally, I would really like the option to spawn some sort of "debug repl" buffer, which functioned more or less like an ordinary sly-mrepl-mode buffer except that all expressions happen to be evaluated in the spawning debug frame. Ideally the buffer would be automatically killed upon debug frame cleanup too.

Is there any scope in sly for a feature like this (perhaps even some option/command I've overlooked)?

[joaotavora]

Personally, I would really like the option to spawn some sort of "debug repl" buffer, which functioned more or less like an ordinary sly-mrepl-mode buffer except that all expressions happen to be evaluated in the spawning debug frame. Ideally the buffer would be automatically killed upon debug frame cleanup too.

This is interesting, but needs to be very well thought out to be effective.

When the error stems from the REPL itself, you already get a kind of indication (in the prompt) that you're inside the "context" of an error. This is much like in any lisp's "raw" REPL, SBCL and so. But, jus tlike in those REPL's evaluation does not happen in the frame of the error It's just code run by the *debugger-hook*, which is looping around waiting for requests from the network.

Also, I'm not sure all Lisps support evaluating in a particular frame.

But let's get down to business. Maybe we could enhance that interface, the error-from-the-REPL interface so that evaluations are done in the top-level frame where the debugger was invoked. Maybe this would be an interesting, useful and "clean" first step? You want to prototype it? At any rate it would need a clear indication that one is in this "mode".

But that would leave all the other errors that stem asynchronously from other parts of the Lisp. Maybe spawn a REPL for those? What about evaluating things in other non-top frames? Is that ever useful?

[joaotavora]

(Oh and congrats for inaugurating the discussion feature here 🎊 ! Also checking if things thread here or not)

[anlsh]

I'm not sure I understand what you're saying, so I just want to make sure I understand things here

First off, can you explain to me what a top-level frame is?

When the error stems from the REPL itself, you already get a kind of indication (in the prompt) that you're inside the "context" of an error. This is much like in any lisp's "raw" REPL, SBCL and so. But, jus tlike in those REPL's evaluation does not happen in the frame of the error It's just code run by the debugger-hook, which is looping around waiting for requests from the network.

This part is describing the cause of the following behaviour, correct?

1. Type (let ((b 0)) (/ 1 0)) in the *sly-repl* buffer, which pops up a sly-db buffer complaining about a division-by-zero error. *sly-repl* is still active
2. Evaluating b in *sly-repl* doesn't work, since b isn't being evaluated within the error frame

But let's get down to business. Maybe we could enhance that interface, the error-from-the-REPL interface so that evaluations are done in the top-level frame where the debugger was invoked. Maybe this would be an interesting, useful and "clean" first step? You want to prototype it? At any rate it would need a clear indication that one is in this "mode".

But that would leave all the other errors that stem asynchronously from other parts of the Lisp. Maybe spawn a REPL for those? What about evaluating things in other non-top frames? Is that ever useful?

I'm only guessing here, but the second section indicates to me that you're envisioning a mechanism by which the frame of an existing REPL buffer is changed to the "top-level frame where the debugger was invoked." IE, you're thinking that step 2 from earlier should evaluate to 0 because the *sly-repl* buffer would be placed into some special transient state where it evaluated things in the debug frame.

In this conception, your questions concerning asynchronous errors and debug repls for non top-level frames (another question: what is a "top level frame?") make a lot of sense. I, however, was describing a more manual process which I think avoids these issues

I was thinking of adding a command, call it spawn-repl-for-frame which could be invoked on arbitrary frame buttons in a sly-db buffer (like eval-in-frame can be), which would spawn a *sly-repl-for-frame-xyz* buffer. We already have eval-in-frame, so I was thinking that the "eval" step in the REPL for the *sly-repl-for-frame-xyz* could essentially just be replaced by an eval-in-frame xyz.

This "one frame one buffer" approach avoids the asynchronicity issue you mentioned, since debug frames are no longer competing to change the "mode" of the "main" repl. Also, since the user themself spawns debug repls from the relevant frame button, they could naturally do so for any frame they wanted to.

[joaotavora]

A top level frame is the topmost frame. In your example, it is the frame that signalled the error. In SBCL it's the first in this list (frame 0):

Backtrace:
 0: (SB-KERNEL::INTEGER-/-INTEGER 1 0)
 1: (SB-INT:SIMPLE-EVAL-IN-LEXENV (LET ((B 0)) (/ 1 0)) #<NULL-LEXENV>)
 2: (EVAL (LET ((B 0)) (/ 1 0)))
 3: ((LAMBDA NIL :IN SLYNK-MREPL::MREPL-EVAL-1))
 --more--

Note that you cannot "evaluate B" anymore. In SBCL at least, it has been optimized away by the compiler. But you can access these locals:

 0: (SB-KERNEL::INTEGER-/-INTEGER 1 0)
      Locals:
        X = 1
        Y = 0
 1: (SB-INT:SIMPLE-EVAL-IN-LEXENV (LET ((B 0)) (/ 1 0)) #<NULL-LEXENV>)
      Locals:
        SB-KERNEL:LEXENV = #<NULL-LEXENV>
        SB-IMPL::ORIGINAL-EXP = (LET ((B 0)) ..)
 2: (EVAL (LET ((B 0)) (/ 1 0)))
      Locals:
        SB-IMPL::ORIGINAL-EXP = (LET ((B 0)) ..)
 3: ((LAMBDA NIL :IN SLYNK-MREPL::MREPL-EVAL-1))
      Locals:
        SLYNK-MREPL::FORM = (LET ((B 0)) ..)
        SLYNK-MREPL::IN = #<SB-IMPL::STRING-INPUT-STREAM {10059DB583}>

Evaluating b in sly-repl doesn't work, since b isn't being evaluated within the error frame

As we've seen, that's not the only reason why evaluating b doesn't work. But yes, it's one of the reasons. In other Lisps depending on how eval works, they might be accessible in some frames.

I'll get back to you on the other points when I can.

[joaotavora]

IE, you're thinking that step 2 from earlier should evaluate to 0 because the sly-repl buffer would be placed into some special transient state where it evaluated things in the debug frame.

Yes, I'm thinking that.

I, however, was describing a more manual process which I think avoids these issues

What you described avoids some issue, but it brings others. Such as how to deal with that REPL once the frame is destroyed. Or what to do if two REPLs are accessing different frames of the same stack? What to do if one of these trigger an error or invoke an active restart. These semantics would have to be precisely specified.

This "one frame one buffer" approach avoids the asynchronicity issue you mentioned, since debug frames are no longer competing to change the "mode" of the "main" repl.

OK, I think I understand your model. It has some promise of simplicity too, I can understand that.

Just noting that SLY can already have more than one REPL (in case you didn't know what). However, when evaluating things in a frame (in Lisps that allow it) that evaluation must happen in a specifc thread, the thread where the error happened. That thread is usually not prepared to serve REPL requests (which are slightly different from normal RPC requests). In other words, when spawning a REPL one
must give it a thread, but I'm not sure it can be "any thread". I'd have to check.

[AkashaP]

Oh hello, I had the same desire so I went ahead and made a plugin myself, I did not notice this thread until after I made the announcement thread. I hope it's good enough. It even prints stuff like local variables to the repl as buttons that you can press.

#494

I mostly just copy pasted stuff i saw from sly code, iirc works just by storing the name of the debugger buffer and executing eval-in-frame in that buffer, and it works well enough for me I haven't got it to crash or anything yet.

The repl is does not close after the debugger window closes and stays 'sticky'. If it is closed with kill-buffer it regenerates itself when needed. There is one eval-in-frame repl per unique debugger window name, so it works if there are multiple debugger windows even latched onto the same lisp instance, but it is sticky so if for example the debugger is closed and another exception pops up with the same name then the listings of variables etc. will be stale but will still work and you can still just press Z to print out the new listings again. It auto-detects if the debugger it is meant to send commands to is gone and will just print a notification until the debugger is available again.