GFX::Monk Home

zero install is great

Zero install is a marvellous system that I've known about for a little while, but only just started to use. It’s a package manager (like apt or yum), with two important differences:

  1. Packages are distributed and named by URL – there is no single repository, just the internet. This makes for potential trust issues, but it’s far better than (for example) launchpad PPAs, because…
  2. Packages are installed and run as regular users. No root access required.

It also has some additional perks:

  • Cleanup is trivial – just clean out your zero-install cache.
  • Making packages is pretty simple.

For its convenience, using zero-install puts some restraints on you:

  1. No triggers. You can’t run a script on install / uninstall, because there are no such events – merely “run”. That means your program has to be self-contained, and must deal with any first-run issues in the code itself. Probably not a bad idea though.
  2. No arbitrary placement of files. I've got a bunch of customisations that (for example) put things in /etc/profile.d. You can’t do that sort of thing with zero-install, not even in the user’s home directory (e.g ~/.config). This means it’s not a great solution for configuration-based packages that coexist on the filesystem in well-known directories, so I certainly don’t see it replacing APT for that sort of stuff any time soon. But it’s certainly an excellent tool for delivering both programs and libraries.

I've put together my first 3 zero-install packages, and hopefully there will be more to come. You can find them here: http://gfxmonk.net/dist/0install/

Two of them are existing software, and the third is a tiny utility for working with zero-install itself. You can click on the xml files in that directory listing for an overview of what each package does.

Steve Jobs on Flash

I don’t even like flash, but this argument made by Steve Jobs makes me mad:

By almost any definition, Flash is a closed system.

Excepting, apparently, the definition that makes Flash open because swf is a publicly documented format which anyone is free to implement a compiler or viewer for. Having produced a new compiler (for example), one is then free to distribute swf files compiled with this third-party compiler to anyone with a flash player, who may then run them by any means they choose (including using an official Flash player or plugin from Adobe).

Compare that again to people who want to write iPhone apps using any tool other than Apple’s, and who want to distribute their creations to end-users to use without Apple’s endorsement (i.e the App Store).

And then please, continue to regale me with Apple’s astounding openness on this matter compared to the Big Bad Adobe.

Please note that I'm talking about the swf format here, not Adobe’s Flash creation program. Flash is to swf as XCode is to compiled iPhone Apps – any other comparison is disingenuous as I'm sure Steve knows.

The metaphysical angle against apple's new developer agreement clause

A really nerdy joke, but also a perfectly arguable stance within the language of the agreement. I love it.

Personally, I can’t believe the nerve of Apple these days. It’ll be interesting to see what fallout (or depressing lack thereof) comes from their ever-increasing paranoia.

Save My Text

savemytext is a tiny app engine webapp I wrote last night.

When you write text in it, it will save your text. When you come back, your text will still be there. You can have multiple text boxes. Since it’s an appengine app, you’ll need a google account to use it.

A trivial app, to be sure. But all too often I find myself writing gmail drafts just in order to get a persistent text box between computers. I figured, why not do it properly?

(I was going to just call it “textarea”, but someone already stole that name (and tens of similar ones, without actually having an app to put up. How rude))

Battling javascript contortion with lisp (of all things)

I'm pleased to report that my crazy notions of replacing javascript metaprogramming with lisp metaprogramming appear to be headed steadily in the direction of success. It'd take a while to explain exactly what I'm up to (and the reasoning behind it), but essentially I'm trying to solve the same problem that async.js, narrative javascript and strands all try to solve: asynchronous callbacks are ugly, error-prone and downright confusing.

All of the above mentioned tools are unsatisfactory in various ways. Both narrative javascript and strands are complex enough that I uncovered serious bugs in both reasonably quickly. async.js is much more stable (and I actually have a working application with it), but still requires very careful programming and only works on mozilla browsers.

So I set forth with parenscript, which is essentially javascript dressed up as lisp. It doesn’t make for any prettier javascript, but it does make for one hell of a metaprogramming opportunity using lisp macros.

The aim is to convert straightforward, procedural-style code into the contortion required to appease asynchronous callbacks. I'm certainly not done yet, but I do have some compelling proof to show that it’s a plausible thing to do with lisp. Here’s a contrived example for, say, getting all items from whatever feed the supplied item-id belongs to. This involves getting the item to find the feed it belongs to, then returning all items contained within that feed. The “store” objects in this scenario refer to lawnchair stores, which do asynchronous local datastore lookups:

    (asyncfun get-sibling-items (item-id)
      (defer item (item-store.get id))
      (console.log (+ "item belongs to feed: " item.feed-id))
      (defer feed (feed-store.get item.feed-id))
      (ret feed.all-items))

And here is the generated javascript:

    function getSiblingItems(itemId, cb) {
      itemStore.get (id, function (item) {
         console.log('item belongs to feed: ' + item.feedId);
         feedStore.get(item.feedId, function (feed) {
            cb(feed.allItems);
          });
       });
    };

This is just a simple example, but the lisp code still shows a remarkable reduction of both noise and contorted control-flow, and the generated code ought to work in all browsers. Worth pursuing, certainly.

The Appendices of the CSS Spec Have Awesome Titles

Specifically, their titles (somewhat contortedly) start with the letter of the appendix itself (A through I). And appendix H is a friggin easter egg!