Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!dewey.soe.berkeley.edu!oster From: oster@dewey.soe.berkeley.edu (David Phillip Oster) Newsgroups: comp.sys.mac.programmer Subject: Re: Problem with LSC 4.0 debugger. Message-ID: <31520@ucbvax.BERKELEY.EDU> Date: 26 Sep 89 04:00:08 GMT References: <244@dbase.UUCP> <3424@cbnewsc.ATT.COM> <1563@atanasoff.cs.iastate.edu> Sender: usenet@ucbvax.BERKELEY.EDU Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) Distribution: na Organization: School of Education, UC-Berkeley Lines: 50 In article <1563@atanasoff.cs.iastate.edu> jwright@atanasoff.cs.iastate.edu.UUCP (Jim Wright) writes: >How should recursive functions be handled? Are they a special case at all? >Do you really want to allow local variables be changed in calling functions? Just handle this problem the same way it is already handled: you set a context in the program window by using the pop-up menu at the bottom of the window. If you enter variable names in the data window, they are interpreted in the program window's current context. Since the compiler generated the code in the first place, it is easy for it to remember whther there is a stack frame, and as for register variables, a simple integer remembers them, since they are allocated sequentially. At the worst, you could add a single bit for "this frame is too complex to remember". A debugger that let me look at variables up the stack is still better than what I've got. While you are at it: how about letting me save the debugger state in a file, so I can reload it when I run the program again, and have the debugger know what files and what variables I was looking at, and what breakpoints I set. How about treating the parameter list of a procedure, and the set of local variables of a procedure as a pseudo-struct, so I can look at the whole set of them in their own window, as I look at structs now. In fact, this would be a reasonable interpretation of typing a procedure name into the data window, in that procedure's context: it would have the value "stack frame 0x0000", and double clicking on it would bring up a stack-like window of all the locals and parameters. Many lisp debuggers work this way. As it stands, the popup menu at the bottom of the program window is really an annoying feature: I can point at nested stack frames, but having pointed at them the debugger won't let me do anything meaningful with them. Also, how about debug time variables or at least macros, so I don't have to refer to a structure as (**(**(**(**foo).fum).fie).fazzle).fop simply because my progragram doesn't happen to assign (**(**(**foo).fum).fie).fazzle to a variable. I should be able to assign it to a variable, say "piggins" at debug time, so I could just type (**piggins).fop rather than the whole tedious expression. I'd even be happy if it were really a macro, and not a true variable. Also, how about making the debugger trust the Make command: if I use the make command to tell the compiler that I know fiels a.c, b.c, and c.c weren't really modified by a change to a .h file, the debugger doesn't believe me and refuses to let me debug any functions in those files until I do a full recompile. Why? Don't get me wrong, I still think it is a great debugger, I just wish that Lightspeed C version 4 had improved on it a little.