I am not. Cameron Kaiser maintains it. But we are working together to get a better feature set, like listings, compatibility options, or improved linking out.

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

sorry if this sounds a little harsh, but the xa65 source code is in dire need of a clean-up/refactor.
i tried porting it to windows (and even my 65816 SBC as a little experiment) a while back and gave up because it was honestly just horrendous to look at.
there is inconsistent/broken indentation, sometimes it's tabs, sometimes spaces, (sometimes it's both on the same line).
also there's inconsistent whitespace between operators. i'd always recommend 1 space between operators except for brackets for readability, and sometimes you do do that like "var = 1 + i", but other times it's all mushed together like "var=1+i".
and i've also noticed variables using inconsistent casing, sometimes there are underscores to seperate words (snake_case), other times there aren't (flatcase). this can lead to very similarly sounding variables, like how the file xa.c has 2 different variables named "no_link" and "nolink".

so overall i'd highly recommend just sitting down and refactoring and reformatting the entire thing (for the latter there are a lot of online code reformatters you could use). some more comments would also be nice, especially before any bigger/more confusing pieces of code or variables with shorter names to explain what they're generally for (or maybe just giving variables longer names, like there are literally 2 variables named "er" and "ner" with no explaination given on what either mean or do).

again i'm sorry if this sounded harsh but this just has been stirring in my brain for a while now.

@Proxy - yes, you are absolutely right, and we are awfully aware of that.

2.4.0 will come out in this state - but I'll see what I can do for 2.4.1, if time allows and Cameron does not object.

For Java, there are refactoring tools that rename all occurrences of a variable, so the code stays consistent. Is there anything available for C? Can Eclipse IDE do that .... ah yes, just checked. Will be very helpful....

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

Andre mentioned this post to me (coincidentally I reactivated my account here yesterday). I'm not as nice as he is.

That said, I'm going to restrain myself and simply say that while the code definitely isn't pretty -- and if you'd looked at earlier versions you'd see where new code tries to be more consistent and I've added comments to other sections for my own reference -- people always say "this needs a rewrite/refactor" like a rewrite/refactor will solve everything (and yeah, we know about spaces, variable names, etc.; Granny is perfectly capable of sucking eggs). The history of computing is that refactors and rewrites end up introducing nearly as many bugs as they fix.

What attracted me personally to xa in the first place is that it compiles on nearly everything and "just works" (FTR, there have been Visual Studio solution files and mingw support since at least 2007, so I don't know when you were trying to work on it -- if they don't work then I'll gladly accept updates). I've also taken a very conservative approach to regressions which is why there is a large test suite and we keep adding to it, and try not to break syntactical oddities people may have been depending on, at least between point releases. Refactors screw that up too.

We're already introducing some breaking but IMHO necessary syntactic changes in 2.4, mostly in those edge cases, and adding a rewrite just adds more regression risk. Andre and I are xa's most important users but I suspect the other people using xa also do so because updates have been so conservative. It will still build on your old little NetBSD machine, for example, and it should still generate the same bitwise output from your hairy preprocessor macros.

As we get more complete coverage from test cases, we can try to clean up the technical debt. I concede this post was pretty harsh too and I'll wear that, but you kind of asked for it.

Cameron Kaiser

_________________
Machine room: http://www.floodgap.com/etc/machines.html

i know that rewriting existing code will inevitably lead to loads of edge cases and similar bugs, but shallow clean ups (ie variable names, whitespace, and comments) shouldn't break things, or atleast not as badly, though would still help a lot with readability.


oops nvm i'm dumb, i just tried it again and was able to fully compile it on Windows with MSYS2 and the included make file.
specifically i had to do it from within the MSYS2 terminal instead of the Windows one.


yea ok that's a pretty good argument.


yea, full rewrites make more sense for really big updates where you likely have some breakage anyways.


nah it was fine, tbh a lot of that was just frustration because i really wanted a native modern macro assembler on the 65816.
though that job is likely better suited for something specifically written for it. C or not.

65816 support is an acknowledged weaker point. I've got a WDC SXB myself now and I will likely do fixes where I find pain points while I'm programming it (but the KIM-1 is more fun because it's more of a challenge).



I'll add that to the docs. Thanks for checking it still worked, since I don't run Windows locally.

_________________
Machine room: http://www.floodgap.com/etc/machines.html