Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!pro-carolina.cts.com!stowekeller From: stowekeller@pro-carolina.cts.com (Stowe Keller) Newsgroups: comp.sys.apple Subject: Re: Orca/Pascal question Message-ID: <9001151702.AA19676@trout.nosc.mil> Date: 14 Jan 90 23:59:11 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 71 Re: STEIN@UCONNVM.BITNET (Alan Stein), Subject: Orca/Pascal Question > I just received the most recent upgrade for Orca/Pascal and am > finding it very flaky, especially the desktop. I wrote a very short > (@20 line) program that refused to go through the second link pass > under the desktop, but goes through without incident under the > shell. Is anyone else having that sort of problem? Yes, unfortunately, the Prizm desktop environment is very buggy, and ByteWorks readily admits this (but unfortunately shows little inclination to fix it anytime soon). Their usual advice is to use the text shell, which I usually prefer to avoid because I like most of Prizm's conceptual design. Another known bug involves using Prizm with debug code generation enabled, and compiling a Pascal program with optimize turned on: you'll often get a generic "Compiler Error" message as a result. Also, if you compile any program under Prizm with debug code generation on and then try to run the executable from the text shell, you are pretty much guaranteed to get a crash since the text shell does not know how to handle the debug code. (I think someone may have written a text shell-based debugger, but I don't know any details yet.) I recall some weird crashes with compiling certain files in the text shell and then trying to execute them under Prizm from the shell window. And other times I've had Prizm crash or hang after long sessions and for no good reason; I should point out, though, that this doesn't happen very often with Pascal, whereas it is far more common with ORCA/C, which is much more buggy (although Mike Westerfield has made tremendous progress fixing the bugs there and will be releasing ORCA/C 1.1 before too long). Other known Pascal problems according to ByteWorks: -avoid use of "byte" variables - ByteWorks recommends using integers instead until they fix the compiler. -"set" variables have problems, but I don't have any details. -The compiler apparently doesn't always catch bad parameters, as when you pass a value instead of a pointer. (Ideally the compiler would catch this as "invalid type" or whatever.) -And when writing CDA's, remember that you are limited to a 256 byte stack, which can easily be exceeded if you pass a lot of parameters and make nested subroutine calls. I, too, just upgraded from ORCA/Pascal 1.2 to 1.2.4 (or release 3 or whatever), and I've run into a strange problem: the ErrorExit and ErrorTrap sample files don't seem to work on my machine when I compile and run them (ie, no errors get trapped), yet the executables which came on the disk DO work as expected. I have no clue what might be wrong with my setup or the upgrade I performed - I've tried changing all kinds of things, making sure the library files are in alphabetical order (as required), removing all NDAs and CDAs except for the control panel, etc, and I still can't get it to work. I'm using GS/OS System 5.0.2, 2.25Meg of RAM, 7MHZ TWGS, Apple SCSI Rev C with Chinook 40Meg hard drive, one 3.5" apple drive. The person I talked to at ByteWorks was not aware of any problems like this and said they couldn't duplicate it. Anyone else run into this? Stowe Keller ------------------------------------------------------------------- Stowe Keller Author of ProDOS8 LIST utility CompuServe: 71540,725 GEnie: SKELLER BIX: stowekeller UUCP: [ sdcsvax nosc ] !crash!pro-carolina!stowekeller ARPA: crash!pro-carolina!stowekeller@nosc.mil INET: stowekeller@pro-carolina.cts.com ------------------------------------------------------------------------ Stowe Keller Author of ProDOS8 LIST utility CompuServe: 71540,725 GEnie: SKELLER BIX: stowekeller UUCP: [ sdcsvax nosc ] !crash!pro-carolina!stowekeller ARPA: crash!pro-carolina!stowekeller@nosc.mil INET: stowekeller@pro-carolina.cts.com