Via JWZ’s LiveJournal I found a method for slicing a bagel into two linked halves. I decided to try it. Video below the cut.

Continue Reading »

Introduction

Like many Unix geeks, I have software installed that I’ve built manually from source. A good example is my post on compiling django; a number of the relevant dependencies were built in /usr/local/src/ and installed in /usr/local/. I also like using package managers, because if I’m not doing any customization (and the package is common and not hard-to-find), I want to just get the latest version and slap it in the right place. The conflict between the two methodologies is when a managed package depends on software that is already installed on your system, either part of the default configuration (OS X ships with a fair bit of Unixy software included, especially if you install the Dev Tools, although not always a “standard” or particularly recent version) or custom-built.

I recently dumped Fink for MacPorts; while I’ve used Fink for a long time, since an early version was available for Mac OS 10.2 Jaguar in fact, it’s just gotten in a messy state maintenance-wise. I’ve been familiar with apt since using Debian-based systems at the SCCS, but the mish-mash of binary and source items, the preponderance of out-of-date packages, and the apparent need to install 70 metric boatloads of GNOME just to satisfy a few dependencies was frustrating. Of course, MacPorts has its own weaknesses, as do almost all package managers; in particular, none of them seem to be able to track whether a package was installed explicitly by the user or merely to satisfy a dependency. My opinion is that the latter should get uninstalled when all of its dependents are uninstalled, but no package manager seems to agree with me on that. A rant on that probably merits a separate post.

Below the cut is a rough step-by-step guide to creating a local portindex and creating portfiles for your manual dependencies. Note that most MacPorts users would tell you this is a terrible idea, and you should just install all the port dependencies, but I already put the effort into these custom from-source builds and I just want to use them without duplicates getting dropped all over my hard drive.

Continue Reading »

Introduction

As you may have gathered, I have a… healthy… relationship with everyone’s favorite MMO, World of Warcraft. I forget who originally planted the idea in my head (there’s a good chance it was Lilboo, formerly of the Daring Blades on Kirin Tor), but I decided that I wanted a dedicated game controller that was more than just the keyboard; there’s just too much going on in WoW for an FPS-like control layout, in my opinion. I settled on a Nostromo, and after a few weeks of adjusting, and very few changes to my bindings, I have gotten very used to what may be a very unusual control style.

Verbose explanation of how I use the device below the cut.

Continue Reading »

Introduction

A coworker of mine gave me some live yeast bread starter two weekends ago, and I have proceeded to actually bake it into bread. This is, believe me, quite out of character. I am posting this recipe here (which, as far as I know, is relatively useless without the culture) both for my records and so I have a place to point people who need the recipe and may not want a printed copy, perhaps because they are, like me, allergic to paper.

If you live in Boston, I’m happy to provide you with some starter for free (I hear it’s like a cult); I’ll have 3-4 become available every week and a half or so.

I don’t know the origin of the recipe; Liz gave me a photocopied sheet with no authorship information. I’ll try to find out. I’ve made a few minor edits for my own clarification.

I’m also open to suggestions on a means of distribution other than plastic gallon ziploc bags; while they have the advantage of being air tight, and clearly indicating when the bag needs to be squeezed, it seems like a waste of plastic. I am reusing the ones I’ve received, and the ones I’m keeping for my own permanent starter, but it seems like there might be a better way.

Caveats

• Do NOT refrigerate the mixture (this will kill the yeast)
• Air formation in the bag is normal (a byproduct of fermentation)
• “Squeeze” means let the air out, and mix the starter a bit by squishing

Schedule

For each day, from the date marked on the starter, do the listed step:

1. Nothing
2. Squeeze
3. Squeeze
4. Squeeze
5. Squeeze
6. Add 1 cup flour, 1 cup sugar, and 1 cup milk. Squeeze.
7. Squeeze
8. Squeeze
9. Squeeze
10. Bake!

Baking

In a large bowl, combine the batter with 1 cup flour, 1 cup sugar, and 1 cup milk. Mix.

Partition 1 cup of starter into four 1 gallon ziploc bags. Pass along to friends and family, along with a copy of these instructions or a link to this blog post: http://blog.ultranurd.net/2009/03/15/amish-cinnamon-bread/

Add to the remaining batter in the bowl:

• 2 cups flour
• 1 1/2 tsp baking powder
• 1/2 tsp baking soda
• 1/2 tsp salt
• 1 tsp cinnamon
• 2 small boxes instant vanilla pudding
• 1 cup sugar
• 1 cup oil
• 1 tsp vanilla extract
• 3 large eggs
• 1/2 cup milk

Mix well.

In another bowl, mix 1 tsp cinnamon and 2 tsp sugar (or just use cinnamon-sugar if you have it). Sprinkle this into the bottom of two well-greased bread pans, then add the batter.

Bake the loaves at 325° for 1 hour, or until a toothpick inserted into the center comes out clean.

Introduction

This post is a guide for building your own version of Apache’s mod_python as a Universal Binary in order to support a custom Django install containing the Twitter libraries. As you can probably gather, this information is likely only useful to advanced Mac users who are comfortable in Terminal with compiling and installing software from source. If you’re still interested, gird your loins, crack your knuckles, grab some Mountain Dew, and read on.

Mac OS X 10.5 “Leopard” is yet another step forward into the world of 64-bit. At the same time, Apple has to support both PowerPC and Intel architectures. This is no mean feat, and this is where “fat” or Universal binaries come in.  Apple also has an explanation of Universal binaries, although it’s heavy on PR. This is all well and good, but there is one problem: once you make this leap, all of your library dependencies must contain the architecture you’re running as. Much software is still built as 32-bit only; while it may be a “fat” binary, containing both Intel and PowerPC machine code, it only has the 32-bit versions thereof. For reference, the names of the various architecture flags:

Huzzah naming conventions! There’s a lot of history in those names. I’ve linked to the relevant Wikipedia articles if you’re curious; these flags will be coming up again later when configuring various builds. The main thing to note is that most build configurations default to i386 on Intel Macs (even though Core 2 and Xeon processors are natively 64-bit), probably because most software is developed for 32-bit versions of Windows and Linux. As you’ll see, we’ll be overriding that default in several places to get this whole mess working.

Unfortunately, Universality is a cancer, which in my case starts with the Apple-shipped version of the Apache web server in 10.5, a universal binary. Everything it touches needs to be Universal as well, so that Apache can run as a 64-bit process by default. I wanted to add Django support on my web server via mod_python, specifically to play with the Twitter API, which meant I also needed to build python-twitter and its dependencies, as well as a MySQL python module to allow Django to talk to my database. None of these are included in the default Leopard version of Python 2.5.1.

After getting all of this set up, and trying to start my test Django app, mod_python was giving me errors about architecture. As it turns out, the included version of Python is only a “fat” 32-bit binary, not a Universal binary… which means all of the new Python modules I just compiled to support Twitter and Django were only 32-bit, which in turn means that the included Universal version of Apache and mod_python couldn’t use them. Yay.

Below the cut you’ll find my complete instructions for compiling all of the relevant components and their dependencies. I also took the opportunity to update to the latest release version of Python 2.6 and MySQL 5.1, and as a side effect my database server is now running as a 64-bit process. Progress has been made here. Feel free to comment or contact me if you have questions.

Continue Reading »

Introduction

I’ve recently become obsessed with git for version control. I know that there are many git tutorials out there; this is probably redundant, but it focuses on only the simplest operations for my own reference. The git man pages themselves are extremely well written. This post is an adaptation of an article I wrote for our department wiki, targeted at some of my fellow researchers who have probably never heard of git. I removed all of the references to our internal projects.

Unfortunately, one of our major codebases at work is stored in a Microsoft Visual SourceSafe repository; it has been for years, and there’s enough momentum that we likely won’t move to a better version control system any time soon. If the motivation sounds odd, I mostly write research code, so we are regularly creating totally new code that may be used once or twice and then never again.

Visual SourceSafe has limited branching capabilities, so many users keep large subsets of the codebase checked out onto their development machine. When a major experimental change is feature-complete, dealing with merges in VSS is a pain that typically involves face-to-face negotiations of who checks in what when, or one person spending a day or two fixing conflicts in WinMerge or a similar tool. This article demonstrates how to use git, a modern distributed version control system used by the Linux kernel (among others), to manage smaller-scale changes to VSS code trees on Windows without having to risk checking in files that “break” functionality for other users.

The main point of using a local version control repository inside of a VSS checkout is three-fold:

1. Commit more often
2. Easy branching for experimental code (whether or not it pans out)
3. More detailed history/self-documentation of recent changes

I’ve found that my development habits have gotten much better using git; in particular, I commit just about every successful compile-and-test, and I try to isolate commits by functionality as much as possible, so that it’s trivial to cherry pick experimental changes that should be kept or not.

Continue Reading »

Introduction

I generally do Big Brother on Saturday afternoons from about 2 to 6 at Patrick’s house near Central Square. Sometimes we go out for a museum (a trip to the Museum of Science is likely next week), or a movie, but this week I didn’t have any ideas. Patrick had previously showed me some YouTube videos of  water balls, and we’ve done “kitchen science” before, so I was looking into that this morning… but it looked like the listed materials would be hard to obtain, and a number of comments claimed that the video was fake. However, in the related videos, I stumbled across this page on vortex cannons, and decided that would make a fun quick activity. Unfortunately, because I’m an idiot, I didn’t take any pictures >.<.

Materials

Due to the supplies at hand, we had to use a slightly different procedure, but the visual effect was pretty impressive.

• One (1) 1-liter plastic bottle, empty and dry
• One (1) tea candle target
• One (1) fog machine
• Matches (or some other candle-lighting device)
• A room with still air

Procedure

We found two techniques worked pretty well, but produced very different results. One, when combined with the fog machine, allowed us to really visualize what was happen, and gave me the opportunity to explain some of the science to Patrick; the other actually put the candle out.

We first tried it without the fog machine, but couldn’t get the candle to blow out; it turned out that our aim was a bit off. The chemical fog stuff (part of an old Halloween setup) allowed us to actually see and aim the smoke rings, and see the vortices forming.

Grabbing the bottle with both hands and squeezing in a quick pulse produces a large, slow-moving smoke ring, with a long-lasting vortex that you can watch stretch as the ring expands. If you squeeze too hard, you just get a turbulent puff; too soft and you get nothing. It takes some trial and error. While these were nifty to look at, they couldn’t put out the candle, even from only a few centimeters away.

I found tapping one side of the bottle with just two fingertips, very firmly, produced a small but fast burst that formed a very fast-moving smoke ring. You could barely tell it was a ring at that speed. They moved fairly straight (as opposed to the slower-moving rings that tended to drift a bit), but were a bit touchy to aim. Once you connected with the candle flame, it went right out, without any guttering as you would see when trying to blow it out manually. We were able to successfully put the candle out at about a meter.

 Conclusion

This was a very fun demonstration, and only took a few minutes to set up. It also requires no cleanup, and you can hypothetically sneak up on your little sister and blow smoke rings at her. Not that I would encourage that sort of sibling mischief…

One thing I needed was a concrete example of why this is important science, and not just a toy demonstration. It’s hard to explain fluid dynamics to a ten year old. Patrick enjoyed it as a project, though.