Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!umd5!uvaarpa!mcnc!rti!sas!cole
From: cole@sas.UUCP (Tom Cole)
Newsgroups: comp.sys.mac
Subject: Re: LightspeedC 3.0
Summary: Arrived Friday afternoon, July 8
Keywords: Still Waiting
Message-ID: <570@sas.UUCP>
Date: 9 Jul 88 16:06:39 GMT
References: <403@dbase.UUCP>
Organization: SAS Institute Inc.,Cary NC,25712
Lines: 68

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....