After numerous minor edits and optimisations, I got feedback from a shipwright that it did not work on windows; I thought this was an omission in pyproject on my part, but it simply turned out that windows was simply non-unix and was thus not compatible with some of the libraries. Unfortunately, it seems that compatability substitutions are quite complicated, and so I added a line about compatability in my readme.

I started working on the PCB! I had previously tried out kicad as part of a mini keyboard project, but it turned out rather difficult to work with, and for some reason alignment wasn’t working at the time, so I gave up. But this time, alignment seemed to just work, components aligned to a shared global grid, and so it worked out overall. I’m quite happy with how it turned out; nothing crazy, with the addition of only an LED, but hopefully it should be functional!

I made various minor edits, from error handling of edge cases (e.g. tiny terminal with huge rendering config) and optimised mouse input, then reformatted the project for pypi upload. And then I uploaded it!

I decided to call the project spume (plume was already taken by someone else :<), but I would love to hear some other nice names. Does anyone have any good ideas?

I worked on README.md and added CLI flag argparse, adding flags for sim dimensions, physics config such as maxiter and rtol, grid spacing, time speed, and viscosity, among others.

I continued working on it; just a single spawn point with no interesting interaction made it seem like a rather generic, almost repetitive sim. So I added WASD to move the spawn point around, then I added click-to-disrupt mechanics to introduce some more interesting, unpredictable, visually interesting patterns.
It took multiple iterations of various input-handling systems to settle on a final, simple but (mostly) reliable input system that should be fairly easy to extend in the future without using external libraries.

README upgrades
As below; I added a feature section! And a contributing section, though I do doubt anyone will contribute to this.

More bug fixes! The plugin worked, but after sleep / time elapsed / new sessions / something else along those lines, it kind of just stopped working for some reason. Spent a long time working out why, and to be honest I’m still not completely confident. But to the best of my testing, it works consistently now.

Every felt slightly down after a terminal error? Python bug, command not found? Fear not, fahhh.zsh is here to inject some motivational humour into your terminal! Enjoy an encouraging sound effect with every stderr output, and let the vibes flow through your anger! And with a wide range of sound effects, randomly chosen each time, you’ll never get bored! Just don’t turn the sound up too loud :D.
A good, short and sweet project; I think it’s quite effective. Enjoy!

I had planned to submit this for macondo, so unfortunately I’m really behind on devlogs. So below is a recap of a few things.

I first read up on fluid simulators, about implementations like stable fluids, or more particle-based versions. I got a basic skeleton (diffuse, advect, project) and made sure I understood most of the logic.

I then wrote up the advection logic. This took an unfortunate amount of time; I started with a basic manual implementation, but then with some review from DS V4, it was suggested I implement a multigrid logic for performance, so I followed some guides (and advice from V4) to implement it.

I then worked on the diffusion script (I’m separating all parts into different scripts for max clean-ness :D). It wasn’t so bad, but I had to do a bit of research, read up on conjugate gradient solvers, but with some help it was fine.

Projection was a pain; seemingly it affected border conditions, and had to be done multiple times, or could be optimised or something, but it seems to almost work. (Still diverges? I’m not sure.) Ahhh, but the output logs still show significant issues. One day it’ll work.

I then used matplotlib to make a changing visualisation. I would like for it to be a TUI visualisation (with braille?), but for now it works.

After a long break (school international tours, and other stuff), I continued, first by converting the matplotlib visualisation into a TUI ascii-gradient-based terminal text visualisation, using ansi codes for alternate buffers and overwrite to efficiently create the TUI.

That’s a really short recap of my progress; there seem to be a lot of physics accuracy issues, performance optimisations, stuff to learn about numpy vectorisation, etc. But it’s already really cool to watch the visualisation! And the ascii turned out really nice.

More errors; my shipwright ran the project from system home (something I hadn’t anticipated; I was expecting it to be a repo-level tool), and so the tool took ages gobbling up his configs and binaries, much of which it couldn’t read. So now I’ve made it so context is not default on; one must pass –context flag for it to activate (otherwise we’ll have too many llms getting gigabytes of random stuff!). Hope this helps.

The ship came back with an error — I don’t have slack notifications and I found out weeks late! — and I scrambled to fix it.

Turns out there was a subtle f-string syntax nuance that python flags as an error in pre-3.12 versions, but is accepted in post-3.12 versions, and so my 3.14 venv accepted it, while maybe the shipwright’s didn’t. I fixed the formatting, but pushed min version up to 3.12 just to be safe (I feel like 3.12 is a very stable version, shouldn’t be too aggressive a version).

And then when I was testing I found out that multi-model flag inputs didn’t work for some reason! So I fixed that, which was surprisingly easy.

Then a few checks, updates, and pushes later, and I was done!

You can now use endpoints apart from opencode zen and custom models, defined with cli flags!

You can now get a result back in under 5 seconds with diffusion gemma on nvidia nim!

I uploaded it to pypi!

Everytime I try to upload to pypi, I always forget the format (src/…) and the commands with twine and build, but I’m getting there. I keep making minor errors (e.g. local imports can be absolute, but packaged version must use relative), and so I’m already up to 0.1.2 (two more updates to get it to a working state).

You can not install with pip install amalgam-panel! (Amalgam was taken already by a wrapper :<)

Added conversation / follow-up questions! The cli saves past prompts and responses, attaching to new messages as context, and allows for a more chat-interface style interaction.

I ran into lots of trouble with the ordering of messages and context structuring, but in the end it seems to work fine. Hope it’s a good change!

Added a context summarisation flag! You can now pass in –summarise-context for it to query free llms and summarise large repositories (any text-based files), saving tokens before the panel starts its work. Hopefully helpful for larger, unfeasibly large codebases, though rather dependent on the context-summarisation model (currently big-pickle, seemingly the most reliably-always-free model with respectable and reliable performance, with little errors or json issues).

While I was finishing up my Trisolaris project, along with polishing calculations for a fluid simulation project, I found myself asking multiple llms to check for errors or potential issues. This resulted in up to seven opencode instances in separate windows, and after getting their responses, I would then pass them to a reliable llm I trusted — often mimo v2.5 — to merge into a single cross-referenced response. While this was great, helping me to catch potential edge cases or give me some general advice on potential improvements, it was very messy and time-costly, and for my rather humble laptop, performance-draining. And so I thought I would use the opencode zen api and make a python tool to automate the process!

Amalgam is a python cli that accepts a variety of flags (to customise every aspect of it, from temperatures, number of responses, to timeout, and other parameters) and a prompt, presenting prompt and context to a ‘panel’ of llms (quite literally every free model available on the zen api, auto-detected with key validation), collecting numerous responses to be merged into a single unified, comprehensive response. This maintains the advantage of having multiple llms with different strengths, while keeping it overall time-efficient by automating many of the cross copy-pasting required normally, along with presenting all context (though this may be token-costly for larger repos, this could be improved in the future).

I’m quite happy with what I’ve got. It’s been a short project so far, but for my purposes, it’s practically done. I will work on it, potentially adding follow-up question features and context summarisation for larger repos, but it largely fulfills its purpose!

The below two screenshots show the before and after, from multi-window clusters to a singular, clean and unified report.

If anyone has suggestions or feature ideas, I would love to implement them! I feel like this is a perhaps common idea, but I haven’t find a solution for my needs (completely free auto-discovered model panel, with customisability yet simplicity); hope you like it!