• * [Tested Fixed in 1.25 Beta r1489]@variablename - Seems to point at one byte BELOW the correct one.
  
  * [Can't replicate cleanly. Needs proved example of error.] [This was probably caused by the stack erorr which is fixed in r1489 ] CHR / CHR$ - CHR$(variable) seems to crash sometimes. CHR$(number) works fine.
  
  * [Tested Fixed in 1.25 Beta r1489] BOLD and ITALIC cannot be used as temporary attributes (BOLD 1 works. PRINT BOLD 1;"Hello" does not.) The compiler issues some very cryptic error messages about this.
  
  * -O2 and -O3 are likely to fail to compile what -O1 and no optimization compiles perfectly. (Seems to fail in 'update_goes_and_comes' in optimizer.pyc on larger files)
  
  * [Tested Fixed in 1.25 Beta r1489]SHL and SHR don't work for Integers (reported by LCD)
  
  *[Tested Fixed in 1.25 Beta 1] Comparisons : the Boolean logic for >= for type FIXED is bugged. (it always returns true)
  
  *[Tested Fixed in 1.25 Beta 1] uByte seem to have something wrong on the comparison front as well:
  
  Code:

  DIM ub as uByte
DIM b as byte
DIM ui as uInteger
DIM i as integer
DIM ul as uLong
DIM l as LONG
DIM fi as fixed
DIM fl as float

print ub,b,ui,i,ul,l,fi,fl

if 0<=20 then print "0<=20" : END IF
if ub <= 20 then print "ub <= 20" : END IF
if b <= 20 then print "b <= 20"   : END IF
if ui <= 20 then print "ui <= 20" : END IF
if i <= 20 then print "i <= 20"   : END IF
if ul <= 20 then print "ul <= 20" : END IF
if l <= 20 then print "l <= 20"   : END IF
if fi <= 20 then print "fi <= 20" : END IF
if fl <= 20 then print "fl <= 20" : END IF
  
  NOT strictly speaking broken, but serious "Quality of life" issues:
  
  * The compiler's errors could be a lot more helpful!
  1> Instead of "unexpected end of file" how about "You started a FOR loop on line 30 that never finished" and "You have an IF on line 100 that doesn't have an END IF" - if the compiler could say what statement or parenthesis isn't closed that would help me track down about 90% of my bugs. As it is, I type a line, compile, type a line, compile and so on - otherwise I'd never find the problem! [I'm REALLY bad at forgetting END IF]
  
  2> Could we get a warning any time a variable is used that hasn't been DIM first? Or just plain not allow it, even? A mistyped variable (vectory instead of vectorY) is very hard to find if the compiler simply creates it without telling me. So the program compiles and runs, but the math isn't working right...
  
  * The assembler seems to be very slow - zxb --asm program.bas returns to the command prompt within a few seconds. If we ask the assembler to assemble the file as well, it can stay away for several minutes.
  

LCD Wrote:From day to day it causes less pain, so I hope, I can start working again in around three weeks.

I hope, Boriel will reappear soon and clear some of the questions. Strange, but I caaot recall, the Variable pointer ever worked here.

britlion Wrote:Glad to have you back Boriel.

I keep editing the list of items at the start of this thread to keep it up to date. I just found out (after two days of scratching my head at something that didn't work correctly) that type FIXED comparison ">=" always returns true... So added that to the list. I don't know if it notifies you of edits or not, so I thought I'd add a post to say there's a new bug in the list.

britlion Wrote:Way to go Boriel!

I just added a problem with comparisions for type uByte, however.

If and when you have a moment, can you check that? I put an example program that fails for me as well.

I'm trying to keep the original message current on bugs. I'll retest them all against any new releases, of course.