Yuku free message boards

Thanks to Tyler and RadSurfer for their testing.

Note that this affects only the IDE. I have not dropped support for VTI in the hardware detection code in TIGCCLIB (though it's something I consider doing at some point because it wastes memory on real calculators just to accomodate a broken obsolete emulator).

And the new IDE is now up too, as part of TIGCC 0.96 Beta 8.

Probably. I guess at least the execute_command interface should do that. Probably enter_debugger and reset_calc too.

But why?

• VTI was last updated in 2001. (And that was an unofficial fork, the last version by Rusty was in 2000. And the source code for the fork has been lost.) In other words, it has been completely unmaintained for 5 years!
• Related to the previous point: VTI doesn't emulate any current calculator models (Titanium, V200) or hardware versions (it only really emulates HW1!), nor support current AMS versions properly (the handle list and program entry breakpoints don't work in AMS 3, and in Rusty's last version not even in AMS 2).
• The 2001 unofficial versions are very buggy (the debugger crashes frequently for no reason), the last reliable version was Rusty's 2000 version which only supported AMS 1.
• VTI's hardware emulation isn't even accurate for HW1, it doesn't emulate the CPU prefetching and a few other details.
• VTI has no C debugger, making it particularly useless for debugging TIGCC programs.
• VTI has no inter-process communication interface. Have you seen what the code to "interface" to VTI looked like? I have. It was sending messages to simulate keypresses, and worse, locating the HWND of a text box internal to VTI's Open File dialog to send it a message changing its text. Yuck! This dirty hack also had other limitations, for example some characters in command-line arguments couldn't be entered (even common ones like the quote) and there was no way to set a program entry breakpoint on the sent program (so if it crashed before the first user action, there was no way to debug that).

So I really don't see a good reason why VTI should still be supported. It has been superceded by TiEmu for years. (For me, TiEmu 2 was "VTI 3" and TiEmu 3 is now "VTI 4".) And every extra checkbox makes it harder to maintain TIGCC IDE, especially considering the type of code which was used in the VTI case.

Quote:

---

Well, VTI has been around for years, you told it yourself, so it's been years people has been used to it.

---

But now TiEmu has been around for years too. You've had years to get used to the new emulator. Why didn't you? One excuse was "TIGCC IDE can't send to it", well now that excuse is no more.

Quote:

---

OK, it's not the ultimate emu, but such an emu is not required to program for ti68k, but if you are doing some very special stuff.

---

VTI can indeed be used only for "some very special stuff", in particular you need to know assembly to be able to do anything with the debugger. And you need to know assembly pretty well if you want to debug a C program with it. I did debug C programs with VTI back when this was the best we had, so believe me when I say this is a really painful process and you need to really know what you're doing. It took lots of time and manual work to check simple things Insight (TiEmu's GDB GUI) can tell you in seconds.

TiEmu, on the other hand, is useful to all C programmers thanks to its C debugger.

Quote:

---

TIemu is HEAVY,

---

It's very lightweight compared to the average commercial app, or to stuff like OpenOffice.org. It is similar in size to Firefox, which Mozilla calls "lightweight".
TiEmu Win32: 4124115 + 5163151 (GTK+) = 9287266 (and the required GTK+ hasn't changed for months and will probably stay the same for a while, so it only has to be downloaded once)
Firefox 2.0 Win32 en_US: 5900416
OpenOffice.org 2.0.4 Win32 en_US: 96865977 without JRE, 115198591 with JRE
TIGCC itself is also comparable in size (4411703). So I don't see where the problem is.

Quote:

---

slow,

---

On a modern computer (>= 700 MHz, and the 700 MHz class is 5 years old now!), it is very fast. And on an old one (such as my 266 MHz laptop), it still works well enough for its purpose: debugging calculator programs.

Quote:

---

unfriendly,

---

No.
If you want a more specific answer, you need to be more specific in your criticism.

Quote:

---

hard to install

---

No. You only need to click "Next" all the time and it gets installed with the default options. This is the same as for TIGCC and many other Window$ programs.

Quote:

---

and takes forever to download, including gtk.

---

See the numbers I quoted: even including GTK+, it only takes 2.11 times as long to download as TIGCC or 1.57 times as long as Firefox. And something really heavy like OO.o doesn't even compare, it takes more than 10 times longer to download than TiEmu and GTK+.

Quote:

---

I don't deny it may be good, but one just can't install it on a non connected computer.

---

Huh? How would you install TIGCC and VTI on such a computer? You can use any of:
* a CD-R
* a USB stick
* a pack of 10 floppies
* a portable music player allowing to store files on its memory
* an external HDD
or any other media to transfer TiEmu, same as TIGCC, VTI or any other software. Heck, maybe if you're really nice Romain will even send you a CD-R with TiEmu.

Quote:

---

Maintaining IDE code for VTI shouldn't have been so bad, have you even touched it once before removing it in all those years ?

---

No, but I would have had to touch it now to add TiEmu support. Replacing the VTI code with TiEmu code was easier, I didn't have to add conditionals, just replace "VTI" with "TiEmu" in some parts of the code. (Heck, there's still several variable names with "VTI" in the name. I would have had to replace all these with conditionals.) In others, I just replaced the VTI interface code with a port of the TiEmu interface code from KTIGCC. This is also a major advantage: TiEmu's inter-process communication interface is pretty much the same no matter whether you use DCOP, OLE Automation or D-Bus, so the logic is almost the same in KTIGCC and TIGCC IDE now, as opposed to the custom hacks we had for VTI.

Quote:

---

I just think (and I'm not the only one) removing that feature is bad, and is just a selfish concern about doing everything (as usual) your own selfish way (but I'm not sure you are aware of that, you may truly think all you do is the best way (which is sad))

---

I work my @$$ off to provide you a C debugger to the community and integrate it into TIGCC IDE as well as possible and you call me "selfish" just because I removed support for an obsolete emulator which hasn't been updated for 5 years, doesn't even have an inter-process communication interface (so it was a miracle the interfacing with TIGCC IDE has worked at all all these years) and doesn't have a C debugger (so it's very unhelpful for TIGCC programmers)? It's you selfish whiners who want everyone to support whatever ancient software you happen to use who are selfish, not those of us who actually do work! (Sadly, I'm one of the few remaining ones, you selfish whiners scared everyone else away.)

Quote:

---

Can you really tell one poor checkbox makes TIGCC IDE impossible to maintain ?

---

Yes. That "one poor checkbox" would have required at least 100 extra lines of code to implement, scattered throughout several places in the IDE. The more checkboxes, the more such code will clutter the IDE, and the more of a pain it will be to maintain. Not to mention that useless options also clutter the option dialogs, which are already cluttered enough as is. (Qt layouts won't even allow that much clutter. Guess why KTIGCC's equivalent dialogs are significantly larger than TIGCC IDE's. It's for this reason.) I'm all for options which are actually useful. This one isn't.

Quote:

---

Come on, be serious. You've done better jobs on it.

---

Don't talk to me in this tone. I'm completely serious, and talking to me like this will not make me reconsider my decision, in the contrary. If you obtain anything this way, it will be a ban. Accusations like this really get you nowhere.

Quote:

---

Remember: I don't tell TIemu support is bad, I just tell it was useless to remove VTI support.

---

And I say it would have been useless to leave it in.

Quote:

---

Note that is not the first useful feature you took from TIGCC (IDE), starting by the "readable generated assembly code".

---

That one was actually a bug fix, the "Generate debugging information" checkbox now actually does what its label says, and the "tigcc -g" option now finally does the same as in all other toolchains. It also allowed me to remove a few dozen lines of no longer needed code.

That "feature" was really only a stopgap around the lack of a true C debugger, its main use was to allow debugging C with VTI. Now we have a true C debugger. Insight also allows you to see interspersed C and assembly if you really want to know what ASM code your C code generates (the MIXED mode does exactly that).

Quote:

---

Not everybody can use or install TIemu/debugger.

---

Why not? If you can install TIGCC, you can also install TiEmu.

Quote:

---

You just make it harder for those who can't (or just don't want).

---

I really doubt the "can't" part, I suspect the "don't want" part is more of the reason, and I don't see why I'm supposed to help these people. There's really no valid reason not to upgrade to TiEmu. It's not like we charge for upgrades.

Quote:

---

I'm not sure to have been the one killing the communauty.

---

It's not just you, you're hardly the only selfish whiner around here. (Just go to that forum with the "y" to find the others.)

Quote:

---

Open your eyes, this forum is dead, there won't be as many people who will use tigcc+tiemu than people who once used tigcc+vti, ever !

---

This is hardly my fault. And keeping VTI support in TIGCC IDE wouldn't have changed this in the least.

Quote:

---

Nobody cares about your "@$$", you're the only one pushing yourself for having the monopoly over TI68K dev tools.

---

Huh? How is it my fault that nobody wants to help? If I complain about competing tools, it's only because their developers' time would be spent much better on helping TIGCC than on starting yet another compiler (or worse, interpreter) which won't reach TIGCC's feature set anywhere in the next 20 years if ever.

Quote:

---

OK, I recon you've done some great work, but you really lack humility, common sense and mind opening.

---

The usual ad hominem FUD, now can we please come back to the facts?

Quote:

---

You've already disgusted me from helping you once,

---

How have I disgusted you? You never gave a reason! For all I know, you promised to help out with Fargo support, then when we reached the point where you were supposed to start actually lifting a finger, you didn't deliver on your promise.

Quote:

---

then from helping people here

---

If flaming and trolling is what you call "helping people", then I did... Your signal:noise ratio on this board is very low.

Quote:

---

and at last from programming for ti86k

---

I assume you mean "68k"... So you not even caring enough about the platform to spell it correctly doesn't have anything to do with your "disgust"? You just found a convenient excuse for your laziness like in the previous 2 cases, and I take offense from that.

Quote:

---

Too bad, tigcc could have been really better, but it might be too late.

---

It could have been "better" how? Do you have any real, feasible suggestions?

And let me introduce to the way things work in the Free Software world: the one who does the work decides. You and the other whiners don't ever do anything but whining. If you think you can improve TIGCC IDE or TIGCC in general, do it.

Relatedly, ExtendeD, I know you're an excellent coder, if you think a single window for the debugger would be great, why don't you send a patch?