awd@dbase.UUCP (Alastair Dallas) (07/06/88)
I've heard Rich saying that LSC3.0 is shipping, but I haven't seen it-- I sent my check in two weeks ago. I'll tell the net when it shows up. /alastair/
palmer@tybalt.caltech.edu (David Palmer) (07/07/88)
In article <403@dbase.UUCP> awd@dbase.UUCP (Alastair Dallas) writes: >I've heard Rich saying that LSC3.0 is shipping, but I haven't seen it-- >I sent my check in two weeks ago. I'll tell the net when it shows up. > >/alastair/ I got LSC 3.0 yesterday (Tues. July 5) from MacConnection (1 (800) Mac-Lisa) for $95+$3S&H. (I sold my version 2.15 for the difference between the upgrade price and the new price and bought version 3.0 new) Good stuff. I ran the source-code debugger in 1 Mb by shrinking the partition sizes and putting an FKEY in to quit the finder (I used resedit to make a new FKEY resource, id=5, contents = A9F4, and put it in the finder. Now, when I type clover-shift-5, finder quits, leaving enough memory for the debugger (also with a reduced partition) and the program being debugged) I don't know how large a program you can debug with that much memory, but someday RAM prices will come down (perhaps). David Palmer palmer@tybalt.caltech.edu ...rutgers!cit-vax!tybalt.caltech.edu!palmer "Walt sent me"
cole@sas.UUCP (Tom Cole) (07/09/88)
In article <403@dbase.UUCP>, awd@dbase.UUCP (Alastair Dallas) writes: > I've heard Rich saying that LSC3.0 is shipping, but I haven't seen it-- > I sent my check in two weeks ago. I'll tell the net when it shows up Well, my copy arrived Friday afternoon. I hate to gush, but this is *real* neat. The source level debugger is pretty much everything promised, and it still has that nice fast feeling. I am fortunate enough to have a 5mb ][ and it runs nicely. Comparisons to LightSpeed Pascal's debug environment seem inevitable, and here are a few observations: 1. The expression evaluator doesn't let you call functions, something LSP did permit. It also doesn't let you use ++ or -- (no surprise there, I guess). This is not all that big a deal for me, however. It does seem to understand virtually every other expression I could throw at it - scalar, address, etc. 2. If a variable is being monitored in the data window, and it goes out of scope, it is removed from the data window. This is inconvenient if you are watching logic that repeatedly dips into a support routine and you want to see something that keeps happening in that routine. You can "lock" items in the data window so they aren't removed, but they don't seem to get updated either. Maybe I am missing something. A small complaint, but I liked LSP which just said the value was "out of context" or something like that, and left it in the old Observe window. 3. The pre-compiled include files are NICE! They thoughtfully provide one called MacHeaders which includes about 80% of the managers .H files. It is automatically #include'd for you unless you turn off the feature. The idea is that you dont' have to put the handful of #includes in each of your routines if you don't want to mess with it - similar to LSP which always knew about most of the Toolbox. The only manager I wished they had included was the printing manager, but you can recompile the header yourself to include whatever you want, so it was no big deal. 4. The compiler/editor/linker runs in one partition, the debugger in another, and your program in a third. This means (as far as I can tell) that the environment your program runs in WHILE DEBUGGING is almost identical to the world it will have to stand up in as a real application. This was one of my few recurring annoyances with LSP - the world the application was debugged in was too cushy, and many memory-related errors didn't show up until you ran it standalone - no helpful, friendly debugger present anymore. LSC seems to create a world that is a lot more like the real world. Nice work. 5. The compiler world and the debugger seem to talk back and forth a good bit - smells of interprocess communication. Was this implemented as a real nifty IPC system, or did you guys cheat. Wanna share what you did? 6. I read a lot of grumbling about memory, costs, and 2mb for the debugger. I admit I am fortunate enough to have upgraded to 5mb last fall before the crunch. However, if you wanna do real C development, and MPW is too cumbersom or not needed, this is the greatest thing since sliced bread and you ought to bite the bullet and buy some memory somewhere somehow somewhen. Well, I guess I liked it. These are the opinions of someone who has no connection with Think, er, Symantec other than being a happy customer and an admirer of quality code. Tom Cole SAS Institute {anywhere}mcnc|rti|sas|cole These are my opinions. Get your own....
clive@drutx.ATT.COM (Clive Steward) (07/11/88)
A question for you people who have been doing reviews: does the debugger allow debugging inits, or das? Thanks...! Clive Steward
jwhitnell@cup.portal.com (07/14/88)
|A question for you people who have been doing reviews: does the |debugger allow debugging inits, or das? No, it doesn't support either DAs or Inits. Jerry -- Jerry Whitnell jwhitnell@cup.portal.com ..!sun!cup.portal.com!jwhitnell
singer@endor.harvard.edu (Rich Siegel) (07/15/88)
In article <7310@cup.portal.com> jwhitnell@cup.portal.com writes: >|A question for you people who have been doing reviews: does the >|debugger allow debugging inits, or das? > >No, it doesn't support either DAs or Inits. Wrong. Using the DAShell, you can debug a desk accessory. (I know it can be done; I saw Mike doing it at a demonstration). You cannot, however, debug other code resources, unless you're willing to write a shell program to test under. >Jerry --Rich Rich Siegel THINK Technologies
jwhitnell@cup.portal.com (07/17/88)
Rich Siegel writes... |In article <7310@cup.portal.com> jwhitnell@cup.portal.com writes: |>|A question for you people who have been doing reviews: does the |>|debugger allow debugging inits, or das? |> |>No, it doesn't support either DAs or Inits. | | Wrong. Using the DAShell, you can debug a desk accessory. (I know |it can be done; I saw Mike doing it at a demonstration). You are, of course, correct. The file DA Shell in the subdirectory DA stuff documents how to debug a desk acessory. Of course, the manual says nothing about it hence the confusion on my part. I believe someone at THINK is also working on a tool to allow you to debug CDEVs from the source level debugger. | | You cannot, however, debug other code resources, unless you're willing |to write a shell program to test under. You usually need a shell program to test with anyway, unless you can write code the first time without any bugs :-). Code resources such as CDEF, WDEF and MDEF all can be debugged using a shell (I'm working on a CDEF now by just this method). INITs are about the only thing that can't be debugged this way since they run standalone in a strange enviorment. Of course, the purist might point out that that what you are debugging is not what you'll finally ship and changes may have to be made to the code to convert to a real DA/CDEF/MDEF/etc. Mostly this has to do with applications using A5 (which is the only world the source debugger works in) while code resources use A4. So you do need to be careful when writting your code. |>Jerry | --Rich Jerry -- Jerry Whitnell jwhitnell@cup.portal.com ..!sun!cup.portal.com!jwhitnell