Yuku free message boards

The "Flashappy" patch that is required prior to installing GTC isn't currently too easy to find, though I've read it should be added to the ticalc archives some day soon.
Currently, the second result of a "Flashappy" request to Yahoo! returns a direct download link. The same request to Google returns, as first result, a direct download for an older, harder to use version. Don't use the older version.

GTC currently offers no way to browse the functions' documentation on-calc, but there's talk on yAronet about providing it. It would eat up 200-400 KB (estimated) of memory, though, so it would not be as usable on 89 and 92+ (Maxmem-patched if necessary) as it would be on XPand-patched V200 and 89T.

> it cannot process functions beyond a relatively low maximum size
This allegation, while correct AFAIK, would be more convincing with a figure


Many end users don't give a damn about a software being FLOSS or not, so I'm not convinced bringing once again this semi-off-topic rant about GTC being non-FLOSS was necessary.


> it is also missing some new features like the *scanf family functions
It's a fact... but it's not like the *scanf family of functions is useful for (and used in) many TI-68k programs, due to its sheer size (even if you did a good job making a small implementation). For practical matters, hardly anybody gives a damn whether GTC is lacking them or not.

> Current versions of TIGCCLIB do not work with GTC due to its technical limitations.
Unlike you and me, some people who could read this topic have not been programming for TI-68k calculators long enough to know what you're talking about, so you should have given technical information
GTC indeed doesn't have the ld-tigcc linker, which is designed for computer usage and therefore probably too memory-hungry for on-calc operation on programs > 24 KB. Since TIGCCLIB of TIGCC 0.95+ heavily uses features introduced by TIGCC 0.95+ ld-tigcc, it's obvious that GTC cannot use the TIGCCLIB of TIGCC 0.95+ without prior modifications.

Call that 'technical limitations' of GTC if you wish, but you could also have enlightened readers with what could be deemed a 'technical limitation' of your own ld-tigcc: its poor data structures, which give terrible results on large compilations, as detailed in http://tichessteamhq.yuku...bal-data.html#reply-32762 (source of the '90% figure': http://www.yaronet.com/po...l=&s=108648&p=4&h=111#111 ). Needless to say, the figure for programs smaller than 64 KB is lower than 90%.

> because I don't think many people care about why exactly GTC does not support the latest TIGCCLIB, what matters to them is that it doesn't support it.
Well, I tend to think you're wrong
See, one thing my hobby optimizing a couple dozen other peoples' programs taught me, is that most people don't know the wide range of possibilities offered by TIGCC and its linker. They do not seem to have strolled through the documentation of the compiler and linker switches & features - or maybe they have, but they haven't gone through trial&error to see what's best for each of their programs.
Unless there's a compelling reason (e.g. program too slow, the 64 KB limit nearing fast, etc.), a proportion of programmers spends little time optimizing their programs. Optimization is two-fold, as outlined in S1P9: modification on the code, modification on the toolchain switches. Few programmers use non-default compiler & linker switches (especially relocation types, BSS handling). Even -mregparm is definitely not present in all programs, though it's one of the easy optimizations.

My point is, while GTC (in its current state) does indeed not support a number of capabilities of TIGCC 0.95+ (it's a fact), comments like yours could turn off GTC some programmers that would not even be affected by the difference in functionality
Remember that GTC has (even) more potential for improvement than TIGCC has...

> Turning people off GTC is kind of the point.
How sad you let yourself display that amount of disrespect for someone else's work...

You're always complaining that you don't have time to work on TIGCC. Wrong.
What we can see, since you've been un-banned from yAronet (after a long ban following you showing utter disrespect for other people... very few people have been banned from yAronet over its lifespan...), is that you miss few opportunities to e.g. bash GTC, make off-topic comments about free software, licensing (e.g. yesterday in English-speaking http://www.yaronet.com/en/posts.php?sl=2&s=115368 , 2 off-topic comments out of 2 posts...), Fedora and the like.

As I explained above, in practice, licensing does not matter at all in the TI-68k community. Who cares if commercial use of the GTC code is forbidden by the license ? Commercial software has never worked well on TI-68k calculators.

GTC allows for on-calc development, while TIGCC doesn't. Period. So you cannot turn people off using GTC as an on-calc compiler. Full stop.
You might succeed in turning several people off using GTC as an on-computer compiler, but that's another story.

> As for "more potential of improvement", I don't believe it.
What I don't believe is that you don't believe it
Since "from a technical point of view, GCC has the framework for a lot of things which would take years to implement in GTC.", as you wrote yourself, it's obvious that GTC has more potential of improvement than TIGCC
More seriously... there are ways to reduce the time needed to maintain and evolve a project, you know

> As for "ways to reduce the time needed to maintain and evolve a project", working with you is certainly not one of them, if that's what you're alluding to!
Nope, I'm smarter than this
Within TIGCC, I know - as I have written lately on yAronet, and you've also shown a fresh example - that some of my contributions were not of good quality. Fact.
I have explained why, at the time, I didn't improve them (an activity called "university", you too know very well about it), although I tried: several years ago, I started making a tool that cleared the toolchain part of the work of integrating the contributions. Obviously, the other part of the work, reviewing&testing the contributions for correctness is not my job, that's the meaning of "peer review". Besides checking for stupid copy&paste mistakes in the .hsf/.hsh, which I haven't done correctly at the time, that is.

So no, I was definitely not alluding to you working with me inside of TIGCC. Like numerous times before, I (but it's not always me) was alluding to the way you're maintaining TIGCC: what you are doing, what you aren't doing. You know what we think, you've read it multiple times over the years on yAronet, twice in the past two months. We've got better ways to use our time than translating in English what we've said multiple times under different forms, to no avail.


This summer, I made the tool that fixes the toolchain part of the work for integrating the contributions I was talking about above. Three-four additional years of practice in CS, and knowledge of a scripting language I didn't know at the time, enabled me to make it in three hours. And what happened ? You rejected my "short-term hack" because "it's not the good solution", despite:
* your solution and mine being equally relevant to solve the toolchain part of the problem (for readers, if you care reading through our garbage: it's about consistently adding a header name in front of references in the documentation, or about consistently removing it, in order to fix the current mix of the two which proves a royal pain when moving files around);
* modifying my ~130-SLOC Perl script to implement your solution being trivial (but that's stupid because it would make the documentation not work with the current documentation tools);
* to this date, you still failing to show a truly compelling reason for rewriting the tools. Agreed, rewriting them would make yourself, when you (seldom) use them, independent from Windows and Delphi, and that would be a good time to, in the process, fix annoyances like the "stop on first error" behaviour - but these are not functionality reasons. You haven't shown a single use case, a single documentation feature, where the current time-frozen Windows binaries could just not do the job.
If the problem is generating the CHM file, well, ~90% of personal computers out there run Windows, so you can easily find someone who can do the job for you. It's not like it's hard to install the freely downloadable HTML Help programs, unpack a set of files, run HTML Help Compiler, wait a bit and send you the result...


> I'll be willing to work with you the day you'll accept that I am the TIGCC project leader, period.
Huh ?! Seriously, WTF have you been smoking this afternoon, that makes you write that I haven't accepted that YOU are the TIGCC project leader ??
You are the sole remaining member of the TIGCC team, sole reviewer of patches, etc., and things have been that way for years... so it's a well-known FACT that you are the TIGCC project leader !
See, it's not that we don't accept that you are the TIGCC project leader. It's that we disagree with you on the way to go forward with TIGCC, what modifications could be made on TIGCC. This is VERY different. Please don't try to cheat on facts
For example, you wrote again lately that you don't want to upgrade the 'kernel' support in TIGCC to support PreOS features because that would cause 'lock-in'. The fact is, PreOS being the only 'kernel' that has been maintained for the past FIVE years, and the only one that works on 89T, I fail to see what lock-in upgrading to PreOS would cause...