Anyway, did you even know that Cocoa Emacs existed? You may have hard of Carbon Emacs or Aquamacs, but WTH is Cocoa Emacs? It turns out that with the final stable release of Emacs 23.1, it came with a Cocoa native build option. Thus, Cocoa Emacs is now the standard, no-nonsense build of emacs for OS X.

So, how does Cocoa Emacs compare to Carbon Emacs? It acts and feels mostly the same, although I think it looks a bit crisper and feels a bit faster (which is probably an illusion). It is smaller on disk (95 MB vs 157 MB), and, of course, it is based on a newer version of emacs itself. It is The Future!

There are two things that irritated me with Cocoa Emacs when I switched:

1. Meta is, by default, mapped to the option key. However, this is easily fixed.
2. Carbon Emacs came with a built-in version of aspell. With Cocoa Emacs you need to get aspell separately. This is less easily fixed, but it isn’t too bad.

You can get a pre-built stable version of Cocoa Emacs from here, or nightly builds from here.

Step 1: Switch the meta key back to the command key, where it is meant to be. This can either be done via Customize, or you can do it manually with elisp. Manually, add:

(setq ns-command-modifier 'meta)

to .emacs. This same thing can be done simply via Customize:

1. M-x customize,
2. go to Environment->NS,
3. and change the “Ns Command Modifier” option to “meta”.

You can map option to something else, keep it is “meta”, or unset it altogether (which is how it behaves in Carbon Emacs, and probably what you want).

Step 2: getting aspell. If you never ask emacs to spell check anything, you can ignore this. There are three ways that I’ve thought of to get aspell:

1. Copy it from Carbon Emacs. I haven’t actually tried this, but it should be possible to copy it from the Carbon Emacs bundle into the Cocoa Emacs bundle. You will probably need Contents/Mac OS/bin/aspell and aspell-import, and Contents/Resources/lib, and Contents/Resources/site-lisp/site-start.d/builtin-aspell.el. Good Luck.
2. Install aspell via macports. If you already have macports, this is probably the way to go. To do it this way:
   • % sudo port install aspell
   • % sudo port install apsell-dict-en (or some other language dictionaries)
   • In emacs: M-x customize-option, ispell-program-name, and set the value to /opt/local/bin/aspell.
3. Get it by installing cocoaAspell. This is what I’ve done currently.

CocoaAspell both delivers a version of aspell (to /usr/local/bin) and also delivers a preference pane for getting it configured. Nifty, but I had to manually fix the aspell configuration to point it to the dictionaries, and you also need to modify the ispell-program-name variable (which can be done via Configure, as well).

To fix the aspell configuration, I edited /usr/local/etc/aspell.conf, changing:

dict-dir /usr/local/lib/aspell-0.60

to

dict-dir /Library/Application\ Support/cocoAspell/aspell6-en-6.0-0

Or, I suppose, you could copy the dictionaries back to /usr/local/lib/aspell-0.6.0.

1. Install instantclient. You will need the basic and sdk modules. I suggest also getting the sqlplus module while you are at it. I put this in /usr/local/instantclient_10_2.

2. Modify your .bashrc (or whatever) to set ORACLE_HOME and DYLIB_LIBRARY_PATH to /usr/local/instanclient_10_2.

3. Get DBD::Oracle from CPAN. (I got 1.22). Here is where it gets tricky: In Terminal:

% perl Makefile.PL

This generates Makefile.

1. Edit Makefile, changing: NMEDIT=nmedit to NMEDIT=echo

2. Edit dbimp.c, removing all code that references dump_env_to_trace(). I found a patch at macosxhints.com, but this is tied to a particular release of DBD::Oracle. I decided to use my mad programming skillz to logically do what was needed. Hopefully this will be fixed in some future version of DBD::Oracle.

3. Again, in Terminal:

% make && sudo make install

And that should do it.

1. Discover Black Ink. It has a 30-day trial period
2. Try for 30 days. Like in the beginning, like at the end.
3. Buy it. I go the the online store and pay via paypal.
4. Wait for 3 days. See credit card charge go through.
5. During this time, fail to check the spam traps.
6. Wait for 4 more days. Nothing from Red Sweater Software.
7. Send email to support@red-sweater.com asking for actual registration code.
8. Wait 3 more days. Silence.
9. Discover that somehow, searching for “red-sweater” in Mail.app doesn’t find mail in the spam folders.
10. Eventually find 3 emails from Daniel Jalkut with your registration code.

Update: All fixed now. I am somewhat amazed that posting to my blog was an effective means of communication. I’m guessing this reflects more on Red Sweater Software’s customer service diligence than anything else.

Update[2]: So my friend Sean summed this whole event up as: “You posted to your blog, Daniel Jalkut read it, said ‘check your spam box, dumbass’, and now you look like an idiot.” Yep.

I haven’t spend a whole lot of time on crossword puzzles before, mostly because I sort of suck at them. But a few days ago, I discovered Black Ink. I never tried the previous (java-based) version, but this version is pretty good. But it makes looking up stuff in oneacross (which I didn’t even know about before) ridiculously easy. And you are one command-tab stroke away from your browser and the crosswordy goodness of wikipedia, google, and imdb.

I haven’t laid down the cash-money for this application yet, but if I keep going I’m going to have to.

Here is how you use it:

1. Get into your FireFox.app bundle — I find this easiest to do via Terminal: cd /Applications/FireFox.app/Contents/MacOS/chrome
2. Make a copy of your original toolkit.jar file: cp toolkit.jar toolkit.jar.original
3. Replace toolkit.jar with the one you just downloaded from me: mv ~/Desktop/emacs-keybindings-ffox-toolkit.jar toolkit.jar
4. Restart FireFox.
5. Enjoy the soothing balm of having Emacs keybindings work in yet another application.

I wouldn’t use this jar file with other versions of FireFox, by the way.

Update: Pete has created the equivalent toolkit.jar file for Firefox 1.5.0.3, although it looks like nothing in toolkit.jar actually changed between 1.5.0.2 and 1.5.0.3, so mine might actually still work. Nonetheless, I suspect that keeping up with weekly bugfix releases is going to be quite tedious. Which is probably why the MozillaZone folks aren’t doing it…

Update to the Update: Pete, at my instigation, has just scripted this, so we don’t have to manually fix Firefox/Thunderbird/etc. Hooray!

So, while I have yet to use it for its main purpose, video chatting, I have tried it for a different purpose: Delicious Library. This app has a neat trick of turning your iSight (or other webcam, really) into a barcode reader. This was so fascinating to me, that I bought Delicious Library just to play with this feature. That and tracking my books, CDs, video games, and DVDs seemed like a decent idea anyway.

Never mind that I only own about 200 books and can pretty much remember what and where they all are. Never mind that I only have a about 150 CDs (pathetically low!), and my video game and DVD collections are even smaller. Also pay no attention to the fact that I rarely lend any of these materials to anyone (or, at least, I do so infrequently enough that I can generally remember what I’ve lent).

So, while my use of Delicious Library is essentially and advanced form of procrastination, I did want to check it out to see if my parents would get any use out of it. See, they, at least, have quite a lot of books, and a certain subset of them are frequently lent. And I’m always looking for news ways for them to get use out of their Macs.

First, getting the barcode reading to work: this requires (unsurprisingly) adequate ambient light. And it requires a bit of fiddling with the item to be scanned. Sometimes, scanning works right away, sometimes it is a maddeningly tricky.

Second, scanning DVDs and games was generally pretty successful. One game I had (Halo 2, limited edition) had no barcode, and one game didn’t come up (Katamari Damacy).

However, scanning books was a different story. Most of my cookbooks scanned and loaded successfully, but when I moved to the bulk of my collection, paperback fiction, the success rate dropped dramatically. I think maybe 3 of 160 books scanned and were recognized. Of course, Delicious Library allows you to enter books by ISBN, which is much more reliable.

Delicious Library is using amazon.com’s web services to do all of its searching, and I find it curious how brittle an identifier the UPC is, as compared to ISBN. My unresearched theory is that UPCs tend to identify a particular printing of a book, where the ISBN refers to a book in all of its forms. (This may be a reflection on how amazon uses these numbers rather than what the standards themselves say). So, if your book isn’t very recent, or is an edition not sold by amazon, then the UPC is unlikely to work.

I still like Delicious Library (even if its use to me isn’t that profound), but I would recommend that if you are primarily going to index books, you might not want to bother with the barcode reading.

Update: The barcode reading works perfectly with books that you just got from Amazon. I was looking at my parent’s book collection noticing that a number of them are old enough to not have ISBN numbers (or any real identifier beyond title and author), so I expect that those will be fun to enter into Delicious Library.

Update to the Update: The barcode reading isn’t perfect, even with books you just got from Amazon. I had just bought 4 books, and the 4th book came later. When I scanned this book, Delicious Library first came up with nothing, then, on a subsequent try, came up with a different book!

This scanner (which replaced an older, SCSI scanner that we couldn’t get to work with the new iMac) was a well-recommened (for the Mac, anyway) Canon scanner. I forget the model number, but it is essentially a LiDE 30. At the time, my mother was either running OS 9, or at least still largely relying on Classic to get stuff done. The scanner came with an OEM version of OmniPage SE for OS 9. It worked, but it was largely unintuitive to use.

It was then that I learned that scanners were the black-hole of usability on the Macintosh. Where the Mac had made many things very easy that had once been hard, scanner support was still largely left up to the vendors, who were only marginally interested in making their stuff work on the Mac. In short, it sucked.

Fast forward a few years: after one hard disk meltdown, one iMac replacement (to a new 17″ iMac G5), and Tiger, Classic is gone, and with it, any ability to even use the scanner to do anything, let alone OCR. Fortunately, the burning need for this functionality had lessened, so it wasn’t that big of a deal.

I would occasionally look for ways to get that scanner back in business. What was frustrating is that it looked like the cheapest thing to do was to buy a new scanner! The only OCR software that I knew about was OmniPage Pro, which was $400. The scanner was only $150 new.

Enter VueScan. This weekend, I convinced my mother to download it (ok, actually I just downloaded it for her) and try it out. For the first time on the Mac, scanning was easy! It was straightforward. OCR worked. The scanner is back in business.

Only time will tell if this $90 package is ultimately worth it, but I was impressed.

What is really driving Apple to Intel is not the long awaited 3.0 GHz G5 chip. What is driving this is the Pentium M. More than half of Apple’s computer sales are laptops, and, apparently, IBM doesn’t have a very promising roadmap for laptop-friendly chips. Intel is the leader here with the Pentium M series. While Apple’s high-end server line gets press and attention, moving to Intel isn’t that big of a win for that platform. Not that it will hurt, either–Intel does have some fast parts. But, it seems to me, what Apple really needs is a fast (and growable) line of laptop processors that it can get in volume. Intel fits that bill.

Don’t feel bad for IBM — every new gaming console will apparently use IBM processors of some sort. That should account for a little volume.

[UPDATE]: Now that I’ve actually watched the Stevenote, my observations are even more obvious. Steve and Paul Otenelli both said, right out, that it was all about processing power per watt. Of course, that doesn’t directly mean that this deal was all about the laptop — liquid cooling in the high-end G5 PowerMacs is a little disturbing, too.

Now the thing to see if whether or not Apple essentially abandons their 64 bit mantra. They don’t have to, Intel has x86-64 stuff too, but the development platform appears to be a straight-up P4.

SCPlugin add a contextual menu to Finder for Subversion. It also is able to “badge” files in the Finder to show their subversion status. It is a nice tool, but hardly required. In any case, if you want your searches to work again, just remove the preference pane for it from /Library/PreferencePanes. SCPlugin will still work, but you won’t be able to change the location of the subversion binary or disable the plugin easily without restoring the preference pane.

Users of BBEdit on Mac OS X might be familiar with this, as BBEdit includes a nice command line utility that you can use for this. If push came to shove, I could probably live with using BBEdit as my main editor. However, for many years, I’ve been using a shell script wrapper around “gnuclient”, which would bring up an (X)Emacs frame with my file. Very very convenient. This was a practice started in the distant past when I used both XEmacs instead of (GNU) Emacs, and it took forever to launch a new instance of XEmacs (as well as each instance sucking up a lot of memory).

In any case, I wanted to stick with Emacs because 15 years of using it has so deeply ingrained the key combinations that I try and turn on emacs-like key bindings wherever I go. Not the BBEdit is a bad editor, but when you’ve invested in Emacs as much as I have, you tend to want to stick with it for most things. (I do find BBEdit to be a much better option when dealing with HTML and CSS, however).

So, first off was to get a build of Carbon Emacs. I had played with Aquamacs, which is essentially a different build of Carbon Emacs, but it want’s to use ESC as meta by default, and that doesn’t work for me. I had originally tried Aquamacs because my original copy of Carbon Emacs was locked into a particular, weird install location. The current version of Carbon Emacs doesn’t seem to have that restriction, and seems to be quite nice, actually.

Next, was to get gnuserv/gnuclient working. Interestingly enough, OS X 10.4 (and possibly earlier? I haven’t checked) comes with gnuserv and gnuclient already installed, presumably for use with the terminal-based emacs that it ships with (and it works!). Getting it to work with Carbon Emacs was just the trick I was looking for.

Based on previous work, I had downloaded an external gnuserv implementation. Version 3.12.6 didn’t compile cleanly on 10.4, but 3.12.7 did. I don’t think that you need to do this at all, however. Mostly what you need is to give Carbon Emacs access to three elisp files from that gnuserv distribution — which are already in your Tiger system in /usr/share/emacs/21.2/lisp directory. The three files are gnuserv.el, gnuserv-compat.el, and devices.el. You could probably just throw them into your Carbon Emacs’s internal lisp directory, or you can do what I did–put them somewhere in your home directory and get .emacs to point to them. Something like:

(setq load-path (cons (expand-file-name “~/.fsfemacs/pkg/gnuserv”) load-path ))

which assumes that you put them into the ~/.fsfemacs/pkg/gnuserv directory. Modify that to match wherever you put them. Next, put

(gnuserv-start)

somewhere in you .emacs. This will actually cause your Carbon Emacs to run gnuserv in a sub-process. One potential problem remains, however. If you have DISPLAY set in the environment that Carbon Emacs in running it (like I do), using gnuclient will generate an error message, rather than actually work. What is going on is that Carbon Emacs cannot actually connect to an X display (not actually being an X application). There are probably a number of different ways to fix this. How I did it was to patch devices.el:

--- devices.el  2000-01-31 18:12:32.000000000 -0500
+++ devices.el.davidb   2005-06-03 11:09:03.000000000 -0400
@@ -69,7 +69,8 @@
have no effect."
(cond
((and (eq type 'x) connection)
-    (make-frame-on-display connection props))
+    ; (make-frame-on-display connection props))
+    (make-frame props))
((eq type 'x)
(make-frame props))
((eq type 'tty)

Oh, and a helpful hint for any folks (like me) who traditionally defined a lot of binding to function keys: in Carbon Emacs, option+function key seems to register as the function key, and bypasses any OS-level bindings.

Update: for convenience, I’ve put up local copies of the gnuserv-3.12.7 package (unpatched), the dtemacs script, and my gc script.

I’ve been exclusively traveling with my personal powerbook for a while, so I was probably 80% here already. I’ve been browsing, reading email, blogging, etc. on the mac for years. What I hadn’t been doing was developing (not necessarily for the mac, just on the mac). My main Java development environment has become eclipse, which runs on OS X, so not much of a problem there. My main perl/python/C/etc. development environment is emacs, however, and I needed to tweak that a bit (more on that later).

I had three factors that encouraged me to jump:

1. I was becoming increasingly annoyed with the disconnect of browsing and IM’ing on two different machines, and
2. a work powerbook became available when knitbot left for greener pastures, and
3. I was starting to feel a little claustrophobic in my office being surrounded by screens and machines. Consolidation was in order.

These letters read like a summary of every Mac vs. PC flamewar ever, distilled down to the essence, and without the profanity. I love it. You can tell if you are a Mac lover or a hater just by reading the two pages (so far, anyway) of letters.

This article does repeat the Mac-is-inherently-safer meme, which one of the haters takes issue with. I like to think that he missed the point.

The bit that really drives me batty is the behavior where the drawer opens on whichever side has the most room. My solution for preventing this is to never close the drawer, which largely defeats the purpose of the drawer.

Server Problems

My first real attempt (beyond just skimming the subversion book and installing an internal test system that I only let live for a few days) was to install version 1.0.8 on our group’s web server box, running Fedora Core 2. This was a pretty easy install as FC2 comes with an rpm for subversion 1.0.8. It is practically done for you. You just need to decide on a repository strategy and a backup plan. It all went swimmingly well until we started to tentatively use it. At that point, I discovered that the Berkeley DB database it was using got corrupted at the drop of a hat. This was bizarre, and I still don’t know what the issue was. We spent about a day searching the Internet for others experiencing the same problem. Nothing. Not being willing to seriously debug this issue, I backed off for a bit. A few weeks ago, I tried again, this time with version 1.1.0-rc4 and the FSFS filesystem, instead of BDB. A few cvs2svn runs later, I was comfortable that this install of subversion was stable and fine.

Enter Subclipse

I’ve been using the Eclipse IDE for my Java development for a few months now, and I had gotten somewhat used to using it for some of the CVS management of my projects. (This after 10 years or so of using the command line for all CVS work). Of course, there exists a plugin for Eclipse for working with subversion, Subclipse.

And, of course, once I got the latest version of this plugin (0.9.22 or 21), I couldn’t get it to work. Not on linux (my normal development platform), nor Mac OS X, my teammates main platform (and probably my future development platform).

The problem was, essentially, that Subclipse uses javahl, a JNI interface to the C subversion client libraries, and it was missing or mismatched on both platforms.

Linux

On my Linux workstation, the first problem was that javahl wasn’t built or installed with the subversion RPMs. I had already been hacking an existing subversion RPM to be a 1.1.0 RPM, and just had to modify it further to actually build the javahl stuff, and then put it in a separate RPM. That took a few hours. Then I had to come to the slow realization that the patches from my original RPM were causing the javahl stuff to not link correctly. Then I had to realize that my eclipse installation wasn’t finding the shared library (I solved that by creating a shell script to put /usr/lib in LD_LIBRARY_PATH before launching Eclipse).

Note that on Linux, before I got the javahl stuff to work, it would use the subversion command line tools, but this produced irritating error dialogs all the time. It just wasn’t the smoothest solution out there.

Mac OS X

(I’ve been using the subversion package from metissian.com for Mac OS X. I like fink, but this was so much easier)

When I first tried Subclipse on Mac OS X, it just caused the JVM to die. Later, after the latest Java 1.4.2 update, it just didn’t work. This was a similar issue: console would spew forth error messages that I could tell immediately were because there was a mismatch between the installed javahl stuff and Subclipse (no problems loading the shared lib on this platform, the metissian package puts the shared lib in a valid spot). After struggling with this for a day, just updating to the 1.1.0 version of the package solved everything.

The Future

In the future, I’m hoping that Subclipse switches to a native Java subversion library, which will hopefully make Subclipse always work right out of the box.