Rode around San Francisco on a rainy Saturday.

When talking with other cyclists, particularly other fixie riders the subject of gearing often comes up. My usual ride has an odd but very specific gearing: 47 up front, 19 in the rear. Why?

The gain ratio (47 / 19) is just a hair under two and a half (2.47). Good for going up (and down) hills in San Francisco. 47 and 19 are both prime. This distributes the wear pretty evenly over the chain and sprockets. Any given link on the chain will hit the same tooth on the chainring every 893 revolutions, which is approximately once per mile with 700c (~27 inch) wheels.

Empirical evidence leads me to believe this ratio is as close to perfect as you can get for San Francisco, for a brakeless everyday fixie. It’s equally good for banging around town or a paradise (Tib) loop.

So iTunes users drive VWs and drink cider + imported beer.

WTF?

For a bunch of reasons, I refrain from eating at McDonalds, Burger King, KFC, etc. I’m not vegetarian, but the food I buy/cook tends to skew that way, and I generally buy organic produce, eggs, chicken, and whatever else I can.

Sometimes I absolutely just crave the plasticine mediocrity of a Mickey D’s burger. There’s something about how they’ve perfected the taste and mouth-feel of it that sometimes just sounds really, really good. I haven’t caved into this particular urge in years (score one for standards), but it’s getting harder.

What I want is an organic McDonalds. Not vegetarian, not even necessarily the most wholesome of corporate culture either (it wouldn’t hurt), and not even having particularly good food. I want to be able to roll into OMcDs, order a couple bacon cheeseburgers, shake (is it too much to wish for soy?) and fries, sit down and stuff myself until that greasy-near-nausea feeling overcomes me. Well, maybe not the last part. Truth is, one of the reasons I don’t partake of the McBurgers is just that. The grease overload giveth and the grease overload taketh away. Usually just the memory of my last fast-food binge is enough to keep me on the wagon for a few months.

So refined: a McDonald’s clone, with organic beef/buns/produce, soy milkshakes and comparable fries, somewhere in the San Francisco area. I will gladly pay twice as much.

The design of this blog started out as a generic two-column-right template, modified using Custom CSS. I wanted to have a fluid design without fluid column widths. What I did was fix the primary content column (alpha) to a specific width, and then canned the secondary column as a hard & fast container.

The content modules in the right side are fixed width and float left. They are sized such that 3 of them across is equal to the alpha column. On short pages like the Archives page, the sidebar modules wrap nicely around the main content area.

It will probably take some tweaking over the next few weeks until everything is hammered down.

Update 1: Shaved 5-10px off the column widths so that 2 columns fits on an 800x600 screen, 1 column on 640x480, and 3 columns at 1024 pixels wide.

Update 2: Converted the design to Advanced Templates because of a bug in IE6, where the containing div around a set of floats, even position: static and float: none would still wrap the floated elements.

Both Mozilla and the Webkit folks fixed the bugs I noticed with their <canvas> implementations. It was pretty nice to see someone make a Doom-style renderer using the same method I had been attempting at the time.

From a set of photos taken of the ruined munitions plant in Hunter’s Point.

Posted a bunch of old party flyers I designed 2000-2004. Some were for club nights at places that no longer exist: Townsend/King Street Garage (torn down in 2004 and now a loft building) and Sno-Drift (shuttered earlier this year). Some were for house parties.

Need to have a party in the new house at some point…

…or why they can’t work the way I want them to.

I was reading Simon Tatham’s brilliant essay on Coroutines in C the other day after hunting around to see if anyone had implemented continuations in JavaScript. This is a jumbled account of how I came to want and fail to make them work (yet).

JavaScript is a wonderful language, it has the expressiveness of Perl with the syntactic clarity of Java. As much as I love Perl, sigils have always bugged me a little and I really really like writing single-line blocks without braces or inverting the order as Perl requires.

A lot of the stuff I’ve been writing lately fits a basic pattern: object A calls a method on object B and supplies a callback so that when the operation is completed, object B can supply object A with the result. Generally the sort of thing that object B does involves making a request to the server or querying the user for some information.

An example of this would be a modified window.confirm() method. Assume your favorite browser overloads the function with an additional argument: window.confirm( message, callback ) The function would return immediately, returning control to the calling function and after the user clicks OK or Cancel, the callback function is called with a single value of true or false.

function step() {
    var message = "Your mouse position has changed. "+
        "Click OK to confirm the change or " +
        "Cancel to return to the original position.";
    window.confirm( message, correct );
}

function correct( result ) {
    if( result )
        revertMouse();
}

Callbacks work pretty well. Since JavaScript supports lexical closures, it’s trivial to create a closure that simply wraps the this object and a particular method. Our core.js has two factory methods for doing just that: bind() and bindEventListener(). Our example rewritten as a class:

Annoy = new Class( Object, {
    step: function() {
        var message = "Your mouse position has changed. "+
            "Click OK to confirm the change or " +
            "Cancel to return to the original position.";
        window.confirm( message, this.correct.bind( this ) );
    },

    correct: function( result ) {
        if( result )
            revertMouse();
    }
} );

This works pretty well, to a point. If you need to set up multiple levels of asynchronous calls, the code degenerates pretty quickly. Callbacks calling other callbacks, creating closures around other closures, generally doing a good job of concealing or at least confusing the actual flow of the program.

This is especially obvious with AJAX. Ideally you don’t want to use a blocking request, tying up the UI in JavaScript, holding the browser hostage. Making asychronous requests to the server end up looking a lot like the above example:

ServerList = new Class( Object, {
    init: function( id ) {
        this.id = id;
        this.length = 0;
    },

    getItems: function( index, length, callback ) {
        var _this = this;
        AJAX.call( "getItems", [ this.id, index, length ],
            function( response ) {
                _this.handleResult( response.result, callback );
            } );
    },

    handleResult: function( result, callback ) {
        this.length = result.length;
        callback( result.items );
    }
} );

The ServerList class is a model, and there’s another class that acts as the view. It handles rendering the list, handling user events, etc. There’s a producer-consumer relationship between the model and view classes, and a p-c relationship between the model and the server. Since requesting items from the server is an asynchronous operation, the view class must have a callback (and therefore another closure) to accept the results from a call to the getItems() method. Just one level deeper, and the ratio of algorithm complexity to code complexity has noticably worsened. The logical flow of the program is obscured in a pair of callbacks and closures in two classes.

The view class is completely dependent on the model class to supply it with information. The callback supplied on every request could be replaced with a single call to instantiate the relationship between the two objects:

ServerList = new Class( Object, {
    init: function( id ) {
        this.id = id;
        this.length = 0;
        this.observers = [];
    },

    observe: function( observer ) {
        this.observers.add( observer );
    },

    unobserve: function( observer ) {
        this.observers.remove( observer );
    },

    getItems: function( index, length ) {
        var _this = this;
        AJAX.call( "getItems", [ this.id, index, length ],
            this.handleResponse.bind( this ) );
    },

    handleResponse: function( response ) {
        var result = response.result;
        this.length = result.length;
        this.observers.forEach( function( observer ) {
                if( observer.itemsLoaded )
                    observer.itemsLoaded( result.items );
            } );
    }
} );

All an observing object needs to have is a specified method that the producer recognizes for passing items. In this case it’s itemsLoaded(). The ServerList class could have multiple observers who can all be notified when new items are loaded. They can determine if and what to do with that data. A hypothetical view class:

ServerView = new Class( Object, {
    init: function( list ) {
        this.list = list;
        this.list.observe( this );

        this.offset = 0;
        this.length = 10;
        this.items = [];
        this.loaded = false;
    },

    setOffset: function( offset ) {
        this.offset = offset;
        this.loaded = false;
        this.draw();
    },

    draw: function() {
        if( !this.loaded ) {
            this.list.getItems( this.offset, this.length );
            return;
        }

        var html = "";
        this.items.forEach( function( item ) {
                html += "<p>" + item.index + ": " + item.name + "</p>";
            } );
        document.body.innerHTML = html;
    },

    itemsLoaded: function( items ) {
        items.forEach( function( item ) {
                var index = item.index - this.offset;
                if( item.index < 0 || item.index >= this.length )
                    continue;
                this.items[ index ] = item;
            } );
        this.loaded = true;
        this.draw();
    }
} );

Now the complexity has been mostly moved to the view class. Whether the result is preferable to using callbacks is debatable. An object with a lot of observers could result in a lot of noisy traffic, calling methods on observers when they don’t care about the result.

After mucking through the first two options, I realized what I really wanted was continuations. I want to be able to call a JavaScript function that will return after some amount of time with a response, returning control back to my function. I wanted to turn the draw() function into something resembling this:

    draw: function() {
        var items = this.list.getItems.yield( this.offset, this.length );
        ...
    }

The idea being that the state of draw() would be saved while getItems() went on its merry way to get the data. The draw() method would return immediately at the getItems.yield() call and only when that completed would the remainder of the function be called.

So I started hacking on it a bit after reading Simon’s article on continuations in C. I figured the same thing could be hacked using closures and goto. All I would need to do is have a function recompiler that modified a method or function, wrapping the contents in a closure and declaring all lexicals outside the closure. Essentially a continuation factory. So my first stab at what a generated function would look like was this:

Before:

function test() {
    var count; // predeclaring all lexicals to simplify function recompiler

    count = 0;
    while( 1 ) {
        sleep( 500 );
        document.body.appendChild(
            document.createTextNode( count + " " ) );
        count++;
    }
}

After:

function test() {
    var count;
    var continuation = function( rval ) {
        if( !continuation.label ) {
            count = 0;
            while( 1 ) {
                window.setTimeout( continuation, 500 );
                continuation.label = 1;
                return;
            __1:
                document.body.appendChild(
                    document.createTextNode( count + " " ) );
                count++;
            }
            __1: ;
        } else {
            while( 1 ) {
                if( continuation.label == 1 )
                    break __1;
                return;
            }

        }
    }

    return continuation();
}

I had been hoping to use either break or continue as a substitute for goto. Alas, when compiled Firefox complains that label __1 is missing. So I’m at a stopping point. There doesn’t seem to be a way (in normal JavaScript anyway) to jump into a loop or other lexical block.

Anyone have any ideas?