Paying taxes

A long time ago - 3 or 4 months, when I started this project - I tried to update my version of Parrot every few days. I'd get some code working, then the next day I'd svn update in the Parrot dir, rebuild, and carry on. But a couple of things happened, and I realized that that was a stupid idea. Once you give out commit privs, it's next to impossible to enforce any kind of discipline without chasing volunteers off your project, so Parrot is stuck with the occasional commit-without-testing.

So I decided that me updating without any kind of knowledge about stability was a stupid thing to do, and I started just updating after the monthly releases. This is a bad idea, too, because the release process seems to involve a "code freeze" for a little bit just before the release, and then everybody slams in whatever branch they've been holding off on merging for the last week. So I'm basing my stuff on the tagged release, rather than trunk, which is as it should be.

A few times, there have been failures even then, because the code didn't work, or a bug was introduced, or whatever. I've evolved a procedure for that, too -- I move the old Parrot workspace out of the way until I'm sure the new one is good, and I don't waste any time waiting for fixes. This means sometimes I go two months with no updates, but that's not such a bad thing.

At any rate, every month or so I "pay the upgrade tax." That is, I invest an hour or more in getting and building and rebuilding, and oh, yeah, I forgot I need to run dos2unix, and re-rebuilding Parrot. My buddy Jesse is now convinced that I've generated a meme, since other folks on #parrot keep telling me about paying the tax.

Today is tax day, and there's this new version of NQP, called NQP-rx. (That's the last sentence in this post that I'll be able to write without having to go back and remove profanity.)


And the thing is, it's "better" than NQP + PGE, because it promises to finally let me put NQP in-line in the grammar targets, rather than just inline PIR. But there's a price, and the price is a bunch of changes. Like a stricter POD parser.

IMO, pod6 leaves a fair amount to be desired. Damian delivered something that looks a whole lot like xPmOlD, and for documenting source code it's *way* more verbose than it should be. I wasn't too unhappy with the NQP pod parser, since it would accept code like:

method foo() {
=method
Blah blahblah
=end

    code_for_foo();
}

But now there's a new sheriff in town, and I'd have to say something like "=begin method" at the top. Which wouldn't suck too bad (it's only 14 characters or so, compared with the <ahem> 1 character required for docstrings in elisp, or the <cough> 3 characters required in python). But then I'd also have to say "=end method" at the end, because matching end-tags have been such a great f.....reaking idea in Ada and Xml, so I decided that "ctrl-q" - one "character" - was a much better solution. So I've converted my POD comments into block comments (# at beginning-of-line) which Notepad++ does with a keystroke. The suboptimal part is that I'm having to do that over and over again, whereever I have written any documentation. I'm doing this in Kakapo, which (I'm sorry, it's true) I'm still working on. And sometimes I wind up just deleting the documentation. Hell, *I* know what the stuff does, and isn't that enough?

Another change which irritates me (but probably only me) is the $-variable interpolation in NQP. Yesterday it wasn't there, today it is. And since I've been doing a lot of PIR-generation, I'm caught replacing " with ' in a thousand places.

I'm sure there will be some stuff that doesn't irritate me until run-time, too. But I'm going off to pay the upgrade tax now, and this month the taxes are high. Should I blame Obama for this, too?