The solution was to coerce GCC into not using its own inline memcpy without affecting other inlining. Turns out all you have to do is make the size argument a variable rather than a constant. So I changed lines like this:
memcpy(to, from, 8);
int sz = 8;
memcpy(to, from, sz);
I'll send this off to Matt tonight, and I should also port it to the main SQLite codebase. This took way too long to figure out...
At least the free carafes of coffee were still available.
.namespace [ 'MyHandler' ]
.local pmc r
find_type $I0, 'Apache::RequestRec'
r = new $I0
r.'puts'("Just a bunch of text.")
I was able to encapsulate Apache's request_rec structure in a Parrot object, and I've implemented a 'puts' method that calls ap_rputs using the request_rec and the supplied string.
You can use this as a content handler in httpd.conf:
Now, you can write entire handlers in Parrot, but the real goal is to have higher-level languages use Parrot to instantiate Apache::RequestRec objects and use them as they see fit for mod_perl, mod_python, or mod_whatever. mod_parrot will act as the layer between the language and Apache -- infrastructure we can write once instead of once for each language. A lofty goal, yes, but so is everything with Parrot.
Source code is coming soon.
The original mod_parrot was limited by the Parrot API at the time, and only ran bytecode as a whole program, a la Apache::Registry. Nowadays we have goodies like namespaces and the ability to call Parrot subs from C (handlers!), making things much more interesting. This week I'm focusing on writing some internal wrappers for calling Parrot subs and the Apache module hooks. From there things are hazy, since there are so many directions I can go once I have an Apache module. I'll probably need to create a roadmap of sorts to keep my brain organized.
So I wrote Monocle. Monocle is written in Perl. It has no configuration files. No GUI. no web UI. Just a server, some commands to configure it, and an embedded database. It has reporting features that let you answer questions like, "Was our service down last night at 3:45 AM?", and "Was our response time faster the first week of June than the first week of July?", and of course, "What was our uptime for the month of January?" Anyone with an SLA on their services will appreciate these reporting features.
This is nothing revolutionary. Just a simpler design with the core features I think belong in a monitoring system.
If anyone wants to try it out, I put up a simple web page here. It's still in beta, so bug reports are most appreciated!
Now I need to dig around some code and see what I've gotten myself into..
I came home a few hours before a massive line of thunderstorms rolled through, taking down half a tree in my backyard and washing away half the mulch in my garden. A homeowner's work is never done...
So they put me on standby for the 9:30, with a double booking on a Wednesday morning flight *just in case*. Thankfully, I got the last seat on the flight and got into Portland around 11:30. Took a shuttle to the hotel, where Geoff bought me a beer, which was sorely needed.
Anyway, I'm here. See y'all around Portland!