Report Bugs Here

Moderator: Mmiscool

User avatar
By Electroguard
#56605 I think there are effectively 2 bugs hiding in the same place!

When I think about it, the rules seem fairly obvious and common-sense:

"Text inside quotes is intended to be treated as quoted text"

Unrecognised text outside of quotes is only acceptable when creating a new 'variable = value' statement.

An appropriate '=' assignment operator is an essential pre-requisite for variable creation or modification.

So obviously a bug must exist if it can create new variables from unquoted text that doesn't even have an accompanying '=' to assign any value (even if the value might be empty or nul).
But considering there is no '=' to assign any value, a second hidden bug is the worst, because rather than just creating an empty variable, it populates variables with an echo of the unquoted text, thereby creating a text variable as a fait accompli.

If the first 'undeclared variable creation' bug just created an empty "" variable it might be managed with 'if variable=""' which could be responded to as appropriate, but the second hidden 'echoed contents' bug causes the unwanted populated variables to become text whether you like it or not.

I don't suppose many other people are using 525 line scripts and scores of potential variables yet... but as the uses and capabilties of Esp_Basic grows, so too will the script sizes, number of variables used, and the complication of variables usage - so I think the above bug(s) will impose constraints on any future growth and real-world use of ESP_Basic, even though no-one else is bothered by the bug at the moment.

So I expect it's going to need looking into and resolving eventually, therefore the best I can do is offer detailed info which might be considered relevent or useful now or later, even though that just makes me seem like a noisy annoyance most of the time. If my comments lead to improvements then I can feel I've been able to usefully contribute in a small way, and if they are ignored then at least I'll know I've done my best - even though that then means looking for some convoluted way around any remaining problems I have.

In this case it should be possible to treat all variables as text then convert any (such as udpport etc) to or from numeric whenever necessary, but that's a lot of unwelcome aggro, so I'll hold off for a few days in case a fix is issued. I suspect it might be quite easy to change the bug2 code so that it filled bug1's empty variables with empty "" data rather than echoing in the name text, but unfortunately I am not a programmer and don't have the 'smarts' to do anything useful myself, so I can only point things out for a wizard to magic up if considered appropriate.
User avatar
By Oldbod
#56619 I'm going to sound really nit-picky here, but it's common practice to create variables without using an explicit "=". Though usually there is an implied "=" - as in, dim an array of strings, you'd expect the array to be populated with empty strings. Numeric variables, all 0. I think that probably with the key aim of keeping it simple there's not much documentation on how espbasic variables work.

It's surprisingly hard to build 100% solid rules to analyse the text file that is a program.

I haven't tried to get to the bottom of this, but I'm wondering if the way some element of variable handling has changed for performance reasons and somehow a bug has slipped in. I don't speak C++ or any form of C but I've looked at the source code in the past using the arduino.cc ide and the ide is not exactly overburdened with developer-assisting features (that I've found anyway, there may be loads). That sounds very unfair, as the writers have done a great job in getting it to work for arduino and then esp, and I suspect that c may be not very easy to create an ide for, if you see what I mean.

I think you do yourself a disservice to say you're not a programmer....
User avatar
By Electroguard
#56631 I just had a worrying thought - perhaps the same bug similarly creates unwanted populated variables in flash also!

I've noticed Mmiscool has recently created a DEL.DAT() command for removing an element from flash memory, but perhaps we also need some form of flash VARS dumo to be able to see what is there.

Because the snippet below could be filling up flash with unwanted variables populated with cloned name data - and to my knowledge there is no way of checking what variables exist... hence the need for the code snippet in the first place.


Code: Select all[READVARS]
tmp = read("Title")
if tmp <> "" then title = tmp
tmp = read("Name")
if tmp <> "" then localname = tmp
tmp = read("Global")
if tmp <> "" then globalname = tmp
tmp = read("Group")
if tmp <> "" then groupname = tmp
tmp = read("Description")
if tmp <> "" then description = tmp
tmp = read("Opmode")
if tmp <> "" then opmode = tmp
tmp = read("Debugmode")
if tmp <> "" then debugmode = tmp
tmp = read("Buttonmode")
if tmp <> "" then buttonmode = tmp
tmp = read("Voicemode")
if tmp <> "" then voicemode = tmp
tmp = read("UDPport")
if tmp <> "" then udpport = val(tmp)
tmp = read("Ondelay")
if tmp <> "" then ondelay = val(tmp)
tmp = read("Offdelay")
if tmp <> "" then offdelay = val(tmp)
tmp = read("Onduration")
if tmp <> "" then onduration = val(tmp)
tmp = read("Offduration")
if tmp <> "" then offduration = val(tmp)
tmp = read("Blinks")
if tmp <> "" then numblinks = val(tmp)
return
User avatar
By Mmiscool
#56671 when using the read function you can request it as a value.
It will return 0 if the data element dose not exist.

bla = read.int("myddata")