to make matters worse, I already have a plan for a simpler prototype of this project that requires 0 comonents except for RGB LEDs. I should just wait until I at least try that out (which is probably going to take 6 months of its own anyhow) before I speculate about making a whole new thing with a ton of R&D...
transplanted a broken ballpen (wooden enclosure split in the front and couldn't hold the brass insert anymore) into soke aluminum L-brackets in #theWorkshop today
Makes me think about editors as general (and more customizable) shells:
imagine a complex, running programming system. You connect to it by opening an empty file. Every time you write to disk (or stream it to a binary) the system writes feedback back into the same file. To edit e.g. a named function that is running in the system you type a macro and save. The system replaces the macro with code that redefines the function. You can then edit and redefine the function.
"The codebase manager lets you make changes to your codebase and explore the definitions it contains, but it also listens for changes to any file ending in .u in the current directory (including any subdirectories). When any such file is saved (which we call a "scratch file"), Unison parses and typechecks that file. Let's try this out."
Reposting from inside thread: this essay by paul chiusano is my go-to justification for end-user programming, and problem-analysis of the user experience status quo:
"[A]pplications (“appliances” is a better word) come equipped with a fixed vocabulary of actions, speak no common language, and cannot be extended, composed, or combined with other applications except with enormous friction. [...] Applications [...] should be replaced by programming environments."
tye type system isn't too tricky to do, but it would be great if every client could bring their own set of coercion/transformation functions. How can I formulate these and bring them into the type-pathfinding process without compromising the server (code execution) or losing predicate accuracy (structural matching)?
the RW server is just some housekeeping and general grinding. Just realizing that maybe I should even rely on something external like webDAV backend.
The type negotiation is the biggest topic. The type system itself will have to change first, and then I should probably switch to something like A* rather than breadth-first search. Just wouldn't know how to formulate the heuristic there (cost is pretty clear - sum of estimated data weight (bytes) and processing power required (cpu time?))
Happy I'll get to work on mmm.s-ol.nu again. Todo list for the BA topic is:
- local server with RW access, just-in-time content processing/conversion
- new client with content editing capabilities
- server & client negotiate type conversions on either side of the transport
- reimplement SSR "fist-class" (after RW server replaces SSR as only access atm)
thinking about how to make a dactyl keyboard (https://github.com/abstracthat/dactyl-manuform) more portable:
- mating cutouts on the bottom of the shells, where there is an excess of space anyhow
- dividing the shell into multiple hinged pieces to flatten it out; with magnets to lock it in the folded position (lots of oofs in constructing this; hinge positions, overlap, running the wires...)
Revel in the marvels of the universe. We are a collective of forward-thinking individuals who strive to better ourselves and our surroundings through constant creation. We express ourselves through music, art, games, and writing. We also put great value in play. A warm welcome to any like-minded people who feel these ideals resonate with them. Check out our Patreon to see our donations.