bkahn@archive.webo.dg.com (Bruce Kahn) (10/05/90)
Ive been writing an application under Orca/C that is composed of 2-3 separate
files. Since the prizm debugger under Orca/C is a source level debugger, it
would be really nice if I could use it to debug my program. All attempts at
doing this have failed and Im out of ideas. I havent been able to reach
ByteWorks; they've had a busy line, so Im asking the net. Has anyone been
able to debug segmented (desktop) programs under Prizm? Any ideas (besides
cumbersome fprintf's)??
--
Bruce (bkahn@archive.webo.dg.com or
kahn@adam.dg.com)
Standard disclaimers apply, except where prohibited by law...toddpw@tybalt.caltech.edu (Todd P. Whitesel) (10/05/90)
If you are still using a beta version (it says b in the version number at the top of the screen as ORCA starts up) then I suggest you mail off that registration card right away (I am...) I got it to work with their sample program but with mine it enters debug mode and I can't get out! I can't even pull down the debug menu. I am pretty convinced that the debugger is still flaky and I expect (read: IT HAD BETTER) the 1.1 final version to fix the problems. Todd Whitesel toddpw @ tybalt.caltech.edu
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/05/90)
In article <1023@dg.dg.com> bkahn@archive.webo.dg.com (Bruce Kahn) writes: >Has anyone been able to debug segmented (desktop) programs under Prizm? >Any ideas (besides cumbersome fprintf's)?? fprintf() won't do you any good in a desktop application. I haven't tried exactly the scenario you describe, but I have managed to successfully use the ORCA debugger with ORCA/C 1.1 under other circumstances. Make sure the COMPILE option is set to generate debugger code (this consists of some COP opcodes followed by data for the debugger), and you may have to create an EXE link output instead of a SYS16 output. Note also there is a "graphics window" that you're expected to open via one of the menu options if your program uses the display.
jb10320@uxa.cso.uiuc.edu (Desdinova) (10/05/90)
In article <1023@dg.dg.com> bkahn@archive.webo.dg.com (Bruce Kahn) writes: [...] >ByteWorks; they've had a busy line, so Im asking the net. Has anyone been >able to debug segmented (desktop) programs under Prizm? Any ideas (besides >cumbersome fprintf's)?? I believe that was one of the features Mike was going to add for the next version. Keep trying that number- you'll get through. And tell him you'd like to see support for your ideas. I guarantee he'll consider it. > Bruce (bkahn@archive.webo.dg.com or > kahn@adam.dg.com) > Standard disclaimers apply, except where prohibited by law... -- Jawaid Bazyar | Blondes in big black cars look better wearing Senior/Computer Engineering | their dark sunglasses at night. (unk. wierdo) jb10320@uxa.cso.uiuc.edu | The gin, the gin, glows in the Dark! | (B O'Cult) Apple II Users Unite! Storm the New Product Announcement and Demand Justice!
bkahn@archive.webo.dg.com (Bruce Kahn) (10/08/90)
In article <14027@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes: |> In article <1023@dg.dg.com> bkahn@archive.webo.dg.com (Bruce Kahn) writes: |> >Has anyone been able to debug segmented (desktop) programs under Prizm? |> >Any ideas (besides cumbersome fprintf's)?? |> |> fprintf() won't do you any good in a desktop application. I use: #ifdef DEBUG fprintf(debug_fp, "Filename = <%s>\n", replyPtr->filename); #endif This works wonders for tracking variables (globals or locals) across various modules. Granted its crude but at least you get a trail to follow and can do SOME debugging... |> |> I haven't tried exactly the scenario you describe, but I have managed |> to successfully use the ORCA debugger with ORCA/C 1.1 under other |> circumstances. Make sure the COMPILE option is set to generate debugger |> code (this consists of some COP opcodes followed by data for the |> debugger), and you may have to create an EXE link output instead of a |> SYS16 output. Note also there is a "graphics window" that you're expected |> to open via one of the menu options if your program uses the display. Can an EXE have resources in it? Since I use duplicate -d and duplicate -r to merge the forks, can I do this under prizm (apart from running my 'make' scripts in the Shell window)? I didnt think that duplicate would touch a file that was not of type S16 (I recall having to use change foo.dfork s16 after I did the link using ZapLink). Guess Ill have to peek at the sample Bullseye program to see about this 'graphics window'. -- Bruce (bkahn@archive.webo.dg.com or kahn@adam.dg.com) Standard disclaimers apply, except where prohibited by law...
jason@madnix.UUCP (Jason Blochowiak) (10/14/90)
In article <14027@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: [Deleted the referenced article] >fprintf() won't do you any good in a desktop application. On the contrary - although I would probably just use printf(). It's a matter of making a GrafOff() call, doing the printf()'ing, possibly waiting for a ReadChar(), and then doing GrafOn(). One of the other possibilities is just printf()'ing, and then using one of the CDA's that lets you look at the text screen. Btw, the text tools aren't really very supported anymore, but they're fine for debugging type stuff, as all of your debug code should be stripped out of the production code... [Also deleted the comments about the orca debugger] -- Jason B. - jason@madnix.UUCP or astroatc!nicmad!madnix!jason@spool.cs.wisc.edu I'm now working at SoftDisk, Inc. Of course, what I say is what I say, and not what they say... I will be calling this account for awhile & dealing with mail here, but I won't be calling nearly as frequently as I used to.