That's not a lot... Could it be the sort routine's fault? (I'm assuming there's a sort routine)

Reporting a bug~~
Well, I've grown used to the random RAM clears that happen while using Axe, but this particular one caught me off guard:
The parser told me that at 86% on the 2nd pass, there was a duplicate error. I hit prgm, to scroll to (it was weird, since I'm pretty sure there WASN'T any duplicate error-causing code, and the calc shut off. ofc, ram clear. I don't have the source since it was lost in the crash (I know you can compile from archive, but I usually don't because stuff like that never happens )

not sure if this will help, but about deep thought's bug, i had the same thing happen to me when i tried to romdump my calculator about 3 months ago using TiLP. so if you tried to romdump recently it may have been that rather than axe parser.

I after reading the these reports, I would recommend to NOT use the error scrolling features until I figure out what the bug is.

I after reading the these reports, I would recommend to NOT use the error scrolling features until I figure out what the bug is.

I haven't even used the error scrolling yet (ever).

not sure if this will help, but about deep thought's bug, i had the same thing happen to me when i tried to romdump my calculator about 3 months ago using TiLP. so if you tried to romdump recently it may have been that rather than axe parser.

I have never done a ROM dump either (though I plan to do it in a few days for WabbitEmu).

Do you know exactly how to recreate the bug? Did you run axe programs before this happens? A buggy program can cause bad stuff in long term (until next RAM clear)

Buggy programs aren't that big of a problem for me, since I clear my RAM about once (possibly more) every day anyway. (Excessive RAM clears doesn't hurt the calculator in the long run, does it? ) Anyway, here's how I got the bug (simplified):

1. Made Axe source code. It didn't do anything at all except create a label with some code for a sprite. Nothing else; the program was a test and was functionally useless.
2. Compiled Axe program. No errors; worked fine.
3. Ran program from MirageOS. As expected, the program did nothing at all.
4. Decided that my PRGM list was a bit cluttered. So I went into Mem Mgmt/Del... to get rid of some stuff.
5. Deleted a couple of RAM variables. Found a 1263-byte Y₁ and two parametric equations that obviously didn't belong. Made a very stupid decision to try deleting Y₁. Calculator froze; even the run indicator was stuck in place.

Before I did all this, I purposely cleared my RAM to get rid of unused variables (because I'm too lazy to delete them one by one), so the only applications that could have caused the error are Axe and MirageOS. Since I've never seen MirageOS with a bug like this, and since Axe is still a beta, I figured that it very likely was caused by Axe.

On a slightly related topic, I tried renaming a BASIC program from ICON16 to ICON8. I expected the filesize to shrink one byte, but this didn't happen. Anyone how this happened?

I don't know if this is because of Axe Parser at all, but seeing as it's only started after I downloaded it, I felt I should post it here.

I've been noticing that certain actions on my calculator have gotten slower and slower. Before, I could archive and unarchive variables under 1 KB almost instantaneously, but recently, it's become really slow. I just tried to archive a mere 68-byte program, and it took four whole seconds. Same goes for exiting Axe: when I first downloaded the app, it exited in less than a second, but now it also takes something like four seconds. Anyone have any idea what's happening? I've already tried RAM clears (dozens of them since I first downloaded Axe -- don't worry, most of them were intentional), and it hasn't helped. I really hope this isn't anything permanent.

Bug report with Text command (or boolean logic):

Text(4+4(B>9)+4(B>99)+4(B>999)+4(B>9999),0,A▶Dec

Regardless of the results in B, A content will always be displaying at X coordinate 0 instead of at its respective location, like it would in TI-BASIC (with the command "Text(0,4+4(B>9)+4(B>99)+4(B>999)+4(B>9999),A")

It's because Axe doesn't do implicit multiplication. You need to do "4*(" instead of "4(". Actually, this would probably be more optimized overall:

Text((B>9)+(B>99)+(B>999)+(B>9999)+1*4,0,A▶Dec

oh darn I forgot about the lack of implicit multiplication support

THanks guys, and that was an epic ninja: by two members with similar nicknames