A few years ago, on July 4th one of my mom's dogs freaked out, somehow managed to escape, and got hit by a car before my mom found her. She loved that dog, regularly attending nose work competitions with it.
One of your pets getting a seizure must be harrowing for both you and the dog.
When claude goes down a wrong path, I tend to clear context and write a new prompt that helps guide it down the correct path.
Whatever thinking or context that led it there has inertia and tends to be sticky, otherwise.
Pretty annoying when it brings those up again later from memory...
Exactly. How can "we" develop and encourage benchmarks for multi-turn user assistance?
That is what I want.
I feel like the models and harnesses push much too hard against this workflow -- that they push you towards letting go and vibe coding, with only your discipline (and desire for a quality and maintainable product) holding it back.
Yes. I think one of the big advantages of SoA is that you only pay for the fields you're currently using.
If you need a field somewhere, you can add it and only pay the cost of iterating it where you need it.
foot also offers a client/server architecture.
If you start a foot server (e.g. with a systemd service), you can use `footclient -N`.
This may reduce the memory pressure of running many terminals.
This is similar to the `kitty --singleinstance` mentioned in another comment by amarshall.
Yeah, for now.
I'd like it to be open, but I also want to potentially be able to make money/a living off of it.
My dream would be that it can be open while hardware vendors pay me to optimize for their hardware.
For how, being closed gives me more options. It's a lot easier to open in the future than to close, so it's just keeping options open.
I've thought a lot more about the engineering than any sort of marketing or businesses plan, so I just want to defer those.
I'm still working on it.
I'm currently working on a cache tile-size optimization algorithm that should (a) handle trees (a set of loops can be merged at some cache levels and split at others, e.g. in an MLP it may carry an output through the L3 cache, while doing sub-operations in the L2/L1/registers) (b) converge reasonably quickly so compile times are acceptable.
This is the last step before I move to code generation and then generating a ton of test cases/debugging.
My goal is some form of release by the end of the year.
I was once a bit of a Julia performance expert, but moved toward c++ for hobby projects even while still using Julia professionally.
I wrote a blog post at the time with exactly that punchline (not explicitly stated, but just look at the code!):
https://spmd.org/posts/multithreadedallocations/
The example was similar to a real production-critical hot path from work.
Maybe things changed since I left Julia, but that was December 2023, for years after this blog post.
In my experience, llms don't reason well about expected states, contracts, invariants, etc.
Partly because that don't have long term memory and are often forced to reason about code in isolation.
Maybe this means all invariants should go into AGENTS.md/CLAUDE.md files, or into doc strings so a new human reader will quickly understand assumptions.
Regardless, I think a habit of putting contracts to make pre- and post-conditions clear could help an AI reason about code.
Maybe instead of suggesting a patch to cover up a symptom, an AI may reason that a post-condition somewhere was violated, and will dig towards the root cause.
This applies just as well to asserts, too.
Contracts/asserts actually need to be added to tell a reader something.
I netted huge performance wins out of AVX512 on my Skylake-X chips all the time.
I'm excited about less downclocking and smarter throttling algorithms, but AVX512 was great even without them -- mostly just hampered by poor hardware availability, poor adoption in software, and some FUD.
I use niri and footclient -N, so builtin window and tab completion don't appeal to be.
Foot feels fast, but I've not actually measured the latency.
It also seems to use less CPU than GPU accelerated terminals (which it isn't) from just glancing at btop. So I'm not sold on GPU-acceleration as a feature unless I see benchmarks demonstrating the value in improved latency and reduced CPU use compared to foot
I love that foot's scrollback search, selection expansive, and copy can be entirely keyboard driven. Huge QoL feature for me that often seems neglected to me in other terminals.
I use kakoune, and don't understand why helix seems to be taking off while kakoune (which predated and inspired helix) remains niche.
Kakoune fully embraces the unix philosophy, even going so far as relying on OS (or terminal-multiplexer, e.g. kitty or tmux) for window management (via client/sever, so each kakoune instance can still share state like open buffers).
Sensible defaults and easy setup are a big deal. No one wants to fiddle with setting up their lsp and tree-sitter. There's probably more to their differences in popularity than just this, though.
Is including batteries the main reason helix seems to have started taking off, while kakoune hasn't?
I use kakoune, because I like the client/server architecture for managing multiple windows, which helix can't do. The less configuring I do the better, but I've hardly done any in the past year. It's nice to have the option.