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