Clojure: Transparently using delayed values

Clojure has a nice ‘(delay)’ macro which will delay the computation of anything you like.

(def lazy-val (delay (+ 1 2)))
lazy-val  ;; #<Delay@57d4f95b: :pending>
@lazy-val ;; 3
lazy-val  ;; #<Delay@57d4f95b: 3>

But, as you see above, you need to deref it with @ in order to get at the value on the inside. There are cases where this is a pain. You may have a chunk of code which already operates on regular values, and you want to provide a lazily computed value to it. As long as you’re using protocols, you’re good: you can extend-protocol on top of the Delay type to provide a version which is lazily constructed upon calling any of the protocol methods.

(defprotocol MyProto
(do-it [this]))</code>

(defrecord Impl [a b]
MyProto
(do-it [_] (+ a b)))

(extend-protocol MyProto
clojure.lang.Delay
(do-it [this] (do-it @this)))

(def lazy-instance (delay (->Impl 1 2)))

(do-it lazy-instance) ;; 3

This could probably be done more concisely with a macro, but I’m happy with this for now.

TwitConc, a twitter concordancer

I made a little program to make it easy to, given a word you want to learn, find example sentences for it on twitter. It barely works, but it’s already useful. I really like the flashcards I’ve made from twitter, they have a nice… flavor?

http://digitalartificer.com/TwitConc/

And if you want the source: http://github.com/mullr/TwitConc

If it’s broken for you, let me know how and I’ll try to fix it. I’ve tested on my mac only.

Configuring msysgit for improved awesome

Git, as many of us know, is pretty great. And it works with great things like github and gerrit. I’ve been using it for work lately and like it very much. But the windows toolchain leaves something to be desired.

It turns out that the first rule of git on windows is don’t use cygwin git. I didn’t understand why this was until I started dealing with large repositories and doing a lot of waiting. git status took 15 seconds to run EVERY TIME. Luckily I figured it out and started using msysgit instead. msysgit is a pretty good port, but anybody who’s used a mac or any unix machine with a real terminal emulator will be immediately dismayed to find out that its shell runs inside the regular cmd.exe window. Which is crap.

This is how to make it not crap.

1. Configure the console
Did you know you can make cmd.exe not suck? I didn’t. It’s pretty easy.


The most important setting is “QuickEdit Mode”, which lets you select text directly without doing the brain-damaged menu selection thing. Then you can hit enter to copy it. The right mouse button pastes. Double click selects a word, just like you’d expect; this is really useful when dealing with git, since you can double click a commit hash and hit enter to quickly copy it, then right click to paste it to the command line.

The other settings I use and recommend are:

  • Font: Consolas 14pt
  • Window Size: Width=128
  • Window Position: “Let system position window” turned off, set to be the right half of my screen every time.
  • Colors: I use a light yellow background and dark foreground. This gives good contrast against the blue you see in so much colored output, unlike the default black background. BG=255,255,236, Text=0,0,0. You should configure your prompt first if you want to do this, so you don’t get stuck with invisible text.

2. Configure your prompt.
The default msysgit prompt settings are kind of crap. This is what I use in my ~/.bash_profile. NB: this is set up for a LIGHT background, so the text is BLACK. If you use this with the default colors, your text will be invisible.

function parse_git_branch {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
}

function proml {
  local       BLACK="\[\033[0;30m\]"
  local        BLUE="\[\033[0;34m\]"
  local         RED="\[\033[0;31m\]"
  local   LIGHT_RED="\[\033[1;31m\]"
  local       GREEN="\[\033[0;32m\]"
  local LIGHT_GREEN="\[\033[1;32m\]"
  local       WHITE="\[\033[1;37m\]"
  local  LIGHT_GRAY="\[\033[0;37m\]"
  case $TERM in
    xterm*)
    TITLEBAR='\[\033]0;\w\007\]'
    ;;
    *)
    TITLEBAR=""
    ;;
  esac

PS1="${TITLEBAR}\
$BLACK\w$GREEN\$(parse_git_branch)\
$BLACK\$ "
PS2='> '
PS4='+ '
}
proml

You can easily adjust the colors to be how you like. Note that the last color here will override the text color you set in the prefs window; that confused me at first. Also make sure your profile file is executable (chmod +x ~/.bash_profile) and starts with #!/usr/bin/bash, if you’re having any troubles.

3. Configure git a little
This isn’t specific to windows, but it makes my git experience so much smoother. I found the ‘lg’ alias on the internet and forgot where. Sorry, guy who made this first.

[merge]
        tool = winmerge
[mergetool "winmerge"]
        cmd = 'C:/Program Files/WinMerge/WinMergeU.exe' \"$MERGED\"
[color]
        diff = auto
        status = auto
        branch = auto
[alias]
        lg = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)&lt;%an&gt;%Creset' --abbrev-commit --date=relative
        anchor = tag -f anchor
        s = status

‘git lg’ will now give you a nice colored log summary. I use ‘git anchor’ frequently before trying out something I may mess up or want to quickly revert; it makes it easy to get back to where I was without having to inspect the reflog. And finally, I use ‘git status’ so much that I just abbreviate it to ‘git s’.

4. RTFM
There are incredible amounts of excellent information about git on the web. Read them. You can look at my bookmarks over at del.icio.us for a starting point if you want.

Although there are a number of windows guis around, in various states of incompletion, you’ll be much better off if you learn to use git from the command line. Yes, this means editing commit logs in vi, if you stick with the defaults. If you can’t do this already, you should learn how. The GUI tools, as they are today, simply hide too much important stuff from you. The real power in git is understanding how the commit graph works and how it changes when you do various operations; this is something that should in your face, not hidden away. At most, ‘git gui’ is acceptable for staging things for commit. ‘gitk’ is alright as well. But I haven’t yet seen any windows-specific guis that do a good job.

C# techniques: simulating stack unwinding and block syntax

One of my favorite things about C++ was its predictable stack unwinding.  This could be combined with anonymous scopes for some powerful techniques.  (I learned all about this from Steve) For example, I might want to hold onto a lock to something for a particular time.  I could simply make an object which allocates the lock in its constructor and releases it in its destructor.

// Anonymous scope for lock
{
ResourceLock lock;
//…
}

ResourceLock allocates the resource it its constructor. It lives on the stack until the local block is exited, whereupon its destructor is called and the lock is released.

The really great thing about this technique, especially for things like locks, is that it’s entirely exception safe. Can we do something similar in C#?

Method 1: IDisposable/using
The C# way of doing predictable allocation is IDisposable. And since we have a bit of syntax sugar in the ‘using’ block to make it exception safe, we may as well use it for this purpose.

class ResourceLock: IDisposable
{
public ResourceLock()
{
// allocate the lock
}

public Dispose()
{
// release the lock
}
}

// usage example
using(new ResourceLock())
{
// the lock is held here…
}
// … and released here

Hopefully the usage is pretty obvious. I like this method because the usage syntax is pretty good. In fact I don’t know of another method for things like locks. But there are other scenarios where you might want to do a bit more.

Method 2: Delegate passing
You’ll be familiar with this technique if you’ve ever used Ruby or Smalltalk. Those languages (and others) have native support for blocks. It’s not quite as nice in C# but still usable.

Let’s take the example of data binding. There are often cases where you need to do a batch of operations on a class which can throw change events. While it’s not strictly incorrect to throw an event after each operation, it can be a big performance problem. So we want disable change notification while the operations are in progress and throw a single change event when they’re done. Think of it as a kind of data-binding transaction.

We’ll implement the Transaction method using a Delegate parameter:

// A class which is observable in some way
class DataBindingClass
{
    public void Transaction(Action a)
    {
        try
        {
            SuspendChangeNotification();
            a();
        }
        finally
        {
            ResumeChangeNotification();
            NotifyObserversOfChange();
        }
    }
}

By passing an anonymous delegate to this method, we get an acceptable (but not great) syntax.

public void DoStuff(DataBindingClass db)
{
    db.Transaction(delegate() 
    {
        // do some stuff
    });
}

Don’t forget that you can pull in variables from the surrounding scope via closure. That’s really the only reason this technique is worth bothering with.

Method 3: IEnumerable/yield return/continuations
Okay, we’ve now stepped clearly into the realm of abuse. Please don’t do this in your code. But in the interest of completeness…

Since the yield return syntax is really a form of continuation, we can get the same general scoping effect with a little bit of creativity.

// A class which is observable in some way
class DataBindingClass
{
    public IEnumerable<int> Transaction()
    {
        try
        {
            SuspendChangeNotification();
            yield return 42;
        }
        finally
        {
            ResumeChangeNotification();
            NotifyObserversOfChange();
        }
    }
}

// usage example
public void DoStuff(DataBindingClass db)
{
    foreach(var i in db.Transaction())
    {
        // do some stuff
    }
}

As you can see, we abuse the ability of foreach to iterate over any IEnumerable to simulate a block syntax. In this case the block is only called once, so the loop only runs one time. The particular value we yield out Transaction() is completely arbitrary, as is the type. It’s only there to fool the loop into running.

In summary
C# gives us some reasonable tools here. I recommend method 2 (delegate passing) for most cases – it’s very flexible and the syntax is reasonable.

Trick-hot command pattern in C#

I’m working on some code that needs an undo feature, so naturally I turned to the command pattern.  I pulled out GoF to glance at their naming conventions and started to type, all the while thinking “there has to be a better way to do this.” Here’s what I think is a better way.

Recall that the command pattern specifies an abstract “Command” type with an Exceute method. This is only needed in languages without first-class functions: C# gives us delegates, which are pretty much equivalent in this case.  So we’ll skip the custom class and just use them.

But the extended, more useful form of the pattern also has an UnExecute method, used for undo.  This lets you push the commands onto a stack after executing them.  Undo is then simply a matter of popping the most recent command off the stack and UnExecute()ing it.  The command instance retains enough state information to undo what it had previously done.

We can do all that through the clever application of closures.  I’ve chosen to implement the commands as static methods, but they could also be implemented as regular methods, even virtual if you’d like to be able to route around to different implementations. Here’s a fictitious example:

static class Commands
{
    public static Action HAlign(Item stationary, Item movable)
    {
        int oldX = movable.X;
        movable.X = stationary.X;

        return delegate()
        {
            movable.X = oldX;
        };
    }
}

Executing the command is just a method call, and enabling undo is as simple as pushing the returned Action (just a delegate with no parameters or return type) onto an undo stack. (Stack<Action> will do nicely) The returned delegate captures, via closure, all the state in needs for undo to work properly.

That’s it! There are a few small land-mines in the details of how closures work (especially w.r.t. non-local or iteration variables), but the general technique is very simple.