squaremobius dot net

Content subject to imperceptible change

Just recently I've been working on porting this site to fuschia, which is really just some Python code I've been playing with for slapping templates on RDF. I hope to make very little perceptible difference to the site (posting here infrequently also supports this aim). But I will be pleased.

There are some other things I want to work on that will make very little difference to anyone but myself. I want to make a JavaScript-and-DOM implementation of an Atom client (this will help me post stories). I want to revisit the styles, and reform that Dreamscape theme. I want to be a fully-functional member of the semantic web (by providing all sorts of feeds and metadata).

Inevitably though, there may be some gee-whiz stuff. There may also be some new content. Or—dare I say it (dare! dare!)—a podcast. I'll try not to surprise anyone.

Code archaeology

I got down to looking at the directory that holds my code checkouts the other day. There's a progression of version control software: CVS -> Arch -> Darcs; and several false starts (some without corresponding starts).

For example, there's PIJ, which amounts to the bare bones of a process-calculus based kernel in Java.

... All data implements Channel. The channel provides a process view of data. Most primitives (which are in turn just banged continuations hanging off ports) will access data directly rather than going via the process reflection. ...

Then, there's an implementation of join calculus (concurrency again!) with some syntax-case madness from TonyG, and a very simple scheduler from me.

  (define (scheduler-step continue)
  (and (not (queue-empty? *SCHEDULER-QUEUE*))
       (begin (call/cc
	       (lambda (k)
		 (set! stop! (lambda () (k 'dummy)))
		 (if (not (queue-empty? *SCHEDULER-QUEUE*))
		     ((queue-pop! *SCHEDULER-QUEUE*)))))
	      (and continue
		   (scheduler-step continue)))))

Then, Sake, which is supposed to be our answer to both Ant and Make but fails through lack of working ... anything. I do like the idea of it though.

Rather than being discouraged by all this unfinished, possibly abandoned code, I'm now feeling a little bit enthused about reviving, redeveloping, and redacting.

Darcs repository online

I hitched up darcs.cgi to the site; now you can view things I keep in Darcs. There's only some slightly chaotic Fuschia code in there at the minute — I prefer GNU/Arch right now, but that might change.

hacking hacking hacking

I've been doing some guerilla hacking on zowie. Starting from the SDL and Cairo bindings for Chicken, I added some makeshift protocols for building and rendering scenegraphs, then classes representing some graphical primitives and a camera. A small bit of fooling around with events and we can zoom in and out on a simple scene with transparent, filled and stroked rectangles and text.

The next step is to add an MVC layer; the views I am (perhaps cheekily) calling 'zorphs'. Soon I should have input event handling, damage reporting, and the other basic stuff I need to for user interaction. Go the hacking!

Hey someone should ..

.. write a plugin for Firefox that does the equivalent of del.icio.us bookmarklets, but synchronises with Firefox's bookmarks. Why? Because del.icio.us has

1. An API for getting and setting
2. Neat keyword indexing
3. Sharing!

Well well — someone has done something just as good!

Smalltalk, Generation Next

TonyG has written a whole bunch of material on method dispatch in Smalltalk NG, which is our plan to write a Smalltalk-like system using process calculus primitives.

The origins of Smalltalk

TonyG pointed me at this paper by Alan Kay about the origins of Smalltalk. I want to be writing papers like this in twenty years' time!

More: Dan Ingalls wrote a paper about the principles followed in developing Smalltalk. He said, in 1981,

Even as the clock ticks, better and better computer support for the creative spirit is evolving. Help is on the way.

Sometimes speculating about technology feels more like archaeology.

The design of fuschia--1

What I think are good points about fuschia-0:

• The template system is small, clean and simple. Not sure about how arguments are represented (or whether there should be any), but we'll see.
• The arrangement of templates works well — using a document template, then within that a story template, etc. Might be useful to supply a standard 'use a template' function for customisers.
• Some of the utility (helpers) code is fairly reusable.

and points that need updating

• Keeping everything in the environment dictionary is just silly and makes the code messy. Most things can just be let in configuration, with variables really the only things worth keeping in the environment dictionary.
• Conceptually the storage/query abstration is in strife, probably from trying to be too generic. Better to assume more things and make things that are usable — 80/20, man. It's worth checking out gyre to see how queries are made there.
• It's too complicated even just to bootstrap. More assumptions, or better defaults. Relatedly, there could be far less code.
• I think I'm coming around to TonyG's view of the difference between caching and storage; caching is not a facade on storage, it's a facade on the model (or indeed, it is the model).
• Filters were just chaotic.
• Query parsing (and unparsing) is a bit ad-hoc and introduces problems with templates, though the code is probably reusable; needs to be thought through a bit more first.

I think the new way of going about things is:

• Base classes (the default for bootstrapping) can be 'in-memory'; subclasses of those might load from the filesystem, etc.
• Keep a caching model of the stories à la gyre; apply filters to stories when loading them (on demand according to the query).
• Bootstrap with some sensible settings but allow the user to override them immediately, as well as in per-query configuration.
• Make sure nothing upsets static rendering!

and open questions:

• Will I just end up with gyre with a few extra hacks (and should I therefore just branch from gyre)?
• How can I introduce some of the Zowian ideas about semantic-to-spatial relationships? Are they even in a state to be used?

Where am I going with this anyway?

Ever start something then realise you have no idea where you want to end up? 'course you have. You'll know how I feel about Fuschia then.

Fuschia started as a response to blosxom being, well, Perl, and PyBlosxom being, well, too far away from blosxom (yes that's right, you can't win with me). No sooner had I begun thinking about it than I formulated Grand Plans; for example, Fuschia will have a flexible and powerful template system and per directory configuration and … — you know how it is. And very soon after that, TonyG up and implemented his own blosxom-alike, citing irreconcilable differences. PALT.

So, it's back to basics: Is it worth rewriting Fuschia? What do I want it to do that isn't available elsewhere?

The first question I'll have to think about (and find time for). This is what I want it to do that's halfway novel:

• A templating system similar to blosxom, but 'safe' in that the template variables have to be supplied as such explicitly
• per-query configuration and templates, with usable defaults
• the opportunity to plug in different renderers, story filters, backing stores, and whatever else makes sense
• Static rendering that Just Works

As it stands, it is over- (and poorly) engineered, and sketchy as hell. With my new-found direction, maybe I can pull it back from the brink of untouchability.

HCI as language

TonyG and I were talking about human computer interaction as a conversation. If you consider a user interface to be a language, with a vocabulary and a grammar, then user actions are sentences. More specifically, taking the example of a direct manipulation style interface: icons or selections of icons are noun (phrases), gestures are verb (phrases). Dragging a file icon to the trash can is saying FILE GOES TRASHCAN.

A few things are apparent when you look at things this way: most direct-manipulation(-of-files) systems have effectively one verb (gesture): that is, GOES, usually indicated with a click and drag gesture. Most sentences are just noun-verb-noun. Also, the computer is mostly a passive partner in the conversation, aside from 'minimal encouragers' — brief sound effects and animations as feedback that the gesture was recognised.

Using more than one verb

I said before that most systems only have one verb GOES; you might contest that there is also INVOKE (intransitive), so let me qualify my position by adding that has meaning within the system. I'm saying that starting an application or opening a file is stepping outside of the language (more on this later, or in another post). In file manipulation, it may be that one verb is sufficient — the rest is interpetation based on the nouns in the sentence and the context. There seems to be a trade-off between a rich set of interpretations and a rich set of verbs, which is heavily weighted in favour of interpretations. This is a little weird to me.

The contrasting situation is to have a rich set of verbs (hence, gestures) and consistent meanings for the verbs. For example, to delete something you could scribble over it; delete should after all be intransitive, surely. If you want to modify something, click in it (this is half-arsedly approximated by the 'file-type associations' pattern in desktop systems). If you want to move it, select (circle?) it and drag it.

More complex sentences

Sentences in contempory graphical user interfaces are very simple; usually NOUN VERB NOUN. There's no recursion, only statefulness. What if you could form complex sentences? Sure, with only one verb there are not that many interesting complex sentences you can form. With many verbs you can make interesting noun phrases: Text similar to this text should be copied here.

Having a conversation

So far the computer is listening to what we say, and interpreting it as commands to update its state. The computer may as well not be there, it's just the user (as TonyG puts it) shuffling paperweights.

If we imagine the computer on the other side of the screen, and the screen itself as the speaking-space between the user and the computer, then we can have a 'proper' conversation. For a start the computer should ask when it doesn't understand or needs more information; and it should ask in the same language as we are using. What does this mean, concretely? Good question.