So far I never needed it, but now the a real debugger would help a lot
(in this specific case I'm having a divide by zero somewhere, but the
stack-trace isn't really helpful as it doesn't tell me at all in which
LINE or expression it happens; it's more than just one or two
divisions). Another problem is that SLIME doesn't seem to display my
function's parameters, nor all of the locals (I have a LET* in this
particular case, and it only shows part of them, leaving some others
more or less at random).
Software is Aquamacs/SLIME 1.2.1/OpenMCL (0.something).
How do I get SLDB to show ALL variables, or -- even better -- a single
stepper with breakpoints (does such a thing exist in SLIME)?
--
If you have to ask what jazz is, you'll never know.
Louis Armstrong
Ulrich Hobelmann wrote:
> So far I never needed it, but now the a real debugger would help a lot
> (in this specific case I'm having a divide by zero somewhere, but the
> stack-trace isn't really helpful as it doesn't tell me at all in which
> LINE or expression it happens; it's more than just one or two
> divisions). Another problem is that SLIME doesn't seem to display my
> function's parameters, nor all of the locals (I have a LET* in this
> particular case, and it only shows part of them, leaving some others
> more or less at random).
>
> Software is Aquamacs/SLIME 1.2.1/OpenMCL (0.something).
>
> How do I get SLDB to show ALL variables, or -- even better -- a single
> stepper with breakpoints (does such a thing exist in SLIME)?
>
Pressing "v" on the line of the stacktrace shows the corresponding code
location. You will at least see the function in which the stracktrace
was triggered (which with small functions may be sufficient), but
getting a more exact location depends on your lisp and debug settings.
So setting an (optimize (debug 3)) will help there and add more
variables to the locals list, as they do not get optimized away.
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
> Pressing "v" on the line of the stacktrace shows the corresponding code
> location. You will at least see the function in which the stracktrace
> was triggered (which with small functions may be sufficient), but
> getting a more exact location depends on your lisp and debug settings.
> So setting an (optimize (debug 3)) will help there and add more
> variables to the locals list, as they do not get optimized away.
>
> Peter
>
Thanks Ulrich for the question and thank you Peter for the answer -
I've been wondering about this for a while.
Related Slime question. How do you get the cross-reference tools like
who-calls to work? Whenever I try them I just get errors like the
following:
There is no applicable method for the generic function
#<STANDARD-GENERIC-FUNCTION SWANK-BACKEND:WHO-CALLS (0)>
"Blaine" <·············@hotmail.com> writes:
> Related Slime question. How do you get the cross-reference tools like
> who-calls to work? Whenever I try them I just get errors like the
> following:
>
> There is no applicable method for the generic function
> #<STANDARD-GENERIC-FUNCTION SWANK-BACKEND:WHO-CALLS (0)>
You implement them for your CL implementations backend.
',mr
--
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
Peter Herth wrote:
> Pressing "v" on the line of the stacktrace shows the corresponding code
> location. You will at least see the function in which the stracktrace
> was triggered (which with small functions may be sufficient), but
> getting a more exact location depends on your lisp and debug settings.
> So setting an (optimize (debug 3)) will help there and add more
> variables to the locals list, as they do not get optimized away.
Thanks, the optimize setting was what was needed to get all those
parameters to show up.
--
If you have to ask what jazz is, you'll never know.
Louis Armstrong