I am gonna forward this question over to the people at franz, but I'm
you guys might also know...
I have found the Emacs Lisp debugger to be phenomenal. Elisp is a bit
simpler than Common Lisp, but the interface is ideal for debugging,
and I havn't figured out how to step through source code,
expression-by-expression, in ACL yet, the way you can with edebug (and
M-x gdb in (X)Emacs). Is there a way?
Specifically, I'd like to step through, by pressing some key
(e.g. spacebar), and I'd like to, at any time, evaluate the value of
a variable in the current scope.
dave
* David Bakhash
| I am gonna forward this question over to the people at franz, but I'm
| you guys might also know...
have you read the chapter on Debugging in the User Guide? (in case you
hadn't noticed, it is distributed with the binaries as a PDF file, and a
Acrobat PDF reader for Linux is included. see the doc/ directory.)
#:Erik
--
"Where do you want to go to jail today?"
-- U.S. Department of Justice Windows 98 slogan
David Bakhash <·····@bu.edu> writes:
< Specifically, I'd like to step through, by pressing some key
< (e.g. spacebar), and I'd like to, at any time, evaluate the value of
< a variable in the current scope.
I don't know if you'll find this helpful but...
You can step a form by typing `:step form' at the toplevel. You can
get documentation on any top-level-alias (the :commands) with `:help
alias-name', and a list of built-in aliases with just :help.
A few that may be worth checking out are step, local, set-local, pop,
res, ld, and cload. I imagine that most of these functions are in any
lisp environment - some may even be required (like trace and load).
The :syntax is just faster to type.
I think it might be real difficult to bind the spacebar to continue
stepping, as there is no way to read a single character under the unix
programs. You may however, be able to bind step to space followed by a
newline (but newline is the default so this is somewhat senseless); of
course, you could always play stty games.
There is some source code in the misc/dot-clinit.cl and
src/autozoom.cl files that may help demonstrate how you can customize
the top-level a bit. Also in the acl 4.3 manual there was a section on
how to play with the aliases - I imagine that most of the information
still applies to the newer acl.
You can also change the `:' character to something else, but I can't
think of the variable's name right now. Also some of these aliases can
be called as functions, like (trace ...), etc. Hope this helps some...
Steve Gonedes (········@worldnet.att.net) wrote:
: David Bakhash <·····@bu.edu> writes:
: < Specifically, I'd like to step through, by pressing some key
: < (e.g. spacebar), and I'd like to, at any time, evaluate the value of
: < a variable in the current scope.
: I don't know if you'll find this helpful but...
: You can step a form by typing `:step form' at the toplevel. You can
: get documentation on any top-level-alias (the :commands) with `:help
: alias-name', and a list of built-in aliases with just :help.
I guess David Bakhash is not asking for command line stepping. But
rather he is asking (I think he is asking) for SOURCE-LEVEL stpping.
I asked exactly the same question few months back. But there does not
seem to be any CL that does this. Many CL hackers are happy
with command line stepping. But I really wanted source-level
stepping somehting similar to GUD-MODE in Emacs with GCC.
May be Franz is working on it. Somebody from Franz (Kelly Murray?),
posted on this group some time back which hinted that they may be
doing it for their next version. May be one day we will have something
like this in ACL. At one point, I was thinking of hacking one for myself.
May be I will do once I get my thesis out of my way.
Srini
In article <··············@mute.eaglets.com>,
Sam Steingold <···@usa.net> wrote:
>>>>> In message <············@tribune.usask.ca>
>>>>> Sent on 2 Jun 1998 16:34:39 GMT
>>>>> Honorable ·····@skorpio3.usask.ca (P. Srinivas) writes
>>>>> on the subject of "Re: ACL debugging":
....
> >> seem to be any CL that does this. Many CL hackers are happy
> >> with command line stepping. But I really wanted source-level
> >> stepping somehting similar to GUD-MODE in Emacs with GCC.
>
>I think CLISP does what you want.
>
>[COMMON-LISP-USER]> (step (let ((zz 10)) (incf zz)))
I think this is what is refered to above as command line stepping.
You are given a command line for the stepper and you enter commands.
The source-level stepping is more akin to the classic MacPascal (and others
before and since) where the "fickle finger of truth" points in the source
code window at the current line that is about to be executed/evaluated.
Similar to the GDB mode in Emacs for C and other languages:
==> (let ((zz 10)) (incf zz) (print zz))
Something like the above.
This has much more to do with the Editor that comes with the environment
(or used in conjunction with the environment) than of "Common Lisp" per
se. Since STEP is required by the language, seemingly many vendors provide
only and most users make use of this "lowest common denominator"
functionality.
However, unlike C/Pascal and Lisp source can be often organized to
in such a way where the "interesting" computations aren't sepereated
out into different lines. Such as the example above. Roughly the C
equivalent is
{ int zz=10 ;
zz++ ;
printf ("~%d\n" zz);
}
Although, it too could be written in a "horizontal fashion". However
when stepping through the more "horizontal" lisp example above, the
"indicator" isn't going to move as you step. You can do some stuff with
highlighting text.
That said in some sense since the source code is propabably present somewhere
on the programmer's screen... you get more screen real estate "resuse" out
of not redisplaying the source code over again in the Listener window...
[ Another "problem" that C/Pascal don't have is the heavy utilization of
macros. Even if you don't extensively use macros yourself you can use
standard CL macros. Source debugging code that has been heavily
"transformed" from the "raw" version present in the editor window can
also be a bear to do correctly. It probably means recording/tracking
line numbers through a number of transformations back the to original
source... Similar to the problems with source debugging heavily
optimized code. ]
--
Lyman S. Taylor "I'm a Doctor! Not a doorstop... "
(·····@cc.gatech.edu) The EMH Doctor in "Star Trek: First Contact".
One difficulty with providing source-level editor-based stepping in Common Lisp
in contrast to C is that Common Lisp provides macros that can do arbitrary
(potentially non-local) code rewrites that may be difficult or impossible for
the stepper to undo. Try running a command-line stepper on code that uses
LOOP, Series, Iterate, PCL, LM-Prolog, Joshua, Screamer, or one of the many
expert system shells written as macrology on top of Common Lisp and you will
see why.
Jeff (http://www.neci.nj.nec.com/homepages/qobi)
Jeffrey Mark Siskind (····@research.nj.nec.com) wrote:
: One difficulty with providing source-level editor-based stepping in Common Lisp
: in contrast to C is that Common Lisp provides macros that can do arbitrary
: (potentially non-local) code rewrites that may be difficult or impossible for
: the stepper to undo. Try running a command-line stepper on code that uses
: LOOP, Series, Iterate, PCL, LM-Prolog, Joshua, Screamer, or one of the many
: expert system shells written as macrology on top of Common Lisp and you will
: see why.
This is indeed a real problem. But Common LISP is introspective
and you have all the power of the language at hand during the run time
as opposed to C debuggers such as GDB etc. So it is not hard to
keep the macro expander at hand and compute the source-level
FROM that has the current form being evaluated. Infact one can
also have option of showing expanded macro at teh source level to
see the exact form.
Even if we do not handle the full blown macro, we can gain
a lot LISP, if we can get a stepper for a subset of CL.
Srini
--------------------
Srinivas Palthepu Email: ·····@cs.usask.ca
ARIES laboratory, Phones: (306) 966-8654 (lab)
Department of Computer Science, (306) 966-4759 (office)
University of Saskatchewan, (306) 373-6724 (home)
57 Campus Dr, Saskatoon, SK, S7N 5A9 Fax: (306) 966-4884
But Common LISP is introspective
> and you have all the power of the language at hand during the run time
> as opposed to C debuggers such as GDB etc. So it is not hard to
> keep the macro expander at hand and compute the source-level
> FROM that has the current form being evaluated.
No, this is not possible. A macro translates the written expression to the
expression that the evaulator sees. At step time you need to do the reverse
translation. Since the translator can be an arbitrary computable function in
Common Lisp this is not easy to do. Worse, it might not even be a function
since it can depend on global state. Having the macro expander at hand doesn't
help you. And even if you could tell that some written expression S1 was
transformed into some evaluated expression S2, when the stepper hits some
subexpression of S2, you couldn't easily tell which subexpression in S1 that
came from. There might not even be a corresponding subexpression in S1 because
the code in S2 might be *generated* by a global analysis of the code in S1
(as happens say with a macro that does partial evaluation; see the partial
evaluator for Common Lisp, available from my Web page, for an example). Or
worse, the code in S1 might not even be Common Lisp. Macros can be used to
implement compilers from non-CommonLisp source languages to CommonLisp
target-languages. See LM-Prolog, Joshua, ConLog, or Pseudo-Scheme for examples.
The notion of a stepper presupposes a very restricted Vonneumann model of
computation. Some langauges, particularly ones that are more declarative and
less imperative, are better viewed with different models. For example
rewrite systems or theorem proving. In such models, there is no notion of
`program counter' or `the current program point'. And C-like steppers don't
make sense for such models. While a subset of Common Lisp can be viewed in an
imperative model, the language as a whole, particularly when macros are used,
transcends that.
Jeff (http://www.neci.nj.nec.com/homepages/qobi)
Jeffrey Mark Siskind <····@research.nj.nec.com> writes:
> No, this is not possible. A macro translates the written expression to the
> expression that the evaulator sees. At step time you need to do the reverse
> translation.
Actually, if your macro can be made to expand into special identities that
mark "client code" separate from "macro implementation code", you don't.
e.g., if:
(let ((x 3)) (+ x 4))
expands into
(dont-step ((lambda (x) (step (+ x 4))) (step 3)))
[Of course, then you have to trust the macro.]
> > No, this is not possible. A macro translates the written expression to the
> > expression that the evaulator sees. At step time you need to do the reverse
> > translation.
>
> Actually, if your macro can be made to expand into special identities that
> mark "client code" separate from "macro implementation code", you don't.
> e.g., if:
> (let ((x 3)) (+ x 4))
> expands into
> (dont-step ((lambda (x) (step (+ x 4))) (step 3)))
This only works if there is a clear distinction between client code and macro
implementation code. And the client code passes through the macro unmodified.
This won't work with macros that do massive code walking. Like PCL, my partial
evaluator for Common Lisp, or Screamer. In something like Screamer, someone
can write something as innocent-looking as (+ (f x y) (g u v)). And if F or G
happens to be nondeterministic, the expanded code is CPS-converted and looks
nothing at all like this. Even though (except for the backtracking aspect
which necessitates the CPS-conversion) the semantics of the code is unmodified.
This confuses the hell out of people who try to step or trace Screamer
programs, or even just use the debugger.
> [Of course, then you have to trust the macro.]
The problem of trusting macros occurs not just in stepping but also in error
reporting. People from the C world are accoustomed to having the compiler
and/or run time system report errors in terms of the precise line and/or
character position in the source file where the error occured. This, too, is
difficult in the presence of macros. And few Lisp implementations do this.
When I teach Lisp or Scheme to students who have been brought up on Turbo C
this is the thing that they find most disturbing. And I must admit, I see
their point. So when I built Stalin, I built a reader that preserved line and
character positions. Essentially the reader encapsulates all s-expressions
as pseudo s-expressions with augmented file positions. Both the compiler and
the run-time system use this information to report errors. (Potentially, it
can also be used for stepping and tracing but this is not done yet.)
But there is a cost. Because now, macros don't manipulate s-expressions. They
manipulate encapsulated s-expressions. Thus they must be written using
sx-car, sx-cdr, sx-cons, sx-list, sx-length, sx-map, ... instead of car, cdr,
cons, list, length, map, ... This has the obvious disadvantages. It also has
some nonobvious disadvantages. Like the fact that while for pairs
(cons (car x) (cdr x))=x, (sx-cons (sx-car x) (sx-cdr x))/=x. Because x
preserves file-position information that (sx-cons (sx-car x) (sx-cdr x)) loses.
So in the interest of providing maximal position information, the macro writer
must take care to use existing list structure when possible, rather than
recreating identical list structure. And this adds undesirable complication to
some macros.
Jeff (http://www.neci.nj.nec.com/homepages/qobi)
Jeffrey Mark Siskind <····@research.nj.nec.com> writes:
[of source-level debugging]
> When I teach Lisp or Scheme to students who have been brought up on Turbo C
> this is the thing that they find most disturbing. And I must admit, I see
> their point.
Some years back I was in a similar situation, which inspired me to
write PSD, the portable Scheme debugger. PSD uses Emacs to quietly
transform a procedure into an instrumented version that behaves as if
run under a conventional debugger such as gdb. More information at
http://www.cs.tut.fi/~pk/papers.html.
PSD works fine for the kind of code I write, but fails miserably if
macros are used. This may contribute to my feelings about macros and
higher level procedures discussed over at comp.lang.scheme.
Something similar should be fairly easy (although laborious) to write
for the macro-free subset of Common Lisp.
--
pertti
Jeffrey Mark Siskind <····@research.nj.nec.com> writes:
>No, this is not possible. A macro translates the written expression to the
>expression that the evaulator sees. At step time you need to do the reverse
>translation. Since the translator can be an arbitrary computable function in
>Common Lisp this is not easy to do. Worse, it might not even be a function
Clearly it's not practical to determine exactly what source generated
an arbitrary expression, but wouldn't it be fairly straightforward
most of the time?
For example, in the following piece of code:
(dotime (i 10)
(do-something i))
I'd (perhaps naively) expect the (do-something i) to pass through the
macro-expander unchanged and to be eq to the version that was
originally read.
In cases where it isn't possible to trace the origin of an expression,
it seems reasonable for the debugger to drop back to the ordinary
stepper or something similar. After all, even in C, the mapping from
machine code back to source is often pretty approximate in the
prescence of macros, but it's still better than nothing, IMHO.
I'm pretty sure that the new version of gambit-c has source-level
debugging and macros, though I haven't had the chance to play around
with it.
-- Matthew McDonald <····@cs.uwa.edu.au>
* Jeffrey Mark Siskind
| One difficulty with providing source-level editor-based stepping in
| Common Lisp in contrast to C is that Common Lisp provides macros that can
| do arbitrary (potentially non-local) code rewrites that may be difficult
| or impossible for the stepper to undo. Try running a command-line
| stepper on code that uses LOOP, Series, Iterate, PCL, LM-Prolog, Joshua,
| Screamer, or one of the many expert system shells written as macrology on
| top of Common Lisp and you will see why.
I wonder if I'm missing something, but all the Common Lisp steppers I
have used have been source-level steppers in the trivial sense -- they
could not step through compiled code in the first place -- all they could
do was to step source-level forms. macro functions were called to return
a new form to step through -- never saw a macro expansion function that
returned compiled code, either, so the macro form would be eminently
"undoable" in the sense that you already know what it was to begin with.
I'm not sure I _want_ to step through compiled code, either -- it isn't
the compiler that I'm debugging. I'm usually quite happy to step through
the macro expansions, though, since I'm debugging macro expansions that
interact in weird ways more often than I'm debugging "straight" code.
not that I wouldn't like a more "visual" interface that highlighted the
expression under stepping and replaced sub-forms with their values,
including macro expansiosn, but this should a be a lot easier to write
than a source-level stepper or debugger that worked with compiled code
and debug information.
I still wonder if I have missed something really obvious, again.
#:Erik
--
"Where do you want to go to jail today?"
-- U.S. Department of Justice Windows 98 slogan
Erik Naggum (··@naggum.no) wrote:
: I wonder if I'm missing something, but all the Common Lisp steppers I
: have used have been source-level steppers in the trivial sense -- they
: could not step through compiled code in the first place -- all they could
: do was to step source-level forms. macro functions were called to return
: a new form to step through -- never saw a macro expansion function that
: returned compiled code, either, so the macro form would be eminently
: "undoable" in the sense that you already know what it was to begin with.
The issue here is not stepping interpreted code vs stepping compiled code.
It is probably better not try to step through compiled code.
The issue here is *command line* stepping Vs *source level* stepping.
In other words, the original poster (I think) was asking for is
something similar to GCC/GDB in Emacs. For example, one can have
an overlay arrow point to the current form being evaluated
*in the same buffer* for the source code file for the function,
and let me stepp through by some keystroke (or a mouse click).
One can also have the current form being highlighet with
a different colour or font, which is better than a simple arrow.
I should be abel to point to any variable/symbol and query for its value
at any time. In short we want something like what C/Pascal debuggers offer.
Stepping through macros is a problem as somebody pointer out.
Srini
--------------------
Srinivas Palthepu Email: ·····@cs.usask.ca
ARIES laboratory, Phones: (306) 966-8654 (lab)
Department of Computer Science, (306) 966-4759 (office)
University of Saskatchewan, (306) 373-6724 (home)
57 Campus Dr, Saskatoon, SK, S7N 5A9 Fax: (306) 966-4884
·····@sparkle.usask.ca (P. Srinivas) writes:
> Erik Naggum (··@naggum.no) wrote:
> : I wonder if I'm missing something, but all the Common Lisp steppers I
>
> The issue here is not stepping interpreted code vs stepping compiled code.
> It is probably better not try to step through compiled code.
> The issue here is *command line* stepping Vs *source level* stepping.
> In other words, the original poster (I think) was asking for is
> something similar to GCC/GDB in Emacs. For example, one can have
Yes. this is *exactly* what I was referring to. Specifically,
something such as edebug. GDB as well, though I think that edebug is
better, given all the other elisp facilities built into emacs
(i.e. such as `find-function', etc.)
I dislike the command-line stuff, as it's obviously nothing compared
to source-level debugging.
dave
I've mentioned to Franz that I feel their STEP support is at least 15 years out
of date.
Stepping in ACL5 doesn't have any GUI support
(in the pre-beta). Even ACLPC had a stepper I where I could point and click
into and over foms. So the interactive development environment for lisp
stepping is identical
to the emacs mode in ACL5.
It may be powerful, but I find it painful to use.
If I load interpreted code, I end up stepping into so many transformations
and stuff which has no obvious relationship to my code that it's easy to get
lost. For instance, stepping through a CLOS method dispatch is rediculous,
and wandering into macro expansion logic is usually annoying.
If I step over code which is calling largely compiled functions, then I have
something closer to source-level stepping from a user perspective, but I can't
decide dynamically when I want to step into the compiled form. Well, maybe I
can, if I want to constantly reload compiled/interpreted code during stepping,
and *if* the stepper picks up the effects. I find the ACL stepper extremely
fussy, such that it often (silently) ignores requests for stepping even when the
code is loaded interpreted.
I guess the point I really wanted to make (rather than rant and "me too" my way
through this post), is that I like lisp, but I need to sell lisp internally to
my peers. I shudder to think of trying to show a Visual C++ developer how
they'll have to step through lisp code. It will not be a positive experience.
I hope the lisp vendors still around will bring the IDE's into the 90's with
respect to stepping. Maybe Harlequin is already there, I haven't used it.
Dave Tenny
Dave Tenny
············@games.ultranet.com - no spam please
············@ma.ultranet.com wrote:
: I guess the point I really wanted to make (rather than rant and "me too"
: my way through this post), is that I like lisp, but I need to sell lisp
: internally to my peers. I shudder to think of trying to show a Visual
: C++ developer how they'll have to step through lisp code. It will not
: be a positive experience. I hope the lisp vendors still around will
: bring the IDE's into the 90's with respect to stepping. Maybe Harlequin
: is already there, I haven't used it.
I agree that it's going to be a hard sell for typical developers, but
it's interesting that for me, better debugging is a significant part
of the reason I'm using Lisp instead of C++ for my current project.
(And this is true even though I'm using CMUCL, not ACL, and I was
happy with even the pre-Christmas version which had significantly
worse debugging support than the current version, which in turn has, I
think, worse debugging support than ACL.)
For me, the worst part of debugging under VC++ (I forget the versions,
maybe 4.2 and 5.0? whatever versions were current last year..) was
the way that it presents class objects as raw data, so that it's
tedious and error-prone to find out what's in a collection class or
what a smart pointer refers to. This got old very, very fast. In my
coding and testing, I spend most of my time at a level where most
statements manipulate relatively abstract objects, and I'm not amused
by a debugger which makes me inspect them byte by byte instead of just
letting them display themselves.
The second worst part was the lack of an interpreter. The third worst
part was the inability to redefine a function on the fly and then try
again.
It's probably not so bad if most of your programming works directly
with things which are represented directly as machine words or arrays
of machine words. But my code last year worked with trees and STL
collections, and my code this year has all sorts of weird trees and
graphs.
(Better single-stepping and variable inspection would still be nice.)
Bill Newman
············@ma.ultranet.com writes:
> I guess the point I really wanted to make (rather than rant and "me
> too" my way through this post), is that I like lisp, but I need to
> sell lisp internally to my peers. I shudder to think of trying to show
> a Visual C++ developer how they'll have to step through lisp code. It
> will not be a positive experience. I hope the lisp vendors still
> around will bring the IDE's into the 90's with respect to stepping.
> Maybe Harlequin is already there, I haven't used it.
Just to throw a wrench into the works, I certainly agree that STEP is
far from what someone whose played with VC++ and its ilk is used to.
One question I have, though, is whether the LispMs had a similiar
facility to what most programmers are used dealing with today in terms
of debuggers.
On the crass assumption that they didn't, because of all of the
difficulties mentioned before, then despite how desirable they may be,
perhaps the folks using them had not felt that such a facility was
that important.
I'm guessing that because the development paradigm is so much
different, that steppers aren't as vital as they are for a language
such as C.
In C, you've got your whole program. For debugging, you lay out a mine
field of break points and what have you, and then throw the entire
program at it to see what sticks. How many times do we just stick a
break point at the top of one specific function, just so we can see
that the function works? You run make(1) on your 10,000 line program
just to see if your function works.
Of course, in Lisp, you'd just run the function in the Listener.
I think, from a cognitive point of view, in Lisp you're always trying
to write and deal with a 2 dozen line routine, whereas in C that 2
dozen line routine is lost in everything else.
Technically, they're identical, but it's more difficult to deal
conceptually with the small C function as a lone function compared to a
Lisp function.
Surely, this isn't a carte blanche statement. I'm a fan of the
conventional IDE's as well, and being able to watch code run is great
when trying to learn new routines, to get the feel of what someone
else was trying to do. I also had problems when dealing with GUI
framework stuff in Lisp. Not so much the routines of mine that were
called by the framework, but more trying to understand the framework
itself, particularly when it's misbehaving because of something I've
done.
But for core routines and algorithms, I don't find the "command line"
debuggers that problematic. I find I use trace more than break,
anyway. I hardly ever use step.
In the long run, the nicest thing about the whole paradigm is that I
don't end up writing a 10,000 line program. Rather, I end up writing a
1000 10 line programs, each done on their own. when they are all
combined, they just happen to work like a 10,000 line program.
Sure, it's not all coincedence, but despite the all the planning, when
you get that last little routine in place and the whole thing just
seems to snap together, it still feels good.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. ······@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
······@netcom.com (Will Hartung) writes:
> On the crass assumption that they didn't, because of all of the
> difficulties mentioned before, then despite how desirable they may be,
> perhaps the folks using them had not felt that such a facility was
> that important.
>
> I'm guessing that because the development paradigm is so much
> different, that steppers aren't as vital as they are for a language
> such as C.
I haven't played with debugging in lispm's, but I have programmed a little
in C, and A LOT in lisp. I think I run into a situation where I wish I had
a stepper about once every six months. The rest of the time, advice, trace
and stack inspection do great jobs at figuring out where the bugs lie.
I do use lots of break statements and the like in lisp as well. But if I do
things right, I can in fact put in a break statement relatively early on in
the code, figure out where execution will go, and simply modify small parts
of the code to figure out if the program behaved as expected. With C it
isn't *nearly* as convenient.
Working with threads and asynchronous events in lisp, I suspect, will make
the picture a lot messier. I also suspect that lisp would be able to
provide facilities to make the task simpler in this environment as well,
though I don't have a good enough feel for this.
> Technically, they're identical, but it's more difficult to deal
> conceptually with the small C function as a lone function compared to a
> Lisp function.
True, but the biggest difference comes in when you have to study the
interactions between functions. Being able to figure out the method
invocation order at run time while debugging can be a very useful thing.
> Surely, this isn't a carte blanche statement. I'm a fan of the
> conventional IDE's as well, and being able to watch code run is great
> when trying to learn new routines, to get the feel of what someone
> else was trying to do. I also had problems when dealing with GUI
> framework stuff in Lisp. Not so much the routines of mine that were
> called by the framework, but more trying to understand the framework
> itself, particularly when it's misbehaving because of something I've
> done.
To some extent, being able to watch code is useful. Ultimately though it
depends on what you are able to watch. One thing that has landed me in
trouble on various occasions is that you cannot trace funcalled functions
in compiled code in lispworks. This is the aspect of lisp that starts
making things fairly ugly, and better facilities to track functions used in
this way would be *very* handy.
> In the long run, the nicest thing about the whole paradigm is that I
> don't end up writing a 10,000 line program. Rather, I end up writing a
> 1000 10 line programs, each done on their own. when they are all
> combined, they just happen to work like a 10,000 line program.
>
> Sure, it's not all coincedence, but despite the all the planning, when
> you get that last little routine in place and the whole thing just
> seems to snap together, it still feels good.
Lisp, in my little bit of experience, allows you to do this right, while
it's next to impossible in C to work this way. The interactions between
object files and headers and what have you start getting on my nerves very
quickly.
Sunil
In article <················@netcom.com>,
Will Hartung <······@netcom.com> wrote:
>One question I have, though, is whether the LispMs had a similiar
>facility to what most programmers are used dealing with today in terms
>of debuggers.
Symbolics Lispms had some sophisticated point-and-click mechanisms that
were extremely useful during debugging, but they didn't have a visual
stepper. However, I remember seeing research papers on such things in the
L&FP conferences, and they almost always used Lispms has the platform to
develop them.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Barry Margolin <······@bbnplanet.com> writes:
> Symbolics Lispms had some sophisticated point-and-click mechanisms that
> were extremely useful during debugging, but they didn't have a visual
> stepper. However, I remember seeing research papers on such things in the
> L&FP conferences, and they almost always used Lispms has the platform to
> develop them.
MCL has a relatively useful stepper and quite a few tracing options.
Usually I'm quite happy with MCL debugging capabilities.
Sure, you are starting to loose with inlined functions, macro generating
macros, tail-recursion removal, ...
The Symbolics Lisp machine often wins because of its presentation
based GUI (maybe in ten years a vendor will develop a portable
CLIM-based IDE with similar capabilities, sigh).
The debugger is quite nice. You have one command-line-based version
(well, actually everything is mouseable) and a window-debugger.
Hmm, maybe I put a screenshot of it online.
The Symbolics can't trace methods, has this ever been fixed?
In article <············@lise.lavielle.com>,
Rainer Joswig <······@lavielle.com> wrote:
>The Symbolics can't trace methods, has this ever been fixed?
I vaguely remember doing (trace (:method ...)) to trace methods.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Barry Margolin <······@bbnplanet.com> writes:
> In article <············@lise.lavielle.com>,
> Rainer Joswig <······@lavielle.com> wrote:
> >The Symbolics can't trace methods, has this ever been fixed?
>
> I vaguely remember doing (trace (:method ...)) to trace methods.
But only Flavor methods? Not CLOS methods?
* Barry Margolin wrote:
> Rainer Joswig <······@lavielle.com> wrote:
>> The Symbolics can't trace methods, has this ever been fixed?
> I vaguely remember doing (trace (:method ...)) to trace methods.
Only works for flavors, not CLOS I think.
--tim
Tim Bradshaw <···@aiai.ed.ac.uk> wrote:
>* Barry Margolin wrote:
>
>> Rainer Joswig <······@lavielle.com> wrote:
>>> The Symbolics can't trace methods, has this ever been fixed?
>
>> I vaguely remember doing (trace (:method ...)) to trace methods.
>
>Only works for flavors, not CLOS I think.
In Genera 8.3, the documentation for "Function Specs for CLOS methods"
claims that using them with TRACE won't work, but it does for me:
> (defmethod zzz ((x symbol)) x)
#<STANDARD-METHOD ZZZ (SYMBOL) 401002114>
> (trace (clos:method zzz (symbol)))
((METHOD ZZZ (SYMBOL)))
> (zzz 'foo)
1 Enter (METHOD ZZZ (SYMBOL)) NIL FOO
1 Exit (METHOD ZZZ (SYMBOL)) FOO
FOO
On another topic entirely, but motivated by the fact that I had to
type in the above example, save it to a file, and insert the file into
the GNU Emacs window I am using to compose this message: It is
possible to paste from the X cut buffer into a Genera X screen.
(#\Keyboard:Paste is bound to the keypad slash key.) Is there some
simple way of copying a selection in a Genera X screen *to* the X cut
buffer?
--David Gadbois
In article <············@lise.lavielle.com>, Rainer Joswig
<······@lavielle.com> wrote:
> The debugger is quite nice. You have one command-line-based version
> (well, actually everything is mouseable) and a window-debugger.
> Hmm, maybe I put a screenshot of it online.
O.k., here is a screen shot of the Genera Window Debugger
running on Genera 8.3 on a MacIvory 3. It is a b&w gif.
http://www.lavielle.com/~joswig/symbolics/genera-window-debugger.gif
The window below the Macintosh menubar has some panes:
upper left: Window title
below: Menu
below: The backtrace
below: Inpect history
below: A Lisp listener in the current break level
upper right: Restarts
below: Disassembly, source code or mouse sensitive source code
below: Items in the current stack frame
In front: A menu invoked by clicking right on a stack frame in the
backtrace
Black line at the bottom: The mouse documentation line
Below: Some system information (time, user,
syntax, package, state, progress bar, ...)
--
http://www.lavielle.com/~joswig/
Will Hartung wrote:
>
> One question I have, though, is whether the LispMs had a similiar
> facility to what most programmers are used dealing with today in terms
> of debuggers.
>
> On the crass assumption that they didn't, because of all of the
> difficulties mentioned before, then despite how desirable they may be,
> perhaps the folks using them had not felt that such a facility was
> that important.
The LispM had a fairly sophisticated debugger, but it didn't work at the
source level. Because of the Lisp-oriented instruction set, it was
fairly easy to read compiled code and understand it in terms of the
source. So the fact that the debugger didn't show this relationship was
less of a barrier than it might have been.
(I do seem to recall that Symbolics had source-level debugging support
under development at one point. I don't know what, if anything, ever
became of this.)
-- Scott
* * * * *
To use the email address, remove all occurrences of the letter "q".
"Scott L. Burson" <·····@zeta-sqoft.com> writes:
> (I do seem to recall that Symbolics had source-level debugging support
> under development at one point. I don't know what, if anything, ever
> became of this.)
It had some bugs for a while, and so was disabled by an option
variable. My recollection is that the bugs were ultimately fixed but
that few were used to turning it on. I think the term "source
locator" is what to look for in the DocEx if you're trying to find it.
Kent M Pitman <······@world.std.com> writes:
> It had some bugs for a while, and so was disabled by an option
> variable. My recollection is that the bugs were ultimately fixed but
> that few were used to turning it on. I think the term "source
> locator" is what to look for in the DocEx if you're trying to find it.
C-M-Sh-c compiles code providing the source locators.
In the debugger the source then is mouseable.