smashing.org

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.

Enjoy!

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!

Thinking about helping out with mod_perl6? Crazy enough to embed another Parrot language in Apache? Then you'll want to read the new mod_parrot HLL Module Developer's Guide at http://trac.parrot.org/parrot/wiki/ModParrotHLLDocs. It's a first draft, but it's pretty complete. Comments welcome!

I often use VMware to test new operating systems or to test software like Parrot and mod_parrot on multiple operating systems.

Ever since the announcement of VMWare ESXi, I've been pining for an ESX server of my own. I already run VMware desktop, and I've run VMware Server, but ESX is nice because it runs on the bare metal, no underlying host OS required, giving you better performance, flexibility and scalability. The problem is that driver support for ESX is very limited, making it quite finicky about what hardware you have.

So while I was deciding whether to build my own server (~$900 for what I wanted) or buy a used Dell server (~$1200 for a Poweredge 1900), I came across this deal at Microcenter: a Dell Inspiron 530 mini-tower desktop, E2220 Dual Core 2.4 GHz CPU (1 MB L2 cache), 320 GB hard drive and 3 GB RAM for just over $400. Not the greatest specs for a server, and I wished it were quad core, but this is for a home lab, and it would be half the cost of building it myself. I knew ESX worked with the SATA controller on the 530's motherboard (ICH9), but it didn't like the onboard NIC. So I picked one up last weekend along with a new hard drive so I could leave the bundled drive intact in case I needed to return it. When I got home I ordered an Intel Gigabit Pro NIC, which finally came today. I threw it in and everything worked!

I'm currently uploading ISOs so I can get the lab going, and I'll spend the next few days migrating services and files from my old server "groovy". She was a good server, but it's time I gave her barely adequate Celeron bones some rest.

UPDATE: The new virtual groovy builds parrot in 2:40, blowing away the 7:08 it took the old decrepit groovy. The respective numbers for building Rakudo: 46 seconds versus 2:27. This is really going to help my development workflow, and this is just a measly desktop. Sweet.