Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!bcm!dimacs.rutgers.edu!seismo!uunet!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!pequod.cso.uiuc.edu!dorner
From: dorner@pequod.cso.uiuc.edu (Steve Dorner)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Does anyone know anything about new Apple development products?
Message-ID: <1991Mar2.015219.8298@ux1.cso.uiuc.edu>
Date: 2 Mar 91 01:52:19 GMT
References: <1991Feb13.050326.24115@verity.com> <1991Feb13.215508.20111@ux1.cso.uiuc.edu> <25022@neptune.inf.ethz.ch>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at U-C
Lines: 46

In article <25022@neptune.inf.ethz.ch> mneerach@iiic.ethz.ch writes:
>In article <1991Feb13.215508.20111@ux1.cso.uiuc.edu>, dorner@pequod.cso.uiuc.edu (Steve Dorner) writes:
>SADE is the *best* source-level debugger *I* haver ever used (and yes, I
>have used gdb quite a lot). The earlier versions were terribly slow, but 
>this has improved a lot.

Please tell me how to do the following things:

1. Use arbitrary expressions in the 'watch variable' window.
2. See variable histories (like Watch Variable, but without erasing the old
values).
3. Use C syntax for structures and casts (trivial cases work, not complicated
ones).
4. Show me local variables UP the stack from the current context.  (This
is the A#1 defect of SADE.  Or do you like "Sorry, that variable is in
a register"?)
5. Show me argument lists on stack backtraces.
6. Let me decide what base I want numbers printed in.
7. Actually PRINT things in windows without doing a 'full stop':
  break foo.(1) begin
    bar
  end
  Doesn't print anything until a full break is encountered.  Full breaks
  engender major switches, screwing up window contents no end.
8. set breaks by source line number (something I can ask my editor for)
   rather than by executable statement number (which FORCES me to open
   the file with SADE to discover).
9. Either save or don't save the 'junk' windows (worksheet, variable watch,
   values); quit bugging me about them.
10. sc7

I could probably fix 1 and 2, and maybe 9 and 10, if I wanted to spend a
few days debugging SADE scripts.  3-8 are just plain out, so far
as I can tell.  (There may be more capabilities than I'm aware of,
since the manual is pretty, but superficial.)

These are the things off the top of my head that drive me NUTS
about SADE.  Even dbx (let alone gdb) can do most of them with a minimum
of pain.  Am I all alone in wanting these things?  Am I all alone in
thinking the SADE environment is kind of *weird*?

Yes, SADE has gotten better in terms of speed; dramatically so.
I still find it an extremely clumsy debugger.
--
Steve Dorner, U of Illinois Computing Services Office
Internet: s-dorner@uiuc.edu  UUCP: uunet!uiucuxc!uiuc.edu!s-dorner