Question

I’m in search for a better technique for doing it. My general struggle is with the fact that debugger enters either too late or too early to be able to catch the value of the variables.

What I tried first:

(loop for i from 0 to 10 do
  (break))

When debugger enter on break, I can’t access i 🙁 So it’s a wasted effort. I’ve tried e option of debugger (eval in frame), but SLIME generally just bugs out, and I have to reconnect to SWANK. v or t don’t help, because the variable just “isn’t there”.

What I ended up doing:

(loop for i from 0 to 10 do
  (signal i))

This is stupid, but works, because it puts i on the stack of the frame I can examine in debugger. But this is just… well, it’s hackish in the worst sense of the word. Isn’t there some way to “watch” a variable, or have a more meaningful way to put a breakpoint, such that I can see more variables around the place the breakpoint is entered?

Answer 1

Your first snippet works just fine for me with CCL (default optimize settings), Emacs 24, and a recently pulled Slime:

Break
   [Condition of type SIMPLE-CONDITION]

Restarts:
 0: [CONTINUE] Return from BREAK.
 1: [RETRY] Retry SLIME REPL evaluation request.
 2: [*ABORT] Return to SLIME's top level.
 3: [ABORT-BREAK] Reset this thread
 4: [ABORT] Kill this thread

Backtrace:
  0: (#<Anonymous Function #x186F9B7E>)
      Locals:
        I = 0
  1: (CCL::CHEAP-EVAL (LOOP FOR I FROM 0 TO 10 DO (BREAK)))

⋮

sldb-eval-in-frame works fine for me, too. Maybe you should try a different Lisp implementation or a different version of Slime.

Also, note that different optimize settings might be important here, and some implementations give better debugging results for interpreted code (if an interpreter is available, that is). Try something like (declaim (optimize (debug 3) (speed 0) (space 0))).