17
Jan 10

Switching to Cocoa Emacs

… from Carbon Emacs, that is. I pretty much assume that if you aren’t already a dedicated emacs user you will just stick with TextMate or TextWrangler, or whatever.

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.


10
Dec 09

Installing DBD::Oracle on Mac OS X, redux

After upgrading to Snow Leopard, I had to redo the installation of DBD::Oracle. This time I used DBD::Oracle 1.23. The good news is that the majority of my previous instructions no longer appear to be necessary. A normal build of DBD::Oracle looks ugly, but completes.

HOWEVER, I did discover that if you are running a 64-bit perl, which you probably are, you need to get the 64-bit Oracle instantclient release. If you build DBD::Oracle and then cannot load the module because of missing symbols (e.g., _OCIAttrGet), then what is happening is that you linked against 32-bit libraries which cannot load from the 64-bit perl instance.


13
Dec 08

wordpress upgrade (2.7)

Posting about upgrading your incredibly common blogging software isn’t very interesting. But I’m going to take this opportunity to suggest that this time, if you are able, switch to using subversion for wordpress.

Installing wordpress is pretty easy. Upgrading it is also easy, but you still have to move your plugins, themes, and wp-config.php around, or delete stuff that gets in the way. Using subversion makes all of that that go away. Yay!

Update: Sadly, since I have been such a blog slacker, I was able to upgrade to wordpress 2.7.1 while this post was still the top post. Using svn did, in fact, make this the easiest wordpress upgrade I’ve done.

Update 2: Even more sadly, I just upgraded to 2.8.1.


12
Nov 08

How to install DBD::Oracle on Mac OS X

Today, I figured out how to get DBD::Oracle to work on Mac OS X Leopard (intel). Since it isn’t (yet) entirely straightforward, I thought I’d describe the process here:

  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.


03
Aug 08

I has iPhone

After a mere 2.5 hour wait in line, assisted by jet-lag, I have acquired the 3G iPhone. More later.


21
Jun 08

python-rwhoisd

Back in 2003, as an exercise to help me learn Python, I wrote python-rwhoisd. Why an RWhois server? I had been the main developer and sole maintainer of the C reference version since 1996, and I had been thinking about writing a replacement in a nicer language ever since. So I pretty familiar with the protocol and problem space, and it was complicated enough to be able to sink your teeth into it, yet not so hard that you couldn’t do it fairly quickly. Basically, a great learning project.

Back then, I wanted this project to be unquestionably mine. I was paranoid enough to believe that if I used any of my employer’s equipment, network access, or time that my employer might claim ownership. Why they would want to is anyone’s guess.

So I was very careful to only work on python-rwhoisd at home, on my own time, on my own equipment. The initial version took me two weeks of nights and weekends. Hm. That makes it sound like I was furiously coding into the wee hours. I was actually only spending a few hours each day on it.

Python was a joy to use. My day job was in Java (and Perl) and it felt extremely liberating to be able to write so much code with so little typing. My favorite part was discovering that as I learned more about Python, my code kept getting smaller without getting less readable. Amazing!

Even though I had basically just written python-rwhoisd to learn a new programming language, I was planning on releasing it. I didn’t think that many folks would want it. RWhois wasn’t (and still isn’t) a popular protocol. But some of my colleagues were evangelizing IRIS at the time, and urged me to not release. They thought that it would muddy the waters, so to speak. So I didn’t release it, and then I basically forgot about it.

Fast forward five years. Just two weeks ago I suddenly wanted to learn how to use Git. I played around with tutorial-like git repositories, but it wasn’t enough. I needed something real to work on. I was casting about for a project that I could use, and I ran across python-rwhoisd, mouldering in a local CVS repository.

I had things that I thought should be improved about python-rwhoisd before attempting to release it again. The main thing was to add IPv6 indexing support, which I had done for the C version several years before. While this wasn’t a perfect project for learning Git in all of its glory (for that, I would need collaborators to merge with), it was good enough. Several days later, I’d added the IPv6 indexing and search support, and it was time to release it.

While I don’t expect there to be any major outpouring of interest over python-rwhoisd, it still should be easier to run than the C version (at least, for small datasets), and it should be possible to get it working on Windows without too much effort.

Get it here.


30
May 08

Running UNBOUND at home.

I finally got around the setting up unbound as my home resolver. I should have done this months ago, when it was in beta or before, since I had access to it. I kick myself. I feel bad. Oh well, let’s get on with it.

My initial impressions:

  1. It will be nice once there are distribution packages for unbound. I spent more time that I would like (which is zero) figuring out where to put the log file, pid file, etc. Of course, I was installing it on a machine running Fedora Core 5…
  2. I was forwarding a zone to a nameserver running on localhost:20053. There is a gotcha to doing this, as, by default unbound won’t send any queries to localhost. You have to add a ‘do-not-query-localhost: no’ config line to fix it. Maybe this is something unbound-checkconf could detect?
  3. unbound’s configuration defaults leave it locked down fairly tightly. I had it running, but on my other machines, it seemed so slow — turns out, my queries were timing out and I was hitting my ISP nameserver. Make sure you add your networks to the ‘access-control:’ config parameters.
  4. I turned up the logging to debug some of my issues. Looking at the log was uncanny.
Anyway, it didn’t take all that long to set up. Hopefully relatively soon I (or someone else) will write up how to configure unbound to run in a few different scenarios.


09
Apr 08

wordpress upgrade (2.5)

I realized that I was running a now-ancient version of wordpress, so I upgraded. It was easy. Yay wordpress 2.5!


20
Mar 08

Duke 71, Belmont 70

I feel sick, but not as sick as I could feel.

Update: Duke 67, WVU 73. Sigh.


11
Mar 08

RFC 5155

Ben Laurie celebrates the publication of RFC 5155. I hadn’t gotten around to blogging about it, but I’m also pretty happy that this RFC finally made it out.

Ben says:

It turns out that in general, to prove the nonexistence of a name using NSEC you have to show at most two records, one to prove the name itself doesn’t exist, and the other to show that you didn’t delegate some parent of it. Often the same record can do both. In NSEC3, it turns out, you have to show at most three records. And if you can understand why, then you understand DNS better than almost anyone else on the planet.

One of the fascinating things about working on NSEC3 was that it forced us to really understand how existence in DNS works. Basically, we had to develop the general form of the theory when we already had a special case (in NSEC). So, after we figured out how NSEC3 had to work, we actually knew more about how NSEC worked.

For me and our co-editor Roy, this RFC culminates the 2nd round of working on the some of the problems that NSEC3 solves. The first effort was “DNSSEC Opt-In”, now published as an experimental RFC, RFC 4956. (That effort was also tied up in DNS minutiae and political wrangling and ultimately failed to make the IETF standards track). For us, it feels more like the culmination of 7 years of work.