Archive for June, 2008

Updating Metadata for 722 gems! AARGH!

Thursday, June 26th, 2008

Seriously. Is this really necessary?

alex@21:~/Documents/Projects/VPNGen$ gem search scp --remote

*** REMOTE GEMS ***

Updating metadata for 722 gems from http://gems.rubyforge.org/
..............................................................................................
..............................................................................................
..............................................................................................
...............................ERROR:  Interrupted

Clojure, Slime, Documentation?

Thursday, June 26th, 2008

Update: It turns out that the Gutsy-included version of slime is rather out-of-date, and the clojure scripts are based on the CVS version. If you’re having the problem below, get thee hence and cvs thyself.

There seems to be a general theme in the emacs world. If I could give it a voice, it might say “I’m great. No, I’m not going to tell you how to use me. You mean you don’t already know?”

Let me put this in context. You might be able to tell from my previous posts that I’ve got a long-standing, from-a-distance interest in all things lispy. Naturally, my attention fell on Clojure (fairly recently, admittedly). My next thought was that I should get slime set up to use it so that I could use a natural environment to try it out, and this is where things started to get dicey.

Almost everything works; here’s the relevant section from my .emacs:

(defun set-clojure-inferior-lisp ()
  (setq inferior-lisp-program
        (let* ((java-path "java")
               (java-options "")
               (clojure-path "~/Documents/Projects/clojure/bin/")
               (class-path-delimiter ";")
               (class-path (mapconcat (lambda (s) s)
                                      (list (concat
																						 clojure-path "clojure.jar"))
                                      class-path-delimiter)))
          (concat java-path
                  " " java-options
                  " -cp " class-path
                  " clojure.lang.Repl"))))

(defun clojure-boot ()
  (interactive)
  (require 'slime)
  (setq slime-net-coding-system 'utf-8-unix)
  (slime-setup)
  (add-to-list 'load-path "~/emacs/clojure-mode")
  (require 'clojure-auto)
  (set-clojure-inferior-lisp)
  (setq slime-lisp-implementations
        '((clojure ("~/emacs/clojure-extra/sh-script/clojure")
                   :init clojure-init)))
  (add-to-list 'load-path "~/emacs/swank-clojure")
  (require 'swank-clojure)
  (cua-mode t)
  (slime))

The annoying thing is what doesn’t work: exceptions are getting lost, and the error message that comes back for each and every one is distinctly unhelpful:

error in process filter: Wrong number of arguments: nil, 3

Where do I go from here? Google knows nothing of this error. I’ve emailed the author of the swank-clojure code for assistance; I’ll update here if I get anywhere with this. It’s really frustrating to be this close to what looks like a brilliant development environment, just to hit a brick wall like this.

VirtualBox, KVM, Windows and Linux

Thursday, June 12th, 2008

Today I’ve been mostly bringing a new subcontractor up to speed on a project I’ve been working on for a while. It’s quite a fun project that I’ll probably post about at some later date (think _why’s mousehole on steroids), but what I’ve spent most of my time on is wrangling virtual machine images.

For me, kvm is the first (free) virtual machine host system that makes everything Just Work. I always had problems with UML and Xen, qemu was too slow, and I always shied away from VMware. Not entirely sure why, but there you go.

Now, back to this contractor: he’s on Windows, I’m on Ubuntu Gutsy. I know that my code won’t work on Windows, because I’m daemonising and fork()ing all over the place. VMs to the rescue! It looks to me like the best combination is kvm on my side, and VirtualBox on his. There’s a very simple conversion that lets me convert my qcow image to a vmdk that VirtualBox can read:

qemu-img convert etch-rodents-i386.img -O vmdk etch-rodents-i386.vmdk

I’ve not seen this documented anywhere; most google hits mention the obsolete vditool, which I couldn’t get to run on my 64-bit host anyway.

Added bonus: the vmdk image is slightly smaller than the qcow. Win.

Entries (RSS)