The Avail Retreat of 2014

From October 22nd to October 27th, Mark, Rich, and I were in Two Rivers, WI, on the first annual Avail retreat. The retreat was a smashing success that produced some awesome technology. It was exactly what we all needed to get back into the swing of things after an uncomfortably long hiatus. It struck the perfect balance between hiking, eating, and coding.

Just after the "1.0.0 DEV 2014-04-28" release, I began work on a subproject codenamed "Avalanche". Avalanche was an attempt to migrate Avail's implementation from Java to machine code (plus dynamic translation via LLVM). I had most of the LLVM instruction set codified, and a substantial portion of the Avalanche front-end and back-end written.

And then my laptop crashed. The hard drive died in a major way. No problem, though, because I'm a good boy who makes regular backups.

And then my Time Capsule died. And three months worth of work on Avalanche was lost forever. I looked briefly into recovery options for the dead drives, but the quotes were prohibitively expensive.

You could say that I was demoralized by this loss, but you would be guilty of a profound understatement. I couldn't even think about Avail for months. It was just too depressing. Mark continued working on file I/O, but otherwise Avail languished.

About a month ago I decided that I had grieved long enough; it was time to get back to work. But I wasn't ready to tackle Avalanche again. I needed a different kind of diversion.

So I decided to make Avail web-accessible. As in, functional as an application server. So…

• I started by building a multithreaded, fully asynchronous implementation of server-side WebSocket.
• Then I built an Avail server capable of processing commands, e.g., "load module /examples/Wump the Wumpus", "run Play Wump the Wumpus".
• Then I rebuilt Avail's standard I/O infrastructure. Every fiber now has its own standard input ("next character"), standard output ("Print:_", and standard error channel ("Error:_"), and forked fibers inherit their parent's channels. The server architecture permits these channels to be layered on top of WebSocket (or some other transport).
• Then I gave every Avail value the ability to render its observable properties as JSON, taking special care to prevent emitting cycles.

Along the way I also mocked up a web version of the Avail workbench. It is still missing a couple features that the workbench has, most notably the ability to run entry points by double clicking them. It can still run entry points though — you just have to type them. It isn't a polished tool by any means, but it was good enough that I was able to use it instead of the Avail workbench starting sometime on October 23rd.

Here's a screenshot of the current version of the tool:

And here it is again, with the command console open:

The web workbench serves primarily to prototype an Avail web client. The command console exists to illustrate how interaction between the client and the server happens, and assists in debugging. If you are interested in the web workbench, then start the Avail server (com.avail.server.AvailServer) and then navigate your web browser to file://$AVAIL_HOME/web/ide/TestClient.html. The web workbench is cool, but it is not the real goal.

If you read the URL carefully, then you probably surmised that the real goal is to develop a full-featured web IDE (integrated development environment) for Avail. The Avail server still needs more development in order to realize this goal, but it is far enough along that the work can begin in earnest. Peter has signed up for this challenge, and likely we will all chip in to support his efforts. The IDE should include at least:

• A syntax-aware editor for Avail source files. (This is trickier than it sounds because of Avail's fluid syntax, but we have good ideas about how to do it already.)
• An interactive source tree, with the ability to load and unload modules. (This already exists in the web workbench.)
• An interactive entry point tree, with the ability to edit and run commands.
• Automatic compilation of dirty source files after a user-configurable timeout. This can also be used to provide live syntax highlighting.
• An Avail debugger. Everyone here is looking forward to this one. Developing a language is pretty hard without a debugger, even given a language like Avail that eliminates so many bugs at compile time!
• When macros become available, the IDE will provide an all-purpose refactoring tool that enables source-altering grammatical substitutions.

On Sunday October 26th, to make Cislyn smile I decided to build a custom web UI for "The Ship of Stories", the choosable path adventure that she built using Avail. The following snapshots are a short sequence of play, with the selected choices highlighted in yellow:

To try the web UI yourself, start the Avail server and then navigate your browser to file://$AVAIL_HOME/web/clients/The%20Ship%20of%20Stories/Client.html.

We have a pretty big vision for Avail on the web, and I promise to blog about it soon.