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

LOG.md

Blame
  • LOG.md 37.69 KiB

    Cuttlefish Dev Log / Scratch Notes

    Dev Prayers for Machine Week

    things that should work before MW

    • properly handle logging of anything and be able to inspect any datatype with this kind of tool (i.e. see the path...)
    • hunk API cleanup:
    • don't have to push new outputs / inputs to the hunk manually (but cross compatible) - confusing if we make it, and it doesn't appear, wtf?
    • err path cleanup ... i.e. cover cases of new hunk writing:
    • syntax errors (in code, on load)
    • file naming errors

    Dev Golf

    hour +/- long tasks under existing structures,

    - assign meaning to charts and graphs (date / location / etc)  
     - this should be generic json-object making, yeah? / csv
    - save tests as .json objects (optionally) develop program for reading  
     - overlay multiples, save images  
     - read-in csv as well, polymorphic for outputs
    - generic wrap / unwrap data objects ...
    - the force loop / layout (floop.js)
     - wire length != zero
     - better keepout-rectangles
     - spawn new hunks at the mouse (floaters! things 'inside' of others!)
     - how to do this all elegantly ... it's ah big redesign: take some hours, consider, maybe it's not so grand ?
    - sys / save etc
     - dates & times in metadata on list ...
     - save systems w/ layout ??
    - menu
     - arrow keys to bump through items
    - import
     - lit-html, emojis don't load when developing offline: store them somewhere.
     - lit-html just writes html strings into the dom? probably easy to rm

    Examples

    Build a looping structure that replaces / stands in for traditional 'for/while' type structures. Recursing through offsets for the path is the currently pertinent example. Again this is a kind of polymorphic issue / etc. Want to write one kind of recursor, often need some secondary trigger / flowcontrol gate item that is of-the-appropriate-type.

    Aspirational Dev

    Things we want to see, extensions, etc,

    Compound Types

    I was thinking about the cf 'api' / workings today. At the moment there is this convoluted / poorly named system where the view messages the manager with some similarely-but-not-well-named names. In the browser, these are actually hooked up through a messaging loop, to abstract in the same way in JS / CPP (remote) and / JS (remote). This was great for development, but there's another way to do it that might be much nicer for the future... which iiiis to retain the 'view' object, but (at the top level) attach each of it's core function (the eight) directly to the manager's reciprocal function, both cast as promises. Other views can call the same promises, but in those cases they're hooked to the view's messaging 'subsystem' ... put this note in the relevant repo.

    For mixed up data types / polymorphism / I just had this idea this morning (more of a clarification) about compound types, and their wraps. Compounds, and Compound Arrays. This is maybe worth some time, and some drawing. I was considering the Squid/Protocol in the context of big serverside apis / the microservices trend. This future where people don't build eachother's software source, but people plug into eachother's operating hardware: where we collaboratively wire together one big operative graph. To mux big data objects, we can wire up / bundle compound data types, named. This is a serialization that rests on our core set of byte-structures, and a wrapping / unwrapping tool, that names things. For instance: a compound wrapper is a hunk having some set of inputs, and one output. The inputs are typed / named as is tradition. Some of these can even be other compound data types. The wrapper (sync / async) takes data off of its inputs, and wraps them into one serialized message, that has some known 'compound' structure... Like, a list of names, then data bits all serialized in key, with type-keys leading. In the compound array messages, we have an array of these compound types (this is the CSV type), where we have one list of names, arrays of these type-keyed objects.

    This is a really nice thing that I would really want to see. Compounds should maybe have names, but should maybe just be id'd by their final roots: any ordered set of the-same types of data should be compatible with the same: that's really the data-type identifier... Noice.

    ... treating data like this allows complex, application / architecture specific representations to be used, but bundles interoperability into the core datatypes we ... likely all agree on. this is on the expectation that computing becomes more specialized as we progress, not less.

    Better Error Paths

    I do, really, want to use this as a wrench. The first component to that is to reconsider error- and logging paths. Though this might add some small delay, I can wrap the cuttlefish manager's loop in a try/catch loop (over per-hunk loops as well). I can write logs out to a floater that is associated with that def's core. Top level logs can come from the manager... bootstrap can catch very top level, those would be halting. Error paths should also default to logging to the console as well... and modifying both to change logging behaviour should be possible.

    Past Logging (Completed or Forgotten Tasks)

    Next Desires (2019-09)

    I think that mostly I would like to focus on the potential of a KOA / Express cuttlefish & vfp package, to run local systems away from my active development.

    Following this, probably the best things to do will be address things like type inconsistencies, and add better error pathing... Also, tickets like the network-level view, and starting to daydream about the interstitial routing layer, if it exists? That awkward link.

    The Latest (2019-07)

    I'm excited about this, so here's two images:

    explosions2

    explosions2

    ... 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). I have also learned: UIs are a PITA.

    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.

    To wrap these things, I can compose 'recipes' from cuttlefish, to manipulate graphs, i.e. building routes and then organizing visual heirarchy accordingly:

    route dev

    Alright, here's the real moment: opening two-layers-of-links down into a (home for) an embedded instance.

    double dev

    Couple of things, at this point:

    • browser performance ... starting to feel the lag, surely, many things could be done to improve this. another day.
    • video capture makes thigs ~ 4x slower. graphics? idk

    OK, after some more testing with genuinely time sensitive systems, I'm not interested in doing planning in the browser anymore. That means that I want better tools to work intimately between node and the browser. To start, I refined my route building tool, so that I can quickly push events down layers. Here's a clip of my ui element (an arrow pad) connecting to a planning element that needs to run ~ 100Hz loops to hardware:

    devdown

    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:

    • blow-up definitions, having inputs, outputs, and cores be in potentially different places.
    • have 'exploded' elements, probably most often used to 'unwrap,' say, a data pipe around a link, (to unconfuse the hourglass)
    • using exploded elements, pin outputs to the left, and inputs to the right. this in particular to show a link 'across' a view
    • wrap a link around a view
    • resize views, and other 'native' elements.

    Other tricks

    • the message board should perhaps belong only to the top-level view, and should be easily hidden

    Considering Force Layout

    There'll be a handful of tricks to make this work out well

    -> a good update model -> this thing can also check our 'rulesets' per the heirarchy, for links and views and whatnot -> that's a kick (topology changes and checks), and a tick (simulation step) -> integrating this with manual movements ... -> the floop should probably only run at the top level ... but subroutines will be nice per view because -> we will have / want to adjust the size of sub-views (in a bubbling kind of way) from the bottom-up... i.e. we really want to avoid overlap, etc

    Probably a good first step is a run through the .def tool, to invent a decent API for moving, exploding, gathering, etc. making 'edge' types. Three types...

    • fixed
    • exploded (just str8 up kapow, but maybe as a rule just blow up the input ?))
    • wrapped
    • unwrapped

    For each object, I'll want to re-write the .deg api so that .deg.inputs.moveto() is a viable function, etc ... such that when I'm running through the sim, every free entity can be one of these ->

    floater.moveto(x,y) // floater.fix(x,y)

    and those can be walked as nodes ...

    dragging objects ? just kill the sim I guess ? or fix it during the sim ... dragging objects should use the same floater.moveto() setup, or a .moveby()

    then I also have to handle native-element resizing ... so .wrap objects need to react to that...

    and then there's this question about how to do it heirarchichally - or all at once, in one floop ? maybe all at once is easier ...

    A good way to set rules ... like, what's fixed etc. I.E. consider -> the ears of a link expand 'around' a program, pushing the view definition 'out' - how will these 'forces' be connected? Just .set the view to match, let them float? Pin the left to 0,0 and float the right? Then take the lower level constraints as fact? nice.

    Traversing Heirarchy

    I am having a feeling that I am going about this poorly. I should remember that I am here to build a tool, not get into semantics about UI and write nice APIs for myself. Alas, black holes abound.