I've been having trouble getting PVM 3.4.5 to install under MacPorts on Leopard. The conf/DARWIN.def configuration file defines the FAKEXDRFLOAT preprocessor symbol; it may be needed for OS X 10.4, but it causes a compiler error w. GCC 4.0.1 under 10.5:

I'm not using it on any projects involving multiple people. All of my employer's code still lives in subversion repositories.

Rather, I'm using bzr for local, lightweight revision control. It sure is nice to be able to go into a directory tree where I'm whanging together a prototype, or where I'm working up some documentation; and to say

$ bzr init$ bzr add .$ bzr commit -m "New repository"'

And bingo, I can make changes and back out of them at will, with little fear of trashing anything. And of course, for technical writing it's nice to be able to refer to old revisions.

Lately I've started fiddling around w. bzr branch, building prototype web servers in one directory tree and occasionally pulling them out to a "deployment" branch. This feels a little more like working with subversion, but bzr lets me make local "checkpoint" commits, where some things are broken, without fear of breaking the build.

At this point my only problem with bzr is that I don't quite grok what's going on under the hood. Distinctions between branches and checkouts seem clear enough. But I don't understand why, when I commit from a "checkout" workspace, a subsequent bzr status in the source workspace will tell me that my workspace is out of date; whereas a similar sequence of actions from a "branch" workspace -- a commit followed by a push, followed by a status in the target workspace -- offers no warning that the code has been updated.

Given some time and experience these confusing behaviors should make more sense. Meanwhile, it sure is nice having cheap, local revision control. Kinda like XCode 3's Project Snapshots, but without the XCode :)

Last week's sojourn with Leopard gave me a chance to learn about some new ways of performing common system administration tasks. I've already written about using iCal in place of cron. I also had a chance to get acquainted with launchctl.

I have some custom web app servers which need to launch at system startup, and which need to be restarted if they fail. (I guess I could launch them from within Apache...)

The last time I needed to launch anything at system startup on OS X, /Library/StartupItems was in vogue. It's still usable, but now launchctl and /Library/LaunchDaemons et al are recommended in its place. As the launchd man page states:

In Darwin it is preferable to have your daemon launch via launchd instead of modifying rc or creating a SystemStarter Startup Item.

At some point my web apps may be deployed on Linux. So instead of going all the way with launchctl I decided to introduce supervisor into the mix: use launchctl to keep supervisor running, and use supervisor to keep the custom services running.

Of course this is a stupid thing to do. Both launchctl and supervisor are intended for the same types of problems. But supervisor will be available on Linux whereas, presumably, launchd will not. This is as good a place as any to learn how to use supervisor.

This script is installed as /Library/LaunchDaemons/com.agendaless.supervisord.plist. As the launchctl.plist man page says, that's the place for "System wide daemons provided by the administrator."

Both the name of the plist file and the value of the Label are based on the domain of the copyright owner for supervisor: http://www.agendaless.com/

The ProgramArguments consist solely of the path to the supervisord executable.

RunAtLoad ensures that supervisor is started as soon as it is loaded.

Setting Debug to true increases the odds that, if some problem arises in running supervisor, the problem will be noted in the system log.

Finally, KeepAlive ensures that, if supervisor dies, it will be restarted. (KeepAlive is not documented in the OS X 10.4 man pages; it may make sense only for OS X 10.5. I need to re-read the blog where I saw it mentioned to better understand its intended use.)

I'm still such a novice with supervisor (not to mention launchctl) that I'm not sure supervisor meets the expectations of launchctl. But in any case, the above seems to work.

Just after returning from Christmas vacation my iMac (Intel Core Duo 1.83GHz, 17") started showing spinning beachballs. And the system log started accumulating error messages similar to those described on this blog. The hard drive was dying.

Luckily I'd run a SuperDuper backup the night before starting vacation.

It was also lucky that I had an early-model Intel iMac. Supposedly newer models are much harder for amateurs to service.

Thank goodness for John Wood's iMac_Disassembly web page. If it weren't for him I'd either be running from an external hard drive right now or shipping the iMac off for a very expensive (not under AppleCare) repair.

Using the photos and instructions on the disassembly page I was able to swap out the failed 160GB Seagate Barracuda 7200.7 for a 320GB Western Digital WD3200AAJS, purchased from NewEgg. Required tools:

A #0 Phillips screwdriver for the memory slot cover

A T-8 Torx driver for the top case

A small Allen wrench (not sure about the size) for the screws securing the LCD panel to the back case

A sharp knife and a spot of rubber cement for moving the temperature sensor to the new drive

The whole job took about an hour and a half, not because it was difficult, but because I am a coward :)

There were two minor differences between my iMac and the one Mr. Woods took apart. Mine had two "hooks" at the top of the front plate, and I bent one of them slightly before discovering it was there. And in addition to the black tape overlying the sides and bottom of the LCD panel, I had perforated foil tape running along the top edge.

Everything's up and running again, and now I have lots of free disk space :) Time to do another backup. Of course in the meantime I've been doing development under Leopard on the MacBook; so it's tempting to follow that backup with an archive-and-install of 10.5 onto the iMac...

The man pages didn't say anything about these @ characters. Google was no help since it ignores punctuation characters like "@".

Eventually I realized that, since I had done an "upgrade" installation of Leopard, my man pages might be out of date. Indeed they are: Apple's online man pages explain @ and much else that's new in the ls command:

If the file or directory has extended attributes, the permissions field printed by the -l option is followed by a '@' character. Otherwise, if the file or directory has extended security information, the permissions field printed by the -l option is followed by a '+' character.

And

The following options are available: -@ Display extended attribute keys and sizes in long (-l) output.

Luckily, the osacompile command lets you do the same thing from the command line. Together with Python's pathname-manipulation facilities, osacompile makes it simple to create AppleScript wrappers for shell scripts.

Given the path to a shell script, the following Python program creates a corresponding AppleScript wrapper in the same directory:

And here are the bindings I'm currently using in my ~/Library/KeyBindings/DefaultKeyBinding.dict file. Basically they cause the "Home" and "End" keys on the Apple keyboard to move the cursor to the beginning and end of the current text line. Hitting these keys while holding "Shift" will also select all text covered by the move. And the page up/down keys do what you'd expect.

These days I'm learning how to work with some new (to me) Java cheminformatics toolkits. Google, Jython 2.2.1, and VoodooPad are helping me get up to speed:

Google to find the documentation for the Java APIs

Jython to learn API nuances without an edit/compile/test cycle

VoodooPad as a scratchpad for sample scripts -- it's easy to save them in pages that sit alongside my worklog

During initial exploration I just bang up the script in VoodooPad, then repeatedly select all (Cmd-A), copy (Cmd-C), switch to a Terminal session running Jython (Cmd-Tab), and paste (Cmd-V).

The "learnings" are going into proper Jython scripts maintained with TextMate.

It's nice to be able to deploy using Jython instead of pure Java. Since almost all of the heavy lifting is being done inside the cheminformatics jars, I don't need to worry about the overhead of running a Python interpreter inside a JVM...

Here's a simple example using CDK, to transform an SD string into a SMILES string.

See here for the full discussion. The upshot is that, if you are storing string data into an SQLite3 database via Python, and if you suspect that the data may contain non-ASCII characters, you need to ensure that it's properly converted to (Python) Unicode before inserting.