I updated ModPerl6::Registry to support recent changes in Rakudo's IO class, so registry scripts work once again. Unfortunately I had to resort to some inline PIR, but I'm sure I'll be able to convert that to pure Perl 6 soon enough. Next up: solving some reported compilation problems on Fedora...
I've completely refactored the mod_parrot configuration subsystem and made everything work with an installed Parrot and Rakudo as of Parrot r40850. This was way more work than I thought it would be, but it's done! Now you tell
apxs, and (optionally)
perl6 are, and it takes care of the rest. Building against an uninstalled Parrot source tree is now unsupported, though it may still work.
All tests pass and everything seems to work after installing except for ModPerl6::Registry. I think recent Rakudo and/or Parrot changes broke that, so I'll have to take a look. Regular mod_perl6 handlers work fine. That's all for now.
I've already had requests for slides from my "LOLCAT History of Perl 6 and Parrot" lightning talk. The slides don't really have any meaning without the narration, so I'm going to make a video slideshow and post it here and on the YAPC site. Stay tuned.
I just finished giving my talk at YAPC. It went okay, but not great. Everything worked, but as this was a new talk, it wasn't as polished as I would have liked. Next time will be smoother.
Slides are available here: http://www.smashing.org/jeff/talks
Ceiling cat demands a larger audience for "A LOLCAT's History of Perl 6". YAPC it is. :)
I took a look at Web.pm to see how things were going, and it looks very nice indeed. I'm pleased to see that, as far as I can tell, access to request- and response-specific data elements has been encapsulated. This means that with a few tweaks I can replace the CGI-esque environment variable lookups with their mod_perl6 equivalents if the user is running under mod_perl6. I'll have to ping masak and see how he wants to handle that...
I will unfortunately be missing the Parrot Virtual Machine Workshop happening on the weekend before YAPC in Pittsburgh. My YAPC talk, Using and Contributing to mod_perl6 is still on though. YOU WILL ATTEND. Because I'm missing the workshop, a mod_parrot/mod_perl6 BoF might be a good idea. Ping me if you're interested.
I'm convinced. mod_parrot will support Python's WSGI interface (or more likely, a variant of it) for its languages. This will let us execute handler code outside of the Apache process, with mod_parrot handling the details behind the scenes. Exactly when this will happen is up in the air, as there are plenty of things on the roadmap to worry about, but I'm convinced that it would be a win, especially for mod_perl6.
I'm proud to announce that after a year of hard work, mod_parrot 0.5 has been released. The most significant change is an architecture overhaul allowing each language to register its own Apache module. This frees mod_parrot from doing the heavy lifting that Apache already does, and allows languages to manage their own configurations and hooks as they see fit. It also standardizes the interface between mod_parrot, Apache and languages.
Other changes include tying Parrot I/O to request I/O (think CGI, PHP or mod_perl registry scripts), support for POST data, initial support for threaded MPMs, and a rewrite of mod_perl6 in Perl 6. The full change list is available in the CHANGES file.
Following this release, mod_perl6 will be removed from the mod_parrot source tree and placed into its own repository. This will let potentially separate teams work on the two projects independently. If you're interested in contributing to either project, let me know!
You can download mod_parrot from the mod_parrot website at http://www.smashing.org/mod_parrot. Detailed documentation is also available on the site, including an HLL module developer's guide, which will help you hack on mod_perl6 or even write your own HLL module.
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
# 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!