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.

I called compreg to load the high-level-language compiler for winxed. This did not work until I setup the search paths for the parrot vm. Luckily, parrot_config supplies me with those at build-time. When that was done, the compiler still would not work - the PIR compiler was not registered, and winxed compiles down to PIR, not to bytecode. Registering the PIR compiler via the imcc api fixed that
problem, and now mod_parrot can run your scripts, provided they are written in winxed.

It also turned out to be so that - due to an apache module being a loadable library - every and all functions exported by both mod_parrot and apache are available via NCI. That is, if you build parrot with libffi support, which at first I had not. The inside_out branch is set up to experiment with this. In the end, I'd like to create an IOHandle that calls apache functions directly, so as to avoid copying and improve integration.