Hardware Upgrades, Coding Challenges, and UXN Insights

Today brought some exciting developments, particularly concerning my MNT Reform. I received new, higher-capacity batteries (3200 mAh), which is fantastic. More importantly, these new batteries have resolved my persistent battery balance problem. I no longer have one battery overcharged while the others are drained, ensuring my computer won't unexpectedly shut down again. While I'm still awaiting the charger, the batteries seem to be working well, and I plan to balance them properly once it arrives next week.

My work on the Epoch library continued today. I successfully added an example using the aggregator, and it appears to be functioning as expected within the example environment. I then began the process of integrating it into Catacloud, which is its ultimate destination. However, this led me down a significant rabbit hole: I found myself back in Epoch, implementing transactions. I now realize this detour was due to my oversight in not having the Postgres state store implemented. My thought process was, "I might as well add transactions now and do it directly with transactions." This, however, was a misstep. Implementing transactions for the in-memory version of Epoch, if done properly, would be a substantial amount of work—far more than I initially anticipated. I'm considering dropping this specific transaction implementation for now and revisiting it at a later date.

The importance of transactions and atomic operations across multiple stores cannot be overstated. If I can implement transactions with both the event store (which could be Kafka) and the state store (perhaps Postgres or another solution), it would guarantee that events and state are saved atomically within the aggregate. Currently, my process involves first persisting events and then the state. This non-atomic approach creates a vulnerability: if state persistence fails, I have no way to roll back the already published events. This could lead to a situation where I have to rehydrate the aggregate or repeatedly attempt to save the state. If another operation then modifies that same state, it could result in a corrupted state. While the events themselves remain intact, allowing for state rehydration, it's far from ideal. An atomic operation would provide much greater consistency and reliability.

Beyond coding, I've been delving deeper into the UXN virtual machine. I came across a fascinating blog post (https://bullno1.com/blog/type-checking-with-symbolic-execution), bullno1 implemented a language server, a debugger, and other verification tooling for it. It was incredibly insightful, and I'm keen to explore it further. I believe I'll need to implement something similar within my own game. The intriguing question is whether I can achieve this directly with UXN. If so, it would be a significant breakthrough. My goal is to implement a virtual machine that can run on my development machine and also be embedded within the game. This would allow me to reuse the same software across my entire development stack, significantly accelerating the development process, as I could develop and test on my machine and then seamlessly integrate it into the game without needing separate in-game tooling.

Overall, that pretty much sums up my day. Despite accomplishing several tasks, I don't feel it was particularly productive, mainly because progress felt very slow. The event store work, in particular, has been a months-long endeavor, a very slow grind. I'm hopeful for a breakthrough soon so I can finally move past it.