That only proves that it doesn't break on the current contents of the .hs? files, it could still choke on future valid files.

That remains to be seen. And the likelihood of this happening is reduced by the fact I'm careful not to introduce any file that does not have explicit header references. Just for completeness, once in a while, I'm running the script, and so far, I haven't had a single line changed by the script.
BTW, I had already posted, in http://trac.godzil.net/gcc4ti/ticket/3 and IIRC somewhere else, how I had checked the operation of the script...

I guess we could also make a version which only strips out the header where it is the current header?

The script does not contain any licensing or even any copyright information. Do What The Fuck You Want To with it.

I wrote as a quick hack to convert this to the Qt Assistant ADP format (which isn't even the latest one, I'll need to update the stuff to support the new QCH format). That converter is extremely slow.

A full run of the Update* programs (the longest one being by far UpdateInclude) and your converter takes about three minutes on my computer. And it's all single-threaded stuff executed sequentially. Not sure that qualifies for "extremely slow". Remember, that's less (on the same computer) than the multi-threaded compilation + test suite of the infrastructure I've intermittently been working on for two years in my previous job.

It also means it is impossible to regenerate the documentation with only built-from-source Free Software, you need prebuilt Delphi binaries.

We agree to disagree on the priority of the task of killing every non-free bit from a program tree.

In fact it [address/value hacks] 's the most useful part of your contributions

These hacks used to be useful... in 2002-2003, when they were made, i.e. 2-3 years after the last AMS 1.xx versions (most hacks are aimed at AMS 1.xx). We're now in 2009-2010, i.e. ten years (!!) after the last AMS 1.xx versions, so it's pretty obvious that they're less useful nowadays. Thus, only a subset of them gets re-tested and added.

most of the prototypes are already there in unknown.h

Again, get a clue. Previously known prototypes are a minority in the updates I committed to GCC4TI SVN.

and the documentation is just documentation, it can be consulted directly from contrib.zip (and some of the functions are also documented in TI's PDF).

They can consult that file, but in practice, they won't, because it's very-little-known. And known to be incomplete, at that.

So you didn't test them in the obvious way (which is how I'd have tested them): create a new project, add #include <tigcclib.h> and draw a sprite!

Testing required a new project indeed, since the examples on sprite routines are so scarce in the documentation.

You seem to have completely misunderstood the purpose of a pre-beta testing prerelease

Quit being stupid: I misunderstand the concept of testing prereleases so much that I've been making two of them for TILP II 1.14, the first one being compiled with MSVC and the second one being compiled with cross-MinGW.

But the facts are that nobody is working on this in your supposedly "active" project.

And nobody is working on it in your supposedly "actively maintained" project, which is, as a matter of fact, far less worked on than GCC4TI.

Its startup is slow, but that's not a practical problem at all.

Users do disagree about that, I've mentioned the complaints about old versions of ttunpack-super-duper-small despite it being much faster than the lzma decompressor