various musings and babblings.
Archive for June 2005
I see this mistake so often online, I wonder what causes it. I mean, really, it’s endemic.
Usually “loose” is used when “lose” was meant, but I’ve seen the opposite mistake as well.
For the record:
Ok, both words have a whole lot of meanings, but they don’t overlap.
As I sit here, I’m listening to my newly acquired Simon & Garfunkel boxed set. This has been a long time coming, as I finally gave up my plan to borrow and steal my sister’s copy of “Collected Works”, which is now out of print. For some reason, I had failed to research and actual find the replacements for the “Collected Works” release, and, for whatever reason, I couldn’t handle buying all the albums separately.
You might not have pegged me for a S&G fan. After all, their whole output was done before I was born. But, more than anything else, Simon & Garfunkel was the music of my childhood. I have vivid memories of lying on the floor of our dining room, listening to S&G playing on a HeathKit turntable that my father had built. There was other music playing in my childhood, but this is where my father’s musical taste and mind really intersected.
When Simon & Garfunkel’s “Collected Works” was released on vinyl (the Internet tells me this was December, 1981), my sister and I collaborated and bought it for my father. This was really just all five albums packaged together, and the only thing new for us was “Wednesday Morning, 3AM”, S&G first album, which, for whatever reason, Dad never got. We had bought it not to get new music, however, but to replace the deteriorating original LPs. We had played them too often.
The vinyl collection is long gone, a victim of my parent’s move. (I’ll take credit for the Talking Heads and ABC, but the Wham! album was not my fault). With my latest move, my long S&G drought has come to an end.
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: