Examine the values โ€‹โ€‹of local variables in the SLIME debugger?

I am looking for the best technique for this. My common struggle is that the debugger comes in too late or too early to catch the value of the variables.

What I tried first:

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

When the debugger enters break, I cannot access i :( So this is a wasted effort. I tried the debugger option e (eval in the frame), but SLIME is usually just an error and I have to reconnect to SWANK. v or t do not help, because the variable simply "does not exist."

What I finished:

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

This is stupid, but works because it pushes i onto the frame stack, which I can check in the debugger. But it's just ... well, he breaks into the worst sense of the word. Isn't there a way to โ€œlookโ€ at a variable or have a more meaningful way to set a breakpoint so that I can see more variables around the place where the breakpoint was entered?

+4
source share
1 answer

Your first snippet works great for me with CCL (default optimize settings), Emacs 24, and the recently-released 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 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. Maybe you should try another Lisp implementation or another version of Slime.

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

+2
source

All Articles