Re: MCL 3.0 wishes

[eliot@cs.umass.edu (CHRISTOPHER ELIOT)]

In article <21OCT199309533375@cs.umass.edu>, eliot@cs.umass.edu (CHRISTOPHER ELIOT) writes...

>But again, how do you get a dissasembly
>of a function?  For large functions it is often very difficult to
>find out where you are and the Lisp Machine debugger would just
>hand you the current location inside the function right there
>on a silver platter.  MCL does not.

Since I posted that, several people have informed me that there are
features of MCL I didn't know about.  Here is a list of some features
that are easy to overlook and might be helpful. I'm not sure my
gripes are completely over, but I need to try these out for a few
weeks and see if I am satisfied.

 From a backtrace window:
cmd-Option-Click on the name of a function in the upper part
will do the equivalent of meta-. on that name, bring up
the source code if it is available.

Double-clicking on the name of a function will Inspect that function.
By default this shows nothing of any great interest, but under
the Commands pop-up you can select Show Disassembly and Show PC
to help locate where you crashed.

If you like this facility you can make it come up more automatically:
In your Init file (or wherever) you can set these global variables:

(setq *BACKTRACE-ON-BREAK* t)   ; Make the backtrace window come
up on every error, without requiring you to ask for it.


(setq *INSPECTOR-DISASSEMBLY* t) ; Make the Inspector show the
disassembly listing by default when you inspect a function.

With these settings you can, indeed, get to the disassembly listing
from a break by a single double-click.

A general comment to people (like me) who post messages about what
MCL will do in various situations: remember that there are these
global switches that cause different types of behavior to
occur. When someone seems to be crazy because you-just-tried-it
and it does not work that way, perhaps the two MCLs are
configured differently and you both can learn something.

Chris Eliot