2026-05-15

I've made some changes to wom. One of the largest one was getting rid of passing arguments when spawning a process. With arguments, we had two ways to pass data when starting a process: through the arguments or through files. I realized that we always want to use files. Without the program reading its state from its files, we have no way (simple) way to restore it when the OS is saved as a quine. A non-simple way I experimented with a bit was to save the arguments in a `prog` file, to be replayed on reboot. But then the argument file had to be kept in sync. And, if we have to use an argument file... we might as well just use files. So files always win.

I've updated the spawn syntax to allow passing initial data for files, which basically give keyword argument for free, without even needing arguments at all. So to spawn a directory at a path, we can just do `dir path=/foo/bar`.

All of this made me realize that processes are a lot like actors. They are responsible for their own work. But instead of exposing a single inbox, they expose files that the outside world can write to or read from.

I added a `ERR!` clickable label on the window when the process it runs has an error. Clicking on it will open the proc's err file. That file is never wiped. If you want to discard that error, you can erase it. Since wom is browser-based, the main goal of errors is to indicate that something failed. The browser's dev tool is the debugger you'd then want to use.

dir, the file browser program, will select the program to open based on the extension. Here's how it works: if you click on `myfile.foo`, dir will aim to find a `foo` program (in /bin) and will start it with a path file that will take the value of the file you just opened.

I changed other things as well, such as `bat`, the program runner. I'll talk about one another time!

2026-04-04

I've just written a little more about wom on this page. I am now happy with the abstractions. I've also been thinking about a little language to start processes and connect files together. That way, a spreadsheet program can connect to a charting program, and the chart can update as soon as a selection is made. More on that soon!

2026-03-31

I cleaned the files exposed by a process down to: `ctl`, `wctl` and `label`. The ctl files (ctl and wctl) take in commands and act as pipes: you write to it, the text is consumed. ctl are commands for the process. wctl takes commands to manage the window attached to the process. At first I had a `rect` file, changing the file would update the window's coordinates. But using a ctl file lets me do validation, check ranges etc. For example, to move a window to position 10x10, we can do `fs.write('/proc/pid/wctl', 'size 10 10')`. I've also added a `/opt/start` file where we can list what goes to the global right-click menu

2026-03-28

I got a new coffee machine, and it's really good! On wom, I realized that I was conflating commands and state when it comes to IPC. For example, a process folder would expose an observable `dirty` file. Removing its content would trigger a save and update the UI of a window to remove the '*'' next to the name. But what if the save operation fails? What if the program was opened without a path? I could work around that by introducing a little state machine in the `dirty` file: '!' could mean "i request a save" and "*" could mean the file is dirty. But if each file in the process have to expose a mini state machine, the complexity skyrockets. Instead, I went down the Plan9 route: process that will take commands expose a `ctl` file. That file acts as a pipe: what you write in it gets consumed. That's how the outside world communicates with the process. Write `save` in it and the process will trigger a save. Since the content of the observable gets emptied after each message, we can send the same command twice. When we read that file, we see the content of the internal states of the process with key values. I could do that by 1/ creating a ctl file and saving its original data observable's set function and 2/ replacing the file's data set by a new one that just checks the command and take actions 3/ update the original data when any state change.

2026-03-25

I did some preliminary work on the directory structure of the filesystem for wom. The OS is single user, which simplifies things a lot. I'm using /tmp to store current Prompt windows return values. Since a file is an observable I can just listen to any changes to it and trigger a callback accordingly. I've added a Confirm program too, as well as a `dirty` file within a proc/{id} directory. When attempting to close a process that has a non-empty dirty file, a Confirm window appears to ask for confirmation. The fact that `dirty` is a file allows programs from the outside to trigger a save as well. For now, that's how I plan to manage IPC.

2026-03-23