Hi all,
I'm using CLISP. When loading a compiled file, the debug information
is not available, i.e., no stack trace information. In order to debug
I need to load the .lisp file. Why is that?
Besides, I find the fact that there are no line numbers in the debug
information quite annoying, (although the place of the problem can be
pin-pointed by the stack trace). Is there a solution for that?
Thanks
iu2
iu2 <·······@elbit.co.il> writes:
> I'm using CLISP. When loading a compiled file, the debug information
> is not available, i.e., no stack trace information. In order to debug
> I need to load the .lisp file. Why is that?
Because a compilation is a speed optimization, not a debug
optimization (at least for clisp).
That's the way it is, if you want to debug with clisp, don't compile.
> Besides, I find the fact that there are no line numbers in the debug
> information quite annoying, (although the place of the problem can be
> pin-pointed by the stack trace). Is there a solution for that?
Not really. The problem is that lisp sources are not text files, they
are symbolic expressions.
One could imagine keeping track of an association between a
line/column and lisp tokens (symbols, literals, conses, etc) making
the sexps, but since these sexps can be manipulated in any way at read
time and at macroexpansion time (and some of them even generated from
thin air then), it would hardly be meaningful anyways.
Let's take a simple example:
(macroexpand '(loop for i from 1 to 10 do (print i)))
(MACROLET ((LOOP-FINISH NIL (SYSTEM::LOOP-FINISH-ERROR)))
(BLOCK NIL
(LET ((I 1))
;;; ^ ^
(PROGN
(LET NIL
(MACROLET ((LOOP-FINISH NIL '(GO SYSTEM::END-LOOP)))
(TAGBODY SYSTEM::BEGIN-LOOP (WHEN (> I 10) (LOOP-FINISH))
;;; ^ ^^
(PROGN (PROGN (PRINT I))) (PSETQ I (+ I 1)) (GO SYSTEM::BEGIN-LOOP)
;; ^^^^^^^^^ ^ ^
SYSTEM::END-LOOP (MACROLET ((LOOP-FINISH NIL (SYSTEM::LOOP-FINISH-WARN)
'(GO SYSTEM::END-LOOP))))))))))) ;
T
For the sexp eventually compiled, only a few tokens (underlined with
^^^) come from the user "source". The rest comes from the "source" of
the loop macro. What's more, all the I's come from the same "source"
position.
--
__Pascal Bourguignon__ http://www.informatimago.com/
COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
protons, etc.) comprising this product are exactly the same in every
measurable respect as those used in the products of other
manufacturers, and no claim to the contrary may legitimately be
expressed or implied.
Pascal Bourguignon <···@informatimago.com> wrote:
+---------------
| iu2 <·······@elbit.co.il> writes:
| > Besides, I find the fact that there are no line numbers in the debug
| > information quite annoying, (although the place of the problem can be
| > pin-pointed by the stack trace). Is there a solution for that?
|
| Not really. The problem is that lisp sources are not text files, they
| are symbolic expressions.
|
| One could imagine keeping track of an association between a
| line/column and lisp tokens (symbols, literals, conses, etc) making
| the sexps, but since these sexps can be manipulated in any way at read
| time and at macroexpansion time (and some of them even generated from
| thin air then), it would hardly be meaningful anyways.
+---------------
Actually, the PLT Scheme guys did a pretty good job with their
Zodiac[1] source-correlating reader & macro-expander, used in the
MrSpidey debugger front-end [now merged into DrScheme, IIUIC],
which replaced the normal Scheme reader with a "Scheme DOM reader"
[to coin a phrase] which read s-exprs and annotated each node
with file/line/charpos [and other info]. Then the evaluation
pre-pass did further annotation, e.g., putting in back-links
from lexical variable uses to their binding points, which the
IDE [in DrScheme] could display with cute little arrows.[2]
It would certainly be *possible* for a CL implementation to do
something like that as well, but AFAIK none do. They just use
the normal READ defined in the CLHS.
-Rob
[1] Shriram Krishnamurthi, "Zodiac: A Framework for Building
Interactive Programming Tools. Tech. Rep. 95-262, Rice Univ.,
Houston, TX, USA, 1995.
[2] For some pictures of how this looks in action, see
<http://www.soe.ucsc.edu/~cormac/papers/mrspidey.pdf>
"PLT MrSpidey: Static Debugger Manual".
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
In article <································@speakeasy.net>,
····@rpw3.org (Rob Warnock) wrote:
> Pascal Bourguignon <···@informatimago.com> wrote:
> +---------------
> | iu2 <·······@elbit.co.il> writes:
> | > Besides, I find the fact that there are no line numbers in the debug
> | > information quite annoying, (although the place of the problem can be
> | > pin-pointed by the stack trace). Is there a solution for that?
> |
> | Not really. The problem is that lisp sources are not text files, they
> | are symbolic expressions.
> |
> | One could imagine keeping track of an association between a
> | line/column and lisp tokens (symbols, literals, conses, etc) making
> | the sexps, but since these sexps can be manipulated in any way at read
> | time and at macroexpansion time (and some of them even generated from
> | thin air then), it would hardly be meaningful anyways.
> +---------------
>
> Actually, the PLT Scheme guys did a pretty good job with their
> Zodiac[1] source-correlating reader & macro-expander, used in the
> MrSpidey debugger front-end [now merged into DrScheme, IIUIC],
> which replaced the normal Scheme reader with a "Scheme DOM reader"
> [to coin a phrase] which read s-exprs and annotated each node
> with file/line/charpos [and other info]. Then the evaluation
> pre-pass did further annotation, e.g., putting in back-links
> from lexical variable uses to their binding points, which the
> IDE [in DrScheme] could display with cute little arrows.[2]
>
> It would certainly be *possible* for a CL implementation to do
> something like that as well, but AFAIK none do. They just use
> the normal READ defined in the CLHS.
LispWorks can locate the source form for an error.
Set DEBUG to a high value. Type :ed in the debugger.
It will highlight the current subform in the editor.
In Symbolics Genera you can compile code with source
locators (C-M-Sh-c in Zmacs). The debugger will then
show mouse sensitive source code...
>
>
> -Rob
>
> [1] Shriram Krishnamurthi, "Zodiac: A Framework for Building
> Interactive Programming Tools. Tech. Rep. 95-262, Rice Univ.,
> Houston, TX, USA, 1995.
>
> [2] For some pictures of how this looks in action, see
> <http://www.soe.ucsc.edu/~cormac/papers/mrspidey.pdf>
> "PLT MrSpidey: Static Debugger Manual".
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
--
http://lispm.dyndns.org
Rainer Joswig <······@lisp.de> wrote:
> LispWorks can locate the source form for an error.
> Set DEBUG to a high value. Type :ed in the debugger.
> It will highlight the current subform in the editor.
As can cmucl and sbcl with Slime (press "v" on a frame in sldb).
--
Juho Snellman
····@rpw3.org (Rob Warnock) writes:
> Pascal Bourguignon <···@informatimago.com> wrote:
> +---------------
> | iu2 <·······@elbit.co.il> writes:
> | > Besides, I find the fact that there are no line numbers in the debug
> | > information quite annoying, (although the place of the problem can be
> | > pin-pointed by the stack trace). Is there a solution for that?
> |
> | Not really. The problem is that lisp sources are not text files, they
> | are symbolic expressions.
> |
> | One could imagine keeping track of an association between a
> | line/column and lisp tokens (symbols, literals, conses, etc) making
> | the sexps, but since these sexps can be manipulated in any way at read
> | time and at macroexpansion time (and some of them even generated from
> | thin air then), it would hardly be meaningful anyways.
> +---------------
>
> Actually, the PLT Scheme guys did a pretty good job with their
> Zodiac[1] source-correlating reader & macro-expander, used in the
> MrSpidey debugger front-end [now merged into DrScheme, IIUIC],
> which replaced the normal Scheme reader with a "Scheme DOM reader"
> [to coin a phrase] which read s-exprs and annotated each node
> with file/line/charpos [and other info]. Then the evaluation
> pre-pass did further annotation, e.g., putting in back-links
> from lexical variable uses to their binding points, which the
> IDE [in DrScheme] could display with cute little arrows.[2]
>
> It would certainly be *possible* for a CL implementation to do
> something like that as well, but AFAIK none do. They just use
> the normal READ defined in the CLHS.
Indeed. Here is already a lisp reader that could be used to do that:
http://darcs.test.informatimago.com/lisp/common-lisp/reader.lisp
http://darcs.test.informatimago.com/lisp/common-lisp/source-text.lisp
(Each source object keeps track of the file position it has been read
from). There remains to write an evaluator...
> [1] Shriram Krishnamurthi, "Zodiac: A Framework for Building
> Interactive Programming Tools. Tech. Rep. 95-262, Rice Univ.,
> Houston, TX, USA, 1995.
>
> [2] For some pictures of how this looks in action, see
> <http://www.soe.ucsc.edu/~cormac/papers/mrspidey.pdf>
> "PLT MrSpidey: Static Debugger Manual".
--
__Pascal Bourguignon__ http://www.informatimago.com/
COMPONENT EQUIVALENCY NOTICE: The subatomic particles (electrons,
protons, etc.) comprising this product are exactly the same in every
measurable respect as those used in the products of other
manufacturers, and no claim to the contrary may legitimately be
expressed or implied.