Copy to Mac OS X Clipboard from Vim

Here's a short, but nifty, addition to your ~/.vimrc that'll make copying to your Mac's clipboard a little easier:

map cc :w !pbcopy

Typing 'cc' in command mode will put the entire current buffer into the clipboard. If you type 'cc' while you have lines selected in visual mode, it'll only copy those lines.

Woo!

From Common Lisp to Clojure (Part 1)

I recently started tinkering around with Clojure as a test to see if I could replace Java with a Lisp-like language. For those unfamiliar with Clojure, here's a quick intro to what it's all about:

Clojure is a dynamic programming language that targets the Java Virtual Machine. It is designed to be a general-purpose language, combining the approachability and interactive development of a scripting language with an efficient and robust infrastructure for multithreaded programming. Clojure is a compiled language - it compiles directly to JVM bytecode, yet remains completely dynamic. Every feature supported by Clojure is supported at runtime. Clojure provides easy access to the Java frameworks, with optional type hints and type inference, to ensure that calls to Java can avoid reflection.

As a regular user of Common Lisp, it has taken some adjustment to get used to Clojure's syntax choices, but I'm starting to believe that they are for the better and will allow those unfamiliar, or afraid of Lisp, to give it a try. A small example is the new syntax for LET; a function that binds values to variables. The code below in Common Lisp would assign 3 to x, and x + 1 to y:

(let* ((x 3)
       (y (+ x 1)))
  ...)

In this case, we have to use LET*, which evaluates things sequentially (LET does the assignment in parallel). In Clojure, however, LET is always LET*, and a lot of the extra parentheses are removed. The above would be written like the following in Clojure:

(let [x 3
      y (+ x 1)]
  ...)

The []'s were originally introduced in Scheme to make heavy paren code (LET, COND, etc.) easier to read, but was never enforced. I never used the [] helpers while writing Scheme, but I can understand why they might increase readability. Aside from the few syntactic differences, I felt more or less right at home using Clojure, with the added ability of being able to easily interface with Java programs.

Dynamic Java?

Despite Clojure's dynamic nature, we can still drop down to enforce typing when performance is an issue. I've started to switch over to Clojure as my primary language for Project Euler problems, and one of the first things I needed to write was an efficient prime number sieve. I more or less copied the algorithm from Roger Corman's Lisp examples, without the type decoration as I was unsure how to do it in Clojure. I ended up with the following as a result:

(defn unoptimized-sieve [n]
  "Returns a list of all primes from 2 to n"
  (let [root (Math/round (Math/floor (Math/sqrt n)))]
    (loop [i 3
           a (make-array Boolean n)
           result (list 2)]
      (if (>= i n)
        (reverse result)
        (recur (+ i 2)
               (if (< i root)
                 (loop [arr a
                        inc (+ i i)
                        j (* i i)]
                   (if (>= j n)
                     arr
                     (recur (do (aset arr j true) arr)
                            inc
                            (+ j inc))))
                 a)
               (if (not (aget a i))
                 (conj result i)
                 result))))))

Notice the use of Java's java.lang.Math.round/floor/sqrt functions and the Boolean type. The first thing I noticed was how slowly this ran compared to my Common Lisp version. Finding the first 100,000 primes took a little longer than I anticipated.

user> (time (last (unoptimized-sieve 100000)))
"Elapsed time: 6160.188 msecs"                                                                                                                                                       
99991

I knew being able to tag types would increase my runtime dramatically, as it had done with the Common Lisp version, so I went ahead and did just that.

(defn sieve [#^Integer n]
  "Returns a list of all primes from 2 to n"
  (let [root (Math/round (Math/floor (Math/sqrt n)))]
    (loop [#^Integer i 3
           a (make-array Boolean n)
           result (list 2)]
      (if (>= i n)
        (reverse result)
        (recur (+ i 2)
               (if (< i root)
                 (loop [arr a
                        #^Integer inc (+ i i)
                        #^Integer j (* i i)]
                   (if (>= j n)
                     arr
                     (recur (do (aset arr j true) arr)
                            inc
                            (+ j inc))))
                 a)
               (if (not (aget a i))
                 (conj result i)
                 result))))))

A few simple compiler hints (shown in bold) dramatically reduced the running time:

user> (time (last (sieve 100000)))
"Elapsed time: 164.058 msecs"                                                                                                                                                        
99991

Quite the speed bump for very little work if I do say so myself. Now I can finally start solving more Project Euler puzzles!

So... What Do I Think?

I obviously haven't played around with Clojure too much, but here are my current pros and cons.

Pros

• On the JVM: For the work that I do, I find myself writing a decent amount of Java code. A great deal of my classes provide code for assignments written in Java and I have to decide between rewriting provided code in a language I like, or using Java. Now, I don't have to make that choice anymore.
• Data Structures are Immutable: One of the things I love about Lisp is you can do whatever you want. Program functionally, imperatively, object-oriented-ly, ..., the list goes on and on. But the more I used it, the more I realized I just did everything functionally. Clojure takes a big step for Lisp in forcing immutable data structures and basically forcing the programmer to think functionally. The main benefit lies in concurrency, which I plan on exploring in the near future.

Cons

• No Tail Call Optimization: You're probably thinking "how can a functional language not have tail call optimization?" which is exactly what I thought when I read it. Unfortunately the JVM does not provide such a facility, luckily Rich Hickey provided a workaround in the form of RECUR. It essentially is just a goto that rebinds the variables to the new values in the most recent LOOP or DEFN call. In the second RECUR in the example above, (do (aset arr j true) arr) is set to arr, inc is set to inc and (+ j inc) is set to j in the most recent LOOP call, and the forms are re-evaluated. It's kinda hacky but it works, and with any luck the new JVM will have TCO and we'll be all set.
• Lack of Robust Documentation: Perhaps I'm a bit spoiled with JavaDocs and the CL HyperSpec, but I do find the Clojure documentation a bit lacking. This is entirely understandable as the language is very new, but it is definitely something that would turn off those new to Lisp. Luckily, with a "Programming Clojure" book on the way, things are looking up in that department as well :).

All in all, I think Clojure is very promising and I hope to see the community thrive. It's slowly winning me over, which isn't too tough once I can work in a great environment for a REPL-based language.

EDIT: an even faster version that uses primitives (courtesy of Rich Hickey in the comments):

user> (time (last (sieve 100000)))
"Elapsed time: 17.963 msecs"                                                                                                                       
99991

:)

emacs-w3m 100% CPU Usage on Mac OS X

emacs-w3m is a simple interface from emacs, to the text browser w3m. The main reason I started using it was it allows me to quickly look up information in the Common Lisp HyperSpec without having to Cmd+Tab away from emacs, giving a pretty nifty way to view the HyperSpec. All of a sudden, when I would launch emacs, it would hang with w3m sucking up 100% of my CPU. I finally found the problem on a mailing list, apparently it's some bug in gc, the garbage collector w3m uses. To make a long story short, adding

(setenv "GC_NPROCS" "1")

to your

~/.emacs

file before w3m/emacs-w3m is required, eliminates the problem.

My .screenrc

As per request, here's my .screenrc:

# skip the startup message
startup_message off

# Automatically detach on hangup.
autodetach on

# If a screen dies, don't freeze the whole screen waiting for it.
nonblock on

# Change default scrollback value for new windows
defscrollback 10000
scrollback 10000

# start with visual bell as default
vbell off
vbell_msg "Bell on %t (%n)"

# look and feel
caption always "%3n %t%? @%u%?%? [%h]%?%=%c"
termcapinfo xterm 'hs:ts=\E]2;:fs=\007:ds=\E]2;screen\007'
hardstatus alwaysignore
hardstatus alwayslastline '%{gW}%-w%{.wb}%n %t%{-}%+w %=%{.w}'


activity "Activity in %t (%n)"

Gives you this.

I shamelessly stole this from someone on the Something Awful Forums.

Nested screen sessions rule

While it can quickly get a tad precarious, having a nested screen session is pretty damn cool.



Switching between them is pretty simple. '^a' tells the terminal it's a screen command. Simply hitting an additional 'a' tells it it's the nested screen, and so on, depending on how many times you hit a (obviously, this would get too difficult to work with, hitting a five times just to send a command to a screen is a waste of everyones time). So, in this image, '^a a n' would shift the nested screen to the next 'tab', and so on.

Distributing Common Lisp Code -- Executables Say What?

One of the most common questions asked by those new to Lisp is how to make a nice, shiny executable. How do I make "Hello, World!" in Lisp like I have in C? I spent hours earlier today looking for various ways to package things, and it seems as though relying on our good old friend bash is the best solution, at least, if you're dealing with the SBCL implementation of Common Lisp. I wrote this to be a nice little guide, so others don't have to scour comp.lang.lisp themselves for answers.

We'll start with a simple example doing everything manually, then script everything. "Hello, World!", here we come! First off, let's get some code going for hello.lisp. (bear with me here, this is a convoluted way to do Hello World in Lisp, however, it'll make it easy to understand how to pull together larger applications)

hello.lisp

(format t "Hello, World!~%")

Looks innocent enough. But how do we run this guy now? The traditional way is to bust open an SBCL REPL, and either load/interpret the symbols, or compile it and run it from within SBCL; we're going to do the latter.

dhcp223:~ ynadji$ sbcl
* (compile-file "hello.lisp")
; compiling file "/Users/ynadji/hello.lisp" (written 15 OCT 2007 04:00:10 AM):
; compiling (FORMAT T ...)

; /Users/ynadji/hello.fasl written
; compilation finished in 0:00:00
#P"/Users/ynadji/hello.fasl"
NIL
NIL
* (load "hello.fasl")
Hello, World!
T

Sexy, our first Lisp program! But see how much of a pain it is to manually compile the file, then run it? Imagine this with several files with inter-dependencies! It's difficult in Lisp to do what you would do in C, however, you can fake it with some very simple bash scripts and some elbow grease¹.

The first step is to set up your files into packages, and handle those properly. I'm not going to describe Lisp packages in depth here, please see this for a more complete reference. The example I'm going to give is with a sudoku puzzle solver I wrote in Lisp. It's quite horrendous Lisp code, but it'll illustrate my point nonetheless. Below are the package definitions for the two files in this application:

config-parser.lisp

(defpackage :config-parser
  (:use :cl)
  (:export #:sudoku-config-parse)
  (:export #:sudoku-config-dump))

(provide :config-parser)
(in-package :config-parser)

and

sudoku.lisp

(defpackage :sudoku
  (:use :cl :config-parser)
  (:export #:backtracking))

(provide :sudoku)
(in-package :sudoku)

What's important to note is that sudoku.lisp depends on config-parser.lisp and sudoku.lisp exports the function BACKTRACKING. We see this in the following steps, where we write our Makefile to take care of compilation and our bash script to run BACKTRACKING.

Makefile

all:
        sbcl --noinform --eval "(progn (compile-file \"config-parser.lisp\") (compile-file \"sudoku.lisp\") (quit))"

clean:
        rm -f *.fasl

SBCL allows you to pass in a form to evaluate. You see here I compile both files (in the correct order), then quit SBCL to drop me back down into my shell. Running 'make all' compiles both files and leaves me with two .fasl (compiled Lisp code)

dhcp223:~/Code/Lisp/sudoku ynadji$ make
sbcl --noinform --eval "(progn (compile-file \"config-parser.lisp\") (compile-file \"sudoku.lisp\") (quit))"
; compiling file "/Users/ynadji/Code/Lisp/sudoku/config-parser.lisp" (written 06 OCT 2007 01:55:55 PM):
;; (each function from config-parser.lisp is compiled here)
; /Users/ynadji/Code/Lisp/sudoku/config-parser.fasl written
; compiling file "/Users/ynadji/Code/Lisp/sudoku/sudoku.lisp" (written 15 OCT 2007 02:11:19 AM):
;; (each function from sudoku.lisp is compiled here)
; /Users/ynadji/Code/Lisp/sudoku/sudoku.fasl written
; compilation finished in 0:00:00

With this taken care of, now it's time to write our bash script to execute everything. Using what we learned from in the compile phase, it's easy to see the same logic (evaluating forms from the SBCL command-line) can execute our code as well as compile it.

sudoku.sh

#!/bin/bash

if [ $# -eq 0 ]
then
        echo "Usage ./sudoku.sh INPUT_PUZZLE [SOLUTION]"
else
        if [ $# -eq 1 ]
        then
                sbcl --noinform --load config-parser.fasl --load sudoku.fasl --eval "(progn (sudoku:backtracking \"$1\") (quit))"
        else
                sbcl --noinform --load config-parser.fasl --load sudoku.fasl --eval "(progn (sudoku:backtracking \"$1\" \"$2\") (quit))"
        fi
fi

The two fasls are loaded and this time, the evaluation uses the symbols compiled from our code. You notice it once again uses PROGN to sequentially evaluate what we want, then quit SBCL. If any errors are encountered, we get thrown into the SBCL debugger, but our code is perfect and doesn't have that problem, right?

Empty Sudoku Puzzle: hard1.txt

2, ,1, , ,5, , , 
 ,6,7, , , , , ,8
8, , , ,6, , , , 
 , ,9,6, , , ,1, 
 , ,8, ,7, ,3, , 
 ,3, , , ,1,4, , 
 , , , ,9, , , ,3
7, , , , , ,6,8, 
 , , ,3, , ,5, ,1

dhcp223:~/Code/Lisp/sudoku ynadji$ ./sudoku.sh hard1.txt solution.txt
"Nodes expanded:" 
39555 
dhcp223:~/Code/Lisp/sudoku ynadji$

Solved Sudoku Puzzle: solution.txt

2,9,1,8,3,5,7,6,4
3,6,7,2,1,4,9,5,8
8,5,4,9,6,7,1,3,2
4,7,9,6,2,3,8,1,5
5,1,8,4,7,9,3,2,6
6,3,2,5,8,1,4,9,7
1,8,5,7,9,6,2,4,3
7,4,3,1,5,2,6,8,9
9,2,6,3,4,8,5,7,1

This sure beats fumbling around in SLiME every time I want to quickly solve a sudoku puzzle! If you're interested in playing around with this yourself, I've posted my code (with Makefile/bash script) on my webspace for you to use. Most likely the included fasls won't work on your machine, and you'll have to recompile them for your version of SBCL, but that's a simple 'make' command away :).

Footnotes

1. I wanted to mention that something as simple as Hello World can be made into an executable with SB-EXECUTABLE, however, it's difficult to use with larger programs and it does essentially the same thing, create a trampoline to launch your code through SBCL. For example:

dhcp223:~ ynadji$ sbcl
This is SBCL 1.0.9, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.

* (require 'sb-executable)

("SB-EXECUTABLE")
* (compile-file "hello.lisp")

; compiling file "/Users/ynadji/hello.lisp" (written 15 OCT 2007 04:00:10 AM):
; compiling (FORMAT T ...)

; /Users/ynadji/hello.fasl written
; compilation finished in 0:00:00
#P"/Users/ynadji/hello.fasl"
* (sb-executable:make-executable "hello" "hello.fasl")

T
0
* (quit)
dhcp223:~ ynadji$ ./hello 
Hello, World!

The problem with SB-EXECUTABLE is there isn't a way (AFAIK) to create a trampoline with multiple fasls. And if there is, they sure as hell don't make it easy to find. I'd recommend against it.

Linux iTunes Serving with mt-daapd

Ever since I've gotten my MacBook, I've been a little spoiled with new technology. And with that, my aging Debian desktop is nearly unbearable to use. I love Linux and I'm very attached to this computer too, so I've been setting it up so the things I use the machine for, can be done over ssh/server-based tools. For example, I now use Azureus' nifty web-interface, since I need packet encrypting, and AFAIK, Azureus and uTorrent are the only clients that support it outside of the box. The last thing I really needed to do was find a way to efficiently stream my music collection to my MacBook since gnump3d just wasn't really cutting it.

So naturally, I start googling around and stumbled upon this post on macosxhints.com titled "Use a Linux box as an iTunes music server". Fortunately, that sounds like exactly what I want! Unfortunately, I couldn't get mDNSResponderPosix to compile for the life of me. You'd think a vendor who tried to pretend to support open source would offer some support, binaries, documentation, or something to make such a useful tool like mDNSResponder install properly. There are tons of hits of mDNSResponder not compiling properly, but no one had my problem, and very few of them actually solved their problem. I understand Apple's support of open source is pretty much non-existant, but that's the beauty of it. Any slack they drop, gets picked up by the community, which is where mt-daapd comes in.

mt-daapd is an implementation of Apple's Digital Audio Access Protocol (DAAP), which is essentially an HTTP server catered towards serving music across a local network. And since iTunes is pretty much the only competent audio player on OS X (which is both scary and depressing), mt-daapd and iTunes get along quite well.

The install is very painless:

$ sudo apt-get install mt-daapd

and you're more or less finished. Either edit /etc/mt-daapd.conf or launch http://localhost:3689 (the default port for iTunes music sharing) to open up a nice configuration tool to get things set up properly. I'm not a huge fan of the GUI configs, especially when you have a nice, simple text file to set all your settings. Regardless, the config tool they have is pretty nice, especially for someone not familiar with something like this. As soon as the daemon has started, you're ready to listen to your music with iTunes. It's as simple as that. The only problem I forsee is how the database is stored. It organizes song by inode, so your audio files must all be on the same hard drive. Luckily for me, I've got my nice 300 GB external with all my tunes on it, and I'll probably just buy a much larger hard drive if I ever need to.