21/03/2005 @19:10:33 ^21:08:10

SOMETIMES YOU'RE LUCKY, SOMETIMES YOU'RE NOT

While replying to an email (don't laugh, I do reply sometimes, just very rarely) from Dave this morning (Look he's linked to me like four times today, show him some love) the following humorous anecdote came to mind and rather than confine it to an email I thought I'd share it with you, my faithful readers: (god I sound like a prick. I'm sorry. I've been awake for about 28 hours and I feel woozy. But prior to this I slept 23 hours out of 32! I don't know.)

Reverse Schroedinbugs

A schroedinbug is defined by the Jargon file as follows: (from the definition on Foldoc)

A design or implementation bug in a program that doesn't manifest until someone reading source or using the program in an unusual way notices that it never should have worked, at which point the program promptly stops working for everybody until fixed.

Last month you may remember while at its old location the site's front page emptying. This was an artifact of the way the code calculates which updates to display* I knew full well this was going to happen and could do nothing to prevent it, and indeed was quite looking forward to it (I have that sort of sense of humour)

However the date passed and it didn't happen. I was thoroughly perplexed. The port of the old PHP code to perl was behaving as expected. I stared at the twisted evil that is PHP code until my eyes grew hot and cindery, and failed entirely to spot any reason why what I believed was physically impossible was happening right before my eyes!

So I gave up. I had to run the PHP code again to see what the hell was going on. But I'd resolved not to let the black heart of the PHP interpreter blight my CPU cycles with its blood and intestinal discharge, so instead I ported the entire site code to the dystopian and obsolescent fields of crocuses. This took ages. The code went over all right but file format incompatibilities between different versions of the Berkeley DB library reared their many (well, three or four I know about) ugly heads. It took a long time to get the old update database into a format the DB library which which PHP on mimosa (well, crocus) was linked. Some hours and many bizarre error messages later I finally got it working.

And there it was, staring me right in the face, an update-less page, pure as the driven snow, if the driven snow was grey and had a hexagonal tessellation of circles imprinted upon it. Totally mystified and confounded, I reloaded the tab which contained the page at triv... At exactly which point it emptied.

I had spent in total several hours proving that what triv's PHP interpreter was doing was, as I suspected, totally impossible. At exactly the point it was proved it was behaving impossibly, and I have to stress only at that point, did it stop doing it. Mental. Reverse Schroedinbug. See?**

* given time T, defaulting to "now", include:
 • all the updates from the month containing T prior to T, and:
 • all those from the month before the month containing T, if the day of the month of T is before the fifteenth.
Yes quite. Who the fuck cares. I know. I only put this shit in because I'm anal.

** While you could very well argue that I simply fell foul of an simple web caching issue, I will still argue it's PHP's fault for being retarded. Its date functions in particular are terrible; the parameters they take and return differ wildly from the POSIX standard functions with which they share their names, and which everyone knows (or at least, knows which man page to read to check them)