Posts: 153
Threads: 29
Joined: Jul 2009
Reputation:
2
Have you had enough of me yet? :-D
I'm having a weird issue with ELSE, but I'm not sure if I'm doing something wrong or not. Take a look at this test program:
Code: dim num as ubyte
cls
num = 1
test()
num = 2
test()
num = 3
test()
num = 4
test ()
sub test
IF num = 1 THEN
PRINT "1"
ELSEIF num = 2 THEN
PRINT "2"
ELSEIF num = 3 THEN
PRINT "3"
ELSE
PRINT "X"
END IF
PRINT "---"
end sub
I would expect the output from this to be like this:
Code: 1
---
2
---
3
---
X
---
But it's actually like this:
Code: 1
---
2
---
3
X
---
X
---
Condition "3" is running correctly, but the final ELSE block is also being processed so you get two lines output if num is 3. Have I messed up the syntax there? The behaviour is certainly different to how it used to be, as an old program that used to be okay is now failing.
I've tried this in 2100 and also 1866 and it does the same in both, so it must've been a while since I compiled it! :-)
Posts: 1,763
Threads: 55
Joined: Aug 2019
Reputation:
24
It's another, and this one is related to the ELSEIF sentence (not very tested sorry). This is really an important one. Let me fix it... and again, thanks! :oops:
Posts: 153
Threads: 29
Joined: Jul 2009
Reputation:
2
I'll try not to find anything else today. :-D
Posts: 1,763
Threads: 55
Joined: Aug 2019
Reputation:
24
I've located the bug. But this one is harder to fix. :oops: (still working on it...)
Posts: 1,763
Threads: 55
Joined: Aug 2019
Reputation:
24
Ok, seems to be fixed now. Please, download 1.2.7-r2105, as always, from the Download page and check, please. :roll:
Posts: 153
Threads: 29
Joined: Jul 2009
Reputation:
2
Looking good! All the tests I've run so far have worked great.
Great work as usual, boriel - thanks! :-)
Posts: 1,763
Threads: 55
Joined: Aug 2019
Reputation:
24
Thanks! So should we release 1.2.7 final and go for 1.2.8 (e.g. Dynamic arrays or read/data/restore or whatever new feature?)
Posts: 153
Threads: 29
Joined: Jul 2009
Reputation:
2
I certainly don't have any more problems at the moment, and the ones I have had have been pretty obscure (apart from the -Z thing, he he). All seems good for a release from my point of view.
Posts: 1,763
Threads: 55
Joined: Aug 2019
Reputation:
24
LTee Wrote:I certainly don't have any more problems at the moment, and the ones I have had have been pretty obscure (apart from the -Z thing, he he). All seems good for a release from my point of view. Done. Latest 1.2.7 release fixes a bug with DRAW and OVER 1.
I've started 1.2.8 and, again, it will be a major code refactorization (headed towards 2.x release). In this release, I think I could introduce dynamic arrays, or probably READ/DATA/RESTORE and GOTO/GOSUB <variables>...
But currently 1.2.8 just does the same 1.2.7 does (Just rearranged yesterday some objects and files). Let's hope... it works :|
Posts: 153
Threads: 29
Joined: Jul 2009
Reputation:
2
Will download and test asap. :-)
Posts: 153
Threads: 29
Joined: Jul 2009
Reputation:
2
Everything seems to be compiling and running okay with the release 1.2.7!
Just one minor difference I can see, and I'm not sure what the implications of this are. When I compile the project that requires -Z, I now get an extra 'WARNING' from the compiler, which is this:
Code: alloc.bas:73: warning: FUNCTION 'reallocate' declared as FASTCALL with 2 parameters
The Wiki says that FASTCALL functions can only have a single parameter, and sure enough 'reallocate' in alloc.bas has two parameters. This doesn't seem to affect anything in my program, but is this a problem? I note that in the previous build the function was the same, but the warning wasn't generated. :-D
Posts: 1,763
Threads: 55
Joined: Aug 2019
Reputation:
24
LTee Wrote:Everything seems to be compiling and running okay with the release 1.2.7!
Just one minor difference I can see, and I'm not sure what the implications of this are. When I compile the project that requires -Z, I now get an extra 'WARNING' from the compiler, which is this:
Code: alloc.bas:73: warning: FUNCTION 'reallocate' declared as FASTCALL with 2 parameters
The Wiki says that FASTCALL functions can only have a single parameter, and sure enough 'reallocate' in alloc.bas has two parameters. This doesn't seem to affect anything in my program, but is this a problem? I note that in the previous build the function was the same, but the warning wasn't generated. :-D Yes, that's ok.
This is because if you're using -Z the compiler ALLOCates 21*8 = 168 bytes for UDG in the heap, and updates system variable UDG (23675) to point to that address. If you don't do this, you can surely use POKE USR "a", ... to create UDG (the legacy way), but this can corrupt the heap (which now also maps into that memory space).
Posts: 153
Threads: 29
Joined: Jul 2009
Reputation:
2
Cool, thanks for the reply. All systems are GO, then! :-)
|