Ticket #42 Integrate most of the "TIGCC" Tools Suite into GCC4TI - Page 1

Do you really think this makes sense? Much of the tools suite can be used with no toolchain at all, so I think having it as a standalone package is much more useful. In addition, it would make it easier to use the same tools with TIGCC and with GCC4TI and prevent a completely useless duplication of efforts.

Also note that TIGCC/*nix used to bundle the tools suite and I dropped that in 0.96 Beta 7 r1. What you're doing is a step backwards.

As for the few tools which are being bundled with TIGCC to support pucrunch compression, those are in principle no longer necessary because ld-tigcc now supports pucrunch natively (in the standalone version, not in the link.dll yet):[ul][li]on *nix, we currently bundle ttpack and ttbin2oth. Those will no longer be needed with KTIGCC 2. It would even be possible to backport the changes for using ld-tigcc's native pucrunch compression to KTIGCC 1.[/li][li]on W32, we currently bundle only ttpack. The functionality of ttbin2oth is implemented in the Delphi code. We would need some adjustments to the link.dll interface to be able to use the pucrunch from ld-tigcc, or we could drop link.dll altogether. In TIGCC, the plan is to get rid of link.dll by moving to KTIGCC 3.[/li][/ul]So I don't see the benefit in bundling the tools suite with the toolchain.

Thanks for posting your opinion.

Do you really think this makes sense?

Yes, otherwise I wouldn't have done it
Some of the reasons why it makes sense to Thomas and me have been detailed in ticket #42, https://trac.godzil.net/gcc4ti/ticket/42 . Another one is below.

Much of the tools suite can be used with no toolchain at all, so I think having it as a standalone package is much more useful.

That the tools are part of the GCC4TI repository doesn't prevent anyone from making them a standalone package
Not that either Thomas or I really see the point, though. These tools are small, and still used by multiple active developers (to name three of them: Ranman, Lachprog, Folco) as part of build scripts.
What's the point of requiring users to go fish themselves for yet another set of tools ? We're looking at easing the user experience, see also ticket #30 ( https://trac.godzil.net/gcc4ti/ticket/30 ).

In addition, it would make it easier to use the same tools with TIGCC and with GCC4TI and prevent a completely useless duplication of efforts.

Well, these tools are very low maintenance. In years, the only modifications have been:
* 64-bit compatibility;
* the recent improvement to ttbin2str which enables readding it in the suite;
* addition of ttsetname;
* deletion of ttdasm. BTW, dasm-tigcc isn't in TIGCC, why is that ? I know where to download it, but is it another thing you forgot to include, like the CHM -> Qt converters ?

A duplication of efforts on that item would mean that there's no cooperation between TIGCC and GCC4TI on that item, and that would not be good. As I already wrote multiple times, having different goals & timelines, and disagreeing on various technical matters, doesn't mean that TIGCC and GCC4TI can't cooperate (in fact, they do, !).
OK, there has been a duplication of effort on stdint.h. That one was really unintentional, and the blame lies on both side: we didn't open the GCC4TI infrastructure soon enough - we did less than two weeks later, along with the first public release - and you didn't install a feature request tracker that would have enabled us to post the feature request itself and that we worked on it. And I started attending #tigcc in order to try avoiding reoccurrence of this.

Also note that TIGCC/*nix used to bundle the tools suite and I dropped that in 0.96 Beta 7 r1.

I was not aware of that.

What you're doing is a step backwards.

I disagree, see above
(To me, the step backwards was dropping the tools in 0.96 Beta 7 r1 )


We may rename "GCC4TI Tools" to "GCC4TI/TIGCC Tools" or "TIGCC/GCC4TI Tools", if that's a problem for you. But having them within TIGCC / GCC4TI makes sense for reducing present (pucrunch-related code in ld-tigcc code, I didn't even think of it) and preventing future (e.g. variable name checking code) duplication.
I'd tend to see the reduction of the ttppggen / ld-tigcc code duplication the other way round, i.e. modifying ld-tigcc to use chunks of ttpack/ttppggen code in a way or another (either as an external executable, or as embedded code, since most tt* are meant to be embedded in other C files).
What about backwards compatibility if we remove ttppggen ?

Lionel Debroux (./2) :
Not that either Thomas or I really see the point, though. These tools are small, and still used by multiple active developers (to name three of them: Ranman, Lachprog, Folco) as part of build scripts.What's the point of requiring users to go fish themselves for yet another set of tools ?

I don't see how yum install tigcc-tools-suite is a problem. Even on W32 you just have to download and unzip a zipfile, the TIGCC Tools Suite doesn't even have an installer. And having them be separate packages allows using one without the other. Not all uses of the tools are in conjunction with TIGCC, and not all TIGCC users need the tools either.

BTW, dasm-tigcc isn't in TIGCC, why is that ? I know where to download it, but is it another thing you forgot to include, like the CHM -> Qt converters ?

No, it's intentionally separate. TIGCC doesn't use or require dasm-tigcc, dasm-tigcc doesn't use or require TIGCC. To me that's the definition of separate packages.

We may rename "GCC4TI Tools" to "GCC4TI/TIGCC Tools" or "TIGCC/GCC4TI Tools", if that's a problem for you.

What about a neutral name like "TICT Programming Tools Suite"? Having "TIGCC" in the name occasionally confused some users (they didn't understand that TIGCC Tools Suite != TIGCC - the same goes for "GCC4TI"), and also as I said, those tools can be used without TIGCC. (The eBook tools you removed are perfect examples, but there are more tools which can be used without TIGCC. For example, ttbin2str may be useful even for TI-BASIC programmers.)

But having them within TIGCC / GCC4TI makes sense for reducing present (pucrunch-related code in ld-tigcc code, I didn't even think of it) and preventing future (e.g. variable name checking code) duplication.I'd tend to see the reduction of the ttppggen / ld-tigcc code duplication the other way round, i.e. modifying ld-tigcc to use chunks of ttpack/ttppggen code in a way or another (either as an external executable, or as embedded code, since most tt* are meant to be embedded in other C files).

The problem is that this makes standalone releases out of the version in your repository, as you suggest:

That the tools are part of the GCC4TI repository
doesn't prevent anyone from making them a standalone package

very hard. Depending on how you organize this, I might end up having to fork the tools suite to be able to ship a standalone package. If you want me to use it as you ship it, you need to make sure it can be built without a full GCC4TI source tree. But sharing code across components makes that hard.

And losing the eBook tools is a regression, will you do a standalone package with those?

What about backwards compatibility if we remove ttppggen ?

ttppggen should definitely stay, it's also useful to compress somebody else's program without needing to recompile it. But it belongs into the separate "TICT Programming Tools Suite" package, not TIGCC nor GCC4TI. TIGCC/W32 never included ttppggen. TIGCC/*nix did, but didn't use it internally, it was just including the entire tools suite. It no longer does.

Not all uses of the tools are in conjunction with TIGCC

You have a point there. But all this means is that the standalone version of the GCC4TI/TIGCC Tools (or whatever their name) will have to include more things than we (Thomas and I) had thought, no biggie.

and not all TIGCC users need the tools either.

That can be addressed through ticket #30, but Thomas and I are [EDIT: NOT] too convinced it's worth the trouble.

BTW, dasm-tigcc isn't in TIGCC, why is that ? I know where to download it, but is it another thing you forgot to include, like the CHM -> Qt converters ?

No, it's intentionally separate. TIGCC doesn't use or require dasm-tigcc, dasm-tigcc doesn't use or require TIGCC. To me that's the definition of separate packages.

Being separate packages for the end user is one thing, but like the tools which are the topic of this ticket, what prevents dasm-tigcc (whose help makes it pretty clear that it's for TI calculators and which imports chunks of ld-tigcc) from being part of the TIGCC CVS repository or the GCC4TI SVN repository ?
dasm-tigcc also duplicates a subset of the tilibs/TIEmu headers and code, and that is not good. Maybe you manage duplication through symlinks on your HDD (thereby triggering an update of the dasm-tigcc sources when upstream tilibs/TIEmu are modified... if CVS is smart enough), but that's not directly reproducable by others. svn:externals ( http://svnbook.red-bean.com/1.5/en/svn.advanced.externals.html ) may come to the rescue here, that said.

they didn't understand that TIGCC Tools Suite != TIGCC

Well, maybe that was because pieces of the former should have been available by default in the latter for a long time ?
(All of Thomas, the TIGCC Team and me share blame for pieces of the TIGCC Tools Suite never having been integrated in TIGCC. It's a fact it never got done, and one of the reasons of this state of things is that each of us focused on various other things.)

Depending on how you organize this, I might end up having to fork the tools suite to be able to ship a standalone package. If you want me to use it as you ship it, you need to make sure it can be built without a full GCC4TI source tree.

SVN handles symlinks within a repository. Therefore, I'd feel logical that the following setup:
* components/varnamechecking.{c,h} for the variable checking code (note that the path and name of the variable name checking code isn't set in stone for now)
* tools/varnamechecking.{c,h} -> symlink to ../components/varnamechecking.{c,h}
yields a copy of varnamechecking.{c,h} in tools when checkouting the single "tools" folder.
I've already used symlinks with SVN, but never in this situation, so I can't tell whether that actually works.

What about a neutral name like "TICT Programming Tools Suite"?

Well... IMO, it would be more important (more descriptive for users) to mention that they are for TI-68k calculators (which they are) than to mention that TICT (instead of whoever else) did the tools, wouldn't it ?
What about something like "TI-68k Additional Tools [Suite]" ?

And losing the eBook tools is a regression, will you do a standalone package with those?

Of course.
Anyway, some chunks of the Tools Suite were to permanently remain outside of TIGCC/GCC4TI, e.g. because they're experimental (a ttpack which requires less memory, etc.) or broken and outdated (tthdex on TIGCC 0.95+ / AMS 3.xx / HW3).
As written in ticket #42, if we find a valid use case for ebooks within TIGCC, we'll add the corresponding "PC" executables, ebook reader and Alice in Wonderland example as well.



BTW, I didn't write about the calctools in ticket #42, but:
* ttstart and pstarter have a LOT of code in common. That requires some changes, but it would be great if ttstart and pstarter used the same "lzma", "ttuf" and "ttup" headers (and maybe "shrn", though this one is currently commented out in ttstart). However, ttstart and pstarter themselves had better remain different source files, since mixing them up would make maintenance harder;
* ttmem is useful for testing under low-memory conditions (I remember someone fixing bugs in his memory handling code after using ttmem);
(* ttrow is a graphical version of the _rowread documentation, less useful)

[EDIT: fixed a sentence where I wrote the opposite of what I meant]

Lionel Debroux (./4) :
Being separate packages for the end user is one thing, but like the tools which are the topic of this ticket, what prevents dasm-tigcc (whose help makes it pretty clear that it's for TI calculators and which imports chunks of ld-tigcc) from being part of the TIGCC CVS repository or the GCC4TI SVN repository ?
dasm-tigcc also duplicates a subset of the tilibs/TIEmu headers and code, and that is not good. Maybe you manage duplication through symlinks on your HDD (thereby triggering an update of the dasm-tigcc sources when upstream tilibs/TIEmu are modified... if CVS is smart enough), but that's not directly reproducable by others. svn:externals ( http://svnbook.red-bean.com/1.5/en/svn.advanced.externals.html ) may come to the rescue here, that said.

The code isn't symlinked, it's forked. The code portions from libtifiles2 are modified and the unneeded parts ripped out, likewise the integer type definitions from ld-tigcc.

I could support building against a system libtifiles2, but for the few functions I'm using from it, I don't see how it's worth it. It'd also drag in libticonv and glib2 which aren't used by dasm-tigcc at all. For the other copied/forked stuff, there's no system library I could link against, it's all portions of application source code. (Well, I guess strictly speaking I could build a shared copy of libopcodes, but there's no such shared version of it, and I use differently-patched copies of libopcodes for assembling (GNU as) and disassembling (TiEmu, dasm-tigcc): the instruction tables for disassembling contain the dots to make the disassembler output nicer - it's not easy to automatically add them because e.g. no.p or rt.s doesn't make sense -, but those dots break the assembler.)

Well... IMO, it would be more important (more descriptive for users) to mention that they are for TI-68k calculators (which they are) than to mention that TICT (instead of whoever else) did the tools, wouldn't it ?What about something like "TI-68k Additional Tools [Suite]" ?

It's OK, but isn't the word "Additional" redundant? You can add "Developer" or something like that if you think "TI-68k Tools Suite" is too generic. Or "TICT TI-68k Tools Suite" maybe?

BTW, I didn't write about the calctools in ticket #42, but:* ttstart and pstarter have a LOT of code in common. That requires some changes, but it would be great if ttstart and pstarter used the same "lzma", "ttuf" and "ttup" headers (and maybe "shrn", though this one is currently commented out in ttstart). However, ttstart and pstarter themselves had better remain different source files, since mixing them up would make maintenance harder;

I wouldn't lose too much time on "shrn" if I were you, it's inferior to ttunpack-small in all metrics. I originally investigated it for licensing reasons, but the ttunpack-small license is now actually more liberal (LGPL with exceptions vs. LGPL without exceptions - a pstarter built against shrnklib cannot be legally distributed in binary-only form, you have to provide a way to relink which, given how the code is included, is the whole pstarter source code). And the shrnklib algorithm is slower and both the decompression code and the compressed executables (in most cases) are larger. So I don't see much benefit in supporting it. Maybe the best thing to do is to just cvs rm it. I don't know anybody who ever used it, other than me, for testing only (and I quickly discarded it as crap).

By the way, the LZMA code should probably get updated to the latest LZMA SDK, which is now public domain. That should clear up any questions on whether we can allow unmodified launchers with LZMA support to be distributed without source code. (The LZMA SDK originally had an exception similar to ours and our copy is modified to save as much size as possible, so we would have needed permission from the author to extend the exception to our version.)

* ttmem is useful for testing under low-memory conditions (I remember someone fixing bugs in his memory handling code after using ttmem);

All the tools are useful. That doesn't mean it makes sense to ship them with the toolchain.

The code isn't symlinked, it's forked. The code portions from libtifiles2 are modified and the unneeded parts ripped out, likewise the integer type definitions from ld-tigcc.

OK.
libopcodes is a different beast indeed, but are the external bits of ld-tigcc and TIEmu extracted through automated means ? (for subsets of a given file, a sed script that keeps lines between by two markers would certainly do the job just fine)
The more the maintenance and building process is automated, the easier it is to make releases.

Well... IMO, it would be more important (more descriptive for users) to mention that they are for TI-68k calculators (which they are) than to mention that TICT (instead of whoever else) did the tools, wouldn't it ? What about something like "TI-68k Additional Tools [Suite]" ?

It's OK, but isn't the word "Additional" redundant? You can add "Developer" or something like that if you think "TI-68k Tools Suite" is too generic. Or "TICT TI-68k Tools Suite" maybe?

Yes, "developer" is better than "additional"
What about "TI-68k Developer Utilities" ? That would emphasize that these are "companion tools" to the main development tools that the rest of the TIGCC/GCC4TI toolchain is.

I wouldn't lose too much time on "shrn" if I were you [...]

ACK. Anyway, I didn't plan on spending time on "shrn" (other than fallout of modifications in pstarter, if any) before having unified the three other decompression files (if possible).
For testing purposes, where can I get shrnklib-compressed executables ?
[EDIT: oh, wait, I remember that the shrnklib compressor and decompressor code is in PreOS.]

By the way, the LZMA code should probably get updated to the latest LZMA SDK, which is now public domain.

Indeed, though I don't think it's that urgent.

Lionel Debroux (./6) :
libopcodes is a different beast indeed, but are the external bits of ld-tigcc and TIEmu extracted through automated means ? (for subsets of a given file, a sed script that keeps lines between by two markers would certainly do the job just fine)

No, it's completely forked. Where I merge changes (which so far I only did for the __attribute__((may_alias))-related stuff in the integer definitions, which by the way needs fixing again for GCC 4.3 - I don't remember merging any other change one way or the other, in fact I haven't touched dasm-tigcc for a while), I do it by hand.

The more the maintenance and building process is automated, the easier it is to make releases.

Well, that assumes I want to merge the changes in the first place. And that there are any changes to merge.

What about "TI-68k Developer Utilities" ? That would emphasize that these are "companion tools" to the main development tools that the rest of the TIGCC/GCC4TI toolchain is.

That sounds good.

For testing purposes, where can I get shrnklib-compressed executables ?

You need to call ttstrip, shrink92 and ttbin2oth.

The more the maintenance and building process is automated, the easier it is to make releases.

Well, that assumes I want to merge the changes in the first place. And that there are any changes to merge.

My remark applies to software projects at large

I already sent you a patch to dasm-tigcc on 20080525, but you don't want it

What about "TI-68k Developer Utilities" ? That would emphasize that these are "companion tools" to the main development tools that the rest of the TIGCC/GCC4TI toolchain is.

That sounds good.

ACK.
ttdasm used to be part of these utilities. Do you have a valid gripe against GCC4TI importing some form of dasm-tigcc (which is FLOSS, and just better than ttdasm both from a functionality and legal POV) in its repository, in order to replace ttdasm ?

!call Kevin Kofler
--- Call : Kevin Kofler appelé(e) sur ce topic ...

* "GCC4TI Tools" renamed to "TI-68k Developer Utilities" (r1310).

* I started merging pstarter and ttstart (r1311).
I haven't committed this change yet, because I have neither finished the rest of the changes to the ttstart code & dependencies nor tested them (which will be a PITA, given how many executables there are...), but I've got rid of TPRs for both pstarter and ttstart.
You showed me several weeks ago how useless the pstarter tpr is (a one-liner that calls TIGCC does the job just fine), and I don't see the point in modifying/creating eleven TPRs (and that's if I don't add support for shrink92 to ttstart - otherwise, "eleven TPRs" becomes twenty-three TPRs...) when an 11- (or 23-)liner does the job just fine.

* I know you're VERY busy with Fedora / KDE stuff (I saw your name appearing twice on LWN.net, once in a discussion about the D-Bus screwup in definitely-too-bleeding-edge-and-too-low-on-quality-standards Fedora and once referring to your reply to Aaron Seigo's post about KDE 4.2 on his blog), but you haven't replied to ./8

Lionel Debroux (./8) :
ttdasm used to be part of these utilities. Do you have a valid gripe against GCC4TI importing some form of dasm-tigcc (which is FLOSS, and just better than ttdasm both from a functionality and legal POV) in its repository, in order to replace ttdasm ?

What will it change? It's yet another of my projects you're forking... It'll just be something I'll have to rm in my packaging of your tools suite.

Lionel Debroux (./9) :
* I started merging pstarter and ttstart (r1311).

I don't like this. As I said in the original topic about the pstarter, I don't want ifdef-littered code. But once again I'll be maintaining the official pstarter anyway, you do what you want to your fork, there's nothing I can do to stop you (you already have permission to apply the exception for unmodified versions to the versions you modify).

I haven't committed this change yet, because I have neither finished the rest of the changes to the ttstart code & dependencies nor tested them (which will be a PITA, given how many executables there are...), but I've got rid of TPRs for both pstarter and ttstart.
You showed me several weeks ago how useless the pstarter tpr is (a one-liner that calls TIGCC does the job just fine), and I don't see the point in modifying/creating eleven TPRs (and that's if I don't add support for shrink92 to ttstart - otherwise, "eleven TPRs" becomes twenty-three TPRs...) when an 11- (or 23-)liner does the job just fine.

I don't see the point of supporting all those compression methods, there should be one default (ttunpack-small or LZMA), people who want another one should just change the parameter in the TPR and rebuild.

As I wrote in ./4, I'm not merging pstarter.s and ttstart.s, only (if possible, I don't know yet for sure) the tts-* and pst-* headers. Again, reducing code duplication and easing maintenance.

It's yet another of my (emphasis mine) projects you're forking...

No. Rather, we're de-forking your (improved, it's a fact !) fork of one of the projects we're maintaining: besides having the same switches as ttdasm, dasm-tigcc uses some code from ttdasm. Fact, acknowledged in the copyrights.
What you're calling a fork of dasm-tigcc (if any: the command-line compatibility between dasm-tigcc and ttdasm would make it possible to make the new ttdasm just start dasm-tigcc...) is actually reintegration to upstream by the upstream maintainers
I don't remember dasm-tigcc being contributed to the former TIGCC Tools Suite, and I can't find a mail whose body contains "dasm" in my whole inbox (which contains mails since the end of 2005, i.e. before dasm-tigcc existed).
Yes, "we" and a plural for "maintainer": by me importing the "GCC4TI Tools" -> "TI-68k Developer Utilities" into GCC4TI, the list of upstream maintainers has expanded. And unlike your fork, the upstream ttdasm will be maintained in a public SCM repository, not in a closed fashion somewhere on your own computer...

Now, it's a fact that we're going to fork dasm-tigcc. Blame yourself for this, not us: we wouldn't have to fork dasm-tigcc if you developed it in cooperation with both your users and other developers
As you remember, the dasm-tigcc patch I sent you on 20080525 (before we decided to create GCC4TI) that I mentioned in ./8, was a PoC patch for an alternative, default-disabled, '%'-less syntax. Being trivial, the patch makes it clear how easy it is to program a multi-year-old (and multi-person) tiemu-gdb feature request.
And what happened ? You dismissed the patch outright in a one-liner e-mail that read (in French) that it had zero usefulness...

I don't see the point of supporting all those compression methods, there should be one default (ttunpack-small or LZMA),

There IS one default. ttstart has supported ASM + ttunpack since before ttunpack-small existed. I chose to keep ttunpack (-fast in your terminology), because the newest version of it is smaller and faster than the older, pre- Greg Dietsche / myself / Samuel Stearley versions, and because sizeof(ttstart_asm_ppg) < 2 * sizeof(pstarter).

people who want another one

ttstart maintainers belong to that group of people...

should just change the parameter in the TPR and rebuild.

That's pretty inefficient (and therefore stupid) of a suggestion: the automated, GUI-less build of all four possible versions of pstarter + all eleven versions of ttstart, through the `tigcc` tool (instead of `sed`/`perl` + `tprbuilder` to modify the TPR) takes less than two seconds on my computer.

ttstart 2.x has the capability of handling multiple compression formats in a single executable. That must be tested, right ?
(I guess that the testing work can be narrowed a bit down from 11, or 23, executables, but that's still some testing work).


Every few days, `cvs up -d` on the TIGCC repository and `find . -iname "*chm*"` tell me that you still haven't added the chm2dcf ("slooooow") et dcf2adp tools at the .../doc/converter where they belong, three weeks after I privately reported you the problem (20090109). It's not that you haven't had time for this until now, but you decided to spend it writing FUD against GCC4TI and its developers (20090113 onwards)...

The sources are in the source tarball, that's enough.
Yes, they should be present in the CVS, it's not intentional that they're missing, but I don't see this as a high-priority issue at all.

It's not a high-priority issue, but it's one which is pretty easy to fix.

As for the rest of your message:

Lionel Debroux (./11) :
As I wrote in ./4, I'm not merging pstarter.s and ttstart.s, only (if possible, I don't know yet for sure) the tts-* and pst-* headers. Again, reducing code duplication and easing maintenance.

Well, that may well be possible, we'll see.

It's yet another of my (emphasis mine) projects you're forking...

No. Rather, we're de-forking your (improved, it's a fact !) fork of one of the projects we're maintaining: besides having the same switches as ttdasm, dasm-tigcc uses some code from ttdasm. Fact, acknowledged in the copyrights.
What you're calling a fork of dasm-tigcc (if any: the command-line compatibility between dasm-tigcc and ttdasm would make it possible to make the new ttdasm just start dasm-tigcc...) is actually reintegration to upstream by the upstream maintainers
I don't remember dasm-tigcc being contributed to the former TIGCC Tools Suite, and I can't find a mail whose body contains "dasm" in my whole inbox (which contains mails since the end of 2005, i.e. before dasm-tigcc existed).Yes, "we" and a plural for "maintainer": by me importing the "GCC4TI Tools" -> "TI-68k Developer Utilities" into GCC4TI, the list of upstream maintainers has expanded. And unlike your fork, the upstream ttdasm will be maintained in a public SCM repository, not in a closed fashion somewhere on your own computer...

You're re-forking my fork.
That said, at the time you had no issues with me forking dasm-tigcc and even refused to integrate it into the TIGCC Tools Suite on the grounds that it pulls in too much stuff. Funny how your opinion changes.
At this point I'm no longer interested in getting it merged, if you want to do it now, you're on your own. And we'll probably end up with 2 separate versions given that you want to do changes I don't agree with.

Now, it's a fact that we're going to fork dasm-tigcc. Blame yourself for this, not us: we wouldn't have to fork dasm-tigcc if you developed it in cooperation with both your users and other developers
As you remember, the dasm-tigcc patch I sent you on 20080525 (before we decided to create GCC4TI) that I mentioned in ./8, was a PoC patch for an alternative, default-disabled, '%'-less syntax. Being trivial, the patch makes it clear how easy it is to program a multi-year-old (and multi-person) tiemu-gdb feature request.And what happened ? You dismissed the patch outright in a one-liner e-mail that read (in French) that it had zero usefulness...

Which is still true. The idea is to generate code which can be assembled with GNU as, Thomas intentionally changed it for that. So why generate code which doesn't assemble with GNU as's default settings?

In addition, your patch is simplistic, you're only dropping the '%' signs. What people asked for in the tiemu-gdb feature request was to support the obsolete A68k syntax (or the obsolete VTI syntax, which is very similar) entirely. This means $ instead of 0x, * instead of . for the current %pc and so on.

IMHO, TIGCC's tools should all use the same syntax (and I still think tiemu-nogdb should be fixed to use the same syntax), it doesn't make sense to start supporting multiple syntaxes.

I don't see the point of supporting all those compression methods, there should be one default (ttunpack-small or LZMA),

There IS one default. ttstart has supported ASM + ttunpack since before ttunpack-small existed.

That's history.

I chose to keep ttunpack (-fast in your terminology), because the newest version of it is smaller and faster than the older, pre- Greg Dietsche / myself / Samuel Stearley versions, and because sizeof(ttstart_asm_ppg) < 2 * sizeof(pstarter).

people who want another one

ttstart maintainers belong to that group of people...

Then you should make that the default, not build dozens of versions of ttstart which only confuse people.

should just change the parameter in the TPR and rebuild.

That's pretty inefficient (and therefore stupid) of a suggestion: the automated, GUI-less build of all four possible versions of pstarter + all eleven versions of ttstart, through the `tigcc` tool (instead of `sed`/`perl` + `tprbuilder` to modify the TPR) takes less than two seconds on my computer.

But it leaves users confused about which version to use. Regular users should get one default version, advanced users can recompile.

ttstart 2.x has the capability of handling multiple compression formats in a single executable. That must be tested, right ?(I guess that the testing work can be narrowed a bit down from 11, or 23, executables, but that's still some testing work).

Then you build a version which supports them all. So you have 2 TPRs, ttstart and ttstart-all. How's that not enough?

Lionel Debroux (./13) :
It's not a high-priority issue, but it's one which is pretty easy to fix.

It's not that easy. I have to:
1. decide on where to put it in CVS and
2. update my scripts which sync the sources from CVS to my directory tree which I create the tarballs from, and which also contains generated files (e.g. tigcc.a, the HTML documentation etc.) and other stuff which is not in CVS (e.g. A68k).

That said, at the time you had no issues with me forking dasm-tigcc

Yes, and you misunderstood my message...
IIRC, at the time, Thomas had already agreed to the principle of relicensing the code (his own, of course, not the rest of the strange mix) under a GPL-compatible license, which allows forking. I didn't have any, and I still don't have any issue with you forking dasm-tigcc, because I can't have any.
So that's not what I was trying to point out, it was obvious to me. What I was trying to point out is that dasm-tigcc is a(n improved) fork of ttdasm, and that to me, integration into GCC4TI would be integration back into upstream (which you disagree with, it's your right).

and even refused to integrate it into the TIGCC Tools Suite on the grounds that it pulls in too much stuff.

I don't remember writing that it pulls "too much" stuff, much less where, but if you say I did, I must have done it... However:

Funny how your opinion changes.

... my mind hasn't changed that much on pulling stuff: as shown in this topic, I'm still worried by external code being pulled (and for some bits, forked, as you wrote), because of the possibility to forget backporting fixes from upstream.
I've already changed my mind on a number of topics and persons since I've been in the TI-68k community, but this one is not one of them.

Then you should make that the default, not build dozens of versions of ttstart which only confuse people.
But it leaves users confused about which version to use. Regular users should get one default version, advanced users can recompile.

Did I write that we were going to provide all 12 or 24 (forgot one earlier today) versions of ttstart to final users ?
No, I didn't. Did you seriously think that we were going to do such a blunder (it's obvious that providing that many executables would confuse users) ??

Then you build a version which supports them all. So you have 2 TPRs, ttstart and ttstart-all. How's that not enough?

Well, prove us that reducing from 12 or 24 to 2 tests will not lower the quality of testing (which is not even a metric of correctness, as you know)
As I wrote above (./11, "(I guess that the testing work can be narrowed a bit down from 11, or 23, executables, but that's still some testing work). "), I didn't seriously think about testing all combinations. For example, since the ASM support is mostly independent from the test, only two executables (one or even two of which can be used in other tests as well) need to be tested for checking ASM support:
* ASM support disabled: check that it cannot launch an ASM program;
* ASM support enabled: check that it can find and launch an ASM program;

Does TIEmu have an easy way to get the data output through the link port (like, say, VTI Logger) ? That could enable automated tests of launchers (and other programs), through the use of ROM_CALL_479 "link_printf"...

1. decide on where to put it in CVS

TIGCC module, doc/Programs ?

For ttstart, I'd concentrate on testing the versions you actually ship, for the others, whoever builds them should test them and report issues to you.

For the doc tools, they're currently specific to TIGCC/*nix (and by the time we have KTIGCC on W32, we may well have a better/faster solution), so I'd rather put them somewhere into tigcc-linux.

For ttstart, I'd concentrate on testing the versions you actually ship, for the others, whoever builds them should test them and report issues to you.

I'm afraid we can't do that, unless we give up on coherency.
Remember how hard I complained about you making below-minimum testing for GCC 4.0, which broke one TICT program (crash) and pessimized three others, i.e. had a negative impact on all 4 out of 4 TICT software I tested GCC 4.0 with at first ?

For the doc tools, they're currently specific to TIGCC/*nix (and by the time we have KTIGCC on W32, we may well have a better/faster solution), so I'd rather put them somewhere into tigcc-linux.

You could also start merging the tigcc and tigcc-linux folders, by not adding more stuff to the latter. tigcc-linux has few subfolders, and will have even less when `tigcc` and `patcher` are de-duplicated (with or without integration of `patcher` into GCC)...

Lionel Debroux (./18) :
I'm afraid we can't do that, unless we give up on coherency.Remember how hard I complained about you making below-minimum testing for GCC 4.0, which broke one TICT program (crash) and pessimized three others, i.e. had a negative impact on all 4 out of 4 TICT software I tested GCC 4.0 with at first ?

Well, it would just mean you finally realized that the developers can't test everything, we need to rely on users for most of the testing.

Oh, and a bug doesn't matter if nobody encounters it. So if you can fix reported bugs quickly, then it doesn't matter that they were there in the first place. If on the other hand you sit on a bug for years like on the TICT Explorer crash without HW3Patch (despite the fix being trivial and having been sent to you in a timely manner), then it does matter.

Well, it would just mean you finally realized that the developers can't test everything,

I've realized that for years, and I did even write it in this topic: "[...] testing (which is not even a metric of correctness, as you know)" ( ./16 ):
* exhaustive testing is impossible for practical matters, except in VERY trivial programs.
* testing is only a way to prove that a number of expected good things work as they should, and a number of known bad things are rejected in a way or another.

we need to rely on users for most of the testing.

It's a fact - but it does not mean that we have to follow the TIGCC ""lead"" on below-bare-minimum testing
You admitted you tested it on a handful of programs (Backgammon and a couple others, IIRC). That sample is so small (and therefore outside of a quality-minded approach) that you didn't even notice the size regressions that were later reported by multiple persons besides me...
If you had an automated test suite of a couple dozen programs of different types, you'd much more easily get an idea of the strengths and weaknesses of a new GCC version. Making such an automated test suite is no problem, because "disk space is cheap", right ?
(and in case a new GCC version requires changes on the program side, you can even ask the original developer - if still active - to do the work for you, after providing him a beta version of the new compiler)

If on the other hand you sit on a bug for years like on the TICT Explorer crash without HW3Patch (despite the fix being trivial and having been sent to you in a timely manner), then it does matter.

Oh, a rehash of http://tichessteamhq.yuku.com/topic/1360?page=3 ...
As I wrote there, this particular bug you're always talking about was fixed one of the days following your report (which contained an explanation of the bug and a fix)
(Unlike most other bugs in TICT-Explorer 1.40 Beta, this particular fault of the crash protection could have been caught by a small automated test suite that just launches TICT-Explorer, or a program launched by it, under all meaningful configurations: HW1 with whatever AMS, HW2 w/ AMS 2.xx w/o HW2/3Patch, HW2 w/ AMS 2.xx w/ HW2/3Patch, HW3 w/ AMS 3.xx w/o HW3Patch, HW3 AMS 3.xx w/ HW3Patch.)

I know, I never uploaded a bugfixed version of TICT-Explorer, and you know why:

Oh, and a bug doesn't matter if nobody encounters it

You're defeating your own argument here...
As I wrote there, TICT-Explorer 1.40 Beta is in that situation, for two reasons:
* it is distributed only through a single message board topic (AFAIK), and this topic is only mentioned on, not linked from the main page of the TICT website (i.e. it's harder for search engines to find it);
* most of all, since HW3Patch is compulsory for a number of programs on 89T, many 89T calculators already have it. So the users of such calculators who know about that obscure TICT-Explorer version wouldn't even notice the problem (as I didn't).

Since the 2005 beta tests, I don't remember anyone writing me about TICT-Explorer 1.40 Beta... Either nobody tried to report the problem, or nobody knows about this version... or nobody was stuck by the problem.

I used Backgammon and TI-Chess 4.00 as the testcases.
Making an automated test suite is not easy, one has to send the programs to TiEmu for testing and then see what they return. And it's hard to automatically verify that TI-Chess can still play chess.
I consider it much more important to test that the games still work rather than to check whether they're a few bytes larger or take a few nanoseconds longer.

I used Backgammon and TI-Chess 4.00 as the testcases.

Which is, by all measurements, a too small test suite.

I consider it much more important to test that the games still work

Which you did, but it didn't mean much, given the dismal size of the test suite.



Your reply makes me think that you understood the following paragraph

If you had an automated test suite of a couple dozen programs of different types, you'd much more easily get an idea of the strengths and weaknesses of a new GCC version. Making such an automated test suite is no problem, because "disk space is cheap", right ?

was referring to a TIEmu test suite.
It ain't
This paragraph, and the surrounding paragraphs between two quotes of yours, is referring to a compiler test suite (run the building process and see what the compiler yields size-wise)

And it's hard to automatically verify that TI-Chess can still play chess.

Definitely

A testsuite which doesn't verify that the program actually works is completely worthless. Who cares if we save 2 bytes but TI-Chess crashes as soon as you move a pawn (hypothetical example)?

I may use unclear wording, but you're repeatedly misunderstanding me (here, I already know that e.g. the GCC test suite contains both "compileability" and run-time tests)... so I'm giving up.