Monday, November 16, 2009

Delta is my friend

I think it was a couple years ago when working for the CLR and running into what appeared to be a compiler issue in a newer version of gcc. Zipping up the entire enlistment and shipping it to Apple would have been a rube mistake: (1) Microsoft doesn’t really want its source disseminated unnecessarily, even if the partners have a limited non-disclosure agreement. (2) Even the youngest tester knows the mantra: get a small, simple repro.

Suffice it to say that our source code is rather complex (and probably a small factor more than it need be). Generating a giant .ii file and then culling it manually to keep the reproduction while shedding intellectual property is a soul crushing problem. You can make some educated guesses at what is causing the compiler to behave oddly, but sometimes those guesses are ill-founded, and there’s no easy way to get to minimal repro.

Enter Delta, which Mike Stump of Apple pointed out to me. It takes the tedium out of reducing the reproduction down to a minimal one, making the obfuscation/renaming process usually much easier (unless something about the names themselves are problematic).

You start with your giant reproduction: g++ flags flags flags -c file.ii, where file.ii is the preprocessed version of your source (i.e., replacing the “-c” with “-E” at the gcc line). In our cases, this can be something like 1.8 MB of text file. You then write a simple “interestingness” decider script, e.g., that gcc succeeds in compiling the source, but that the output contains a particular warning. Then you run Delta in several iterations, and it selectively removes parts of the source file, tests the file for (continued) interestingness, and if it is still interesting, it caches the smaller result, and keeps going, looking for more text it can remove and still have the repro intact. Several hours later (of the computer’s time rather than your own), it can knock the size down to a few K of text, and then the whole problem becomes much more tractable.

I’ve probably had to post only six or so bugs that fell into this category, but Delta has saved me tremendous time and effort.

Getting background pictures on disk images to “stick”

As a part of working on an installer for TeachTown, I ran into a problem where we were trying to make an automated build process for the installer and making a nice disk image for the installer: the process of assigning a background image via AppleScript would work in the moment, but after you hdituil detached the image, it would vanish. e.g.,
osascript -e 'tell app "Finder" to set background picture of icon view options of container window of disk "disk_name" to POSIX file "full_path_to_image_file_on_disk_image"'
hdituil detach /Volumes/disk_name

We found that running sync wouldn’t help, but that if we waited a while (e.g., sleep 5), it would usually “take.” Well, Apple replied with the Magic™: The Finder doesn’t commit the changes made to Finder metadata immediately to disk, and whereas if you told the Finder to eject the disk, it would know better, write its metadata and then eject, but for whatever reason hdiutil detach would just unmount the disk image out from under the Finder and it wouldn’t necessarily have known to write the metadata first.

Workaround and/or fix: Use the update disk verb to force the Finder to write out the metadata. e.g.,
osascript -e 'tell app "Finder" to update disk "disk_name"'

That should make sure that background image and icon size/placement settings that you made get committed before the detach.