Please rename your forks of TIGCCLIB and ld-tigcc

Parts of your forks still attempt to impersonate TIGCC, confusing users. Both your version of "TIGCCLIB" and of "ld-tigcc" are modified (including some changes which have most definitely not been approved by the TIGCC Team). Therefore, it is not appropriate to call them "TIGCCLIB" and "ld-tigcc". Please call them "GCC4TILIB" and "ld-gcc4ti" or come up with some other name for them. Your unauthorized use of the "TIGCC" name for your forks and the nature of the changes they contain hurt the reputation of the TIGCC Project. Lack of time is not a fair excuse, because you have had years to do the renames (and they should have been done before making any releases of your fork).

As should be obvious, and IIRC as already explained to you in another place, renaming would make it possible for projects to force building on GCC4TI instead of your unmaintained TIGCC, which is clearly the last thing you want to happen.

Nonsense. The name "TIGCCLIB" is not used anywhere internally. It is just a matter of documentation and user-visible naming! The name tigcc.a is used internally, but as it is automatically linked, renaming that to gcc4ti.a should also not have any effect on user programs.

As for ld-tigcc, it is also clear that this binary should not be called directly, but only ever through the command-line frontend or the IDE. Please stop bringing up this excuse for misusing the "TIGCC" name!

The only item where your rationale makes any sense is the tigcc command-line frontend, but even there I prefer having it clearly named gcc4ti and you know that. It can easily be symlinked one way or the other.

Please reopen the issue (looks like github won't let me even though I'm the reporter) until it is actually resolved!

And as GCC4TI is already incompatible with TIGCC and will become even more so with time, so projects should clearly be specifying what they want to use. And finally, calling TIGCC "unmaintained" is quite arrogant considering your sparse commit history. (And by the way, there's also the SVN repository still up which you aren't pushing anything to, with its own issue tracker that throws an error when one tries to register there. Looks like this project is actually the fork of the fork.)

Oh, and your continued refusal to respect the TIGCC name is likely going to affect the arrangement we had agreed on for the LPG projects whose names you appropriated. You have been warned.

for practical matters, TIGCC and GCC4TI hardly matter to anybody. Their target audience has been small for 6-7 years (the community belittled a lot in 2006-2007), two years before the advent of GCC4TI. Despite its low programmability, the Nspire series, is phasing out the TI-68k series even more by the day in actual users' hands, so the target audience is getting smaller by the day. IOW, the mere fact of discussing about TIGCC and GCC4TI is essentially ado about nothing.
you and me will discuss the occasional incompatibilities later and in other venues... but both of the changes that you single out were obviously made for a reason. The reasons of one incompatibility is indicated in the commit log (it removes broken code); for the other incompatibility, you haven't found the reason by yourself, and you will disagree with it (hint: it's a use case you don't care about).
having a sparse commit history is better than having basically no commits for years, not even backports for bugs crashing users' calculators which have been duly reported to you, let alone the dozens of bugfixes, new features (some of which were contributed to TIGCC as early as 2002, more than a decade ago by now...), major build system improvements (reliability, portability, streamlining), optimizations, long-overdue work for getting closer to standard libraries and toolchains. Refusal for years to implement / commit things deemed useful (and sometimes even implemented, but lost forever as you failed to publish some of the contributions and you don't act on them by yourself...) by users, and the general neglect of the code base shown by the aforementioned items, hurt the TIGCC project's reputation far more than anything else... We (most of us being former TIGCC contributors - some of us have our name in the credits) had correctly identified code base neglect before starting GCC4TI. It's a fact that we have worked to improve the situation, for the users' benefit.
the GCC4TI Github repository was created at a time the server hosting the project suffered hardware failure. It's not a "fork of the fork" in the classic sense of "fork", though I suppose it is in the weak sense of "fork" brought by Github - anyhow, it's merely a continuation of GCC4TI on another infrastructure, with an up-to-date SCM (the one I've been using since the outset for working on GCC4TI because it's simply more powerful and faster), by the lead developer. This repository has been in plain sight for more than two years (including in my yAronet signature !), making your recent public provocation about nothing supposedly being done in GCC4TI for more than two years even more ludicrously stupid (all the more it's a prime example of the pot calling the kettle black - unlike you, I do actual work in the TI community).
since you bring up the unrelated LPG matter... let's have this place record that, no matter what you keep clamoring and lying, as made clear by the original authors of the programs, you - not me - are the one who misappropriated their names in the forks you created more than four years ago, and stopped maintaining after only several months without producing a single release of the full software stack. On my side, I produced 4 releases of the projects I became the de-facto sole maintainer (instead of co-maintainer) of when your commit privileges were revoked due to your aggressive behaviour against fellow developers and users. 4 releases isn't that much, as some projects make a new release every few weeks... but it's infinitely better than 0. All of the releases I produced provide bugfixes, new features and cleanup; they were produced with the help of multiple contributors, mainly Jon and Benjamin.
from the users' POV, spending time on reviewing and productive activities is immensely better than spending time on improductive / counter-productive matters. Bringing up to date projects which have been unmaintained for years, otherwise offer zero new feature over GCC4TI and LPG software, and have zero brand recognition (TIGCC does have one, but your unreleased forks of LPG software obviously do not), clearly belongs to the latter category. So does sending the usual provocations which show you have no clue what you're talking about.

for practical matters, TIGCC and GCC4TI hardly matter to anybody. Their target audience has been small for 6-7 years (the community belittled a lot in 2006-2007), two years before the advent of GCC4TI. Despite its low programmability, the Nspire series, is phasing out the TI-68k series even more by the day in actual users' hands, so the target audience is getting smaller by the day. IOW, the mere fact of discussing about TIGCC and GCC4TI is essentially ado about nothing.

And that is one of the reasons why I am not spending hours on TIGCC anymore as I did in the past.

you and me will discuss the occasional incompatibilities later and in other venues... but both of the changes that you single out were obviously made for a reason. The reasons of one incompatibility is indicated in the commit log (it removes broken code); for the other incompatibility, you haven't found the reason by yourself, and you will disagree with it (hint: it's a use case you don't care about).

Still, making such incompatible changes goes against a core design principle of TIGCCLIB (source compatibility guaranteed forever), and the default.h change also breaks a core design principle of TIGCCLIB by its nature (i.e., even when disregarding compatibility entirely).

having a sparse commit history is better than having basically no commits for years, not even backports for bugs crashing users' calculators which have been duly reported to you,

Such as?

I am not aware of anything that needs urgent fixing in TIGCC.

let alone the dozens of bugfixes,

A handful bugfixes, and lots of poorly thought-out changes that "fix" "bugs" that are not really bugs at all.

new features (some of which were contributed to TIGCC as early as 2002, more than a decade ago by now...),

Features which are either not sufficiently tested, not implemented fully or correctly, or have been rejected for valid reasons. All the features which were done properly (not in a half-assed way) have been integrated.

major build system improvements (reliability, portability, streamlining),

Basically all your build system "improvements" are unnecessary and/or actually make things worse. (And the very few changes that might possibly make sense are bundled with all the other unnecessary changes, which makes them also not useful.)

optimizations,

Micro-optimizations saving less than 10 bytes. Those are the only actual improvements you have to show, and that's when they work at all. You have a history of "optimizations" that break things. Both TIGCC releases (before the fork) and GCC4TI releases have had showstopper bugs due to your poorly-tested optimizations. The time wasted on such pointless micro-optimizations would be much better spent on the long-overdue upgrade of GCC to a modern version. The improved compiler optimizations there have the potential to save hundreds of bytes on large programs. Targeted work on machine-specific compiler optimizations (peepholes etc.) could also be of much help. Optimizing away a handful bytes in the library is just a pure waste of time.

long-overdue work for getting closer to standard libraries and toolchains.

Those are completely unnecessary changes (which by the way also change the names of internal binaries exactly like renaming ld-tigcc to ld-gcc4ti would, yet you refuse to do the latter with the "compatibility" excuse).

Refusal for years to implement / commit things deemed useful

There were always good reasons why I rejected something. Either the whole idea was flawed, or the implementation was incomplete or buggy. I do not commit half-assed changes (also because I know that once the part the implementor cared about is in, nobody cares about actually finishing the feature to work for all use cases).

(and sometimes even implemented, but lost forever as you failed to publish some of the contributions and you don't act on them by yourself...) by users

We uploaded a contrib.zip with all the contributions we received. Anything not included there was simply not properly contributed to us.

and the general neglect of the code base shown by the aforementioned items,

The "general neglect of the code base" just shows that TIGCC is in a state where almost no changes are actually needed. Add to that that (as you said) very few users actually still use TIGCC, and that your behavior is doing everything to demotivate me, and you see why TIGCC is not being committed to.

We (most of us being former TIGCC contributors - some of us have our name in the credits) had correctly identified code base neglect before starting GCC4TI.

The TIGCC code base was not neglected at all before you started GCC4TI. The commit rate had just slowed down because TIGCC had reached a state of maturity. Proposed changes were rejected because they didn't make sense, not out of any kind of neglect. (Accepting the half-assed patches would actually have been neglect.)

It's a fact that we have worked to improve the situation, for the users' benefit.

Nonsense. It is not for the users' benefit that 2 competing projects are working against each other instead of together, nor that you effectively killed the motivation of the only person (me) who was doing serious work on TIGCC. The most needed improvements (newer GCC, continuing KTIGCC development etc.) do not even show up on your list of priorities. Why would I want to do all this hard work just to have it parasited by you, who undoubtedly would market it all as your work?

the GCC4TI Github repository was created at a time the server hosting the project suffered hardware failure. It's not a "fork of the fork" in the classic sense of "fork", though I suppose it is in the weak sense of "fork" brought by Github - anyhow, it's merely a continuation of GCC4TI on another infrastructure, with an up-to-date SCM (the one I've been using since the outset for working on GCC4TI because it's simply more powerful and faster), by the lead developer.

Then why is there no mention of this on the official GCC4TI site? And why is the old SVN repo still up if you aren't pushing to it?

This repository has been in plain sight for more than two years (including in my yAronet signature !), making your recent public provocation about nothing supposedly being done in GCC4TI for more than two years even more ludicrously stupid

The official SVN repository for GCC4TI shows no commits for over 2 years. Fix your site if you want people to actually know that the project is not dead.

(all the more it's a prime example of the pot calling the kettle black - unlike you, I do actual work in the TI community).

It is mainly your fault that I have lost interest in doing anything for the TI community.

since you bring up the unrelated LPG matter... let's have this place record that, no matter what you keep clamoring and lying, as made clear by the original authors of the programs, you - not me - are the one who misappropriated their names in the forks you created more than four years ago,

Where am I misappropriating the names? I am renaming all the projects exactly as you had demanded! And I'm really feeling like a donkey now because this is preventing me from doing any releases (because I never had the time to complete the renames of the applications) whereas you happily release GCC4TI releases which are sprinkled with "TIGCC" all over the place. That's why I'm thinking of changing my strategy and just releasing the stuff as is, even if it says "TiLP" and "TiEmu" in several places. You do not care at all about respecting my project names, why should I respect yours?

And I still believe that I should be the legitimate maintainer of TiLP and TiEmu, because I used to develop those together with Romain for years. I had agreed to rename everything to avoid any trouble, but now that 1. this is preventing me from doing any releases (I had underestimated the amount of effort it would be to rename everything) and 2. you do not honor your part of the deal (which is to stop using the TIGCC name you never had any claim over to begin with), I really don't see why I should honor mine either.

and stopped maintaining after only several months without producing a single release of the full software stack.

You know exactly why there is no release. You forced me to rename everything, and Romain's code has the project names littered literally everywhere. It takes weeks to do the renames and I do not have those weeks of time, nor does your attitude motivate me to take those weeks of time. Of course, the inability to do any releases also does not motivate me to do development there. You forced everything to a halt and now you dare blaming me for that!

On my side, I produced 4 releases of the projects I became the de-facto sole maintainer (instead of co-maintainer) of when your commit privileges were revoked due to your aggressive behaviour against fellow developers and users.

My commit privileges were actually revoked because I asked Tyler to set up a mirror of the repository in case you break something. There was no "aggressive behavior", I was just not OK with you being ranked equal or higher to me in the project when I had been a codeveloper for years (unlike you), and also considering your attitude with respect to TIGCC and GCC4TI. You fork my project (clearly stating that it is because you do not want to work with me) and then you expect me to work together with you on other projects? You gotta be kidding!

4 releases isn't that much, as some projects make a new release every few weeks... but it's infinitely better than 0. All of the releases I produced provide bugfixes, new features and cleanup; they were produced with the help of multiple contributors, mainly Jon and Benjamin.

The contributors' attitude has also demotivated me from working on those projects. In particular, the fact that they submitted their work to the name-usurpating fork rather than to the original project at its new home.

from the users' POV, spending time on reviewing and productive activities is immensely better than spending time on improductive / counter-productive matters. Bringing up to date projects which have been unmaintained for years, otherwise offer zero new feature over GCC4TI and LPG software, and have zero brand recognition (TIGCC does have one, but your unreleased forks of LPG software obviously do not), clearly belongs to the latter category. So does sending the usual provocations which show you have no clue what you're talking about.

If I release them as TiLP 3 and TiEmu 4, they will have name recognition. That is exactly what I am threatening hereby. Stop abusing the TIGCC name!

And by the way, merging the occasional useful commits from your repository will not be that much work, most of the work will actually be filtering out the crap that should never have been committed anywhere. And I still think users are way better off with the original pre-fork versions of the projects (even without any updates) than with your forks and all the regressions they include.

not even backports for bugs crashing users' calculators which have been duly reported to you

Meanwhile, you have left a bug that crashes users' calculators unfixed for now 8 years and 1 month, despite a patch having been sent to you (by me)! http://tichessteamhq.yuku.com/reply/7126/TICTExplorer-140-Beta-series#reply-7126

having a sparse commit history is better than having basically no commits for years, not even backports for bugs crashing users' calculators which have been duly reported to you,

Such as?

For instance, your very own buggy and clearly untested code in __fgetchar. In several dozens of lines, two distinct reasons why the routine would crash, a third reason why it wouldn't work properly anyway. And I learned that it wasn't even the first time something wonky with one of the callers of this routine was reported to you.

All the features which were done properly (not in a half-assed way) have been integrated.

Lie. Among others, my 2002 and 2003 optimizations on sprite routines, derived from common community knowledge and ExtGraph were both correct and trivial. Joey's 2005 further optimizations + feature expansions to the same sprite routines were correct. Optimizations on other code snippets were correct.

Basically all your build system "improvements" are unnecessary and/or actually make things worse.

I see, it's easier to live in denial than to admit that your build system is highly sub-par on multiple accounts...

Micro-optimizations saving less than 10 bytes.

Get a clue before belittling other persons' useful work in such a contemptuous way. For most typical TIGCC/GCC4TI programs, the gain is 16 bytes, as a result of a single optimization in one of the most frequently used bits of the startup code copied across programs (SAVE_SCREEN). The other routines are less frequently used.

You have a history of "optimizations" that break things.

So do you, as you know. Some of your bugs didn't end up in a final release only because I was one of the few testers who tried to compile programs with your new compiler version and noticed the disaster you hadn't noticed due to your inadequate testing. You love criticizing Microsoft's general attitude, but "users are beta-testers" is one of the things they introduced on the marketplace...

Both TIGCC releases (before the fork) and GCC4TI releases have had showstopper bugs due to your poorly-tested optimizations.

"showstopper" is a such an excessive word for a problem I noticed before anyone else did, and for which I quickly pushed an erratum duly mentioned on all official download links ;) BTW, occasional breakage in an evolving project is a fact of software coding, and better than a dead project.

Optimizing away a handful bytes in the library is just a pure waste of time.

Fortunately, you must be the only one thinking that optimizing the startup code ("the _nostub programs' stub", as some would call it), and other library bits also duplicated across programs, is a "pure waste of time" :)

long-overdue work for getting closer to standard libraries and toolchains.

Those are completely unnecessary changes

Get a clue. Simple changes for easing porting work are never wrong...

We uploaded a contrib.zip with all the contributions we received.

Lie. Some of the changes which were re-sent to me for GCC4TI, and integrated at long last, have never been part of that file, otherwise I could have reviewed integrated them earlier.

Anything not included there was simply not properly contributed to us.

Forcing people to contribute through the communication means you want, rather than accepting input through all communication means that you attend, is an obvious no-no for an open source software maintainer. But we already knew it's not like you apply clues about being a good maintainer.

The "general neglect of the code base" just shows that TIGCC is in a state where almost no changes are actually needed.

Software engineering good practices indicate that before the end of the life of a project (which is the phase of all TI-68k programming-related software, nowadays), maintainability changes are important. We did them, you didn't, and it's clear from your messages that you don't even want to take our user-noticeable and maintainer-time-saving modifications...

The TIGCC code base was not neglected at all before you started GCC4TI.

Lie. The build system was a mess, and such basic testing as trying to compile the examples for the first time in years showed multiple build errors, uncovered a compiler bug... not to mention a dozen name collisions for the on-calc binaries. I noticed these name collsisions when performing actual testing of the examples by sending them in bulk quantity; I thought it could prove annoying beyond just me, and fixing the problem was trivial, so I just did it.

The most needed improvements (newer GCC, continuing KTIGCC development etc.) do not even show up on your list of priorities.

As you know, pursuing development of an IDE whose design goal was to remain as compatible as possible with the blunders of the Delphi IDE, based on a huge bloat of a framework (not the default one on most Linux distros, at that) where the majority Windows OS is a second-class citizen, is far from being universally seen as a high-priority task... The cost/benefit ratio of upgrading the compiler is negative (and getting even more negative as time passes by): it might improve optimization in some areas (though there are unresolved post-4.1 pessimization bugs for the m68k target in GCC Bugzilla), but there's a risk of breaking stuff (you did yourself, see above)... and it takes significant coding and testing time for the benefit of very few users. Better spending time on lower-hanging fruit with a more direct impact on the code base. YMMV, as usual.

Why would I want to do all this hard work just to have it parasited by you, who undoubtedly would market it all as your work?

Yeah, sure, as if I had such lack of respect... I don't know who you are trying to convince, as the commit histories of gcc4ti, libti*/gfm/tilp, tiosmod/amspatch and possibly even others make it clear that I don't have such lack of respect :)

Then why is there no mention of this on the official GCC4TI site?

One of the positive effects of not mentioning this on the official GCC4TI site was that as long as you weren't aware of it, your usual negativity and destructiveness (temporarily shown on yAronet before the moderators moderated you in two topics, and shown here) didn't express itself. Folco thought it would be useful to mention GCC4TI, with a link, to an old-timer who recently said "hi" on yAronet (and it was useful for the old-timer), which had the side effect of making you aware of the Git repo linked in my signature for two years... otherwise, you'd still be persuaded that the project is dead. You are so pathologically obsessed about GCC4TI that you started trolling about it and polluting the topic without even bothering to say "hi" to the old-timer until Folco hinted you !

The official SVN repository for GCC4TI shows no commits for over 2 years. Fix your site if you want people to actually know that the project is not dead.

Pretty much only people like you, who attend only tiny, very low-activity areas, fail to read user signatures and fail to get a clue about what they're criticizing (making themselves even more ridiculous in the process), think that the project is dead. Unlike you, we're not attempting to pretend that the project is not dead and lying about it :)

It is mainly your fault that I have lost interest in doing anything for the TI community.

Yeah, sure. We've read that a great too many times. You still haven't understood that your own extremely poor reputation, among people who get along with each other (once all of them have understood your lies and the way you abused the naiveness of some of them) far better than you get along with them, is your own bloody fault. It's not just in the TI community that you're known to be a difficult person (the coined term in FLOSS development is "poisonous person"). We know that you've earned yourself several powerful blows in the Fedora community about your low understanding of other persons' needs. In the TI community, we (all of those whom you're having trouble with, and the ones who have heard of you through extremely negative terms, i.e. all old-timers and many relative newcomers) work far more cooperatively and with many fewer hurt feelings, so it's not us who have an attitude problem...

And I still believe that I should be the legitimate maintainer of TiLP and TiEmu

What you believe about that situation is irrelevant, as you know. You were co-maintainer before you behaved silly.

You forced everything to a halt and now you dare blaming me for that!

Rather, you forced yourself to a halt ;)

without you being such a roadblock on the path of advancing the state of the art of a TI-68k development environment, GCC4TI wouldn't exist in the first place. It's not that we didn't want to work with you - as I duly wrote earlier, most of us are former TIGCC contributors, and tried to contribute more changes;
your forks of LPG software are themselves partially a consequence of GCC4TI, as you wrote above; but if you were more cooperative and more able to take other persons' needs and points of view into account (you got lambasted in the Fedora community for the same), you wouldn't have planned to implement noxious changes, and there would have been no valid reason for revoking your commit privileges after Tyler started the fork on your request. And BTW, far more than myself, the ones who asked you to rename are more entitled about it than I am: the projects' creators and former maintainers, Julien and Romain.

In particular, the fact that they submitted their work to the name-usurpating fork rather than to the original project at its new home.

Repeating your lies won't magically make them true: your stuff is not the original project and its new home, it's a bunch of unmaintained hostile forks, and you are the usurpator.

If I release them as TiLP 3 and TiEmu 4, they will have name recognition.

Ha ha ha. Assuming you ever bother doing that rather than behaving usefully (for just once in a while), any name recognition you could garner through such a stupid move would only be highly negative ;) See, one of the two most hated persons of the community, artificially inflating the version numbers (in a highly ridiculous, desperate attention-whoring move) for his hostile forks not providing any extra features, while still spouting out the usual nonsense about being the legitimate maintainer... that's simply a hopeless move which can only worsen your situation ;)

As already mentioned, renaming tigcc, tigcc.a and ld-tigcc was not done (though in terms of occurrences, the majority was certainly replaced by "GCC4TI" or "TIGCC/GCC4TI" quite a while ago), due to the uselessness of introducing such highly artificial user-level incompatibilities. GCC4TI never intended to be incompatible with TIGCC in any significant way, it has never been (the two incompatibilities that you pointed are not significant) and never will be (because of the lack of TI-68k native code developers nowadays, which makes it hard to justify spending much time on further major code changes).

And by the way, merging the occasional useful commits from your repository will not be that much work, most of the work will actually be filtering out the crap that should never have been committed anywhere.

Unsurprisingly, your FUD tactics haven't changed from nearly five years ago (and your pollution of the ticalc.org GCC4TI announcement news item)... fortunately, it was already just plain silly at the time, and it's even far sillier now that as shown by the commit history, the number of areas in which the code base was improved has been largely expanded. The vast majority of the changes in the commit history do improve the code base, no matter the nonsense you're blurting out. Full stop.

Meanwhile, you have left a bug that crashes users' calculators unfixed for now 8 years and 1 month, despite a patch having been sent to you (by me)!

As you're fully aware, despite the fact you're bringing the matter yet another time:

the bug was fixed immediately on my side by integrating your patch, but then it got stuck in another set of unfinished bugfixes and features (because I was reaching the end of my studies). Granted, I could have published a new version with that sole change... if the bug had any meaningful practical impact. It clearly doesn't, and you still refuse to admit that fact:
the bug occurs only for users of an alpha version of one of the many file explorers of the community (a minority of which work on the 89T) posted on an obscure message board, i.e. an extremely limited set of users, to begin with;
the bug occurs only on calculators whose OS is not patched with your own HW3Patch or my own tiosmod+amspatch and which are not running PreOS (which disables that silly RAM execution protection as well)... Given that a great many other programs don't work without HW3Patch / PreOS, it's standard practice for pretty much everyone to install it. That's what I had done myself for testing, out of habit.

The argument we're having makes me think of something in a way I hadn't thought before in such terms: as a matter of fact, the current status quo, i.e. you doing nothing on either your dead LPG software forks or your dead TIGCC (but doing work / trolling in other communities, such as Fedora/KDE community), and me working on LPG software with the community, without having to rename it, and working on GCC4TI without fully renaming it, minimizes time spent on improductive matters... Also, as usual, both you and me look silly in such arguments...

For instance, your very own buggy and clearly untested code in __fgetchar. In several dozens of lines, two distinct reasons why the routine would crash, a third reason why it wouldn't work properly anyway.

Uhm yes, looks like there are indeed some bugs there. I'll merge your fixes.

And I learned that it wasn't even the first time something wonky with one of the callers of this routine was reported to you.

When would that have been? In the golden times of TIGCC, I usually fixed all the bugs that were reported to me within 24 hours. I don't see how this would have fallen through the cracks.

All the features which were done properly (not in a half-assed way) have been integrated.

Lie. Among others, my 2002 and 2003 optimizations on sprite routines, derived from common community knowledge and ExtGraph were both correct and trivial. Joey's 2005 further optimizations + feature expansions to the same sprite routines were correct. Optimizations on other code snippets were correct.

I was indeed sent a few versions of optimized sprite routines. They all suffered from issues which prevented merging them as is. Either they were significantly larger than the existing routines in TIGCCLIB, because all the conditionals were pulled out of the loops (IIRC, that was the problem with your routines, which were rejected because of that), or they added a lot of new functions and were missing the .hsf files for them (IIRC, that was why Joey's routines were put on hold and added to the set of pending contributions). Thus, sorry, but they fall under the "in a half-assed way" clause.

I see, it's easier to live in denial than to admit that your build system is highly sub-par on multiple accounts...

This just does not matter at all for users. Most users use binary packages in the first place, and for those who build from source, all they need is a script that works. They don't care how it works.

Micro-optimizations saving less than 10 bytes.

Get a clue before belittling other persons' useful work in such a contemptuous way. For most typical TIGCC/GCC4TI programs, the gain is 16 bytes, as a result of a single optimization in one of the most frequently used bits of the startup code copied across programs (SAVE_SCREEN). The other routines are less frequently used.

So you managed to win a whopping 16 bytes, in a place called exactly once (if at all) in any given program. I'm impressed… just kidding! Effective optimizations target places that appear many times in every program, e.g. compiler code generation. All the work we did in TIGCC on avoiding relocations and/or representing them more efficiently, supporting F-Line ROM_CALLs etc. was also effective in that way, but I think we already pretty much maxed that out. Most gains could be had from the compiler, which you basically did not touch at all.

You have a history of "optimizations" that break things.

So do you, as you know. Some of your bugs didn't end up in a final release only because I was one of the few testers who tried to compile programs with your new compiler version and noticed the disaster you hadn't noticed due to your inadequate testing. You love criticizing Microsoft's general attitude, but "users are beta-testers" is one of the things they introduced on the marketplace...

The first GCC betas with most of the faults were shipped separately, as an optional testing update to a TIGCC beta release, i.e. a beta for a beta. Of course these are for testing purposes and will have bugs. Somebody does have to test things at some point. I cannot possibly test all the programs users use TIGCC with (or at least I wasn't able to back then, when there were still a lot of TIGCC users). Thus the call: "Test your programs with this new GCC beta and tell me if anything's broken." Part of the deal was that I'd fix the issues immediately, which I did. I'll also note that part of the "disaster" you talk about was minor optimization regressions in some places, when other programs had hundreds of bytes saved just by using GCC 4.0 rather than 3.4. There were some genuine miscompilations, but most of them were fixed before even reaching a beta release of TIGCC.

And by the way, most of the GCC 4.0 regressions were not my fault to begin with, but upstream GCC's. We provided a working GCC 4 before anybody else, even Fedora. So of course it had some issues, which I fixed within hours of them getting reported. The major optimization improvements in GCC 4 were well worth it.

Both TIGCC releases (before the fork) and GCC4TI releases have had showstopper bugs due to your poorly-tested optimizations.

"showstopper" is a such an excessive word for a problem I noticed before anyone else did, and for which I quickly pushed an erratum duly mentioned on all official download links ;)

The pre-fork TIGCC breakage you caused, on the other hand, included one "optimization" which did not even compile, causing many programs to fail to build at all. Your TIGCCLIB contributions had many bugs and defects, which is why they could not be integrated any faster.

BTW, occasional breakage in an evolving project is a fact of software coding, and better than a dead project.

It's fun how you only apply this to your buggy one-line changes (fault rate per LOC: 100%) and not to the major improvements from GCC 4.

Fortunately, you must be the only one thinking that optimizing the startup code ("the _nostub programs' stub", as some would call it), and other library bits also duplicated across programs, is a "pure waste of time" :)

Your SAVE_SCREEN change saves (according to you) 16 bytes in the average interactive program, 0 bytes in the average non-interactive program. Upgrading to GCC 4.0 saved dozens of bytes in the average program, up to entire kilobytes for large programs. What's the more effective change? Even some straightforward tweaks I made to GCC peepholes, instruction cost estimates or the output for switch statements all saved significantly more than 16 bytes on average.

Your optimization is also totally uninteresting speed-wise because it touches code executed only once at startup and/or termination of the program.

Get a clue. Simple changes for easing porting work are never wrong...

Porting to what? Your bogus "portability" changes don't add support for any additional platforms, some actually make it harder to do such a port. One example is how you changed scripts from #!/bin/bash, which is always the same shell, to #!/bin/sh, which can be pretty much any buggy shell that is remotely Bourne-like or POSIX-like. That most likely actually decreased the set of platforms on which the scripts run (in addition to requiring a lot of other unnecessary changes, some of which degrade the quality of the scripts, such as the need to support versions of echo which don't understand -n, unlike the bash builtin).

We uploaded a contrib.zip with all the contributions we received.

Lie. Some of the changes which were re-sent to me for GCC4TI, and integrated at long last, have never been part of that file, otherwise I could have reviewed integrated them earlier.

Sorry, I should have said: "We uploaded a contrib.zip with all the contributions we received and accepted.", obviously. The ones you miss were rejected.

Forcing people to contribute through the communication means you want, rather than accepting input through all communication means that you attend, is an obvious no-no for an open source software maintainer. But we already knew it's not like you apply clues about being a good maintainer.

Some venues for "contribution", such as unaffiliated forums I can get banned from at any time (and did, repeatedly), are just not appropriate venues.

Software engineering good practices indicate that before the end of the life of a project (which is the phase of all TI- 68k programming-related software, nowadays), maintainability changes are important. We did them, you didn't, and it's clear from your messages that you don't even want to take our user-noticeable and maintainer-time-saving modifications...

The vast majority of your changes don't improve maintainability at all. Some even actually decrease maintainability in the name of misguided "portability", such as the totally useless removal of bash extensions from the scripts or the uglification of the code of your still-unnamed fork of ld-tigcc to pointlessly remove nested functions. (Both TIGCC and GCC4TI can only be compiled with GCC anyway, because GCC doesn't support any other compiler for a cross-GCC build, because bootstrapping is not supported for cross builds. Thus, the removal of GCC extensions from any GCC4TI code is totally silly and counterproductive.) And you did nothing at all to solve the real maintainability issues (reliance on ancient GCC and Binutils releases, reliance of KTIGCC on kdelibs 3, 2 different IDE codebases, the several documentation toolchain issues you are well aware of etc.). All your changes are only chasing windmills.

The TIGCC code base was not neglected at all before you started GCC4TI.

Lie. The build system was a mess, and such basic testing as trying to compile the examples for the first time in years showed multiple build errors, uncovered a compiler bug... not to mention a dozen name collisions for the on-calc binaries. I noticed these name collsisions when performing actual testing of the examples by sending them in bulk quantity; I thought it could prove annoying beyond just me, and fixing the problem was trivial, so I just did it.

Nonsense. I already told you many times that examples are not a test suite. Those examples were never intended to be compiled as is, but rather to serve as a source of inspiration and code snippets for actual user programs. In particular, the name collisions are not a bug! Sending all the examples at once has never been a valid or supported use case. Yet, you still bring those imaginary "bugs" up as a purported evidence of "neglect". So, who's the liar here?

As you know, pursuing development of an IDE whose design goal was to remain as compatible as possible with the blunders of the Delphi IDE, based on a huge bloat of a framework (not the default one on most Linux distros, at that) where the majority Windows OS is a second-class citizen, is far from being universally seen as a high-priority task...

And what alternative do you have to offer? "Just use Eclipse/KDevelop/vim/whatever" is not a reasonable alternative. None of them offers the kind of convenience and integration for TIGCC or GCC4TI development that the TIGCC IDEs offer. If you really think our IDEs are crap, develop a better one!

The cost/benefit ratio of upgrading the compiler is negative (and getting even more negative as time passes by): it might improve optimization in some areas (though there are unresolved post-4.1 pessimization bugs for the m68k target in GCC Bugzilla), but there's a risk of breaking stuff (you did yourself, see above)... and it takes significant coding and testing time for the benefit of very few users.

Making changes to the startup code also requires a lot of testing, which you just haven't done. There are many possible combinations, and (for efficiency reasons) later startup sections can depend on the register state (in extreme cases, including even the status register!) of previous sections. So you need to test all the possible combinations of options, which are exponentially many. This actually takes longer to test properly than a compiler upgrade.

Better spending time on lower-hanging fruit with a more direct impact on the code base. YMMV, as usual.

A higher-hanging fruit (see the previous paragraph) with a less direct impact on the code base (see the paragraphs on the size impact of startup code changes vs. compiler changes), you mean?

Yeah, sure, as if I had such lack of respect... I don't know who you are trying to convince, as the commit histories of gcc4ti, libti*/gfm/tilp, tiosmod/amspatch and possibly even others make it clear that I don't have such lack of respect :)

I have seen your original GCC4TI announcements, where you took the credit for the changes you had just taken from TIGCC CVS HEAD. (And when you mentioned me in passing, it was only for blaming me for not releasing those changes, even though they were not important enough to warrant a release.)

One of the positive effects of not mentioning this on the official GCC4TI site was that as long as you weren't aware of it, your usual negativity and destructiveness (temporarily shown on yAronet before the moderators moderated you in two topics, and shown here) didn't express itself. Folco thought it would be useful to mention GCC4TI, with a link, to an old-timer who recently said "hi" on yAronet (and it was useful for the old-timer), which had the side effect of making you aware of the Git repo linked in my signature for two years... otherwise, you'd still be persuaded that the project is dead.

So you were intentionally hiding your changes from me. That means you cannot reasonably blame me for not having merged any of your new changes into TIGCC CVS yet. (But I can already tell you that the majority will not be merged because they do not bring any benefit.)

You are so pathologically obsessed about GCC4TI that you started trolling about it and polluting the topic without even bothering to say "hi" to the old-timer until Folco hinted you !

The "old-timer" is one of the founding members of TIGCC. Telling him to use a fork of TIGCC is not only a blatant advertisment (at the expense of the real TIGCC), but also an insult to the project he helped creating. In addition, Folco's post also advertised kernel-based programming as if it were still relevant in 2013, and even PedroM (which I think he's the only serious user of). So it was very misleading and painted a completely wrong picture of the current developments in TI calculator programming.

Pretty much only people like you, who attend only tiny, very low-activity areas, fail to read user signatures

Users don't read forum signatures. Users read the project web site, see no commits since 2011 and think the project is dead, exactly like I did.

and fail to get a clue about what they're criticizing (making themselves even more ridiculous in the process), think that the project is dead.

The official site shows no current commits, so it is clearly a dead project. Only this fork of yours is active.

Unlike you, we're not attempting to pretend that the project is not dead and lying about it :)

My project is on hold for lack of time, not dead. I still plan to do improvements and releases, eventually. The current beta of TIGCC is still the one I recommend everyone to use until the next release of the real TIGCC.

And you're not attempting to pretend that the project is not dead and lying about it, you were attempting to pretend that the project is dead and lying about it. ;-)

You still haven't understood that your own extremely poor reputation, among people who get along with each other (once all of them have understood your lies and the way you abused the naiveness of some of them) far better than you get along with them, is your own bloody fault.

This just shows how effective your character assassination is. People blindly believe your populistic personal attacks.

It's not just in the TI community that you're known to be a difficult person (the coined term in FLOSS development is "poisonous person").

When will you finally understand that you are the poisonous person? The best thing you can do to the TI community is leave it.

We know that you've earned yourself several powerful blows in the Fedora community about your low understanding of other persons' needs.

There too, the problem was not me. The problem was the unacceptable attitude and decisions of some FESCo members. There are also other people in Fedora complaining about the same things than me (and I've received private messages of support from even more people who don't dare saying it in public for fear of being ostracized the same way as me).

In the TI community, we (all of those whom you're having trouble with, and the ones who have heard of you through extremely negative terms, i.e. all old-timers and many relative newcomers) work far more cooperatively and with many fewer hurt feelings, so it's not us who have an attitude problem...

Is this the royal plural? All the projects you forked have exactly one active committer: you. So who would be there to cooperate with?

And I still believe that I should be the legitimate maintainer of TiLP and TiEmu

What you believe about that situation is irrelevant, as you know. You were co-maintainer before you behaved silly.

I did not behave in a silly way at all, I was just stating what I thought obvious, i.e. that Romain leaving promoted me from second developer to lead developer. This was just stating the standard rules for community projects, which (to my understanding) TiLP and TiEmu had clearly become at that point. Unfortunately, Romain still treated them as one-man shows, which is IMHO unacceptable and shows a total lack of respect for my huge amount of contributions (and also Tyler's contributions, e.g., he started the GFM, not Romain).

Rather, you forced yourself to a halt ;)

Nonsense. It is you guys' insistence on me renaming everything which is grinding the projects to a halt, no less, no more.

without you being such a roadblock on the path of advancing the state of the art of a TI-68k development environment, GCC4TI wouldn't exist in the first place. It's not that we didn't want to work with you - as I duly wrote earlier, most of us are former TIGCC contributors, and tried to contribute more changes;

You (all) did not try to contribute more changes, you tried to force them in, that's a clear difference. The changes I rejected did not "advance the state of the art", they all had flaws which would have degraded TIGCC's quality (and which now did degrade GCC4TI's, which is why I recommend to use the original TIGCC). You were unable to accept a "no" and kept rehashing the same change proposals over and over even for suggestions with fundamental flaws that of course hadn't changed since the last time this had been discussed. Even for those changes which would have been nice in principle, the implementation was often flawed and/or blatantly incomplete and the submitter refused to fix the flaws resp. implement the missing pieces (often documentation, sometimes required pieces to make the feature work in combination with existing supported TIGCC features the submitter did not care about). That is not what a serious contribution looks like.

your forks of LPG software are themselves partially a consequence of GCC4TI, as you wrote above; but if you were more cooperative and more able to take other persons' needs and points of view into account (you got lambasted in the Fedora community for the same), you wouldn't have planned to implement noxious changes,

None of my planned changes are "noxious". See the list and rationale for yourself: https://www.calcforge.org/trac/emu-tigcc/blog/romain-lievin-leaves

and there would have been no valid reason for revoking your commit privileges after Tyler started the fork on your request.

There was no valid reason for revoking my commit privileges. We did not start a fork, we started a mirror. It was supposed to track the LPG repository 1:1. It was Julien's removal of my commit privileges from the LPG repository which forked the project. (And at that point, I was glad to have the mirror, it allowed quickly responding to that hostile action.)

And BTW, far more than myself, the ones who asked you to rename are more entitled about it than I am: the projects' creators and former maintainers, Julien and Romain.

Romain's actions show that he never really understood the idea of a team project. He even outright admitted that he had only used me as a free developer for what he still considered his personal projects. And he refused to release his power grab even after leaving the projects.

Repeating your lies won't magically make them true: your stuff is not the original project and its new home, it's a bunch of unmaintained hostile forks, and you are the usurpator.

I am not a usurpator, I am the same person who used to develop these things in the past, together with a person who left the community (Romain).

Ha ha ha. Assuming you ever bother doing that rather than behaving usefully (for just once in a while), any name recognition you could garner through such a stupid move would only be highly negative ;) See, one of the two most hated persons of the community, artificially inflating the version numbers (in a highly ridiculous, desperate attention-whoring move) for his hostile forks not providing any extra features, while still spouting out the usual nonsense about being the legitimate maintainer... that's simply a hopeless move which can only worsen your situation ;)

I think it would actually work quite well. People seem to think names are everything or they wouldn't have come to you rather than me with their contributions.

As already mentioned, renaming tigcc, tigcc.a and ld-tigcc was not done (though in terms of occurrences, the majority was certainly replaced by "GCC4TI" or "TIGCC/GCC4TI" quite a while ago), due to the uselessness of introducing such highly artificial user-level incompatibilities.

You keep repeating that lie. That does not justify calling the library TIGCCLIB at user level. Nor are tigcc.a and ld-tigcc names that the user should ever use or see (That's what we have the IDEs and command-line frontends for!), so renaming those to names that do not lie about the nature and origin of the code would not be a user-level incompatibility.

GCC4TI never intended to be incompatible with TIGCC in any significant way,

And that's a big mistake. Projects which expect to use TIGCC should not be getting something clearly different without asking for it. This arrogant misfeature also prevents users from sanely installing GCC4TI in parallel to the real TIGCC (for which I still plan new releases!).

it has never been (the two incompatibilities that you pointed are not significant)

Any incompatibility is significant. TIGCCLIB is guaranteed to be source compatible between releases. Anything that does not fulfill this guarantee is clearly not TIGCCLIB.

and never will be (because of the lack of TI-68k native code developers nowadays, which makes it hard to justify spending much time on further major code changes).

Then just discontinue GCC4TI altogether! Then at least I can work on TIGCC again instead of wasting my time with discussions like this.

Unsurprisingly, your FUD tactics haven't changed from nearly five years ago (and your pollution of the ticalc.org GCC4TI announcement news item)... fortunately, it was already just plain silly at the time, and it's even far sillier now that as shown by the commit history, the number of areas in which the code base was improved has been largely expanded. The vast majority of the changes in the commit history do improve the code base, no matter the nonsense you're blurting out. Full stop.

Of course I have looked at your commit history before stating that. In all of 2013, you made only 4 commits. And your history shows a lot of changes to build scripts etc. which are not user-visible at all, and which I also will not and cannot merge because they break my maintainer workflow.

Meanwhile, you have left a bug that crashes users' calculators unfixed for now 8 years and 1 month, despite a patch having been sent to you (by me)!

As you're fully aware, despite the fact you're bringing the matter yet another time: the bug was fixed immediately on my side by integrating your patch, but then it got stuck in another set of unfinished bugfixes and features (because I was reaching the end of my studies). Granted, I could have published a new version with that sole change... if the bug had any meaningful practical impact. It clearly doesn't, and you still refuse to admit that fact:

I refuse to admit a "fact" that's just plain wrong.

the bug occurs only for users of an alpha version of one of the many file explorers of the community (a minority of which work on the 89T) posted on an obscure message board, i.e. an extremely limited set of users, to begin with;

That file explorer is basically the only one that does not rely on kernels, on HW2Patch/HW3Patch etc. It also used to be the most reliable one before you ruined it. And that alpha version is the only version that was released that works at all on the Titanium. You have also failed to make an actual Titanium-compatible release for over 8 years now.

the bug occurs only on calculators whose OS is not patched with your own HW3Patch or my own tiosmod+amspatch and which are not running PreOS (which disables that silly RAM execution protection as well)... Given that a great many other programs don't work without HW3Patch / PreOS, it's standard practice for pretty much everyone to install it. That's what I had done myself for testing, out of habit.

Working without HW2Patch/HW3Patch has always been one of the TICT Explorer's main features! The code goes through a lot of pain to ensure this. Your alpha release broke this distinctive feature, and fixing it only required a trivial change.

The fact that you haven't noticed this issue shows that you failed to do even the most simple of all tests: Send the program to a fresh TiEmu savestate and run it. TiEmu already had execution protection emulation at that time, which is how I had immediately noticed the issue.

The argument we're having makes me think of something in a way I hadn't thought before in such terms: as a matter of fact, the current status quo, i.e. you doing nothing on either your dead LPG software forks or your dead TIGCC (but doing work / trolling in other communities, such as Fedora/KDE community), and me working on LPG software with the community, without having to rename it, and working on GCC4TI without fully renaming it, minimizes time spent on improductive matters...

Your arrogance will never end. You are not working on anything "with the community", you are the sole committer to your almost-dead projects (only 4 commits to GCC4TI in the last 12 months).

Also, as usual, both you and me look silly in such arguments...

I may look silly, but you are silly.

(EDIT: Quote formatting fixes.)

PS: And while I don't like the existence of GCC4TI in the first place, what irks me the most is how you and your fans (like Folco) keep advertising it as an update for TIGCC, when it is not an update, but a fork. The choice is not between old and new, but between original and fork. The latest TIGCC release happens to be older, but that doesn't make it worse. That is what triggered my reaction on yN, not the mere mention of GCC4TI.

For instance, your very own buggy and clearly untested code in __fgetchar. In several dozens of lines, two distinct reasons why the routine would crash, a third reason why it wouldn't work properly anyway.

Uhm yes, looks like there are indeed some bugs there. I'll merge your fixes.

You already wrote that in the past. Fortunately, users can (and do) rely on GCC4TI.

And I learned that it wasn't even the first time something wonky with one of the callers of this routine was reported to you.

When would that have been?

Find it yourself in your own logs of your IRC chan whose topic line reads "The official TIGCC chan - le chan officiel de TIGCC. Official languages: English, French. Charset: UTF-8. Please post in UTF-8 only, people posting in other charsets will be kickbanned. Posting #tigcc logs to the public or indirectly contributing to such a leak will lead to a permanent ban. No appeals." (and as we all know, the part about publishing logs is there because you use that place to behave even worse than you do publicly)

All the features which were done properly (not in a half-assed way) have been integrated.

Lie. Among others, my 2002 and 2003 optimizations on sprite routines, derived from common community knowledge and ExtGraph were both correct and trivial. Joey's 2005 further optimizations + feature expansions to the same sprite routines were correct. Optimizations on other code snippets were correct.

I was indeed sent a few versions of optimized sprite routines. They all suffered from issues which prevented merging them as is. Either they were significantly larger than the existing routines in TIGCCLIB, because all the conditionals were pulled out of the loops (IIRC, that was the problem with your routines, which were rejected because of that),

You remember incorrectly: the oldest versions only touched the address (offset) computation code in such a way that it became not larger but faster at first, then both smaller and/or faster. As you're aware, the same changes were field-tested in ExtGraph (before the routines were rewritten in ASM) and other libraries.

I see, it's easier to live in denial than to admit that your build system is highly sub-par on multiple accounts...

This just does not matter at all for users. Most users use binary packages in the first place,

Windows users do, but most *nix users don't. Do I need to remind you how ludicrously unpackageable TIGCC is, due to, among other no-nos, its unprefixed executables colliding with system (host) executables, and its reliance on an environment variable ? GCC4TI fixed the collision with host executables.

and for those who build from source, all they need is a script that works. They don't care how it works.

And our script works far better than the one we inherited. It stops upon the first error instead of silently leaving users with a broken build (users care about that), it requires basically no hours-long hand-holding for compiling outside Linux, etc.

We will never agree with each other about the cost/benefit ratio of optimizing the standard library vs. working on the compiler. It's not the first time, but your notes on the size improvements in some programs between the major GCC 3.x and 4.x architectural changes are largely tangential to the matter of upgrading from the 4.1.x: there have been no architectural changes of the same magnitude which could yield similar gains, and there are known m68k regressions on GCC Bugzilla.

long-overdue work for getting closer to standard libraries and toolchains.

Those are completely unnecessary changes

Get a clue. Simple changes for easing porting work are never> wrong...

Porting to what? Your bogus "portability" changes don't add support for any additional platforms,

Hmm... it seems you're interpreting that part of my sentence (re-added for context) as "porting GCC4TI to other platforms", while I meant it primarily as "porting software to TI-68k/AMS", even though I did indeed also remove some non-portabilities from the TIGCC code base. That's a mostly valid interpretation, just not what I meant.

some actually make it harder to do such a port. One example is how you changed scripts from #!/bin/bash, which is always the same shell,

But not necessarily installed out of the box (on some platforms you don't care about). And remind me what she-bang configure scripts, which are among the most portable shell scripts one can find (and are therefore a pattern to follow for portable scripts), use ?

to #!/bin/sh, which can be pretty much any buggy shell that is remotely Bourne-like or POSIX-like.

There's a known largely safe common subset of the language for such shells, you know. A number of simple, mechanical changes get excellent coverage. The extra last mile, for highly weird or outdated platforms, is irrelevant for TIGCC/GCC4TI, as the code of the programs built by the scripts would itself break on those platforms.

That most likely actually decreased the set of platforms on which the scripts run

Silliness. Some platforms barf on your scripts right from not the start due to not finding the interpreter, and even if that is fixed by manual user intervention outside the script, manual intervention inside the scripts is still going to be necessary pretty soon.

(in addition to requiring a lot of other unnecessary changes, some of which degrade the quality of the scripts, such as the need to support versions of echo which don't understand -n, unlike the bash builtin).

Funny how you use the ability to use 'echo -n' as "quality" :)

We uploaded a contrib.zip with all the contributions we received.

Lie. Some of the changes which were re-sent to me for GCC4TI, and integrated at long last, have never been part of that file, otherwise I could have reviewed integrated them earlier.

Sorry, I should have said: "We uploaded a contrib.zip with all the contributions we received and accepted.", obviously. The ones you miss were rejected.

And it's highly disrespectful of both contributors and users of not uploading them anywhere. Basically, all of the contributions, even the rejected ones, were useful to someone.

Forcing people to contribute through the communication means you want, rather than accepting input through all communication means that you attend, is an obvious no-no for an open source software maintainer. But we already knew it's not like you apply clues about being a good maintainer.

Some venues for "contribution", such as unaffiliated forums I can get banned from at any time (and did, repeatedly), are just not appropriate venues.

And ? You can just store every report or contribution seriously, whatever the place.

Software engineering good practices indicate that before the end of the life of a project (which is the phase of all TI-68k programming-related software, nowadays), maintainability changes are important. We did them, you didn't, and it's clear from your messages that you don't even want to take our user-noticeable and maintainer-time-saving modifications...

The vast majority of your changes don't improve maintainability at all.

In your opinion.

Some even actually decrease maintainability in the name of misguided "portability", such as the totally useless removal of bash extensions from the scripts

Using bash for portable scripts is a known anti-pattern. Full stop.

or the uglification of the code of your still-unnamed fork of ld-tigcc to pointlessly remove nested functions. (Both TIGCC and GCC4TI can only be compiled with GCC anyway, because GCC doesn't support any other compiler for a cross-GCC build, because bootstrapping is not supported for cross builds. Thus, the removal of GCC extensions from any GCC4TI code is totally silly and counterproductive.)

In your opinion. Nested functions are ugly, and some diversity compiling code bases doesn't hurt: as you should know, in general, GCC and Clang provide different diagnostics (which is definitely interesting sometimes), and Clang is even forcing GCC to improve.

And you did nothing at all to solve the real maintainability issues (reliance on ancient GCC and Binutils releases,

GCC is hard to upgrade and the upgrade has dubious cost/benefit ratio.

reliance of KTIGCC on kdelibs 3, 2 different IDE codebases,

Developer reliance on KDE is a problem for users, to begin with.

the several documentation toolchain issues you are well aware of

You neglect to mention that I did perform work on the documentation system, though not in the way you envisioned. I nullified the largest issue, causing difficulty in making and integrating any large contribution which moved files across headers (my own contributions being, by far, the largest block of that kind). Rewriting a new documentation system takes time for little gain, it's something which should have been done nearly a decade ago.

etc.). All your changes are only chasing windmills.

In your opinion.

The TIGCC code base was not neglected at all before you started GCC4TI.

Lie. The build system was a mess, and such basic testing as trying to compile the examples for the first time in years showed multiple build errors, uncovered a compiler bug... not to mention a dozen name collisions for the on-calc binaries. I noticed these name collisions when performing actual testing of the examples by sending them in bulk quantity; I thought it could prove annoying beyond just me, and fixing the problem was trivial, so I just did it.

Nonsense. I already told you many times that examples are not a test suite.

I replied equally many times that while it's not the goal you assign them, one can nevertheless take advantage of them, as some sort of "level 0" test suite. You clearly didn't even do that, given the poor results my experience yielded.

Also, I added a test suite for select code snippets ;)

Those examples were never intended to be compiled as is, but rather to serve as a source of inspiration and code snippets for actual user programs.

Assuming that was Zeljko's intention, it's silly in the first place. Also, why provide an entire folder containing ready-made source files and TPR files (the latter were added in post-Zeljko times), if they're not meant to be compiled and executed unmodified ? Even hello world examples, which are just about the first thing one tries to compile and run ?

If you want to be coherent with your statements, then remove the examples folder from the installed code base, keep them only in the documentation...

In particular, the name collisions are not a bug!

They're a user annoyance. YMMV on considering it a bug.

Sending all the examples at once has never been a valid or supported use case.

Bad for you.

Yet, you still bring those imaginary "bugs" up as a purported evidence of "neglect". So, who's the liar here?

You, by still pretending that user-visible issues are imaginary.

As you know, pursuing development of an IDE whose design goal was to remain as compatible as possible with the blunders of the Delphi IDE, based on a huge bloat of a framework (not the default one on most Linux distros, at that) where the majority Windows OS is a second-class citizen, is far from being universally seen as a high-priority task...

And what alternative do you have to offer? "Just use Eclipse/KDevelop/vim/whatever" is not a reasonable alternative. None of them offers the kind of convenience and integration for TIGCC or GCC4TI development that the TIGCC IDEs offer. If you really think our IDEs are crap, develop a better one!

As you remember, developing another IDE has been a wish list item from the beginning. However, since the community largely died two years before GCC4TI, it's one of the things which never got done due to high cost and low number of users.

The cost/benefit ratio of upgrading the compiler is negative (and getting even more negative as time passes by): it might improve optimization in some areas (though there are unresolved post-4.1 pessimization bugs for the m68k target in GCC Bugzilla), but there's a risk of breaking stuff (you did yourself, see above)... and it takes significant coding and testing time for the benefit of very few users.

Making changes to the startup code also requires a lot of testing, which you just haven't done. There are many possible combinations, and (for efficiency reasons) later startup sections can depend on the register state (in extreme cases, including even the status register!) of previous sections. So you need to test all the possible combinations of options, which are exponentially many. This actually takes longer to test properly than a compiler upgrade.

Let's examine the 7 changes made in GCC4TI somewhere under the trunk/tigcc/archive/startup path, shall we... 1) the addition of the FlashOS library - irrelevant to the current discussion; 2) a commit which changes line ending properties - non-functional change, irrelevant to the current discussion; 3) the 16-byte SAVE_SCREEN optimization, for which simple usage of grep and a relatively short of analysis of the couple dozen lines of output (at the time), opening several files in the process to check more thoroughly indicates that there is no other relevant dependency on a2 (whose usage this commit removed in this code path); 4) next commit: 10-byte Common Subexpression Elimination on the internal F-Line emulator setup and teardown code. Folco and I added back a usage of a2, but that works per the previous item; 5) support for MIN_AMS=301 and MIN_AMS=310. Trivial copy&paste&adjust of other similar code snippets with same section number; 6) optimize clr.l dn -> moveq #0,dn in _execute_in_ghost_space.s: no behavioral change, as you're aware; 7) later, further optimization of __execute_in_ghost_space: a) my field-proven left shift + N SR bit testing code snippet for detecting VTI (part of my patch for reducing the size of the standalone VTI detection code from 32 to 20 bytes); b) a brand-new replacement of move.w -2(a0),d1 followed 5 lines later by movea.l 0xC8,%a0 by the move.w -(a0),d1, locally equivalent due to the later destruction of a0.

=> no need for exponentially complex testing. Unit testing of the SAVE_SCREEN optimization, the internal F-Line emulator and the other changes (which we did, of course, perform) does the job. Get a clue.

Better spending time on lower-hanging fruit with a more direct impact on the code base. YMMV, as usual. A higher-hanging fruit (see the previous paragraph) with a less direct impact on the code base (see the paragraphs on the size impact of startup code changes vs. compiler changes), you mean? See my paragraph about the 4.1.x -> later changes being less clear of a win than 3.x -> 4.0/4.1. Besides, we have long agreed to disagree.

Yeah, sure, as if I had such lack of respect... I don't know who you are trying to convince, as the commit histories of gcc4ti, libti*/gfm/tilp, tiosmod/amspatch and possibly even others make it clear that I don't have such lack of respect :)

I have seen your original GCC4TI announcements, where you took the credit for the changes you had just taken from TIGCC CVS HEAD.

I did indeed tell users that the unreleased fixes were now available to them, and there's no problem to be seen with that. So perhaps you'd have wanted me to write explicitly what everybody knew anyway ?

(And when you mentioned me in passing, it was only for blaming me for not releasing those changes,

At the time, two years were an important amount of time between TIGCC (beta) releases.

One of the positive effects of not mentioning this on the official GCC4TI site was that as long as you weren't aware of it, your usual negativity and destructiveness (temporarily shown on yAronet before the moderators moderated you in two topics, and shown here) didn't express itself. Folco thought it would be useful to mention GCC4TI, with a link, to an old-timer who recently said "hi" on yAronet (and it was useful for the old-timer), which had the side effect of making you aware of the Git repo linked in my signature for two years... otherwise, you'd still be persuaded that the project is dead.

So you were intentionally hiding your changes from me.

Passively, among the things I refrain from posting to yAronet to prevent your pollutions and racking up everybody's nerves. Remember ExtendeD's 2010 note about the community attending the places it finds itself comfortable in (i.e. moving from yAronet, which was at the forefront of Nspire reverse-engineering at the beginning of 2010, to the much friendlier Omnimaga where disrespect is strongly punished) ? It was directed at you.

That means you cannot reasonably blame me for not having merged any of your new changes into TIGCC CVS yet.

You didn't even bother to get to obtain even superficial, continued knowledge of what you criticize so madly. You act this way with other pieces of software / real-world equipment than GCC4TI, that said, as shown by the topics in the General discussions sections of yAronet.

(But I can already tell you that the majority will not be merged because they do not bring any benefit.)

That's your problem.

You are so pathologically obsessed about GCC4TI that you started trolling about it and polluting the topic without even bothering to say "hi" to the old-timer until Folco hinted you !

The "old-timer" is one of the founding members of TIGCC. Telling him to use a fork of TIGCC is not only a blatant advertisment (at the expense of the real TIGCC), but also an insult to the project he helped creating.

BlueZ would rather know that something he worked on in the distant past is still being taken care of, even if that's in another project.

In addition, Folco's post also advertised kernel-based programming as if it were still relevant in 2013, and even PedroM (which I think he's the only serious user of). So it was very misleading and painted a completely wrong picture of the current developments in TI calculator programming.

You're the only one seeing much wrong in this depiction to someone who hasn't attended the community for the better part of a decade and wasn't aware of such developments.

Pretty much only people like you, who attend only tiny, very low-activity areas, fail to read user signatures

Users don't read forum signatures. Users read the project web site, see no commits since 2011 and think the project is dead, exactly like I did.

You're not a standard user.

Unlike you, we're not attempting to pretend that the project is not dead and lying about it :)

My project is on hold for lack of time, not dead.

Yeah, riiight.

You still haven't understood that your own extremely poor reputation, among people who get along with each other (once all of them have understood your lies and the way you abused the naiveness of some of them) far better than you get along with them, is your own bloody fault.

This just shows how effective your character assassination is. People blindly believe your populistic personal attacks.

Your usual denial and reality distortion field. Explanations about your noxiousness are always backed by facts, you know - and in that area, facts galore.

It's not just in the TI community that you're known to be a difficult person (the coined term in FLOSS development is "poisonous person").

When will you finally understand that you are the poisonous person?

When that is true for me. Fortunately, it isn't true for me, and anyway, other people will keep me in check far before I become remotely as much of a prick as you've been since ~2000.

The best thing you can do to the TI community is leave it.

Yeah, riiight. It's something you should apply to yourself, rather. There's nobody in a community which cannot be replaced, but nowadays, the fact is that you're far easier to replace than I am.

We know that you've earned yourself several powerful blows in the Fedora community about your low understanding of other persons' needs.

There too, the problem was not me. [...]

And more denial...

In the TI community, we (all of those whom you're having trouble with, and the ones who have heard of you through extremely negative terms, i.e. all old-timers and many relative newcomers) work far more cooperatively and with many fewer hurt feelings, so it's not us who have an attitude problem...

Is this the royal plural? All the projects you forked have exactly one active committer: you. So who would be there to cooperate with?

Hint: cooperation extends far beyond commits.

[snip more things we have a different vision of]

your forks of LPG software are themselves partially a consequence of GCC4TI, as you wrote above; but if you were more cooperative and more able to take other persons' needs and points of view into account (you got lambasted in the Fedora community for the same), you wouldn't have planned to implement noxious changes,

None of my planned changes are "noxious".

In your opinion. I know your list well, but a number of us thought that your changes are noxious.

[snip more things we have a different vision of]

Ha ha ha. Assuming you ever bother doing that rather than behaving usefully (for just once in a while), any name recognition you could garner through such a stupid move would only be highly negative ;) See, one of the two most hated persons of the community, artificially inflating the version numbers (in a highly ridiculous, desperate attention-whoring move) for his hostile forks not providing any extra features, while still spouting out the usual nonsense about being the legitimate maintainer... that's simply a hopeless move which can only worsen your situation ;)

I think it would actually work quite well. People seem to think names are everything or they wouldn't have come to you rather than me with their contributions.

Pfft. You still refuse to even think that you're doing things wrong and that names are not the only reason why people are working with me on LPG software (let alone why people have worked and are still occasionally working with me on GCC4TI, which does not have and will never have the recognition of TIGCC). For the record, I'm OK with GCC4TI not reaching the recognition of TIGCC - I'm not working on software for recognition and fame.

And no, it cannot work well for you in a community where many have known you in negative terms for years (well before GCC4TI). The dick move of releasing your forks under the inappropriate names and with an artificially increased version number (effectively treating users as so lowly that they could fall immediately for a higher version number meaning it must be better) would only worsen your reputation further :)

As already mentioned, renaming tigcc, tigcc.a and ld-tigcc was not done (though in terms of occurrences, the majority was certainly replaced by "GCC4TI" or "TIGCC/GCC4TI" quite a while ago), due to the uselessness of introducing such highly artificial user-level incompatibilities.

You keep repeating that lie. That does not justify calling the library TIGCCLIB at user level. Nor are tigcc.a and ld-tigcc names that the user should ever use or see

But they (seldom) do, even if you say it's unsupported.

(That's what we have the IDEs and command-line frontends for!), so renaming those to names that do not lie about the nature and origin of the code would not be a user-level incompatibility.

It is an incompatibility. Full stop.

GCC4TI never intended to be incompatible with TIGCC in any significant way,

And that's a big mistake.

Of course not.

Projects which expect to use TIGCC should not be getting something clearly different without asking for it. This arrogant misfeature also prevents users from sanely installing GCC4TI in parallel to the real TIGCC

Reliance on the TIGCC environment variable on both sides (we obviously didn't rename the environment variable for the usual reason of not adding needless artificial incompatibility, and we also didn't fix reliance on an environment variable in the first place) already does that anyway, you know.

(for which I still plan new releases!).

You keep pretending to plan new releases, rather.

it has never been (the two incompatibilities that you pointed are not significant)

Any incompatibility is significant.

We agree to disagree on that.

and never will be (because of the lack of TI-68k native code developers nowadays, which makes it hard to justify spending much time on further major code changes).

Then just discontinue GCC4TI altogether!

Rather, you should just discontinue TIGCC.

Then at least I can work on TIGCC again instead of wasting my time with discussions like this.

Remind me who exactly started this "discussion", as usual ?

Unsurprisingly, your FUD tactics haven't changed from nearly five years ago (and your pollution of the ticalc.org GCC4TI announcement news item)... fortunately, it was already just plain silly at the time, and it's even far sillier now that as shown by the commit history, the number of areas in which the code base was improved has been largely expanded. The vast majority of the changes in the commit history do improve the code base, no matter the nonsense you're blurting out. Full stop.

Of course I have looked at your commit history before stating that.

Almost looks as if not.

In all of 2013, you made only 4 commits.

Fact - for now.

And your history shows a lot of changes to build scripts etc. which are not user-visible at all,

That one is simply a lie which flies in the face of facts, sorry.

and which I also will not and cannot merge because they break my maintainer workflow.

The maintainer workflow hasn't changed much, actually. It's just more reliable and automated :) The difficulty of building the code base and the difficulty of making releases are sore thumbs we had correctly identified before starting GCC4TI, and we have worked on addressing them.

[snip] the usual disagreement about TICT-Explorer

The argument we're having makes me think of something in a way I hadn't thought before in such terms: as a matter of fact, the current status quo, i.e. you doing nothing on either your dead LPG software forks or your dead TIGCC (but doing work / trolling in other communities, such as Fedora/KDE community), and me working on LPG software with the community, without having to rename it, and working on GCC4TI without fully renaming it, minimizes time spent on improductive matters...

Your arrogance will never end. You are not working on anything "with the community", you are the sole committer to your almost-dead projects (only 4 commits to GCC4TI in the last 12 months).

I am infrequently using arrogance, in fact - and in this instance, it's because of your own arrogance ;) If you were still part of the wider community, you'd have a clue.

keep advertising it as an update for TIGCC, when it is not an update, but a fork.

Both an update and a fork, in fact.

The choice is not between old and new, but between original and fork.

Between outdated and unmaintained for practical purposes, and more up to date with more features and fewer bugs.

The latest TIGCC release happens to be older, but that doesn't make it worse.

Hmm, so the latest TIGCC release has known bugs (all of those which were fixed since it was produced nearly seven years ago, among which crasher bugs) but it's not worse than GCC4TI, which contains said fixes and a number of other user-visible improvements in multiple areas ?

(and as we all know, the part about publishing logs is there because you use that place to behave even worse than you do publicly)

No, it is because I and other users have been quoted out of context in a defamatory context and/or to make fun of us. And also because I consider such logging or quoting a violation of privacy. It is as if I sat at a table in a restaurant, talking to other people, one of whom secretly records everything on a dictaphone and broadcasts it (or worse, misleadingly selected portions of it) over the restaurant's music equipment or even on worldwide TV. Why would the digital equivalent be any more acceptable than that?

Now if you just give me the date of the discussion you're thinking of, I can find it in my own personal logs.

You remember incorrectly: the oldest versions only touched the address (offset) computation code in such a way that it became not larger but faster at first, then both smaller and/or faster.

There definitely was some issue with your submissions or they would have been merged. I don't remember the details of every rejected submission.

Windows users do, but most *nix users don't. Do I need to remind you how ludicrously unpackageable TIGCC is, due to, among other no-nos, its unprefixed executables colliding with system (host) executables, and its reliance on an environment variable ? GCC4TI fixed the collision with host executables.

There is no collision with host executables, the TIGCC executables live in their own prefix along with the whole of TIGCC (and that's how all the cross compilers are set up in Fedora). This is a totally pointless change. (And in addition, you contradict yourself: Elsewhere, you claim you cannot rename ld-tigcc because of people invoking it directly, yet you happily break the compatibility for those invoking TIGCC's gcc directly (with the full path). Both are exactly in the same situation. Neither is supported by TIGCC.)

It's not the first time, but your notes on the size improvements in some programs between the major GCC 3.x and 4.x architectural changes are largely tangential to the matter of upgrading from the 4.1.x: there have been no architectural changes of the same magnitude which could yield similar gains, and there are known m68k regressions on GCC Bugzilla.

If you really think upstream GCC's improvements are not useful, then do your own work on the compiler. There is definitely area for improvement in the m68k backend. (It's GCC's oldest backend, the very first beta release of GCC was for m68k only!) But of course, working on GCC requires technical competence…

Hmm... it seems you're interpreting that part of my sentence (re-added for context) as "porting GCC4TI to other platforms", while I meant it primarily as "porting software to TI-68k/AMS",

Increasing ISO C compatibility to ease porting PC software is a good thing, but not at the expense of backwards compatibility with the large already existing TIGCC-using codebase! If you're going to make some incompatible changes to increase ISO C compatibility, you have to make them dependent on a flag (that would be off by default).

But not necessarily installed out of the box (on some platforms you don't care about). And remind me what she-bang configure scripts, which are among the most portable shell scripts one can find (and are therefore a pattern to follow for portable scripts), use ?

Have you ever actually tried to read a configure script??? Those are autogenerated for a reason. Just look into one of them! They are exactly the proof that supporting all possible and imaginable sh shells is not maintainable! They are full of ugly complicated workarounds for buggy shells.

Silliness. Some platforms barf on your scripts right from not the start due to not finding the interpreter,

Of course running something without its dependencies will fail. You also cannot compile TIGCC without GCC or without a libc. I don't see how something as basic and portable as bash is an unacceptable dependency.

and even if that is fixed by manual user intervention outside the script, manual intervention inside the scripts is still going to be necessary pretty soon.

Not true. The changes in the scripts only became necessary after you stopped requiring bash, because then, instead of the bash builtins, you got crappy system binaries for commands like echo.

Funny how you use the ability to use 'echo -n' as "quality" :)

Something like this:

Do you want to do xyz?
(y/n)

looks just broken. It should say:

Do you want to do xyz? (y/n)

in one line. That's what echo -n is for.

And it's highly disrespectful of both contributors and users of not uploading them anywhere. Basically, all of the contributions, even the rejected ones, were useful to someone.

It just does not make sense to track rejected contributions. contrib.zip collects the pending contributions (that were accepted in principle, but required manual work to get merged, usually related to .hsf files), that's what it is for. Anything discarded from that set is deleted from the ZIP (and obviously, everything rejected from the outstart never got added to the ZIP in the first place). Collecting rejected contributions would bring no benefit to the TIGCC project. And users should generally not use them, as there is a reason why the contributions were rejected!

Using bash for portable scripts is a known anti-pattern. Full stop.

In your opinion.

Developer reliance on KDE is a problem for users, to begin with.

-1. The KDE libraries are the best framework available to developers, thus allowing to provide the best IDE possible to our users. In addition, KDE Plasma Desktop is the most popular GNU/Linux desktop environment according to surveys; applications using the KDE libraries integrate much better into that than ones using any other framework.

You neglect to mention that I did perform work on the documentation system, though not in the way you envisioned. I nullified the largest issue, causing difficulty in making and integrating any large contribution which moved files across headers (my own contributions being, by far, the largest block of that kind). Rewriting a new documentation system takes time for little gain, it's something which should have been done nearly a decade ago.

I indeed forgot to mention your change, which only worsens the issue instead of fixing it, because it requires updating all the files even when you move a group of related functions from one header (usually unknown.h) to another. What needs to happen is to remove the requirement for specifying the header file for every function one links to. You did the exact opposite.

Assuming that was Zeljko's intention, it's silly in the first place. Also, why provide an entire folder containing ready- made source files and TPR files (the latter were added in post-Zeljko times), if they're not meant to be compiled and executed unmodified ?

Because the TPR file is the way to open the example in the IDE, in order to read its code and copy snippets from it! (Of course, if you don't use the IDE because you hate it or the libraries it is based on, you don't understand that.)

They're a user annoyance. YMMV on considering it a bug.

Why would one want to send the whole examples folder to the calculator? That just doesn't make sense as a use case. (Most of) the examples are not end user programs. (There are a couple which are standalone games also released for end users on ticalc.org, where end-user-targeted programs belong.)

As you remember, developing another IDE has been a wish list item from the beginning. However, since the community largely died two years before GCC4TI, it's one of the things which never got done due to high cost and low number of users.

Then you have to maintain the existing ones. Telling users to just use the command line is not acceptable.

Passively, among the things I refrain from posting to yAronet to prevent your pollutions and racking up everybody's nerves.

Yeah right, it's "pollution" when one disagrees with you, LOL. And FYI, I got banned from yN again this week, so feel free to go back there to post your ads and FUD.

You're the only one seeing much wrong in this depiction to someone who hasn't attended the community for the better part of a decade and wasn't aware of such developments.

The issue is that Folco selected a small and misleading subset of what happened during that decade. He did not mention things such as:

the new TIGCC linker (since version 0.95) and its features,
support for C debugging (probably the most asked-for TIGCC feature ever) through TIGCC 0.96 Beta 4 or newer and TiEmu+GDB,
the fact that "kernels" have been rendered mostly obsolete by TIGCC and TIGCCLIB development.

Users don't read forum signatures. Users read the project web site, see no commits since 2011 and think the project is dead, exactly like I did.

You're not a standard user.

I never claimed that. I only claimed that standard users are no more likely to read your forum signature than I am. (In fact they're less likely to do that!)

You keep repeating that lie. That does not justify calling the library TIGCCLIB at user level. Nor are tigcc.a and ld-tigcc names that the user should ever use or see

But they (seldom) do, even if you say it's unsupported.

That does not justify calling the library TIGCCLIB at user level.

(That's what we have the IDEs and command-line frontends for!), so renaming those to names that do not lie about the nature and origin of the code would not be a user-level incompatibility.

It is an incompatibility. Full stop.

That's just a lame excuse for misusing a name you don't own. (If you actually cared about invoking internal executables, you wouldn't have done the pointless rename of the GCC and Binutils ones.)

Reliance on the TIGCC environment variable on both sides (we obviously didn't rename the environment variable for the usual reason of not adding needless artificial incompatibility, and we also didn't fix reliance on an environment variable in the first place) already does that anyway, you know.

You are supposed to rename $TIGCC and tigcc too, exactly for that reason.

Programs should get TIGCC if they ask for TIGCC and GCC4TI if they ask for GCC4TI, period. And users should be free to install the 2 totally different projects in parallel.

And your history shows a lot of changes to build scripts etc. which are not user-visible at all,

That one is simply a lie which flies in the face of facts, sorry.

Huh? I did not say that the history contains only such changes, but that it contains a lot of them, and it definitely does. Check for yourself if you don't even remember what you committed to your own project!

The maintainer workflow hasn't changed much, actually. It's just more reliable and automated :)

Your changes definitely do break my workflow. For example, they completely change the way documentation generation is handled.

Hmm, so the latest TIGCC release has known bugs (all of those which were fixed since it was produced nearly seven years ago, among which crasher bugs) but it's not worse than GCC4TI, which contains said fixes and a number of other user-visible improvements in multiple areas ?

GCC4TI contains a lot of changes which make it worse than TIGCC. Those changes all have been or would have been rejected when submitted to TIGCC. It also contains a small set of minor bugfixes, but those do not compensate for the overall degradation of quality.

(and as we all know, the part about publishing logs is there because you use that place to behave even worse than you do publicly)

No, it is because I and other users have been quoted out of context in a defamatory context and/or to make fun of us.

How convenient of an excuse ;) Perhaps the problem was with the content you posted, though ? Just sayin'...

Now if you just give me the date of the discussion you're thinking of, I can find it in my own personal logs.

I assume this is an exceptional, explicit grant to post information extracted from the logs, so I can tell you it was right in the timeframe of me making the fix to __fgetchar and committing it to GCC4TI. Or perhaps you could simply grep for the function's name, or the name of its caller ?

Windows users do, but most *nix users don't. Do I need to remind you how ludicrously unpackageable TIGCC is, due to, among other no-nos, its unprefixed executables colliding with system (host) executables, and its reliance on an environment variable ? GCC4TI fixed the collision with host executables.

There is no collision with host executables,

A user (and remember, *nix users) was worried he broke his computer because he did the mistake of adding $TIGCC/bin before /usr/bin in the path (despite the warning in the documentation). It was easy to fix for us, it wasn't easy to fix for him; it's no good that such things can occur in the first place.

But of course, working on GCC requires technical competence...

It's far from being the first time you're writing I'm not technically competent. It's specifically one of the things I had in mind when pointing your arrogance - I know of some people more competent than I am, but I'm not that incompetent ;)

Hmm... it seems you're interpreting that part of my sentence (re-added for context) as "porting GCC4TI to other platforms", while I meant it primarily as "porting software to TI-68k/AMS",

Increasing ISO C compatibility to ease porting PC software is a good thing, but not at the expense of backwards compatibility with the large already existing TIGCC-using codebase! If you're going to make some incompatible changes to increase ISO C compatibility, you have to make them dependent on a flag (that would be off by default).

The library part of changes I was referring to doesn't impact backwards compatibility. Adding a prefix to the toolchain's internal executables (should never have been different, all well-behaved cross-toolchains do it), does indeed break the use case of calling the internal executables directly, and it's impossible to add compatibility symlinks (without colliding with system executables if $TIGCC/bin is misplaced in the path, see previous paragraph). In return, among other things, no need to shoehorn yet more ad-hoc modes and yet more specific behaviour into the tigcc front-end...

But not necessarily installed out of the box (on some platforms you don't care about). And remind me what she-bang configure scripts, which are among the most portable shell scripts one can find (and are therefore a pattern to follow for portable scripts), use ?

Have you ever actually tried to read a configure script???

Obviously, hence my note about "The extra last mile, for highly weird or outdated platforms". We did the simple bash -> sh changes for getting the scripts to parse and execute with platform sh on (at least) Linux (including the lightweight Debian dash), MacOS X, FreeBSD, OpenSolaris... and then more changes.

and even if that is fixed by manual user intervention outside the script, manual intervention inside the scripts is still going to be necessary pretty soon.

Not true. The changes in the scripts only became necessary after you stopped requiring bash, because then, instead of the bash builtins, you got crappy system binaries for commands like echo.

Get a clue by looking at the scripts, and find things which are not required by the bash -> sh move, but required for the script to work outside the box on non-Linux platforms (or for merely canadian-cross-compiling - another use case we support while you don't), or required for erroring out on the first error and silently leaving users with broken builds (wasting both their time and maintainer time debugging their problems), etc.

And it's highly disrespectful of both contributors and users of not uploading them anywhere. Basically, all of the contributions, even the rejected ones, were useful to someone.

It just does not make sense to track rejected contributions.

For you, it doesn't. For others, it does.

And users should generally not use them, as there is a reason why the contributions were rejected!

Not necessarily a good one...

As for KDE, the surveys that I know of don't paint such a wide usage of KDE even among Linux distros. It might be more popular than any single other DE (?, even though KDE remains a second-class citizen in most distros), but considering the sheer number of people who use Gnome Shell / MATE / Cinnamon, KDE Plasma remains still a minority. Also, KDE is a buggy dwarf on Windows and MacOS X, and doesn't exist on Android + Chrome OS. All three families are (far) more used by actual users than desktop Linux. And even on many-GB hard drives, having to install up to several hundreds of MBs of packages just for a tiny IDE (not everybody has such good Internet connections as French people, or as academics such as you) does not strike as user-friendly. I know some users are turned off by having to download loads of data.

You neglect to mention that I did perform work on the documentation system, though not in the way you envisioned. I nullified the largest issue, causing difficulty in making and integrating any large contribution which moved files across headers (my own contributions being, by far, the largest block of that kind). Rewriting a new documentation system takes time for little gain, it's something which should have been done nearly a decade ago.

I indeed forgot to mention your change, which only worsens the issue instead of fixing it, because it requires updating all the files even when you move a group of related functions from one header (usually unknown.h) to another. What needs to happen is to remove the requirement for specifying the header file for every function one links to. You did the exact opposite.

As you know:

under the new scheme for links, updating other files when moving one or more file is trivial - a single sed / perl / equivalent one-liner per file. The new scheme, whose implementation didn't take long (and besides, allowed me to practice more Perl), allowed forward progress without having to spend full-time days on rewriting a set of C++ documentation tools, fixing the annoyances of the existing Delphi tools in the process. It wasn't worth the trouble to rewrite everything by myself, but YMMV.
years ago, I did contribute my operational knowledge of the documentation system, and some code, into early work on a rewrite of a set of documentation tools, started by someone else. With my contribution, the tools choked on far fewer documentation files. Both them and me had other items on our respective plates and the rewrite never got finished.

In both cases, I did something about the situation.

Assuming that was Zeljko's intention, it's silly in the first place. Also, why provide an entire folder containing ready-made source files and TPR files (the latter were added in post-Zeljko times), if they're not meant to be compiled and executed unmodified ?

Because the TPR file is the way to open the example in the IDE, in order to read its code and copy snippets from it!

The code is already embedded in the documentation; and I know of some users who will try to compile and run the program before attempting to copy snippets.

Passively, among the things I refrain from posting to yAronet to prevent your pollutions and racking up everybody's nerves.

Yeah right, it's "pollution" when one disagrees with you, LOL

Pollution is not about the disagreement, it's about constant trolling (not just in the TI calculators section), refusal to agree with real-world facts pointed to you multiple times and backed by real-world evidence (e.g. in the energy topic, solar photovoltaic panels and windmills are not the panacea you keep promoting due to their high environmental costs), and the general destructiveness you display on TIGCC/GCC4TI, LPG software, Ndless (attacking common sense: ExtendeD and geogeo obviously did it right not to publish raw 0-day vulnerabilities immediately so that TI could fix them right away - that way, one of them could be leveraged by Nleash and later the second generation of Ndless) and other developments.

And FYI, I got banned from yN again this week

Oh, you got yourself banned again, for the third time ? "Congratulations" :) Getting banned from yAronet even once is quite an achievement, if a highly negative one. From the history of the few persons who ever got banned from yAronet, it means that one has really misbehaved in such a way that the pain was too high for the moderators (which means it was too high for non-moderator users, in the first place).

so feel free to go back there to post your ads and FUD.

I plan on restarting occasional cross-posting of some news items from elsewhere, which I stopped when you returned last time, due to the immediate attack showing that you hadn't changed, posted in one of my cross-posted topics. Also, browsing nearly a year and a half of Nspire community developments (hundreds of items) to sort out the most interesting items (dozens of items) and summarize them would be a good thing for yAronet old-timers, to whom a single topic was posted in the relevant section since your previous return...

And your history shows a lot of changes to build scripts etc. which are not user-visible at all,

That one is simply a lie which flies in the face of facts, sorry.

Huh? I did not say that the history contains only such changes, but that it contains a lot of them, and it definitely does.

Previous items in the discussion showed that you have a wrong assessment of "user-visible". Or perhaps you meant that by fixing your blunders (scripts which don't work outside of Linux, which silently leave users with broken builds, a lengthy procedure for packaging and building, etc.), we made our scripts less user-visible than the ones we inherited, because ours fail or otherwise misbehave less often, which is obvious goodness.

Check for yourself if you don't even remember what you committed to your own project!

Multiple items in this discussion make it clear that I have a better knowledge of the changes I applied to GCC4TI than you do, thank you ;)

GCC4TI contains a lot of changes which make it worse than TIGCC.

In your opinion. Fortunately, most people have a saner assessment of the situation :)

I assume this is an exceptional, explicit grant to post information extracted from the logs,

Hahaha, don't be silly, you know very well the difference between what is clearly not allowed and what obviously is.

so I can tell you it was right in the timeframe of me making the fix to __fgetchar and committing it to GCC4TI.

Thanks. ;-)

A user (and remember, *nix users) was worried he broke his computer because he did the mistake of adding $TIGCC/bin before /usr/bin in the path (despite the warning in the documentation). It was easy to fix for us, it wasn't easy to fix for him; it's no good that such things can occur in the first place.

So "breaking compatibility" (for people abusively calling internal executables) to "fix" blatant user errors is acceptable, but doing the exact same thing to stop misappropriating the ld-tigcc name is not? WTF?! This just shows how ridiculous this excuse is. As one of the 2 authors of ld-tigcc, I have to insist again: You must not call your fork of ld-tigcc "ld-tigcc"! (For example, your patch to remove nested functions is clearly not acceptable for ld-tigcc, and thus your code is something clearly different.)

But avoiding that kind of silly user errors is why people should use packages. Which implies that you should make packages, you are a Debian user, why don't you make debs of your stuff? For Fedora, I ship a TIGCC RPM which just works.

And if that ridiculous kind of "compatibility" is really the issue which prevents renaming your fork of ld-tigcc, you can just ship a ld-tigcc → ld-gcc4ti symlink, while clearly identifying the program to the user (in --version output, documentation etc.) as "ld-gcc4ti", not "ld-tigcc".

But of course, working on GCC requires technical competence...

It's far from being the first time you're writing I'm not technically competent.

You just wrote that. I never did. :-p

That said, if you think you are competent for GCC work, then why are you not doing it?

Get a clue by looking at the scripts, and find things which are not required by the bash -> sh move, but required for the script to work outside the box on non-Linux platforms

Well, I remember looking into your patches back then, and your claimed "fixes for non-Linux" were touching only the syntax of commands like echo which are bash builtins. I'll have another look to see if there are now changes that are genuinely needed. My scripts did work fine on Mac OS X, though I might have accidentally broken that because there are way too few Mac OS X users compiling TIGCC (and none willing to make binaries, except for one who hasn't updated them for ages).

(or for merely canadian-cross-compiling - another use case we support while you don't),

What's the point?

For what it's worth, my current W32 binaries are built as canadian crosses, but of course not using the TIGCC/nix build scripts, because W32 is not a nix system. And some parts of TIGCC/W32 cannot be cross-built at all. (In particular, the Delphi stuff, and last I checked, I was also unable to build a valid CHM on Fedora.)

or required for erroring out on the first error and silently leaving users with broken builds (wasting both their time and maintainer time debugging their problems), etc.

The way you did it also removed support for building without the useless directories in the GCC and Binutils releases, increasing build times by a lot (just to build stuff which ends up discarded anyway) and also requiring the user to download much larger tarballs.

As for KDE, the surveys that I know of don't paint such a wide usage of KDE even among Linux distros. It might be more popular than any single other DE (?, even though KDE remains a second-class citizen in most distros), but considering the sheer number of people who use Gnome Shell / MATE / Cinnamon, KDE Plasma remains still a minority.

You forgot Xfce there. Luckily, KDE apps work just fine under all those desktop environments, and the KDE Project keeps working on improving that even further. (E.g., in KDE Frameworks 5, using KFileDialog in applications will be deprecated. Instead, they shall use QFileDialog, and the KDE Platform Plugin will use the KDE implementation only under a KDE Plasma environment. Under other environments, you'll get the platform's native file dialog instead.)

Also, KDE is a buggy dwarf on Windows and MacOS X,

GTK+ also has its problems on those proprietary operating systems, and the alternatives are all proprietary and not portable.

But of course we need to use (at least) kdelibs 4 to port to those operating systems, which is why finishing KTIGCC 2 should be a priority.

and doesn't exist on Android + Chrome OS.

The Calligra developers actually got a subset of kdelibs to work on Android. This will probably be supported even better in KDE Frameworks 5. But is Android really a serious target for GCC4TI? I think you'll have other problems than just the IDE!

not everybody has such good Internet connections as French people, or as academics such as you

I am using a standard Austrian residential broadband connection, no academic Internet2 connection.

under the new scheme for links, updating other files when moving one or more file is trivial - a single sed / perl / equivalent one-liner per file. The new scheme, whose implementation didn't take long (and besides, allowed me to practice more Perl), allowed forward progress without having to spend full-time days on rewriting a set of C++ documentation tools, fixing the annoyances of the existing Delphi tools in the process. It wasn't worth the trouble to rewrite everything by myself, but YMMV.

Rewriting the documentation tools would have allowed to address also several other issues, e.g.:

the fact that they are in Delphi, a non-portable proprietary language, and,
the fact that they quit with a fatal error at the first unresolved reference, making you start the (lengthy) conversion process all over!

Your hackaround only "fixes" one of the issues (which isn't even the most important one), and that poorly. It also means I cannot easily merge any non-trivial documentation changes from you into TIGCC because I'll have to fix all the links by hand (because your hack is obviously not acceptable for TIGCC).

years ago, I did contribute my operational knowledge of the documentation system, and some code, into early work on a rewrite of a set of documentation tools, started by someone else. With my contribution, the tools choked on far fewer documentation files. Both them and me had other items on our respective plates and the rewrite never got finished.

Yeah, I wrote that project off as a failure. If you think it produced anything of value and you still have the code that was produced, then finish it. Otherwise, the work just has to be restarted from scratch, sadly.

Previous items in the discussion showed that you have a wrong assessment of "user-visible".

Changes to the internals of the build scripts are not user-visible.

That said, if you think you are competent for GCC work, then why are you not doing it?

Should be clear from earlier parts of the discussion: very low number of users, dubious cost/benefit ratio.

Get a clue by looking at the scripts, and find things which are not required by the bash -> sh move, but required for the script to work outside the box on non-Linux platforms

Well, I remember looking into your patches back then, and your claimed "fixes for non-Linux" were touching only the syntax of commands like echo which are bash builtins.

Nope, they're not touching only that...

(or for merely canadian-cross-compiling - another use case we support while you don't),

What's the point?

Using the same build scripts for building both *nix and Windows executables (those which can be built by the script) from Linux, for instance ?

For what it's worth, my current W32 binaries are built as canadian crosses, but of course not using the TIGCC/nix build scripts, because W32 is not a nix system.

Handling canadian cross builds in the scripts was not even hard to do... and when that's done, the difference between a *nix native build and a Windows cross-build is a couple parameters put into the top build script.

And some parts of TIGCC/W32 cannot be cross-built at all. (In particular, the Delphi stuff, and last I checked, I was also unable to build a valid CHM on Fedora.)

That's not a problem for me, I have my own legal copies of multiple Windows versions for generating CHM files once in a while, and of Delphi 2005 for rebuilding the IDE and the tigcc front-end.

or required for erroring out on the first error and silently leaving users with broken builds (wasting both their time and maintainer time debugging their problems), etc.

The way you did it also removed support for building without the useless directories in the GCC and Binutils releases, increasing build times by a lot (just to build stuff which ends up discarded anyway) and also requiring the user to download much larger tarballs.

FYI, GCC4TI discards less stuff than TIGCC does, as part of being less of a non-standard toolchain.

Also, KDE is a buggy dwarf on Windows and MacOS X,

GTK+ also has its problems on those proprietary operating systems, and the alternatives are all proprietary and not portable.

GTK+ sees some usage in the wild on those OS. Nowadays, Qt 4/5 probably does more than GTK+ (and rightfully so), but Qt wasn't an option on Windows several years ago. Both GTK+ and Qt see far more usage on those OS than the large (and buggy, on those OS) KDE framework.

under the new scheme for links, updating other files when moving one or more file is trivial - a single sed / perl / equivalent one-liner per file. The new scheme, whose implementation didn't take long (and besides, allowed me to practice more Perl), allowed forward progress without having to spend full-time days on rewriting a set of C++ documentation tools, fixing the annoyances of the existing Delphi tools in the process. It wasn't worth the trouble to rewrite everything by myself, but YMMV.

Rewriting the documentation tools would have allowed to address also several other issues, e.g.:

the fact that they are in Delphi, a non-portable proprietary language, and,

In itself, the usage of Delphi is less of a problem than it used to be, because FreePascal has improved a lot over time.

the fact that they quit with a fatal error at the first unresolved reference, making you start the (lengthy) conversion process all over!

Again, while the conversion process used to be relatively lengthy a decade ago, it's much less so nowadays, even on a computer more than two years old and two processor generations behind, as is mine. As I've already mentioned in earlier discussions, producing the documentation takes less time than building the various software projects I've been working on as a professional software engineer for 6 years...

Your hackaround only "fixes" one of the issues (which isn't even the most important one),

For merging non-trivial documentation changes, it is the most important one.

and that poorly. It also means I cannot easily merge any non-trivial documentation changes from you into TIGCC because I'll have to fix all the links by hand (because your hack is obviously not acceptable for TIGCC).

That's your problem if you don't want to even use the ~100 SLOC Perl script I posted publicly more than five years ago (and you're aware of that), let alone change to make it fit your own vision of the behaviour it should have.

Suppose that, in my day job in the software industry (nowadays) or in academia (formerly), there's a technical annoyance in the stuff we (in the team) are working on, and we can come up with two main solutions for making forward progress:

a mitigation-type solution: spending a short while on producing a presumably short snippet of code (as far as we can imagine) written in a scripting-type language (certainly Perl because that's what we know best in the team), which munches stuff in such a way that the main technical annoyance (for our use case) disappears;
a redo-type solution: spending presumably multiple times that amount of effort on producing far more C++/STL or C++/Qt SLOC able to replace the existing tool, fixing the main technical annoyance, and even other minor ones in the process, but little beyond that (otherwise it would take even more development time).

What do you think we are going to choose, during the next team planned or impromptu meeting, given that we're allocated a fixed (and insufficient, as always) number of days for our project ? Are we going to deprive the implementation of other, more important features, from days of work, and have to come up with a worse / more hacky solution for those, because we wasted time but higher-level management and the clients want to see stuff done ? In academia, the same thing applies. I'm well aware of the corners PhD candidates do take for producing results in time for a stream of conference papers (and indirectly PhD advisors). Some of my M.Sc developer colleagues in research labs had been recruited specifically to perform much-needed software engineering on horrible research toys (dozens of thousands of C++ SLOC with low comment / statements ratio, no SCM, no documentation, hardly any testcases, some of them originally building and working only on the PhD candidate's computer - that's no fiction) so that the research products could actually be used, you know, in the real world.

years ago, I did contribute my operational knowledge of the documentation system, and some code, into early work on a rewrite of a set of documentation tools, started by someone else. With my contribution, the tools choked on far fewer documentation files. Both them and me had other items on our respective plates and the rewrite never got finished.

Yeah, I wrote that project off as a failure. If you think it produced anything of value and you still have the code that was produced, then finish it. Otherwise, the work just has to be restarted from scratch, sadly.

... assuming it's a sane thing to do the full rewrite in the first place, of course. For the documentation tools we're currently talking about, the tradeoff is questionable.

Previous items in the discussion showed that you have a wrong assessment of "user-visible".

Changes to the internals of the build scripts are not user-visible.

When you have properly analyzed the changes to the internals, you'll see that some of them are user-visible ;)

Trying to support cross-compiling for W32 in the automatic build scripts is totally pointless as long as there are components in GCC4TI/W32 that cannot be cross-compiled.

As for the kind of corners that are cut out there, I know far too well about that, I'm a PhD student myself (so I know how things run in academia), I have seen (and had to help fixing) unfinished code written for a PhD thesis, and I have also seen enough examples of bad code written at companies (just by looking at company-written Free Software, and also at sites like The Daily WTF) and know very well why it happens (deadlines, lack of importance given to long-term maintainability, etc.). That does not mean that it is an example to follow. You say yourself that the junk that is produced often cannot be used in the real world!

If you hack around issues instead of fixing them properly, you pile up hack upon hack, and the resulting code stops being maintainable in the long run. TIGCC has been suffering for ages from the issues with the documentation toolchain, rewriting it is sorely needed, hacking around them does not resolve anything. Especially not if the hack does the exact opposite from what a proper fix for the problem it is supposed to fix would look like.

And I noticed you evaded the part of my message that actually referred to the original topic! Why would a ld-tigcc → ld-gcc4ti symlink not resolve your compatibility concerns with stopping the abuse of the "ld-tigcc" name?

Trying to support cross-compiling for W32 in the automatic build scripts is totally pointless as long as there are components in GCC4TI/W32 that cannot be cross-compiled.

In your opinion :)

If you hack around issues instead of fixing them properly, you pile up hack upon hack, and the resulting code stops being maintainable in the long run.

your own track record in the TI community makes you unfit for complaining about software maintainability;

it's dubious whether putting full paths everywhere, instead of a mixture of relative and full paths (which made it hard to make and integrate large contributions, I know that better than anyone else), is a hack;

finally, there's no "long run" for the TI-68k platform. Wake up, the TI-68k platform was abandoned by TI in 2005, more than 8 years ago, and the community belittled a lot in 2006-2007 (effectively shortly before the commercial Nspire appeared, but unrelatedly, as at that point, the Nspire did obviously not matter on the marketplace). TI-68k programming software is clearly in the "slow death" life cycle phase - and for those, fixing bugs and performing maintainability changes in the build system (which we did on the GCC4TI side) are far more important than a complete rewrite of the documentation generation system... That's not to say that all TI-68k programming software should absolutely shun off any kind of new feature or improvement.

TIGCC has been suffering for ages from the issues with the documentation toolchain,

Yes, but the most important practical issue has disappeared on the GCC4TI side, as I've explained.

rewriting it is sorely needed,

In a world with large amounts of free time, large number of users, and bright future for TI-68k/AMS programming, I'd agree. However, in the real world...

hacking around them does not resolve anything. Especially not if the hack does the exact opposite from what a proper fix for the problem it is supposed to fix would look like.

In your opinion.

A year later, GCC4TI is still misusing the ld-tigcc and TIGCCLIB names. The issue is not closed at all.

I was a bit confused by the remnants of the name TIGCC in GCC4TI but it was not hard at all to figure out that this is a fork. May I direct your attention to the bottom of https://en.wikipedia.org/wiki/TIGCC#Development_of_TIGCC

I do not think that @debrouxl needs to go through and remove every single reference of the name TIGCC because of beef you have with the fork's existence. There is no "attempt to impersonate TIGCC," as this is an entirely different repository.

The fact that this in an entirely different repository does not matter at all. If I open a repository on GitHub and call it "Microsoft Windows", it "is an entirely different repository" than the real thing, but the repository would still get deleted (especially now that GitHub is owned by Microsoft) and I would probably also get sued by Microsoft.

The GCC4TI linker and the GCC4TI runtime library falsely claim to be components of TIGCC.

I also still do not see an explanation as to why a simple compatibility symlink would not address any remaining compatibility concerns with renaming the ld-tigcc binary to something like ld-gcc4ti (more than 8 years after I asked the question! Twice, even).

Almost 10 years later, GCC4TI still falsely claims to be TIGCC in many places. You did not even bother fixing strings such as the "built for TIGCC/*nix [version]" in the CLI frontend, let alone renaming the executables to allow parallel installation with the original TIGCC as you are supposed to.

debrouxl / gcc4ti

Please rename your forks of TIGCCLIB and ld-tigcc #4