Make Install: Polycode

I somehow stumbled on Polycode, which is an interesting "free open-source framework for creating crossplatform games and interactive applications". It reminds me a bit of Processing, except that you use C++ or Lua for creating applications.

In addition to supporting 2D and 3D applications, it features a large selection of asset loaders (including Blender, of course) and has a Unity-like IDE. Runs on all major platforms, though there are no ready-to-download executables yet. You'll have to build everything from source to get started.

As an added bonus, there is a blog linked to the polycode. Always nice to see developers writing about their pet project.

Minimalist Dataflow Engine

I'm really enjoying these minimalist literate programming exercises, so here is another: a minimalist dataflow engine named "dfntly". It is very loosely inspired by the excellent Knockout library, but obviously has much fewer features. I would like to add some support for observable arrays, for example, and for asynchronous calculations where the dataflow engine only calculates further when the reply comes in. But that's something for another day.

In the meantime, if you feel like it, give it a go!

On "The Next 700 Asychronous Programming Models"

I was watching this talk by Philipp Haller on InfoQ on "how to make Rx programming more natural and intuitive by generalizing Scala's Async". The cliffnotes are this: unify the two by implementing async through observables. Clever.

Now, while the result was interersting I got a bit "stuck" thinking on this example from the presentation:

val futureDOY: Future[Response] =
  WS.url("http://api.day-of-year/today").get
val futureDaysLeft: Future[Response] =
  WS.url("http://api.days-left/today").get

val respFut = async {
  val dayOfYear = await(futureDOY).body
  val daysLeft  = await(futureDaysLeft).body
  Ok("" + dayOfYear + ": " + daysLeft + " days left!")
}

What it's trying to do is retrieve data from two remote services and compose the results in some way (don't worry about what it's really trying to achieve; it's one of those hypothetical examples which academics are really good at; I know, I used to be one). Now, as you may have noticed the services are consumed in an asynchronous way. That's where the need for futures and explicit waits for their results comes in.

Having been playing a bit with futures and their composition for the minimalist asynchronous process virtual machine I understand the mind bending it can take to get this right in more realistic examples. As a programmer you constantly have to be aware of what methods return results which are immediately available (i.e. are synchronous) and which ones are not. Because if you get it wrong the results will be unexpected and probably quite annoying to debug.

So here comes my question: rather than trying to come up with lots of creative ways of composing asynchronous behaviours and avoiding callback hell, why not stick to the principle of least surprise and make all asynchronous calls act as synchronous ones by default ? What is really stopping the above code from being as simple as:

val dayOfYear = WS.url("http://api.day-of-year/today").get.body
val daysLeft  = WS.url("http://api.days-left/today").body
val respFut = Ok("" + dayOfYear + ": " + daysLeft + " days left!")

A programmer's default mindset, I would argue, is that code is synchronous. By making that the default the obvious solution becomes a correct one.

Asynchronous execution, if wanted, can still be supported by explicitly requesting it. So another way to write the example could be:

val futureDOY: Future[Response] =
  async { WS.url("http://api.day-of-year/today").get }
val futureDaysLeft: Future[Response] =
  async { WS.url("http://api.days-left/today").get }

val respFut = async {
  val dayOfYear = futureDOY.body
  val daysLeft  = futureDaysLeft.body
  Ok("" + dayOfYear + ": " + daysLeft + " days left!")
}

While not as concise as the earlier rewrite at least it removes all doubt about which parts of the code don't want to wait for specific results.

Anyway, just wanted to get this off my mind. If you like, or think I'm just blowing smoke, let me know.

Minimalist Asynchronous PVM

So adding support for asynchronous tasks turned out not to be so difficult. With a little help of Q's promises and support for composing them all it took was a minor rewrite of the main tick function...

Anyway, this version of the minimalist PVM can be found here, together with an example which queries the OpenWeatherMap API.

Note that in the process of doing this I also added some minor tweaks to the basic version of the PVM; the most useful of which is the ability to define a starting runtime state for the process upon activation. I extended the examples there as well to showcase this.

Minimalist Literate Programming

As a quick follow-up to the minimalist PVM you can now find a very simple literate programming tool over at my github. It's a single Perl script which converts source code into a Markdown document. It does this by extracting the text from the comments in the source code, and wrapping the code itself in code blocks. Want an example of the output ? The README.md for the tool is exactly that. (Self-documenting code FTW!)

Minimalist Process Virtual Machine

Over at my github account (see, I do have one) I just added a minimalist implementation of a Process Virtual Machine (PVM).

Wait, what ?

Let's start with what a PVM is. You can find a thorough description of it here, but in brief it is an engine which can drive automated business processes and workflows. It actually forms the core of JBPM and Activiti. (If you really feel like geeking out on workflow engines you should definitely head over to Joram Barrez's blog, which has all sorts of Activiti craziness in it.)

I really wanted to figure out what makes such an engine tick, and while I can look at the source code for JBPM and Activiti they were never meant as an educational example. These engines have real work to do, and so come with usual amount of hardening and boilerplating. Rather than deep-diving through all that I wanted to see what a minimalist implementation could look like.

When it comes to minimalist implementations a lot depends on your choice of language. Ideally you want something which is really flexible without imposing a lot of structure. Prototype-based languages are a great fit and, as it so happens, Javascript is a popular example of one.

So that's where I went. I've got a minimalist PVM capable of running in a Node.js environment. As you'll see there's very little code to it; and I actually spent most of the time getting everything into the form of a literate program.

Because it is very minimalist there are certain features it does not (yet) have. The big ones are wait states (e.g. for human interaction), asynchronous tasks (e.g. for doing IO or REST calls), and persistence. In a future version I'll see if I can add those in a minimalist way as well, but for now this will do to satisfy my curiousity.

If you like, let me know; and feel free to experiment further.

Make Install: Solarus

Solarus is an open source Zelda-like 2D game engine. How Zelda-like, you may be wondering ? Well...



I'd call that pretty convincing. :-)

For the curious, it has a C++ core, and uses Lua for scripting the actual games.