So, I decided to try to tackle this. As I've said before, I don't want
to push the responsibility for frame cleaning to Slime -- setting
options yes, but actually doing the cleaning should be done by SBCL.
Without getting into implementation details right now, here's my
proposal for a brave new SB-DEBUG:BACKTRACE interface. I think
FRAME-CALL-AS-LIST and PRINT-FRAME-CALL should have similar toggles.
(defun backtrace (&key
"Print a listing of the call stack to STREAM, going down from the current
frame. In the debugger, the current frame is indicated by the prompt.
COUNT is the number of frames to print (defaulting to *BACKTRACE-FRAME-COUNT*,
initially MOST-POSITIVE-FIXNUM), and SKIP is the number of frames to skip
before starting to print (defaulting to zero).
If PRINT-THREAD is true (the default), the backtrace is preceded by printing
the current thread object.
If PRINT-FRAME-SOURCE is true (the default is false), each frame is followed
by printing the source responsible for it, when available.
METHOD-FRAME-STYLE (defaulting to *METHOD-FRAME-STYLE*, initially :NORMAL),
determines how frames corresponding SBCL generated method functions are printed.
Possible values are :MINIMAL, :NORMAL, and :FULL.
:MINIMAL prints them as
:NORMAL prints them as
((<NAME> [<QUALIFIER>] (<SPECIALIZER>*)) ...args...)
:FULL prints them using the exact method function name:
((SB-PCL:FAST-METHOD <NAME> [<QUALIFIER>] (<SPECIALIZER>*)) ...args...)
((SB-PCL:SLOW-METHOD <NAME> [<QUALIFIER>] (<SPECIALIZER>*)) ...args...)
If SHOW-ENTRY-POINT-DETAILS is true (defaulting to *SHOW-ENTRY-POINT-DETAILS*,
initially false), each frame is printed with entry point details. This is
mostly of interest to SBCL developers, but in case you are seeing
2: (FOO 42)
3: (FOO 42)
turning on entry point details can assure you that FOO is not actually being
called twice, but you are eg. seeing both the external and normal entry points
in the backtrace.
As a point of order, let's please not focus on the exact names of the
arguments (should it be :PRINT-ENTRY-POINT-DETAILS instead, etc.), but
rather on the meaning of the toggles themselves and their defaults.
Names can be hashed over after we have something resembling a
I'm particularly interested in hearing from the two extremes here --
those wanting to have the full method function names, and those
preferring the minimal version.
Is the interface bad? What should change?
Is it good, but defaults are wrong?
Is it perfect?