Strange "bug" that causes code to change

[Tom Morrison]

So...I had thought I was getting really sloppy with my editing, but it's now happened many times and I know I'm not that bad!

I have a statement "IF I + J + K > 0 THEN..." and it gets routinely (but not always) changed to "IF I = + J + K > 0 THEN..." .  Unfortunately, the altered code is syntactically correct, so it doesn't get caught when I do a "check".  However, it often shows up...but not always when I reload the program.  Am I missing something here?  I've changed the program to assign the sum of the variables to another variable that I check for > 0, but don't understand why this code changes some of the time.  I seem to recall trying to enclose the sums in parens, but it slammed the left paren against the IF and I got nervous it wouldn't be allowed.  I've just tested that and it seems OK.

Otherwise, the SolderCore is working very well in our monitoring systems.

[CoreBASIC Wizard]

On Monday, 2 December 2013 20:07:46 UTC, Tom Morrison wrote:

So...I had thought I was getting really sloppy with my editing, but it's now happened many times and I know I'm not that bad!

I have a statement "IF I + J + K > 0 THEN..." and it gets routinely (but not always) changed to "IF I = + J + K > 0 THEN..." .  Unfortunately, the altered code is syntactically correct, so it doesn't get caught when I do a "check".  However, it often shows up...but not always when I reload the program.  Am I missing something here?

Hmm, I don't know why the code would change, but hey, I take you at your word.  :-)  Which version of CoreBASIC?

 

I've changed the program to assign the sum of the variables to another variable that I check for > 0, but don't understand why this code changes some of the time.

Me neither.  Computers are usually deterministic, apart from uninitialised variables.

 

 I seem to recall trying to enclose the sums in parens, but it slammed the left paren against the IF and I got nervous it wouldn't be allowed.  I've just tested that and it seems OK.

Ahh, well, there is a heuristic for the pretty-printer.  The pretty printer does not know about the syntax of statements, nor the structure of the program.  Therefore, when it sees an opening parenthesis following a tokenised keyword it omits the space before the paren.  This is great for things like COS(X) in an expression, but not so good for IF (X+1) > 3 or PRINT (3*Y)^2.  

 

Otherwise, the SolderCore is working very well in our monitoring systems.

Well, that's good to know.  But I'd like to track down the program issue.  It's hard to say what it could possibly be, but the tokeniser is fairly complex.  It can't be the runtime that is altering the program because the runtime can't insert tokens into the token stream (that requires the program tokens to be moved about, and it doesn't do that).

There are two possibilities: the tokeniser is incorrect in some cases (and gets caught with uninitialised vars) or the token stream is incorrectly interpreted when printed.  Both of these are possibilities...  Hard to tell without a cast-iron repro case.

[Tom Morrison]

On Monday, December 2, 2013 7:52:42 PM UTC-5, CoreBASIC Wizard wrote:

On Monday, 2 December 2013 20:07:46 UTC, Tom Morrison wrote:

So...I had thought I was getting really sloppy with my editing, but it's now happened many times and I know I'm not that bad!

I have a statement "IF I + J + K > 0 THEN..." and it gets routinely (but not always) changed to "IF I = + J + K > 0 THEN..." .  Unfortunately, the altered code is syntactically correct, so it doesn't get caught when I do a "check".  However, it often shows up...but not always when I reload the program.  Am I missing something here?

Hmm, I don't know why the code would change, but hey, I take you at your word.  :-)  Which version of CoreBASIC? I'm using 1.2.28 which has proven to be rock solid except for this anomaly.

 

I've changed the program to assign the sum of the variables to another variable that I check for > 0, but don't understand why this code changes some of the time.

Me neither.  Computers are usually deterministic, apart from uninitialised variables.

 

 I seem to recall trying to enclose the sums in parens, but it slammed the left paren against the IF and I got nervous it wouldn't be allowed.  I've just tested that and it seems OK.

Ahh, well, there is a heuristic for the pretty-printer.  The pretty printer does not know about the syntax of statements, nor the structure of the program.  Therefore, when it sees an opening parenthesis following a tokenised keyword it omits the space before the paren.  This is great for things like COS(X) in an expression, but not so good for IF (X+1) > 3 or PRINT (3*Y)^2.  

 

Otherwise, the SolderCore is working very well in our monitoring systems.

Well, that's good to know.  But I'd like to track down the program issue.  It's hard to say what it could possibly be, but the tokeniser is fairly complex.  It can't be the runtime that is altering the program because the runtime can't insert tokens into the token stream (that requires the program tokens to be moved about, and it doesn't do that).

There are two possibilities: the tokeniser is incorrect in some cases (and gets caught with uninitialised vars) or the token stream is incorrectly interpreted when printed.  Both of these are possibilities...  Hard to tell without a cast-iron repro case.

I'm not sure how I can help, but I've seen this on 3 different SolderCore devices.  What's strange is that I "fix" the code and it's usually good go to.  However, if I edit the file again, it seems it might be reverted.  What's the worst thing is that the functionality changes to the new code.  This particular IF statement is used to decide if I should be sending data to a cloud service.  After I make a change to the program, I've learned I need to run it and test that the data is being pushed.  Every time I see no updates, I check and find this statement changed.  It's not that it's just being displayed differently.  I'm wondering if this could have something do to with coming out of the "edit" mode.

Let me know if there's anything I can do to help.