davidb dives in

Step…

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.

Hmm.. The online store page says “…usually within a few minutes”. Is two weeks to wait long enough? I guess after that I’ll be reversing the charges. Or something.

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.

That is, if you consider looking up crossword puzzle clues on oneacross.com to be cheating. Or even if you think that looking up stuff in imdb and wikipedia is cheating.

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.

If you are like me and have been made retarded by Emacs, you might miss the standard Emacs bindings in FireFox and/or Thunderbird. Well, never fear, there is a way to fix it. While it is pretty easy to fix on Linux, it is a wee bit of a pain-in-the-ass on OS X. So, to save some of you some time, here is the modified toolkit.jar for Firefox 1.5.0.2.

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!

Last weekend, I got an iSight. I didn’t actually need one for anything, but I was curious and I had a little spot bonus money to burn.

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!

About 3 or 4 years ago, I bought my mother a scanner for her iMac (G3). Now, my mother isn’t a photographer or particularly interested in scanning pictures or old photos. What she uses a scanner for is OCR. At the time, she was assembling a report for her church, and folks frequently gave her hard copies of things rather than emailing her the documents. This wasn’t the absolute best solution, since the OCR software frequently introduced a fair number of errors, but it beat typing everything in.

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.

Well, because grumpy suggested it, I thought I would post some digested thought about this new Mac-on-Intel thing. I don’t claim that I’m really the original thinker here by a long shot, but here goes:

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.

A mystery was solved today! The current build of SCPlugin (v.269) causes the search field of the System Preferences application to not work under Mac OS X 10.4 (Tiger). Specifically, the preference pane for SCPlugin, not the actual extension.

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.

As part of my final migration to all things Macintosh, I needed to get my text editing situation under control. After developing on various X windows based platforms for the vast bulk of my career, I’m very comfortable with using the command line to navigate around a programming project. My work pattern is typically to move around on the command line until I need to edit a file. Then I have a command line tool that will bring that file up in my chosen editor.

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.

This week, I took the plunge. While I’ve been using macs for years now, all this time my main work environment was Linux. I was very used to developing on Linux, and it was hard to justify changing. This week, I finally switched to full-time mac use (a feat that Grumpy accomplished some time ago).

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.

Grumpy points me to a glowing, happy Salon article, Hallelujah, the Mac is back. This is an interesting article that raises a number of interesting points. More entertaining, however, are the reactions to that article, as selected by Salon.

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.