I was very surprised to find out today that Debian has bug trackers for C-INTERCAL and CLC-INTERCAL, and that they are actually being used. (I had no knowledge of this previously; this follows on from a bigger surprise I had the day before when I discovered that Debian packages C-INTERCAL, and actually maintains it, although I already knew that CLC-INTERCAL was Debian-packaged.) In case you're wondering, they are <http://bugs.debian.org/cgi-bin/pkgreport.cgi? ordering=normal;archive=1;package=intercal;repeatmerged=1> and <http:// bugs.debian.org/cgi-bin/pkgreport.cgi? ordering=normal;archive=1;package=clc-intercal;repeatmerged=1> for C- INTERCAL and CLC-INTERCAL respectively. (They even seem to have some use; INTERCAL compilers double up as testbenches for other tools.)
This seems to be a useful resource for finding out more information about INTERCAL bugs. For instance, I found out independently about C- INTERCAL bug #273968 (the bug numbers are shared with all other Debian packages, luckily; INTERCAL may traditionally be buggy, but it isn't that buggy), and used an entirely different fix.
One possible problem is this, from the Debian Policy Manual: "If an upstream package has problematic version numbers they should be converted to a sane form for use in the Version field." Both CLC- INTERCAL and C-INTERCAL probably qualify as having insane version numbers under this metric; I see that version 1.26 of C-INTERCAL was actually numbered 1.26, though, and that seems likely to cause problems when I release version 0.27 (hopefully coming soon; there are a few code changes that need to be made, and I also need to finish up the greatly expanded documentation).
Still, it's nice to see that INTERCAL has caught on in this way, and that other people are investing the time and effort to look after it. I have some new names (Joey Hess and Mark W. Eichin for C-INTERCAL, Mark Brown for CLC-INTERCAL) to learn. -- ais523
> One possible problem is this, from the Debian Policy Manual: "If an > upstream package has problematic version numbers they should be > converted to a sane form for use in the Version field." Both CLC- > INTERCAL and C-INTERCAL probably qualify as having insane version > numbers under this metric; I see that version 1.26 of C-INTERCAL was > actually numbered 1.26, though, and that seems likely to cause > problems when I release version 0.27 (hopefully coming soon; there are > a few code changes that need to be made, and I also need to finish up > the greatly expanded documentation).
Well, I was discussing this very issue with Mark Brown recently - just because we happened to be in the same pub at the same time, as one does. We agreed that C-INTERCAL's version numbers are going to cause problems to the Debian versioning system. He, of course, has already found the way around this for CLC-INTERCAL.
I wanted to upload CLC-INTERCAL to CPAN, but I'm finding difficult to make the version numbers compatible. Well, I have some ideas but they aren't unusual enough, so I'll accept suggestions.
C
-- The address in the "From" header won't work. Email to "usenet" at "intercal" dot "dyn-o-saur" dot "com" may or may not reach me, depending on how far it manages to go through the spam filter, and other conditions which I won't disclose.
|
