QB64.org Forum

Active Forums => QB64 Discussion => Topic started by: TempodiBasic on April 12, 2021, 05:58:56 pm

Title: It seems that I have found another bug/issue of QB64 1.5
Post by: TempodiBasic on April 12, 2021, 05:58:56 pm
Hi
I was playing with our QB64 when I got this error
see here
  [ This attachment cannot be displayed inline in 'Print Page' view ]  
can you make your try using this code?

Code: QB64: [Select]
  1. if m < 10 then d = d + "0" + Ltrim$(m)
To be clear the parser launches a warning about the argument of Ltrim$ but nothing about adding a STRING to a SINGLE variable.
Moreover look at the warning launched by parser... do you see that ",1" ???
Welcome feedbacks
Title: Re: It seems that I have found another bug/issue of QB64 1.5
Post by: bplus on April 12, 2021, 07:09:26 pm
I think it is complaining that m is by default single, not a string.

WTH there is so much wrong with that.... LOL
Title: Re: It seems that I have found another bug/issue of QB64 1.5
Post by: FellippeHeitor on April 12, 2021, 07:22:34 pm
The parser will catch one error at a time. When you fix the error of passing a number to LTrim$, then the IDE will point out the next error.

The ,1 in the error message in the length of the literal string "0". Try changing it to "zero" and you will see "zero",4 in the status bar.
Title: Re: It seems that I have found another bug/issue of QB64 1.5
Post by: TempodiBasic on April 13, 2021, 06:11:23 pm
@FellippeHeitor 
ok so I have learned that or QB64 parser goes from right to left of line of code or QB64 parser uses a list to choose in what order analyze the line of code.
Thanks
Title: Re: It seems that I have found another bug/issue of QB64 1.5
Post by: bplus on April 13, 2021, 06:57:58 pm
Probably just does functions first that is the way my evaluators work, then does math same precedence we use */ before +- then Booleans. Also probably has to read ahead to determine how to use + for addition or concatenation.
Title: Re: It seems that I have found another bug/issue of QB64 1.5
Post by: SMcNeill on April 13, 2021, 07:25:24 pm
QB64’s IDE error order isn’t logical, nor does it follow any ruleset.  Basically the way it works is like this:

Galleon has an idea for a modern QBASIC.  He writes a translator...

V0.1 basically does:
    IF usertext$ = “SCREEN” then
       set screen...  if error, toss error.
    ELSEIF usertext$ = “PRINT” then
       print stuff or toss an error.
    ....

Then v0.2 came out.  A few new functions went between those two.

Then v0.3 came out.  Some new stuff was added after all that.

V04 added stuff at the very beginning...

Vp.5 added stuff in various points....

Other people joined in...  They added code to random laces which seemed to work...

Sometimes things didn’t work...  ESPECIALLY after we started adding precompiler commands.  Order of precedence became quite important.  Stuff got moved and reordered...  then reordered again...

Now it’s basically a jumbled up mess of:

IF a THEN....
ELSEIF x THEN...
ELSEIF b THEN....
ELSEIF m THEN....


Each keyword is processed seperately, andthey can more or less appear in any unstructured order —- when added, when altered, when moved, at the point where they used to make sense, but now seem out of place...

You won’t always see errors left to right, or right to left, or by alphabetical order of precedence....  they just pop up in the order they appear in the jumbled up mess that is the spagetti code when makes QB64.
Title: Re: It seems that I have found another bug/issue of QB64 1.5
Post by: johnno56 on April 13, 2021, 08:22:34 pm
I'm no expert, when it comes to Basic, but I do not think the "string" side of the equation is the problem.

Unless the variable 'D' has been defined as a string it will probably remain as an integer. eg: D$ = D$ + "0" + Ltrim$(m) should work. The above equation is saying that integer D is equal to integer D plus strings.... (mismatch)

My opinion... for what it's worth...
Title: Re: It seems that I have found another bug/issue of QB64 1.5
Post by: Pete on April 14, 2021, 12:28:42 am
Well it don't mean a thing if you ain't got that string... and d in that code, as shown, ain't a string.

In other words, what John said, but with a catchy tune added.

Pete