Friday, January 18, 2008

Wham-O Co-Founder Dies

Richard Knarr, the co-founder of Wham-O, died today. Wham-O was responsible for the Hula Hoop and the Superball, and for popularizing the Frisbee.

Their first marketing idea was a slingshot; they had been using one to hurl meat to their pet falcons to train them.

Saturday, January 5, 2008

Switching Finks

One of the open-source projects I contribute to is Fink, a package manager for OS X; if you've used apt-get or yum on Linux, it provides a similar facility, allowing you to install, say, GnuPG by running fink install gnupg. It installs things into its own directory tree, rooted at /sw by default, to avoid interfering with things shipped by Apple (/, /usr) or manually installed by the user (/usr/local.) That is, if you have Fink installed, your system will have /sw/bin, /sw/lib, /sw/etc, /sw/share/man, &c.

So that you can run things installed in these nonstandard locations, Fink provides some shell commands in /sw/bin/ which edit environment variables like PATH and MANPATH to include the /sw/* directories. Most Fink users have . /sw/bin/ in their ~/.profile, so these commands will be invoked when their shell starts.

Having my shell automatically pull in Fink at startup doesn't work for me, though. It's important to me to have a clean environment available. For instance, when I'm contributing to non-Fink open-source projects, trying to help someone who doesn't have Fink installed troubleshoot something, or submitting a bug report for a program that interacts with other programs where I have the Fink version installed, but Apple ships a different version with the system. (Note that this is only an issue if program A interacts with program B by invoking it as a standalone process without using an absolute path.)

Also, as a Fink developer, I actually have multiple Fink installations at different paths, and I only want one loaded at a time; I don't want to activate /Volumes/SandBox/fink/dev-sw in an environment where /Volumes/SandBox/fink/sw has already been pulled in!

It's much easier to pull Fink stuff in later when I need it than to undo the changes that /sw/bin/ makes to my environment. My solution for making it easy to activate a particular Fink installation was to add the following to ~/.bashrc:

if [ -n "$SW" ]
    then export CFLAGS="-I$SW/include"
    export LDFLAGS="-L$SW/lib"
    export CXXFLAGS="$CFLAGS"
    export ACLOCAL_FLAGS="-I \"$SW/share/aclocal\""
    export PKG_CONFIG_PATH="$SW/lib/pkgconfig"
    export PS1="[$SW_DISPNAME \\W@$(hostname -s)]\\\$ "
    . "$SW/bin/"
    export PATH=~/bin:"$PATH"

What this does is arranges it so that if I start a new shell with SW and SW_DISPNAME set, it'll pull in the Fink installation rooted at the directory $SW and put $SW_DISPNAME in my shell prompt so that I can see which environment I'm using. The extra environment variables before . $SW/bin/ set things up so that if I compile things by hand, they'll find and link against Fink-installed libraries; the PATH setting at the end is because places the Fink bin directory at the front of the PATH, and I want my personal bin directory to come before it.

I run the following script (saved as ~/bin/finkinit) when I want to pull in Fink:



case "$FINK" in
    *) echo "Unknown fink install '$FINK'" >&2 ; exit 1

exec /bin/bash

This gives me a subshell with Fink turned on, which I can exit out of when I want to return to a clean environment. If I run it as finkinit, I get my main Fink installation, or I can run finkinit dev to get an alternate Fink.

Tuesday, January 1, 2008

For All Your Finger-Pointing Needs

While working with a large codebase, I often want to find the origin of a particular line. Subversion offers a tool, annotate (aka blame, aka praise), which displays the author and revision for every line in a file, indicating who made the last change to a line. However, the last change is often not very useful; it was a minor change as a result of some other change you're not interested in, or the code was moved around due to refactoring, and you need to go back even further.

When I need to do this, I find myself doing a sequence of:

1. svn blame FILE | less; find the revision N where the line was last changed
2. svn log -rN FILE | less; if the change is interesting, read the commit log for the file
3. svn blame FILE@N-1 | less; using Subversion's little-known pinned revision syntax, find the previous time the line was changed
4. Using N-1 as the new N, return to step 2.

: Pretty much any Subversion command that takes a path argument can be given PATH@REVISION instead to use the version of the path at a particular revision. This is great for diff and cat as well as blame. I use it for working with deleted files and branches and diffing a branch against trunk.

I've put together a rough version of a tool to make this easier; it's at /trunk/blamegame in my repository, which is here for browsing with ViewVC, or it can be checked out with svn co blamegame . It still needs some fine-tuning and documentation, but invoke it like blamegame FILE LINE (where FILE is a URL or the path to a file in a Subversion working copy) to start looking at a particular line of a file. You can navigate and search the file using a less-like interface. To drill down to the previous change to a line, hit r and then enter the line number. l, o, n, and m switch between viewing the commit log, the changed parts of the old file, the changed parts of the new file, and (the default) the diff. If you need to change the path you're looking at (for instance, to jump inside a branch), use the p command. h will show the available commands.

Let me know what you think.

Pretty Mushrooms

The Washington Post has a nifty gallery of mushroom photos by Taylor Lockwood.