~jakintosh/programming

/pages

Programming

There is nothing here yet.

/programming Stream

December 6, 2023

/stream /programming /december-adventure

Today's work was thinking work. Part of my goal of putting the /coalescent computer on pause was to start framing coalescent data within existing computing systems instead of a blank slate, and so I wanted this project to reflect that. Today I was thinking about how I would manage the different "resources" (accounts, entries, reports) in a coalescent way, and I think I came up with a plan to achieve that.

Each "agent" (user/node pair) will have its own event log, and each log can only be edited by its owner. A log is just a text file where each line describes some (CRUD) event on a resource. The logs can freely be synced with other agents, and each agent can keep track of how long it thinks each log is so that they know when there are new events to process in a given log. If my state tells me that agent1.log is 40 lines long, but my local copy is now 42 lines long, that means two events have come in for that log since the last time I processed events.

Effectively, this means the CLI will have some commands that write to the local agent's event log, an event log resolver that generates and modifies resources based on all of the event logs as a single logical unit, and then report generating commands that work from the local resources. There can be a little bit of state on an agent that helps it track and cache what it's already computed, but it can also at any point just re-run through all of the event logs again to rebuild the current state. Playing back events means it will also be possible to catch instances where new events are trying to write to "closed" books.

This sounds complicated when writing it all down, but I think with a little more planning it should be possible for this to be implemented pretty quickly (minus syncing, which will just be done with rsync).

December 5, 2023

/stream /programming /hare /december-adventure

Another short December Adventure session today, but I implemented some functionality for creating and listing accounts within a project. For now, this is done by adding files to an 'accounts' directory inside the project, and having each account file be the stringified version of an account struct. I should probably put together some kind of de/serializing functions that make it easier to re-ingest the text file back into program data later on, and also clean up the way I'm creating "resources" since I'll need to do a lot more of that. Honestly, if I have more than a few minutes to work on this tomorrow I should take a step back and do a bit more planning now that I have all of this infrastructure working.

December 4, 2023

/stream /programming /hare /december-adventure

I only had about twenty minutes for my December Adventure today, but managed to implement the books list command using the config work from yesterday. I also refactored those config functions to work as a general key-value store, which made it very easy to then also implement books set project to set the active project. Overall, the work I did yesterday made it so that implementing these other commands was pretty straightforward. I need to come back to this a bit later and think through the error handling a bit better, because for now it just unwraps all the errors with !.

						
$ ./books list
spiral-house
home
					
$ ./books set project home
ok
						
					

December 3, 2023

/stream /programming /hare /december-adventure

Had a pretty packed day, but found a few moments to tinker. Spent most of today's time starting to learn about the fs, io, and os modules of the standard library. Wrote a few functions for reading and writing files, and now the CLI for books lets you set a directory where it looks for your projects by default. Trying to lean on the filesystem to do all of the work in this project, so this "setting" is just a file $XDG_CONFIG_HOME/books/root that contains the path.

						
$ ./books set root ~/books
ok
					
$ cat ~/.config/books/root
/home/jak/books
						
					

December 2, 2023

/stream /programming /hare /december-adventure

Today's work on the December Adventure was more fleshing out of the command tree as I was thinking about the different types of resources that need to be created and managed. Things like accounts, journal entries, and so on. Fleshing out the tree has been a good test of my cli module, and is also a good way to think through the use of the program as a set of resources being managed.

I also needed to figure out a way to have the user set an active project and let the program know where to find project directories, and this led me to learn about the XDG Base Directory Specification, which is what defines the ~/.local, ~/.config, and ~/.cache directories, and what types of files should go in each. I learned something new, and also figured out how I should handle the default storage of configuration and state data for this program.

December 1, 2023

/stream /programming /hare /december-adventure

I've been cutting my teeth on /hare for a few weeks now, and yesterday I finally got my "learning project" (a CLI argument parsing module) finished. So today, I started work on a CLI double-entry bookkeeping program which I think is going to be my December Adventure for 2023.

Today's work was fleshing out a command tree using my new argument parsing module, and then learning about how the Hare compiler uses multiple source files. I can now compile a binary that executes a few placeholder subcommands.

November 14, 2023

/stream /technology /programming /hare

Over the past few days, I've been starting to get acquainted with the Hare programming language. Someone on Merveilles mentioned something about it, and after looking it up something really clicked about it for me. I'd been really starting to sour a bit on Rust, especially the complexity of the ecosystem, and was thinking that I should start to learn 'C'. So finding the Hare language, which is an opinionated 'C' replacement whose opinions heavily match my own, has been a joy.

From what I can tell so far, the core idea behind Hare is that "Understandability of the Toolchain" should be the highest goal. You can bootstrap the compiler with gcc in about 30 seconds, with about 30k lines of source code. That's faster than building most simple Rust binaries with an empty cache. In terms of language features, it is focused on proven ideas implemented well, and consistency over syntactic sugar. As an example of its philosophy, its implementation of tagged unions turn a very basic type system into something that punches way above its weight class in terms of capabilities and program correctness. It makes a big leap from something like C towards something like Rust, but with an order of magnitude less complexity.

So far, the only things close to a "dealbreaker" is the limited editor integrations, like in-editor compiler warnings, and autocomplete/autoformatting. Perhaps I can try my hand at an LSP implementation...

September 2, 2023

/stream /colophon /programming /linux

After spending a few hours this week trying to build a CLI that replaces my jnl shell-alias tool and allowed it to publish my website, I spent a few more hours today really thinking about the difference between a shell script and a program binary, and if I wasn't creating unecessary complications. This project of porting a shell script to a Rust binary taught me a lot of things about the nature of the shell as a computing environment, and pushed me to try to keep these tools as shell scripts for now.

I ultimately don't feel like the scripts I have now are the best version of this tool, but I also don't think that the compiled binary I was building was any better... and it was going to take an order of magnitude longer. I'm going to sit in the discomfort of these unfinished tools for a while as I continue to shape the /coalescent computer environment, and at least enjoy the fact that it's much faster to add entries to my website logs now.

July 10, 2023

/stream /technology /programming

A few days ago I watched this video about the performance differences between stack machine VMs and register machine VMs (when running on a physical register machine). The takeaway was that due to pipelining, a stack machine VM runs slower since it is always reusing the top of the stack, and none of the work can be done in parallel. For example, the equation ( 1 + 2 ) * ( 3 + 4 ) on a stack machine could be 1 2 + 3 4 + *, but all 7 instructions have to be run sequentially; on a register machine ( 1 + 2 ) and ( 3 + 4 ) can be decoded and prepped at the same time, since there is no dependency on those calculations (only the '*' must wait).

This, for some reason, made something click about Interaction Nets, in a way that didn't resonate with me the first time I started reading about them. It might have just been because lambda-calculus feels so opaque to me and I didn't have a good visual model in my head, and that this concept of dependencies in calculations gave me that visual. From there, I revisited HVM's github and Devine's interaction net page (linked above), and found myself thinking about rewriting rules again too.

Either way, this all got me thinking about how you might be able to declare "dependencies" for calculations in a stack machine. Could you maybe "branch" a stack into parallel computations with different memory addresses? Could you use that for SIMD operations? Would this be a great way to increase real world performance, or would it make writing code unecessarily complex? Am I just reinventing an obvious idea from a part of computer science that I don't know about?

July 2, 2023

/stream /technology /programming /collect

Spent a good chunk of time today revamping a community website to add a blog, and part of that meant figuring out how to implement a "dynamic root path" for URLs. I had to make some changes to 'collect' for it to work, but I think it's more robust now: it should more fully be able to recurse through contexts looking for objects of a certain name (which in this case is the "root-override").

Adding this feature has made me feel a little bad about 'collect', since with only four months having passed it feels quite sloppy and difficult to reason about the source code. It's definitely not worth rewriting again any time soon, but it's worth keeping in mind as my web projects that rely on it continue to grow.

May 30, 2023

/stream /reading /merveilles /programming

I read Situated Software, by Clay Shirky which seemed to be bubbling up in conversation around Merveilles today. It elaborated on some of the ideas I've been playing with lately, specifically around offloading the social aspect of computing networks to the humans in the loop instead of strict algorithms. This note on payment in small scale networks was particularly in line with that:

The possibility of being shamed in front of the community became part of the application design, even though the community and the putative shame were outside the framework of the application itself.

May 24, 2023

/stream /technology /programming /collect /colophon

As I started fleshing out components of this site, I wanted to add some new features to /collect. I added the ability to reuse the name of a @map as a value using "$NAME", and it can also be interpolated in strings with "@name". I also exposed a list of the @group objects on a @map using the value "@groups" on a @map. The first change reduced redundancies when writing new stream events, and the second made it possible to render all of the groups for each stream event.

May 23, 2023

/stream /technology /programming /colophon

Built out the rough framework for this website, settling on the complimentary "garden" and "stream" metaphors.

Start