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

Scratch

'aye, but as the legends state: software doth make the hardware singeth'

IAA ... it's all addressing -> ->

still notekeeping ... peep the below, then ... manager walking, type completion, and back to nautilus, tonight the ponyo return

On Friday the Hardware Singeth

ok, patches via this (numexcludes) hack ... that's ... just fine before walking over, probably a few final rites

• just sanity check the manager, probably write something (including notes about what-happens-next) ... and, like, where are you at with the manager message set? is this a complete set? consider embedded ... minimizing embedded work, and the corner cases like state loading and state-before-init ... !
• before you 'take the dive', wrap up typeset, and write those things down also
• also, to avoid insanity, maybe take tuesday morning for hardware / swd debugging ? load that bootloader, say hello to ponyo ?

really, genuinely, things you'll want as you go

• bring back splash loading ? save positions into patches? I'm imagining a more complete system with in heavy program-reps-in-json only world ...

ok, for the future, save will only be possible with a 'save selected' patch or something similar: picking whether bootstrap hunks should be added etc ... I can't make this decision right now

for now, just don't save those... you know which ones they are, and you can check the version in the view, and have a standard (known) bootstrap program set. ok... then we can rip thru adding programs !

still need to work out those relative-links-and-indices

this is an impatience thing, I should note. on another loop through the view, this will be first order.

...

monday circuits, programming, ponyo hello / refresher, and instron assembly ?

cuttlefish -> nautilus on tuesday, and see about drawing links // coordinating across links 'well' (but what of the split link ?)

ponyo late tueday, and wednesday, thursday machine assy ... friday same, probably

A Pickle Averted

• ctrl f for INDSWAP
• and RETURN

program save / load

• rewrite / integrate with briefstate messages ?
• once up, test deleting etc, some uncertainty about connection unhooking

// for interest, 'startStateRefresh()' inside of vptch.js is where you broke off

// to restart, go back to saving patches: do by index, etc... and then on reloads, you'll have to contend with that same-ness issue ... i.e. those first two hunks, or whatever other bootstrap structure is being replaced

links, cuttlefish

• going to have to wrastle type conversion allowances, i.e. want to go from num -> uint8 at the link, fluidly, and want to be able to name js types with 'uint8' - particularely at the link, try this first, that's your entry bug
• link also doesn't build inputs / outputs when the names are 1 char long

Important Lessons Learned

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.

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).

End Notes

UI / Usability

At the moment, the UI really hobbles along. There are a few big bugs and problems to undo and I've plans to crush these out apres serialization is 'solved'.

• 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

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... (is this still true?)
• 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 !)

View Potshots / UI Code Golf

• link hookup still doth not rock
• contexmenu click not localized (when zoomed out)
• would like state to be size-by-value ... for strings ... w/r/t names
• 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