SBCL 1.2.0 has just been released. The big improvement in this release is support for ARM under Linux. As usual, it compiled and passed the test suite without problems on my OS X systems.
As I say every month, if you’re looking for an excellent Common Lisp implementation, give SBCL a look.
If you write Emacs functions—even for yourself—you are, of course, including a docstring. Functions have a way of escaping from your init.el and finding their way to someone else’s config. Even if that doesn’t happen you may find yourself happy to have a reminder of the function’s details. At least if you’re like me.
It turns out that docstrings have their own mini-markup language. Xah Lee has a nice tutorial on how to use that markup language. I find Lee’s post clearer and easier to read than the Documentation Tips page of the Elisp Manual.
The Emacs built-in documentation is nicely formatted and, when properly done, very useful. Most times, it’s all you need to use a command, function, or variable successfully. By learning and using the markup language that docstrings provide, you can document your code as nicely as the built-in functions.
Irreal is undergoing a sustained spam attack again. This is despite the nucaptcha, which is still working. Either the spammers have defeated it or they’re paying a bunch of people a penny a piece to fill them in. In either case they spam only older posts to reduce the chance that anyone other than Google will notice.
To combat this nonsense, I’ve shut off comments for posts more than a week old. I hated to do this because I sometimes get useful comments on older posts but as usual the spammers are ruining things for the rest of us. Perhaps I can reenable comments on the older posts when the spammers give up and go home.
Sorry for the inconvenience.
If you’re a geek you gotta love this whether or not you’re a Formula 1 fan. I’ve written about Formula 1 racing before so this is two more times than I expected to have anything to say about it.
It’s easy to dismiss racing as a sort of silliness that has nothing to do with the exalted heights to which we nerds aspire. As the two Irreal posts show this is far from the truth. Racing, as it’s practiced today, is extraordinary technical with enough serious challenges to occupy any of us.
I’m still not a racing fan but I do admire the technical challenges that they’ve overcome. If you haven’t seen my first post, take a look at it and follow the links: what the pit crews do is nothing short of extraordinary.
As I wrote the other day, there has been, of late, an ongoing, vigorous debate on the virtues of dynamic versus static typing. There are a lot of muscular declarations from both sides but not a lot of evidence. Now Robert Smallshire has looked into the matter and discovered that dynamic typing is much more effective than it should be.
Even more, he says that the benefits of static typing cost more than the benefits they provide. That’s pretty provocative and of course he gets some push back in the comments. You’ll have to watch the video to see if you think he makes his case.
Even if you’re neutral in static-dynamic skirmishes or don’t care, the video is still worth watching because Smallshire tightens down on what, exactly, we mean by typing and various orthogonal meanings that can apply to that term.
Worth watching if you have any interest in types in programming languages. The video is just under 52 minutes so plan accordingly.
This is by way of an obvious Emacs tip. While I was in my emacs.el adding ace-windows, I decided to fix a problem with ace-jump-mode as well. When I first installed it I used【Ctrl+x Space】as the triggering key sequence. Somewhere along the line that got taken over by GUD so I changed it to 【Ctrl+c Space】 but that doesn’t work for Org files because it’s used to blank table fields so I needed a new binding. I chose 【Hyper+a】 because it easy to type and therefore fast. Once I got that taken care of I starting thinking about ace-jump-mode and realized that I could use it more widely than I’d been doing.
Mostly I was using it for micromovements and using isearch for larger movements as recommended by Steve Yegge but if the place you want to go is on the current page it’s a lot easier and faster to use ace-jump-mode. I just use the first letter of the word I want to go to as the jump target, pick the correct red letter, and I’m there. I could, I suppose, specify the universal argument to jump into the middle of a word but it doesn’t seem necessary.
I’ve been making an effort to follow this plan for a few days now and it’s working out very well. If you aren’t doing this, try it out. You might find yourself with a new habit.
The other day, I wrote about ace-window, a really nice way of quickly jumping from one window to another. I used the suggested key sequence 【Meta+p】 to trigger it so it seemed pretty fast.
After using it for a while, I noticed that it didn’t work with ibuffer because ibuffer uses 【Meta+p】 to move through filters. Since I very often have an ibuffer buffer open, I decided to change the triggering key sequence.
One further thing you should know about ace-window is that if there are only two windows, it simply switches to the window that doesn’t have focus (exactly as if you had typed 【Ctrl+x o】). I remembered that Mathias Dahl had commented that he used 【F1】 and 【F2】 to move between windows because it was a single key and very quick so I decided to use a function key. I chose 【F11】 because I find it easy to reach. Now things are even better. If I have two windows open I can switch between them with 【F11】 and if there are more than two windows, ace-window gets triggered with the same key. A definite win.
Sacha Chua has posted the latest episode in her Emacs Chats series. This time it’s with Bozhidar Batsov, who, among other things, runs the excellent Emacs Redux blog. Batsov is also the author of the prelude, projectile, and cider packages for Emacs.
Batsov talks about how he got started with Emacs, his hopes for its future, and his plans for ongoing Emacs work. He demonstrates some of the features of prelude, a sort of advanced starter kit for Emacs, and his project manager projectile. I was delighted to learn that he uses many of the same micro-optimizations that I do. For example, he’s a big user of ace-jump-mode and ace-windows, two packages that I’m using more and more lately.
The chat is a bit over 53 minutes so you’ll need to set some time aside. The beginning of the chat has some technical problems with bandwidth but once you get through the initial snafus it’s fine. Batsov has made some significant contributions to the Emacs community so I think you’ll enjoy hearing what he has to say.
Update: Added link to the video.
Suppose you have a large, sorted sequence of integers that you wish to store in memory. You need to be able to efficiently add and delete elements to and from the sequence while keeping it sorted. What data structure would you use?
The two natural candidates are arrays and linked lists. Which one do you think is most efficient? If you’re like most programmers you would choose the linked list to limit the amount of data you have to move. For example, if you use arrays and your sequence is 1,000,000 integers long, you will, on average, have to move 500,000 integers for each addition or deletion. With a linked list, on the other hand, it’s simply a matter of adjusting a couple of pointers. It makes sense, then, that a linked list is the most efficient data structure to use.
Except it’s not. The linked list is, in fact, a couple of orders of magnitude slower than using an array. How can this be? It turns out, as Bjarne Stroustrup explains in this video that the process is completely dominated by the linear search to find the insertion/deletion point. The reason for that has to do with the cache; watch the video for the details.
If you’re familiar with Emacs internals, you’ve probably wondered why Emacs treats its buffers as arrays and moves data when it needs to insert or delete characters from the middle of the buffer rather than using a linked list of lines as many editors do. It may seem grossly inefficient to do things this way but as the video shows, it is, in fact, far more efficient on modern machines.
The video is only 7 minutes and 45 seconds but makes an important point. It’s entertaining as well as informative and well worth your time.
I get most of my packages from the MELPA repository and I’m very happy with the results. Some folks object to MELPA because the repository has snapshots of the packages that may not be stable. I’ve seldom had any problems with a package but I can see how others might be concerned.
Bozhidar Batsov has a nice post at Emacs Redux that explains how to get only stable packages from MELPA. The TL;DR is that MELPA has a second repository made directly from Github packages tagged as ready to release by the maintainers. See Batsov’s post for the details.