The release that wasn't
Submitted by jeff on December 12, 2008 - 11:41am.I was planning to release mod_parrot 0.5 this week. All of the milestones were completed. All the tests passed. And then the pdd22io branches were merged back into Parrot trunk, and ModPerl6::Registry and mod_pipp broke very loudly. DOH!
Here's the scoop.
Perl 6 registry scripts and PHP scripts running under mod_pipp relied on Parrot's (former) string IO layer to capture output from scripts and feed it to Apache. It was suboptimal and I knew this layer was going away, but it was the easiest solution to the problem at the time I wrote the modules. Now, with the PDD22 IO changes in place, Parrot has a very nice FileHandle PMC that I can subclass to do my bidding. Unfortunately, the subclassing doesn't work yet because Parrot's IO functions still poke at the internals of the PMC and Parrot's opcodes ignore the PMC's methods, rendering any subclass useless. DOUBLE DOH!
What I've done in the meantime is sick and twisted, yet very "Perl 6-ish". When a registry script is requested, I rebind Rakudo's say and print builtins to my own versions which send the output to Apache. I then run the script, resetting the bindings afterward. It all works quite nicely. Of course this only works for mod_perl6, but that's my primary concern right now.
The point of all of this is that while ModPerl6::Registry is usable again, I'm delaying the release of 0.5 until I have a more palatable solution in place. Hopefully it's a subclassed FileHandle, but Allison may also provide a stringified version of the FileHandle PMC as a stop-gap solution.