Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Possible String issue? (*solved*)
#1
I don't know whether this is expected behaviour or not because of the way Strings are stored, but my high score routine just presented this issue so I thought I'd check before I changed how it works. :-)

If I declare a string outside of a sub I can use it within any sub. If I change the value within the sub then that's fine, unless I make it equal to another String which was declared within that sub. If I do that, the value of the first string becomes blank as soon as the sub ends.

This is kind of hard to explain, so see this example:
Code:
dim testglobal as string

cls
testglobal = "global"
print testglobal
setlocal()
print testglobal
print "done"

sub setlocal
    dim testlocal as string
    testlocal = "local"
    testglobal = testlocal
    print testlocal
    print testglobal
end sub
The output from this is:
Code:
global
local
local

done
During the sub the value of testglobal is "local". Once the sub ends, it becomes blank.

I think I would be better off using a function for this kind of thing rather than a sub, but I just thought it was worth checking whether that behaviour was expected or not.
Reply
#2
Looks like you've found another bug. The testglobal string value should remain after function exit. Will check it this evening (GMT).
Reply
#3
Oops! I'd been doing so well today, too. :-D

Had a very productive lunchtime integrating the standalone high-score code that I'd written with my game code.

Thanks, boriel!
Reply
#4
This bug has made me discover another inner-sever bug in the compiler which was introduced at least in 1.2.6 (maybe earlier).
I've switched from Subversion to Mercurial. This is the temporary source repository URL: <!-- m --><a class="postlink" href="https://boriel.dyndns.org/hg/zxbasic">https://boriel.dyndns.org/hg/zxbasic</a><!-- m --> if you wanna see progress.
I've rewritten several parts which lead to faster and better code (even seems to fix this bug) which were planned for 2.x anyway.

However the compiler does not pass all test yet, so still fixing code. This bug is related to what Britlion observerd somewhere in the forum (I can't find the thread, sorry) :oops:
Reply
#5
Someone mentioned me?

I'm glad you swapped to mercurial. It's what we use at work, so I'm starting to be familiar with it - even though I'm not in development, so I tend to limit what to do to hg -u pull Smile
Reply
#6
britlion Wrote:Someone mentioned me?

I'm glad you swapped to mercurial. It's what we use at work, so I'm starting to be familiar with it - even though I'm not in development, so I tend to limit what to do to hg -u pull Smile
Heyyyy, Welcoooooooooooooooooooooome :!: Big Grin Big Grin Big Grin

You can pull the ZX Basic compiler (click above to have a look at the repos), with:
Code:
hg clone https://boriel.dyndns.org/hg/zxbasic
or using TortoiseHg.

Also, the compiler is rather unstable now (see download page). It turns out you were right. I was puzzled about asm code generation you pointed out somewhere in this forum. The compiler was generating very obfuscated asm code. Eg.
Code:
DIM a as UInteger
DIM b as UByte

LET b = a AND a
Generates
Code:
ld hl, (_a)
    push hl
    ld hl, (_a)
    ex de, hl
    pop hl
    call __AND16
    ld (_b), a
Instead of
Code:
ld hl, (_a)
    ld de, (_a)
    call __AND16
    ld (_b), a
It turns out I wasn't aware of it because I was using -O3 parameter on many tests (which effectively cleans up the code a lot). Now I'm fixing this, because cleaner code not only is better, but also allows -O3 to optimize even better and more. :roll:
Reply
#7
Best of luck with the changes, I'm happy to run any tests if required. :-)
Reply
#8
Okay, a new super-mega-upgrade (preprepe-alpha) has been uploaded. Please, download and test, here. It should work.
It passes all tests, but it might not be enough.

This is a very new release. It produces much better code (like it did prior 1.2.6). But needs intesive testing.
Since I have switched to Mercurial versioning control, added some deep changes, etc. I won't add new features to this release. Believe it or not, I've spent almost 24 hours (more than 12 hrs a day since Friday) fixing this. :oops:

So, now, it's time to check and tell me if it works.
Reply
#9
Your dedication is very much appreciated, boriel! I'll run a bunch of tests and keep my fingers crossed.

Incidentally, both the .zip and .tar.gz downloads of the Python-based versions are still the old 2153 build, they don't appear to have updated. I've grabbed the .exe version for now. :-)
Reply
#10
LTee Wrote:Your dedication is very much appreciated, boriel! I'll run a bunch of tests and keep my fingers crossed.

Incidentally, both the .zip and .tar.gz downloads of the Python-based versions are still the old 2153 build, they don't appear to have updated. I've grabbed the .exe version for now. :-)
Yep, I forgot to upload these. Will do these evening! Wink
Reply
#11
Well, mostly good news! I've recompiled everything I have and it's all working as it was before, no new errors.

The String issue in the listing above appears to be fixed, which is great! However, the high score table code that I initially noticed the problem with still isn't working, and I have no idea why because in theory it's doing exactly the same thing as the shorter listing. I initially thought it might be related to the fact that the 'global' variable in my full code is an array of strings rather than just a single string, but a quick test program has proven that this isn't the case.

It could well just be an error in my code, I need to go and do some more checking. I'll get back to you. :-)

Cheers, boriel!
Reply
#12
LTee Wrote:Well, mostly good news! I've recompiled everything I have and it's all working as it was before, no new errors.

The String issue in the listing above appears to be fixed, which is great! However, the high score table code that I initially noticed the problem with still isn't working, and I have no idea why because in theory it's doing exactly the same thing as the shorter listing. I initially thought it might be related to the fact that the 'global' variable in my full code is an array of strings rather than just a single string, but a quick test program has proven that this isn't the case.

It could well just be an error in my code, I need to go and do some more checking. I'll get back to you. :-)

Cheers, boriel!
Array of strings has not been tested (yet), only 8bit/16bit ones. Will do this evening... Wink
Reply
#13
Okay, I figured out what it is... and it's a weird one, to say the least! :-)

This is a revised version of the code above but with the value being stored in an element of a String array instead of in a standalone String. It compiles and works perfectly with the new version of ZXBasic:
Code:
dim testglobal(5) as string

cls
testglobal(1) = "global"
print testglobal(1)
setlocal()
print testglobal(1)
print "done"

sub setlocal
    dim testlocal as string
    testlocal = "local"
    testglobal(1) = testlocal
    print testlocal
    print testglobal(1)
end sub

However.... if I take out all of the literal '1' values and make the array index a variable instead, the code no longer works - you get a blank value at the final 'print'.
Code:
dim testglobal(5) as string
dim pos as UBYTE

cls
pos = 1
testglobal(pos) = "global"
print testglobal(pos)
setlocal()
print testglobal(pos)
print "done"

sub setlocal
    dim testlocal as string
    testlocal = "local"
    testglobal(pos) = testlocal
    print testlocal
    print testglobal(pos)
end sub

Hopefully that makes some sense to you, boriel! :-D
Reply
#14
LTee Wrote:Okay, I figured out what it is... and it's a weird one, to say the least! :-)

This is a revised version of the code above but with the value being stored in an element of a String array instead of in a standalone String. It compiles and works perfectly with the new version of ZXBasic:
Code:
dim testglobal(5) as string

cls
testglobal(1) = "global"
print testglobal(1)
setlocal()
print testglobal(1)
print "done"

sub setlocal
    dim testlocal as string
    testlocal = "local"
    testglobal(1) = testlocal
    print testlocal
    print testglobal(1)
end sub

However.... if I take out all of the literal '1' values and make the array index a variable instead, the code no longer works - you get a blank value at the final 'print'.
Code:
dim testglobal(5) as string
dim pos as UBYTE

cls
pos = 1
testglobal(pos) = "global"
print testglobal(pos)
setlocal()
print testglobal(pos)
print "done"

sub setlocal
    dim testlocal as string
    testlocal = "local"
    testglobal(pos) = testlocal
    print testlocal
    print testglobal(pos)
end sub

Hopefully that makes some sense to you, boriel! :-D
It does!
In fact that was the bug I was expecting! Wink
Reply
#15
Even better! :-D
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)