0 Members and 9 Guests are viewing this topic.
Another bug ?I have this in my prog:[]→°Test .étatThis 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 ?
00B00000B0034CBB9DB29DB4AF1800180B37004141150800861CB0866662445C861
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
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 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.
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.
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.
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.
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".
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.
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.
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?
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 meant I'd potentially like to change store arrows to not close anything rather than closing everything.
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 ?