boriel Wrote:The 1st problem seems a critical bug, so I'm going to fix it right now! (The function parameter STR(X) bug).
On the other hand, this code works ok:

Code:

dim a as ubyte a=20 print str(a)

I use EmuZWin emulator. Which one do you use?
Emulator crashes are not related to the compiler (or should not be).

Note: The POKE STRING ... is a rather strange case. I will check it, anyway.

LCD Wrote:

boriel Wrote:The 1st problem seems a critical bug, so I'm going to fix it right now! (The function parameter STR(X) bug).
On the other hand, this code works ok:

Code:

dim a as ubyte a=20 print str(a)

I use EmuZWin emulator. Which one do you use?
Emulator crashes are not related to the compiler (or should not be).

Note: The POKE STRING ... is a rather strange case. I will check it, anyway.

I was using SPIN 0.666, but after finding it a little "unstable" I should maybe switch to different emulator. It was a crash of the Spectrum code inside emulator. But I had cases where the emulator completly crashes (not from your compiler).
I also found out that the compiler warnings ("x defined as float", or "x not used") causes the compiler to stop the compilation. But I don't give up...

boriel Wrote:

LCD Wrote:

boriel Wrote:The 1st problem seems a critical bug, so I'm going to fix it right now! (The function parameter STR(X) bug).
On the other hand, this code works ok:

Code:

dim a as ubyte a=20 print str(a)

I use EmuZWin emulator. Which one do you use?
Emulator crashes are not related to the compiler (or should not be).

Note: The POKE STRING ... is a rather strange case. I will check it, anyway.

I was using SPIN 0.666, but after finding it a little "unstable" I should maybe switch to different emulator. It was a crash of the Spectrum code inside emulator. But I had cases where the emulator completly crashes (not from your compiler).
I also found out that the compiler warnings ("x defined as float", or "x not used") causes the compiler to stop the compilation. But I don't give up...

???
Al this behavior is really odd and is scaring me... hock:
Which codes produces "x defined as float" or "x not used"?
"x not used" should appear if x variable is not used and optimization level (-O) > 1. E.g. -O2
Then x variable is removed. Other than that, it should produce a program.

By the way, a workaround on your subroutine code, place

Code:

DIM erg$

inside your subroutine before using the variable fixed the problem. It seems I forgot to implicit declared local vars.

EDIT: Fixed. I didn't forgot it. Just an extra tab mislead in a python sub.... and that was the bug!

LCD Wrote:Scary, I know... If I write

Code:

Dim daytime$ as string

and don't use it (or simply rem out the lines where it was used), the compiler throws out:
"warning: Variable 'daytime' is never used Errors occured, compilation failed".
the same with other variables:

Code:

Dim a as ubyte

results in "warning: Variable 'a' is never used Errors occured, compilation failed" if I do not use the variable.
Will check again which code resulted in "x definded as float", maybe the break was caused by something different (I often forgot to write "THEN" after IF and ELSEIF) :oops:

boriel Wrote:

LCD Wrote:Scary, I know... If I write

Code:

Dim daytime$ as string

and don't use it (or simply rem out the lines where it was used), the compiler throws out:
"warning: Variable 'daytime' is never used Errors occured, compilation failed".
the same with other variables:

Code:

Dim a as ubyte

results in "warning: Variable 'a' is never used Errors occured, compilation failed" if I do not use the variable.
Will check again which code resulted in "x definded as float", maybe the break was caused by something different (I often forgot to write "THEN" after IF and ELSEIF) :oops:

Well, catching ELSEIF and others missing syntax error is something I will try to improve soon.

Can you paste some code where this happens? (I need more code context).

LCD Wrote:

Code:

dim a as ubyte dim b as uinteger a=20 print a

If you compile these lines (not using variable b), the compiler should only ignore the fact, variable b is not used, but it stops with this message:
"temp.bas:2: warning: Variable 'b' is never used Errors occured, compilation failed"
It occurs only with optimisation levels 1-3, but not if no optimisation is selected.

Quote:zxb temp.bas -O2 -T -B -a
temp.bas:2: warning: Variable 'b' is never used
INFO: __PRINTU8 is not defined. No optimization is done.
INFO: PRINT_EOL is not defined. No optimization is done.

Quote:temp.bas:2: warning: Variable 'b' is never used Errors occured, compilation failed

boriel Wrote:

LCD Wrote:

Code:

dim a as ubyte dim b as uinteger a=20 print a

If you compile these lines (not using variable b), the compiler should only ignore the fact, variable b is not used, but it stops with this message:
"temp.bas:2: warning: Variable 'b' is never used Errors occured, compilation failed"
It occurs only with optimisation levels 1-3, but not if no optimisation is selected.

This is what I get:

Quote:zxb temp.bas -O2 -T -B -a
temp.bas:2: warning: Variable 'b' is never used
INFO: __PRINTU8 is not defined. No optimization is done.
INFO: PRINT_EOL is not defined. No optimization is done.

I also see something strange in this error message:

Quote:temp.bas:2: warning: Variable 'b' is never used Errors occured, compilation failed

the bold letters are not part of the compiler message! :?:

I also get the warning, but the program gets compiled, and temp.tzx file is created.

Perhaps you're using an external IDE / script to compile? Notice that warnings are also send to stderr output (like error messages), because many programs expect them this way.

LCD Wrote:

boriel Wrote:

LCD Wrote:

Code:

dim a as ubyte dim b as uinteger a=20 print a

If you compile these lines (not using variable b), the compiler should only ignore the fact, variable b is not used, but it stops with this message:
"temp.bas:2: warning: Variable 'b' is never used Errors occured, compilation failed"
It occurs only with optimisation levels 1-3, but not if no optimisation is selected.

This is what I get:

Quote:zxb temp.bas -O2 -T -B -a
temp.bas:2: warning: Variable 'b' is never used
INFO: __PRINTU8 is not defined. No optimization is done.
INFO: PRINT_EOL is not defined. No optimization is done.

I also see something strange in this error message:

Quote:temp.bas:2: warning: Variable 'b' is never used Errors occured, compilation failed

the bold letters are not part of the compiler message! :?:

I also get the warning, but the program gets compiled, and temp.tzx file is created.

Perhaps you're using an external IDE / script to compile? Notice that warnings are also send to stderr output (like error messages), because many programs expect them this way.

Yes, I'm a donkey, that's the reason... It works if I compile first and then start the emulator, not if I start the batch operation (compile and then start the emulator automaticaly).
I'm using a IDE which does not start the emulator after compilation if something was sent over the stderr channel (because it supposes to be a error which aborts the compilation). Could you please change the output to send such messages to the normal std program output, like the other compiler (optimisations) warnings?

boriel Wrote:zxb.exe already returns an errorlevel <> 0 if there were an error (this is the standard behavior). You can however tell the compiler to use a different file (--stderr), but it will not separate warnings from errors. I suppose I will have to add a flag for that.

LCD Wrote:

boriel Wrote:zxb.exe already returns an errorlevel <> 0 if there were an error (this is the standard behavior). You can however tell the compiler to use a different file (--stderr), but it will not separate warnings from errors. I suppose I will have to add a flag for that.

No chance to read the error level because error level cannot be readed out,

Quote:C:\>zxb.exe
Usage: zxb.py <input file> [options]

zxb.py: error: missing input file. (Try -h)
C:\>echo %errorlevel%
2

Quote: but you send the usual compiler warning (INFO) like these:

boriel Wrote:The environment variable %errorlevel% only returns 0 on successful compilations. This value is also returned in most APIs when executing a external program as "return code" or "exit value" or similar.

Quote:This will be transformed into :remark: or :info: codes (like warnings, but less important) and also output to stderr in the next version (I've been so busy fixing bugs I couldn't do this before).
Anyway, I will add a flags for warnings and infos like '--warnings-file' and '--info-file' so you can isolate warnings from error msgs, etc.