Archive for the ‘ Development ’ Category

Schema v0.81 Window Manager Screenshot

I’ve spent the past week building a window manager on top of the Knockout.js library for the Schema app. Here’s a screenshot:


Schema v0.81 Debug Build (featuring window manager)

Schema v0.81 Debug Build (featuring window manager)

If you’re interested in the HTML 5 details, check out my personal blog:

Framing the SCDL Data Model in HTML 5

Today’s Schema build is the best SCDL reference I’ve written to date:

Today marks my fortieth consecutive day of heads-down coding on Schema – a single page HTML 5 application for designing systems in Soft Circuit Description Language (SCDL – pronounced “scuddle” as in to make haste).

About half of this time has been consumed learning tricky details of other people’s amazing HTML 5 libraries (e.g. Knockout.js is really great).

The other half has been devoted to struggling to codify the SCDL object model (serialized to JSON and used to synthesize runtime code).

I’ve strongly resisted the urge to write about SCDL here as I’ve explained the concept countless times to some very smart people with little success to-date. I’m resigned to the fact that nobody is going to “get it” until they can see it. That is see and edit the graph models that underpin SCDL using browser-based SVG visualizations.

Over the past week I basically re-wrote the entire SCDL data model for Schema because it had just gotten out of control (entire data and view model in a single Coffeescript file). That single file is now twenty and I’m glad I did this now although I didn’t get a lot of sleep this week :-)

Tuesday I reached parity with where I was when I started refactoring and today the SCDL data model is almost completely framed in Coffeescript. It’s not yet functional (e.g. there are lots of methods missing) but the overall structure has been captured in classes.

Today’s development build of Schema is interesting. Essentially it’s a Knockout.js view bound to the SCDL data model with buttons that allow to instantiate objects. As changes are made, the SCDL catalogue JSON is updated dynamically.

If you’re intrigued by SCDL, check out today’s build.

Note that I’ve cached today’s build on my own website for future reference. Once the SVG visualizations are online, most people will not care about this detail (that’s the whole point after all). But today’s build is perhaps the best SCDL reference I’ve written to-date so I’m sharing with those of you interested in this early work.



Schema Day 32

Schema Day 32

I’ve been busy. The effort must be completed so that we can all design systems graphically and transform them into executing code. I’ll be really happy when this application is done enough to start sending out URI’s and explaining just what the heck this is all about with diagrams.



Generic Finite State Machine Library in C++

This is a little C++ template library I wrote over Christmas break in 2012 that implements a generic Turing Machine customizable to theoretically any task via static data tables that specialize for a specific input and output vectors, and a specific state transition matrix.

The example isn’t completely finished IIRC but that’s okay. It’s done enough to demonstrate the basic concepts that we can write simple little programs that leverage static data tables (e.g. SCDL models) to do whatever we want.

As a side note, while developing this example I found many roads leading me to the strange and wonderful land of  boost::proto. Proto can (and actually should) be used to implement my generic FSM. Why? If we convey all the structural and logical details of our design captured in SCDL to the C++ compiler, then the C++ compiler can optimize the ever-living bajesus out of it.

So for example, in my little library when “clock” edge (actually modelled as a function call) occurs, my simple algorithm performs several table lookup operations. But in my intended use case these tables are static data. I failed to convey to the compiler this detail so what it gave me was a generic library that can handle dynamically reconfigurable FSM (which I don’t need) at  the cost of imposing additional overhead in the case of static tables.

What we would ideally like to be able to do is transform SCDL “machine” models (so the static model data that comprises in the I/O vectors and state transition matrix) into a native runtime that an assembly language dog could not further optimize by hand. So no table lookups, just inline blazing fast code.

Given the simplicity of this little C++ program, later I may extend it a bit and try installing some variation of it server side for performing simulation runs (e.g. turn it into a webservice basically).

It’s quiet in here :)

I’m reserving this blog for talking about building software with circuit models. But in order to make it possible to efficiently even write about the subject I need pictures. Even better, I need a way to quickly make pictures. Even better, the pictures should be interactive, editable, savable, shareable…

This is the forthcoming “Schema” app for the browser I’ve mentioned briefly here. I’ve been busy: as of this writing encapsule/schema repository on GitHub is 66-commits old young and I’m on an unbroken 25-day commit spree. If you’re interested in my adventures in HTML5 open source development you can read the day-to-day here:

Early Schema SCDL Editor Demo

I’ve deployed a snapshot build of work in progress on Encapsule Schema – a single-page HTML5 application for creating, visualizing, and editing JSON-encoded Soft Circuit Description Language (SCDL) system models.

Demo snapshot build:

Although primarily a demo of single-page, cached HTML5 application development at this point. You can actually explore the SCDL data model a bit but adding and removing SCDL entities from the forms embedded in the app’s main page.

SCDL Catalogue JSON

Schema Editor Produces SCDL in JSON

As you add/remove SCDL entities from a SCDL catalogue, you’ll note that the JSON representation of SCDL catalogue is updated live.

This is not even pre-alpha at this point. But a good start :-)

If you’re interested in the HTML5 client development that’s going into the Schema editor, you can follow along on my personal blog:

SCDL and Web Services

My Dad has been having fun hacking with single-board computers and has been sending me a lot of links. This review of the of the Raspberry Pi Model A looks interesting: A quick Model A show and tell from Adafruit

I spent years working as an embedded systems engineer and have a love of these small and inexpensive single-board computers. As a side note my Leap Motion Leap should arrive soon and I want to try connecting it to a Raspberry Pi for some recreational hacking.

The general idea is that I would use a small HTTP server on the Raspberry Pi to communicate with a fancy-pants HTML5 application running in the browser to monitor the Leap and control routing of Leap data out to various other peripheral devices connected to the Raspberry Pi. The details aren’t important. But what is interesting is how I think I can leverage SCDL in this project.

Soft Circuit Description Language  (SCDL) is a JSON object model for “soft circuits.” Soft circuits are system design artifacts conceptually analogous to digital circuit schematics.

As SCDL is JSON you can send it around conveniently. Maybe you have a web service API defined on your embedded web server that accepts a SCDL JSON parameter as input for example. Now consider what our little embedded web service might do with the SCDL it just received.

Recalling that SCDL is used to model program specifications, one particularly interesting thing our little embedded web server might do is transform the program specification into something it can actually execute, execute it, and return the results of the program execution to the caller as the request response.

Let that sink in for a minute. We just defined a single trivial web service API that can be implemented with widely available technology that effectively eliminates application logic as we know from the server (client too but we’ll get to that).

Rather than server-side routing tables and lots of carefully written routines here and there, we have a single simple web service that will essentially re-wire itself dynamically to service requests.

We can apply the same logic to the client as well and application logic as we know it starts to magically evaporate. Yet the functionality remains. There’s actually no magic. Just some clever factoring. But it’s weird. So let’s dig a bit deeper.

Think of a JSON-encoded SCDL message sent from point A to point B as a request and response protocol.

Request input comprises: a SCDL catalogue in JSON format, optionally some other JSON-encoded data objects that will be used as input to the program described by the SCDL catalogue.

Request output comprises: a JSON string (possibly containing another SCDL catalogue to be processed by the caller).

Bringing this back to the Raspberry Pi and our little embedded web server example, consider that upon receipt of a SCDL catalogue from the client, the embedded webserver unpacks the SCDL and uses the “soft circuit” schematic diagram it represents to:

  • instantiate the described program using a library of native plug-ins installed on the Raspberry Pi
  • “execute” this program (effectively a dynamically created web service)
  • return the results to the caller in JSON format (data + possibly more SCDL…)

Here the simple web service has absolutely no idea what the semantics of the request are.

And, this is why I say that there’s no hard-wired application logic on the server. In fact there is application logic on the server. It’s just expressed in a very pure and compact.

Our server-side deployment consists of (a) a collection of  low-level plug-ins and (b) a SCDL catalogue that specifies the “parts” that a client can use in a “soft circuit” to form a request.

In essence, this static SCDL catalogue is your application logic. It defines a grammar of possible requests and maps each to a concrete web service, built on-the-fly, via program transformation.

I like this idea because I’m lazy. I don’t want to figure out how to talk to my Leap device when it’s plugged into the USB port on my Raspberry Pi.

Rather, I want to browse a catalogue of Leap modules, select one for Raspberry Pi, stick it in my deployment package, and then expose it via my server’s SCDL catalogue. That way if a client wants to open a web socket to read a live telemetry stream of Leap data, it can send the server a SCDL request containing a little “soft circuit” that connects the Leap module to a web socket module.

Client-side, I’ve got the server’s SCDL catalog. I see the server has a Leap module and a web socket module and I know that the server knows how to connect the two somehow. I also know how I can ask the server to connect the these two resources for me.

We’ll come back to this topic later. That’s enough to think about for today :)

SCDL Visualization and Editing Ideas

Soft Circuit Description Language (SCDL) draws its core concepts from digital circuit schematics and defines a schema for serializing the following entities to JSON format:

  • virtual software “cores” – small, re-usable Turing Machine models
  • virtual software “chips” – re-usable system specification assemblies comprising any number of “cores” and/or “chips” wired together.
  • virtual software “circuits” – an abstract blueprint for building a software program.

The HTML5 SCDL editor I’m working on leverages D3js for data visualization (and some interaction). I am hugely inspired by this library.

Some ideas:


Relational input & graph building:

SCDL model hierarchy navigation:

SCDL interconnection topology:

SCDL entity interaction:

SCDL core transition matrix:

Simulation and test results: