For 1.2.1, a few people wanted me to try to find a place for interrupt data other than L₂ because they wanted to have that space available in their programs that used custom interrupts. Basically all of the viable side-effect-free RAM was already in use, so I had to settle for something with as minor of a side effect as I could find. That ended up being 9200h, part of which stores some sort of data about tables (I'm not exactly sure what).

Anyways, when I made this change, I was aware it would screw up table stuff. To try to remedy this, I added the LnReg^r command, which theoretically restores the important table data that got clobbered by the interrupt code. Get the table data back in a valid state (possibly via a RAM reset), try using this instead of the plain LnReg, and tell me if it that works.

Right now when I try to compile the program into the app I get a not enough rom error and after I garbage collect, it does nothing at all   (by nothing at all I mean it still says not enough rom space). Anyone have suggestions?

Perhaps you don't have enough ROM space? If you're using an 83+, it's quite easy to run out of space in ROM. This generally means that you already have 2 or 6 app pages used up.

When an error occurs, the name of the (sub)program currently being compiled should already be on the screen. As for your issue of not being able to jump to the error to see the context... that doesn't really sound like Axe's place. Neither unfinished versions of zStart nor source files larger than RAM sound like things Axe should be expected to deal with. But I'll look into it regardless.

EDIT: How do you currently edit your files? That would probably help me figure out the best way to provide some sort of error context information that you can use.

I personally think this whole thing has been blown out of proportions, but I'll provide my two cents.

- lately, Eeems has been modifying features of the site that could have bothered the user experience of Omnimaga members, and this without any prior consent from any member, and in this case with the explicit disagreement of a support staff : http://chat.eeems.ca:9003/?server=irc.omnimaga.org%206667&channel=omnimaga&date=Thu%20Nov%2006%202014#1415302519917

One (or a few) people not liking a change doesn't mean it's a bad change. Regarding this particular change of post edit notifications in IRC, if they do in fact filter out spammy multi-edits as Eeems suggested they should, I actually welcome this change.

- in similar situations, Eeems said having the right to perform such modifications as he is the one paying for the hosting of the site. While we all thank him for this, this fact shouldn't become an excuse for making alone decisions that could affect greatly, and in any way, user experience.

Since he's paying for the site and I believe is a primary code contributor, I think Eeems does deserve more weight in these decisions. Regarding the change above, it doesn't really seem like a change that could greatly affect users' experiences. Even if you don't like it, it's a minor annoyance at most. But if there are larger changes that he has made that others have disagreed with which you'd like to bring up, those could be a different story. Preferably, bring them up with another site staff member.

- the co-owner group now only contains Eeems and geekboy, when it used to include way more people like rcfreak0 and Netham45 (the latter holding the full legal rights on the domain, as shown when entering "omnimaga.org" as a domain name here : http://whois.pir.org/). If it was the result of group reorganization, no Omnimaga user was notified of such action unlike the news item located here says it would happen : http://www.omnimaga.org/news/the-status-of-our-staffing-and-the-changes-that-are-being-made/

Neither rcfeak0 nor Netham45 were forcibly overthrown. But yes, the diminishing core staff population is concerning, and it would be nice to have more. I can't say I know who those people should be, though.

- despite Omnimaga being meant to be a friendly place of interest sharing, free speech, and overall amusement, we feel that Eeems treats it too much like a professional responsibility, thus harming the enjoyment of members.

I can't say I've felt this lately, but I also haven't been around much lately. If there's any particular evidence of this to cite, perhaps that could be more compelling. Again, preferably show this to a site staff member.

- the Omnimaga IRC chat has been made by Netham45 then Sorunome to be a free place of discussion. In our opinion, Eeems has proven irrelevant over-restrictiveness several times. We feel that he has been forcing people to join a different channel to carry discussions about certain topics he doesn't like, while there is no topic restriction for the #omnimaga channel.

This sounds a lot like the first point, both of which are actually already the case in Cemetech's IRC channel, and both of which I personally think are positive changes. While having to move to a different IRC channel can be annoying, I completely understand the reasoning for a site admin wanting off-topic discussion to occur outside of the main channel. Off-topic chat should always be liable to being asked to move. If your issue is the manner in which you were asked to move, that deserves consideration, though.

Overall, we think that Eeems should prove more humble behavior, both towards site members and the site itself. It goes by accepting (and actually requesting) others' opinions and taking into account negative feedback. While we perfectly understand the privileges given by the statute of site administrator, we think it should not be mistaken with the statute of absolute ruler.

I agree that accepting others' feedback should definitely occur. However, don't confuse not accepting feedback with accepting feedback but disagreeing. And this is linked to the second point; I haven't seen any issues large enough that have warranted Eeems' disagreement with feedback to be scrutinized. Feel free to show any such issues, though.

Just ignore all the REP_NEXT macros. They're markers to signal to the Axiom system that the next instruction references an address that needs to be linked up at compile time.

That command definitely makes sense to add. The only thing I'd think about is if there's potentially a token that makes more sense, but none spring to mind.

It brings up the menu. I want a way to skip the menu (because it messes up if the user clicks no) and garbage collect on its own

There may be a way to bypass the menu and force a garbage collection. But the menu has good reason to exist because, although uncommon, there are valid reasons why a user would want to avoid garbage collection. So I would not recommend trying to force a garbage collect without the user's confirmation. If the user says no, that means they'd rather your program, as you said, "mess up" rather than a garbage collection occur. You can at least ensure that your program "messes up" gracefully, though.

Hmm, I guess no way if its archived then?

Although there may be weird edge cases where it is possible to safely resize a variable in place in archive, this should generally be considered impossible to do. Unarchiving, resizing, and then re-archiving a variable is the simplest way to resize an archived variable.

As a side note: if your project design involves treating archived variables as anything but read-only data, you might need to redesign your project.

That should definitely exist, yes. I can't really remember why it doesn't... I guess I can try it at some point.