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