GCC4TI manifesto - Page 1

The GCC4TI readme should contain several notes about why we decided to fork TIGCC, shouldn't it ?

Here are several ideas:
[ul][li]the rate TIGCC evolves has been low for a couple of years. Most of the work on that timespan was on KTIGCC, a _rewrite_ in C++/Qt/KDE of the existing Delphi TIGCC IDE (i.e. not a brand-new feature).[/li]
[li]some features that are known to be useful to multiple/all programmers and/or multiple/all users, have had trouble (delays) getting in, have been refused, or have been removed from TIGCC. Let's mention:
[ul][li]multiple optimizations in TIGCCLIB startup and non-startup code;[/li]
[li]new features in TIGCCLIB;[/li]
[li]VTI support in the Delphi TIGCC IDE was removed. Though the TIGCC IDE <-> VTI support is a dirty hack, VTI is a strange mix of code with different licenses, VTI is less featureful, full of bugs and unaware of V200 and 89T emulation, VTI remains easier to install (no GTK+ dependency) and feels faster than TIEmu. Multiple programmers are known to still use VTI.[/li]
[li]upgrading 'kernel' support. PreOS has been for five years the only maintained 'kernel', it is the only one that works on 89T calculators, and some recent 'kernel'-based programs are using some of its capabilities not found in other kernels: PreOS has become the de-facto standard 'kernel'.[/li][/ul][/li]
[li]some recently-announced directions for TIGCC, e.g. replacing the Delphi TIGCC IDE by KTIGCC (and thereby adding a dependency on the huge, buggy KDEwin framework), have worried some of us. Due to the added difficulty and bloat of the TIGCC installation process, we're not convinced will be worthwile an upgrade. All the more it doesn't fix well-known limitations of the Delphi IDE, e.g. TIGCC projects: multiple use cases have been identified, for which TPRs are too simple-minded to fit.
([Link to the "coup de gueule" on KDEwin ?])[/li][/ul]

It's probably best for us not to wade too much into non-technical reasons: remember that many people in the community see only the bright part of him (I know, I did for a long while), the technically-capable and usually helpful guy on the message boards. Many people are not aware of the darker part, that was best shown on yAronet for years and led to his ban for a long while, making him one of the very few persons ever banned from yAronet.


Please discuss, suggest, improve, etc.

Ping ?

Hey guys ! Did I write something so correct, so complete and well-written that you have nothing to comment on ? I strongly doubt it

I vote for being the less verbose possible. Let's just say that" we didn't agree anymore with the TIGCC maintener and the direction of its developpement."

Yeah, maybe it doesn't need to be that verbose (I know I tend to write large blocks of text ).
However, don't you think that if we don't back our reasons by (mostly) technical arguments, it will be all too easy for Kevin to make us look bad (even though we have tried working with him, it's a fact) ?
I know that we shouldn't direct all our actions against Kevin, but that does not mean that we don't have to care at all about how he reacts: you all know that he isn't going to hesitate at all firing at our project, he has already started doing so !

Oh, when exactly have you tried working with me? You never tried joining the TIGCC Team, nor did PpHd or Godzil.

Both PpHd and myself have made actual contributions to TIGCC. You have refused some of them for technical reasons (most of PpHd's linker patches, some of my contributions to the documentation), some of them because you didn't like the idea (Ptr2Hd, fastitoa.h, some _LOC_ function, etc.).
Remember, I acknowledged my still unmerged contributions to the documentation not being ready for merge *years* ago, when I started doing a tool that modifies the documentation to solve part of the problem. I completely implemented this simple tool several years later, for the GCC4TI project, in a programming language that is much more adapted to the task but which I hadn't learned at the time. It's posted on the Trac, BTW

But code contributions are just an aspect of working on an open source project. Feature requests are another one. And for years, most of our feature requests have been turned down by you, not necessarily in a graceful way. Often, the reasons you give are not seen as universal truth: often, there are counter-arguments to your arguments.


Mayhem wrote it pretty well on the TIGCC/TICT message board. This guy has never been part of any discussion/flame, though he has read most of them. That didn't drive him away from the TIGCC/TICT message board, unlike at least one person who told me so.

Kevin, you have contributed a lot to this community. You have also proven to be an invaluable information resource for the community. But taking into consideration all of your posts that I have read on this board for some 5 years (on and off), I would ask you to consider what people want to do vs. what you think is best for people (even if you can justify your recommendations, people can frequently equally justify their actions against your recommendations
). Since you enjoy taking on big projects which depend on contributions from more than one person, and people will only work with other people for prolongued periods time if they feel a mutual respect, it is probably in your best interest to reconsider your approach.

So we have definitely tried working with you, but we've grown tired and demotivated of being turned down, or delayed for a long time (unmerged TIGCCLIB optimizations, etc.).
That said, we still do work with you (e.g. uncontroversial chunks of PpHd's ld-tigcc patches), or at least discuss with you about it how it could be done (FlashOS support, code de-duplication and modularization).

A couple of suggestions / ideas

1) Kevin and Sebastian have done a great job on IDEs, but I'd recommending dropping the IDE. This allows a focus on the tool chain and library and avoids wasted effort. Instead, package something like Eclipse or Anjuta (why reinvent the wheel).
2) drop support for old AMS versions; it is easy to upgrade with a link cable or PC. This reduces complexity of the project. It might be pretty safe to pick the very latest versions of the OS. I don't think TI puts much effort into these calculator models anymore, so future OS versions are somewhat unlikely.

Thanks for your input

1) the main roadblock in dropping the TIGCC/GCC4TI-specific IDE is that there are many, many IDEs on various platforms
Otherwise, it's a fact that the IDE embedded in TIGCC/GCC4TI has few distinctive capabilities (not all of which are universally considered as features: for example, the ability to compile unsaved files, which, besides being different from what pretty much all other IDEs - and SCMs anyway - do, yields a mess in the design and implementation of the build system), and lacks the extensibility of most other IDEs.
2) yeah, it's a fact that my address/value hacks are of very little practical use nowadays. They still made some sense when I created them, but, uh, that was in 2001-2003 (!). I recently added support for MIN_AMS == 301 and 310 in GCC4TI.

I agress with dietsche, I think it could be preferable to drop compatibility with at least AMS 1.xx. If not, why the IDE shouldn't run under Win 3.1 ?

Okay, there is PedroM, but I think than a global job of several coders could help PpHd to port it to the AMS 2.x standard. (anyway, I don't know the PpHd's opinion about that)

More, we have already some xml files ready to support syntax highlightning on editors which support that (does many editors support that ?).

dietsche (./7) :
1) Kevin and Sebastian have done a great job on IDEs, but I'd recommending dropping the IDE. This allows a focus on the tool chain and library and avoids wasted effort. Instead, package something like Eclipse or Anjuta (why reinvent the wheel).

My opinion on this subject is well known (search this forum and the TIGCC message board at TICT HQ, you'll find several reasons why this is a horrible idea, I'm fed up of repeating them), but if the GCC4TI folks want to make their project less useful, it's their choice. (It'd mean that project files would no longer be compatible between the 2 projects though. There's no way TIGCC is going to switch to a third-party IDE.)

2) drop support for old AMS versions; it is easy to upgrade with a link cable or PC. This reduces complexity of the project. It might be pretty safe to pick the very latest versions of the OS. I don't think TI puts much effort into these calculator models anymore, so future OS versions are somewhat unlikely.

The TI-89 and TI-92+ cannot be upgraded beyond AMS 2.09, so that'd be at least 2 "very latest versions" to support. So all the AMS version machinery would still be there and there's not much to gain. It's not that hard to keep backwards compatibility. And in addition, PedroM doesn't implement most AMS 2 or 3 ROM_CALLs either.

dietsche (./7) :
2) drop support for old AMS versions; it is easy to upgrade with a link cable or PC. This reduces complexity of the project. It might be pretty safe to pick the very latest versions of the OS. I don't think TI puts much effort into these calculator models anymore, so future OS versions are somewhat unlikely.

Why do you exactly have in mind by dropping the support of old AMS versions?
The tigcclib hacks for getting some romcalls on old AMS? Or increasing the MIN_AMS bu default?

Why do you exactly have in mind by dropping the support of old AMS versions? The tigcclib hacks for getting some romcalls on old AMS? Or increasing the MIN_AMS bu default?

I actually meant dropping old AMS support entirely. But I didn't know that PedroM needs older AMS support.... so maybe it isn't a great idea to drop support The main idea was to simplify the framework and make maintenance easier.

But yes, I would also think that maybe the default AMS version should be at least 2.05 (whichever version of the OS supports fline rom calls... i don't remember for sure) for applications meant for TI's operating system. I'm a big fan of fline when speed isn't a concern.

Greg

dietsche (./12) :

I actually meant dropping old AMS support entirely. But I didn't know that PedroM needs older AMS support.... so maybe it isn't a great idea to drop support The main idea was to simplify the framework and make maintenance easier.

I don't think it will really simplify the maintenance: most of the times, it simply says that the function N is not available for AMS older than M.0m Moreover we are obbliged to keep this infrastructure due to the difference between 89, 92+ and V200/89 Titanium.
Avoiding the tigcclib hacks for old AMS can simplify it.
Morover some users may prefer older AMS versions than the latest ones which were slighty faster, or offer more archive memory

Indeed, we'd not gain much in terms of maintenance ease by actively dropping support for old AMS versions.
What we can do is not integrating the AMS 1.xx address/value hacks that I developed in 2001-2003, when they made much more practical sense than they do now.

I still remember how much you nagged me because I didn't add them immediately without testing (when some of them didn't even compile!), now you don't want them anymore.

I asked you to add them years ago, when they still made practical sense
Nowadays, AMS 1.xx (older than 1999 !) are irrelevant, and integrating those address/value hacks would require some work, while there are much more useful things to do ( http://trac.godzil.net/gcc4ti/report/1 ). Dropping the bulk of these value/address hacks is probably the only reasonable thing to do with them.
Now, if someone able to do that work stepped in to test all of the value/address hacks, I'd point out that there are more useful things to do, and that it would be better to work on something else. If that's the only thing that he's motivated for - which is extremely unlikely ! - I can't see how I could refuse the contribution, however.

Of course, I'm not delighted to see some of my effort in contributing to the TI-68k community, which represent days and days of free-time work, being thrown away. But well, adapting to the changes brought by time flowing by is part of life. And I had some fun and learnt some things doing that work - isn't it what matters, in the end ?