gft_robert@gsbacd.uchicago.edu (10/18/89)
I'm writing a somewhat tricky text-processing XFCN of about 500 lines and I need some hints about how to debug XFCN's in general. The XFCN makes almost no ROM calls, so it's hard to see how far I've gotten in it before it crashes (which it does). I'm using THINK Pascal. Is there any way that one can use the source-level debugger when writing XFCN's? I doubt it very much, but just thought I'd ask. Would HyperTMON (which I've never seen) be of any help at all? If I were doing it with MPW Pascal/TML Pascal, would it be possible to use SADE? Failing that, what are the tricks you use when debugging complicated XFCN's? Do you write out diagnostic info to the HyperCard screen? As a last resort, how would one go about debugging it from the machine level (MacsBug, etc.). I ask, because I'm not sure about the low-level interaction between my XFCN and HyperCard itself, and want to know what I should expect to be seeing. Any info much appreciated! Robert ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = crsp_ra@gsbacd.uchicago.edu * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
dan@lclark.UUCP (Dan Revel) (10/19/89)
From your description I would say that your best bet would be to debug your code *before* making it into an XCMD/XFCN. You could even mock-up a program which calls your routine the way Hypercard would. Of course this won't work if you intend to make call-backs or pass messages to Hypercard. -- dan@lclark tektronix!reed!lclark!dan Dylsexics untie! (-|
mjm@eleazar.dartmouth.edu (Michael McClennen) (10/20/89)
In article <5870@tank.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: >I'm using THINK Pascal. Is there any way that one can use the source-level >debugger when writing XFCN's? I doubt it very much, but just thought I'd ask. >Would HyperTMON (which I've never seen) be of any help at all? If I were doing >it with MPW Pascal/TML Pascal, would it be possible to use SADE? The only way to use a source level debugger when writing an XCMD is to compile the code as an application first (you can also write a simple application shell which calls your XCMD code in the same way HyperCard would). The problem with this, of course, is that you can't debug any of the interaction between your code and HyperCard (callbacks, messages, etc.) HyperTMON is a HyperTalk script debugger, and is of no use for XCMDs. >Failing that, what are the tricks you use when debugging complicated XFCN's? >Do you write out diagnostic info to the HyperCard screen? > >As a last resort, how would one go about debugging it from the machine level >(MacsBug, etc.). I ask, because I'm not sure about the low-level interaction >between my XFCN and HyperCard itself, and want to know what I should expect to >be seeing. I have written many complicated XCMDs, and do most of my debugging using TMON. Unfortunately, one has to modify the TMON user area a bit to get it to recognize addresses in your code, but if you don't mind a little inconvenience this doesn't matter. The low-level interaction between your XFCN and HyperCard is simply a matter of a subroutine call to HyperCard for each callback. If you are using the standard glue library, you don't have to worry about this at all. You will notice calls to the glue routines in your code, and merely have to keep track of their arguments and return values. Of course, examining the arguments passed to you by HyperCard and the result you give back is simply a matter of looking at the parameter block. Other than these, you will see standard Macintosh non-application code, and the fact that it happens to have been loaded into memory and called by HyperCard matters not a whit. Michael McClennen mjm@dartmouth.edu Dartmouth College Academic Computing
gft_robert@gsbacd.uchicago.edu (10/20/89)
In article <717@lclark.UUCP>, dan@lclark.UUCP (Dan Revel) writes... >From your description I would say that your best bet would be to >debug your code *before* making it into an XCMD/XFCN. You could >even mock-up a program which calls your routine the way Hypercard >would. Of course this won't work if you intend to make call-backs >or pass messages to Hypercard. That's indeed the problem: I'm using a lot of callbacks. Oh well. ============================================================================ = gft_robert@gsbacd.uchicago.edu * generic disclaimer: * "It's more fun to = = crsp_ra@gsbacd.uchicago.edu * all my opinions are * compute" = = * mine * -Kraftwerk = ============================================================================
tom@iconsys.UUCP (Tom Kimpton) (10/31/89)
In article <5870@tank.uchicago.edu> gft_robert@gsbacd.uchicago.edu writes: > >As a last resort, how would one go about debugging it from the machine level >(MacsBug, etc.). I ask, because I'm not sure about the low-level interaction >between my XFCN and HyperCard itself, and want to know what I should expect to >be seeing. > Not knowing what's available in Pascal, here's what I do in C: (I hope you know C :-) { char dbug[256]; dbug[0] = sprintf(&dbug[1],"formatting and debug info",args); DebugStr(dbug); } Putting this into your code will drop you into the machine level debugger, with the string being printed out. Again not knowing Pascal, but XCFN/XCMD's compiled with the MacsBug symbols option (LSC&TC) on will retain their symbols when installed in hypercard and MacsBug will show symbolic offsets. Hope this helps. -- Tom Kimpton UUCP: {uunet,caeco,nrc-ut}!iconsys!tom Software Engineer INTERNET: tom@iconsys.uu.net Icon International, Inc. BITNET: icon%byuadam.bitnet (multi-user acct) Orem, Utah 84058 PHONE: (801) 225-6888