On 1/13/06, Paolo Amoroso <amoroso@mclink.it> wrote:

Jonathon McKitrick <jcm@FreeBSD-uk.eu.org> writes:

...

I'm new to SLIME, and trying to figure out some practical debugging strategies since I'm so used to single-stepping and breakpoints, and we don't have those facilities (IIRC) under Lisp/SLIME.

My own debugging approach is heavily based on SLIME's ability to display function call backtraces and examining/inspecting stack frames. I personally rarely use single-stepping and breakpoints.

I agree. With a functional programming style your error is usually on the stack and easily seen examining the backtrace. Michael

On Fri, 13 Jan 2006, Jonathon McKitrick wrote:

On Fri, Jan 13, 2006 at 04:18:37PM +0100, Paolo Amoroso wrote: : Jonathon McKitrick <jcm@FreeBSD-uk.eu.org> writes: : : > I'm new to SLIME, and trying to figure out some practical debugging strategies : > since I'm so used to single-stepping and breakpoints, and we don't have those : > facilities (IIRC) under Lisp/SLIME. : : My own debugging approach is heavily based on SLIME's ability to : display function call backtraces and examining/inspecting stack : frames. I personally rarely use single-stepping and breakpoints.

But doesn't that require an exception or an error to break into the debugger? If you are trying to track down a logic error, what approach can you use?

PRINT. The fact that it returns its argument and that recompiling a function takes a fraction of a second, makes this old-fashioned debugging method quite useful. Andras

Jonathon McKitrick <jcm@FreeBSD-uk.eu.org> writes:

On Fri, Jan 13, 2006 at 04:18:37PM +0100, Paolo Amoroso wrote: [...] : My own debugging approach is heavily based on SLIME's ability to : display function call backtraces and examining/inspecting stack : frames. I personally rarely use single-stepping and breakpoints.

But doesn't that require an exception or an error to break into the debugger?

Well, my bugs already provide enough opportunities for entering the debugger without explicit breakpoints or calls to BREAK...

If you are trying to track down a logic error, what approach can you use?

As Andreas has already pointed out, strategically placed PRINT or FORMAT expressions are handy and effective tools. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

* Jonathon McKitrick [2006-01-14 08:30+0100] writes:

I've read the links you guys have posted, and I have figured out a lot. But there is one thing yet eluding me. I'm running SLIME with SBCL, and I cannot figure out how to resume execution after breaking into the debugger. I've been able to edit the code, recompile, and restart the whole execution, but actually fixing the code and continuing from that stack frame doesn't seem to work for me yet. When I enter a number 0-9 for the stack frame to resume, SBCL complains by breaking again and telling me I cannot continue from there.

Pressing 0-9 doesn't restart the frame with the corresponding number; it invokes the restart (see CLHS conditions chapter) for that number. E.g. if you call (break), SLIME will display something like this: Restarts: 0: [CONTINUE] Return from BREAK. 1: [ABORT-REQUEST] Abort handling SLIME request. 2: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {AF41B49}>) Backtrace: 0: (BREAK "break") 1: (SB-INT:EVAL-IN-LEXENV (BREAK) #<NULL-LEXENV>) Pressing 0 invokes the `continue' restart, which will return from the call to BREAK; it doesn't restart the frame 0. Restarting a frame (i.e. selecting a frame, unwinding the stack down to that frame, and invoking the corresponding function with the same arguments) isn't implemented for SBCL. I think it works for Lispworks, Allegro, and OpenMCL. This kind of restarting a frame would be most useful if the program needs to run a long time before the bug is triggered. You could fix the bug and test the fix quickly without having to wait again. If your application never runs for very long, you probably don't miss much if you simply restart from the beginning. Often it's also not necessary to unwind the stack before you can test a fix: you can just call the modified function from within the debugger (if you can figure out the arguments which triggered the bug). Helmut.