I wrote a 2d esolang called asciidots inspired by ascii art and circuits, where “dots” follow ascii art paths and undergo operations. I posted it to Show HN a while back (2017!), where it ended up getting attention on HN and elsewhere.
Since then, I used Pyodide to make a home page with an interactive demo of the language. This let me use the existing Python reference implementation of asciidots in the browser, allowing exact feature parity (bugs and all) to support existing code. As a fun trick, I used a CSS animation for the logo instead of a GIF so it wouldn’t freeze while Pyodide is loading.
Nix is a package builder & manager that creates reproducible build environments. Using the Nix language, you specify what the build environment should look like ($PATH, what should be in the build folder, etc). Nix then calls a program of your choice to do the actual building.
Just like Nix lets you specify a build environment using the Nix language, NixOS lets you specify, using the Nix language, what you want your operating system to look like (systemd services, $PATH, etc).
You should be able to use Nix, the package builder & manager, on any POSIX system afaik.
> why am I expecting an error? Shouldn't that keyword be "on_exception" or something?
`expect` takes an input that is either an error or a value, then turns that input into just a value. The provided string is the error message if something goes wrong (i.e. the input was an error).
My understanding is that a terminal multiplexer consists of three parts:
1. Managing shells and windows
2. Parsing the ECMA-35/ECMA-48 escape/control sequences
3. Rendering the shells' parsed output within their window boundaries
> Can you share some resources etc on what could a good starting point if I want to explore this as a side-project?
My understanding is that i3 would intercept the keypress, not passing it onto the terminal. While I want 3mux to work with i3, I decided to choose defaults that appeal to the audience that would need 3mux most (i.e. non-i3 users). I plan to soon make the key bindings configurable.
The biggest thing stored by 3mux should be the state of the terminal screen, so memory usage should be negligible.
> Can you (easily) nest 3mux like tmux with (auto-)grouped sessions to produce a (max) 9x9 "grid" of windows to organize your remote hosts, and their windows into an easily accessible structure. (I use this to be able to reach any window in any other terminal window on any host with max 4 keypresses)
This is an awfully specific request. However, I plan to soon add support for workspaces, which should give the user access to, for example, 40 panes within 2 keypresses, given a hypothetical 10 workspaces and 4 panes per workspace.
> Why choose Go? Just curious.
Good question! I chose Go for its go routines and channels. I somewhat wish I used Rust simply because of its elegance. 3mux's performance bottleneck right now is completely IO, so I don't think moving to Rust would make a noticeable difference to the end user apart from the installation process.
I'm a long-time user of i3 (now sway). I wrote this tool to provide the elegance of i3 to terminal users everywhere, especially for people like myself who sometimes use a non-i3 wm or no window manager at all (e.g. when testing code on a bare-bones raspberry pi).
Since then, I used Pyodide to make a home page with an interactive demo of the language. This let me use the existing Python reference implementation of asciidots in the browser, allowing exact feature parity (bugs and all) to support existing code. As a fun trick, I used a CSS animation for the logo instead of a GIF so it wouldn’t freeze while Pyodide is loading.