rs4u#@ANDREW.CMU.EDU (Richard Siegel) (04/20/87)
This isn't a bug per se, but it is a suggestion.
I was recently writing some code that involved calls to SetResLoad().
At one point, I had a double whammy: a bug in my program while
the ResLoad global was FALSE. What happened (of course) is that the program
dies, and since ResLoad is FALSE, Lightspeed Pascal crashes when it
tries to report the error. (In this case, I got a System Error 02, presumably
becuase LSP couldn't load a dialog to report the error). I get the thumbs-
down icon in my code, but no "bug box", just a crash.
My suggestion is the following:
When LSP does a context switch from program to LSP environment,
save the program's value of ResLoad, then call SetResLoad(TRUE), so
that LSP doesn't die trying to do its thing. Likewise, restore
the program's ResLoad then switching from LSP back to the program.
This shouldn't be too terribly hard to implement, since LSP
saves lots of other stuff in context switches... And, it should prevent
system crashes when ResLoad inadvertently gets trashed, or if the
program dies while ResLoad is FALSE (which is what happened to me).
--Rich
Richard M. Siegel
Materials Characterization Instrumentation Section
Mail Stop 231
NASA/Langley Research Center
Hampton, Virginia 23665
(804) 865-3036
Arpanet: rs4u@andrew.cmu.edu
Uucp: {your fave gateway}!seismo!andrew.cmu.edu!rs4u
Disclaimer? I don't even KNOW 'er!klash@uvicctr.UUCP (Karl B. Klashinsky) (09/04/87)
I'm working on porting a Turbo Pascal Unit to LightSpeed Pascal, and I've
hit a catch. In the Turbo Unit, the high bit of an integer is set with
foo := $8000 ; {set high bit -- value is -32768}
But, LightSpeed won't accept that -- it complains that the
"constant (whose value is -32768) is out of range".
I thought that the range of ints was supposed to be -32768 to +32767.
I've tried the obvious "hacks", with no luck. For instance:
i := -32767 ;
i := i-1 ; {nope -- int overflow}
or
i := -16384 ;
i := 2 * i ; {ditto}
I don't know why (yet) but the Unit does not work properly if "foo" does not
have the high bit set.
I'm using LSP 1.0. Can anyone please help me? Will a more recent version
of LSP help?
Karl
--
Karl Klashinsky "Gee, I wish I could find a
University of Victoria neat quote to put in my
British Columbia, Canada .signature"
<me>
e-mail: {uw-beaver, ubc-vision}!uvicctr!klashflorman@randvax.UUCP (09/12/87)
> > I'm working on porting a Turbo Pascal Unit to LightSpeed Pascal, and I've > hit a catch. In the Turbo Unit, the high bit of an integer is set with > > foo := $8000 ; {set high bit -- value is -32768} > > But, LightSpeed won't accept that -- it complains that the > "constant (whose value is -32768) is out of range". > > I thought that the range of ints was supposed to be -32768 to +32767. > I've tried the obvious "hacks", with no luck. For instance: > > i := -32767 ; > i := i-1 ; {nope -- int overflow} > or > i := -16384 ; > i := 2 * i ; {ditto} > > I don't know why (yet) but the Unit does not work properly if "foo" does not > have the high bit set. > > I'm using LSP 1.0. Can anyone please help me? Will a more recent version > of LSP help? > > Karl > > -- > Karl Klashinsky "Gee, I wish I could find a > University of Victoria neat quote to put in my > British Columbia, Canada .signature" > <me> > e-mail: {uw-beaver, ubc-vision}!uvicctr!klash I too have run into this problem more than once. It stems from Lightspeed's definition of the INTEGER type being -MaxInt..MaxInt, where MaxInt = 32767. This is documented on page 19 of the reference manual, and is actually in conformance with the ANSI Standard Pascal, where the other major Pascals for the Mac are not. So Think probably considers this to be a "feature" rather than a bug. The solution is to turn off overflow checking for the offending statements with the $V compiler directive. {$V-} foo := $8000 ; {set high bit -- value is -32768} {$V+} It is interesting to note that the documentation for the $V option, on page 13-3 of the manual, erroneously states the range of INTEGER to be -32768 to +32767. This is the range for MPW, TML and Turbo, but not for Lightspeed. PS. Think has recently posted an update (version 1.1A or something) to a number of networks. I haven't seen it yet, but it may fix this problem. -- ======================================================================== florman@rand-unix.ARPA {decvax,sdcrdcf,trwrb,trwspf,vortex}!rand-unix!gnu!florman "There is no limit to the amount of good that people can accomplish, if they don't care who gets the credit." - Anonymous
palarson@watdragon.waterloo.edu (Paul Larson) (01/12/88)
I have a particularly frustrating problem wiht Lightspeed Pascal 1.0. I need advice. After compiling a program with the <command> G keystroke, but before the program is actually run, an error alert with the following text appears, "Macintosh System Error -36: I/O error(bummers)." The heading of the window which shows the progression of the compile is "Updating [project name]." If it helps, I have been working with several of the File Manager commands. What's going on? Has anyone else encountered a similar problem? Apparently, the errror occurs after the compileing, but before the code is executed. Thanx in advance, Johan Larson