Suppose I have a function foo, which contains mathematical operations,
and I make a mistake in it somehow, and when called, it gives me the
following error:
Argument X is not a NUMBER: NIL
[Condition of type SIMPLE-TYPE-ERROR]
Restarts:
0: [ABORT] Return to SLIME's top level.
1: [TERMINATE-THREAD] Terminate this thread (#<THREAD
"worker" {DA13C01}>)
Backtrace:
0: (SB-KERNEL:TWO-ARG-- NIL 0.4176315789473684d0)
Locals:
SB-DEBUG::ARG-0 = NIL
SB-DEBUG::ARG-1 = 0.4176315789473684d0
1: (FOO
...
Now if there are many calls to - in foo, can SLIME help me find which
one of them caused the error? I guess the question, generally stated,
is: is it possible to quickly find out which call to a particular
function caused the error? Something like having the cursor jump
there would be handy.
Thanks,
Tamas
Den Mon, 10 Dec 2007 11:12:58 -0800 skrev Tamas:
> Now if there are many calls to - in foo, can SLIME help me find which
> one of them caused the error? I guess the question, generally stated,
> is: is it possible to quickly find out which call to a particular
> function caused the error? Something like having the cursor jump there
> would be handy.
Try pressing 'v' on the offending stack frame. Note that the availability
of the debug info depends on how the code was compiled, you might need to
DECLAIM/PROCLAIM (optimize debug) and recompile the code to get
meaningful results. There's also a stepper in SBCL which SLIME is able to
use if you break, except that I get extremely uneven results -- I've been
able to successfully use it maybe two or three times, the rest SLDB just
bails out with "no restart found, evaluation aborted".
Cheers,
Maciej
Tamas <······@gmail.com> writes:
> Now if there are many calls to - in foo, can SLIME help me find which
> one of them caused the error? I guess the question, generally stated,
> is: is it possible to quickly find out which call to a particular
> function caused the error? Something like having the cursor jump
> there would be handy.
Since your backtrace was from SBCL:
* Compile the code with (debug 2) or higher.
* Press "v" on the stack frame of FOO.
--
Juho Snellman
On Dec 10, 7:17 pm, Juho Snellman <······@iki.fi> wrote:
> Tamas <······@gmail.com> writes:
> > Now if there are many calls to - in foo, can SLIME help me find which
> > one of them caused the error? I guess the question, generally stated,
> > is: is it possible to quickly find out which call to a particular
> > function caused the error? Something like having the cursor jump
> > there would be handy.
>
> Since your backtrace was from SBCL:
>
> * Compile the code with (debug 2) or higher.
How do folks usually do this for all the code in a project? What
would be the easiest way to set (debug 3) globally (including
libraries and (sbcl) implementation)?
--Andy
On Dec 11, 2:41 pm, Andy Chambers <··············@googlemail.com>
wrote:
> On Dec 10, 7:17 pm, Juho Snellman <······@iki.fi> wrote:
>
> > Tamas <······@gmail.com> writes:
> > > Now if there are many calls to - in foo, can SLIME help me find which
> > > one of them caused the error? I guess the question, generally stated,
> > > is: is it possible to quickly find out which call to a particular
> > > function caused the error? Something like having the cursor jump
> > > there would be handy.
>
> > Since your backtrace was from SBCL:
>
> > * Compile the code with (debug 2) or higher.
>
> How do folks usually do this for all the code in a project? What
> would be the easiest way to set (debug 3) globally (including
> libraries and (sbcl) implementation)?
>
> --Andy
I think http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=binarytrees&lang=sbcl&id=2
gives an example (search on 'proclaim').
Andy Chambers <··············@googlemail.com> writes:
> On Dec 10, 7:17 pm, Juho Snellman <······@iki.fi> wrote:
> > Tamas <······@gmail.com> writes:
> > > Now if there are many calls to - in foo, can SLIME help me find which
> > > one of them caused the error? I guess the question, generally stated,
> > > is: is it possible to quickly find out which call to a particular
> > > function caused the error? Something like having the cursor jump
> > > there would be handy.
> >
> > Since your backtrace was from SBCL:
> >
> > * Compile the code with (debug 2) or higher.
>
> How do folks usually do this for all the code in a project? What
> would be the easiest way to set (debug 3) globally (including
> libraries and (sbcl) implementation)?
Depends on what you mean by global, I guess, but there are two main
choices:
1) (sb-ext:restrict-compiler-policy 'debug 3) at the repl -> All
further compiles will use a debug level of 3, no matter what
optimize declarations or declamations are used.
2) (declaim (optimize debug)) at the repl -> All further compiles
will use a debug level of 3, unless they're locally overridden
by declarations. If any files you compile contain declamations
that change he debug level, those changes will only be in effect
for that file.
Instead of the repl you could also put those lines in .sbclrc. In both
cases you will need to ensure that all relevant code is recompiled,
e.g. by removing any fasls or using :force t with asdf:load-op.
And of course neither of those would matter for SBCL itself, since it
was already compiled before you had any way of doing the above things.
Compiling SBCL itself with debug level 3 would be a bad idea. (debug
2) would probably not cause problems, besides bloating up the core
file by a factor of 2. That could probably be done by modifying
make-host-2.lisp and src/cold/warm.lisp.
--
Juho Snellman