Not much news recently, just plugging away at various buglets, incorporating patches, updating docs. The use-case "just hotsync to keep a backup of Pilot with no conduits" is shaping up well, finally. Finding the discipline to test stuff thoroughly is .. difficult.

Testing KPilot is one of those things that really takes the fun out of developing it. Whereas for lots of KDE applications you can just recompile, click, and see the results of your fixes, KPilot is different - and much slower. Suppose I'm working on the KNotes conduit; copy handheld to PC isn't working quite right (this is bug 69595). When I make a fix, I need to:

  • switch to another user (to save my own data),
  • check the state of that user's knotes and kpilot directories,
  • check the state of the Palm m105 I use for testing (this may involve hotsyncing it to a known state with pilot-xfer),
  • start KPilot
  • perform the hotsync
  • check the state of kpilot and knotes for the results

This is a turnaround of, say, 10 minutes, and it requires special attention to detail in some of the steps, and it takes batteries too.

Using the PalmOS simulator POSE isn't that big of a help, since it's crash-prone (at least on my Debian box, and on FreeBSD it doesn't run at all), and the syncs - the most time consuming part of the operation - take just as long.

Finally, checking the results isn't something that can be done mechanically, at least not easily: I need to view the contents of Palm databases (in KPilot) and check the data held by other programs (like KNotes). If it was a matter of comparing some md5 sums, it would be much easier to see if I had the right results for a particular test.

Lest it seem like I'm merely complaining: I'm not. I'm admitting that I like coding more than testing. I'm admitting I like the cheap thrills of instant bug-fixing gratification, and that slow test cycles take those thrills away. I'll even go so far as to say that I have great admiration for folks that can stick to test-based software development - most of the time I can hardly describe beforehand what it is my software is supposed to do, let alone figure out how to check it in an effective manner.

That said, it's back to the old grindstone ...

(The title of this blog entry is of course derived from a singularly lousy pun which appears in one of Asimov's "postcard stories." It took me years to understand it.)