Thanks for the update! It is great that it works better than before. However, remember that I uploaded the USRMAN25.BAS program in this thread below? With this new version the program is no longer able to save and load the data file that it uses properly. The command "PRINT ERR,ERL" shows that error 14 (Out of string space) occurs in line 170 and 1480. Note that this error did not occur with release 15.08.3. https://sourceforge.net/p/pcbasic/discussion/general/thread/cd3374af/?page=1
Wengier
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also, the CLOCK program does not work properly with this version. It results in the "Out of memory in 190" error, which did not occur with release 15.08.3. I believe I had uploaded the program somewhere in the forum before too, but since I can't find it I am uploading it again.
Thanks. I suspect the issue with CLOCK.BAS is related to the fix of recursive FN calls, as a rexcursive call should give an Out of Memory error. However, the FNANG call is obviously not recursive, so will check why it triggers the error.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Wengier, the issue with CLOCK.BAS has been found and solved for the .5 release. I'm hoping to push that out a bit quicker as .4 took too long.
The issue with USRMAN25.BAS is more complicated, it's actually quite surprising that it worked before. The problem is caused because PC-BASIC maps all strings to memory locations and throws an error if the emulated memory is full. However, in GW-BASIC, strings defined as literals in the program code are not stored separately in memory, but are rather kept as a pointer to the program code. Therefore, all the strings in DATA commands in your program will take up string space in PC-BASIC but not in GW-BASIC.
It's a problem that I've noticed before in a different context, but solving it properly is likely to require a substantial rewrite of how I'm dealing with strings. Which needs to happen at some point anyway, it's just not clear it can be done for a minor update or will need to be part of the next major update. Unfortunately the latter has been much delayed due to lack of spare time.
Bottom line is, it will be solved but it may take a while. (Reverting the change that caused it would make USRMAN25.BAS work, so I'll probably do that for now, but it's not a proper solution. Other programs would fail even without the change.)
Thanks again for reporting the bug!
Rob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all, I've uploaded release 15.08.4.
This update brings the following improvements:
PRINT ***,STRING$(7),VAL("--1"), recursiveFNcalls,BLOADinSCREEN 6,PRINT (-1)^0.5\,MOD,EQVandIMPoperators for negative operandsKEY 1, ""andKEY 1, chr$(0)switch off key macroAUX,CON,PRNandNULCLEAR.READ AandINPUT AThanks to all bug reporters, you know who you are!
Rob
Thanks for the update! It is great that it works better than before. However, remember that I uploaded the USRMAN25.BAS program in this thread below? With this new version the program is no longer able to save and load the data file that it uses properly. The command "PRINT ERR,ERL" shows that error 14 (Out of string space) occurs in line 170 and 1480. Note that this error did not occur with release 15.08.3.
https://sourceforge.net/p/pcbasic/discussion/general/thread/cd3374af/?page=1
Wengier
Also, the CLOCK program does not work properly with this version. It results in the "Out of memory in 190" error, which did not occur with release 15.08.3. I believe I had uploaded the program somewhere in the forum before too, but since I can't find it I am uploading it again.
Wengier
Thanks. I suspect the issue with CLOCK.BAS is related to the fix of recursive FN calls, as a rexcursive call should give an Out of Memory error. However, the FNANG call is obviously not recursive, so will check why it triggers the error.
Hi Wengier, the issue with CLOCK.BAS has been found and solved for the .5 release. I'm hoping to push that out a bit quicker as .4 took too long.
The issue with USRMAN25.BAS is more complicated, it's actually quite surprising that it worked before. The problem is caused because PC-BASIC maps all strings to memory locations and throws an error if the emulated memory is full. However, in GW-BASIC, strings defined as literals in the program code are not stored separately in memory, but are rather kept as a pointer to the program code. Therefore, all the strings in DATA commands in your program will take up string space in PC-BASIC but not in GW-BASIC.
It's a problem that I've noticed before in a different context, but solving it properly is likely to require a substantial rewrite of how I'm dealing with strings. Which needs to happen at some point anyway, it's just not clear it can be done for a minor update or will need to be part of the next major update. Unfortunately the latter has been much delayed due to lack of spare time.
Bottom line is, it will be solved but it may take a while. (Reverting the change that caused it would make USRMAN25.BAS work, so I'll probably do that for now, but it's not a proper solution. Other programs would fail even without the change.)
Thanks again for reporting the bug!
Rob