### Author Topic: Bug Reports  (Read 163789 times)

0 Members and 1 Guest are viewing this topic.

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1920 on: July 14, 2014, 05:10:15 pm »
Another bug ?
I have this in my prog:
[]→°Test .état
This gives an error, and jumps on the first "t" in "état". I guess it's because it didn't get that the "." started a comment but why ?

Thanks for the report. I looked into it and was able to fix it pretty easily. (perhaps deceptively so?) If you'd like to grab the fixed version and confirm that I didn't horribly break anything, you can test the developmental build.

#### Hayleia

• Programming Absol
• Coder Of Tomorrow
• LV12 Extreme Poster (Next: 5000)
• Posts: 3367
• Rating: +393/-7
##### Re: Bug Reports
« Reply #1921 on: July 15, 2014, 03:08:19 am »
I didn't see anything broken for now but I can confirm that this line works now.
Thanks
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

#### Hayleia

• Programming Absol
• Coder Of Tomorrow
• LV12 Extreme Poster (Next: 5000)
• Posts: 3367
• Rating: +393/-7
##### Re: Bug Reports
« Reply #1922 on: July 15, 2014, 10:03:11 am »
Double post for another bug
I declared a constant twice in my program (yeah, stupid, I know ) but the error message was DECLARE FIRST instead of something like ALREADY IN USE.
I own: 83+ ; 84+SE ; 76.fr ; CX CAS ; Prizm ; 84+CSE
Sorry if I answer with something that seems unrelated, English is not my primary language and I might not have understood well. Sorry if I make English mistakes too.

#### Zemmargorp

• LV4 Regular (Next: 200)
• Posts: 115
• Rating: +7/-2
• Either programming or thinking of it.
##### Re: Bug Reports
« Reply #1923 on: August 01, 2014, 09:42:03 am »

Here are some errors I found by trying stupid things !

The first one is when you try to compile a program which has the same name as the source : you get an error, and pressing the [prgm] key will freeze the calculator during some seconds. I've also noticed that, when the compiled name takes more than 8 characters, the error "NAME LENGTH" appears in a strange way. And it would be great if, when compiling to a program instead of an application, the lowercase letters of the program name were converted into uppercase, instead of truncating the name.

Like the "NAME LENGTH" error described earlier, when compiling to a program instead of an application, if the name contains more than 8 characters and uses lowercase, the error "INVALID TOKEN" will appear in a strange way, and pressing the [prgm] key will make the calculator freezing during a few seconds. Here's the hex code corresponding to that error, as it appears on the calculator :

Code: [Select]
             00B00000B0034CBB9DB29DB4AF1800180B37004141150800861CB0866662445C861

In addition to that, after compiling an empty source, when you try to execute the compiled program, you get a "SYNTAX" error, instead of displaying "Done". I know, it's because the compiled program is empty too, but it could at least contains $C9. And by the way, you get the same problem when compiling a source which contains only a "Return". But this isn't the case anymore if you add a label right after the Return ! That's a bit strange. In fact, to solve all this, Axe should automatically add$C9 at the end of the compiled program if there's none, without looking more than that at what's written in the source.

There are also some problems with the multiline comments... If you end the comment the line after you started it, Axe Parser doesn't detect the comment's end, and make the error "MUST END COMMENT". And if, instead of skipping lines inside a multiline comment, you use colons, you get the same error.

An other little bug for the road : trying to display a string ending with the [sto] arrow generates the "INVALID TOKEN" error.
I'm french, that's the reason why my English can be a bit approximate.

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1924 on: August 01, 2014, 03:34:19 pm »
The first one is when you try to compile a program which has the same name as the source : you get an error, and pressing the [prgm] key will freeze the calculator during some seconds.

I get the "SAME OUTPUT NAME" error as expected, and going to error occurs instantly.

I've also noticed that, when the compiled name takes more than 8 characters, the error "NAME LENGTH" appears in a strange way.

I'm not sure what you mean by the error appearing in a strange way. It seems fine to me. If you mean none of the progress bar and such have appeared yet, that's because the header of the program is parsed specially and before main parsing begins.

And it would be great if, when compiling to a program instead of an application, the lowercase letters of the program name were converted into uppercase, instead of truncating the name.

This used to be the case, but when I rewrote header parsing, I removed this behavior. My reason for doing so was twofold: to make header parsing easier for me, and to implicitly prevent code that was meant to be compiled as an application from being compiled as a program. I figured that, if you encountered this error, you could just quickly convert the name to uppercase anyways and not encounter it again.

Since I made this change, one dissenter has presented an argument against the change. He frequently develops applications and compiles test builds as programs to avoid the somewhat long application-writing pass, and as such, he needs to change the case of the name when switching between compiling test and release builds. But for being a relatively small problem that only one person has brought up and which can be worked around in a matter of seconds, I haven't had enough reason to change the behavior back.

Like the "NAME LENGTH" error described earlier, when compiling to a program instead of an application, if the name contains more than 8 characters and uses lowercase, the error "INVALID TOKEN" will appear in a strange way, and pressing the [prgm] key will make the calculator freezing during a few seconds. Here's the hex code corresponding to that error, as it appears on the calculator :

Code: [Select]
             00B00000B0034CBB9DB29DB4AF1800180B37004141150800861CB0866662445C861

If the strange appearance is the same as the strange appearance I described before, that's expected. But I think I may have inadvertently reproduced the freeze you're experiencing. If my suspicion is correct, it's due to the fact that changing any Axe settings (anything in the options menu or the target compiled type) results in the Axe settings appvar needing to be modified and saved back to archive, which is done when Axe exits, whether to the homescreen or to an error in the program editor.

There are also some problems with the multiline comments... If you end the comment the line after you started it, Axe Parser doesn't detect the comment's end, and make the error "MUST END COMMENT". And if, instead of skipping lines inside a multiline comment, you use colons, you get the same error.

I can reproduce this bug. I'll try to fix it, although Axe's comment/newline parsing has always been a bit wonky, so it may not be as easy as it would seem.

An other little bug for the road : trying to display a string ending with the [sto] arrow generates the "INVALID TOKEN" error.

Axe has tried to be friendly to BASIC coders used to newlines and store arrows closing/breaking out of any open parentheses, braces, or quotation marks. As a result of this, like in BASIC, you can't include a store arrow in a string, because it immediately ends the string and is parsed as a normal store arrow. However, unlike in BASIC, there are other ways to include data which, although a bit messy, let you include a store arrow in string data. If you know the character code for the store arrow, which is 0x1C, you can plop it in the middle of string data, like "ABC"[1C]"D". You could also do this without directly providing the character code because fetching the character code for the store arrow is valid, like "ABC"Data('→')"D". However, take note that strings need a null terminator byte, which is provided automatically when a line of data ends with string data. It would not be provided automatically in a case like "ABC"[1C], so you would need to make the line end in string data, like "ABC"[1C]"", or add the null byte yourself, like "ABC"[1C00].
« Last Edit: August 01, 2014, 03:38:55 pm by Runer112 »

#### Zemmargorp

• LV4 Regular (Next: 200)
• Posts: 115
• Rating: +7/-2
• Either programming or thinking of it.
##### Re: Bug Reports
« Reply #1925 on: August 01, 2014, 07:34:57 pm »

I'm not sure what you mean by the error appearing in a strange way. It seems fine to me. If you mean none of the progress bar and such have appeared yet, that's because the header of the program is parsed specially and before main parsing begins.
Yes, that's what I mean. Before finding these errors, I was not used with error messages without the progress bar and everything.

If the strange appearance is the same as the strange appearance I described before, that's expected. But I think I may have inadvertently reproduced the freeze you're experiencing. If my suspicion is correct, it's due to the fact that changing any Axe settings (anything in the options menu or the target compiled type) results in the Axe settings appvar needing to be modified and saved back to archive, which is done when Axe exits, whether to the homescreen or to an error in the program editor.
Ok, so the strange appearance is expected. And the bug is maybe due to the settings ? My settings are the following : "No shell", "Lowcase ON", and "Auto Backup".

I can reproduce this bug. I'll try to fix it, although Axe's comment/newline parsing has always been a bit wonky, so it may not be as easy as it would seem.
Yes, but this is not a major bug. I know how complicated it is to interpret a colon, because its behavior may vary : inside a string it's a character, inside a line it can be used between brackets, whereas newlines are always separators of instructions ! So I sympathize

Axe has tried to be friendly to BASIC coders used to newlines and store arrows closing/breaking out of any open parentheses, braces, or quotation marks. As a result of this, like in BASIC, you can't include a store arrow in a string, because it immediately ends the string and is parsed as a normal store arrow.
Excuse me, I made a mistake, I thought that the store arrow didn't close strings. But, unlike TI-Basic, the store arrow doesn't close the parentheses : "1→Y*2+(Y→Z", "Disp Z>Dec" writes 1.
I'm french, that's the reason why my English can be a bit approximate.

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1926 on: August 01, 2014, 07:48:52 pm »
Ok, so the strange appearance is expected. And the bug is maybe due to the settings ? My settings are the following : "No shell", "Lowcase ON", and "Auto Backup".

I assume the bug we're talking about is the slight freeze? Are you sure this happens every time and not only when you've changed a setting in the options menu or the compile target type?

Excuse me, I made a mistake, I thought that the store arrow didn't close strings. But, unlike TI-Basic, the store arrow doesn't close the parentheses : "1→Y*2+(Y→Z", "Disp Z>Dec" writes 1.

Yeah, I guess the store arrow doesn't close parentheses in Axe. Come to think of it, it doesn't close curly braces either. I'm not sure how big I'd be on changing this now, though, since it's been this way forever and there haven't been any other problems reported with the way it is. If I did want to change this behavior, I'd probably do it in the theoretical Axe 2.0, since lots of other language grammar changes would be made as well and I'd want to lump them all together.

#### Matrefeytontias

• Axe roxxor (kinda)
• LV10 31337 u53r (Next: 2000)
• Posts: 1982
• Rating: +310/-12
• Axe roxxor
##### Re: Bug Reports
« Reply #1927 on: August 01, 2014, 07:50:03 pm »
No no no no no no don't touch parenthesis and brackets you'll kill all of my sources if you do so

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1928 on: August 01, 2014, 08:10:30 pm »
Well yeah, that's why if I'm going to do it, I'm going to do it in Axe 2.0 with probably other language grammar changes that could break existing programs.

#### Zemmargorp

• LV4 Regular (Next: 200)
• Posts: 115
• Rating: +7/-2
• Either programming or thinking of it.
##### Re: Bug Reports
« Reply #1929 on: August 01, 2014, 08:19:34 pm »
No no no no no no don't touch parenthesis and brackets   you'll kill all of my sources if you do so

Yeah, I guess the store arrow doesn't close parentheses in Axe. Come to think of it, it doesn't close curly braces either. I'm not sure how big I'd be on changing this now, though, since it's been this way forever and there haven't been any other problems reported with the way it is. If I did want to change this behavior, I'd probably do it in the theoretical Axe 2.0, since lots of other language grammar changes would be made as well and I'd want to lump them all together.

No, seriously, like said Matrefeytontias, don't change this ! It's way better like it is ! Even in an Axe 2.0, even if there are others grammar changes ! When I said "But, unlike TI-Basic, the store arrow doesn't close the parentheses", it was only a remark ! Axe Parser is better than TI-Basic ! How could you write "X*2+(A*3+Y→Z)+GDB0" if the store arrow already closes the parentheses ?

I assume the bug we're talking about is the slight freeze? Are you sure this happens every time and not only when you've changed a setting in the options menu or the compile target type?

Yes, and yes.
I'm french, that's the reason why my English can be a bit approximate.

#### Runer112

• Project Author
• LV11 Super Veteran (Next: 3000)
• Posts: 2289
• Rating: +639/-31
##### Re: Bug Reports
« Reply #1930 on: August 01, 2014, 08:27:00 pm »
No, seriously, like said Matrefeytontias, don't change this ! It's way better like it is ! Even in an Axe 2.0, even if there are others grammar changes ! When I said "But, unlike TI-Basic, the store arrow doesn't close the parentheses", it was only a remark ! Axe Parser is better than TI-Basic ! How could you write "X*2+(A*3+Y→Z)+GDB0" if the store arrow already closes the parentheses ?

Oh, I worded my response pretty poorly... I meant I'd potentially like to change store arrows to not close anything rather than closing everything.

#### Zemmargorp

• LV4 Regular (Next: 200)
• Posts: 115
• Rating: +7/-2
• Either programming or thinking of it.
##### Re: Bug Reports
« Reply #1931 on: August 02, 2014, 09:00:22 am »
I meant I'd potentially like to change store arrows to not close anything rather than closing everything.
If by that you mean store arrows won't close anymore strings and datas, then, fine, it's a good idea !
I'm french, that's the reason why my English can be a bit approximate.

#### Zemmargorp

• LV4 Regular (Next: 200)
• Posts: 115
• Rating: +7/-2
• Either programming or thinking of it.
##### Re: Bug Reports
« Reply #1932 on: August 05, 2014, 11:06:32 am »
I know why my Axiom didn't work... and it was not even my fault !
Its name was "AXIOM", and when I renamed it (by chance) "AXIOM2", it worked !
That means Axe Parser doesn't behave correctly when the Axiom used is named "AXIOM".
You should fix it quickly, because other people may write Axioms and call them "AXIOM".
I'm french, that's the reason why my English can be a bit approximate.

#### Matrefeytontias

• Axe roxxor (kinda)
• LV10 31337 u53r (Next: 2000)
• Posts: 1982
• Rating: +310/-12
• Axe roxxor
##### Re: Bug Reports
« Reply #1933 on: August 05, 2014, 11:54:54 am »
No, that was a TASM issue. Switching to SpASM fixed it.

EDIT : oops just saw the answer in the other thread. Did you try compiling into AXIOM2 with TASM ?
« Last Edit: August 05, 2014, 11:58:31 am by Matrefeytontias »

#### Zemmargorp

• LV4 Regular (Next: 200)
• Posts: 115
• Rating: +7/-2
• Either programming or thinking of it.
##### Re: Bug Reports
« Reply #1934 on: August 05, 2014, 12:22:33 pm »
No, that was a TASM issue. Switching to SpASM fixed it.

EDIT : oops just saw the answer in the other thread. Did you try compiling into AXIOM2 with TASM ?

Not yet. But I'm quite sure it does work.
*Editing the "compile.bat" file... Compiling with TASM...*
*Adding the file generated to emulator... Compiling with Axe...*
Yes, compiling into "AXIOM2" with TASM works.
*Editing the "compile.bat" file again...*
But I'm happy to have installed SPASM, since it supports the ".org" directive, and it will be useful for my Axiom  .

About Axioms : I don't succeed in using the prefixes $7F and$49 to change the replacement policy. Does anyone know which instructions to use them with (ld ? bcall ?), how to use them (before the instruction op-code or before the address), etc ?
I'm french, that's the reason why my English can be a bit approximate.