quuxplusone

The hex grid (rather than, say, square, or random Voronoi regions). The fact that some hexes have 1 voter and some have zero (rather than, say, all hexes having 1 voter, or any having more than 1). The circular colored dot indicating the voter's party (rather than, say, a picture of a horse, or tinting the entire hex). The "Hint", "Reset", and "Submit"/"Call election" buttons below the grid, in that specific order; and (I assume) the nature of the hints. The "health bar" graphic depicting the number of horse voters and donkey voters.

The point of choosing Kevin Bacon in the first place was that "Kevin Bacon" sounds roughly like "separation," so the reference works. AFAIK there was no additional criterion.

> The C++ container classes assume noexcept constructors for this reason, because creating a list of size 20 calls your constructor 20 times, and the cleanup gets so much messier.

No, STL containers such as std::vector definitely do not assume (nor require) non-throwing constructors. They just do the right thing. Yes, cleanup is messier than it would otherwise be.

STL containers do require that your destructors not throw (but do not require that they be noexcept).

I have no special information, but it could just be Amdahl's Law. If one guy (or bot) checked in 5GB of binaries before you thought to enable git-lfs, then that's not a 100/25 ratio, it's a 95/20 ratio. And if it was 10GB, that's a 90/15 ratio, and so on. IIUC, the old un-LFS'ed binaries remain in the history unless you actively `git lfs migrate` and rewrite your whole history, which they might not want (or care enough) to do.

Yes, that's a good (and shorter) way to put my complaint. :)

For all I know, perhaps this even was guarded by such a link, but because I got to it through HN, I would have missed the warning.

FWIW, I wish you'd spent a few minutes cleaning up the first dozen pages of Claudespeak. You have some human text at the bottom of the post, but first you force your readers to wade through (or skim, or just close the tab) stuff like "Solver experiments show the bare rule is loose" — "is a chore with the shape of a puzzle:" — "test candidate mechanics on thousands of random gardens with an exact solver, a constraint-programming optimizer, and a deductive difficulty grader" — "the only U-turn-free raking among 12 par rakings of 6,310,226. Ripple stones and wave bands, the obvious “pattern” constraints, add texture but not tightness" — ...

You do see how that's all garbage, right? So why not just delete it? Keep the good part, delete the bad part.

The game widget itself takes up 3 pages on mobile, because of all the Claude web design.

... Wait, as I scroll down again in composing this complaint, I realize I'm wrong about there being any human text at all. It's all garbage. This makes me kind of sad for the Gwern we've lost.

> I'd be very surprised to learn that GHS had ever developed their own frontend.

Actually I take that back. At the dawn of time (1982), GHS definitely had its own frontend. They switched to EDG sometime before my time. I meant I'd be surprised to learn they'd switched from EDG to something home-grown.

This also meant that in my time there was a hefty "glue" layer between the EDG frontend and the GHS middle-end (the middle-end being the tree transformations and "indep" optimizations before you got into the back-end stuff): you had to take the structures EDG produced and turn them into the structures the GHS middle-end wanted.

I was there right when John Regehr's Csmith was first making big waves. We started using it, and also rolled our own fuzzer with more focus on embedded-software trouble spots, such as `volatile` and `packed` and I forget what else. (Guy Goldstein originated and led this, as I recall.) I don't actually remember the fuzzer finding a lot of crashes, but maybe it did, and I do remember its finding a lot of miscompilations, i.e., bad optimizations.

In my day (2006–2011) Green Hills used EDG's frontend. I have the vague impression they might have already switched away. (I know Intel ICC already switched to Clang a while ago.) I'd be very surprised to learn that GHS had ever developed their own frontend.