mdr@omepd (Michael Rutenberg) (06/30/88)
I hate to ask, but would somebody who has used or tried LSC 3.0 please describe some of the features in it. I can wave my hands as well as the rest, but I'd like to know more than "source debugging" and "precompiled includes". I'm positive about 3.0 and I'll likely upgrade, but I'd also like to know more (first!). I'll start - the debugger, from the picture I saw in one of the tabloids, looks like the LSP debugger. What are it's novel features? Can I look at named variables on the call stack and mess with them? Can I break when variable is modified? I'd just like to know what it does. What interfaces are there to low level debuggers (eg TMON) or are they ever needed any more? :-) How do precompiled #includes work? Are they automatically maintained caches of the symbol table information for the include file? Nosy minds with finite resources want to know! Boy, I'd like to play with it! Mike
drc@dbase.UUCP (Dennis Cohen) (07/01/88)
In article <3630@omepd>, mdr@omepd (Michael Rutenberg) writes: > I'll start - the debugger, from the picture I saw in one of the > tabloids, looks like the LSP debugger. What are it's novel features? The first, and most noticeable difference is that it requires MultiFinder and runs in a separate layer, thus giving full compatibility -- something you don't have with the Pascal product. The price is the amount of memory required. > Can I look at named variables on the call stack and mess with them? Yes, you can look at named variables, including structs, and modify their values. > Can I break when variable is modified? I'd just like to know what it does. I haven't had occasion to see if checkpoints were implemented, so I don't know the answer to that one. The nicest feature is the use of popups for popping back and forth through your calling chain and being able to double click on fields of structs in the variable window and get a new variable window which displays what you just double-clicked. > > What interfaces are there to low level debuggers (eg TMON) or > are they ever needed any more? :-) All of the old TMON/MacsBug compatibility is still there, and it is still occasionally needed (like when trying to traipse through ROM to find out what is getting trampled). > > How do precompiled #includes work? Are they automatically maintained > caches of the symbol table information for the include file? They are similar to the MPW Pascal $LOAD files in that they have, in symbol table form, all the information from the include file, thus allowing a quick load of a single file rather than the multiple #includes with subsequent processing. Dennis Cohen Claris ------------ Disclaimer: Any opinions expressed above are _MINE_!
gillies@p.cs.uiuc.edu (07/06/88)
There's one feature I'd really like to see in the LSC 3.0 debugger:
If you are hand-generating test cases for your program, it helps a lot
if the debugger has the ability to create & assign to data structures.
For instance, I have a record "DataRec" and I want to create an
instance, assign some values to it, and then invoke a procedure with
the record as one of the arguments. The debugger (hopefully) supports
this with a nice primitive like "> z = Make(DataRec)". Ideally, it
supports doing this from a script (regression testing). MIT's CLU
language debugger could do this for the programmer/tester (everything
but scripting).
Does LSC 3.0 have this ability? If not, could you (Rich) suggest it for
inclusion in a future release?
Don Gillies, Dept. of Computer Science, University of Illinois
1304 W. Springfield, Urbana, Ill 61801
ARPA: gillies@cs.uiuc.edu UUCP: {uunet,ihnp4,harvard}!uiucdcs!gillies