For some time now, I’d been trying to get XS modules compiling on Windows correctly under ActiveState Perl, all to no avail. But now, thanks to the wonder of Strawberry Perl, I’ve actually been able to build and test the module all on my own. I am hugely grateful to the authors for putting together Strawberry Perl. It’s a huge boon for developing Perl on Windows (Not that I diss ActiveState; they’ve also done a good job, but they’ve gone in different directions).

Now, I’m going to sit down and attempt to rework all this as a module+script, along with some tests. That I managed to break things in the 0.09 release was very irritating, and the tests should have caught that.

Update: Please grab subatom 0.12 instead when it shows up if you want a working version. Doh.

• Restore the ability to send output to stdout.
• Make the command line mode work, as well as the config file.
• Don’t cover up stderr when executing “svn log”.
• Force subversion to give us back UTF-8, and cope with it.
• Add support for using—limit if your svn has it.

That item about UTF-8 has annoyed me, because it’s brought me into contact with a hated topic: locales.

Subversion internally works with UTF-8 everywhere. This is a sensible design. But in order to interface with the outside world, it needs to convert that into whatever character encoding you are using. How does it know what character encoding to use? It guesses from the locale.

The locale is meant to be a specification for how to sort characters, how to format the date and so on and so forth. In recent years, it’s also been taken over to specify the character encoding that’s in use. So, to specify that I want to see the world in UTF-8, I need to say:

  export LC_ALL=en_GB.UTF-8

Except that breaks ls(1). Yes, ls(1). For some insane reason, setting a locale changes the way that things work such sorting now happens in a case-independent manner. So that “README” files no longer appear at the top of a directory listing. I haven’t investigated any further to see what else is broken. I quickly switched back to the “C” locale, which effectively means no locale.

So now, I’m left wondering how to tell the system that I’d like UTF-8, but none of the other inconveniences that locales bring me.

There are only two new features in this release:

• Add in a option to specify link[@rel="self"], which means that the generated feeds can now pass the feedvalidator with flying colours. Many thanks to Hans F. Nordhaug for the patch.
• I’ve added in a config file. I broke down and did it because I’d ended up with scripts that just called subatom in a variety of ungainly ways. Using a config file makes things slightly more manageable.

However, as with all releases, there are already a couple of problems:

• Hans found that it doesn’t really cope with character encodings properly. This is particularly shameful for me. So I’ll take a peek at it tonight to ensure that we tell subversion to give us UTF-8 and process that accordingly.
• Another point brought up by Hans is that it should invoke svn log as svn log --limit. I’d been avoiding that because I’m still on an older version of svn at work, but there’s no reason to not run svn help log and check the output to see if --limit is available.

• In the latest versions of CPAN.pm you can specify that sudo be used “make install” so you don’t have to run “sudo cpan” up front, which is dead handy.
  • Of course, installing into your home directory is better.
• CPAN::Mini keeps a private mirror of CPAN up to date. It comes out at around 500Mb. After being stuck on a train with no wireless, the value of this became very clear!

• XML::Genx 0.21

• It’s not absolutely clear in the documentation that any valid Perl string will work correctly (be it UTF-8 encoded or not). I need to double check the tests for this and amend the docs.
• The API is still fairly horrible. It mirrors the C api almost exactly, but this feels very odd as a Perl programmer. I need to have a think about what would be better. Ideally, I’d like something more like ruby’s builder. In fact, I actually wrote something similar to that before (XML::SAX::Builder), but that uses SAX, which is too slow in Perl.

I really appreciate the feedback. Apart from Aristotle, it’s the only feedback I’ve had since I released it.

If I can figure these out, I should probably slap a 1.0 on it.

I also reckon I should do a talk on “Why we need another XML writer”. There are quite a few on CPAN already and I should say why I wrote another one…

• JavaScript::JSLint 0.04, which is just renaming from Lint to JSLint to more accurately reflect where it’s come from (pointed out by Matthias Miller).
• subatom 0.07 which switches from the baroque XML::Atom api to the much nicer XML::Atom::SimpleFeed (thanks, Aristotle).
• subatom 0.08 because I am a doofus and left a warn statement in.

I also fixed a problem where I was covering up errors when the lint couldn’t do anything more (e.g. nested comments). After my mailing Douglas Crockford about it, he kindly pointed out that this was mentioned in the comments. I’d entirely missed it. Ah well. Anyway, it now returns a “cannot proceed” message.

Update: after spotting something rather stupid, I’ve now uploaded JavaScript::Lint 0.03 instead.

So now I’ve wrapped up JSLint into a small command line tool (and Perl lib), JavaScript::Lint.

It’s fairly simple at the moment. I plan to add support for the options in jslint soon.