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.
What are some ways to accomplish the same thing? Or do we just use C-c C-t and debug that way, reading return values from traced functions?
-Jonathon -- "I am sure that Jesus would use a command prompt. Hello? Ten Commandments??"
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.
Paolo
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, 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?
-Jonathon -- "I am sure that Jesus would use a command prompt. Hello? Ten Commandments??"
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
On Fri, 13 Jan 2006 15:48:29 +0000, Jonathon McKitrick jcm@FreeBSD-uk.eu.org wrote:
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?
There's also BREAK:
http://www.lispworks.com/documentation/HyperSpec/Body/f_break.htm
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
On Fri, Jan 13, 2006 at 03:48:29PM +0000, Jonathon McKitrick wrote:
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?
Liberal ASSERT forms will serve to drop you into the debugger when suspicious things happen. If the run-time cost is problematic for release they can be conditionally killed by simply shadowing ASSERT in your package.
http://www.lispworks.com/documentation/HyperSpec/Body/m_assert.htm
Also, TRACE is your friend.
-bcd
Hi Jonathan,
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.
What are some ways to accomplish the same thing? Or do we just use C-c C-t and debug that way, reading return values from traced functions?
You might find some of the techniques described in these blog postings useful: http://bc.tech.coop/blog/050608.html http://bc.tech.coop/blog/050616.html http://bc.tech.coop/blog/040628.html http://bc.tech.coop/blog/040922.html
-- Bill Clementson
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.
-Jonathon -- "I am sure that Jesus would use a command prompt. Hello? Ten Commandments??"
* 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.
-
Andras Simon -
bdowning＠lavos.net -
Bill Clementson -
Edi Weitz -
Helmut Eller -
Jonathon McKitrick -
Michael Price -
Paolo Amoroso