Yuku free message boards

> As I said on yAronet, you may not call your software TIGCC, because it is not TIGCC.
Neither you nor other members of the TIGCC team have registered the TIGCC trademark, so this is irrelevant. Full stop. Please stop editing other people's posts for no valid reason.
As I said ( http://www.yaronet.com/en...?sl=&s=117269&p=1&h=11#11 , http://www.yaronet.com/en...?sl=&s=117269&p=1&h=22#22 ) on yAronet: we'd rather focus on functionalities and proposing these functionalities to users, instead of focusing on trolling and hampering other people's work

> Your patch is huge.
You have neither looked at the patches, nor correctly read (or understood) what I've written on yAronet, have you ?
In the first post of http://www.yaronet.com/en/posts.php?s=117269 , I wrote
"Comme vous pouvez le voir, il est facile de gérer à la fois VTI et TIEmu: environ 300 lignes de code. Le gros des lignes du premier patch est dû au changement des infos graphiques suite au redimensionnement de l'interface."
English version:
"As you can see, handling both TIEmu and VTI (along with each other) is easy: about 300 lines of code. The majority of the lines in the first patch is due to graphical information being changed following the interface being resized."
With figures (facts), so that everyone can see that you're posting rubbish: the first patch adds or changes 6996 lines in the IDE. 6832 of those lines, i.e. more than 97% of the patch, are due to the Delphi form that handles the Preferences menu. Delphi stores most of it as a bitmap, and that's what makes the bulk of the diff in that file (95+%). Since when bitmaps are functional code ?
What I wrote holds: it's easy to handle VTI along with TIEmu. It would still hold even if it required 600 lines instead of 300.

> * You clutter the configuration dialogs with a useless option.
That's your opinion, we beg to differ.
> There is no benefit to supporting an old unmaintained emulator when there's an alternative which has all its features and more (including something as essential for TIGCC programming as a C debugger!),
It's certainly useful to a portion of TIGCC users, but it's definitely not "essential", sorry. Martial (Folco), PpHd, Flanker and I are programming mostly or exclusively in assembly (nearly all of my present work on TICT software is ExtGraph): where exactly does the C debugger help ?
I've never used that thing since it was in early beta, where its introduction made TIEmu unusable for practical purposes (crashes every few minutes - almost worse than in the pre-alpha TIEmu 2 series, which ExtendeD, yourself and I helped debugging and improving). And for a long time, the Debian tiemu-gdb package didn't contain it, so I couldn't use it anyway.
Now, it is out of beta, but it's slowing TIEmu down, and often annoying me with warnings about some "1 / 0" expression being invalid...

> all it does is make a mess of the configuration settings for no reason.
How is that ? I restored the usage of the old VTI registry key, while leaving the usage of the TIEmu registry key intact.
(if I did otherwise, it's a bug).


> * You did nothing to solve the root problem, which is that VTI does not have a viable inter-process communication interface. You need to fix VTI, not TIGCC IDE. And if you implement the TiEmu interface, for which the sources/specs are readily available, VTI would work in the current unmodified TIGCC IDE without your hack.
You know it very well that the sources of VTI (I mean, the significantly improved version that JM did, none of us on yAronet would want to use Rusty's one anymore) have been lost. Therefore, you know it very well that it's hard to implement what you're suggesting. At least, harder than spending several hours reintroducing a known-working feature in TIGCC IDE, feature whose removal has been criticized by multiple users over the past two years
(Not to mention that we're aiming for easy installation - see below - and that your suggestion requires users to update their VTIs. VTI's installed base is gigantic. Users will definitely massively upgrade their VTIs if the new version brings little but compatibility troubles with ALL current TIGCC installations, yeah...)

> * Your Delphi code will become completely useless when the cross-platform KTIGCC 3 will become the only supported TIGCC IDE.
KTIGCC 2 isn't even complete, fact. It's not portable (you wrote it has multiple hard-coded 'unixisms'), fact. And you're talking about KTIGCC 3 ?!
KTIGCC 3 requiring the huge, non-native and very buggy KDE 4 framework for Windows is precisely the last straw that broke the camel's back for us, THE particular event that decided us to make a more organized TIGCC fork (it already existed for ld-tigcc in PedroM). It started with the topic ( http://www.yaronet.com/en/posts.php?sl=2&s=113677 ) where squalyl detailed how much kdewin sucks, and where you wrote (down the first page) that KTIGCC 3 would replace completely the TIGCC IDE, but that it would require the huge kdewin (which is buggy, that was the topic).
kdewin clutters users' machines, makes TIGCC installation harder (because it requires yet another framework for non-native applications, there's already GTK+ for TIEmu and TILP), for what purpose ? Running a wimpy IDE which is less featureful than other IDEs (worse code completion, etc.), and has ZERO distinctive features (neither TIGCC project handling and TIEmu communication can be taken into account here: they are already correctly handled, on Windows by the TIGCC IDE and on *nix by KTIGCC 1).
Your plan for KTIGCC 3 vs. the TIGCC IDE makes zero sense to us.

> Are all those graphical changes really necessary?
Yes:
> And what did you do to that bitmap? (You didn't even explain the change,
We did not explicitly modify the bitmap, it's a byproduct of a simple resizing of the form (its height had to be increased so that the new radio button + edit field + "Browse" button can fit). It's Delphi's fault, due to the way it encodes form information.
> for all I know you could have replaced it with anal pr0n.)
...

> > I didn't remember the exact message, so I reinstalled that annoying TIEmu + GDB, and reproduced the bug: every time you're changing the OS version (which is something I'm doing at least once most times I'm using TIEmu), you get the message of which I made a screenshot at http://tict.ticalc.org/misc/gdb_sucks.png .
> When exactly does that happen? Do you have a .dbg file loaded when you change the OS version and get that error? Or is just changing the OS version without anything loaded enough? Because I cannot reproduce this here on Fedora 9. (Maybe yet another Debian-only issue?)
This happens even if I haven't explicitly loaded any .dbg file loaded before changing the OS. I don't use any saved state (at least on PedroM 0.82 alpha 1 89T, which is the default OS TIEmu boots here), if that might influence the problem.

> > (yes, the name of the PNG is intentionally offensive... just as e.g. your bashing of ETP, which used to be present in your signature on yAronet until fairly recently, this presence lasting several years)
> That was on Ti-Gen, not on yAronet.
Fine, but it's offensive all the same

You don't understand why some people are attached to VTI, despite its drawbacks that I know too (well, most of them: I have never stumbled across using VTI on non-default dpi settings myself) and that it isn't maintained... but the fact is, they are, and these persons can collectively give multiple reasons for this.
You and us have diverging opinions on the issue. (Up to a point, of course) We don't feel that it's up to us maintainers to decide what tools users should use. In other words, we're more into giving users the choice to use the software they want to, than you are.
Maintainers preventing users to use the programs they like doesn't work so well anyway for practical matters. By making it harder to use than TIEmu, you have tried to prevent people from using VTI, an old, incomplete emulator that may lead to programs crashing users' calculators because several problems cannot be detected with VTI... What have you ended up with exactly ? Some people have switched, obviously, but others are still sticking to older versions of TIGCC (older 0.96 Betas or even 0.95) because of the functional regression they think IDE -> VTI communication support being removed is... Some of these older versions have known bugs that may lead to programs crashing users' calculators (or valid programs that cannot be built even if they should be buildable).

FYI, we didn't have to provide some information over the respective characteristics of the two emulators, but we did:

Caption = '&Virtual TI (old, buggy, incomplete but faster)'

Caption = 'TiE&mu (newer, better but larger and slower)'

> That's why you must refuse to answer any questions people are asking unless they're using the latest version of TIGCC
Up to a point, we beg to differ

> then I'll ask you to rebuild ExtGraph with such a global import, that might help forcing people to upgrade. What do you think of this idea?
Er... I wonder why you're asking me what I'm thinking of your idea ?
Like TIGCC and PedroM, both of which have already been forked, ExtGraph is open source software, under a license that allows forking.
Either I'm not willing to follow what you're "strongly considering" doing (and you or anyone else have every right to fork it), or I'm willing to follow what you're "strongly considering" doing (and you or anyone else have every right to fork it).
So whatever I'm thinking of your idea doesn't matter at all.

For good or bad, "If it ain't broke, don't fix it" is an important trait of human behaviour. Just to give one example, many people are still using Windows 2000 or older, Word 2000 or older, and all kinds of vintage software on vintage computers, because it just works for them. No matter they're using unsupported software that has bugs and security holes.
You should learn living with that