A new address book public repo

Veteran readers may recall my old posting of the address book rewrite repository. My original idea did not turn out so well—I had about 5 heads at one point because of review comments and simultaneous patches. Not to mention the history (though fun to look at) was a pain to try to follow.

I therefore created a brand new version of the repo. In the new one, I'm structuring things a bit differently. Rather than trying to keep one branch going, I'm going to have multiple named branches.

The first one is default, or the comm-central import. The tip of the default branch is the tip of comm-central when I imported that.

One set of branches is the experimental let's-add-new-address-book-type branches. I already have a prototype SQL AB developement branch, sqlab. When I start experimenting with Evolution support, there will be an evolutionab branch. And so forth and so on. If you have custom AB types that you want to publish, email me a bundle and you'll get your very own named branch in this repo (for as long as it exists).

Another set of branches is the bugs I'll be working on. These branches will tangle around each other as a fix one bug or another, since some bugs depend on other bugs. I'll try to keep a last-idl tag up-to-date such that any changes on a branch after the last branch point or this tag (which ever comes later) do not change any IDL files.

Debugging palmsync

Also known as "An Exercise in Frustration and Self-Torture." As part of preliminary work for mailing list sanity, I need to make some changes to palmsync. It's not like I haven't changed this code before, but the work I need to do here is more than a simple s/a/b/g command. So, time to fire up the 'ole Windows partition and test.

Pain point number one: trying to get necessary stuff to work. First you need the Palm CDK. After getting that (complete with throw-away email account), you now need something to test the other end of palmsync—the PDA. Back at home, I have a monstrously old PDA whose functioning I would not guarantee. Fortunately, there's a nice palm emulator which I can install.

Now I just needed to Hotsync. Another non-trivial task, as my computer does not have two serial ports between which I could slap a cable (it doesn't even have one serial port…). After figuring that part out comes another problem. The palmsync failed to register. "No problem," I say, "I'll just reinstall it." And it still fails. Turns out that the necessary registry key used %ProgramFiles%. Don't you just love the registry?

That's all set up, so I click the sync button and… it fails. That wouldn't seem to be a problem, as I've already had to diagnose many errors to get to this point. Except I seem to have hit the critical unsupported limit:

• I'm using a custom-built version of a program (that's really not saying much, though)
• Said program is built with a technically unsupported compiler (VC 7.1)…
• …which is unsupported on my OS (Windows Vista)…
• …using and old SDK (Windows 2000)…
• …and it's a 32-bit on a 64-bit machine.
• The emulator officially supports neither Vista…
• …nor a 64-bit machine.
• Hotsync doesn't officially support the 64-bit machine either.

Debugging this proved to be a pain. The conduit logs didn't seem to function. Trying to get the VS debugger's nose in there proved a futile task until I did a world rebuild. Which takes 5.5 hours on my system (blame ext3). I finally got the debugger in, only to find a barrier thanks to COM. Some more work managed to shove the debugger in there and finally allowed me to pinpoint the error. Sorry, errors. Suffice to say that it's a mess in there.

So how did I get palmsync under the debugger? First off, let me describe my VS setup: I have mailnews as a project in VS (an NMake project, to be precise), set up such that clicking the build button actually builds in the mailnews directory (thanks to some custom hacking around msys). Based off of some external documentation for debugging Palm conduits, I created a new configuration (called "Palmsync," imaginative little me) whose command ran the hotsync program with -ic as its sole argument. Popping that under the debugger the normal way in VS allowed me to break on Palm's side of the conduit. On the Mozilla side, debugging is done by firing up an instance of TB under the debugger like normal, initiating the hotsync, and breaking and debugging as normal.

Modulo the fact that palmsync is in reality extremely fragile and apparently too buggy to support my nearly-empty testing profiling, it works now. Time to fix some more old bugs solely to be able to get to the point where I can work on the preliminary work for mailing list sanity.