$IF UNDEFINED bug (solved and pushed)

[SMcNeill]

Sometimes, QB64 seems to break my brain...

Case in point, it seems as if the current version of QB64 no longer supports checking to see if a precompiler variable is defined, or not, in our code.

This used to work at some point.  I've used it in the past, and it worked.  But, it doesn't work now...

An example of the code which I'm speaking of is as simple as the following:

Code: QB64: [Select]

1. $IF X = UNDEFINED THEN
2.     $LET X = TRUE
3.     PRINT "Foo"
4. $END IF
5.  
6. $IF X = UNDEFINED THEN
7.     $LET X = TRUE
8.     PRINT "Foo"
9. $END IF

With the first $IF, X is undefined, so we should define X and print "Foo".  The second set of code shouldn't execute as the $IF value of X is defined previously...

Instead, it currently *does* execute, and anyone who uses $IF in this manner should be cautious about the glitch, until I can sort it out.  I'm starting to dig into it, but I thought I'd go ahead and warn folks about it, since it can completely destroy your code as it currently exists.

[SMcNeill]

Found the glitch -- it's down in QB64.bas where we evaluate our $IF statements, in the FUNCTION EvalPreIF (text$, err$).  Look down in the code there, and you'll see this segment:

Code: [Select]

            IF INSTR(symbol$, "=") THEN 'check to see if we're equal in any case with =
                FOR i = 0 TO UserDefineCount
                    IF UserDefine(0, i) = l$ AND UserDefine(1, i) = r$ THEN result$ = " -1 ": GOTO finishedcheck
                NEXT
                IF NOT UserFound AND LTRIM$(RTRIM$(r$)) = "UNDEFINED" THEN result$ = " -1 ": GOTO finishedcheck
                IF UserFound AND LTRIM$(RTRIM$(r$)) = "DEFINED" THEN result$ = " -1 ": GOTO finishedcheck
            END IF
The issue here is the variable UserFound... If we search all of QB64, we won't find that variable in use *anywhere*.  What the heck happened to it???  There's no way we can compare it to anything, if we never make it anything...

UserFound is supposed to be a simple little variable that says, "we found this variable in our list of user precompiler variables", or not...   Instead, it no longer exists inside QB64...

And my mind melts trying to sort out what/when/how it disappeared.  /sigh

Fix is rather simple -- swap out that small segment of code, and replace it with this one:

Code: [Select]

            IF INSTR(symbol$, "=") THEN 'check to see if we're equal in any case with =
                UserFound = 0
                FOR i = 0 TO UserDefineCount
                    IF UserDefine(0, i) = l$ THEN
                        UserFound = -1
                        IF UserDefine(1, i) = r$ THEN result$ = " -1 ": GOTO finishedcheck
                    END IF
                NEXT
                IF UserFound = 0 AND LTRIM$(RTRIM$(r$)) = "UNDEFINED" THEN result$ = " -1 ": GOTO finishedcheck
                IF UserFound = -1 AND LTRIM$(RTRIM$(r$)) = "DEFINED" THEN result$ = " -1 ": GOTO finishedcheck
            END IF
Save, recompile, and you're good to go.

I'll push changes into the repo build to make this glitch go away, so grab a fresh copy after it updates in a day or so, and $IF UNDEFINED and $IF DEFINED will work as intended for you.  If you don't want to grab a whole new version of QB64 for something so simple, just make the changes and recompile yourself.  I dunno know where UserFound disappeared off too, but it's simple enough to put it back in there so our comparisons work once again.  ;)

[Bert22306]

Don't know what I did wrong, Steve, but I entered your new code in qb64.bas, deleted the old one, recompiled, and when I test using the code in your first post, nothing prints. I was expecting to see Foo printing out, once.

[SMcNeill]

Don't know what I did wrong, Steve, but I entered your new code in qb64.bas, deleted the old one, recompiled, and when I test using the code in your first post, nothing prints. I was expecting to see Foo printing out, once.

It should.  Which version are you using — 1.2 or the Dev build?  I’m grab a fresh copy, apply the fix as here on the forums and make certain it works.  If not, I’ll dig deeper into why it’s working for me now, and what might be different with the version it’s still being stubborn with, and then I’ll report back. ;)

[Bert22306]

Okay, so I downloaded the current development build, and first tried to run your test program with the qb64.bas "as is." As expected, I got

Foo
Foo

Then I replaced that section of code like you said. In the IDE, I can now see the second $IF statement's $LET and PRINT lines grayed out, where they were not grayed out before. Cool. A hopeful sign. (Also happened with my previous development build.)

And yet, now I get no Foo output at all.

[SMcNeill]

I'll dig back into it.  Give me a few days for things to settle down here once again, and I'll report back in to you about whatever the heck is going on.  I tend to rely on this functionality for my own code, so it's something I definitely want working, so I'm not very likely to forget about it like I do some of the other glitches which pop up in QB64 from time to time.  ;)

[SMcNeill]

Try the attached version of QB64.bas, if you will, Bert.  It'll need to go into the source folder of the Development build, but I think it corrects the issue for us.  At least, with my initial testing, it has.

You can use some simple test code like the following:

Code: [Select]

$IF X = UNDEFINED THEN
    $LET X = TRUE
    PRINT "foo"
$END IF

$IF X = UNDEFINED THEN
    PRINT "foo2"
$END IF

The first set of code should be colored normally and execute.  The second set should be grayed out to indicate it's inactive, and shouldn't do anything.  Running the code should produce one "foo" on the screen for you, but not a "foo2".

If this works out the issue (finger's crossed), I'll dig into removing the changes to the windows console font next.  It's nice to be able to use QB64 to change the font size and type in the console, but the Windows calls to do so are actually quite modern.  Since we're currently compiling all the way back with Windows XP machines and such, I don't think we want to expand functionality at the expense of obsoleting QB64 on those older systems.  Console Font changes will either need to wait a few more years for people's OS's to upgrade as they replace older systems, or else I'll have to sort out a way to toggle them on and off according to the OS they're using -- and I just don't have time for that sort of thing, at the moment.  ;)

[Bert22306]

Excellent. Works fine. I even stressed it by adding more statements, and it never duplicated the output. Nice work, Steve! Thanks.

[SMcNeill]

Then I’ll push the patch into the repo later tonight/tomorrow, and folks can safely use $IF UNDEFINED/DEFINED once again. 

[SMcNeill]

Changes pushed into the Development Build. Hopefully, this will correct the issue for everyone else, as it seems to have did so for both me and Bert.  :)

[SMcNeill]

Sometimes, QB64 seems to break my brain...

Case in point, it seems as if the current version of QB64 no longer supports checking to see if a precompiler variable is defined, or not, in our code.

This used to work at some point.  I've used it in the past, and it worked.  But, it doesn't work now...

An example of the code which I'm speaking of is as simple as the following:

Code: QB64: [Select]

1. $IF X = UNDEFINED THEN
2.     $LET X = TRUE
3.     PRINT "Foo"
4. $END IF
5.  
6. $IF X = UNDEFINED THEN
7.     $LET X = TRUE
8.     PRINT "Foo"
9. $END IF

With the first $IF, X is undefined, so we should define X and print "Foo".  The second set of code shouldn't execute as the $IF value of X is defined previously...

Excellent. Works fine. I even stressed it by adding more statements, and it never duplicated the output. Nice work, Steve! Thanks.

And yet, I downloaded the repo all nice and fresh today, and...

IT DOESN'T WORK!!

Well, it kind of does...  It just works backwards!!

DEFINED and UNDEFINED are reversed from my initial testing, and I have no idea WTH is going on anymore.  My poor brain is melting...

[SMcNeill]

IT DOESN'T WORK!!

Well, it kind of does...  It just works backwards!!

DEFINED and UNDEFINED are reversed from my initial testing, and I have no idea WTH is going on anymore.  My poor brain is melting...

Scratch that.  The changes work; the internal/source folder just hasn't been updated with the proper c-version of QB64.bas yet, so running the setup script doesn't create a QB64.bas with the changes in it yet.  Take the QB64.exe that setup creates, use it to compile QB64.bas in the source folder, and the QB64(2).exe works as it should..

It's just part of the build process which hasn't caught up to all the internal changes yet which is still leaving the glitch to linger for folks who build QB64 themselves...

And here I was thinking I was going damn crazy with this!!   :P