s-ol @s_ol@merveilles.town

(gonna take 6 months *until* i try that out, not 6 months to try out. should only take one or two days)

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

oh my god why did I spend an hour researching the components I would need to buy for yet another hardware project idea, while my last one is still at home waiting for proper firmware or a case to be developed >.>

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

https://www.unisonweb.org/docs/tour/scratch-files

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:

http://pchiusano.github.io/2013-05-22/future-of-software.html

"[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)?

#theWorkshop

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)

prof replied, and I quote:

pulled a 180 and proposed a different thesis project (the new topic is developoing mmmfs further). Let's hope prof is interested

i guess the other hand would include the battery pack for the SBC

my ergodox i put on top of each other bottom-to-bottom and into a little case, but i usually have to loosen at least one of the tenting feet so that they don't get in each other's way. Ideally it would also be quicker to unpack than that.

i like this aesthetically a lot but need to work out how this would make sense for transporting together with the other half

- using the excess of space to put an SBC into one of the hands

are there any medium-sized tablets that can be easily & reliably used as external monitors (with manageable delay, so hopefully without a userspace app on a mobile OS)

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

turns out the ever-popular Pioneer DJing equipment is basically stereo-only (which, being analog-ly interconnected, makes sense).

The CDJ digital-out might be able to output more than two channels, but that still means no automatically-tracked mixing...

Hello everyone!
I am exhibiting at the Maker Faire Rome this year and need to find a 2ch CRT Oscilloscope with X-Y mode that I could borrow.

Do you know anyone there that might have one, or any hacker-, makerspaces etc?
Help, ideas and re-toots very appreciated!

do we have a hashtag for job postings/search?
Or is that explicitly out of scope for merveilles.town?

cc @neauoire @somnius