NaaLaa Forum
A couple of potential bugs - Printable Version

+- NaaLaa Forum (http://www.naalaa.com/community)
+-- Forum: NaaLaa (http://www.naalaa.com/community/forumdisplay.php?fid=1)
+--- Forum: Bugs and suggestions (http://www.naalaa.com/community/forumdisplay.php?fid=8)
+--- Thread: A couple of potential bugs (/showthread.php?tid=1057)



A couple of potential bugs - eddavis - 11-01-2022

1) Given the following code:
Code:
s = "abcdef"
wln("s is: '" + s + "' - I am expecting to see 'f': " + right(s, 1))
wln("s is: '" + s + "' - I am expecting to see 'ef': " + right(s, 2))
wln("s is: '" + s + "' - I am expecting to see 'def': " + right(s, 3))
wln("s is: '" + s + "' - I am expecting to see 'cdef': " + right(s, 4))
wln("s is: '" + s + "' - I am expecting to see 'bcdef': " + right(s, 5))
I get:
Quote:s is: 'abcdef' - I am expecting to see 'f': bcdef
s is: 'abcdef' - I am expecting to see 'ef': cdef
s is: 'abcdef' - I am expecting to see 'def': def
s is: 'abcdef' - I am expecting to see 'cdef': ef
s is: 'abcdef' - I am expecting to see 'bcdef': f

I do not thank that is correct.

2) The following code did not give syntax error - but it did not work - where atarry is defined as: atarry = []
Code:
elseif tok = "@" then; nexttok(); n = atarry(parenexpr())
Code should have been:
Code:
n = atarry[parenexpr()]

3) The following code did not give a syntax error, but crashes with:
Code:
(renv) bugs.n7:24: runtime error: Register is not a label (BC_CALL_R)
Code:
vars = []
var = 19
wln("*** " + chr(var + asc("a")) + " = " + vars(var))
Code should have been:
Code:
vars[var]

And again, NaaLaa is so cool!  You have done an amazing job!


RE: A couple of potential bugs - johnno1956 - 11-01-2022

Hi Ed,

As to why the results seem to be 'reversed', cleverer people than I, would have to answer that one... But, just to point out a slight 'quirk' with Naalaa, as compared to most 'Basics', the 'right' command string index starts at zero. Most Basic's index start at one. I do not believe that this will fix your problem... I suppose it would just be FYI... I hope that you get the answer you are looking for...

Regards

J


RE: A couple of potential bugs - eddavis - 11-01-2022

(11-01-2022, 06:49 PM)johnno1956 Wrote: As to why the results seem to be 'reversed', cleverer people than I, would have to answer that one... But, just to point out a slight 'quirk' with Naalaa, as compared to most 'Basics', the 'right' command string index starts at zero. Most Basic's index start at one. I do not believe that this will fix your problem... I suppose it would just be FYI...  I hope that you get the answer you are looking for...

Just to make sure I understand.  Even if zero based, if you have:

s = right("abcdefghi", 2)

What would you expect s to be?

The 2 right-most characters would (to me at least) be "hi".

But if I run:
s = right("abcdefghi", 2)
wln(s)

I get: "cdefghi" - which is the right-most 7 characters.  Hmm.  Does right(s, n) start at n - counting from 0 from the left?
"a" is in position 0, "b" is in position 1, and "c" is in position 2.
Ok, maybe that is what it is doing.

So maybe not a bug, just the old "nut behind the wheel" Smile


RE: A couple of potential bugs - Marcus - 11-03-2022

Thanks for the feedback Smile

Regarding 'right', I designed it to function like that already in the first version of naalaa. 'right' returns the opposite part of a string compared to 'left', because whenever I (myself) use 'right' it's in some sort of combination with 'left'.

The problem with the other errors is that n7 doesn't do ANY type checking at compile time (much like Lua), because variables are allowed to change type at runtime. And, yes, that is kind of bad in the cases where the errors are "obvious". I should try to detect these cases and atleast output warnings.

Code:
visible foo = [1, 2, 3, 4, 5]

bar()
pln foo(4)

function bar()
    if rnd(2) = 0
        foo = function(x)
            return x^2
        endfunc
    else
        foo = baz
    endif
endfunc

function baz(x)
    return |x|
endfunc

If you look at the above code, you might see the beginning of how complicated these checks could become. And that's pretty much why I never bothered to make any checks at all.

In your examples, the compiler just assumes that the variables hold functions and that you're trying to call them. "(renv) bugs.n7:24: runtime error: Register is not a label (BC_CALL_R)" Haha, and that is what you get when you try to make a function call through a variable that isn't a function. I should definitely change that runtime error message, sorry Smile


RE: A couple of potential bugs - Marcus - 11-05-2022

I've followed the discussion about the ^ operator in the Basic Programming Language facebook group. I seem to be doing it the "wrong" way in n7, since I've given unary minus higher precedence. I'll try and remember to fix that.