Hello DMCC Browser

Find fun pet name? RuNDMC stays? Reconfigure, Use and Navigate Dataflow Machine Controllers.

The Dataflow Development Environment

An IDDE: Integrated Dataflow Development Environment.

Our dev environment is itself a context having hunks and a manager... We're not so much writing programs as we are scoping into contexts and sending messages: add this, connect these...

Loading / saving programs we can do locally for remote resources. So long as our mutual understandings don't change (a thing called 'this' does 'that', has 'these' and 'those' outputs etc).

To Start

I'm going to re-write the browser to have its own DMCC Manager.

The browser is going to display, using most of the same code, hunks and links from multiple different contexts, by piping its fingers through whatever link it wants.

One of these managers is 'Native' ...

so ... ui sends messages ... to whichever manager. to start, it's its own manager

Context Switching

I'm figuring the browser (to start) has a dropdown menu, where you can poke through links that are displayed, and set them as the browser ports? Like, the view 'ports' ... ? Some handle that the browser can pipe events into, and handle responses from.

Navigating

This problem is tricky.

UI is a hunk as well, can post messages to managers, and receive them.

It draws things based on these messages...

UI is hefty, and all knowing, but at mercy to the manager for execution, and it has a loop f'n. Many fingered.

At the core of the browser-does-dmc business is this misalignment between the browser world of callbacks-and-event-catching and message passing.

-> at the moment, rewriting port reps, dom 'def' handling -> towards saying hello to an in context element(s) and manager

-> then we want to abstract messages, links, etc ... and pick contexts for right-clicking, and have heirarchichal dom handling

• get up to bower loading things today

• write one module having buttons

• write one module having canvas, loading svg

• write the logger module

• consider a state change

• managers ... and contexts ... and links ... the crux

• consider your UI drawing as a member, a hunk, having links to links ... having each UI context also heirarchichally rep'd ... this makes lots of sense

• req for load does not callback, it's a message

• same with state change

• same with module adds ... reflect this

• roll manager back into node

Cuttlefish / Lilith

OK, I want to make clear what-all I'm planning on doing here.

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

So, we set the UI up as a Hunk within a top-level manager, and set it next to another Manager. So, at the get-go, we already have two managers, nested. The UI element is initially hooked up to our one-and-only manager to begin with... It gets its own DOM in the browser.

The UI hunk won't ever see that toplevel manager.

the native manager contains other managers, one of which has access to the dom (the first) the native view contains all other views

view -> | -> nativemanager view -> | -> anothermanager ... etc, ... at the top level is this manager running two hunks, one a view, one the native manager... probably the yin, the yang, and peace in all the kingdoms

-> tree message (stateful) -> or std message, others: -> add link -> ... ? these are also outside of tree

f

A view is an object that has (1) a path to a manager, and (2) a dom. This is simple enough, however, views can also spawn and contain other views.

To start in simple time, I'm going to write a view object, give it a dom and a messaging port to a manager. When we spawn a new manager, I'll have links, and answers.

View doms are related to one another in a way that is similar to how messages are routed to their managers. These are mirrored trees. They mirror about ... the ... link ?

This feels strange. That's because the views are also hunks that run in a manager. Inside of our view, we have to have some nesting, the same as our managers are. Views need loop() functions, and to be able to add views... to have a list of views. OK.

Let's get to that heirarchy.

Message Statemachine Trees

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)

OK

I'm getting a bit tired of this. I'd like to draw some machines tonight, or do any other list of things.

To wrap up for tomorrow, here's what I want to show:

• load items into the dom
• connect those items and draw their links
• unfuck the div zoom, etc
• ... should be ready to link-in to a node process

Then I should be able to write up a decent plan, and some next steps. And clean up some.

Log 2019/03/10

Things I'm going to want to squish today:

• finishing 'view' i
• escape key & paths ... some clean ui state elements ??
• paths betwixt events

Log 2019/03/12

.. still trying to finish view

• receive messages for adding links, changing state (replies from manager)
• then the link, the nested view
• the link : manager relationship
• the node : browser manager differences ?

The Link

Ok, I think I'm up to this.

Links are primarily responsible for ferring data between two contexts. This means (1) data to / from managers to / from views, and (2) normal stuff.

Since managers themselves have an input and output,

• ok, conceive of each hunk as having access to the manager.
• .postManagerMessage()
• this is a way for state events to bubble up, and down?

Managers don't chat with Managers, they chat with Views.

More like they fire events when things change (to all who are piped in to those events) and they receive messages to change things. They have one msgs input port, and one output port.

Typically, these are connected to (a) view.

But this is all just hookup. Links have one bytes -> bytes input / output (the physical data link). Then they have adaptively-added input and output ports. Typically, we hook ah link's 0th input up to the manager on the other side, and it's 0th output.

So there's two different things going one: one is message passing. The other is a messaging API between the Managers, Links and Views.

I think the tree -> routing thing I am thinking of is actually less productive when, i.e., I would like to connect the same context via two ports, or connect two lower level ports to one another.

I think that NROL / Cuttlefish might have to be more omniscient.

Things I've learned from this dom spiral are:

• use IDs in the dom, and jQuery is nice, and store data in dom elements to disambiguate.
• cuttlefish dom elements are unique, don't think too hard about them
• you can build out view() pretty much independently from everything else, give it a message api pipe, a dom, and ur gravy
• you kind of have this choice right now between a nested heirarchichal representation that acknowledges system perspective, or one that shows the network more explicily, displaying 'links' as well as 'output wires' ... or whatever that distinction is ... rather than 'hiding' the 'link' underneath a hunk of code.

Log 2019/03/13

OK, do links, bootstrap node and websocket, get descriptions and then wonder about how to draw them.

Wash list, rewrite button, write string, handle manager with lists not objects for inputs / outputs.

• button to -> string thruput -> link port -> link output log

View Potshots

• right-click on name to delete
• escape key to leave menu (/ keys on dom ?)

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 ?