I just did this freehand; this was my first try. Not as hard as the instructions make it sound.

I think it’s pretty cool. Impress your nerdy friends!

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.

Create Local Portfile Repository

These instructions are based on Section 4.6 of the MacPorts Guide.

1. Create a directory that will serve as your portfile repository; I used /usr/local/ports/
2. Add this directory to your MacPorts configuration. For me, that meant editing /opt/local/etc/macports/sources.conf to add the line file:///usr/local/ports/ before the standard rsync line (for priority)
3. Update the port index. For me, I needed to run sudo portindex in /usr/local/ports/ because of the way I have permissions set.

Now, if you use any port command, it will look at your local source first.

Create a Placeholder Portfile

For this example, I’m focusing on installing the port phpmyadmin, but satisfying its runtime dependencies on MySQL and PHP using local builds.

1. Check the dependencies of your target port: port deps phpmyadmin

   phpmyadmin has runtime dependencies on:
   	mysql5
   	php5

2. For each dependency, look it up using MacPorts search, and then click on the link to view the checked-in portfile. In general this link will have the form http://trac.macports.org/browser/trunk/dports/CATEGORY/PORT/Portfile, where CATEGORY and PORT are the relevant names of the package you’re trying to replace
   • mysql5
   • php5
3. Now you need to create a local placeholder portfile for each of these packages; in the port repository you created above, you’ll need to create a subdirectory for the CATEGORY and then open a file named PORT in that directory in your favorite text editor. For example:
   • cd /usr/local/ports/
   • sudo mkdir -p databases/mysql5
   • sudo touch databases/mysql5/Portfile
   • sudo emacs databases/mysql5/Portfile
4. We only need a few variables in the portfile to trick MacPorts into accepting our dependency, some of which can be copied from the real portfile. Note that I added a mention of “placeholder” to the description, changed the version to match what I built locally (which is a newer version than what’s available in MacPorts), and added some information about the build. We also need to make MacPorts do a no-op for all port phases. Here’s what mine looks like:

   PortSystem              1.0
   name                    mysql5
   version                 5.1.30
   homepage                http://www.mysql.com/
   categories              databases
   platforms               darwin
   distname                mysql-${version}
   
   description \
       Placeholder for multithreaded SQL database server
   
   long_description \
       MySQL is an open-source, multi-threaded SQL database \
       with a command syntax very similar to mSQL. \
       \
       This is a placeholder built from source in /usr/local/src/mysql-5.1.30/ \
       on 2009.01.27 using the options:\
       \
       ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex \
       --enable-thread-safe-client --enable-local-infile --disable-shared \
       --with-unix-socket-path=/usr/local/mysql/run/mysql_socket \
       --with-mysqld-user=_mysql --disable-dependency-tracking
   
   fetch {}
   checksum {}
   extract {}
   patch {}
   configure {}
   build {}
   test {}
   destroot {}
   install {}
   activate {}

5. After creating and editing the relevant portfiles(s), you need to regenerate the portindex as above.
6. If you run port search mysql5, you’ll see both the real port and your placeholder listed with the short description, like this:

   mysql5 @5.0.83 (databases)
       Multithreaded SQL database server
   
   mysql5 @5.1.30 (databases)
       Placeholder for multithreaded SQL database server

7. If you run port info mysql5, you’ll get a warning about multiple definitions, but see the long description of your custom placeholder:

   Warning: Found 2 port mysql5 definitions, displaying first one.
   mysql5 @5.1.30 (databases)
   Variants:    universal
   
   MySQL is an open-source, multi-threaded SQL database with a command syntax very
   similar to mSQL. This is a placeholder built from source in
   /usr/local/src/mysql-5.1.30/ on 2009.01.27 using the options: ./configure
   --prefix=/usr/local/mysql --with-extra-charsets=complex
   --enable-thread-safe-client --enable-local-infile --disable-shared
   --with-unix-socket-path=/usr/local/mysql/run/mysql_socket
   --with-mysqld-user=_mysql --disable-dependency-tracking
   Homepage:    http://www.mysql.com/
   
   Platforms:            darwin

Undoing the Mess

Pretty simple. Just uninstall the placeholder you created, remove its file from your local ports, rebuild the portindex, and reinstall the “real” package (or just leave it uninstalled, depending on what you’re trying to do). Alternatively, uninstall all the placeholders you created, and remove the offending line from your sources.conf before continuing.

Conclusion

I’ve only tested this with runtime dependencies so far, not build dependencies. I think the general idea is sound, but as I said, it’s probably a terrible idea. I’m curious if you can extend this process to get any other ports to install using system or local dependencies. I’d also welcome any suggestions for a better way to achieve or similar result. Feel free to just call me misguided and mad, as well!

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.

Nostromo

First, the product itself. I have the Nostromo n52, which gives you a D-pad, 14 programmable keys, a scrollwheel, and two thumb buttons. I’ve only seriously tried configuring it for World of Warcraft (and also for Lord of the Rings Online, but I intentionally set that up to be almost identical to WoW).

Last year Belkin released the Nostromo n52te (Flash website), which as far as I can tell is the same product, costs twice as much, and has silly blue lights. Maybe they improved the “touch” of the keys, but the vanilla n52 works fine after hundreds of days of playtime (although the key labels have all worn off).

The Nostromo works with both PC and Mac, and the Mac software is one of the better ones for third-party peripherals; it’s implemented as a System Preferences pane, which is the “right” way of doing this sort of thing on a Mac (as opposed to a standalone application). Here’s what configuring it looks like on a Mac:

Configuring the Nostromo n52 on Mac OS X

Pretty straight-forward; you select the key on the Nostromo you want to configure, and then you can select a wide variety of actions (and add modifiers). I haven’t ever used any of the “turbo” functionality, I treat them all as normal keys, with the exception of the Shift buttons.

Here’s how configuring the Nostromo looks on Windows (and how it looked on the Mac before they wrote new drivers, as opposed to just porting the Windows ones):

Configuring the Nostromo n52 on Windows 7

The same functionality, but the “cool looking” but non-standard UI I find a bit confusing. Both the Mac and Windows versions support some of the other Nostromo series products. The Windows version is a bit better at saving profiles for export; as far as I know, the current Mac version can’t do this (unless you want to dig around in OS X plist files).

Shifting is one of the really cool capabilities of the Nostromo: while there are only a few physical buttons, if you assign 3 of them to Red Shift, Blue Shift, and Green Shift, you effectively quadruple your available buttons (I definitely don’t use that many), as long as you’re willing to press multiple keys at once. This is usually called “chording”, and at this point it’s very well embedded in my muscle memory, as you’ll see below. This is what really gives you “speed at your fingertips” or whatever they put in the marketing literature – with only a few movements of your left hand, you basically get as many keybindings as a standard keyboard.

n52 Keybindings

As you can see below, I use the D-pad for strafe-based movement, since I use mouse turning. The orange button near the D-pad is hard to use with the D-pad, so I just use it as an auto-run toggle. The six buttons in the upper right are associated with the active action bar; either 1-6 or 7-12, depending on whether or not I’m red shifted. The mousewheel is used for applying target markers (skull, X, etc.). Most of the keys on the left periphery are lower priority things, since they’re hit by my pinky or by an extension of one of my other fingers.

The main functionality is with that block of 6 keys. Between the red shift on my thumb (button 15, below the D-pad), and shift (the literal keyboard key) on Button 11, in the lower left for my pinky, I can select any of my character’s actions with a three-fingered cord. Since I organize my action buttons in-game carefully (see the next section), most of my fast in-combat actions can be achieved by mashing one key with the relevant finger, possibly while pressing my thumb. I can press my thumb on the red shift key while using the D-pad to move, although in highly mobile fights I’m likely to use a combination of autorun and mouse movement.

Also, these bindings should be perfectly valid for a newer Nostromo n52te.

The other keybindings are pretty boring: they open the character pane, my current favorite map mod, or my bag management mod. Green shift and Blue Shift are largely unused, although they focus on modifying the core 6 buttons; Green lets me target party members (function keys), including myself (I mostly rely on Grid and mouseover macros these days); Blue lets me activate pet/vehicle abilities (control + number keys).

Blue shift also modifies some other actions, such as making the D-pad turn instead of strafe, or making my flying mount go down instead of up (note that x and space are assigned to the same button, just shifted). There’s a lot of room for expansion, and the configuration is admittedly a bit haphazard… but I’ve been using it for over 2 years, so I’m very used to it. It’s all in muscle memory, and I can react very quickly to most in-game events without moving my hands at all (I use a Logitech Cordless TrackMan® Optical in my right hand).

WoW Keybindings

If it wasn’t obvious to most WoW players based on the bindings listed above, I keep the in-game keybindings set almost exclusively to the defaults (with the exception of a few additions, or tweaks to use particular mods in place of some default UI components). I also use only the default action bar; the shift-# bindings above select one of the six default action bar “pages”, and then 1 through = on the number row activate an action on the current bar. Thus my Nostromo configuration depends heavily on my bar configuration, since I memorize it

Without going into detail at the level of specific class abilities, here’s how I break down the six action bars:

1. Primary abilities: attacks, anything with a short cooldown; in the case of my healers, geared towards soloing.
2. Panic buttons: potions, trinkets, class abilities like Evasion and Desperate Prayer
3. Secondary abilities: longer cooldown combat abilities; in the case of my healers, mouseover macros for their various group healing and cleansing spells
4. Crafting: maybe silly to have a whole bar dedicated, but I don’t otherwise need the space
5. Transportation: mounts, pets, and usable quest items
6. Buffs: poison hotkeys on my rogue, blessings on my Paladin, etc.

I’m admittedly not 100% consistent in this, but that’s the general idea. Because of where 1 and 2 are bound on the Nostromo, the most important bars are under my pointer finger; similarly, within each bar (and related to the core 6 keys above when combined with Red Shift), the most important abilities are in slots 1, 2, 7, and 8, because these are again under my pointer finger.

Maybe a full description of my UI configuration, including button bar breakdowns by class, can come in a future post; the main takeaway from all of this is that I try very hard to keep things similar across characters, so my muscle memory doesn’t have to relearn much as I switch between the different roles on my various alts. Feel free to suggest any tweaks to this!

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.

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.

Dependencies

Here’s a simple tree view of the package dependencies, followed by the order in which we’ll be compiling packages, with links to the relevant download sites. I’m assuming that all source tarballs have been expanded in /usr/local/src/, but obviously any prefix will do. I’m not listing any included packages; pretty much everything here depends on the custom build of the Python Framework. I also assume you have the Developer Tools isntalled from your Leopard DVDs.

• mod_python
  • Python
  • Django
    • setuptools
    • MySQLdb
      • MySQL
  • python-twitter
    • simplejson

Click the package name to jump to the step in the instructions. Click the package version to download the source. (If you’re wondering why most Python packages are being built from source instead of eggs, it’s because there aren’t Python 2.6 eggs available for a lot of packages yet.)

1. MySQL 5.1.30
2. Python 2.6.1
3. setuptools 0.6c9-py2.6
4. MySQL-python 1.2.2
5. Django 1.0.2-final
6. simplejson 2.0.7
7. python-twitter 0.5
8. mod_python 3.3.1

Tips

In the sections below, you’ll see shell commands in <blockquote>s, one per line. If your browser and your shell cooperate, you should be able to copy-paste these without getting extraneous line breaks; just eyeball everything before you hit return. Triple-click to select the line should work.

If you’re unsure of whether or not you’re actually compiling as universal binaries, just use the file command to check what’s contained in a binary file. You should get five lines of output listing all four architectures, like this:

% file /usr/libexec/apache2/mod_python.so
/usr/libexec/apache2/mod_python.so: Mach-O universal binary with 4 architectures
/usr/libexec/apache2/mod_python.so (for architecture i386): Mach-O bundle i386
/usr/libexec/apache2/mod_python.so (for architecture x86_64): Mach-O 64-bit bundle x86_64
/usr/libexec/apache2/mod_python.so (for architecture ppc): Mach-O bundle ppc
/usr/libexec/apache2/mod_python.so (for architecture ppc64): Mach-O 64-bit bundle ppc64


Compilation

MySQL

One huge caveat for this step: I compiled MySQL from source over a year ago, and I don’t remember exactly what I did. I just reused the same ./configure line that I had cached in an old config.log. The addition of multiple -arch flags initially caused a problem with running the preprocessor, but Marc Liyanage proved to once again be a great resource explaining the need for the --disable-dependency-tracking flag.

If you’re replacing an existing MySQL configuration, it wouldn’t hurt to have some sort of backup of your databases. I had no problems installing, and then killing mysqld. It restarted automagically as a 64-bit process.

cd /usr/local/src/mysql-5.1.30/

MACOSX_DEPLOYMENT_TARGET=10.5 CFLAGS='-arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' LDFLAGS='-arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' CXXFLAGS='-arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared --with-unix-socket-path=/usr/local/mysql/run/mysql_socket --with-mysqld-user=_mysql --disable-dependency-tracking

make all

make test

sudo make install

Note the four architecture flags set for all compiler and linker options; you’ll see those a lot throughout this post. I only allow local connections to MySQL, hence the socket path; you may use different depending on your configuration.

Python

While python.org provides a nice OS X Installer package for 2.6.1, it is compiled as a 32-bit “fat” binary, which doesn’t help us address the Universality problem. We’ll use their script for generating a package as well as installing the framework directly, after some minor changes, courtesy this mailing list post by Ned Deily.

If you’re feeling particularly trustworthy, you can download the disk image containing the Installer package that I built from my website. If not, you can make the changes yourself. Either way, Python.framework will be installed in /Library/Frameworks/.

In the Python 2.6.1 source directory, open the file Mac/BuildScript/build-installer.py in your favorite editor, and make the following changes on lines 1, 65, 68, 71, 633, and 1020:

1c1
< #!/usr/bin/python2.3
---
> #!/usr/bin/python
65c65
< DEPSRC = os.path.expanduser('~/Universal/other-sources')
---
> #DEPSRC = os.path.expanduser('~/Universal/other-sources')
68c68
< SDKPATH = "/Developer/SDKs/MacOSX10.4u.sdk"
---
> SDKPATH = "/Developer/SDKs/MacOSX10.5.sdk"
71c71
< ARCHLIST = ('i386', 'ppc',)
---
> ARCHLIST = ('i386', 'ppc', 'x86_64', 'ppc64')
633c633
< runCommand("%s -C --enable-framework --enable-universalsdk=%s LDFLAGS='-g -L%s/libraries/usr/local/lib' OPT='-g -O3 -I%s/libraries/usr/local/include' 2>&1"%(
---
> runCommand("%s -C --enable-framework --enable-universalsdk=%s --with-universal-archs=all LDFLAGS='-g -L%s/libraries/usr/local/lib' OPT='-g -O3 -I%s/libraries/usr/local/include' 2>&1"%(
1020c1020
< os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.3'
---
> os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.5'


You’ll note that some of the changes migrate this script to 10.5 (the hashbang path to Python, the deployment target and SDK version), and some of the changes add support for a Universal binary (adding to the architecture list. It’s possible that some of these changes will be fixed in a future source release of Python 2.6, but I’d guess that most efforts are focused on Python 3.0 at this point.

Once you’ve made the changes, just run the script. You need to be in the BuildScript subdirectory, unless you want to change some of the tmp paths the script uses. This script will do everything, build the framework, download and build any dependencies, install the framework, and generate a disk image. Just sit back and wait!

cd /usr/local/src/Python-2.6.1/Mac/BuildScript/

./build-installer.py


Depending on your shell configuration, you may need to make changes. In my $PATH /usr/local/bin/ trumps /usr/bin/, and I want to keep the Leopard system install of Python 2.5 in place in /System/Library/ and /usr/bin/. Here’s what I did:

cd /usr/local/bin/

for py in `find /Library/Frameworks/Python.framework/Versions/2.6/bin -name py*`; do ln -s $py; done;

This creates a symlink in /usr/local/bin/ for each of the various just-build Python binaries inside the framework (you’ll not that this is equivalent to the system install). If you run which python now, it should return /usr/local/bin/python. If not, adjust your $PATH as needed in your shell configuration file. This is beyond the scope of this post.

setuptools

This one is easy. Just execute the downloaded egg file as a shell script to add setuptools to your shiny new Python installation:

cd /usr/local/src/

sh setuptools-0.6c9-py2.6.egg

MySQL-python

MySQL-python installs using setuptools, as with most Python packages these days; however, we’ll need to make a few changes to get the C part of the extension to compile on OS X. I followed mickeyckm’s guide over at MangoOrange, which I’ve modified here to support all four architectures after looking at suggestions from Geert on the Python mailing list. Note that his manual compilation step isn’t necessary, from what I can tell.

First, you’ll need to modify site.cfg to point to the custom build of MySQL we created above; just uncomment and change the value of mysql_config on line 13 to match its actual install path as follows:

13c13
< #mysql_config = /usr/local/bin/mysql_config
---
> mysql_config = /usr/local/mysql/bin/mysql_config


The setup script for MySQL-python uses this tool to retrieve the compilation flags used with MySQL; since we built our own, this will automatically have all four architecture flags. You can run mysql_config directly and view the output if you don’t believe me.

Next, we need to make a small correction to _mysql.c in order to avoid a type conflict on OS X by deleting lines 37-39 and replacing uint with unsigned int on lines 484 and 485:

37,39d36
< #ifndef uint
< #define uint unsigned int
< #endif
484,485c481,482
< uint port = MYSQL_PORT;
< uint client_flag = 0;
---
> unsigned int port = MYSQL_PORT;
> unsigned int client_flag = 0;


Now we’re ready to build and install. Just run the standard setuptools procedure:

cd /usr/local/src/MySQL-python-1.2.2/

python setup.py build

sudo python setup.py install

Django

No special instructions here. Just run the standard setuptools procedure:

cd /usr/local/src/Django-1.0.2-final/

python setup.py build

sudo python setup.py install

simplejson

No special instructions here either. Just run the standard setuptools procedure:

cd /usr/local/src/simplejson-2.0.7/

python setup.py build

python setup.py test

sudo python setup.py install

python-twitter

Don’t you love it when how-tos get easier as you go along? Just run the standard setuptools procedure:

cd /usr/local/src/python-twitter-0.5/

python setup.py build

sudo python setup.py install

mod_python

Sadly, we end with some pain. Long story short, mod_python relies on apxs (the APache eXtenSion tool, best abbreviation ever) to configure its build, and does not obey any amount of environment variable manipulation to pass in multiple architectures. apxs retrieves useful compiler options, apparently based on the ones used to build your local copy apache… and herein lies the problem. apxs reads those flags from /usr/share/httpd/build/config_vars.mk, and if you inspect that file, you’ll see that there are no CFLAGS or LDFLAGS specified. This is particularly odd, considering that httpd is clearly running as a 64-bit process (according to Activity Monitor), and file reports that all of my other shared objects in /usr/libexec/apache2/ are Universal binaries.

This next bit is my idea, since I couldn’t find any suggestions by googling around. I know perl, so I just read the apxs script to figure out what it was doing, and how it was passing arguments to libtool.

This is probably a terrible idea.

Make a backup of config_vars.mk before adding the four architecture flags to CFLAGS and LDFLAGS on lines 59 and 62:

59c59
< CFLAGS =
---
> CFLAGS = -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64
62c62
< LDFLAGS =
---
> LDFLAGS = -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64


If you run apxs -q CFLAGS or apxs -q LDFLAGS, you’ll see these values, instead of empty strings.

Now just run the standard autoconf procedure to build and  install mod_python.so in /usr/libexec/apache2/:

cd /usr/local/src/mod_python-3.3.1/

./configure

make

cd test

python test.py

cd ..

make

sudo make install

Conclusion

At this point, you need to enable mod_python in your httpd.conf. If you passed the tests for it above, you shouldn’t need to worry about module issues, just double-check your configuration with sudo apachectl -t. When you’re ready to go, sudo apachectl restart, and welcome to the world of 64-bit.

If you have corrections to any of this, or need assistance, feel free to comment and I’ll try to get back to you with suggestions and/or edits.

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.

Setup

Install Git

You’ll only need to do these steps once on your development machine.

1. Get git
   1. If you don’t have it archived, get the latest version of Cygwin’s setup.exe.
   2. Run setup.exe, accept the cached repository and install locations
   3. Find git in the list (in category Devel), and set it to install
   4. Accept and finish the Cygwin incremental install
2. Configure git
   1. Open a Cygwin shell
   2. Run these git setup commands to set authorship:

   $ git config --global user.name "Your Name"
$ git config --global user.email "yname@you.com"

   3. Run these git setup commands to avoid choking on Windows newlines

   $ git config --global core.autocrlf true

Create Git Repository

You’ll do this once for each working directory you create as per above. The commands below assume that you’re working in c:/Projects/HelloWorld/.

1. Create Repository

$ cd c:/Projects/
$ mkdir HelloWorld
$ cd HelloWorld
$ git init
Initialized empty Git repository in c:/Projects/HelloWorld/.git/

2. Configure Repository
   1. Tell git to ignore certain Visual Studio/SourceSafe files that change constantly

   $ echo -e "*.user\n*.ncb\n*.suo" >> .git/info/exclude

   2. See man git-config for more options
3. Initial check-in
   1. Tell git which files you’re checking in

   $ git add <project subdirs>

   2. Commit all files (this may take a minute or two)

   $ git commit -m "Initial check-in"

Usage

This section is divided into common operations. One important note: the commands can be run from any subdirectory of the repository you created above, but most operations apply to the entire tree. The git manpages are excellent, and can explain further. There are a ton of options, but these get at the core functionality you’re likely to use working on most codebases.

View Changes

There are two commands useful here:
$ git status
$ git diff
One conceptual caveat: files that are pending a commit get added to the repository’s index. They’ll be listed in the status, but won’t appear in diffs. Be especially careful about using wildcards with the add command, because you generally don’t want to commit binaries or intermediate build files.

status will tell you which branch you are on, which files have been added to the index but not yet commited, which files have changed since the last commit but haven’t been added to the index, and which files aren’t being tracked by git. New files you create will appear in this list, among build directories you’re probably ignoring. For each file it will tell you if it’s been added, deleted, or modified.

diff will pass the output of diff for each file that has changed since the last commit but hasn’t been added yet to the index. This is a very detailed view, I generally use this to make sure that I’ve added everything I want before committing.

Commit Changes

This is one of the big advantages to local version control: you can commit after even the most trivial change, at least once you’re sure it works.

There are two commands that you’ll use for this process:
 $ git add <file/dir to add> ...
 $ git commit -m "Message for log"
Be very careful specifying directories when adding; git will add any unknown file contained in all subdirectories, which might end up adding a bunch of build files you don’t want.

In general, I use status and diff (described under View Changes above) to see what I’ve changed since the last commit, and to make sure I’ve added everything relevant before committing.

Tag

By default, tagging always applies to the most recent commit. If you have uncommitted changes, they won’t be under the tag. Tags can’t have spaces.

The usage is simple:
 $ git tag -m "Message for log" "my-tag-name"

Move/Rename/Delete Files

It is very important that you never use rm or mv inside of a git repository, because git is likely to get confused about what happened to the files. This includes renaming files inside of Visual Studio, since VS2005 effectively performs a mv behind the scenes. It’s not the end of the world if you do it, you just clobber the file history (git sees it as a delete followed by an unrelated create).

The commands for doing this are:
 $ git rm <file to remove> ...
 $ git mv <source path> <destination path>
They otherwise work exactly like the shell command, they just inform the repository of the change. The changes are automatically added to the index, ready for committing; if you further change a moved file, you’ll still need to add it from its new location.

Use Branches

Let’s say you’re trying out some new functionality, but it’s just not going anywhere. Maybe you’re adding some new functionality, but you need to hop back to the last working commit to build but you don’t want to lose your work. These are just a few of the cases where you might want to branch. You can also branch preemptively.

• Create a new branch to contain current/future changes

$ git checkout -b <branch name>
(edit file, if necessary)
$ git add <broken files>
$ git commit -m "Stuff I broke"

• Switch between branches (this will replace files, make sure your changes are committed to the correct branch)

$ git checkout master
(in master branch)
$ git checkout experimental
(in experimental branch)

• List all branches (* indicates current branch)

$ git branch
  experimental
* master

• There are two ways to delete a branch:
  • -d makes sure that the changes have been committed to the master branch
  • -D just nukes the entire branch and all of its changes, committed or not

  $ git branch -d <branch name>
$ git branch -D <branch name>

• Merging between branches is also easy:

$ git checkout target
(in target branch)
$ git merge source
(all non-conflicting commits from source will be added to target)

Sharing Repositories

Just make your working directory accessible as a shared folder, and another person on the network can get your complete working tree (with commit history and branches) by creating a new repository and pulling from your repository.
$ cd c:/Projects
$ mkdir HelloWorld
$ cd HelloWorld
$ git init
$ git pull //yourcomputer/Projects/HelloWorld/

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.