## SBCL 1.2.10

SBCL 1.2.10 is out and available at the usual place. This month's release is mainly bug fixes, although there is one enhancement. You can get all the details from the NEWS page.

As usual, the system built and ran the regression tests without incident on my OS X 10.10.2 systems. Rather than give you my usual monthly paean to the outstanding team of SBCL developers, I'll leave you with these observations from a satisfied customer.

Posted in Programming | Tagged , | Leave a comment

## News From the Emacs vs. Vim Front

Via reddit: an oddly satisfying exchange.

Posted in General | Tagged | 1 Comment

## Org Capture Video

Jonathan Magen recently gave a talk to the New York Emacs Meetup group on using Org capture. His setup is a little different from mine so it was interesting to see how he did things.

If you're an Emacs user and not taking advantage of Org capture, you're really missing out. I set it up when I first starting using Org mode using Bernt Hansen's excellent Org Mode — Organize Your Life in Plain Text as a guide. His work flow is a bit different from mine so I wasn't really taking full advantage of it until recently when I added capture templates for blog ideas, my journal, and other specialized tasks.

Those capture templates have really made a difference. It's easier and faster to capture data and because they are customized to my work flow the end results are more useful to me.

It's definitely worth spending some time learning the capture system. A good way to get a feel for it is with Magen's video. It's about 15 minutes so you don't need to block out a lot of time.

Posted in General | Tagged , | Leave a comment

## Hunting for Bugs in init.el

If you're an Emacs user and have a non-trivial .emacs or init.el you have almost certainly run into the situation where you make a change or upgrade a package or Emacs and things stop working. I see questions about how to troubleshoot this from n00bs all the time.

Invariably, the advice is to do a binary search on your configuration file by commenting out half of it and seeing if the errors persists and then commenting out half of the other half if so. That process converges in $\log_{2} \,n$ time for $n$ lines. That's pretty quickly for most .emacs or init.el files but is still a pain.

Happily, the prolific Artur Malabarba—when does he have time to work on his thesis?—has come to the rescue with elisp-bug-hunter. If you get an error while loading Emacs, just run

M-x bug-hunter-init-file RET RET


and bug-hunter will do the binary search for you. You'll get a nice report showing where the error occurred. That's pretty nice but bug-hunter is even more flexible. Suppose Emacs loads without error but some aspect doesn't work correctly. If you can write an assertion to detect the error, bug-hunter can still find the problem.

The example Malabarba gives is figuring out how cl.el is getting loaded. To do that, you just run

M-x bug-hunter-init-file RET (featurep 'cl) RET


and bug-hunter will tell you where it's getting loaded. That very issue has come up with my own init.el file so I ran that example and discovered that package-initialize was loading the library. That's very nice indeed. Malabarba gives other examples in the README at the link.

I've loaded bug-hunter now so that it will be available the next time I need it. You could probably get it loaded after the fact but why make life harder than it needs to be?

Posted in Programming | Tagged | 2 Comments

## Killing dired Buffers

Here's a nice tip on how to get rid of a dired buffer by killing it rather than burying it.

## A Bit of Wisdom from John Carmack

For an wonderful and revealing example of using s-expressions for data interchange, see the paper I discussed in this post from my old blog.

## Finally, Some Sanity

I've written before (1, 2, 3, 4) about the insanity that is the open plan office. One would think that it would have withered and died by now but, sadly, it seems as robust as ever. At least the successful tech giants understand how deleterious it is, right? Nope. Facebook's new office space will include a single giant 10 acre room for all 2,800 of their engineers. I can't conceive of working in such an environment or why anyone would think it's a good idea.

Over at Stack Exchange they still believe in private offices but note that the once revolutionary notion that Joel implemented makes them feel sort of old fashioned: like something that Microsoft does. You can read that post to see why it's so successful for them. It helps explain Fog Creek's and Stack Exchange's success.

Now, finally, some tech firms are beginning to notice that the emperor has no clothes. Wildbit is abandoning their open office layout for private offices. Chris Nagele blogs about it and lays out the reasons for the change. It's a good read so you should take a look. Meanwhile, Matt Blodgett has pictures of some of these open office layouts and proposes a game called “spot the desks.” In every case you see really nice looking offices but when you start looking for the desks, you find they're all packed together as if a second thought.

Reading the comments to these posts I was a bit surprised to find that even some engineers are buying into the “improves communication” nonsense. Lots of people have all sorts of anecdotes about the virtues of open office spaces but Microsoft and others have done actual research and found that they're disastrous for worker productivity and health. So much so that they've gone to the expense of building out private office for their developers.

Of course, none of this is news. Demarco and Lister knew all this 37 years ago. I was working in a cube farm when I first read it and loaned it to our CEO hoping that things would improve. The only thing that changed is that I no longer had a copy of Peopleware because he never gave it back.

Still, Wildbit and others like them give hope that sanity will eventually prevail. If that happens, I wonder what Zuckerberg will do with that big room.

Update: Just today, I had occasion to reread Paul Graham's Great Hackers in which he says

After software, the most important tool to a hacker is probably his office. Big companies think the function of office space is to express rank. But hackers use their offices for more than that: they use their office as a place to think in. And if you're a technology company, their thoughts are your product. So making hackers work in a noisy, distracting environment is like having a paint factory where the air is full of soot.

The cartoon strip Dilbert has a lot to say about cubicles, and with good reason. All the hackers I know despise them. The mere prospect of being interrupted is enough to prevent hackers from working on hard problems. If you want to get real work done in an office with cubicles, you have two options: work at home, or come in early or late or on a weekend, when no one else is there. Don't companies realize this is a sign that something is broken? An office environment is supposed to be something that helps you work, not something you work despite.

Notice Graham is complaining about cubicles. It would be interesting to read his thoughts on a huge 10-acre room at which developers sit at big tables. The point stands though: as Graham says, if you arrange to have your developers be interrupted continuously, don't expect good results.

Posted in General | Tagged , | Leave a comment

## How to Install an Info File

I just wrote about implementing abo-abo's solution for having multiple Info buffers and in particular his using the gcl Info file as a substitute for the Common Lisp HyperSpec. I really wanted to try that out so I downloaded the tar file from the link that he provided and installed it in my .emacs.d directory. Then, as abo-abo explained, I added ~/.emacs.d/info to the Info-additional-directory-list variable.

Sadly, it didn't work. I asked abo-abo for his wisdom on the matter and he suggested that I just push the .emacs.d/info directory directly onto the Info-directory-list. I tried that and it didn't work either. I could get to it with the standalone Info reader by using the -f option but couldn't get to it from Emacs.

The problem was that the gcl file was not being added to the dir file that serves as the top node for Info. The proper way to do that is to run install-info. In my case

sudo install-info gcl.info /usr/share/info/dir


Annoyingly, it still didn't work. It turns out that install-info extracts data from the Info file you're installing to update the dir file. For some reason the gcl.info file didn't have the required information. I adapted the information from the sbcl.info file, added it do gcl.info, reran install-info, and everything worked fine. Unless you're trying to use the gcl.info that abo-abo linked to, you don't have to worry about that; just run install-info.

If you're trying to install the gcl file, here is what you need to add to the top of gcl.info

INFO-DIR-SECTION Software development
START-INFO-DIR-ENTRY
* gcl: (gcl).           The GNU Common Lisp compiler
END-INFO-DIR-ENTRY

Another nice thing that abo-abo pointed out in his post was that the gcl Info file can serve as an Info-based HyperSpec. He explains how to get the gcl Info file and install it. If you're a Common Lisp user, this is very nice. It's not the HyperSpec, of course, but has the same information. I'm also planning on implementing that and trying it out.