You mean Fedora Core 4 isn't modern?

I'm not going to dignify that question with a response.

Wait.

No, it's not, as that release has been out of support for years. ;-)

Time to upgrade to Fedora 11 or 12.

I concur. I upgraded from Fedora 8 to Fedora 11 a few months ago. It's definitely better than F8.

(then again, I wouldn't have bothered to upgrade had I not run fsck on the root partition of F8 while it was mounted. d'oh!)

You should upgrade to Ubuntu 4.10. It is what champs use.

That's also obsolete and out of support.

Thanks for the suggestion!
I love Ubuntu 4.10!

That is extremely obsolete! The latest version of it is Ubuntu 10.04! The version I recommend is Ubuntu 9.10.

I've been using TI-Connect 1.6 on Windows 7 x32 for the last month or two fine before this update came out...

There has never been an issue for 32-bit Vista or Win7; that uses the same driver as x86 Windows XP. It's when you get x64 Windows that the drivers for USB won't work. This new update apparently adds drivers for x64 versions of Windows.

(P.S. it's called x86 or 32-bit - there's no such thing as x32)

TI Connect 1.6 does not work on Snow Leopard. Does the patch fix that? However, 1.7 Beta does work, so its not a big issue.

My mistake. The patch is only for windows.

And when do we get Linux support? That's the real question.

Although Linux support would be nice, we already have TILP. :D

And soon CalcForgeLP. :-)

VirtualBox + WinXP

Wow, it's ALMOST like they care.

It'll happen when teachers start using Linux. As BrandonW pointed out over IRC, TI doesn't listen to students, just the teachers, the people who actually create the demand for the calculators.

hey, finally!

Finally! I've been using Windows XP in Virtualbox to sync up my 83+.

Please TI also support to TI FLASH Studio on winXP-sp3, Win7

Thanks

Just use TIGCC, it's worlds better anyway. :-)

I concur, and TIGCC's community-oriented derivative GCC4TI is even better ;)

LOL, GCC4TI is not any more "community-oriented" than TIGCC is, it's just oriented towards the ego of 2 or 3 people who hate me (and you're one of those).

I could have bet money that if you saw my message, you'd spew, as usual, your hatred and lies about GCC4TI and its contributors :)

On technical matters, first:
* on the one side, there's TIGCC, which expects people to download, compile and install TIGCC from SVN to get the bugfixes, and the absence of new significant feature or optimization, made in the past three years (and counting). No bug tracker, no mailing-list, no real developer forum.
* on the other side, there's GCC4TI, which provides recent ready-made releases (and for those who are using other *nix flavors, more portable scripts with proper error handling). A strict superset of TIGCC. A bug tracker, a mailing list, a developer forum.
* the latest release of GCC4TI has, besides multiple bugfixes, started tackling the large backlog of unprocessed contributions to TIGCC. Not even the sprite routine optimizations contributed in 2002 and 2003, at the same time they were performed in ExtGraph, have been processed by the sole TIGCC maintainer.

On non-technical matters, since you're introducing them: let's just say that the facts that we have forked TIGCC, and that many people in the community hate you, is just a consequence of your long-lasting disrespect towards our ideas (lots of things seen by multiple persons as improvements, shut down by you in an unfriendly way) and our work (not processing the contributions of five to seven years ago, etc.).

Your post is yet another shameless attempt at deceiving people into believing that you're the victim... but repeating lies doesn't make them true ;)

> * on the one side, there's TIGCC, which expects people to download, compile and install TIGCC from SVN to get the bugfixes,

Nonsense. First of all, TIGCC is maintained in CVS, not SVN, but that's a technical detail. But most importantly, I do not expect people to compile CVS HEAD to get the bugfixes, in fact I don't really expect anybody other than me to compile TIGCC from CVS HEAD as nobody signed up to become a permanent TIGCC contributor and CVS HEAD is intended to be just for developers. I just do not think the bugfixes are significant enough to make cutting a release a priority. Most people won't even notice those bugs. And I can send out individual fixed binaries on request where needed. I have often responded to bug reports with fixed binaries within hours (even where the bug was not previously known!), I still provide that service (though response times cannot be guaranteed for obvious reasons).

> and the absence of new significant feature or optimization, made in the past three years (and counting).

It's better not to ship an obscure feature or a minor optimization than to risk regressions like the broken sprite routines in the latest GCC4TI release. Features and optimizations need careful testing, which GCC4TI failed to do, and which you, Lionel, also have a track record at failing to do (you already broke 2 TIGCC releases with broken contributions), so I cannot trust you anymore when you claim something you committed to GCC4TI is "well-tested".

> No bug tracker, no mailing-list, no real developer forum.

None of this stuff is really needed. I am, in fact, considering using a bug tracker instead of the current form, but the current setup works fine. The important point is that bugs need to get to the developers, the bug report submission form does the job. As for a mailing list, it would be redundant with the existing message board.

> It's better not to ship an obscure feature or a minor optimization than to risk regressions
Making mistakes is an integral part of doing actual work. Despite the backlog of contributions and ideas, nothing got added in TIGCC in the past 3-4 years, and in the past year, hardly anything got done - not even fixing the problems that we directly reported to you despite your attitude towards us - so it's hard to make mistakes in there ;)
In GCC4TI, we're doing actual work (including some work that reduces the probability to make mistakes, e.g. increasing test coverage), so we have higher probability to make mistakes.

There is indeed a problem with the GCC4TI 0.96 Beta 10 sprite routines. However, a complete erratum (which gives access to more fixes and improvements from GCC4TI SVN, BTW) is available on the GCC4TI website, linked to from both the front page and the download page.

You forgot to mention your own track record for sub-par code (linker, GCC) ;)

> I just do not think the bugfixes are significant enough to make cutting a release a priority.
That's your opinion. It doesn't hurt making a bugfix release once in three or four years.
However, now that GCC4TI distributes TIGCC's bugfixes AND more bugfixes and improvements of its own, making a TIGCC release is even less of a priority ;)

> > No bug tracker, no mailing-list, no real developer forum.
> None of this stuff is really needed
That's your call.
> I am, in fact, considering using a bug tracker instead of the current form
You've been saying that for years.
> but the current setup works fine
For centralized project governance and preventing potential contributors from helping you tackling bugs and feature requests that have been posted in the open, it works just fine. For community-oriented governance and development, not so much.

> * on the other side, there's GCC4TI, which provides recent ready-made releases (and for those who are using other *nix flavors, more portable scripts with proper error handling).

They aren't really more portable (the "portability issues" you fixed were of your own making, the script was #!/bin/bash for a reason) and they degrade user experience (spartan prompts instead of pretty dialogs, and due to the above unnecessary "portability fixes", on some systems, the prompt is even split across 2 lines).

> A strict superset of TIGCC.

Except when you break our existing features, see e.g. your sprite routine regressions.

There are also intentional changes in GCC4TI which arguably degrade the toolchain's quality and usability, such as readding support for an obsolete emulator last updated in 2001 with no C debugger, and the resulting UI clutter (yet another option in an already crammed dialog, and one that serves no practical purpose).

> A bug tracker, a mailing list, a developer forum.

So what? See above (a few paragraphs higher, where I explained why there's no need for those).

> They aren't really more portable
We've already discussed the matter twice...

> (the "portability issues" you fixed were of your own making,
If you had written "some" instead of "the", your sentence could be true (but it's a lie and you know it): as we've previously discussed, there _are_ real portability issues in TIGCC's scripts, revolving around e.g. make and install.
> the script was #!/bin/bash for a reason)
A reason that can be argued for, and that can also be argued against.
> and they degrade user experience (spartan prompts instead of pretty dialogs,
As we've already discussed:
* we decided (after discussion) to remove dialogs after finding out that we had to add even more clutter for handling yet another broken dialog implementation. Remember, we're talking about inputting no more than 4 strings from the user...
* PpHd and me, KDE users, have been annoyed by the 10+-second startup time of kdialog, without any meaningful user feedback... definitely top-notch usability ;)

Anyway, the whole process needs to be run in a terminal, otherwise users can't see where the compilation process fails (especially in TIGCC, whose scripts silently continue on error, which can - and did, in our tests before we improved the GCC4TI scripts - yield incomplete installs): this reduces the usefulness of dialogs.
> and due to the above unnecessary "portability fixes", on some systems, the prompt is even split across 2 lines).
Is this a _real_ problem or just a strawman argument.

> So what? See above (a few paragraphs higher, where I explained why there's no need for those).
That's your call. Fortunately, many many users and contributors of FLOSS (not just in the TI-68k community) think otherwise.

> > and due to the above unnecessary "portability fixes", on some systems, the prompt is even split across 2 lines).
> Is this a _real_ problem or just a strawman argument.

It makes the prompts look like crap and makes for poor usability ("Hey, what do I have to say (Y/N) for now?").

> * the latest release of GCC4TI has, besides multiple bugfixes, started tackling the large backlog of unprocessed contributions to TIGCC.
> Not even the sprite routine optimizations contributed in 2002 and 2003, at the same time they were performed in ExtGraph, have been processed by the sole TIGCC maintainer.

The contribution was incomplete as the required .hsf files, containing documentation and header prototypes, were not included. I received those files, by another contributor (hypersonic), on March 1, 2009, the files in the archive are dated December 25, 2008. So the contributions have been pending only for 8 months, not 7 years.

As for merging only the functions which already have documentation, the author of the optimized sprite routines (MrJoey) explicitly asked me NOT to do this, and unlike you I honor the author's intentions!

And you also merged them incorrectly (as a direct result of not having updated .hsf files to go with them; those .hsf files also have correct register parameter declarations), which resulted in the regression.

And finally, I take offense at your baseless allegations of lying. Why do you always have to attack me personally? Focus on the facts and quit the ad hominem bullsh*t.

> The contribution was incomplete as the required .hsf files,
Bullshit. You're _completely_ missing the point of me mentioning the optimizations to the sprite routines I contributed in 2002 and again, with further improvements, in 2003.
Indeed, these ones were optimizations to existing sprite routines, with no change in functionality. Therefor, they don't require documentation in the TIGCC-specific documentation format - and they have been pending for 7 years, not 8 months.

Joey's modifications were contributed in 2005, 4 years ago. As you didn't include my 2002 and 2003 optimizations, Joey's routines used the pristine algorithm of TIGCC's sprite routines...
Therefore, I completely rewrote his routines (keeping credit, of course) for size and speed optimization. I only kept the calling convention (at first: I changed it when fixing the calling convention mismatch hidden by Joey's test program, and no other test program within TIGCC/GCC4TI tests for it).

As written in the reply to one of your previous posts, there is indeed a problem with the GCC4TI 0.96 Beta 10 sprite routines - but we've made an erratum. You "forgot" to mention it.

> And finally, I take offense at your baseless allegations of lying.
> Why do you always have to attack me personally?
> Focus on the facts and quit the ad hominem bullsh*t.
Great, a paragraph full of that backwards-written crap you're a specialist of ! ;)
First of all, the one who introduced personal attacks in here, is you: "it's just oriented towards the ego of 2 or 3 people".
I focused on some of the facts (infrastructure) that make GCC4TI a more community-oriented project than TIGCC is. I can add that we have publicly-accessible bug and wish list, we have multi-head governance, etc. - so your "GCC4TI is not any more "community-oriented" than TIGCC is" is a lie.

The only reason TIGCC doesn't have "multi-head governance" is that when Sebastian and I asked for help years ago, and when (after Sebastian left) I've been keeping asking for help all this time, you (all of you who are now in the GCC4TI team) WERE NOT THERE to help! All these years, you have never been willing to do any actual WORK. You just kept whining about there being no TIGCC releases, but doing NOTHING to help me getting things done. You could all be TIGCC Team members (and thus part of the "governance") by now if you had actually HELPED all these years instead of complaining and flaming. Sure, some of you have sent some small contributions, but always unimportant things such as minor optimizations (which of course got treated as low priority, because that's what they are) and never anything for the stuff which really matters and which is the real work, like porting the GCC patch to current GCC releases with many interesting upstream improvements (and in fact, there still seems to be no movement towards that in the GCC4TI project, you're wasting all your time on irrelevant details) or like picking up maintainership of the Delphi code (which at least you, Lionel, could definitely have done as you say yourself that you have Delphi installed and some experience with it; this has been an area where I've been desperately looking for help ever since Sebastian left and got completely ignored). If you (all the GCC4TI developers) were truly interested in keeping TIGCC a team project as it had always been (until the "team" degenerated into a single remaining contributor due to unfortunate circumstances), why haven't you done anything to join? Where have you been all this time? Why can't you work WITH the TIGCC project instead of splitting already thin resources on a useless fork?

Another post of yours containing backwards-written things, the usual disrespect (e.g. "useless fork" - remember, WE delivered to users fixes and improvements under a usable form, while you STILL haven't) and another defense of your broken governance model... I did not expect anything less from you ;)
Your ramblings aren't even coherent (!): for example, "All these years, you have never been willing to do any actual WORK" vs. "some of you have sent some small contributions".

We ARE able to cooperate with other people of the TI-68k community, as evidenced by the credits of dozens of programs. We HAVE been willing to work on improving the main TI-68k development environment.
However, you discouraged us from doing so, by rejecting or despising (years of delay; "useless", "minor", "not supported" and sibling favorite expressions of yours)...) other people's work and ideas, even when they do solve a problem, or otherwise improve things for multiple persons.
It's just too easy to blame "unfortunate circumstances" for the head count dropping to one and never coming back up.

Let's mention two of the other ways you turn potential contributors away in the mid-/long-term:
* the absence of an open place to post and track bug reports, feature requests and contributions;
* the attitude of treating easy-integration contributions as unimportant and not bothering to look at them for years, while insisting on newcomers to take on hard / overwhelming tasks.

> Another post of yours containing backwards-written things,

Whenever you don't have concrete facts to counter with, you use that nonsense "backwards-written" term.

> e.g. "useless fork" - remember, WE delivered to users fixes and improvements under a usable form, while you STILL haven't

1. Those "fixes and improvements" range from "useless for 99+% of the users" (fixes for bugs a single user encountered once, or which you found during testing with an artificial testcase and which never hit any actual program) to just plain "useless", not to mention the actually harmful ones (all the stuff I have rejected for good reasons and you merged anyway).
2. People really needing the fixes can get them (just e-mail me and get a fixed binary for your concrete issue).
3. You could have helped me release a new TIGCC with those "fixes and improvements" (except the broken ones, of course!), they don't make the fork "necessary" in any way.

> Your ramblings aren't even coherent (!): for example, "All these years, you have never been willing to do any actual WORK" vs. "some of you have sent some small contributions".

"Actual WORK" means long-term maintenance (which is the real work), not shaving 2 bytes off some assembly in tigcc.a as a fire-and-forget patch.

> * the absence of an open place to post and track bug reports, feature requests and contributions;

I don't see how this is a serious obstacle at all. It sounds more like an excuse.

> * the attitude of treating easy-integration contributions as unimportant and not bothering to look at them for years, while insisting on newcomers to take on hard / overwhelming tasks.

This is just how things are: What I need contributors for is to help with the important tasks. Those tasks tend to be hard, as if something is important and easy, I've already done it! If you see something easy not done yet, ask yourself WHY this is not done yet. Usually the reason is that one of the following is true:
1. The whole idea of the patch is broken.
2. The idea is good in principle, but your implementation is too simplistic and misses all the real issues, a complete implementation needs a lot more work.
3. The idea is fine, the patch is fine, but its benefit is only marginal, it requires a lot of testing to make sure it doesn't break things, and there are much more important issues (e.g. actual bugs) to solve first. (This is usually the case for all those tigcc.a optimization patches. If you really want to optimize TIGCC output, focus on GCC compiler optimizations, which can save entire kilobytes in large programs and might even save more space in the C functions in tigcc.a than some manual optimization in the assembly functions. Those patches to the handwritten assembly which save something like 10 bytes at best are laughable in comparison.)
And in fact, when I reject a patch, I always say why (which is usually one of the above). Asking yourself this question BEFORE wasting your time on the patch would save you the frustration of a rejected patch.

These are MAJOR failures for a so-called maintainer of an open-source software. You're actively preventing people from using the well-known "start small" entry point to meritocracy (remember, you're always touting meritocracy)...
Of course we're not happy with that - and we're trying to make you change your wrong ways, for the common good !
But after
* many years of complaints (since you refused or delayed most of our help, we couldn't do much else than complaining - or creating a fork !);
* fewer years of stagnation in the main TI-68k development environment;
* your sudden announcement of such a strange "high priority" TODO list item as imposing Windows users to download the huge (and enormously buggy, at the time) KDE 4 bloat just so as to use a wimpy IDE;
* your insistance on upgrading the GCC version, which is not even guaranteed to be a win because of various m68k optimization regressions in recent versions, for the benefit of ever so few remaining users, is a hard task with defavorable cost/benefit ratio
we've successfully decided to perform the maintainership work you're not doing.

And you keep spending your time trolling and misrepresenting (not just here - on yAronet and TIGCC/TICT HQ as well) instead of doing, you know, actual work.
And you keep wasting _our_ time straightening out a few things, because we can't let you paint as what we aren't (attackers), while trying to paint yourself as what you aren't (victim). Only those who don't know the facts and don't analyze them would believe in that.

> * many years of complaints (since you refused or delayed most of our help, we couldn't do much else than complaining - or creating a fork !);

Your "help" wasn't anything I or Sebastian or whoever asked for help with! You focused on the wrong issues.

> * your sudden announcement of such a strange "high priority" TODO list item as imposing Windows users to download the huge (and enormously buggy, at the time) KDE 4 bloat just so as to use a wimpy IDE;

You know very well why this entered my plans and got that high priority, in fact I wrote it black on white in the very post you quoted: Nobody was willing to maintain the Delphi code, despite repeated desperate pleas! The result is that it is near-impossible to make ANY changes to the IDE until KTIGCC/W32. If you want us to keep the Delphi code, then MAINTAIN IT! (And this also includes making any changes I request and provide the KTIGCC implementation for.)

Once again, you're blaming me for something which is of your own making (because you were/are clearly qualified and in possession of the required software to pick up the task, but refused to do it).

> * your insistance on upgrading the GCC version, which is not even guaranteed to be a win because of various m68k optimization regressions in recent versions, for the benefit of ever so few remaining users, is a hard task with defavorable cost/benefit ratio

The new GCC has many interesting features which truly benefit all our users. In particular, the optimization switch pragmas solve one of YOUR main complaints about the IDE. (They allow easily setting flags per file and even per function.) There are much more important things in a toolchain than raw code size/speed.

If the "optimization" you talk about was moving the drawing mode conditionals out of the loop, that was intentionally rejected (and one of the constraints I told Joey for the assembly routines was not to do that) because it increases code size (the loop gets duplicated).

As usual, this kind of discussion is leading nowhere...
If you want to keep on rambling, fine, it's your time that you're wasting (instead of, for example, moving, once in a while, your lazy @$$ to perform actual work on the projects that you're supposed to maintain).

I trust you that any subsequent post of yours won't contain the usual kind of disrespect you're famous (in the bad sense of the term) for, so I shouldn't have to set some matters straight ;)

Isn't VirtualBox great :)

Yeah, I've been using that for Vista Home Premium x86 backward-compatability for some time now. Very usefull, even for 32-bit Windows that can't run legacy software (like my printer's allign cartradges feature that won't run on Vista or 7).

VBox is great, but it doesn't let you tap the full processing power of your machine. Not that windows has much other choice, but I like BootCamp better.
Snow Leopard and Win 7

Not to get off-topic but I just wanted to point out there are a couple others for Windows:
-VirtualPC 2007 (free from MS, no USB support)
-Windows VirtualPC (free with Windows 7, +USB support)
-VMWare (paid, +USB support)
-VMWare Player (free?, +USB support, can't create VM's)
-VirtualBox (free, +USB support)

There's also the free VMWare server, but I've never managed to get that to work (it just hard-locks my PC whenever attempting to start a virtual machine). VPC 2007 is certainly much more idiot-friendly.

Agreed on the CPU power, but then again how much CPU does it take to link with a calculator...

I actually don't use it all that often but I do need my XP VM for things like calibrating new print cartradges, accessing some network equipment (with IE6), and working with Blackboard (web-based software my university uses, it works better on IE6 than IE8)

I agree that is does not take much CPU to link a calc. I am speaking as an engineering student who uses AutoCad and Autodesk Inventor, which do take up a lot of CPU. That is why I went with BootCamp. Also, VMware Player was the only one I had heard of for Windows, besides VBox. I guess the encompassing point is to choose what works for you.
On a side note, and I could be totally wring, but do you go to Calvin College? I know Calvin uses Blackboard for Knightvision.

Nope, I'm at the University of Mary Washington.

A lot of colleges use Blackboard, it's a great piece of software when it works...or terrable when it doesn't.

I'm not a Mac user so no idea how Boot Camp/Parallels works. I've read claims that VBox is faster than other VM programs for many things but I can't really try it myself.

> A lot of colleges use Blackboard, it's a great piece of software when it works...

... i.e. never ;-)

> or terrable when it doesn't.

... i.e. always. ;-)

Thankfully, our university (University of Vienna, Austria) didn't renew their license for this crap.