brrt's blog

Results

Tomorrow is google's appointed 'firm pencils down' date. That seems like a good time to discuss the results of my work on mod_parrot so far.

mod_parrot is, as I have mentioned before, a two-layered system, with one half interfacing with apache (the module) and the other half with the interpreter and the compilers, the 'loader'. There is also a vital third component, the test system called pudding.

A new hope

This week I finally got arround to giving a new, fresh structure to the mod_parrot module code. I have complained, perhaps not loudly enough, about the various inadequacies of the old codebase, mostly with regards to extensibility. A cleanup was needed. As such, here is a walkthrough of the new structure, also serving as documentation.

Interpreters with butterfly wings

I for one am totally for whimsical blog titles, wouldn't you agree? In other news, after a lull of two weeks (codewise at least) I've finally started to work on mod_parrot again. The big (dis)?advantage from not working on code is that you start to think more of what you could do (and should have done), rather than what you have done.

As it turns out, I handle interpreters in a rather confused manner. My goal for the next two weeks is to fix that. First, let me describe what should be done to correctly run a script on an interpreter using mod_parrot:

As long as hope remains

So, this was rather an unproductive week, unfortunately. I'm completely busy with moving right now (and will be coming week). What did happen is that I poked a hole into parrot, and the community (nine) fixed it. The story: I started my 'loader' script by directly invoking a subroutine. That by-passed the starting of a green thread on the interpreter, which caused a crash when I tried to do something with that thread, such as sleeping. Nine fixed this issue by starting a green thread upon invocation using the api, which causes my tests to crash no more.

Pandora's Box

Or, the internal Parrot C API. It is open, now. At least, parts of it anyway, and hopefully somewhat limited in scope.

When I set out to write mod_parrot it was my goal to use the 'new' embedding API - the one with all the Parrot_api_* calls. This is a limited API designed for loading and running the parrot interpreter and some scripts. It isn't perfect or even elegant but it works. Moreover, People have Promised it to be Stable. However, because it was designed to be used outside of the parrot runloop, these functions are not re-entrant in a rather subtle manner.

What have we done for you lately

And by we, I mean myself, parrot, and mod_parrot. That is simple: cgi-style running LIVES AGAIN (almost, just need to fix headers ;-)). And with it, all the infrasturcture to implement more and nicer loaders, such as those for PSGI and / or WSGI, and the famous inline loader-in-the-sky I will be writing. Pretty nice, no?

For the technically interested, what has happened is that:

  • Loaders now accept 3 arguments: the request (as a PtrBuf). This is an opaque handle, that can be used to bind to the apache input / output handles.

Update on infrastructure

All things considered mod_parrot is a little less than a 1000 lines long. About half of that is infrastructure (building, testing). For that, it now buys you the ability to configure, start and stop a mock apache server via the pudding framework (testing is influx right now... Karma for whoever can guess why its called pudding.). Not only that, I can attach gdb to the same, also via pudding.

A few steps forward

So, what happened in the world of mod_parrot? Segfaults, thats what happened. And an awesome community helping and fixing every problem.

First the segfault. What happened is that I called compreg() from within a script. That failed because the compreg opcode assumes a hash to initialized, which wasn't. (It was NULL). So once I mentioned this on the mailinglist, within minutes whiteknight++ pushed a fix that made the opcode use the proper API function which fixed the problem.

GSoC starts today

As you may or may not know, I'm tasked with implementing mod_parrot during this years' edition of google summer of code. So in preparation, I have researched the wealth of information that is the internet, and have found the following peculiar little tool:

http://httpd.apache.org/docs/2.2/programs/apxs.html

Which stands for the apache extension tool, and which can - among other things - generate, compile, and install entire modules. I originally planned to take two weeks to do that very thing.

Hello Parrot

Hello everybody,
Let me introduce myself. I'm Bart Wiegmans, brrt on irc, and I will be implementing a new mod_parrot this summer, courtesy of google and whiteknight. Which will make it possible to serve parrot-powered web applications once again.

So, who am I? I'm 24 years old and I study biology in Groningen, the Netherlands where I live together with my girlfriend. Aside from that, I work as a programmer for studenten.net. As for hobbies, I play mario kart and pikmin. I used to say I had four pet rats, but unfortunately one of them died just Last weekend.

Syndicate content