pjz

I'd appreciate a 'shuffle' button that just re-mixed-up the letters into a different order. I find this keeps me from obsessing on adjacent letter pairs that my eyes/brain lock onto.

on a linux box try `man ascii`

uhhh... that's mostly on your browser. The css is at the top and pretty skimpy. If it really bothers you, find a styler extension that will override the CSS to render it more pleasingly.

This seems like it could be an rdf query tool, though offhand I don't know the ref to the right rdf schema.

>having to eff around with the crap show of Ruby/Python/Node envs and how every person likes to use different tools for setting those up

This was the problem I wanted to solve, and I ended up on nix+direnv (and am considering devenv) because nix, due to the existence of nixos, packages all the tools already! Does Mise support zig? or nim? or crystal? Nix does! And Nix will continue to keep up to date with all the tools, whereas things like asdf and mise - since they're specialized and not the basis of a full distro - are less likely to do so.

The practical problem with logging by time is that it's not resource constrained: holding N seconds of logs, even when each line is a bounded size, takes potentially unlimited memory. Logging 'by count' used a bounded amount of memory, and is easy to implement with a fixed size array in memory.

The problem with the 'characters are just numbers' approach is that they're not _just_ numbers.. with the advent of unicode, they're _sequences of numbers_... so bytes thus can mean different things when part of a a sequence than when standalone.

That said, since they're numbers, we should use the most efficient checks for them... which are likely vectorized SIMD assembly instructions particular to your hardware. And which I've seen no one mention.

My first thought was that a library was writing fake books to poison LLMs that were using their corpus without their permission, and that someone had developed a tool to identify such books.

>The logical endgame of that approach is to have a big tug-of-war between two big coalitions

...why just two? He specifically mentioned advocating for ranked choice voting, which would make it a tug-of-war between N coalitions, and would lead to better outcomes that our current broken two-party system.

Crashing due to lack of a sufficient terminfo is indeed more of a lazydocker problem than a ghostty problem. See the issue above for a workaround.

This is an off-by-one interpretation of the zero-one-infinity rule :)

> And why 32 entries? I ran this benchmark with a bunch of different bucket sizes and 32 worked well. I have no idea why that worked out to be the best.

If you were using 2-byte ints, this is likely because cache lines are 64 bytes, so 32 entries would be exactly one cache line, letting each cache line hold an entire bucket, thus reducing those expensive main memory transfers.

I was just wondering what the author's opinion of Zig's take on C-interop would be.