These are pretty rare finds, but I discovered a bug with the app and not the language. Axe doesn't unset G-T mode upon opening, only Horiz mode. There's a simple fix for this, and it's actually an optimization! Changing res grfSplit,(iy+sGrFlags) to B_CALL(_ForceFullScreen) should do the trick.

Also, when I was inspecting the first few instructions of the app to see what code should be changed to fix this, I saw 2 copies of set textWrite,(iy+sGrFlags). Any reason for this?



EDIT: Regarding screen modes, B_CALL(_ClrScrnFull) in the ClrHome command should probably be B_CALL(_ClrScrn). It's exactly the same as B_CALL(_ClrScrnFull) when the calculator is in full screen display mode, which is 99% of the time anyway, but it will correctly clear the homescreen if it's not in full screen mode as well.

EDIT 2: Also, perhaps there should be an Axe command for B_CALL(_ForceFullScreen)? Axe programmers could run into this problem of not being in full screen mode and then their program displaying very strangely, especially if they're printing text to the homescreen. Perhaps another Fix command would work, but you'd need to branch into 2-digit numbers. This would also require changing how multiple options can be chained together with Fix, but I didn't really like the old way anyways. And on a similar note of OS settings that can mess stuff up, how about adding the ability to enable/disable APD as well?

Wouldn't APD only work when the OS is in control, though? I thought that that didn't really happen in Axe programs.

Some BCALLs give control to the OS, for example the BCALLs that that prompt the user to input text.

Return^r needs an alternate version for applications. I believe jp $4083 would work.

How would you ever have 2 versions of a command that are 1 and 0 arguments respectively?  That means it would be valid syntax to both end with a parenthesis or not end with one.  If the token itself had an open parenthesis, it would be counter-intuitive that the parenthesis could never be closed in the 0 argument case, and if the token did not have an open parenthesis, it wouldn't make sense that you had to add one to close the expression in the 1 argument case.  In other words, if you find yourself in this situation, you're violating the rules of the language.

Ah I see what you mean, so add a new command type bit that implies the token expects a parenthesis, that could work.  Alternatively, and probably better, I could enforce these rules automatically by getting the string for each token at compile time and checking if it ends with a parenthesis.  If it doesn't end in one, require one in the code if arguments are required.  If it does end in one, throw an axiom error if using it in a 0 argument case.

I'm not sure if this has been pointed out yet.

I enforce this restriction because it optimizes your code a lot more optimized.

That PDF was intended just for the pre-release guinea pig testers and was quickly written in just a few hours.  I planned to rewrite it for the actual release but got lazy and released it as-is without proofing it again.  Redundant statements are redundant   This file will be removed in all versions after 1.0.4 anyway (stable), its just for those transitioning from 0.x versions to 1.x versions.

so, I have a new bug.

When using the text command (not sure if it happens with all strings, but I haven't noticed it so far) it randomly replaces individual letters with "r", like once I got omnimagr.org, and once I got omrimaga.org. It changes every time I recompile, and sometimes (about 40%) doesn't occur, so for now I'm just recompiling till it doesn't show up.

Yep, seems like a recurring issue. Methinks Quigibo needs to fix this.