So I've hit the same problem I had last time. Template Toolkit and AxKit basically have incompatible error handling. They both use objects to do their error handling and they both are naive enough to assume that any object thrown is one of their own type. For example, AxKit:
sub prep_exception {
my $err = shift;
if (ref($err)) {
return $err;
}
...
Um...that's not good. if you return a Template::Exception object things are going to go very wrong (because there's no throw method for a start). Even worse is Template::Service:
# there shouldn't ever be a non-exception object received at this
# point... unless a module like CGI::Carp messes around with the
# DIE handler.
return undef
unless (ref $$error);
...what you mean like AxKit does. Botheration.
I'm going to probably have to introduce some thunking, which probably means patching either AxKit or Template Toolkit, or probably both. Darn!
So I've been actually trying to use Apoche::Test to test this module and I'm slowly getting there. It's quite swish when it works (we don't use it ourselves at work because apparently it's too clever and autodetects things outside of our build system!) I'm currently playing with writing dummy AxKit lanaguages that unconditionally dump different things in the pipeline so that I can test that the TT language reads and understands the previous data from the pipeline fine.
Once I've got the basic version done there's still big problems ahead. Firstly, there's the issue of caching. Currently I'm creating a new TT object every time, which means that every single time a TT stylesheet is used it's turning the template into Perl code. This is about ten times slower than reusing an existing lump of code. So I need to somehow merge TT's providers with AxKit's providers so that caching works. Which should be fun. The second major issue is configuration. As far as I can see it atm, the configuration for things like INCLUDE_PATH that kip's already done is on a per server not per stylesheet basis (or perl Location block directive). I'm not sure what the right thing to do here is...I'll have to give it some thought.
Anyway, slowly but surely.
However, I want to go a little further. I'm fed up taking down and bringing up the main servers every time I want to change a config change (which is quite often when I'm playing around with AxKit for example.) So I want to be able to run each virtual host standalone on a high port as well as run it as part of the main server. To this end I've split the remaining main httpd.conf into a common.conf and all.conf. And I've implemented a standalone.conf for each virtual host that uses the common.conf and starts the high-port server.
This is all fine and dandy, but what I want is an apachectl for each of these development servers. Which leads me to a problem. They're written in bash. Has anyone got any idea how to referrer to a file relative to the bash script itself (i.e. what Perl's FindBin module does?.) I really don't want to have to have a apachectl file that's hardcoded for each and every server.
I released a new version of Test::Builder::Tester. Minor change to deal with the new Test::Builder that Schwern is going to release Real Soon Now. If you use TBT, I recommend re-releasing your module with a dependancy on the new version so that if anyone installs the new Test::Harness their tests don't unexplainedly fail.
The AxKit Book arrived at work yesterday and I've been pouring over it ever since. It's really good, just thick enough to contain what I want to know without being too thick. It's an irony for all the time I hang out on #axkit-dahut that I've never really used AxKit itself in anger (just all the XML tools it's made up of.) Maybe that's time to change. I'm only slightly upset that ORA seem to have let so many typographical errors slip into the book - there's some examples that contain fragments of XML that are obviously (after a bit of head scratching) meant to indicate things to the publisher (e.g. make this bit bold) and have no place whatsoever in the example that is being covered. But hey, I can live with that. I'll have to get my tippex out when the errata is published.
I've been playing more and more with CamelBones and have had a go at developing some simple applications in this. It helps that the local expert jerakeen sits across the desk from me and I can keep prodding him when I can't get something to work. I'm really impressed that I could write one class in ObjectC and another in Perl and they all interoperate seamlessly - without me having to write a line of XS code! This stuff rocks.
Oh, and in other good news we've finally got that little bit closer to organising YAPC::Europe from work - acme, richardc, jerakeen, Nicholas and I will be staying in the Days Hotel with all of Birmingham.pm if you want to join us.
Normally I use the american keyboard layout (since, as a Perl programmer I really want shift-3 to give me # not £.) This means when I hold down 'Alt' in most applications I can type things like “special quotes” and fünny léttérs. All good and well, but occasionally there's a unicode charecter that I know the code for but there's no keyboard shortcut for.
Lots of googling later and I'm a little more informed. You know within "International" in "System Preferences" you can enable one or more keyboard drivers in the "Input Menu" that you can switch between (with command-space and alt-command-space, or by using the 'show input menu in menu bar' option.) As well as enabling the charecter palette that allows you to scroll though seemingly all of unicode (useful, if not a bit tiresome every single time you want to enter a letter) you should also enable 'Unicode Hex Input'. When you switch to this keyboard driver it acts just like it would if you were using the american keyboard (yey) but changes the way the 'Alt' key works. Now holding down 'Alt' and typing the UTF-16LE code for the charecter (i.e. the hexcode for the codepage) allows you to enter any unicode charecter you want. Cor, it's just like using Windows again.
prove is a Test::Harness thingy that you can run test scripts from the command line without using make. It ships with later Test::HarnessesI also came up with the worst unicode joke in the world evah. I'm so very sorry.
And that's just the *Perl* stuff. Boy am I dog tired.
Shoulda gone to Pisa with acme
Organising technical meetings are hard. Organising lightning talk technical meetings are harder.
I've got fourteen speakers (excluding myself) that I've had to convince to speak at this tech meet. This means they've all been emailed and I'm waiting for their slides (if any) to turn up. I've emailed the announce list announcing the meeting. I've setup the script on penderel to allow people to sign up. I've written a guide to speaking at tech meets that I've emailed to all the speakers.
All that's left to do now is write my own talk, chase everyone to give me the slides, make sure that everyone who's attending knows they have to sign up in advance, get the list accross to morgan stanely, and have a nervious breakdown.
It's fun being London.pm leader sometimes. I can't make my mind up if this is one of those times.
We talked about the usual things. Shoes. Mail order shopping. Holidays. Visting famous landmarks (Pyramids, Dams, Waterfalls) Mucking about on Boats. Funny furrien languages. The usual stuff.
(This may be the majority actually linked to the upcoming and just passed Perl conferences...but that's another story)
After deciding we'd spent quite long enough in the pub some of us adjourned for Curry, but the more sensible of us headed off for Dutch Pancakes. Pancakes are good...
On an alternative note I see that registrations for YAPC Europe 2004 have just opened, and so has the CFP for Lightning talks. I've submitted a talk proposal for using utf8 with Perl, because quite frankly I do believe you should be able to explain everything you need to know about Perl and utf8 in four minutes flat. I'll have to see if I get accepted.