An Observation

It's regrettably common for car drivers to try and muscle out motorcycles, and, given that the motorcyclist is the squishier of the parties involved, it's usually better for the motorcyclist to choose discretion over arguing too hard about right of way.

As an enthusiastic motorcyclist, I've this happen to me numerous times. It is, however, hard not to feel particularly ticked off when the car in question sports a prominent "Think Bike" sticker.

An annoying discovery

One of the great annoyances of manufactured items is they tend to be very symmetrical. This makes various approaches to automated registration more complicated, since there are often ambiguous possible solutions, so one often has to shove in more domain specific knowledge to get the correct answer. Domain specific information makes thins less portable, and generally requires annoying maintenance effort later.

This is all; relevant, since I've been trying to avoid shoving such domain specific knowledge into the registration step for the calibration cube for the x-ray system, which, being quite a precisely manufactured cube, is rather symmetric. I had thought I had enough information available from the views to get around this, and solve the problem fairly elegantly, but I spent the later half of last week and most of this morning failing to make the idea work. The answer obtained looked almost reasonable, but had a 5 cm offset, and a rather high error.

I thus resorted to a heavy-handed optimisation approach, using the domain specific information to ensure the minimum was near the correct place.

This did not work. Given the fairly specific constraints I had placed on the problem, not working was a very surprising result.

Much digging later, I discovered a sign error in the input data I had created to describe the cube last week, which meant I was trying to register the cube a collection of fairly widely spaced separated planes, and getting odd results out.

While I now have a correct solution, I will now need to revisit my earlier idea, and see if it works better with the correct data. Since I spend considerable time checking the data last week, and had convinced myself that it was actually correct, I'm currently rather annoyed with the universe [1].

[1] Because it's clearly not my fault, after all.

Code Mainentance

One of the problems with an under-resourced development environment, such as the one I'm involved in at iTL, is the lack of decent code review. Consequently, the code base ends up with dirty little secrets, like the routines to automatically identify the calibration cube, a awkwardly tangled implementation of what still is actually quite a good idea. It's a chunk of code I'm both perversely proud of, and terrified someone else will look at and thus call me out as a total fraud.

Despite this, it actually works pretty well almost all the time, which is unfortunately an "almost" too many, so today was spent debugging this dirty little secret, which is never that much fun. It's easier than it may sound, though. Most programmers will have had the experience of looking at old code and thinking "How could this possibly ever work?", and most programmers will also have experienced looking at bits of old code and realizing "Oh, that actually quite a nifty trick". For me, reading this code tends to be a sequence of a's followed by b's followed by a's and so on. When the sequence doesn't end at b, it's probably a bug. The retroactive ego-boosting and deflating does make it a slightly bizarre experience, though, and not one I'm keen to repeat anytime soon.

Who knew?

Turns out that spending an entire afternoon in a meeting that spun around in circles doesn't leave me in a good state of mind for reading a thesis draft.

This Week

So, what happened in the past week?

On Monday, there was VTES at Phillip's house. I tried out 3 decks, and, while I didn't do particularly well, I managed to oust my prey in two games, which was a fair effort for the evening

Tuesday, I was off sick

On Wednesday, I attended Geekdinner (pictures here), which was pretty enjoyable, despite riding my motorcycle in the rain (and, please note, the sound of the rain isn't soothing when you're on a bike). The trip back was enlivened by a cylinder cutting out, but I made it home alive [1].

My UPS's finally arrived, so I spent quite some time on Thursday prodding at them. Annoyingly, there's a bug in nut 2.2.1, which is the currently latest packaged version, which breaks support for several megatec usb UPS's, such as my new ones, so I had to roll my own nut 2.2.2 backport, which was not quite as simple as I would have liked.

Today (Friday) was mainly spent on the final stages of setting up our rather idle UltraSparc as a buildbot for numpy. After some annoying surprises (a variant of issue 198 amongst other things), and some fussing around to get multiple chroots installed (so we can test both g77 and gcc4's gfortran), things finally seem to be working properly (see this and this for example).

Workwise, we're testing the latest version of the SPG system, so much bug fixing. I loathed at qt a fair bit, but managed to get most issues resolved. We've also been poking at the robot-SPG communication, which has uncovered some interesting issues with the path planner, so , even there, I can claim to have had a reasonably productive week.

[1] I've always liked that song, the actual riding in the rain less so, though.

Today

Proposition A:

Waking up on a cold morning, and realising that you don't need to get up for a while is one of life's pleasures.

Proposition B: (from Proposition A)

Waking up on a cold morning and realising you must get up now is a poor way to start the day.

Proposition C:

Days that start poorly have a higher likelihood of sucking than other days

Today amply demonstrated Proposition B, and provided no evidence against proposition C.

Vampire on the mind

I failed to distinguish between Nergal and Mysql at a glance today - I think my subconscious is trying to tell me something (whether it's about vampire or MySQL is open for debate, though).

Curse you, James Barrie

For never finishing "Shall we Join the Ladies".

Yes, I knew it was an incomplete play (it even says so in the stage directions). That is of absolutely no comfort whatsoever.

And I can't even swear revenge, what with the march of history and all that.

Darn and botheration.

Common experiences

Communication is much easier when people can call on common experiences. While many concepts and experiences are fairly universal, there are others that are far less common, and, while it may be quite possible to cover the broad outlines, it is very difficult for someone who has not shared a similar experience to truly grasp the details.

Dealing with a mosquito buzzing around inside your helmet on the N2 probably falls into the "not universal" category.

The Eskom Rant

In which nothing particularly new is said about the situation, no great answers are provided, and the tone of the debate is not raised to any great height.

That we have a power crisis is a major problem, and shows poor planning. That we have a crisis, and no particularly coherent response from the warning signs in 2006, is an example of poor planning.

Several things that have struck me during the current situation:

• A scheduled power cut that doesn't happen is almost as bad for productivity as a power cut.
  
• Eskom ain't at all good about providing information about why things go bad - their press releases are appalling. "We need to load shed, tough cookies" basically.
• This leads to lots of rumours (X% of the generating capacity off-line, so much power exported to other countries, etc, etc.), and the lack of information from Eskom makes the denials implausible.
• Unfortunately, the people jumping up and down about the rumours most ardently (the DA and Solidarity stand out here) aren't plausible either, so it's really hard to good any feeling on what the heck is going on
• WTF is up with poweralert's trend pages. The displayed historical trend changes radically over quite short periods of time.
• While the working laptop is nice, until everything that connects me to the Internet at iTL is also on various long-lived battery backups, I can only work at about half capacity during a power failure. When did I become so reliant on Google and other online services?
• Why is iTL listed as both iThemba Labs and Cyclotron in the load shedding schedule? It makes no sense.
  
• Although I finally found a real personal use case for searching pdf's. Pretty much every other document I deal with, I need to read the entire thing, and, since most are academic papers with figures, I usually use the figures to navigate if I need to find something again.
• Considering the number of power outages, I'm surprised more of the hardware I maintain hasn't died.
• Discovering I mis-set my alarm clock after yet another power failure was an unpleasant surprise.
• I need new UPS's for some of the Stellenbosch machines.
• I badly need new UPS's for home.
• Why is it going to take so long to build another power station? There is surely lots of scope for just throwing extra resources at the project (it's not software after all)
• Aren't we due to have the pebble bed reactor come online around 2013 anyway?

Achievements

On Friday, I defrosted the fridge in the lab.

It's a sad comment on the state of the fridge (regrettably, I didn't think to take my camera) that actually achieving what I did on Friday, which was to get almost all the ice out of the fridge, represents a significant achievement, and occupied a considerable chunk of my time. Anyway, the fridge is now again usable.

Probably the frustration of spending most of my day wrestling with a fridge is why I got involved in debugging a postscript issue on #clug - for whatever reason, evince doesn't properly render postscript without the %%Page: comment deliminators - once we figured that out, everything worked a lot better.

Christmas

I like Christmas - it's a good oppurtunity to catch up with family, take a break and laze around doing very little, and generaly annoy the garden's birds by trying to photograph them (which is proving difficult this year since the trees have leaves).

Unfortunately, Christmas is paired with Christmas shopping. In addition to the usual perils of shopping at this time of year (although fortunately fleeing the coast does mean I'm facing less crowded malls than those in the Cape), it also involves selecting some sort of appropriate gift.

Given that everyone I'm shopping for has a reasonable level of disposable income, this means finding something that they want (and isn't ludicrously expensive), but won't buy for themselves, since otherwise they'd have it already. This turns out to be really hard. I suspect it's time to seriously consider falling back on the default gift of a box of biscuits.

Fortuantely, the Christmas season does feature extended shopping hours, so, despite still needing o acquire several gifts, I should be OK.

LotN Starters

So, with the order of LotN Starters having arrived, we had a session to try them out. Overall, the afternoon was quite fun.

In the first game, I played the Assamites, and starting, bleeding Simon, playing the Followers of Set, bleeding Adrianna, playing the Giovanni, bleeding Kevin with the Ravnos. Simon swept the table there, although I was able to burn two minions of his.

This game was rather frustrating for me - Simon got out both Tutu the mummy, and Nakhtorheb, giving him two minions who could untap a turn. I was eventually able to burn both Tutu and another small minion, but in each case, it took a couple of actions to setup. Also, given the Settites S:CE options, the Assamites struggled to be effective. I weirdly only drew 1 Master card, and no untap at all. Adrianna had a couple of good combat combos, but suffered from drawing too much equipment, and wasn't really able to get the Giovanni deck going forward too well. Facing multiple acting minions also didn't help at all. Kevin wasn't able to get the Ravnos deck going, and generally struggled for useful actions throughout.


In the second game, I played the Ravnos (starting again), bleeding Simon with the Giovanni, bleeding Adrianna with the Assamites, bleeding Kevin with the Settites. Kevin and I each gained 2 VPs, with Kevin ousting me after I ousted Simon and Adrianne.

Kevin managed to pull both Tutu and Nakhtorheb for the Settites again. Fortunately, I was able to pull Durga Syn, whose "do not tap for blocking allies and younger vampires, and also had some good luck with drawing untap, but spent much of the game struggling to generate forward momentum due to needing to defend against Kevin. Adrianna struggled with her crypt draw, and ended up bring out 2 ten-caps, while struggling to really impact on Kevin's vampires. Simon was able to pressurise Adrianna quite successfully (striking for 7 in one combat), and, had he ousted her, was probably quite well placed to sweep the table. However, I was able to prevent Simon's lunge succeeding with a Ignis Fatuus, and, thanks to a round of several blocks of Kevin's minions, was able to draw week of Nightmares. The additional bleed allowed me to oust Simon and Adrianna in quick succession, but, despite the 12 pool gained, I then ran out of untap. Kevin, despite being down to only 4 pool (IIRC) was able to bleed through me at an alarming rate (I lost more than 10 in a single turn), and I was unable to generate the stealth needed to get the critical bleeds through.

Overall, the results were not that surprising. All the starters are hurt by having only 6 distinct vampires in the crypt. The Settite starter is the best balanced of the lot, and can generate some quite scary amounts of bleed. The untapping 10-cap is horrible, and is probably the best vampire in the expansion. The Giovanni deck has promise, although is a little light in Dominate (both in the crypt and cards in the deck), and is probably equipment heavy. It also seems an odd choice of deck to have the most votes (3), given the single titled vampire in the crypt. The Ravnos crypt is weird, having only 1 vampire with superior Animalism, although Durga Syn's non-tappiness is very useful (although having a 9 blood reserved as a blocker does suck). The deck struggles with the rather diverse scattering of Chimestry options, and I found the deck really struggled until I got "Week of Nightmares" out. Also, not seeing the Path hurt me, since I spent a lot of blood on Chimestry cards without ever recovering it. The Assasamites needs the most work, undoubtedly. The crypt is a little unbalanced cost wise (2 of the 6 vampires are 10 caps), and the deck needs a clearer focus than it currently has.

Still, I'm happy to have copies of the decks, and the investment looks to be well worth it. The extra potence cards from the Giovanni decks will be very useful, even if I don't put together a good Giovanni deck.

Sutekh ramblings

(Sutekh is, of course, the python Vampire card management app Simon Cross and I have been working on)

Conceptually, the app is fairly simple, and I've been largely using it as a learning bed for pygtk. Consequently, it does things by hand, rather than the often recommended "use glade" approach. Personally, for something that now as a number of dynamic aspects to the gui (ability to rearrange panes, and so on), I think glade would have become quite painful, and straight pygtk coding is fairly easy once you wrap your head around the whole container paradigm. As an vehicle for learning pygtk, it has been pretty good.

But what has surprised me is it's ability to uncover database oddities. We have to date, discovered two issues with sqlobject (both fixed), had to work around sqlite's query optimiser by throwing in extra joins, triggered a segfault in sqlite (fixed in more recent sqlite's fortunately) and hit a bug in mysql query optimiser that makes certain queries run extremely slowly. WE ahven't triggered any postgresql bugs yet (although there have been a few weirdness's with certain versions of sqlobject talking to postgresql), but have had to fix several bugs in Sutekh's code because of postgres's much more stringent SQL implementation. For not a teribly complex database app, it's quite a impressive list.

So, do other people not trigger these bugs? Are we stretching corners of the databases that many other apps just don't hit (Sutekh has a number of tables, and can involve some quite complex joins)? Do other people just stick to one db, and work around it's quirks?

I dunno, but on the other hand, it's quite pleasing to see how some of this bugs have disappeared during Sutekh's lifetime, which is always one of the strengths of FOSS.

Enough already

An open letter to the management.

To whom it may concern,

While I appreciate that, given the near-crisis strain on the region's water supply, rain should always be considered a good thing, surely you must agree that several rainy days in succession in November is pushing it. Getting wet on a motorcycle is to be endured during the Cape winters, but getting wet during prime riding season is an affront to the natural order of things.

While I will concede that today's rainbow was pretty, it's short duration, and that it occurred while I was riding, and thus unable to photograph also shows a distinct lack of proper planning.

Hoping service will improve.
Disgruntled.

Futurex

I'm sorely tempted to write a really lengthy rant about just how bad Futurex was this year, but, considering that such a rant would take me longer to develop to the desired finely honed level of virulence than I actually spent at Futures, I'll restrain myself to a brief, less well thought out rant.

If you had' got the message from the above, Futurex was bad. It was dire. As Mark rather aptly summed it up "It was a good squib short of a damp squib". It would be much easier to list the things they got right rather than the things they got wrong, expect there isn't anything to list as being noticeably right. It felt half-baked, unprepared and poorly thought out. No map, no logic to the positioning of the stalls, only a couple of interesting things on display, amid a lot of just meh. Even the securex side of it didn't have anything interesting.

Basically, unless I am assured by several trustworthy people that the next one is a massive improvement, I'll probably not be attending Futurex again, which is a pity, because, at one time, it used to actually be a useful event.

Speed Traps

I really, really dislike camera speed traps.This is especially the case when I have recently received a fine from a camera trap, but, even those usually quite long intervals between such fines, I maintain I high level of general dislike for them. Of course, it is the righteous indignation for the fine I received on Friday, for which I have no real extenuating circumstances, and am completely at fault, tat prompts this post.

A large part of my dislike is the total separation of the South African camera traps form any form of law enforcement. They are run purely as a money making scheme. The fact the most cities out-source the
whole process should surely ring alarm bells at several levels of government, but apparently is viewed as good business.

The objections to running camera traps as a business should be reasonably self evident. There is o incentive for the company placing the cameras to place them in points where speed reduction is an actively good thing, since, many people being semi-sensible, the number of people speeding will be comparatively low. Likewise, at points where exceeding the speed limit is less of an issue, it's in the company's interest to place cameras to maximise revenue. That this is completely the reverse of the desired behaviour, is the problem.

Similarly, to increase revenue, cameras are disguised. This allows several bites at the cherry before people learn that the camera's there, and allows maximum exploitation of out of town people, who have the added advantage of not being well placed to contest the fine.

this also creates the aspect that annoys me most - the long delay between offense and punishment. Receiving the fine some weeks later means that a) one cannot argue against the fine based on traffic conditions or whatever, and b) the actual events are vague, and thus any defense is difficult. This is also in the interests of the company, as revenue suffers when people can successfully contest fines. Likewise, there is no incentive for applying the law flexibly, since a narrow, legalistic interpretation, is better for the bottom line.

My last objection is not against the cameras system specifically, but the way in which it is used to completely replace all other forms of traffic policing. The number of moving offenses that don't involve speeding on our roads is quite staggering, yet only the one is targeted. And since this is targeted, people adopt tactics to defeat it, such as using false plates, or mounting the plates in positions that are difficult for the camera to observe. Since no other policing is done, these tactics are completely safe. That the system fails to address such obvious gaming of the system is a sad inditement of the system's effectiveness.

So, to summarise: Camera Traps BAD, especially when they nab me.

History of a bug

(or how a problem with our HP printer earned me so money)

The story starts some years ago, where the department bought a rather nice duplex HP4000 printer. For quite some time, I had it happily setup using the on board Postscript interpreter. Then Matlab started producing Postscript 3 graphs, and the on board interpreter didn't handle this, and there was some issue with the newer Matlab's Postscript 2 graphs exceeding the memory capacity of the printer.

Ah-ha, says I, ghostscrpt has good support for the HP printers, so I'll push everything through ghostscript and get PCL output to feed the printer. The only issue was the that the ljet4d driver did not handle Postscript's /Tumble command at all, which was inconvenient, Still, I went with the setup, and, all in all, it worked pretty well, except that, every now and then, we would run into the issue of not being able to bring with /Tumble.

Then, while digging for something, I discovered HP's list of PCL commands, and saw that, supporting /Tumble was quite simple on the PCL side. Thus informed, I spent some time digging into ghostscript's code, and created a patch (which was not very clean at that stage), which did the job. I sent the patch off to the ghosctscript ailing list, and forgot about it for a while.

Sometime later (early 2005), I upgraded the print server, and had to adapt my patch to the new version of ghostscript. In the process, I cleaned up several things, refactoring it to move the Postscipt parsing of /Tumble down into the core, and generally getting something I was much happier with. Since the post to the mailing list yielded no response, I shoved the patches in ghostscript's bugzilla (one bug for the parsing refactoring and one for the changes to the PCL drivers). Since I now had a working setup, I didn't push the issue at all.

Forward to 2007 - I again upgraded the print server, and need to port my patches. At the same time, somebody on the ghostscript side is assigned to the bugs I submitted with the previous patches, and promptly closes them as being old. After complaining that this was not a valid reason to close the bugs, I was told that the parser changes were unacceptable (a decision I disagree with, personally, but it's not my call), but that they would consider an updated fix to the laserjet drivers. There was also a not that the bug had a bounty, which I assumed would be some nomial sum, and didn't note particularly.

After some delays on my side, I eventually found an afternoon and put together yet another version of the patch, and submitted it last week. Thus, I was somewhat surprised when they contacted this week and told me that the bounty was $500. Additionally, they were quite quick about processing the payment, an, at 14:00 this afternoon, my bank contacted me to let me know that the money had arrived.

Overall, I feel quite pleased with the final result - despite the long time frame, it was never more than a couple of afternoon's work and I've had a solution in place for my problem most of the time, but, finally, next time I upgrade, I won't need to worry about this. Of course, I may also no longer have a printer to which the patch applies, but so be it.

On Failure Modes

People designing systems don't think enough about failure modes. Failures are annoying, but you need to design the system to fail gracefully. It is exceedingly annoying when this doesn't happen.

A recent example, that is of particular concern, as it bite me twice yesterday, it the access control system at Stellenbosch. When the system is down for a particular building, there isn't anyone authorized to open the other doors into the building, thus one is forced to wait until the technicians responsible for the access control system respond. Since this is naturally after hours, this takes some time, and is less than ideal when all you want to do is dive into the building quickly to collect something. A failure mode not designed to enable people to do what they need.

I'd feel a lot happier about the whole experience if I thought there was some chance the system would improve.

End of my current car Troubles (hopefully)

My car finally seems to be back in operational condition, due to a badly leaking water pump, leaving the engine running dangerously hot after only a few minutes. Since, based on my email records, the water pump collapsed on the 1st of Feb, this has been an extremely long and drawn out saga.

The major difficultly seems to be how ridiculously hard it is to get parts for remotely old cars in the western cape. Growing up in the Free State, where it is common to keep cars running for yonks, this catches me off guard every time. That I ended up having to get a water pump couriered down from Bloemfontein to eventually get things solved indicates just how strange the problem is. Still, the replacement pump seems to be working fine, so hopefully all will be well for a while.