[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: "rudolf mittelmann" <rm@cast.uni-linz.ac.at>
- Date: Wed, 20 Oct 1993 17:28:11 +0100
- Reply-to: "rudolf mittelmann" <rm@cast.uni-linz.ac.at>
In message <199310201401.AA27386@zip.eecs.umich.edu> kieras writes:
> I second the opinion of joe@genome.wi.mit.edu :
>
> >MCL 3.0 ... ooh, aah ... I wonder if it has my main wish:
> >A debugger comparable to Un*x lisps (for ex. CMU). At least let's see
> >some variable names on those stack frame entries and let's have some way to
> >see roughly which line in the source code we have broken in...
>
> Some time ago, I queried about this, and was told that apparently the
> break/backtrace facility and the interpreter really don't know about each
> other at all. This seems to be a result of CCL/MCL's original
> compile-everything-immediately philosophy, which contrasts to traditional
> lisps' philosophy that everything is interpreted until explicitly
> compiled.
>
> Trying to debug interpretively, standard practice on other lisps since the
> beginning, isn't worthwhile in MCL because the backtrace is so
> unintelligible that you can't tell which user-coded expression failed, and
> the local symbol names are gibberish as well. What clues there are lie
> past the right-hand edge of the backtrace window and might in fact be
> unaccessible unless you have a really big display to blow the window up in.
> Hence your best and only usable debugging option is to run compiled code
> with SAVE LOCAL SYMBOLS so you can see what values your symbols have, and
> use lots of old-timey FORTRAN-era debugging printouts to narrow down which
> expression failed. Hardly modern, and not as good as we had a decade ago!
>
> Fixing this would make MCL my favorite LISP; at this time, its main virtues
> are only that it is a very complete Common LISP that also runs on my
> favorite platform.
> -----------------
> David Kieras
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.
In former times I used the perfect Interlisp-D environment,
and had a hard time to get used to the puritanic Unix
lisp (don't call it environment...).
No I am happy again with MCL.