ramb@sonic.net writes:

I've created a function (defun tester () ...) that does almost what I want - but its not totally correct. I would like to use the slime debugger to start this function and single step through its various parts to see where the mistake is. How do I do that with slime?

The support for stepping is, unfortunately, not very good. I usually insert a call to BREAK at the beginning of the function like: (defun tester () (break) ...) recompile the function, and then run the function. The debugger will pop up and you can use `s' for stepping. `s' inserts a breakpoint at the next "interesting" code location(s) and continues. The debugger will usually pop up again at the next breakpoint. Interesting code locations are: beginning of blocks, call-sites, and return points. I think "block" means a sequence of instructions without branches in CMUCL terminology. There are also sldb-break and sldb-break-on-return commands, but inserting an explicit BREAK works better in my experience. Here are some limitations of the current support: - Sometimes two code locations are at the same source location, i.e., the same position in the Emacs buffer. This can be a bit confusing, but hasn't annoyed me enough yet to fix it. The problem is more severe if your code contains a lot of macros. - There's currently no support for a gdb-like "step into" command, i.e., the ability to continue stepping in a called function. - I think there's also a problem/bug when stepping through unwind-protect code which can cause segfaults. (Segfaults on CMUCL/x86 are currently serious show stoppers because the signal handler trashes the control stack.) - Another (minor) problem are stale breakpoints. Breakpoints are sometimes not properly deleted and are still there if you execute the same function later. Helmut.