✍ The proof is in the meta-tracing JIT interpreter

The one where I implement a native JIT interpreter for my minimal oop language using pypy's meta-tracing compiler toolchain

Hi @Naveen Michaud-Agrawal I understand you've been collaborating with Folk Computer? And a quick search reveals that you may not have told us all about it here! If both are true - over to you! (Else I'll delete this post before I get embarrassed 😳 )

Been a while since I touched it but I've been building a toy postfix stack-based language to inflict upon my kids. My theory is:

• postfix may have benefits for early teaching (linear evaluation order, lack of "syntax", trivial notional machine)
• the obvious drawbacks can be somewhat mitigated if instead of destructively changing the stack, you can navigate all previous stack states. (I'm not the first to try the latter; in particular Kartik did it in Mu, including descending into function calls. I don't even have user-defined functions yet.)
• I wanted to explore "replacing" some uses of control structures with composition of a bigger data type, like a whole picture or animation.

I'm resigned to the thing not being turing-complete.

Initial implementation's data type was 1D "animation" of color change (I wanted them to program an RGB lamp): asciinema.org/a/zObMq9ZLJQNA99X3EhdEDllhA

=> My kids liked typing and mixing colors, but the idea of a single value representing change over time went entirely over their heads 😞

Anyway terminal REPL was a dead end, because you can't go back and edit past code. => I got a prototype web editor — you can move cursor, edit freely, and see stack state before each word: animation-stack-language.netlify.app

TODO: rendering still uses styled block characters 🧑‍💻, I need to learn canvas...

TODO: Next big step will be to replace the data type from 1D "time" to 2D "picture", taking inspiration from forthsalon.appspot.com and code.world .

I'm thinking to make do with some 2D rather than RGB colorspace, so that every pixel can also be interpreted as a vector. That way any picture doubles as a limited representation of function-as-data (not turing-complete! but very visual 🤔).

Hash reference to every function and limiting effects at the top level to allow code to execute even after a failure. This is a bit longer as I try to explain in more detail what these features are in EYG vimeo.com/973314611?share=copy

I made a blog post about visualizing risk. calcwithdec.dev/posts/viz-risk

It's a scrollable explanation that develops up a visualization - a bit going on in it, a problem I have with a lot of things, so was really glad to spend time learning a few things about making this kind of scrollable interaction to more carefully introduce things.

Behind the scenes, the numbers are from a calculang model doing monte carlo simulations on a pension calculator calculang model. This composability (or what I call flexibility) is something I decided not to make this post about, but it's an important part of why calculang exists.

I plan to do a few similar separate exercises, and then spin back to this on it's own. (e.g. next: benchmarking actual results to their older estimates)

So, this blog post isn't really technical, but I hope it's interesting or at least easy to follow, and it fits into a longer piece about calculang. Happy if you have any feedback about the post or questions about this longer piece!

Making more progress on AI assisted visual programming (with voice control).

linkedin.com/feed/update/urn:li:activity:7214151556164640769

I've been building a sync framework that app developers can integrate, to securely sync state changes between clients. I call it DIPLOMATIC, after the concept of a diplomatic bag which travels through foreign territories, but protected against inspection. So far I've got a couple host implementations targeting Deno and Cloudflare (Workers + Durable Objects + D1), as well as client libraries to build web clients in React and CLI tools in Deno.

The attached video shows off a demo app that displays and updates a consistent status message across clients. It generates and stores a cryptographic seed (synced via the browser's password manager), queues status changes when offline or not connected to a host, then pushes queued changes when connected, and receives real-time updates using WebSockets.

I've got some rough docs up at diplomatic-docs.replit.app, and a walkthrough of the demo app from the video at diplomatic-docs.replit.app/docs/demos/status.html.

The backstory is that, for a while I've wanted to build a grand life-planning app, like a TODO list that can operate at the decade-level rather than the daily-level. But I kept running into these blocks:

a) I'll want to access it from phone and desktop, so it needs a sync solution,

b) maintaining servers is a pain, and

c) a life-planning tool will necessarily have personal info, so it shouldn't hang out in plaintext on someone else's computers.

These sorts of issues aren't unique to this tool. In fact, I think they're common enough to merit a general solution. The Web 2.0 client/server model gave us easy software updates and access from multiple devices with consistent data. But we backslid by making all app data visible to the software provider and relying on them to maintain their servers. Mobile apps gave us the additional expectation that we could access our data while offline.

I think there's a simple solution to get the best of all worlds, by encoding app state changes as objects (the Event Sourcing pattern), then encrypting those deltas and shipping them off to a server which relays to other clients, which then decrypt and apply the changes locally. With this architecture, the relay servers all have a standard interface (not application-specific), and they're blind to delta contents, so hosting becomes a commodity. This means companies could specialize in just running these hosts, giving application developers a secure backend without the maintenance burden. It also creates a standardized import/export format for app state—the delta log, so you get a backup format for free.

I'm only designing around single-user apps at the moment. Having a "last-wins" policy for conflicts makes things nice and simple..

If anyone knows of related work I should check out, has suggestions, wants to collaborate, ... let me know. The code is still a bit messy, but I'm planning to tidy that up and open the repo soon.

i wrote up my experience of slowly discovering the live coding world, and how my Arroost tool fits into it, and the motivations for my work

todepond.com/wikiblogarden/scrappy-fiddles/sharing/normalising/live

Hello everyone! I have just finished a set of tools I built while learning about the Hack computer architecture. Today I felt confident that I could share all the code I wrote for this

github.com/Warkanlock/hack-tooling

To me, this architecture was a great starting point if you want to get a hang of how computers, compilers, and virtual machines actually work