timborn@ihlpg.UUCP (Tim Born) (03/25/85)
*** REPLACE THIS LINE WITH YOUR MESSAGE *** Apple Pascal has a prompt for a debugger, but no debugger. Does anyone have, or know of a debugger for Apple Pascal? I'm running into errors that are becoming increasingly obscure; I sure could use ITS or sdb about now. Any pointers appreciated. Tim Born ...ihnp4!ihlpg!ihduck
lyourk@ihlpm.UUCP (LORANY) (04/02/85)
> *** REPLACE THIS LINE WITH YOUR MESSAGE *** > Apple Pascal has a prompt for a debugger, but no debugger. Does anyone have, > or know of a debugger for Apple Pascal? I'm running into errors that are > becoming increasingly obscure; I sure could use ITS or sdb about now. > > Any pointers appreciated. > > Tim Born > ...ihnp4!ihlpg!ihduck There are a few products that may help. Two from DataMost Software, PDQ (Pascal Disk Utility) and Randy Hyde's P-source. First Byte publishes Bug Off! (tm) a Pascal Debugging System for Pascal 1.1 & 1.2. DataMost Software's stuff is more for operating system debugging and I think it has a P-Code dis-assembler. I don't know if it is updated for Pascal 1.2. Bug Off! (tm) looks like what you want, although it is probably not as powerful as sdb, it is about as good as you are going to get on a 64k Apple. It seems to have all the necessary commands and will even save the debugging environment for latter retrieval and testing. Disclammer: I have never used any of the above products and not associated with any of the above companies (except maybe for Apple since I own an Apple //e). Everything above is either a trademark or registered trademark of some company or other. And of course, nothing of this has anything to do with my employer. L. N. Yourk ihnp4!ihlpm!lyourk
timborn@ihlpg.UUCP (Tim Born) (04/03/85)
*** REPLACE THIS LINE WITH YOUR MESSAGE *** I posted a query last week asking if there was a debugger for Apple Pascal. By and large the responses were negative (some maybes, no affirmatives). I think it's evident to anyone who has used Apple's Pascal that the error messages are generally not very useful. I won't bother with the indictment. Let me propose a debugging technique that is crude but effective, and expandable. Given a procedure "X" that is compiled and linked into the buggy program, but never actually called by the program. When the OS traps an error, instead of (or in addition to) the usual "Urrp! Press any key to reset", the OS would invoke the procedure X. Presumably X has not been trashed out by the error (no guarantees on that one), and X has enough knowledge of the memory map and stack frames to perform some reasonable debugging. X can take on many forms. One that might be useful would be the proverbial "core dump" routine. To wit: X dumps the Apple's memory to a disk file for later analysis. This has several advantages: X is small; the machine will be in a sane (reset) state during the analysis; several kinds of analyzers could be used independently or together on the same core file. The analyzers could be interactive (ala sdb), or a simple stack back trace with local variables displayed (always in good taste). This is the expandable part: not only can the person-one-smarter-than-you write a useful analyzer for Apple Pascal users, but the core file could be "standardized" such that it could be transportable to others. Just think: a whole new industry of core-fixers. Just send them your core dump and a check, and poof! back comes your bug, all solved. Now for my next query. This is targeted primarily at Apple Corp. & UCSD. How can I get the OS to invoke my function "X" when it has trapped a fatal error? How can I get more details on the memory layout, stack frame and global areas in Apple Pascal? Ever Forward, tim born
allyn@sdcsvax.UUCP (Allyn Fratkin) (04/05/85)
In article <338@ihlpg.UUCP>, timborn@ihlpg.UUCP writes: > > Now for my next query. This is targeted primarily at Apple Corp. & UCSD. > How can I get the OS to invoke my function "X" when it has trapped a fatal > error? You can't. You can get the operating system to try to continue running your program (if you think it might help) by pressing <esc> at the "type space to continue" prompt. > How can I get more details on the memory layout, stack frame and > global areas in Apple Pascal? There is an Internal Architecture Guide available for version IV of the system, so there *may* be a version for II.1 (on which the Apple system is based). If it isn't available from Apple, it may be available from Softech Microsystems (619)451-1230. Make sure you don't get the guide for version IV because it is very different. I know this doesn't help much, but you could always change to UCSD p-System version IV.13 (available from Softech for a very costly price). It *does* come with a symbolic debugger and it seems pretty nice, although I don't use it. It also has a number of nice features that the Apple Pascal system doesn't have. It is also very slow on an Apple. -- From the virtual mind of Allyn Fratkin allyn@UCSD.ARPA or UCSD EMU/Pascal Project {ucbvax, decvax, ihnp4} U.C. San Diego !sdcsvax!allyn "Generally you don't see that kind of behavior in a major appliance."
timborn@ihlpg.UUCP (04/05/85)
I posted a query last week asking if there was a debugger for Apple Pascal. By and large the responses were negative (some maybes, no affirmatives). I think it's evident to anyone who has used Apple's Pascal that the error messages are generally not very useful. I won't bother with the indictment. Let me propose a debugging technique that is crude but effective, and expandable. Given a procedure "X" that is compiled and linked into the buggy program, but never actually called by the program. When the OS traps an error, instead of (or in addition to) the usual "Urrp! Press any key to reset", the OS would invoke the procedure X. Presumably X has not been trashed out by the error (no guarantees on that one), and X has enough knowledge of the memory map and stack frames to perform some reasonable debugging. X can take on many forms. One that might be useful would be the proverbial "core dump" routine. To wit: X dumps the Apple's memory to a disk file for later analysis. This has several advantages: X is small; the machine will be in a sane (reset) state during the analysis; several kinds of analyzers could be used independently or together on the same core file. The analyzers could be interactive (ala sdb), or a simple stack back trace with local variables displayed (always in good taste). This is the expandable part: not only can the person-one-smarter-than-you write a useful analyzer for Apple Pascal users, but the core file could be "standardized" such that it could be transportable to others. Just think: a whole new industry of core-fixers. Just send them your core dump and a check, and poof! back comes your bug, all solved. Now for my next query. This is targeted primarily at Apple Corp. & UCSD. How can I get the OS to invoke my function "X" when it has trapped a fatal error? How can I get more details on the memory layout, stack frame and global areas in Apple Pascal? Ever Forward, tim born
neves@uwai.UUCP (04/07/85)
> > > How can I get more details on the memory layout, stack frame and > > global areas in Apple Pascal? > A good source for the internals of Apple Pascal is "All about Pascal" published by CALL APPLE. It describes Pascal version 1.1, not 1.2. Another source I have heard about is "P-source" by Randall Hyde published by Datamost 8943 Fullbright Ave. Chatsworth, CA 91311 I have never seen P-source but an engineer at Apple once refered me to it when he couldn't answer my question. I've kind of given up on Apple Pascal. It is too slow and doesn't talk with the rest of the Apple world (i.e. PRODOS). For people who want to program in Pascal on the Apple (and do not need graphics) I recommend a 6mz Z-80 card and Turbo Pascal. The editor that comes with Turbo is so much better than the @#$% UCSD editor! Turbo seems to takes as much time to compile and start a program as Apple Pascal takes to start an already compiled program. I'm still waiting for a Pascal compiler that produces 6502 code and runs under PRODOS. Maybe the new 65C02 chip will inspire some developers.-- David Neves Computer Sciences Department University of Wisconsin-Madison Usenet: {allegra,heurikon,ihnp4,seismo,uwm-evax}!uwvax!neves Arpanet: neves@uwvax
jsdy@hadron.UUCP (Joseph S. D. Yao) (04/16/85)
> ... the core file could be > "standardized" such that it could be transportable to others. > Just think: a whole new industry of core-fixers. Just send them your core > dump and a check, and poof! back comes your bug, all solved. Gee. I'm not sure I'd want a whole bunch of Apple cores coming at me through the mail. ;-) Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}