davidb dives in

In contemplating a move back to Linux for my day job, or at least a future where more of my work is done directly on my Linux box, I began to pine for decent anti-aliased fonts for emacs.

Both the windows and mac builds of emacs 22 have this support built-in. Although, good luck trying to figure out how to change the font to what you want, at least in Carbon Emacs. Fortunately the default font of Monaco is pretty good (albeit not perfect). I don’t have a lot of experience with EmacsW32, even though I do have it installed somewhere.

At first, I was puzzled as to why emacs just didn’t come with anti-aliased fonts on Fedora 7 by default. Some web searches led me to believe that support was to be merged in before emacs 22.1, and there I was, running 22.1. Alas, I had misread the interweb. If support has been merged in, it has been merged in after 22.1. Since 22.1 is the latest stable version of emacs (as of this writing), it isn’t all that surprising that Fedora 7 doesn’t have this.

Ah, well, time to move to the bleeding edge. Concise instructions for building a CVS version of emacs with anti-aliased fonts can be found on the XftGnuEmacs page. I didn’t have a whole lot of trouble building and installing this version, but what I really want is a Fedora 7 package to replace the delivered packages. If I were running Ubuntu, this wouldn’t be much of a problem.

So far, my attempts to hack the existing source RPM for emacs haven’t met with much success. It doesn’t help that emacs take a while to compile, and I keep having to completely start over. I’ll update this entry if I ever get an rpm built.

Update: I’ve managed to work through the major issues, so here is the source RPM for Fedora 7. I’ve put some actual binaries here. This version doesn’t replace the stock emacs-22.1. Instead it installs into /usr/local, but can easily be made the default version via the alternatives command:

alternatives --set emacs /usr/local/bin/emacs-23.0.0

Now that I have a working version of emacs with anti-aliased font support, I’ve been hunting down what font to actually use. Bitstream Vera Sans Mono is a good default, but at the moment I’m trying out Anonymous. For the curious, the bit of elisp that I’m using to set the fonts is this:

(if (eq window-system 'x)
    ;; if we have the Xft-enabled version of emacs...
    (if (>= emacs-major-version 23)
    (progn
      ;; note: Anonymous doesn't come with Fedora.  You can get it here:
      ;; http://www.ms-studio.com/FontSales/anonymous.html
      (set-default-font "Anonymous-10")
      (setq bvsm10 "Bitstream Vera Sans Mono-10")
      ;; unfortunately, anonymous doesn't have bold or italic
      ;; so, use bitstream vera sans mono for that
      (set-face-font 'bold (concat bvsm10 ":weight=bold"))
      (set-face-font 'italic (concat bvsm10 ":slant=oblique"))
      (set-face-font 'bold-italic
             (concat bvsm10 ":weight=bold:slant=oblique"))
      ;; ...and no proportional font, for that matter
      (set-face-font 'variable-pitch "Bitstream Vera Sans-10")
      (add-to-list 'default-frame-alist '(font . "Anonymous-10")))
      ;; otherwise...
      (progn
    (set-default-font
     "-*-lucidatypewriter-medium-r-*-*-14-140-*-*-*-*-*-*"))
      )
  )

I’m doing it this way (instead of in X resources) so that launching emacs-22.1 will still work. If you stick with Bitstream Vera Sans Mono (or DejaVu LGC Sans Mono which is very similar), then you won’t have to bother with overriding the bold, italic, and bold-italic font settings as those will basically just work once you set the default font. You would still have to deal with overriding the proportional font, however.

I was visiting my friend Joe when I was reminded of my theory as to why BEEP (RFC 3080) hasn’t really taken off like it should have. The catalyst for this discussion was my remembering a fairly recent discussion on the (mostly inert) beepwg mailing list. In this discussion, I was reminded that it is seemingly fairly common for implementers (or potential implementers) to really not understand certain aspects of how BEEP works. In this case, it was the use of SEQ frame. This was a particular point of concern when I was writing my own BEEP implementation, Net::BEEP::Lite.

But, let’s step back for a minute. Imagine if you are working on a new project that needs an application-level transport, and one isn’t immediately obvious. You now have two choices: 1) write your own protocol, or 2) reuse an existing protocol. Option 2 is very attractive, because option 1 seems hard. So, you look for a transport protocol to reuse. (BEEP is very attractive for this, as this is its purpose.) Now, lets say you choose your transport, but, after a little investigation there are no suitable implementations to reuse. Now, as a developer, you have to ask yourself a question: can I both write my application AND write enough transport code to make it work? This is what I call a complexity threshold. In general, if you can write the transport code in about 3 days or less, I would think that the answer to the question would be yes. Of course, this threshold is somewhat subjective, but, in general, BEEP fails this threshold. It would probably take three days just to understand what needed to be written. In other words, BEEP is complex enough that it always looks like it needs to be its own project.

Now, of course, this threshold is moot if you can find an implementation to reuse. However, this leads to the next issue: how likely is it that you will be able to find an implementation that you can reuse? In BEEP’s case, this is largely an issue of either BEEP being easy enough to understand and implement by “average” developers, or there being a driving application that attracts enough talent to create good implementations. (There are other issues when trying to reuse other application transports, but I’ll most likely cover them in a different post.) If the second condition is true, then it almost doesn’t matter how hard BEEP is to implement (although, one could certainly argue that a hard to implement protocol wouldn’t likely have a driving application in the first place). However, in BEEP’s case, this doesn’t appear to be true. So it comes down to how difficult BEEP is for someone to write casually. This is the second complexity threshold.

Now, after surveying a number of open-source BEEP implementations, I found them to either be incomplete (in some critical way), broken, and/or quite difficult to use. This, and my own experience, leads me to believe that BEEP is above this complexity threshold as well. Exacerbating this somewhat is the fact that, on the surface, BEEP really isn’t that complex or difficult to understand. But when you delve a bit further, I think it turns out to be more difficult that it first looked, and I think some developers overreact to this, making their implementation more complicated still. Of course, an excellent example, or more documentation, can effect how complex BEEP is to implement. And, of course, how difficult something is to develop is in the eye of the beholder.

I’ve been programming in Java since sometime in 1997, and in all this time I have never embraced certain, now ubiquitous seeming, Java technologies. Mainly I’m thinking about the whole J2EE thing. Partly this is because I haven’t paid much attention to this (huge) development in Java. Partly this is because in 1998 or ‘99 I remember reacting very strongly to an attempt to convert my employer’s entire back office to J2EE.

Back then, I was reacting against doing engineering for engineering’s sake. I had no patience for computer science projects, which is what a J2EE conversion looked like to me. As I researched what EJB’s (the primary J2EE thingamajig back then) would give us that we didn’t already have, the only thing I could find was distributed transactions. I’m sure that there a few businesses that need distributed transactions, but I think that they are few and far between, and for certain we weren’t one of them. I didn’t have decision making power back then (and still don’t, for that matter), but I manage to write a convincing email. The J2EE conversion project never happened.

Since then, JSP was invented (and reinvented), JBOSS was released, J2EE seemingly took over. I’ve never like JSPs. I’ve like the concept of JSP, but not the actual execution. I haven’t looked at JavaServer Faces. I’ve been using Velocity for this task — very simple, very easy. In general, I’ve been sticking to J2SE and Apache Jakarta stuff. Does this make me a Java Luddite?

As I move my current project over to subversion, I’m getting a better feel for what subversion is really like to live with. I just started, so I don’t really have a solid impression yet. I do have some not-so-solid impressions, however:

1. On the command line, I still instinctively type “cvs” instead of “svn”.
2. When I type the right thing, the command line is nicer than CVS. The existence of svn status and svn revert is what I like so far.
3. Subclipse isn’t really all there yet.

Now, when I said before that I got Subclipse working, I wasn’t lying. But, my main motivation for getting it to work at all was to use Eclipse’s “Synchronize with Repository” command. That feature of Subclipse, it appears, is not fully baked. When you try it, all sorts of relatively bizarre behavior manifests itself.

You can still browse repositories, commit changes, modify properties, and the like, which is actually still pretty cool.

I’ve been moving my small work group from CVS to Subversion. Not that we make huge demands on our CM system, but Subversion is an obvious step up.

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.