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