>>>>> "bd" == Bill Dubuque <martigny.ai.mit.edu at wgd> writes:
> I don't use AKCL, but I'm quite familiar with "source level debugging",
> having used MIT/Symbolics Lispms for over a decade. Such capabilities
> are planned for the next major Editi release, assuming appropriate funding
> from Franz. Source level debugging is not trivial to implement because
> the ACL/Win compiler currently has no support for such. That is why you
> don't already see these capabilities in the ACL resident debugging tools.
I wrote and regularly use a "generic" Common-Lisp source-level
stepper/debugger called CLdebug which can be used with a variety of
Lisps and Emacs-to-Lisp interfaces. It works very much like the
Emacs-Lisp debugger called Edebug written by Dan LaLiberte (it
actually uses part of the Edebug display engine). I got so much used
to the ease of debugging with Edebug, that I started to miss this
mechanism more and more when debugging Common-Lisp, which finally made
me bite the bullet and write CLdebug.
CLdebug allows you to step through Lisp source code, set (conditional)
breakpoints, inspect and change local variable values, display the
result of each expression evaluation, etc. When you step through code
the cursor stops before and after every form while displaying the
result of each evaluation in the Emacs minibuffer.
The debugging paradigm used is that you have to instrument the
functions you are interested in with the command 'M-x cldebug-definition',
and then start the evaluation of a form in your Lisp listener with
'(cldebug:run <form>)'. Whenever the evaluation of <form> hits an
instrumented function, Emacs pops up a window with the source code and
stops either at function entry or at some breakpoint in the function
(depending on the debugging mode). Once it has stopped you can step
from there, continue execution, etc. Examination of the Lisp stack
has to be done with the native Lisp debugger, though. If you evaluate
<form> without the 'cldebug:run' wrapper, all currently instrumented
functions behave normally again.
CLdebug works smoothly with user-defined macros and does not need to
have their structure explicitly declared as is necessary in Edebug.
CLdebug also does not modify the code of an instrumented function, the
only difference is that if it was compiled before it will be run
interpreted. Mixing of interpreted, instrumented, and compiled code
is not a problem.
CLdebug is "generic" in the sense that it works by using standard
Common-Lisp only, with a variety of Emacs-to-Lisp interfaces such as
Franz's FI, ILISP, and the standard FSF Emacs Lisp mode. It also
works with Xemacs. We currently use it on a regular basis with ACL
4.2/3, and Franz's FI in GNU Emacs 19.34 and Xemacs 19.13. Since I
haven't tested it with other interfaces and Lisps in about two years,
there might be a tiny bit of work necessary to get it working again in
some of these environments. Also, since it relies on Common-Lisps's
eval-hook mechanism, it is not very useful with Lisps that don't
believe much in evaluation (such as CMU-Lisp). As far as I remember,
I tried it successfully with Allegro-CL, Lucid-CL, CLISP, and GCL (all
under Unix).
So far I've been reluctant to release it publicly, since there were
always these few more features that I wanted to implement (but never
seem to have time to :-), and since there is a certain fragility due
to CLdebug's cross-platform ambitions, in particular, to have some
arbitrary Lisp reliably trigger actions in some arbitrary Emacs is
something a bit hairy. But, if there is enough interest (send me some
mail :-), I might be persuaded to package it up and put it up on the
Web.
Hans
------------------------------------------------------------------------------
Hans Chalupsky USC Information Sciences Institute
<isi.edu at hans> 4676 Admiralty Way
(310) 822-1511 Ext.745 Marina del Rey, CA 90292
------------------------------------------------------------------------------