There will be a new official TIGCC with those same bugfixes and more soon.

What the fork also contains, though, is several low-quality patches which have either been rejected outright from TIGCC because of various inherent technical issues with them or are just not good enough to be merged yet.

So I can only strongly recommend to use only TIGCC releases from the TIGCC project (tigcc.ticalc.org), not GCC4TI or any other fork.

Hey Kevin, please back up your claims with facts ;)
Please post the revision numbers that committed *into the trunk* (as opposed to "into a development branch") something that doesn't meet your quality standards.

I believe in Harvey Dent.... and Kevin Kofler!!!

Omg, first ever tigcc-ticalc flame war down there lol. Reply here where it's safe xD.

Or reply directly to the article (It will go one the second page (under normal settings), there's no flames there ;) )

I wouldn't say it's *too* bad yet... Now whenever one of us has to start deleting comments, I will call it a real flame war. ;-)

xD

Oh I am used to KK vs someone else "flame" war, altough no insults were thrown at each others yet (unless I missed one). I would say something between an argument and flame war, or fight to a certain extent. It was worse on yN/tigen, especially the ETP Studio one, plus I saw worse in the z80 community with the Drubu incident.

Oh and the TI-BASIC file invitation system april fools joke *cough*Shawn Zang*cough*

All those which don't come from TIGCC's CVS.

This is so ridiculous it isn't even funny...
Comments like the one I'm replying to, make people think that you see yourself very highly, and despise others.

The fact is that everyone, by looking at the GCC4TI changesets, can see that:
r1261 and r1307 fix up CVS damage (no line ending handling => checkouted files take EOL convention of the platform... but TIGCC's proprietary documentation system barfs if the documentation files don't have CRLF).
r1263 suppresses formatting quirks from several documentation files.
r1264 works around a limitation of TIGCC's proprietary documentation system that has been present from the beginning. It eases moving files around without having to rewrite thousands lines of code (no convincing use case has been shown so far for a complete rewrite).
r1265 adds the FlashOS library (limited to the header at the beginning of the FlashOS) to the repository, instead of leaving it out-of-tree on Kevin's website (hard to find).
r1267 adds an implementation of stdint.h.
r1268 updates the C headers.
r1272 is a trivial patch to add a new linker built-in, that we proposed for inclusion in TIGCC months ago, but still isn't there.
r1277 adds an implementation of inttypes.h.
r1292 fixes the documentation files of inttypes.h so that they work on case-insensitive filesystems.
r1293 regenerates the Delphi IDE completion information.
r1296 merges the VTI restoring patch (that is, mostly, undeleting code that worked before TIGCC 0.96 Beta 8) to the trunk.
r1299-1306 are things for making the first release of GCC4TI. Notable among those revisions are the introduction of a makefile for ttpack (r1301), a *fix* for compiling ld-tigcc on Windows (r1302). r1303 is one of the ways to reach the goal of building a pstarter.o, there's another one, as we discussed together.

* I know about the line endings, I just run unix2dos on all the documentation files after copying them to my tigccdoc folder I generate the docs in, then dos2unix on the headers to get them back into the canonical LF-only format. There's no need to have CR LF endings in the repository.
* OK for the formatting quirks, but why haven't you sent this patch to me? Not that it is absolutely essential...
* The case for a complete rewrite or port is that the current tools are unmaintainable because they're written in a proprietary language. Heck, they won't even run on my GNU/Linux without using WINE. And your solution is bad, the explicit header specifications for the functions should be removed, not added. But that requires actually changing the documentation tools. Another major issue is the "everything is a fatal error" policy (which also implies that only the first error is ever reported and the whole lengthy process has to be restarted from scratch each time a mistake gets fixed).
* Flash OS support is intentionally not included by default in TIGCC, it's incomplete and experimental (and I already explained that to you at least twice).
* stdint.h is already in TIGCC CVS. :-p And the implementation in TIGCC CVS (by Conrad Meyer) is better than the one you originally committed. (Even you noticed it because you replaced yours with ours.)
* Updating the C headers is not a real change, and I also regenerated the ones in TIGCC (and I didn't change them to CR LF line endings, CR LF has no business to be in the repo).
* Your patches for the linker builtins are not fully reviewed. They will be added to TIGCC when I complete the review.
* Your inttypes.h is definitely not good enough for TIGCC, your documentation is incomplete and repetitive.
* Updating the completion information is not a real change, and I also regenerated the one in TIGCC.

About the line endings: in our *opinion*, having to run unix2dos & dos2unix back and forth just in order to accomodate the limitations of a well-known-as-crappy SCM sucks.

*We* have multiple copies of Delphi, so *we* can modify the documentation tools. But what we lack, for undertaking this task, is a use case...
We're not dependent on Wine because we have native Windows hosts. The process is not really lengthy (about 30 seconds on my 2-year-old computer when running under Wine - much less than most builds in my daily job).
And the "everything is a fatal error" behaviour could probably be fixed easily, if it were actually a real problem. In my experience (dozens of integrated documentation files for TIGCC, years ago), changes that triggered more than one error were infrequent, so in my *opinion*, it's not a real problem.
Years ago, I started fixing what is by far the main cause of them (references wreckage when moving files around) for TIGCC, but I never finished the work... until GCC4TI (in-between, having gained experience and learnt Perl, which makes the task a piece of cake).
Again, as you can see, we have diverging *opinions*.

> About the line endings: in our *opinion*, having to run unix2dos & dos2unix back and forth just in order to accomodate the limitations of a well-known-as-crappy SCM sucks.

s/SCM/documentation toolchain/ :-)
This is yet another reason why it needs a rewrite. (The tools should just work with LF-only line endings.)

No offense to Sebastian, the tools did their job for years and they're definitely better than nothing, but there's definitely room for improvement there.

> * Flash OS support is intentionally not included by default in TIGCC, it's incomplete and experimental (and I already explained that to you at least twice).
You could have repeated your explanation even more times, it still wouldn't have convinced us...
* we see no excuse for maintaining out of tree the header for Flash OS.
* the Flash OS support has been successfully used for years by two different Flash OS. We don't think it can be qualified "experimental". Not to mention it is less experimental in GCC4TI than it is in TIGCC, since no TIGCC release provides the fixes to users...
* as can be seen on the GCC4TI ML, we disagree about the FlashOS support being "incomplete". The chunks of code that are common to *all* Flash OS, without hampering flexibility, are so few and so small (we're talking about several dozens of lines !) that maybe it's just not worth the trouble putting them in a standard library. Especially since it's unlikely that anyone would try making a new Flash OS without having a look at the existing ones...

> [multiple things are] not a real change
I know, but it it weren't obvious, I was explaining every single revision...

> Your patches for the linker builtins are not fully reviewed. They will be added to TIGCC when I complete the review.
Yeah, reviewing two patches that are several dozens of lines each is so damn hard that you haven't done it in months time. Despite spending hours and hours trolling on yAronet and the TIGCC/TICT message board during that period.
But take your time for the review :)

A lot more code could be shared between different Flash OSes than currently is. And Punix also contains several routines copied from PedroM.

* Restoring VTI support is definitely NOT good enough for TIGCC and will never be, VTI support was removed for a reason. The code was an abominable hack, it should never come back. In addition, your patch pollutes the preferences with an unnecessary option (the one to use VTI), increasing UI clutter.
* The makefile for ttpack is not needed.
* As for the fix for ld-tigcc, you dare advertising that as a feature of your fork? Not only did YOU submit a broken, untested patch in the first place, but you also didn't bother telling me about the fix. (This thread doesn't count, it's too late, I already noticed it before, I just didn't get around to verifying that fix and committing it into TIGCC's CVS yet.) So that's a bug YOU introduced into TIGCC and intentionally withheld the fix for.
* Your change for the pstarter.o is incorrect and unneeded.

> * The makefile for ttpack is not needed.
It's not strictly needed, yes.
But when you're thinking of automating the building process (something which you should have done a long time ago, it's a well-known good software engineering practice...), it's more convenient to have a consistent building system. Other parts have makefiles, so I added one here as well.

> * As for the fix for ld-tigcc, you dare advertising that as a feature of your fork? Not only did YOU submit a broken,
As noted in the commit message, yes, I'm the one who submitted the patch. But the commit message also mentions that you didn't notice the problem either.
(Which makes you an incompetent reviewer.)
> untested patch
Wrong, and you know it very well: my tests uncovered a bug in ld-tigcc (a *crash* that can result from a mistake in the typing of linker builtins). I told you about it, and you wrote in return that this was an error on invalid, so for you, fixing this had very low priority...

I only rebuild the Window$ binaries every so often (I only need them when I release), I would have noticed (and cursed you) when building them.

> I only rebuild the Window$ binaries every so often
Which makes you an incompetent maintainer: you don't care, except once in a long while, how things would work for the majority of the users of the program you're supposed to maintain...
You didn't even need Windows to catch the problem: I caught it using a cross-compiler (which I hadn't installed at the time I sent you the patch).
You definitely aren't qualified to complain about others being incompetent reviewers, maintainers, or not having the same quality standards as yours...

Automating the build process is one of the items on the GCC4TI todo/wish list, with good reason. It makes maintainers' life easier, improves portability testing, and reduces the timespan between releases, which benefits users. In a nutshell, it's a win-win situation. That's why it was taught to me, at school, as a well-known good software engineering practice.
What a shame you aren't using this good practice...

I see you wrote in your commit message mirroring my fix, that I did not provide it in a timely manner...
Well, if less than 24 hours for providing a fix is not timely, then waiting for more than 10 days before backporting the fix to the program you're supposed to maintain isn't either...

> Which makes you an incompetent maintainer: you don't care, except once in a long while, how things would work for the majority of the users of the program you're supposed to maintain...

"The majority of the users" don't use TIGCC from CVS HEAD. In fact I don't know a single person who does. What matters is that these things are fixed before a release. Which as a matter of fact is also one of the reasons why I didn't have the time to do a release, this sort of QA is needed.

> You didn't even need Windows to catch the problem: I caught it using a cross-compiler (which I hadn't installed at the time I sent you the patch).

I know, that's how I verified that your fix works.

> In fact I don't know a single person who [uses TIGCC CVS HEAD]
Well, *I* did...
That was before I switched to GCC4TI SVN HEAD (+ local Git branches) for testing, of course.

> but you also didn't bother telling me about the fix.
> So that's a bug YOU introduced into TIGCC and intentionally withheld the fix for.
I noticed the bug only in the process of building the GCC4TI release, on January 2nd. The release (and the end of the initial phase of the GCC4TI project, building up) was done on January 3rd.
I could indeed have told you of the fix right away on January 2nd, instead of waiting for you to find it in the GCC4TI repository. But your lack of respect towards our work and our persons didn't make me too eager doing so, sorry ;)
(well, maybe you didn't find out about the fix before January 5th or so, after Godzil unbanned you from the server, of which you had triggered the anti-abuse protections. But that's not my fault, that's yours.
You're claiming it was a false positive, but sorry, I'm fairly reluctant to buy your claim, since I already opened more than 20 tickets in a few seconds with my mouse's middle click, without getting banned.)

Oh, BTW: I've just done a `cvs up` of the TIGCC repository, only to notice that you still haven't committed this particular fix. You're therefore woefully unqualified to complain that I didn't tell you of the fix right away...

> * Your change for the pstarter.o is incorrect and unneeded.
Wrong for both "incorrect" and "unneeded": it achieves the purpose of getting a pstarter.o.
Now, as I mentioned in a post above, we discussed another solution, which happens to be better. Next time I want to recompile pstarter.o, I'll scrap the TPR and use that solution.

> But that's not my fault, that's yours.

How is it my fault if your project server decides that I "abused" it when all I did was browsing a bit in the revision logs and tasks? You can blame whoever wrote the anti-abuse scripts, or maybe Godzil who installed them, but why me?

> You're claiming it was a false positive, but sorry, I'm fairly reluctant to buy your claim, since I already opened more than 20 tickets in a few seconds with my mouse's middle click, without getting banned.)

And this is outright libel!

There's certainly plenty of abuse the broken script does not catch, but that's just more proof that it doesn't work.

> And this is outright libel!
Well, strange actions can be expected from someone who is stupid enough to sabotage the Microsoft Wikipedia article the way you did (see the URL behind my name for this post)...
There is zero doubt it's you, given that it's the same IP address as that which is the main editor of the TIGCC WP EN page, and that you're always trolling about Microsoft and other proprietary software. On yAronet, you get moderated if you use the "Micro$oft", "Winblow$", "Oh$uX" and other inflammatory words that I've seen you use on #tigcc.

He's an ass, get over it.

Lionel's the ass who's forking my project and wrongly accusing me of sabotage.

I did absolutely nothing abusive to their project site! I only viewed a few pages, isn't that what a website is for? I wasn't refreshing them repeatedly or anything like that, just viewing them like any normal user! I'm not trying to sabotage their server in any way. I even privately reported a performance issue I accidentally found (days after I got automatically banned and manually unbanned, so that can't be what triggered the script) which could be used for a DoS to the server admin (Godzil). He just dismissed it as unfixable. I never triggered that issue again (after the one time I accidentally triggered it, not meaning to cause any trouble).

So how do Lionel's baseless accusations make me an "ass"?

No by "ass" Nikky is talking about how you keep belittling/discouraging others' work on contributions to the TI community while this time could be spent on coding others contributions or improving alerady existing ones. This is also the sole reason the 68k TI community demise

You blame me for the TI calculator community's demise? I wish I had that much power... ;-) The community's sorry state is not due to a single person.

The demise reason is not you, it's the belittling/discouraging of people projects and flame wars that ensued during 2 years, some of which where people just kept adding fuel to the fire. Ticalc used to have to split the 68k POTY poll into two ones because there were lot of choices, mostly from the french community. Now there are two or three POTY eligible programs being released per year, most of which coming from TIFW

What exactly sort of problem do you have with him forking TIGCC? The license allows it, so you must have decided at some point that you wanted to allow it.

Yeah, that's what I said! :)

There's a difference between what's legal / allowed by the license and what's moral / tactful. Forking a project which was not abandoned or taken proprietary is a statement of distrust to the maintainer(s), of course it will create bad blood. (And I only mean real forks there, not development branches approved by the original maintainer(s).) It's sorta like stating that the original maintainers are incompetent (and to make things worse, the GCC4TI developers have made explicit claims/insults of that kind in several places). There are plenty of things which are legal, but morally reprehensible, for example betraying one's spouse. If you marry a woman and then cheat on her, you did nothing illegal (at least in most countries), but you can't expect her to still like you after that. It's the same when you fork a project.

None of the people involved in GCC4TI ever tried to work *with* TIGCC. They could have started contributing to TIGCC, integrating the team and then trying to influence its future. But they didn't want that, they wanted decision power without having contributed anything of value (if at all - I don't remember any contribution to TIGCC from Godzil, for example, not even a trivial patch). That's not how meritocracy works.

I'm also really angered by their statements that they represent the wishes of the community, when really they're merging low-quality patches requested by a vocal minority (such as support for VTI) which hurt the user experience (imagine a new user trying to use VTI: first they'll notice their calculator (Titanium/V200) isn't supported; if they work around that by using a TI-89/92+ update, they'll have trouble with the lack of a C debugger and with all the bugs and limitations of VTI; in short, the user experience will suck).

Oh, and I should add that the interfacing code with VTI they readded to their fork of TIGCC IDE also has its own bugs and limitations:
* try bringing another window to the front while a file is being "sent" to VTI - keyboard input (which is the hack they use to "send" stuff to VTI) will land in that window!
* no special characters can be used in the program arguments, not even quotes (because 2nd can't be pressed due to how VTI checks the Alt key, which doesn't allow 2nd+CHAR nor the keycombo for the quote).
(This is in addition to all of VTI's own bugs.)

The switch to TiEmu, which has a true inter-process communication interface, fixed these issues in TIGCC. GCC4TI restored the old buggy code.

> None of the people involved in GCC4TI ever tried to work *with* TIGCC.
That is just plain SLANDER !
Seriously, how DARE you write about moral and tact ??

Both PpHd and I tried to contribute. I'm listed in the TIGCC credits ( http://tigcc.ticalc.org/doc/ info.html#credits ) for having contributed documentation files (dozens of them) back in *2002-2003* (!)...
I know, there are several dozen other files. You discovered a mistake in one of them, and some others break the callgraph, because it's hard to move a file around, due to the stupid way the callgraph was done. The latter problem was fixed in GCC4TI, without using the overkill solution of rewriting everything (as I mentioned above, you don't have a good use case for the rewrite...).

> They could have started contributing to TIGCC
We did (and partially succeeded), *YEARS* ago !

> That's not how meritocracy works.
I know how meritocracy works, I've already explained to you that I became one of the maintainers of the open-source toolchain (the Cecilia implementation of the Fractal component model) I'm using (and contributing to when it doesn't so something that it would be neat for it to have) in my work...
As it's open-source, my claim is partially, if not totally, verifiable ;)

You have not contributed anything since 2004, that's over 4 years, what you contributed back then was mainly documentation, not code, and it was "contributed" in a form which is a PITA to merge (huge patch dumps which don't cleanly separate into small parts because of the references instead of small independent patches, non-proofread text containing several spelling and grammar mistakes, untested code (the one-line definitions which go to the headers) which sometimes doesn't even compile, ...). And I can assure you I found a lot more than one mistake. The one you talk about was the one I didn't find (and thus broke my release, which sure didn't increase my motivation to continue merging your stuff). Oh and there was one other "contribution" from you: an invalid "optimization" (untested of course, you'd have noticed otherwise) which turned a working loop into a buggy one. That plus the uncompilable definition in your documentation patch makes 2 times you broke a TIGCC release. And you didn't learn your lesson, as your broken ld-tigcc timestamp patch shows.

As for PpHd, did he contribute anything other than the recent small ld-tigcc patches (of which the BSS section one needs work which he is unwilling to do)? His contributions don't even come close to the amount of work we TIGCC Team members each did.

> You have not contributed anything since 2004
And ?
It remains that your "None of the people involved in GCC4TI ever tried to work *with* TIGCC." claim is not only wrong (it's a fact and it's very easy to prove it), but also, it's plain SLANDER.

You know that slandering people is illegal, and that attacking computers is illegal. You were targetted by slander back in 2004 and complained about it.
So WHY are you doing BOTH slander and computer misuse against others ?

WTF, in the same post you accuse me of slander and you come up with your ridiculous "attacking computers" claim.

I did NOT attack your infrastructure, even Godzil confirms it, ask him, he's your admin, he must know!!!

And no, I don't consider a huge patch dump in "take it or leave it" format "working with TIGCC", sorry. You were asked with helping out merging it, you said you had no time and we had to work with whatever was there.

> "your ridiculous "attacking computers" claim."
It's a fact that you triggered the anti-abuse protections of the server, see http://www.yaronet.com/en/ posts.php ?sl=&s=117939 &p=1&h=15#15
("short answer: was flagged as a bot/downloader and got banned for 48h").
Godzil unbanned you manually before the end of the 48h period.

You have little credibility when you're posting something along the lines of "I did not attack the computer, I only used it normally".
Not only you (well, the same IP as that which is the main editor of the TIGCC article...) have already defaced the Microsoft page on July 11th, 2006 (another example of how constructive you can be when you've got a problem with something), but you've also posted above that "None of the people involved in GCC4TI ever tried to work *with* TIGCC". This flies in the face of evidence that has been in multiple TIGCC releases, and on the TIGCC website, for YEARS !
(you were already part of the TIGCC Team at the time, so you should definitely know better)

It's a false positive by an automated script. Even Godzil says it was a false positive. Why do you continue with this lie? I have no intention whatsoever of sabotaging or attacking your infrastructure and never did anything like that, quit being paranoid!

I know Godzil wrote it's a false positive, he did so 9 posts below the yAronet post I linked to, where he explained the reason for your IP address being banned...
Still, given my own experience with the server (I too browsed multiple changesets quickly, and I even once opened ~20 tickets in several seconds, without ever tripping the protection that you tripped), I'm not *completely* convinced.
It's my right not to be convinced and it's my right to tell about it, isn't it ?

What's not your right, though, is smearing slander filth against other people like you did. Your post about us not having ever tried to contribute was not only baseless, but there's consistent basis of the exact opposite !

I just didn't express myself clearly enough.

What I wanted to say is that none of you tried to *join* the TIGCC Team. You (Lionel) indeed made some contributions in the distant past. But you never tried to join the team, which is what I really meant with "work with TIGCC" here: my point is that you (all of you) should join the TIGCC team instead of starting up your own.

And no, it is not your right to post libel/slander about me just because you refuse to accept the facts, which clearly show that your allegation that I was supposedly attacking your project's server is a blatant LIE!

Oh, and this was my last post in this flamefest, unless our beloved friend posts even more slander.
Arguing with someone so eager to lash out at other people and other people's work yields nothing.

Just give up before you fill up the database.

or when we start to have to scroll right to view some comments

It's your right to see me complaining about your computer misuse as slander, but at least, *I* have something to back my claim.
On the contrary, there are multiple facts backing the *opposite* of *your* claim about us not having ever tried to cooperate, ranging from the TIGCC credits to the topic http://tichessteamhq.yuku.com/ topic/4650 , in which we posted patches for TIGCC *AFTER* we started working on the fork...

> You were asked with helping out merging it, you said you had no time and we had to work with whatever was there.
At the time, yes, that's what I wrote, because that was true. I sent the state of work near the end of summer (at least, after the work required by 89T hardware/software changes), before restarting a full-time occupation known as "university".
The reason why it was not completely ready for review&merge, was that stupid inconsistent naming of references between documentation files (Sebastian's and your fault), which made it hard to move files from a header to another. I hadn't updated some references to match my changes, so the update tools barfed on it.
At the time, there was a wider gap of programming knowledge and experience between [Sebastian and you] and me, so you could have fixed the problem more easily than I could have...

Nowadays, the problem is fixed in GCC4TI by a <130-line Perl script (I learnt Perl after you asked me to rework my updates), and it didn't even require rewriting all the documentation tools (there's no use case for that).

Oh and PpHd really didn't try hard to work with TIGCC when it comes to those ld-tigcc patches. When I told him his patches were not acceptable to TIGCC in that form (i.e. they need more work), he immediately answered he'd rather fork ld-tigcc than do them properly (and that was before GCC4TI, he'd just have shipped a forked ld-tigcc within PedroM). Sending a patch to a project on a "take it or leave it" basis, with "leave it" = "I'll fork your project", is not "working *with*" a project.

> he immediately answered he'd rather fork ld-tigcc than do them properly
I assume that either PpHd wrote it in a publicly-accessible place, or that you have his permission to redistribute the contents of his message ?

The former. http://urlx.eu/_MTE2Mw

PS: See also my reply there.

You really need to stop whining and get over it. If you're correct and they're incompetent, then the fork will wither and die. And if you're incorrect and they know what they're doing, the fork will help make things better. What are you so afraid of to act like a cornered and wounded animal?

You just put in words what probably the majority of people reading this are thinking.

The reason is simple, the tool/daemon had crashed a few day before (and didn't restart due to a remaining lock file that haven't been removed)and I didn't notice it until the 05/01 morning when I restart the daemon.

You speak about UI Clutter when one of one of the dialog box you made yourself is an example of one of the wierdest I ever seen ? (I speak about the Project->Options->Compilation tab->Program Otions dialog.

I had never seen a such shitty dialog box nearly unuseable.

That dialog box was actually designed by Sebastian Reichelt.

r1262, r1269:1271, r1273:1276, r1278:1291 don't touch the trunk. The WIP modifications they contain are therefore not included in the GCC4TI release.
r1266, r1294:1295, r1297:1298 merge upstream commits.

Some of the GCC4TI-specific modifications (especially r1263:1264, r1301:1302) actually *improve* the quality of the code !

That's your opinion. This sounds like the perfect reason to fork a project.

(Multiple-part reply to Nikky Southerland, as the post as a whole is over the size limit...)

The reasons of the fork would be more along the lines of Kevin's general behaviour towards other people's ideas, work and persons, and his closed handling of an open source project.
See a post of mine, down this page: GCC4TI has pieces of infrastructure suited for community-driven development, that TIGCC has lacked for years.
We know that some of our patches are incomplete: this is why they live in development branches, in the GCC4TI repository. At least, we're using SVN, which fixes the most glaring flaws of CVS, the well-known-as-terrible SCM Kevin is sticking to...

One of the best examples of the closed handling of TIGCC, is the unilaterally decided removal of VTI support in the Delphi TIGCC IDE. Despite prior complaints to Kevin from community members, when he wrote about his plan on yAronet.
There's no doubt that TIEmu is a more powerful and less buggy emulator than VTI is. However, most programmers *don't have to* care: VTI's bugs don't affect the vast majority of programs. If you have to care about the Protection emulation deficiencies or the incorrect AUTO_INT_5 rate, then you'd better make some tests on TIEmu (but you can borrow code from other programs which have already solved the problem). Otherwise, you *don't have to* use TIEmu.
Programmers are definitely missing out by not using TIEmu, but let's be realistic: we know that Kevin's removal of VTI support has been unsuccessful in making *all* programmers switch to TIEmu. Instead, some programmers have replaced the TIGCC 0.96 Beta 8 IDE with that of older versions (which are less likely to work well under Vista...), or much worse, some programmers stick to older TIGCC versions (with known bugs !!).

VTI is completely useless for almost all new programmers, because they have a TI-89 Titanium or a Voyage 200, neither of which are supported by VTI at all. Lack of support for current calculator hardware and software (where "current" means "anything newer than 2001") is the biggest problem, much more so than emulation bugs. (And by the way, even HW2 isn't supported properly by VTI, it just emulates a HW1 claiming to be a HW2 - for grayscale, which is used a lot, this can make a big difference.)

There are also several other technical reasons not to support VTI.

The way to get people to use a current TIGCC is to refuse to answer their questions if they use an old TIGCC (your answering some of those people's programming questions was outright counterproductive), not to add support for an obsolete emulator. (That's also how I answer when I see a question about an old Fedora on the fedora-list:
"> Hey, I have this problem with FC6...
FC6 is no longer supported, please upgrade to at least Fedora 9."
It's time that people get to understand what "no longer supported" means.)

As for CVS, it does what is needed perfectly, why should I switch?

>>VTI is completely useless for almost all new programmers, because they have a TI-89 Titanium or a Voyage 200, neither of which are supported by VTI at all.

Um, yea, I'm sure that there are just sooo few new TI-83(+,+Silver,84+,84+Silver) progammers out there, sure.

VTI only has partial 83+ emulation. For proper 83+ emulation, 83+SE, 84+ or 84+SE emulation you need to look elsewhere.

What does it emulate then, 85s and 86s?

82, 83, 85, 86, 89 (ROM 2.04 or below), 92 and 92+ (ROM 2.04 or below). For your other 68k needs you need to use TiEmu and for your other z80 needs you need to use WabbitEmu

VTI 2.5 doesn't work with any recent TI-83+ OS, nor has it ever worked with the 83+ SE, 84+, or 84+ SE (as it predates those calculators.)

It also doesn't support the newer TI-82 hardware (ROM 19.006 calculators.) (I seem to remember that someone had figured out how to patch ROM 19.006 so it would work on the older hardware that VTI emulates...)

VTI 3a (which supports only the 73, 83+, and 83+ SE) does sort-of-work with the newer 83+ OSes, but the emulator is much more limited; it's not really useful for anything except debugging FlashApps.

Those calculators are not supported by TIGCC (nor GCC4TI), so they're completely irrelevant here.

I meant "new TIGCC programmers", of course.

My apologies here; not being very familiar with either VTI or TIGCC, I made an inacurate assumption and am now a bit embarased about it (you know happins when you assume...). In the future I'll try to only comment on what I actually know about.

> The way to get people to use a current TIGCC is to refuse to answer their questions if they use an old TIGCC (your answering some of those people's programming questions was outright counterproductive),
That's your opinion. We beg to differ :)

> It's time that people get to understand what "no longer supported" means.
It's time that you get to understand that in the real world, people are resistant to change.
It's a fact that people keep on using unsupported software (older *nix versions, older Windows versions, and userspace thereof) for years, for a variety of reasons: hardware not powerful enough to run the latest Windows or Fedora, dependence on applications or hardware that don't work on newer OS, dislike of more modern UIs (rightly or wrongly perceived as more complex than older ones), etc.

> As for CVS, it does what is needed perfectly, why should I switch?
"perfectly" = wrecks of data integrity on the client side, due to non-atomic commit (which I've already experienced to be a problem even in single-committer mode) ?
Non-atomic commit is a sufficient technical argument for switching to another SCM (thankfully, hardly any other SCM has this broken behaviour). I haven't used CVS in four years - except for checkouting repositories that still use that crap, of course.
And I'm even less eager to use CVS as a developer now that I'm aware, through the use of modern DSCM, that CVS is not done for mirroring (which is great for working without being connected to the server, it happens to me quite often). Due to the design of CVS, cvssuck is very slow and generates server load.

Sticking to CVS because "it works perfectly" (??!) is akin to sticking to an old OS because "it works perfectly". In one case, you're advocating sticking to an old solution when there are technically better ones. In the other case, you're denying others the right to stick to an old solution when there are technically better ones...

I've never had CVS screw my data up.

(second part of the reply)

Often, when discussing something about TIGCC, the discussion came down to Kevin justifying his opinion for doing (actually, "not doing", usually) something, and others justifying their opinion for doing (or not doing, or doing differently) the same thing.
A stalemate resulted, since there was no way Kevin would integrate in TIGCC things he didn't like (even if multiple other persons presented technical arguments for doing that very thing)... so it did not make much sense to spend time implementing the thing.
This, in effect, has significantly slowed the rate of progress: the community has a large todo/wish list (see the GCC4TI tracker, http://trac.godzil.net/gcc4ti/report/1 ), but there has hardly been anything *undisputedly* new in TIGCC for more than two years !
(most of the work on TIGCC since 2006 was writing KTIGCC 1 for Qt/KDE 3.x, and then rewriting it for Qt/KDE 4.x, yielding KTIGCC 2. KTIGCC 2 is unfinished, IIRC, and it still works only under *nix. Therefore, the "KTIGCC is a brand-new feature" assertion is not universally considered to be true.)

> even if multiple other persons presented technical arguments for doing that very thing

But in all those cases there are strong technical reasons why doing that very thing is a horribly bad idea.

And KTIGCC 2 (the KDE 4 version of KTIGCC) is not a rewrite, it's a port. One small portion (argument hints) does need to be rewritten, and in fact that's the main missing part.

And I should add: The problem is that people are so proud of the idea they just had that they're totally convinced it's the only way forward and they just won't listen to any kind of reasoning of why it simply can't work properly and/or is completely unnecessary/overkill nor to any sort of suggestions of better (and often simpler) solutions to the problem they're trying to solve. And then they'll complain when I refuse to make major, technically unsound changes to TIGCC to support their crazy idea.

You're arguing an oppinion. Oppinions are neither right nor wrong. Would you rather have a more capable program with a few bugs, or a less capable, but stable, program; I can say that one of the two options is better than the other, but I can't force anyone to agree with me.

en.wikipedia.org/wiki/Worse_is_better

http://tigcc.ticalc.org/gcc4tifaq.html

Thanks for the ad ^^

There's a reason I didn't link it from the tigcc.ticalc.org front page...

It is such a shame that you all are arguing over a project forking. And, saying to ONLY use things from your project is only going to upset people.

"What the fork also contains, though, is several low-quality patches which have either been rejected outright from TIGCC because of various inherent technical issues with them or are just not good enough to be merged yet."

Remember to keep an open mind. Many fixes and innovations can have issues and they will improve over time. Saying that ideas or code "isn't good enough for the project" just because they aren't top-of-the-line will generally convey the message that the idea is disliked and will usually put it to a stop. Even though I have little to no experience with 68K's (I do things mainly for z80 and Nspire), I do have experience with communities and it is never good to close-mindedly reject something like that.

I must admit that I have some feeling that you didn't try the GCC4TI before judging it too. Remember, never judge a book by its cover.

For some of the affected patches, it is indeed the idea which is disliked, because it is just broken by design.

And I know the patches in it very well. The code to send to VTI had been in TIGCC for ages, it has been removed because it is broken beyond repair (both the communication code and VTI itself are) and a better alternative (TiEmu) exists.

Well, that is a good reason to remove the code. But what is wrong if someone else makes code (which might not be the same) that performs that function? Just because you don't like it doesn't mean that others should not try it. That really just isn't too nice.

I think that we should all just take a deep breath, and let TIGCC and GCC4TI just go their ways and not ctitisize the other.

It's the EXACT SAME CODE which was removed! The "author" of the patch (Lionel) explicitly say so, and I've also seen "his" patch and can definitely confirm it's the same code. So why would I need to try it again to know how broken it is?

Does that "patch" affect the functionality of the rest of the software?

Not at all.

In fact it help people who are stuck with VTI (for various reasons) to use directly VTI like it was before.

The real bargain was to remove the VTI link in the TIGCC mainstream, not to reintegrate it in the fork.

Anyway Kevin is not a member of GCC4TI and have no rights to decide what is right and what is wrong in it.

The VTI communication code was broken by design, it had actual bugs which were impossible to fix, for example quotes could not be sent on the command line. GCC4TI still has those exact same bugs and will probably have them forever as you have no interest in adding a real IPC interface to VTI.

VTI itself also has plenty of bugs which will most likely never get fixed.

TiEmu solves all these bugs.