mbabramowicz@amherst.bitnet (01/26/91)
I've encountered a really weird bug in Lightspeed Pascal 2.03, I think. I was able to get around it, and for all I know it may have been corrected in later versions, but I thought I'd mention it anyway. Basically, the line: rndEndBeep := not rndEndBeep failed to work. That is, before the line was executed (I put a stop on it and watched the variable via LightsBug), the value was TRUE. After the line executed, the value was still TRUE. This happened a number of times without working succ- essfully. Incidentally, rndEndBeep is a boolean variable (of course), and I had several other similar statements that worked fine. Some of these were even in the same "case" construct. You're probably skeptical right now that I didn't do something stupid. But I'm quite sure it is a bug, first of all, because debugging it, I was able to see that the line executed but did not change the variable. Secondly, when I changed a variable declaration so that two boolean var- iables listed separately were listed together soundOn, rndEndBeep : BOOLEAN; then my program worked fine. Weird... has anyone else had this happen? Does Symantec know about this? Has it been fixed in LSP 3.0? I ask these questions out of curiousity only, since it no longer affects me. Michael Abramowicz
nortond@lonexb.radc.af.mil (Douglas A. Norton) (01/31/91)
>> booleanVar:= not booleanVar doesn't work???
Sure it does I use it all the time...I think the problem you are
having is caused by a boolean not being initialized correctly. You
must make sure that the booleanVar is a valid TRUE or FALSE then
it will work. I've seen this problem before when I allocate a
record with a boolean in it and I don't initialize the booleanVar
to TRUE or FALSE.
I hope this helps...
Doug Norton
Rome Laboratory
nortond@lonex.radc.af.milmurat@farcomp.UUCP (Murat Konar) (02/11/91)
In article <11749.27a0a4c2@amherst.bitnet> mbabramowicz@amherst.bitnet writes: >I've encountered a really weird bug in Lightspeed Pascal 2.03, I think. >I was able to get around it, and for all I know it may have been corrected >in later versions, but I thought I'd mention it anyway. > >Basically, the line: > rndEndBeep := not rndEndBeep >failed to work. You think that's weird, occasionally I have problems with Booleans where Lightsbug says a variable is FALSE but the Observe window says it's TRUE. That's a head scratcher. This is also LSP 2.03. I haven't tried it in 3.0. -- ____________________________________________________________________ Have a day. :^| Murat N. Konar murat@farcomp.UUCP -or- farcomp!murat@apple.com
siegel@endor.uucp (Rich Siegel) (02/14/91)
In article <297@farcomp.UUCP> murat@farcomp.UUCP (Murat Konar) writes: > >You think that's weird, occasionally I have problems with Booleans where >Lightsbug says a variable is FALSE but the Observe window says it's TRUE. >That's a head scratcher. This is also LSP 2.03. I haven't tried it in >3.0. Uninitialized Booleans can be both false and true; LightsBug thinks that any non-1 value is false, and Observe gets somewhat confused with non- zero, non-one values. The bug is fixed in LightsBug; any non-zero, non-one Boolean will be shown as "True?". The fix will show up in a future version. R. Rich Siegel Symantec Languages Group Internet: siegel@endor.harvard.edu "I was just trying to be subtle. That's my job, isn't it?"
calvin@portia.stanford.edu (Peter Chang) (02/15/91)
In article <5725@husc6.harvard.edu> siegel@endor.uucp (Rich Siegel) writes: >In article <297@farcomp.UUCP> murat@farcomp.UUCP (Murat Konar) writes: >> >>You think that's weird, occasionally I have problems with Booleans where >>Lightsbug says a variable is FALSE but the Observe window says it's TRUE. >>That's a head scratcher. This is also LSP 2.03. I haven't tried it in >>3.0. I think that in 3.0 all variables are set to 0 upon declaration, if they can be that is. Peter
siegel@endor.uucp (Rich Siegel) (02/16/91)
In article <1991Feb15.092414.1528@portia.Stanford.EDU> calvin@portia.stanford.edu (Peter Chang) writes: > > I think that in 3.0 all variables are set to 0 upon declaration, if >they can be that is. Only global variables are guaranteed to be initialized to zero at program startup. Locals will have whatever values happen to lie inside of the stack frame when the procedure is called. R. Rich Siegel Symantec Languages Group Internet: siegel@endor.harvard.edu "I was just trying to be subtle. That's my job, isn't it?"