Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!att!cbnewsc!fjo From: fjo@cbnewsc.ATT.COM (frank.j.owen) Newsgroups: comp.sys.mac.programmer Subject: Re: Problem with LSC 4.0 debugger. Message-ID: <3424@cbnewsc.ATT.COM> Date: 25 Sep 89 16:07:17 GMT References: <244@dbase.UUCP> Distribution: na Organization: AT&T Bell Laboratories Lines: 33 From article <244@dbase.UUCP>, by awd@dbase.UUCP (Alastair Dallas): > > Does the word 'scope' ring a bell here? K&R, 1st Ed., p. 76: > > Darell's reaction sounds like good salesmanship, but it also demonstrates > why tech support doesn't write the software. > > Maybe I'm being unnecessarily harsh, but how about a law that says that > before Symantec can sell someone a C compiler that that person has to > demonstrate competency in the language. No, I take it back--that's not Yeh, How 'bout it Alastair? How 'bout another law that says that people demonstrating INcompetency in a language (like yourself) be fined for spreading MISINFORMATION! Bruce Beare was completely correct in expecting a debugger to be able to display the local variables of functions that are stacked up in the current calling sequence. All the variables of each function are in the stack frame for that function and CAN be displayed and even modified. Of course you must in some way tell the debugger WHICH stack frame you are talking about, in case there are locals of different functions with the same name, but that is a do-able thing. (Perhaps THINK's debugger could use hierarchical menus - the second level could have entries for each local.) Many debuggers allow you to do this. It is a VERY nice feature. Please do a little homework before reprimanding others on the net! -- Frank Owen 312-982-2182 AT&T Bell Laboratories 5555 Touhy Ave., Skokie, IL 60077 PATH: ...!att!ihc!fjo