README.md

Cuttlefish

Cuttlefish is a Distributed Dataflow Machine Control Context for the browser.

Cuttlefish is an 'Integrated Development and Operation Environment' or something - an IDOE (?) / IDDE: an 'Integrated Dataflow Development Environment'.

It's main job is to provide views (see hunks/hidden/view.js) into other controllers' brains, and help you compose those brains, hook them up to eachother, and make sense of big sprawling programs as one big pile of delicious messaging spaghetti.

Native Cuttlefish 'Hunks' are given access to a DOM/div element, making them nice UI canvases.

view

The Latest

I'm excited about this, so here's an image:

... many lines of js later, I can 'explode' hunk definitions, which means I can invert link relationships, so that I can visually explain nested network relationships in the graph. I've also simplified a lot of view objects, and have come up with this satisfying idea about recipes and atomic operations that I enjoy - that helps me a lot in patch loading, saving, etc - especially for big messy patches (I hope)

Here's the 'unwrapped' link on an 'edgecase' link. This is like looking through a door: depending on the side you're on, the hinge is on the left... or the right... or, fittingly, tx and rx are rx and tx depending on from-where you take your UART names. The cable flips. Etc.

w/r/t force layout

I've re-written much of the display code. the 'view' hunk, that does rendering work, is about 2500 lines all together at this point, which is a pretty yikes-level of code for me.

That said, it's basically the whole project's workhorse - which is interesting in itself. This is one thing I'm definitely excited about for the project: the contexts / managers are very simple - the whole thing has this pretty straightforward 'hind brain' that is just pushing memory around (inside of contexts) and pushing bytes around (over the network).

This might sound like a boast, but I guess this is kind of similar to writing a programming language ... at the base, the instruction set is really small. The syntax, rules, compiling, etc of the language is big, cumbersome, and messy.

The most recent add is to do with making visual sense of nested programs. In order to do this, I've broken up what were previously single <div> elements into collections of them... i.e. inputs, outputs, and state each get a box to live within. This causes some more complexity to the view program because I have to keep track of these handfuls of html elements, and then there's this: I use the same mechanism to 'explode' hunk-definitions, and to 'wrap' (i.e. links) around others (i.e. views). This is really handy, because it lets me accurately draw link->link representations 'across' the link divide, and lets me 'unwrap' a pattern that was very visually cluttered: this common 'hourglass' structure (i.e. feedback).

So, I wrote this all in a rush, in what felt like a javascript bender, and now I'm trying to catalogue accurately what-all happened, to track and hopefully resolve. What I'm working towards is bringing force layout back into the picture, because (as is easy to tell when opening a big program) these things are hot hot messes, and I'm not up to storing positions exactly yet, because that sounds counter to the point.

Here's the things I'd like to be able to do: