In article <···························@uu-stuart-mac.open.ac.uk> ··········@open.ac.uk (Stuart Watt) writes:
-->
--> IMHO debugging in Lisp hasn't changed at all significantly since the Lisp
--> Machine days. There are at least two people who have looked at proper
--> source level debugging recently, and as I am one of them, I would really
--> like implementors to wake up on this.
rather than moan about things we can't change, how about telling us
about this--I'd certainly like to hear what you've done that's new and
different.
somewhere around here I have a small chunk of code written for Explorer
(and probably functional on symbolics also) that did an excellent job of
opening the call-stack when you were in the debugger and letting you get
at all sorts of things quite easily. unfortunately, I haven't used it
for 5 years, and don't know where it is--I don't even remember the name
of it now :(
it greatly improved one's ability to do "source-level-debugging"
-- clint
In article <··········@info-server.bbn.com>, Clint Hyde <·····@bbn.com> writes:
|> In article <···························@uu-stuart-mac.open.ac.uk> ··········@open.ac.uk (Stuart Watt) writes:
|>
|> -->
|> --> IMHO debugging in Lisp hasn't changed at all significantly since the Lisp
|> --> Machine days. There are at least two people who have looked at proper
|> --> source level debugging recently, and as I am one of them, I would really
|> --> like implementors to wake up on this.
|>
|> rather than moan about things we can't change, how about telling us
|> about this--I'd certainly like to hear what you've done that's new and
|> different.
I developed a source-level stepper that displayed Lisp source in a window,
and let you trace/step through it, highlighting the pending forms, and
showing return values. All forms and values were mouse sensitive, you
could mouse a section a function call form and click to turn on tracing,
or have it conditionally stop when that form was called or returned from.
It was quite slick and powerful. It was limited to interpreted code,
but you could VTRACE a compiled function if it could find the source code
for it, calling the compiled version when tracing was off (conditionally too).
Macros are a problem for tracing Lisp source, because the source form
isn't what gets executed. You have the same issue in C using #define's,
but unlike C, I COULD trace any subforms of a CL macro that actually were
executed, so a (with-open-file (stream ...) (read-line stream ...) ..)
the read-line would get stepped through. You can optional expand macros too,
or write a corresponding "visual macro" that could vtrace subforms.
(unfortunately, VTRACE is held hostage by the equivalent of the Serbs, so
don't ask if you can use it)
While it was very useful in some situations -- I thought it was perfect
for beginners, as well as trying to understand someone else's code ---
Lisp isn't like C, where you
have to compile and run the whole program before debugging smaller pieces.
Lisp tends to have smaller functions that are easier to understand and fix,
and are usually much more side-effect-free and thus can be debugged
without running in a specific context.
So the need for such fancy source-level debugging is much less.
-Kelly Murray (···@franz.com) <a href="http://www.franz.com"> Franz Inc. </a>
"Those who can see the invisible can do the impossible" - Carl Mays