Skip to content
Snippets Groups Projects
Select Git revision
  • c87558b241d8befffa5658b7e212dec2f16d7aa2
  • master default protected
  • leo
  • dex
  • pendulum
  • apfelstruder
  • littlerascal
7 results

cuttlefish

Jake's avatar
Jake Read authored
c87558b2
History

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

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: (1) are either requests or responses

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