Some glitches (*solved*)

[LCD]

So, I found some glitches again.
1. In Optimisation modes when procedures (e.g. dummy procedures for ASM containers as used in BeepFX) are not called, ZXBC shows a warning that procedures are not used, but exit with exitcode 1 (Error).
2. Assigning part of String variables do not work. Compiler says, Variable is not Array, but in Sinclair BASIC it works. This example changes string "Test188" to "Tezt188".

Code:

10 LET a$="Test188"
20 PRINT a$(3)
30 LET a$(3)="z"
40 PRINT a$

3. This crases the Spectrum when compiled:

Code:

z=CODE(INKEY$)

[boriel]

Let's separate these bugs so they I can tackle them one by one:

3. This crases the Spectrum when compiled:

Code:

z=CODE(INKEY$)

I can't reproduce it. In fact, it works ok for me.
Are you using it just standalone or as part of a longer code??

[LCD]

Let's separate these bugs so they I can tackle them one by one:

3. This crases the Spectrum when compiled:

Code:

z=CODE(INKEY$)

I can't reproduce it. In fact, it works ok for me.
Are you using it just standalone or as part of a longer code??

Okay...

Yes, it is part of a longer code used in the custom INPUT routine.

[boriel]

So, I found some glitches again.
2. Assigning part of String variables do not work. Compiler says, Variable is not Array, but in Sinclair BASIC it works. This example changes string "Test188" to "Tezt188".

Code:

10 LET a$="Test188"
20 PRINT a$(3)
30 LET a$(3)="z"
40 PRINT a$

This is a bug, definitely, and I think I've fixed it up in Version 1.3.0s927. Can you check it, please :?:

[LCD]

So, I found some glitches again.
2. Assigning part of String variables do not work. Compiler says, Variable is not Array, but in Sinclair BASIC it works. This example changes string "Test188" to "Tezt188".

Code:

10 LET a$="Test188"
20 PRINT a$(3)
30 LET a$(3)="z"
40 PRINT a$

This is a bug, definitely, and I think I've fixed it up in Version 1.3.0s927. Can you check it, please :?:

Bugfix cionfirmed. It works now, thank you!

[LCD]

Let's separate these bugs so they I can tackle them one by one:

3. This crases the Spectrum when compiled:

Code:

z=CODE(INKEY$)

I can't reproduce it. In fact, it works ok for me.
Are you using it just standalone or as part of a longer code??

Please check this:

Code:

paper 0:ink 7:border 0:bright 0:inverse 0:flash 0:cls

print "Test 002: CODE(Inkey$)"
loop1:
print at 0,0;code(inkey$)
if inkey$=" "
    goto loop2
end If
goto loop1

loop2:
end

[boriel]

Thanks!
I''ve reduced it to:

Code:

loop1:
a=code(inkey$)
goto loop1

Seems some misinteraction between code and inkey$... :oops:

[LCD]

Thanks!
I''ve reduced it to:

Code:

loop1:
a=code(inkey$)
goto loop1

Seems some misinteraction between code and inkey$... :oops:

Thats what I though in the first posting, but okay, I forgot to say that it took effect in a loop. I made a workaround waiting for a keypress and then reading Last_K system variable as in your input routine, something that I can live with.

[boriel]

Thanks!
I''ve reduced it to:

Code:

loop1:
a=code(inkey$)
goto loop1

Seems some misinteraction between code and inkey$... :oops:

Thats what I though in the first posting, but okay, I forgot to say that it took effect in a loop. I made a workaround waiting for a keypress and then reading Last_K system variable as in your input routine, something that I can live with.

I've located the bug, and it's a *nasty* one. So your program might crash even if out of a loop. It unbalances the stack... It's safe to use it from within a funcion/sub but not in global scope. Anyway, I'm fixing it right now... :wink:

[LCD]

Thanks!
I''ve reduced it to:

Code:

loop1:
a=code(inkey$)
goto loop1

Seems some misinteraction between code and inkey$... :oops:

Thats what I though in the first posting, but okay, I forgot to say that it took effect in a loop. I made a workaround waiting for a keypress and then reading Last_K system variable as in your input routine, something that I can live with.

I've located the bug, and it's a *nasty* one. So your program might crash even if out of a loop. It unbalances the stack... It's safe to use it from within a funcion/sub but not in global scope. Anyway, I'm fixing it right now... :wink:

Great, I'm currently out on my brothers birthday party, so can test it tomorrow if it is ready then .
Strange but it also crashed inside a Function (Input).
Why I'm always running on the really *nasty* bugs... Maybe because I'm using the compiler at its limits.

[boriel]

Great, I'm currently out on my brothers birthday party, so can test it tomorrow if it is ready then .
Strange but it also crashed inside a Function (Input).

Ok, It seems this (important) bug is fixed. Please, download version 1.3.0s928 and check it. :roll:

Why I'm always running on the really *nasty* bugs... Maybe because I'm using the compiler at its limits.

And I thank you for that! 8)
This is what the compiler needs, but I agree BASIC was not designed to be used this (hard) way (C/C++ and modern languajes seems more oriented toward such usage, IMHO). Anyway, the compiler is getting good because its a rather easy highlevel languaje allowing some hard hacks at the same time. :wink:

[LCD]

Thank you for that fast fixing these nasty bugs I always run into. I will download the new version as soon as possible.
Do not worry, I report only bugs if I expect that something works that way, but it did not. Otherwise I will ask if it is supposed to work that way. I want to bend ZXBC to maximum to show how capable it is. I love this project and I love to code games in Basic and explore how much is possible. ZXBC is my favourite coding language since 2008.
As it gets better, I love it more.

[LCD]

Just downloaded the new versiion and tested the part in question. Works fine now. Many thanks for fixing it.