Debugger REPL

[SuperDisk]

In #581, @phoe suggested the ability to have a REPL inside the context of a stack frame. It seems like this is the default behavior of the SBCL REPL and ECL REPL when run from a command line, as you can access all locals and evaluate whatever you want.

You can kind of achieve this in SLIME by pressing e on a stack frame and then typing an S-expression into the minibuffer, so it's technically feasible, but it's not good enough. It would be extremely, extremely handy to have a full REPL, and be able to use C-x C-e, and all the available evaluation hotkeys in our source file, in the context of a stack frame.

In that issue, @joaotavora indicated that Sly has this feature and so does SLIME; he said to just press enter at the REPL with the debugger open and that's it. I tried with both SLIME and SLY and found that in SLIME, the REPL does let you continue evaluating forms, but it's not in the context of any particular stack frame, it's just the normal toplevel. In SLY, the REPL says that it's busy and you can't type anything at all. So was he just mistaken, or did the code change since then and it's different now, or am I missing something?

I'm wondering if this feature exists or what would be needed to make it exist, since I think this would be an absolutely fundamental and liberating change of the way I'm debugging stuff right now.

[joaotavora]

So was he just mistaken, or did the code change since then and it's different now, or am I missing something?

If you have a question about SLY, you can ask in SLY's tracker, so you get the benefit of addressing me directly ;-)
You can also provide an exact repro of what you're trying to do, your observations and your unfulfilled expectations. I can't guess why you're seeing a "REPL is busy".

AFAIR this is what I meant by my contributions to that issue. I've just run this experiment, as documented in the screenshot.

But this doesn't mean that typing things on the REPL on the right means the same as typing e on a frame on the left .There are multiple frames there, and the REPL can't guess which one you mean. Say you eval bar in the REPL? What bar would that be? This isn't gdb and there isn't a "frame" command. I guess there could be, but I've never really missed it: in SLY and SLIME, I just recompile and choose a restart. Can't do that in in gdb!

[SuperDisk]

@joaotavora Heh, sorry, I thought since you mentioned that it should be part of SLIME, I didn't want to come double post on your repo as well :) but thanks for the response.

Here's an example where I've defined a function called my-func, and it hits a break. The REPL locks up and when I try to hit enter in it, it shows Args out of range: 301 in the minibuffer. Last time I believe it showed the "REPL is busy" message.

I did notice though, that before I evaluated the function, I accidentally tried to call it, and when it opened the debugger to tell me that the function didn't exist it did behave like you show here in that it showed the [1] in the REPL.

[SuperDisk]

It seems to be some sort of problem with (break), if I use (error "whatever") the REPL will indeed continue functioning like you said. But I noticed that I can't access locals in it, so it's not really in the context of that stack frame.

Here's the code:

(defun my-func (a)
  (declare (optimize (debug 3)))
  (let ((y 5))
    (prog1
        (+ y
           (* a 2))
      (error "Yoooo"))))

Compare to if I just run it with SBCL directly in the shell:

➜  Desktop sbcl --noinform --load test.lisp
* (my-func 1)

debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {10048D0253}>:
  Yoooo

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(MY-FUNC 1)
   source: (ERROR "Yoooo")
0] (print a)


11 
0] 

So clearly it can work. I'm just wondering if this functionality is exposed either in SLIME or SLY.

[joaotavora]

Not 100% sure about SLIME, but I am about am about SLY, and no it's not exposed there.

As to the difference with break vs error I think back in the day I could explain why it's different, but I can't right now. Maybe an issue (in the SLY repo) will jog my memory.