smashing.org

This week, allison++ merged in the pdd22io_part3 branch, which, among other things, lets the Parrot I/O API (and its opcode friends) call methods on handle objects. This means I could finally write some code to tie Parrot I/O to Apache I/O and fix registry scripts, Pipp, and yes, even mod_lolcode. :)

I decided to create a new ModParrotHandle PMC which would dispatch I/O method calls to the appropriate ModParrot;Apache;RequestRec methods. It was a learning experience, as I'd never written a PMC before, but it's done and it works very well.

However, I really didn't want to expose the complexity of the PMC to HLL module developers -- I just want them to be able to turn the I/O tying behavior on and off as needed. So I added some methods to the interpreter object to assign a request object to stdin or stdout. The same methods can be used to restore the original filehandles. Here's what it looks like in the Pipp module:

php_file = r.'filename'()
oldout = interp.'stdout'(r)
oldin = interp.'stdin'(r)
r.'content_type'("text/html")
run_php_file(php_file)
interp.'stdout'(oldout)
interp.'stdin'(oldin)

And here's the analogous code in ModPerl6::Registry:

# tie I/O to $r, saving the old filehandles
my $mpi = ModParrot::Interpreter.new();
my $stdin = $mpi.stdin($r);
my $stdout = $mpi.stdout($r);

# run our code
my $res = ModPerl6::Fudge::call_sub_with_namespace($mod, '_handler');

# restore I/O filehandles
$mpi.stdin($stdin);
$mpi.stdout($stdout);

I'm really happy with how this all turned out, and now I'm ready to start packaging and testing for the 0.5 release. Expect it this weekend!