Pet Pixels

Zoë and I sailed from Gibraltar to Almerimar with my Mum this weekend. I use "sailed" a little loosely as there was essentially no wind, so we motored nearly all the way. Zoë had a fantastic time. The weather was lovely, and with so little wind, it was really easy to stop for a swim every so often (like when the water temperature sensor said 27°!). The highlight for me was sitting down for dinner in the setting sun and being joined by 40 or so dolphins. Highly recommended!

I just grabbed the new update to the Safari 4 preview, and I have to say it's very zippy indeed. I ran SunSpider benchmarks on it and FireFox 3.0.1 on my Mac Pro. Safari 4 is on average 75% faster, but has many results that are in the 200 - 500% range. This is only measuring javascript performance of course, but that, plus whatever other changes are in S4, translates to incredible speed in daily use. I use the SafariStand extension to remember my open tabs, and I can reopen about 40 tabs in 8 windows in about 3 seconds, including all their content! FF 3 was a huge improvement over 2, but Safari 4 is a different league. This is only a preview, so it will probably get faster still by release. The integration of the JS debugger is very elegant (Drosera has been rolled in), but I'm still looking forward to the appearance of FireBug for Safari, which someone is doing as a Google SoC project (S4 adds some FireBug hooks too). All the new CSS funkiness from recent webkit nightlies is there too, and I suspect many an iPhone and widget developer is drooling over them...

There's this enormous apache mod_rewrite bug that I ran into back in 2005, and to my dismay, it's still there. Long-standing bugs are usually small edge cases that don't affect many people, but this one is a monster that I suspects pretty much everyone that's using mod_rewrite, and they've just been lucky in avoiding it. The basic issue is this: if you match params that require URL encoding to be safe, mod_rewrite will not rewrite the back-reference (that's $1 below) correctly. So take this very simple redirect: RewriteRule ^(.*)$ index.php?show=$1 [R] so you hit http://www.example.com/a%2Fb and mod_rewrite neatly rewrites it as http://www.example.com/index.php?show=a/b! Notice that it has urldecoded the matched parameter in the replacement string. Apache 2.2 introduced a new B flag to deal with this, but that apparently suffers the same problem! There are two workarounds I've used that are both horrible: double-encode the source string (if you are in control of both start and end points of the URLs) to survive the spurious urldecode, or base-64 encode (javascript flavour) it and do the decoding yourself. I did warn you they were horrible. I'll bet that there are a zillion mod_rewrites out there that suffer from this fundamental problem and haven't even noticed. If a few people voted for this to be fixed, it would probably go away...

Recently I've had a problem with subversion commits returning a '200 OK' result, accompanied by a peculiar MERGE error (when I'm not doing a merge), but weirdly, the commit had actually made it into the repo. I'd googled for this a while ago with no success, but I had another try today and found this post. Thinking about it, I'd had this problem since updating to the very-very-long-awaited trac 0.11 release. So I tracked down the latest release of the trac-post-commit-hook script and installed that, and amazingly enough, it just works. Thank you UberGeek!