Path: utzoo!attcan!uunet!portal!cup.portal.com!jwhitnell
From: jwhitnell@cup.portal.com
Newsgroups: comp.sys.mac
Subject: Re: LightspeedC 3.0
Message-ID: <7417@cup.portal.com>
Date: 16 Jul 88 23:36:34 GMT
References: <570@sas.UUCP> <8239@drutx.ATT.COM> <7310@cup.portal.com>
Organization: The Portal System (TM)
Lines: 43
XPortal-User-Id: 1.1001.3098

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