[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MCL 3.0 wishes
- To: info-mcl@ministry.cambridge.apple.com
- Subject: Re: MCL 3.0 wishes
- From: liberte@cs.uiuc.edu (Daniel LaLiberte)
- Date: Wed, 20 Oct 1993 20:23:52 GMT
- In-reply-to: rm@cast.uni-linz.ac.at's message of Wed, 20 Oct 1993 17:28:11 +0100
- Newsgroups: comp.lang.lisp.mcl
- Organization: University of Illinois, Urbana-Champaign, Dept CS
- References: <199310201628.AA06279@arnold.cast.uni-linz.ac.at>
- Sender: news@cs.uiuc.edu
rm@cast.uni-linz.ac.at ("rudolf mittelmann" ) writes:
I don't understand these new complaints about the MCL debugger.
I think I can do everything with it that I could do with
the Lucid CL (Unix) debugger: inspect stack frames, arguments, local
variables, change some, exit frome selected frame with specified
return value, etc. And, in contrast to Lucid 4.1, all this with
some mouse clicks.
What else do you need?
Even to find the corresponding source code is supported, via
find-definition menu command.
Find-definition will find the function definition that *contains* the
code referenced by some frame, but it doesnt tell you where in the
definition you are. To support this, there must be a mapping from
expressions to source code positions which, admitedly, has some
overhead. But once you do the instrumentation, you can step through
source code, set breakpoints, etc. All those wonderful things that C
and C++ debuggers now have. This is unlike the Lisp steppers which
print expressions, and replace them with values as they are evaluated,
in a separate window; this is useful sometimes, but not the same
thing.
My edebug for Emacs Lisp does the necessary instrumenting of
expressions, and it works with Common Lisp macros and read macros, and
it is not affected by compilation (although optimization is totally
subverted, but hey, you're debugging).
Dan LaLiberte
liberte@cs.uiuc.edu
(Fight interface copyrights and software patents.
**** The current NAFTA will write them in stone !!!! ****
Join the League for Programming Freedom: lpf@uunet.uu.net)