slviajero / tinybasic

A BASIC interpreter for Arduino, ESP, RP2040, STM32, Infineon XMC and POSIX with IoT and microcontroller features.
GNU General Public License v3.0
205 stars 32 forks source link

DIM with floating point arrays #41

Closed RonLinu closed 1 year ago

RonLinu commented 1 year ago

Hi Stefan, defining the upper limit of a floating point array (compiled with #define BASICFULL or BASICHASFLOAT) may not always lead to the correct initialisation of the array.

10 CLR 20 DIM P(20) 30 PRINT P(19)

At line 30, it will raise "Range Error". It should print zero or an undefined value, not a range error. It could be solved, apparently, by assigning a value before printing like: 25 P(19) = 0

I discover this by accident when trying PRIMES.BAS in the examples. Using the following code to clear an array does not fix the problem: DIM P(N) FOR X=1 to N: P(N) = 0: NEXT

Note: this is NOT an issue with an integer array.

Tested on Arduino Mega2560.

slviajero commented 1 year ago

Hi Ron,

I just tried this with the actual code (the one now in the repo) and I could not reproduce the error on an Mega2560.

There is however, a little pitfall with the primes.bas program itself. This happens, when I create 100 primes, then end then program and then try to print an array element

... 97 509 98 521 99 523 100 541 How many primes (0=stop)? 0

print p(19) Range Error

It happens because the primes.bas program does CLR before it prompts for new input.

200 CLR 210 INPUT "How many primes (0=stop)? ",N 220 IF N=0 THEN 500

The array is deleted. When you then do print p(19) at the command line, you autocreate a new array with size 10, which is empty and P(19) does not exist.

Can it be that you did this by accident? If not, can you check with the newest code?

I will check with more examples myself. The heap code is at the core of everything. If there is a bug in it, it would be pretty serious.

Best, Stefan

Am 19.12.2022 um 21:59 schrieb RonLinu @.***>:

Hi Stefan, defining the upper limit of a floating point array (compiled with #define BASICFULL or BASICHASFLOAT) may not always lead to the correct initialisation of the array.

10 CLR 20 DIM P(20) 30 PRINT P(19)

At line 30, it will raise "Range Error". It should print zero or an undefined value, not a range error. It could be solved, apparently, by assigning a value before printing like: 25 P(19) = 0

Then again, it does not always work. Using the following code to clear an array does not fix the problem: DIM P(N) FOR X=1 to N: P(N) = 0: NEXT

I discover this by accident when trying PRIMES.BAS in the examples. Tested on Arduino Mega2560.

— Reply to this email directly, view it on GitHub https://github.com/slviajero/tinybasic/issues/41, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACSY56HFNTFKGQZHZSJAXMLWODECBANCNFSM6AAAAAATDY3C5U. You are receiving this because you are subscribed to this thread.

RonLinu commented 1 year ago

Ok I found the culprit.

Your feedback led me to try the latest AppImage of Arduino IDE 2.0.x from Arduino web site. Now the code runs fine.

I was previously using Arduino IDE 1.8.19 from Arch AUR, on EndeavourOS (dated sept 2022) and it seemed quite fine so far. Obviously, a library is incorrect in the package. I will report this issue to the AUR packager.

Sorry about that!

You can relax. No heap management catastrophe :) Ron

RonLinu commented 1 year ago

I have rechecked with some other BASIC programs along with some experiments of my own. It's ok as far as I can test on my Arduino hardware.

The AUR can be extremely usefull but can be a bummer sometime as I just discovered.

Ron

slviajero commented 1 year ago

Great, I am relieved.

As to the library and software problem in general: I gave a presentation recently to a group of young developers and was asked about learnings from my projects. The key message I gave was to beware of libraries, in particular the very popular and common ones for Arduino. I found countless bugs and design flaws in them. At the moment I invest a lot of times to remove libraries from the BASIC code precisely for this reason. The Picoserial is gone, the real time clock as well and also the I2C EEPROM code is rewritten from scratch. All of these features are no part of hardware-arduino.h without the use of any additional library. Currently I am at the PS2 keyboard part. This is a good library but better don’t look at the interrupt code. It is super outdated and not portable at all. Equally terrible are the graphics things from Adafruit.

Best, Stefan

Am 20.12.2022 um 16:08 schrieb RonLinu @.***>:

I have rechecked with some other BASIC programs along with some experiments of my own. It's ok as far as I can test on my Arduino hardware.

The AUR can be extremely usefull but can be a bummer sometime as I just discovered.

Ron

— Reply to this email directly, view it on GitHub https://github.com/slviajero/tinybasic/issues/41#issuecomment-1359536088, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACSY56HFTZDVHNJH7HTSN5LWOHDXFANCNFSM6AAAAAATDY3C5U. You are receiving this because you commented.

RonLinu commented 1 year ago

I suspected that much about some Arduino libraries.

Have a nice day!