In a previous thread in this group, I came across the line "This tells us
that both "camps" could learn a lot from each other!", both "camps"
referring to Lisp vs. C/C++. I definitely agree. I have been programming
in Lisp for over 12 years now, and only just learned C late last year.
(something that I had been avoiding for a very long time). I was using
Symbolics Lisp machines from 1983 to 1989 and Macintosh Common Lisp from
1990 to 1993. However, I'm now writing educational software and it is
impractical to deliver applications that won't even fit on a high density
floppy disk and require six to eight meg of RAM, when many of the schools
have older machines with only 4 meg and some only have low-density drives.
However, I still miss the Lisp development a lot, in particular the dynamic
environment, incremental compilation, inspector, etc. However, I recently
went back to Lisp for a small project, and I realized that I had gotten
very used to something in my C environment that my Lisp environment just
didn't have! Namely SADE (Symbolic Application Debugging Environment, for
those non-Mac programmers), a source-level debugger from Apple. Now, I am
the first to admit that the SADE user interface leaves a lot to be desired,
but I really like the ability to set a breakpoint by just clicking in a
line of code and typing a keystroke, and then when I step through the
program, the highlighting changes to indicate which piece of code is
currently being executed. I find this to be much easier as a way to
pinpoint exactly where a bug is inside a procedure than the way I would
usually do it in Lisp, which would be to disassemble the current procedure
from the debugger, look at where the program counter was pointing, and go
back to the source code and try to match up the disassembled instructions
to the source. Even when I would compile with the "save-definitions" flag
set, and then use the stepper, I found it to be less intuitive to have
these disembodied s-expressions printed, instead of referring back to the
original source file. Has anybody implemented a source-code debugger for a
lisp environment? Obviously the extensive use of macros would make this a
difficult task (I miss Lisp macros too!), but does it make it an impossible
one?
--
Laura D. Bagnall
TERC
2067 Massachusetts Ave.
Cambridge, MA 02140
phone 617-547-0430 fax 617-349-3535
Laura,
Although I'm not a lisp expert, I've used the lisp debugger for
GNU emacs. It's not a great debugger, but it does allow you to set
breakpoints in functions, examine return values and variables, etc.
the mode is called debug.el. You can probably pick it up off of the Net
(some GNU emacs respository), or I can send you a copy (every Development
NeXT station ships with /usr/lib/emacs/lib full of LISP routines).
Rik Cousens (·······@biztech.com)
In article <··························@mac804.terc.edu>
·············@TERC.EDU (Laura D. Bagnall) writes:
> In a previous thread in this group, I came across the line "This tells
us
> that both "camps" could learn a lot from each other!", both "camps"
> referring to Lisp vs. C/C++. I definitely agree. I have been
programming
> in Lisp for over 12 years now, and only just learned C late last year.
> (something that I had been avoiding for a very long time). I was using
> Symbolics Lisp machines from 1983 to 1989 and Macintosh Common Lisp from
> 1990 to 1993. However, I'm now writing educational software and it is
> impractical to deliver applications that won't even fit on a high
density
> floppy disk and require six to eight meg of RAM, when many of the
schools
> have older machines with only 4 meg and some only have low-density
drives.
> However, I still miss the Lisp development a lot, in particular the
dynamic
> environment, incremental compilation, inspector, etc. However, I
recently
> went back to Lisp for a small project, and I realized that I had gotten
> very used to something in my C environment that my Lisp environment just
> didn't have! Namely SADE (Symbolic Application Debugging Environment,
for
> those non-Mac programmers), a source-level debugger from Apple. Now, I
am
> the first to admit that the SADE user interface leaves a lot to be
desired,
> but I really like the ability to set a breakpoint by just clicking in a
> line of code and typing a keystroke, and then when I step through the
> program, the highlighting changes to indicate which piece of code is
> currently being executed. I find this to be much easier as a way to
> pinpoint exactly where a bug is inside a procedure than the way I would
> usually do it in Lisp, which would be to disassemble the current
procedure
> from the debugger, look at where the program counter was pointing, and
go
> back to the source code and try to match up the disassembled
instructions
> to the source. Even when I would compile with the "save-definitions"
flag
> set, and then use the stepper, I found it to be less intuitive to have
> these disembodied s-expressions printed, instead of referring back to
the
> original source file. Has anybody implemented a source-code debugger
for a
> lisp environment? Obviously the extensive use of macros would make this
a
> difficult task (I miss Lisp macros too!), but does it make it an
impossible
> one?
>
> --
> Laura D. Bagnall
> TERC
> 2067 Massachusetts Ave.
> Cambridge, MA 02140
> phone 617-547-0430 fax 617-349-3535
From: ·············@TERC.EDU (Laura D. Bagnall)
Has anybody implemented a source-code debugger for a
lisp environment? Obviously the extensive use of macros would make this a
difficult task (I miss Lisp macros too!), but does it make it an impossible
one?
Try my Edebug for Emacs Lisp. If you want Common Lisp debugging,
there is a fairly nice subset in cl.el (Dave Gillespie's version).
You can get both from a.cs.uiuc.edu in pub/edebug.
Edebug handles almost any special form or macro (including loop) by
requiring an associated specification of which arguments or components
of arguments may be evaluated so Edebug can instrument them. This
turns out to be better than the usual macroexpansion tricks.
Anyone want to pay me to port this to full Common Lisp (and save me
from the C++ world)? I need a real job soon - the kids are growing up.
Dan LaLiberte
·······@cs.uiuc.edu
(Fight interface copyrights and software patents.
Join the League for Programming Freedom: ···@uunet.uu.net)
In article <··························@mac804.terc.edu>,
·············@TERC.EDU (Laura D. Bagnall) writes:
> 1990 to 1993. However, I'm now writing educational software and it is
> impractical to deliver applications that won't even fit on a high density
> floppy disk and require six to eight meg of RAM, when many of the schools
> have older machines with only 4 meg and some only have low-density drives.
ProGraph probably doesn't have everything you'd like, but if I was
using a Mac I'd certainly want to try it. You can ask about it in
comp.lang.visual, unlee the VB programmers have overtaken tho group
again. Last time I looked in there, it was full of ProGragh people.
Good luck, anyway.
Martin Rodgers
--- Cyber Surfing on CIX ---
In article <··························@mac804.terc.edu> ·············@TERC.EDU (Laura D. Bagnall) writes:
environment, incremental compilation, inspector, etc. However, I recently
went back to Lisp for a small project, and I realized that I had gotten
very used to something in my C environment that my Lisp environment just
didn't have! Namely SADE (Symbolic Application Debugging Environment, for
those non-Mac programmers), a source-level debugger from Apple. Now, I am
the first to admit that the SADE user interface leaves a lot to be desired,
but I really like the ability to set a breakpoint by just clicking in a
line of code and typing a keystroke, and then when I step through the
program, the highlighting changes to indicate which piece of code is
currently being executed. I find this to be much easier as a way to
pinpoint exactly where a bug is inside a procedure than the way I would
usually do it in Lisp, which would be to disassemble the current procedure
from the debugger, look at where the program counter was pointing, and go
back to the source code and try to match up the disassembled instructions
to the source. Even when I would compile with the "save-definitions" flag
set, and then use the stepper, I found it to be less intuitive to have
these disembodied s-expressions printed, instead of referring back to the
original source file. Has anybody implemented a source-code debugger for a
lisp environment? Obviously the extensive use of macros would make this a
difficult task (I miss Lisp macros too!), but does it make it an impossible
one?
I agree that effortless breakpoint-setting on a form-by-form basis (as
was possible on the Symbolics 3600 series) is very desirable, but the
more pressing source-debugging need is actually the latter one you
mention: to find the specific form corresponding to an active stack
frame. At least one commercial implementation (LispWorks) offers this
ability to immediately bring up the "offending" form in an editor
buffer.
--
Lawrence G. Mayka
AT&T Bell Laboratories
···@ieain.att.com
Standard disclaimer.
I have been confronted with the issue of source code debugging when
teaching introductory programming courses in Tampere University of
Technology, and I solved the problem by writing a portable debugger
based on instrumenting source code. It is called Psd, (the Portable
Scheme Debugger), and it is available as ftp.cs.tut.fi:/
pub/src/languages/schemes/psd-1.1.tar.Z, as well as in the Scheme
Repository (now at Indiana?).
It does not handle macros, although it would not be impossible to make
it understand them. As you might guessed, it works with Scheme, not
CL. There is an article about it in a recent Lisp Pointers: Psd -- a
Portable Scheme Debugger, Lisp Pointers, VI(1), 1993
--
Pertti Kellom\"aki (TeX format) # These opinions are mine,
Tampere Univ. of Technology # ALL MINE !
Software Systems Lab # (but go ahead and use them, if you like)
>>>>> "pk" == Kellom{ki Pertti <··@kaulushaikara.cs.tut.fi> writes:
pk> There is an article about it in a recent
pk> Lisp Pointers: Psd -- a Portable Scheme Debugger, Lisp
pk> Pointers, VI(1), 1993
For the WWW types, the article is also available as
<A HREF="http://www.cs.tut.fi/staff/pk/scheme/psd/article/article.html">
hypertext.
</A>
--
Pertti Kellom\"aki (TeX format) # These opinions are mine,
Tampere Univ. of Technology # ALL MINE !
Software Systems Lab # (but go ahead and use them, if you like)
Laura D. Bagnall (·············@TERC.EDU) wrote:
: .............. However, I'm now writing educational software and it is
: impractical to deliver applications that won't even fit on a high density
: floppy disk and require six to eight meg of RAM, when many of the schools
: have older machines with only 4 meg and some only have low-density drives.
If you could do with Scheme, there are lots of small Scheme compilers
and interpreters. Especially the ones that compile to C might fit.
: ..................... Has anybody implemented a source-code debugger for a
: lisp environment?
The Portable Scheme Debugger (PSD), though primitive, does this.
(Maybe I should have checked if Scheme is an F-word in this group?)
--
···········@daimi.aau.dk Staff-programmer
Aarhus University, Ny Munkegade 116 Phone: +45 89423223
DK-8000 Aarhus C, Denmark. Fax: +45 86135725
PGP Public Key fingerprint: E7B1175FC30D9E96B67AF61D89A70A1F