adaptit

I've solved most of my problems by following these guidelines: one worktree for each code domain, using git sparse-checkout to limit the context (e.g. one worktree for the Rust core, one for Swift macOS, one for Swift iOS, etc.), and putting all the rules in claude.md (or agents.md). This way I get "containerization", lower context, and faster search across the codebase. After that, I only install the skills that actually matter for the context.

Maybe it's just conservation of angular momentum: if you look closely, you can see that the spin axis and the way she applies the force aren't perfectly tangential to the object's axis, so the lower point of the T-shape is "bouncing" between many positions. If I'm not mistaken, this is explained by the "intermediate axis theorem".

Ah ok, the lazy construction part is what I was missing, if you basically never build the full key, there's nothing to cache. Makes sense now why the LRU didn't help. I'll think about it over the nextdays.

Probably a naive question, but: couldn't you precompute some vector representation of the string once, and reduce collation to a vector comparison? Basically move the cost upfront and get back to the "fast" byte-comparison case?

Is this an astronomical math calculation done in real time, or do you pre-compute all possible paths? I'm interested in the math behind it.

Emacs is powerful, but the complexity overhead of managing a custom trust layer could easily become a major maintenance bottleneck for average users. Worth considering, but the friction point is significant.

This interval calculator is surprisingly robust. The way it handles boundary conditions and asymmetric intervals is clean and efficient.

Always cool to see these kinds of retro computing resources pop up.

This resource is a really clear breakdown of order relations; visualizing the structure like this makes the abstract concepts much more digestible