AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (05/09/88)
Personal Notes 88.25033 by DAVE LYONS, May. 8, 1988 at 14:25 CT (5126 characters) >Date: Fri, 6 May 88 19:36:42 EDT >From: Roby Sherman <sector@pro-exchange.cts.com> >Subject: RE:Tml Pascal and BASIC!!! > >Boy.. You don't call in a week and you find you've started quite a >conspiracy.. hmmm.. Eh? >Most of the bugs I've encountered with TML Pascal were just stupid little >things that were capable of being "Worked Around" but still pains. Lately, my >main problem with the compiler is that I've been getting those damn little >error $0053 (Prodos 16 parameter exceeded) or an error $0201 Not enough >memory, not because of me, but because of the compiler. How much RAM is free when you get the $201 errors? What were you doing at the time? What were you doing when you got the $0053 error? Was TML interested in hearing about the problem; did they have any suggestions? Most importantly, what VERSION of TML do you have? >Another error encountered, involved putting a space after a begin statement, >or the routine would not work. For example, > >If I were to type : > >If A<>'Hi' Then begin > Writeln('oh my gosh!!'); > Readln; > End; > >This bug was a real variable, sometimes the routine would work, sometimes >not.. Strange.. To correct the compiler, I would have to add a space. So the >routine would look like this : > >If A<>'Hi' then begin > > Writeln('Oh my gosh!!'); > Readln; > End; >That's such a simple thing, but yet such a nuisance.. I have never had anything like that happen to me; I haven't found any problems that seem to be related to the syntax scan...blank lines shouldn't make any difference at all. >Other errors include : > >* My program would crash for no reason - I would make a modification to my >code, test it three to four times, and have it would work fine. I save the >code to disk, come back the next day it mysteriously would not work. This doesn't necessarily sound like a compiler bug, and I doubt that it is crashing for *no reason*. It actually sounds like you have some problems with some toolbox calls. There are lots of bugs that create *potential* problems and only show up some of the time. For example, leaving a handle unlocked when it should be locked; not bothering to check whether an important tool call *succeeded* (check for anything that allocates RAM, at least). >* Many programs work either much better or much worse on their own than they >do within TML's compiler. I had programs that would work fine in the compiler, >but would crash like crazy if I compiled it to disk and ran it from the >launcher. This also sounds like bugs w/ your use of some toolbox routines (as above). >* Certain laws of Pascal are not observed - I only have a 80 column printer, >so when my code starts to get over the length of 80 columns, I cut the code in >half so that it won't wrap around. Now in many Pascals I've used, they would >allow you to put a carriage return in the middle of a line, for example : > > If A<>'Hi' then > Writeln('Oh My Gosh!!'); > >And that should work.. In TML, that routine sometimes works, and other times >crashes the progam.. I do that sort of thing all the time. No problem. You seem to have *something* in your system just waiting to go wrong, so that when you change the position of stuff in RAM a bit (by adding a RETURN and a bunch of blanks or tabs to your code), things go wrong. The soltuion is to figure out what is wrong, not to give up on TML. >* Local Vars don't work so hot in big codes - The current project I'm working >on is already 89 blocks of obj code. A BIG program.. In my procedures, if I >use local variables, such as > >Procedure LoadAFile(Path:String); >Var > FileVar:Text; I haven't tried to use local FILE variables, so maybe there's a problem there. I have used local simple types, records, and arrays with no problems. >* TML doesn't use the standard APW segmentation. They don't divide their code >into the proper sized segments as specified by Apple. You mean they generate code segments bigger than 64K??? I don't understand. >* TML Pascal's and the BASIC's file routines are very buggy. Examples, please??? >* Units have problems - Many times code that use globals not within the unit >or even within the unit do not work. Again, specifically what sort of things can be problems? I'm the lucky guy who gets to write a lot of units for another guy to use in what will be a very large project eventually, so I want to know what to avoid or at least look out for. >Roby Sherman >Interealm > >UUCP: [ ihnp4 cbosgd nosc ] !crash!pnet01!pro-sol!pro-exchange!sector >ARPA: crash!pnet01!pro-exchange!sector@nosc >INET: sector@pro-exchange.cts.com (Disclaimer--I have no connection with TML Systems other than as a [somewhat] satisfied customer.) --David A. Lyons a.k.a. DAL Systems PO Box 287 | North Liberty, IA 52317 BITNET: AWCTTYPA@UIAMVS CompuServe: 72177,3233 GEnie mail: D.LYONS2 Kept Notes "NET INFO APPLE" by DOUG BRENNER, Aug. 29, 1987 at 19:49 CT (3547 notes) 3500 (of 3547) MAIL_RELAY May. 7, 1988 at 8:19 CT (5791 characters) Received: by NDSUVM1 (Mailer X1.25) id 4439; Sat, 07 May 88 08:16:40 CDT Date: Fri, 6 May 88 19:36:42 EDT Reply-To: pnet01!pro-sol!pro-exchange!sector@nosc.mil Sender: INFO-APP Info-Apple List <INFO-APP@NDSUVM1> From: Roby Sherman <sector@pro-exchange.cts.com> Subject: RE:Tml Pascal and BASIC!!! Comments: To: info-apple@BRL.ARPA To: WCC Participate Redistribution <WAPPLEPB@UIAMVS> Boy.. You don't call in a week and you find you've started quite a conspiracy.. hmmm.. Anyway.. Most of the bugs I've encountered with TML Pascal were just stupid little things that were capable of being "Worked Around" but still pains. Lately, my main problem with the compiler is that I've been getting those damn little error $0053 (Prodos 16 parameter exceeded) or an error $0201 Not enough memory, not because of me, but because of the compiler. Another error encountered, involved putting a space after a begin statement, or the routine would not work. For examp{le, If I were to type : If A<>'Hi' Then begin Writeln('oh my gosh!!'); Readln; End; This bug was a real variable, sometimes the routine would work, sometimes not.. Strange.. To correct the compiler, I would have to add a space. So the routine would look like this : If A<>'Hi' then begin Writeln('Oh my gosh!!'); Readln; End; That's such a simple thing, but yet such a nuisance.. Other errors include : * My program would crash for no reason - I would make a modification to my code, test it three to four times, and have it would work fine. I save the code to disk, come back the next day it mysteriously would not work. * Many programs work either much better or much worse on their own than they do within TML's compiler. I had programs that would work fine in the compiler, but would crash like crazy if I compiled it to disk and ran it from the launcher. * Certain laws of Pascal are not observed - I only have a 80 column printer, so when my code starts to get over the length of 80 columns, I cut the code in half so that it won't wrap around. Now in many Pascals I've used, they would allow you to put a carriage return in the middle of a line, for example : If A<>'Hi' then Writeln('Oh My Gosh!!'); And that should work.. In TML, that routine sometimes works, and other times crashes the progam.. * Local Vars don't work so hot in big codes - The current project I'm working on is already 89 blocks of obj code. A BIG program.. In my procedures, if I use local variables, such as Procedure LoadAFile(Path:String); Var FileVar:Text; The procedure would lock, causing me to reboot.. This problem persisted until I made FileVar a global variable... Strange! * TML doesn't use the standard APW segmentation. They don't divide their code into the proper sized segments as specified by Apple. * TML Pascal's and the BASIC's file routines are very buggy. * Units have problems - Many times code that use globals not within the unit or even within the unit do not work. * Overall, the TML Pascal is very buggy.. --------------------------------------------------------------------------- T M L B A S I C P R O B L E M S * Routines would spew out hash! - I wrote a complex little program that broke a string into individual characters, checked the characters for certain values, pull information from an array, and stuck all this information back into one sting.. Cute, huh? This routine worked in BASIC, ZBASIC, GSBASIC, but not TML BASIC, now I ask you. Does that sound like TML or me? For example if a line read : @027 is @006 time.. @0027 is @006 best time.. My routine would change it too : Now is the time.. Now is the best time.. But in TML BASIC, depending on A:How big my stack was, B:If I had the Ctrl-C mode on, C:If I had my cache on, D:If I had the debugger on, it would or not work.. A lot of different variables to sift through, eh? TML, for example would take this line and present a line of this nature : N#$% time.. Now %$ is the Ruinxxxx time... and then crash., The hash is really much worse than my example.. ------------------------------------------------------------------------ TML's support I took this BASIC problem and sent it to TML where Cliff, one of the tech people there told me that it was up to ME to isolate the problem, because he "Doesn't have time to do it." Gee, I thought that was his job... ------------------------------------------------------------------------ TML BASIC bugs continued : Try these two programs and see some cute bugs : GRAF INIT 320 GRAF ON _SetForeColor(0) _SetBackColor(15) Input "Watch the cursor leave a trail!!";A$ END Hmmm.... With the same routine, try typing something, using the DELETE key or the LEFT arrow.. Cute, hmmm??? Here's a (very) small portion of the s*it I've been taking with these products. You guys found any others?? --------------------------------------------------------------------- A Proposed Solution With AppleFest approaching, let's do this.. I think I'm going to find all of the people with chains, nouses, lead pipes, etc. that come to the show to go after the Zip Chip guys, and yell something like, Hey TML Systems helped them take our money! And have those TMLm beat up on those TML guys, too!! Heh heh heh!! Roby Sherman Interealm UUCP: [ ihnp4 cbosgd nosc ] !crash!pnet01!pro-sol!pro-exchange!sector ARPA: crash!pnet01!pro-exchange!sector@nosc INET: sector@pro-exchange.cts.com "Hey Apple! I want blitter hardware!!!!!!" -- An irate IIGS owner! "NET INFO APPLE" by DOUG BRENNER, Aug. 29, 1987 at 19:49 CT (3547 notes) 3515 (of 3547) MAIL_RELAY May. 7, 1988 at 10:50 CT (1145 characters) Received: by NDSUVM1 (Mailer X1.25) id 5321; Sat, 07 May 88 10:47:52 CDT Date: Thu, 5 May 88 18:31:08 GMT Reply-To: Info-Apple@BRL.ARPA Sender: INFO-APP Info-Apple List <INFO-APP@NDSUVM1> Comments: Warning -- original Sender: tag was info-apple-request@BRL.ARPA From: "A. Flora-Holmquist" <ihnp4!ihlpl!nala@ucbvax.berkeley.edu> Subject: APW C debugging question Comments: To: info-apple@BRL.ARPA To: WCC Participate Redistribution <WAPPLEPB@UIAMVS> I am a new IIgs programmer and purchased the APW shell, C compiler, and APW debugger. The debugger is a machine level debugger, the C compiler to the best of my reading does not/will not produce an assembly listing. If I need to debug a C program it appears that sprinkling DrawCString in the code is my only choice. Have I missed something obvious in the APW documentation that addresses debugging C programs with the APW debugger? Any hints? It seems so obvious that a compiler should support some debugger that I can't believe the APW C compiler/APW debugger combination is useless. Thanks for the help. Al Flora-Holmquist ihnp4!ihlpl!nala 88.24920 by MAIL_RELAY, May. 7, 1988 at 9:38 CT (2050 characters) Received: from CUNYVM by CUNYVM.BITNET (Mailer X1.25) with BSMTP id 7123; Sat, 07 May 88 10:37:07 EDT Received: from Think.COM by CUNYVM.CUNY.EDU (IBM VM SMTP R1.1) with TCP; Sat, 07 May 88 10:37:02 EDT Return-Path: <whitney@Think.COM> Received: from godot.think.com by Think.COM; Sat, 7 May 88 09:56:16 EDT Received: by godot.think.com; Sat, 7 May 88 09:56:10 EDT From: whitney@Think.COM Message-Id: <8805071356.AA17545@godot.think.com> To: David A. Lyons <AWCTTYPA%UIAMVS.BITNET@cunyvm.cuny.edu> Subject: Re: Z-Link works at 9600 In-Reply-To: Your message of Fri, 06 May 88 11:32:00 T. <8805061744.AA15310@Think.COM> Date: Sat, 07 May 88 09:56:08 EDT STUDY FOR YOUR FINALS!!! There. how's that? re VT100: There have got to be piles and piles of bugs in my emulation - I had to almost guess everything it does. I have a sheet with a list of codes and a very brief description of what the code does. eg: ESC [ t;b r sets the scrolling region That descrip is almost useless. It doesn't say if t is the line above the top scrollable or if t *is* the top scrollable... It also failed to mention that the host expects the terminal to place the cursor in the top-left of the screen (not the scroll region!). Until I can get a *real* spec for ANSI terminals, I can't write a reliable emulator. Such is life. -- I've been mucking about with save/load terminal settings. The file is stored as a VAR file ($fd) and it does type-checking when loading as well as content verifying (first few bytes have to be $60 "Z-Link"). My only problem now is initial startup of Z-Link without a settings file present on the disk. It is supposed to try to open the file Z.LINK.CONFIG. If it gets an error, it is supposed to just quit (instead of reporting the error FILE NOT FOUND). Well, the error isn't caught (I can't figure out why) and Z-Link promptly declares that the file I tried to open wasn't a proper settings file! It's driving me up the wall! Oh well. I'll get it somehow! oh yeah - STUDY FOR YOUR FINALS! Dave
cc@xroads.UUCP (Dan McGuirk) (05/11/88)
Roby Sherman writes: >[about having problems that would occur on and off, and could be corrected by just changing the program around a little] I also use TML Pascal, v1.00B, and I have had problems with the editor just freezing up sometimes. On a modified version of the GSDemo program, the editor seemed to freeze every time that I scrolled past the first line that was defining global variables. I loaded the source into a different editor, changed the line, and then loaded it into TML Pascal again. It worked fine a couple of times, but then it started freezing up again, this time at a different line every time. I've sent in my original for an update, and I'm hoping that this will fix the problem.. Dan ..ihnp4!crash!xroads!cc -- \ / C r o s s r o a d s C o m m u n i c a t i o n s \/ (602) 971-2240 /\ (602) 992-5007 300|1200 Baud 24 hrs/day / \ ihnp4!crash!xroads!*