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' can write to the DOM elements they are attached to, so we can use it to compose machine interfaces as well.

view

Notes

Today I'm combing through my very rough notes taken while I wrote this thing. I take for granted that it's not done yet, but in the effort of spiraling through writing... Here are some synopsis that I should not forget are things-worth-mentioning.

Scratchy

demonstrated a nested view, and messaging through a link

biggest questions are about

• how to serialize data for cpp contexts
• link -> manager ... names ... ports ...

potshots are

• a session with D3 ... to make it genuinely work
• this goes along with bz tools
• debug why BZ tools fails with a nested view (just... integrate taht state with view... carefully pick through)
• this also goes along with 'view methods' ... poking through the graph and enforcing adjacencies between views, links, and data devices ... and the highlighting through
• try just the highlight through the link -> find by name, this leads to finding and positioning

Views are Hunks, Too

An important aspect was that the 'View' (because we can have many of them) is also a 'Hunk' - this was at times confusing when writing the 'native' 'manager' for the browser, but is going to be a real watershed when I start opening offworld contexts up. This way nothing is mysterious - views aren't mystery windows into other worlds, they are software objects whose messages are obviously routed through the framework.

The UI participates in the computation: anything a user does needs also to be flow-controlled, passed as a message, etc.

This means (as I hope I will see) I can route many views through many contexts, although the view(s) are still obviously (as they are) hunks that operate in the cuttlefish context only.

This still annealing, but I like the direction. It's a tricky pickle, and really at the heart of this problem. Singular views into many programs running together, at once.

State in the DOM; use JQuery & Unique Human-Readable IDs

A big windfall for implementation was my adoption of JQuery and DOM-element-id-writing for selection, etc. This makes programming kind of 'conversational' ... I think most web developers know this, but now I do to. This lets me avoid keeping some global state objects, instead just inspecting the DOM every time something happens and checking it for consistency against messages I receive from the manager.

Give Up on Storing Position

TBD, but I'm going to try to adopt a policy of live-positioning everything. D3 has a great, straightforward force-layout scheme... I can use this to load graphs and draw them in 2D space (actual dimensionality: ?) without having to write those positions into the program representations, where they are meaningless unless rendered.

CSS Transforms are a PITA

I spent a good deal of time struggling with scaling and panning views. I'm not sure that I learned anything, and while I couldn't find it at the time, I think I have figured out a simple way to alleviate my pain on this front. I'll leave this note for myself here: div(div).

JS Promises are Great

For async module loading, etc. Do use. Herringbones nicely with event graph model and is a helpful model when considering how message interperetation should work (i.e. forces / reminds me to consider message reception as async).

Contextual Messaging / Heirarchichal Messaging

This is something I'm still very much working through -

'messages are graphs too' is floating around. I'm still trying to narrow down the set-of-messages that a manager should be able to react to. To start, most routing is just program organization. In some instances things will be contextual though, and are implemented as such: for example, I'm looking forward to implementing (in cpp) on microcontrollers a manager that lists 'available hunks' in relationship to which (limited) microcontroller hardware resources are not already initialized in the graph.

In another context, to allow managers / contexts to grow features without having to add them 'across the board' (for example: I'm probably going to want an idea of graph execution priority in the micro, but not in js), I can use a call-and-response type of message tree traversal. For example, from the manager:

  this.replyHello = () => {
        // writeMessage does buffering on our end
        let options = [{
                text: 'list available hunks',
                header: 'listhunks',
                content: ' '
            },
            {
                text: 'describe running program',
                header: 'listprogram',
                content: ' '
            },
            {
                text: 'save running program',
                header: 'saveprogram',
                content: ' '
            }
        ]
        this.writemessage('putcontextoptions', options)
    }

The 'view' doesn't have a baked in set of 'right-click options' - on a right click it basically just waves at the manager - the manager can decide to send back what-all are the possible options given its state. This is some kind of conversational programming...

Also consider: the 'fog of war' but for these graphs. The notion of graph traversal doesn't exactly reconcile with another idea about stateless message adoption... but we can pass entire graphs each time.

hello -> <- available branches (bytes: names) branch -> <- response (branches or action) ... ? branch -> <- response (branches or action) action -> <- confirm, new status

Messages:

• request list of available
• hunks
• programs
• request to add this thing (hunk or program)
• request to link these things (outputs to inputs)

In my dreams, this is a way of key-parsing messages as well. I.E. I don't really want to write down a list of keys / values for manager messages - these should be locally defined by the unit that will respond to them. I am fond of that 'replyHello' implementation, and would like to extend it to all aspects of manager-ness, and think that this may be an especially helpful idea in the world of purely-serialized data and micros.

Serialization, Links

I'm up to this, now. To test, debug, run faster, I'm going to focus on bringing about serialization truths to cuttlefish / nautilus, before deep diving into ponyo.

Basically, I want to get rid of message-passing-by-json because string-parsing everything would be a bigtime slowdown. Quizically, I'm going to keep string-parsing inside of managers, but not inside of links.

To wake up, I've a small list:

• type-name inputs, especially at the link
• same for comm/
• rebuild / use scrape.js (with //HEADER and //ENDHEADER flags)

There's some UI leftovers in the view.

• want to kick around on spreading things out properly using force layout

• can't add links, did this actually work before ? drag correct zoom factor, and cancel other moves

• towards using state-load-at-program-load to set retrycount to 0

• loading is messy,

• load in state objects before init (rolling through much old code)

• view should have display location for messages you anticipate users needing to see, primarily errors that are responses to view requests: like addlink (type errors) or addhunk (resource not available from cpp) or errors from hunk v8 loading, json program loading, etc.

Once I'm through that, I should be back at happily opening up nautilus-via-cuttlefish. I'll polish my UI, particularly wire views.

I'll explicate the list of messages that I need to send to managers, and to links.

My links, and state-loading, aren't really well enough developed yet to do what I would like to. A generic 'link' can't be limited to some # / type of inputs / outputs. The interface needs to be developable.

I know I'm going to implement some state-object loading on startup, and have init functions. I could use two state objects (inputList and outputList), those being inputs / outputs typed: like "charArray, uint32, float, floatArray" - on init, or on change, we can match this array to internal operation. And can put messages on them via first-byte drop-in (with type checking!).

First order would be re-building links to have non-static wakeup states.

Messages to 254 port are debug, should just be printed. Messages to 253 are to the link itself? Otherwise 0-ordered, and 0th port go to the manager, by convention.

What's stopping me from implementing this? Am I burnt out?

I think this also asks me to reconsider how programs are loaded. Does it? No. It's actually a good test of the existing system.

So, there's a lot to do. It's a good thing I love JavaScript: every language's bastard son, in a King of the North kind of way.

• state objects are typed,
• state objects are written at program load, if they're there.
• does this mean that they go into 'add hunk' message ?
• reload link verbatim but via state-load
• then scrape to nautilus ... and load via ws
• maybe then is view cleanup ?

A List of Types

Since serialization is pretty bound up with types, and I'm going through standardizing that now, here's a list:

Type Name	Length	Byte Structure
byteArray	n	250,n,b1,...,bn

Videos to Take / Demos

• loading with view relaxation
• loading a link, spawning a view
• show two cuttlefishes with views into the same nautilus, editing together... or just pushing program edits back and forth.

Known Bugs

• adding link from the DOM doesn't work when id's don't have one underscore in them...

• an error while adding a link prevents a program (or hunk) from being sent to the view ... addHunk and addLink errors should be carefully handled

Bug Foreshadowing

Here's a list of things that I suspect will eventually roll themselves into bugs with enough testing.

• receiving messages from tree crawl on right-click, after menu dom has already been cleared

• many errors are not appearing when things fail to work ... I believe any undefined / null etc are lost in the wind somewhere. try writing to an object that doesn't exist, or returning it...

• still a drift on the y-axis when zooming // difference between background positioning and div positioning, perhaps div transform origin is lost ?

• program load browser does not consider the case for two identical supplied module ids - i.e. loading two programs (i.e. copy/paste section !)

• inside of the loop, it's possible for things-to-call changing during one loop iteration ? is it ?

• should not be able to add a hunk's output to its own input,

• this also causes (probably) bugfarm when removing a hunk, as we first remove the hunk from the manager's hunks array and then we look for outputs that were connected to it elsewhere

View Potshots / UI Code Golf

• escape key to leave menu (/ keys on dom ? /on new right-click etc)
• on zoom, check if element is view or not,
• if not view (is block) then look for event parent position, not event