Kakapo release-2

I released a limited version of Kakapo today. Then, I released again.

I created the release-1 tag, and felt good for a bit. Then I noticed that some common documentation files were missing, so I added them and created release-2.

Release-2 only provides the _base library, with PMC type extensions. But it's something. Documentation is over at GoogleCode:  http://code.google.com/p/kakapo-parrot/

There's more than one way to do it...

In the process of paying the taxes, I've come across one of the important classes in Kakapo that needs "updating."

In this case, "updating" means "complete rewrite," since I've got the new class system working. So I thought I'd show a before/after version of the code.

Progress!

My taxes aren't paid yet.

That said, I've at least seen some forward progress under the new NQP. The change to not using :init on code at the top level means that I'm getting the chance to write more test cases for every ... single ... file in the kakapo library. And yeah, there's some "why the hell doesn't this work?" going on, as well.

I'm pleased to report that I have a working UnitTest system. It's modeled on xUnit, but the default also includes a TAP Listener so that test cases report as TAP tests.

More snow .. err, code!

We got some more snow here in the northeast. Which means I've had plenty of time to code. Sadly, though, while I've been very active on Parrot's trac submitting tickets, I haven't made much forward progress. This was my tree at about 4:30pm.

Codin' weather

 

Well, the snowpocalypse is upon us, and I've got 15 inches of snow outside my front door. There's nothing to do (and not really any way to do it) until the Super Bowl tomorrow. Obviously, this is codin' weather. Hopefully I can get a Kakapo release in the can, and start back on Close development.

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.)

No Close! Kakapo!

I've been silent for a while, and that's pretty bad.

The reason is that I've been busy not working on Close at all. Instead, I stopped to turn a bunch of the code I had already written into a general-purpose library, called Kakapo.

Kakapo is a runtime library for NQP, that helps developers (like me!) do useful stuff without having to drop into PIR every couple of lines. Since this is code that has been extracted from Slam, obviously Slam will be using it. I hope that other coders find it useful, too.