Emacs on Snow Leopard Update

When last I posted, I was having problems compiling Emacs 23.1 on Snow Leopard, as well as problems with -daemon mode. It appears the upstream emacs repo (git://git.savannah.gnu.org/emacs.git) has resolved the issues regarding compiling on Snow Leopard. Also, -daemon mode has become quite reliable. I can now create new frames and destroy them as often as I want, and Emacs won't crash. I do still have the issue where the modeline font gets garbled after the first connect, but that appears to be related to color-theme (I'm using color-theme-gnome2). If I remove just that one line from my .emacs, then the modeline problem goes away as well.

Emacs patches to build on Snow Leopard

I've been tinkering with the Emacs 23.1 code lately, trying to get it to compile on Snow Leopard, and get --daemon mode working on Mac OS X as well. I'm posting my patches to github as I work on it. I'm a bit of a git noob, so I'm not certain how (or even if) I could make a public repo on github of my branch, containing just my branch changes, and derive from git://git.savannah.gnu.org/emacs.git for the bulk of the data. That would be ideal, rather than maintaining a repo of patches. Also, even though the patch does get Emacs to compile, there are some obvious issues with it, so it's not ready for production use. First, font heights are not being calculated correctly. Second, there's very obvious lag when first starting up the window, which I must have added (as the 32 bit 23.1 binary doesn't have that problem).

Snow Leopard and Time Machine over NFS

Ok, admittedly, I muck around with my systems more than strictly necessary (those that know me are guffawing at how much I'm understating this tendency), but I was having some issues getting Snow Leopard's Time Machine to continue backing up to my OpenSolaris file server over an NFS mount. My first problem was that I had somehow lost my NFS config on the OpenSolaris box. May have been due to a recent zpool upgrade, or due to the fact that I had recently completely destroyed and re-created that pool. In any case, I hadn't noticed this for a while because my NFS mounts were still working as expected for my average usage. After recreating the NFS share info (including the ability for root users on my MBP to be mapped as such on my file server), Time Machine got a bit further along. But now, it seemed to be complaining that it didn't have enough room on the backup drive. I hastily destroyed the old sparsebundle thinking that it a fresh start with a new image would work fine. When trying to backup with no sparsebundle available on the server, it gave the expected error due to being unable to create a sparsebundle directly on an NFS share. I still don't know why that's the case, but I remembered doing the same the previous time I set it up, and just created a sparsebundle locally then copied it to the server.

sudo hdiutil create -size 200g -type SPARSEBUNDLE -nospotlight -volname "Time Machine" -fs "Case-sensitive Journaled HFS+" -verbose /tmp/MACHINENAME.sparsebundle

Unfortunately, now when it tried to connect, I still saw TM attempting to create a new bundle. Not sure why, I decided to poke around backupd with dtrace for a bit to see what it was doing on the file system.

#!/usr/sbin/dtrace -s
syscall::open:entry
/execname=="backupd"/
{
 printf("UID %d: Opening file: %s.\n", uid, copyinstr(arg0));
}

syscall::open:return
/execname=="backupd"/
{
 printf("UID %d: Opening file returned: %d.\n", uid, arg0);
}

Turns out, TM was trying to read a file called com.apple.TimeMachine.MachineID.plist from within the sparsebundle directory (not the mounted image, just the directory). Some searching for that file name brought me to this page where they had the following as the suggested content for that file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>com.apple.backupd.HostUUID</key>
 <string>YOURUUIDHERE</string>
</dict>
</plist>

After dutifully replacing YOURUUIDHERE with my machine's UUID (pulled from System Profiler -> Hardware), Time Machine finally mounted my sparsebundle as requested and started the backup.

Highlights and Lowlights of Snow Leopard

I've had a few days to play around with Snow Leopard now, so I thought I'd just note a few of my favorite bits and a few nits I'd like to pick. The Good:

• Four finger gesture support on my early 2008 MBP. I love this, and find myself already using it all the time for running Expose.
• Improved services and creating services with Automator. About 20 minutes after I had Snow Leopard installed, I had an Automator workflow added to the services menu to open the selected file or folder in Emacs (still haven't finished debugging the --daemon mode on OS X yet though).
• Hiding applications to their app icon, rather than a separate slot in the Dock. It used to drive me a bit crazy that when I clicked a doc icon for a hidden app, the app itself wouldn't pop back into view, and instead I'd have to find the minimized window. No more.
• Dock Expose. I also find myself using this quite often to select a given window of an app.

The Bad:

• Doesn't boot 64 bit by default. Wasn't this supposed to be one of the big selling points of Snow Leopard? Why do I have to hold magic keys during boot or update a plist to get this enabled?
• Once I've booted into a 64 bit kernel, I'm having issues with both VMWare Fusion and VirtualBox. Fusion simply refused to start. VirtualBox attempted to start, but caused a kernel panic.

Getting Emacs 23.1 --daemon to play nice on Mac OS X

I've been a hard core GNU Emacs junky for nearly as long as I've been using computers, and definitely as long as I've been programming. To get my Emacs fix on Mac OS X, I've been using Aquamacs, and while I think they do a great job in general, I don't think I'm really their target audience. I'm not really looking to have a more Mac-like experience in Emacs, I just want an Emacs experience on my Mac. I was very excited to find that the GNU Emacs folks were finally main-lining the NextStep/OpenStep/Cocoa support with version 23. I was also very interested in --daemon mode, as I do have a fair amount of elisp that gets executed on startup. Unfortunately, all did not work perfectly on Mac OS X with 23.1. While the the first connection using emacsclient worked fine, after disconnecting and reconnecting, the font in the modeline would be garbled, and after disconnecting the second time, Emacs would crash. Console.app reported the stack trace each time as similar to:

Thread 0 Crashed:
0   libSystem.B.dylib              0x90071e42 __kill + 10
1   libSystem.B.dylib              0x900e423a raise + 26
2   libSystem.B.dylib              0x900f0679 abort + 73
3   org.gnu.Emacs                  0x00177985 ns_term_shutdown + 117 (nsterm.m:4015)
4   org.gnu.Emacs                  0x0009cf3f fatal_error_signal + 399 (emacs.c:389)
5   libSystem.B.dylib              0x900702bb _sigtramp + 43
6   ???                            0xffffffff 0 + 4294967295
7   libSystem.B.dylib              0x900e423a raise + 26
8   libSystem.B.dylib              0x900f0679 abort + 73
9   org.gnu.Emacs                  0x001262de font_clear_cache + 366 (font.c:2708)
10  org.gnu.Emacs                  0x00126b3b font_update_drivers + 731 (font.c:2653)
11  org.gnu.Emacs                  0x000116ba delete_frame + 442 (frame.c:1466)

Checking font.c:2708, I found:

font_assert (font && driver == font->driver);

I believed (and Wikipedia confirmed) that == binds tighter than &&, so I applied the following patch:

--- emacs-23.1/src/font.c 2009-07-28 09:51:20.000000000 -0500
+++ emacs-23.1-modified/src/font.c 2009-08-24 08:15:31.000000000 -0500
@@ -2705,7 +2705,7 @@
 
         if (! NILP (AREF (val, FONT_TYPE_INDEX)))
    {
-     font_assert (font && driver == font->driver);
+     font_assert (font && (driver == font->driver));
      driver->close (f, font);
      num_fonts--;
    }

That does indeed get me a correct modeline font on the second connection from emacsclient, and the second disconnect appears to work as well, but on the third connect, Emacs is still crashing. Just with a slightly different stack trace now:

Thread 0 Crashed:
0   libSystem.B.dylib              0x90071e42 __kill + 10
1   org.gnu.Emacs                  0x0009ceea fatal_error_signal + 314 (emacs.c:404)
2   libSystem.B.dylib              0x900702bb _sigtramp + 43
3   ???                            0xffffffff 0 + 4294967295
4   libSystem.B.dylib              0x900e423a raise + 26
5   libSystem.B.dylib              0x900f0679 abort + 73
6   org.gnu.Emacs                  0x00177985 ns_term_shutdown + 117 (nsterm.m:4015)
7   org.gnu.Emacs                  0x0009cf3f fatal_error_signal + 399 (emacs.c:389)
8   libSystem.B.dylib              0x900702bb _sigtramp + 43
9   ???                            0xffffffff 0 + 4294967295
10  com.apple.CoreGraphics         0x96f68b3c _setWindowRegion + 382
11  com.apple.CoreGraphics         0x96f6899a CGSClearDragRegion + 75
12  com.apple.AppKit               0x90bf317d _NSClearDragRectsInWindow + 62
13  com.apple.AppKit               0x90bf2b4d -[NSFrameView _resetDragMargins] + 219
14  com.apple.AppKit               0x90b1c32f -[NSThemeFrame _resetDragMargins] + 188
15  com.apple.AppKit               0x90b22a03 -[NSTitledFrame setTitle:] + 724
16  com.apple.AppKit               0x90b22540 -[NSWindow _dosetTitle:andDefeatWrap:] + 324
17  com.apple.AppKit               0x90ea417f -[NSWindow _calcAndSetFilenameTitle] + 361
18  org.gnu.Emacs                  0x001838fc ns_set_name_as_filename + 908 (nsfns.m:667)
19  org.gnu.Emacs                  0x00035577 prepare_menu_bars + 919 (xdisp.c:9506)
20  org.gnu.Emacs                  0x000364dd redisplay_internal + 3373 (xdisp.c:11475)
21  org.gnu.Emacs                  0x00036e38 redisplay_preserve_echo_area + 56 (xdisp.c:12093)
22  org.gnu.Emacs                  0x0015b224 wait_reading_process_output + 4852 (process.c:5018)
23  org.gnu.Emacs                  0x0000ccf6 sit_for + 214 (dispnew.c:6647)

Obviously, I have more testing/work to do.

Paraphrase of Greenspun's Tenth Rule

Recently, I was trying to convince some team members that OSGi would be a good choice for a system we're designing. After indicating the benefits, as I saw them, one person asked, "Couldn't we accomplish the same thing by doing x, y and z?" At the time, I had a rather dry counter, but it occurs to me that Greenspun's Tenth Rule can be rather accurately adapted to the current Java development landscape.

Any sufficiently complicated Java program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of OSGi.

Note to self...

Never run zpool add when you mean to run zpool attach on your new disk. Apparently, zfs does not yet support shrinking a zpool. On the bright side, though I may not have redundant storage, I've now got much more space in my pool!

Upgrading an OpenSolaris Guest for Virtual Box 2.2

Virtual Box 2.2 was just released. I was rather excited to try Compiz in a box, but was soon disappointed to find that my guest OS could not start properly. After some tinkering, I booted into single-user mode (hit e on the text boot line, then add -s at the end of the kernel$ line, then hit b to boot), and ran pkgrm SUNWvboxguest to remove the old guest additions, which allowed the guest OS to boot up just fine.