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.

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.

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]

             00B
00000B0034CBB9DB
29DB4AF1800180B3
7004141150800861
CB0866662445C861


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].

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.

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.

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.

   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".

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 ?