Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!apple!oliveb!pyramid!bjb
From: bjb@pyramid.pyramid.com (Bruce Beare)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Problem with LSC 4.0 debugger.
Message-ID: <85524@pyramid.pyramid.com>
Date: 26 Sep 89 15:33:39 GMT
References: <85031@pyramid.pyramid.com> <244@dbase.UUCP> <85347@pyramid.pyramid.com> <254@dbase.UUCP>
Reply-To: bjb@pyramid.pyramid.com (Bruce Beare)
Distribution: na
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 27

In article <254@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes:
>In article <85347@pyramid.pyramid.com>, bjb@pyramid.pyramid.com (Bruce Beare) writes:
>> 
>> (responses and etc deleted)
>
>I thought about this after I posted my reply: You didn't seem confused that
>the program context hid the variable, you were upset that the debugger wasn't
>magical enough.  That's certainly a valid addition to the wish list, so
>I retract my snide comments about not buying C compilers unless you know C.
>I guess our only continuing disagreement, then, is where to put a global-
>context debugger on the priority list.  It seems like a lot of pain for
>only a little gain, to me, so I'd put it fairly low on the list.
>
>/alastair/

This is where we "really" differ. Without this feature, a debugging programmer
can be reduced to either putting "printf's"  in the code, or even worse, to 
iterative debugging -- place a breakpoint, find a problem, place an earlier breakpoint,
re-run the code to find the value of a variable in the caller, etc...

This can (obviously) be tedious and can greatly slow the debug cycle. When I realized
that this was a missing feature - and not a user-error, I was astounded. This is the
first symbolic C debugger that I have seen that can't do this (i.e. sdb, dbx, cdb, etc).
Think C does a really great job with many things - it shouldn't be second class in the
debugger department.

Bruce Beare