How do you make your Clojure REPL suck less?

Simple, rely on the venerable rlwrap that provides you with a readline wrapper around your existing REPL.

My sucky REPL looked like this:

#!/bin/sh
java -cp PATH_TO/clojure.jar clojure.main $1



Simply install the rlwrap package using your favorite package manager and change your REPL script (clj) to the following:

#!/bin/sh
rlwrap java -cp PATH_TO/clojure.jar clojure.main $1


Major suckiness averted. The added boon of this approach is that you now get all the readline goodness (history traversal, inline editing, etc.) you've come to depend on in other REPLs.

B0rked ports on Snow Leopard

If you are using MacPort to manage OSS on your box and you recently upgraded to Snow Leopard you will find error messages like this when trying to use the ports system:

$ port selfupdate
dlopen(/Library/Tcl/macports1.0/MacPorts.dylib, 10): no suitable image
found.  Did find:
/Library/Tcl/macports1.0/MacPorts.dylib: mach-o, but wrong architecture
while executing
"load /Library/Tcl/macports1.0/MacPorts.dylib"
("package ifneeded macports 1.0" script)
invoked from within
"package require macports"
(file "/opt/local/bin/port" line 39)

The issue is simply that you have all your libs and binaries managed via MacPorts compiled for the i386 architecture and not x86-64 (as required for Snow Leopard).

The solution is simple, but, arduous. You need to install the new version of MacPorts for Snow Leopard, make a backup list of the installed ports, delete them and reinstall the ones you still want.

You may want to pay close attention to the variants of the ports that you had previously installed when reinstalling them.

Also, you need the latest version of Xcode (a version greater than v3.0 will do) installed.

Fun.

See the following two URLs for more info:

• Installing MacPorts
• Migrating a MacPorts install to a new major OS version or CPU architecture

Happy recompiling!

OS X Snow Leopard and broken scrolling in MacVim

My upgrade to Snow Leopard has been pretty smooth sailing bar one annoying hitch. After the upgrade MacVim stopped scrolling properly.

When you scroll down only the last few lines on the screen update and scrolling up only the first few lines. This requires you CTRL-L to redraw the window every time you've finished scrolling.

Yuck!

Looks like this is caused by MacVim's support for ATSUI which has been deprecated in favour of Core Text in Snow Leopard.

If you are experiencing this you can simply turn the ATSUI renderer off by unchecking MacVim -> Preferences -> Advanced -> Use ATSUI renderer.

This is switched off by default so most people won't be affected by this. At the time of this post there was no real indication from the MacVim project if they'd be switching to Core Text in the future in addition to using the ATSUI renderer.

iTerm, X11.app and the case of the missing DISPLAY

If you're running X11.app as your X server on OS X you generally need to use the xterm window it launches for you as part of the system or your specific xinitrc to connect to remote hosts via SSH when you want to enable X11 forwarding (and the propagation of your DISPLAY variable).

I prefer iTerm and luckily the solutions to switch to using it instead of the xterm launched by X11 is pretty easy to implement.

The first option is to make a user specific copy of xinitrc and modify the line that launches xterm to rather launch iTerm. If you don't have a user specific xinitrc (~/.xinitrc) you can grab a copy from /etc/X11/xinit/xinitrc or /usr/X11R6/lib/X11/xinit/xinitrc.

Near the bottom of the xinitrc you'll see a few lines that reference xterm that you can comment our and substitute with:

/usr/bin/open /Applications/iTerm.app

If you access remote X applications very infrequently it may simply be easier to ensure that X11 is running and then export your DISPLAY variable manually in iTerm:

$ export DISPLAY=:0

The final solution is to make all terms aware of your DISPLAY variable by editing your local environment plist (~/.MacOSX/environment.plist):

$ open ~/.MacOSX/environment.plist

This will open the plist in the Property List Editor where you can add a new child (DISPLAY) under the root node with a value of ':0'. For this to take effect you need to log out/in. You could also have dropped 'export DISPLAY=:0' into your local ~/.bash_profile to achieve the same results.

Untrusted SSH clients or Gdk-WARNING **: Connection to display localhost:10.0 appears to be untrusted

While connecting to a local RH system via 'ssh -X' I was seeing errors like:

Connection to display localhost:10.0 appears to be untrusted. Pointer and 

keyboard grabs and inter-client communication may not work as expected.

OpenSSH implements the X11 SECURITY extension that provides two clients types: trusted & untrusted.

Trusted clients can do anything with the display while untrusted clients cannot inject synthetic events (mouse movement, keypresses, etc.) or read data from other windows (e.g. take screenshots).

In theory you should be able to run most applications via the untrusted category but it seems that a fair amount of client apps still do not implement this correctly so YMMV.

If you want to initialize a SSH connection with X11 forwarding support and using the trusted security type you simply replace -X with -Y:

$ ssh -Y USER@HOST

TIP: Add a '-C' to your ssh connections to speed things up. Nothings for free but I am sure the CPU/speed trade-off will suit most users.

Installing ghc on OS X and getting "./configure: line 11082: syntax error: unexpected end of file"

While trying to install ghc from MacPorts I kept getting this:

[...]
--->  Fetching ghc
--->  Attempting to fetch ghc-6.10.3-src.tar.bz2 from 

http://distfiles.macports.org/ghc
--->  Attempting to fetch ghc-6.10.3-src-extralibs.tar.bz2 from 

http://distfiles.macports.org/ghc
--->  Attempting to fetch testsuite-6.10.3.tar.bz2 from 

http://distfiles.macports.org/ghc
--->  Attempting to fetch ghc-6.8.2-darwin-i386-leopard-bootstrap.tar.bz2 from 

http://distfiles.macports.org/ghc
--->  Verifying checksum(s) for ghc
--->  Extracting ghc
--->  Applying patches to ghc
--->  Configuring ghc
Error: Target org.macports.configure returned: configure failure: shell command 

" cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.

macports.org_release_ports_lang_ghc/work/ghc-6.10.3" && ./configure 

--prefix=/opt/local 

--prefix=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.

macports.org_release_ports_lang_ghc/work/destroot/opt/local 

--datadir=/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.

macports.org_release_ports_lang_ghc/work/destroot/opt/local/share/ghc-6.10.3 

--with-gmp-includes=/opt/local/include --with-gmp-libraries=/opt/local/lib 

--with-ghc='/opt/local/var/macports/build/

_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/

work/ghc-bootstrap/bin/ghc' --with-gcc=/usr/bin/gcc-4.0 " returned error 2

Command output: checking build system type... i386-apple-darwin9.7.0
checking host system type... i386-apple-darwin9.7.0
checking target system type... i386-apple-darwin9.7.0
Canonicalised to: i386-apple-darwin
checking version of ghc... 6.8.2
checking for nhc... no
checking for nhc98... no
checking for hbc... no
checking for ld... /usr/bin/ld
./configure: line 11082: syntax error: unexpected end of file

Turns out there's some old cruft in the ghc autoconf macros that were causing the break. The fix was a simple:

$ sudo port selfupdate && sudo port clean ghc && sudo port install ghc

You can see the filed bug and changeset at MacPorts for more information.

Update: Home made nginx + phusion passenger OS X port

The new v2.2.5 version of Phusion Passenger has been released.

If you want to roll this into OS X without having to use their installer you can simply follow the previous article to get this done.

Important things to note is that wherever you used /opt/local/lib/ruby/gems/1.8/gems/passenger-2.2.4* you would now use /opt/local/lib/ruby/gems/1.8/gems/passenger-2.2.5* (the Portfile and the nginx.conf come to mind).

Mounting a disk image with Windows tools only

Coming from the *NIX/Mac world I frequently find myself mounting ISO images as local disks for software installation, etc.

The same requirement recently came up for me on a Windows platform and I was a little stumped as I did not want to spend any money on this (as I see this as an intrinsic part of the the OS) by buying Alcohol or Daemon Tools.

To my surprise Microsoft actually has a (unsupported) tool (Virtual CD-ROM Control Panel) and driver that provides virtual CD-ROM services.

Unfortunately the solution is XP-only. Download the executable above and install the service. Its readme is quite short and to the point so getting this going is pretty easy.

Have fun!