Monday, December 22, 2008

Parallel Development

Now that I'm using git, I have powerful new options available for working on projects, like spawning as many single-feature development branches as I feel like. Today I spun one off and started overhauling the Carrot status system.

The first problem was that there were a lot of statuses, and while referring to them by numeric id sounds cool (it works for Apache), it's a little less than ideal when you're reusing ids between modules. I wrote the damn thing, and I was constantly having to refer to a wiki page to tell me what statuses meant. This has been (partly) fixed by moving the lists of statuses into the modules themselves, in a __DATA__ segment which populates a hashref at constructor time.

The other part of the fix is that statuses are no longer set by passing the 'status' method a number and having that be that. This had all the problems from the above paragraph, plus a complete lack of validity checking. Now statuses are set by passing the short "name" value which acts as a key on the statuses hashref. This makes status changes much more clear (status('EBADPERMS') vs. status(103)), and now passing an undefined name to status causes an abend.

A side-effect of this is that the code is now self-documenting with respect to its statuses, and the list of statuses can't get out-of-sync without the code exploding.

Lastly, the notion of a status being set has been divorced from the notion of something having gone wrong. Several of the Carrot modules now have non-error statuses beyond '0' for "still running" and '1' for "all done" (and, as a side note, '1' is no longer consistent for that -- this needs cleanup and '99' should be the new standard for "ops complete"). Since error statuses start at code 100, the status method now sets an error flag when a code above 99 is set. Soon, all modules will be updated to halt and return undef on error instead of on status.

EDIT: ONE YEAR ANNIVERSARY OF CARROT BLOG AND THE RESTART OF SERIOUS DEVELOPMENT

(...so far yet to go...)

Sunday, December 14, 2008

DOM Update 1

'nukenode' is no more. This is good. If a call to 'add' fails, that's really a fatal error -- there is no reason to cruft up the module with code which sloppily backs out the partial changes. I'm still hoping to factor away the partial changes bit and get back to having adds be atomic with respect to the datastore.

Saturday, December 13, 2008

Movement

First off, I'm now using git for local revision control.

Secondly, I've spent some time recently thinking about what the DOM should do -- oppose thinking about what's wrong with it right now -- and how to most efficiently make those things happen. I believe the result will be much slimmer code which is much more capable.

The DOM as it exists now has 2 fundamental problems. First, as noted previously, it was written over two years in advance of the Grammarian, so it's filled with bad guesses about how things would eventually work out. Second, I wrote it while having a fit of needing to prove to myself that I could write something like this, so it's full of questionable and/or mildly baroque design choices.

It'll be better soon.