Well, it’s been alright, but much to my regret the improved latency due to keystrokes only traveling around my local machine — instead of through the interweb and back as was the case with PINE on a remote machine — makes it almost justifiable. Almost.

Apple Mail makes it really easy to delete messages. You just press the “Delete” button. Poof.

Apple Mail, however, makes it a lot more difficult to SAVE messages. You have to go to the “Message” menu, then select “Move To”, then select the mailbox you want to save it in. Or use the mouse to drag-and-drop it into your mailbox of choice. But this is not acceptable as using the mouse depletes one’s indie cred even more than simply using a GUI mail client in the first place.

So, armed with James Eagan’s article on writing mailbundles I wrote a hack which adds a menu item, complete with keyboard shortcut, allowing the user to easily and quickly file one or more messages away in the “Sent” folder (*). See here:

(*) Since switching to Apple Mail — and having access to its nifty and swift full-text search capabilities — I’ve abandoned the thousand-or-so individual folders in which I used to file things away. Mail in my Inbox now goes to one of two destinations: Trash, for spam and automatic notifications and other stuff I have no interest in ever looking at again, or Sent, for anything written by a human and on occasion important things written by computers.

Download MoveMessageToSentFolder-1.0.zip.
Leopard (Mac OS X 10.5) only.

To install:

• Copy the mailbundle to ~/Library/Mail/Bundles. Create this folder if it doesn’t already exist.
• Open Terminal and run the following commands to enable mailbundle support:

  defaults write com.apple.mail EnableBundles 1
  defaults write com.apple.mail BundleCompatibilityVersion 3
  

In the past couple of months I thought about spending some money on either a Nintendo Wii or a multi-purpose media box (not to mention my anxiety over buying an unmodifiable blackbook). Over the past 3 years I’ve looked at smaller cases as “better”. Before that it was always the full tower case that provided more room and ease-of-use. In this vein I’ve been looking at the world of mini-itx for the past several months.

VIA created the mini-itx specification for itself, but since its creation other companies started creating motherboards with this spec and recently so has Intel. The spec allows for a low-power consumption CPU, which is great for point-of-sales machines, thin clients, and more. The other use of mini-itx, popular amongst personal users, is as a Home Theater PC (HTPC) or media center.

There are several solutions available in this market. By far the most popular media box in the past few years has been a Microsoft product, the XBox. You can slap on an open source GPL media player onto the xbox - XBox Media Center (XBMC). This was great as a video, audio, and game machine for dvds, mpeg4 (xvid), and various audio formats.

Alternatively Apple sells the Apple TV, which not only plays movies, but can connect to your shared ITunes library. However as with many things Apple (and not-Apple) it has limited uses even with the hack to allow xvid and DivX support. Author’s Note: I first wrote this before Mac World Expo January 2008.

The two products mentioned above are limited by their age. Both are not powerful enough to decode h.264 matroska encapsulated video or HDMI video input. This is the problem. Would I be able to build a mini-itx machine capable of doing what these once-awesome products do not? My requirement was pretty simple. I’ve dealt with TV Tuners and HDTV before, and I’m not interested in building a true “HTPC” or personal video recorder (PVR). That ship has sailed. Not to mention all the hullaboo about DRM in bluray/hd-dvd, hd capable monitors, video cards, etc…

After investigating hardware articles and reviews of the boards on mini-itx.com I narrowed down my search to the VIA Epia EX 15000G. This newer board offered a “fast” 1.8ghz VIA C7 processor. A PCI slot would take care of a wireless card as I wouldn’t be dragging cat5 down from the router upstairs to the TV. It seemed to offer everything that I was looking for. It even had an on-board graphics chip with a mpeg2/mpeg4 hardware decoder though underpowered in 3d acceleration!

The VIA Epia boards are also highly compatible in linux so that’s a plus. I delved deeper. I wanted to make sure that this board would suffice. After all I’ve never touched a processor other than AMD or Intel.

However I’m afraid to say that the Unichrome Pro II mpeg2/mpeg4 hardware decoder is not usable at the current time. There have been numerous complaints that hardware decoding doesn’t work for .mkv files and even in Windows! Surprisingly the only h.264 playback possible was in linux with the now seemingly defunct Via enhanced MPlayer.

This was the nail in the coffin. I’m not going to buy a board because it *may* work in linux with the supposed mpeg4 hw decoding support (and not at all in Windows). What does this leave us with? Software decoding? The C7 processor is not powerful enough to decode 720p let alone 1080p content.

The cost of this machine and project will significantly increase switching from a mini-itx C7 processor board to perhaps an intel mini-itx core 2 duo mobile board or switch to micro-atx (about $150-$200 increase in budget with a core 2 duo mobile or desktop).

The smallest really isn’t better.

Mac OS X doesn’t have the luxury of working on the same underlying CPU though, so things need to be handled a little bit differently. The solution Apple came up with was the idea of a “Fat” binary, sometimes called a “Universal Binary”. In other words, instead of a single program being contained in a program file, the program file can contain several programs for different architectures. For example:

cwright@phendrana:~>file /bin/ls
/bin/ls: Mach-O universal binary with 2 architectures
/bin/ls (for architecture i386):	Mach-O executable i386
/bin/ls (for architecture ppc7400):	Mach-O executable ppc

or an even more convoluted example:

cwright@phendrana:~>file GLTools
GLTools: Mach-O universal binary with 4 architectures
GLTools (for architecture ppc7400):	Mach-O bundle ppc
GLTools (for architecture i386):	Mach-O bundle i386
GLTools (for architecture ppc64):	Mach-O 64-bit bundle ppc64
GLTools (for architecture x86_64):	Mach-O 64-bit bundle x86_64

This increases file size considerably (4x in the last example), but it provides you with the cool side effect of being able to drop the exact same program onto a PowerPC Mac, and have it operate identically — as long as you’re properly handling architectural differences such as endianness. Overall, this is a pretty slick solution, and with the exception of a few small tweaks, I doubt I could have come up with a better idea. (The small tweaks, in case you’re wondering, would be shared data segments across the binaries inside, such that non-code stuff only needs to be included once, instead of 4 times. This doesn’t work well when the data contains code though, so you’d need to have flags to control how it operates).

One of many problems rears its ugly head though when developing such portable applications: Linking with static and dynamic libraries.

Out of the box, OS X ships with many libraries that are all appropriately compiled to support all the above architectures, so you never notice this problem when compiling against standard included libraries. However, if you stray off the beaten path, and use another library, you’re destined for trouble. Open Source libraries, especially the ones whose build system depends on the monstrosity that is AutoConf (./configure scripts and all that), are surprisingly difficult to get working. In part, because they’re not designed to be built for multiple architectures in parallel, and in part because AutoConf is infuriatingly worthless when it comes to documentation.

Of course, since I’m writing all of this, I’m obviously in the middle of such a battle :)

By default, I run configure like this:

CFLAGS=\"-Os -fomit-frame-pointer\" ./configure [options]

where options is stuff like --enable-shared and other library stuff. On occasion (only 85% of the time), I also have to override other environment variables because parts like pkg-config don’t work, because other libraries don’t install properly, and a whole host of other problems. I really can’t believe I actually liked dealing with this crap when I used linux… but I digress.

So first off, I think “Hey, I can add some magic to the CFLAGS parameter, and it’ll just compile!” … hahaha … I wish. Here’s what happens:

cwright@phendrana:~/Desktop/Recent Source Stuff/libSomeLib-X.Y.Z>CFLAGS=\"-Os -fomit-frame-pointer -arch i386 -arch ppc -arch x86_64 -arch ppc64\" ./configure --enable-shared

Configure does its thing, and then says it’s done and you’re ready to build. It’s lying, of course:

cwright@phendrana:~/Desktop/Recent Source Stuff/libSomeLib-X.Y.Z>make
make  all-recursive
Making all in libSomeLib
/bin/sh ../libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I.. -I..    -Os -fomit-frame-pointer -arch i386 -arch ppc -arch x86_64 -arch ppc64 -MT io.lo -MD -MP -MF .deps/io.Tpo -c -o io.lo io.c
 gcc -DHAVE_CONFIG_H -I. -I.. -I.. -Os -fomit-frame-pointer -arch i386 -arch ppc -arch x86_64 -arch ppc64 -MT io.lo -MD -MP -MF .deps/io.Tpo -c io.c  -fno-common -DPIC -o .libs/io.o
gcc-4.0: -E, -S, -save-temps and -M options are not allowed with multiple -arch flags
make[2]: *** [io.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

So, -M options aren’t allowed to have multiple arch flags, says gcc. I do some spelunking to find out exactly what these flags do, and find that they’re for creating Makefile dependencies. But wait a minute, isn’t that Configure’s job? Man these build tools are awesome. … (technically speaking, it is Make’s job to make this stuff. There just isn’t a hook to add architecture support anywhere else without completely re-engineering the build system.)

Next up, I read some Apple documentation to see how they go about doing it (for stuff like OpenSSL, etc.). They recommend making a new XCode project, and then making a zillion build targets, taped together with some shell scripts. To be honest, it doesn’t seem very Apple-like. If I’m going to be dealing with shell scripts, I’ll just do it myself in Terminal.

The second attempt consists of duplicating the source tree into 4 directories, one for each architecture. Then, my plan goes, I’ll use lipo to glue them all together into a fat binary, and I’ll be on my way.

I run configure in each directory tree, careful to include only one -arch parameter in each one. I issue make in the i386, ppc, and x86_64 trees without issue, and start to think a bit smugly to myself that I’ve defeated this silly monster. But then, another Configure Dragon charges.

cwright@phendrana:~/Desktop/Recent Source Stuff/libSomeLib-X.Y.Z-ppc64>CFLAGS=\"-Os -fomit-frame-pointer -arch ppc64\" ./configure --enable-shared
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
/bin/sh: /Users/cwright/Desktop/Recent: No such file or directory
configure: WARNING: `missing' script is too old or missing
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details.

Of course, whenever configure tells you to check “config.log” for more details, it’s about as informative as reading a Blue Screen. Also, note the 4th or 5th line, which shows a lack of quoted paths. That looks safe…

The problem, according to configure, is that it “cannot run C compiled programs,” which is actually accurate for this case: Rosette doesn’t translate ppc64 binaries to x86. However, gcc can compile such programs, so we know we can do it. Configure suggests using the “--host” command.

Running configure with --help reveals how --host is supposed to be used. It’ll look like this, I suppose: “--host=ppc64″.

It issues this warning, but continues to do its thing:

configure: WARNING: In the future, Autoconf will not detect cross-tools
whose name does not start with the host triplet.  If you think this
configuration is useful to you, please write to autoconf@gnu.org.

I hope that’s ok.. ?

I run make, and it builds, and finishes. A bit earlier than the others. In the .libs directory, there’s no .dylib, which is what –enable-shared is supposed to create. So, I look at the output from previous builds, and copy the line it inexplicably skips. It’s a pretty long, but simple gcc line that takes all the .o’s and makes them into a .dylib. No idea why it skipped over that one…

And at last, we’re able to build our fat binary using lipo. Hurray for portable cross-platform build tools!

Good morning gentle readers. I opened up my craptop this morning to witness the struggles of what seemed to be a laptop battling cancer. No, this was not another case of opteron cancer. Instead I found that Windows, unable to cope with my Cisco Aironet 350 wireless card, was creating network connections one after another in the system tray.

Recently I have been taking out my wireless network card while at work, which used to always reside in my laptop’s PCMCIA slot. At the end of the day I’d plug it back in usually either before or after I had sent my laptop into power save mode.

So this morning like all mornings I take out my laptop, set it up, open the lid and log in. Within seconds I notice my system tray bombarded by a new wireless network connection appearing once every second or so, enlarging the system tray beyond its normal size (note the arrow to the far right of the screenshot). My esteemed colleague Chris Wright and I were both disappointed that the info bubble did not in fact pop up for each of those connection icons. Luckily this cancer seemed benign, and within a few seconds Windows realized there actually was only one wireless networking device.

Though it seems this all boils down to the lesson: never mess with an IBM trying to get some sleep. Whether it’s not waiting long enough for a print process to get out of the queue causing endless beeping or windows self-replicating wireless network connections, you’ll face the seemingly impossible behavior of a laptop pushing the boundaries of sanity.

Finally, this void has also been filled, via the iPhoto Thunderbird Bridge. It’s still quite primitive, but all the basics are there for iPhoto-Thunderbird integration.

If you’re an iPhoto/Thunderbird user, give it a whirl.

The disappointing part is that this bug was first noticed almost two years ago. While the extent isn’t nearly as bad, it’s still not clean.

This bug came up in our Speech Synthesizer patch for Quartz Composer, featured at kineme. After much testing, profiling, and refactoring, a splendidly small demonstration program emerged.

#import <Cocoa/Cocoa.h>
	
int main()
{
        while(1)
        {
                NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
                NSSpeechSynthesizer *speech = [[NSSpeechSynthesizer alloc] init];
                [speech release];
                [pool release];
        }
	
        return 0;
}

This program endlessly allocates an NSAutoreleasePool, used for memory management, and then an NSSpeechSynthesizer object. After creating them, it destroys them. Destroying the synthesizer object should free any associated memory with the object, and releasing the pool should free up any odds and ends left over, just in case.

Reality paints a much more disappointing picture:

cwright@phendrana:~/projects/SpeechTest>./rapid
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Segmentation fault

It starts off looking ok. It spins for about 15 seconds or so, but then trouble strikes. As you an see, the class starts to have difficulty mapping a voice file (this is only mentioned once in all of Google’s wisdom, with no useful insight as to what it means), and eventually the inevitable crash occurs.

smokris tried this on his MacBook Pro.. Same thing there:

smokris@etu 6 ~/Desktop -> time ./a.out
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Speech Synthesis can't map voice file (12)
Segmentation fault
	
real    0m4.479s
user    0m0.286s
sys     0m0.153s

After my October escapade in Boston — with a brief layover at Yon Reptile Campaign — Life™ decided to shine a ray of hope in my general direction, after Thanksgiving. However, quick to grant me access to enough income to pay rent, Life™ viciously raped my ATI Radeon 9800 Pro, and I was unable to use MPlayer to play movies, use GL to play games, or whatever else we non-Apple people do with our video cards. With a hole in my pocket called “month-to-month” Harmless lay infected with a Savage 2000 card that I bummed from a co-worker while working for JP Morgan Chase. Luckily I began a more permanent presence at Yon Reptile Campaign helping cope with a couple of rambunctious Windows servers, and so I can begin this tale of…

“Project Hayate - Prolonging the Inevitable Shaving of my Metaphorical Neckbeard, Part One”

After a few months of researching I decided that my best choice economically would be to go with an Intel Core 2 Duo 1.83ghz. However with the Intel price drop on April 22nd I, being the simple-minded consumer that economists & marketing analysts love, bought the new Intel Core 2 Duo e6420 2.13ghz instead. Not that I needed a 4mb cache anyway. I quickly found the Gigabyte 965p-DS3 as a relatively compatible motherboard for Linux, purchased 2gb of ddr2-800 from Corsair, a 250gb Western Digital SATA drive, and of course a video card, the XFX Nvidia GeForce 7900 GS PCI-E (so long ATI!). Although if I had more available funds it would have been best to purchase the latest and greatest of Nvidia 8xxx series, but alas that will have to wait.

I returned from my usual weekly business trip in a state of panic. FedEx no longer requires signature by default, and they had most likely left this precious package on my doorstep where no doubt Life™ would have snatched it away and into the hands of some bastard. Despite the 9:34am “delivery time” and confirmation of no package on my doorstep at 10:30am I came home to a package on my doorstep. My descent into emo would have to wait for another day.

I shut down Harmless for the last time, shed a tear of sorrow for the lost, and took its shell (and my BenQ DD DVD Writer :).

With surprising ease I slipped the new power supply and motherboard into the mid-tower case that once housed Harmless. I made sure to put on one drop of Arctic Silver Thermal Paste, and dabbed it evenly over the clean face of the Core 2.

It took a few minutes to learn the essentials of Socket LGA775, but I found it much easier than messing with those damn clips from Socket 478. I was amazed that the Arctic Cooling Freezer 7 Pro Heatsink even fit in the case. It was a close fit, but damn that’s hot (no pun intended).

And the fan, that’s hotter. And fast forward to everything in the case.

… I stood flabbergasted. Was it really that easy? No, the hard part was yet to come — full of doubting Slackware, my sanity, aggravating search queries on Google for pages you knew existed, and fun kernel messages like the one to the right. The night was far from over. However I’ll spare you gentle readers until another episode.