Are you talking about the Volcano View? ("You are on the edge of a breath-taking view. Far below you is an active volcano, from which great gouts of molten lava come surging out, cascading back down into the depths. The glowing rock fills the farthest reaches of the cavern with a blood-red glare...")
Or did you and your friend also add the lava room? Or (this would be the really interesting case, family-tree-wise) was there already a lava room present in your version?
I can't immediately think of a lava obstacle in any version. (Well, the volcanic rift in GOET0580 and IIRC the very endgame of ROBE0665, in a sense. And the Volcano View is crossable in PLAT0550 and its descendants.)
Infocom's "Hitchhiker's Guide to the Galaxy" (1984) includes an object named "no tea", which is in your inventory for much of the game.
Yes, the Volcano View. We planned to add a new area just past it, but as I say we ran out of memory.
I've no idea where the version we started with would fall in the family tree, but this would have been ~1979, and the OS was HT-11, Heathkit's version of RT-11 for their H11 computer kit. So far as I know there was nothing special about it, except that it had been ported to RT-11 on the PDP-11.
That wasn't "leaking stack memory" except in a very literal sense: the BASIC language keeps a stack of the control structures you're inside, so that when you hit an "End" or "Else" statement it knows where to go next. This "stack" of control structures isn't lexically scoped; it's dynamic, based on what control flow commands you've hit. So yes, if you use "Goto" to set up a situation where you're hitting "Then" over and over without ever hitting a corresponding "Else" or "End", the control flow stack will just keep getting deeper and deeper. That's not a "leak" per se: all those "Then" structures are still there, waiting for their "End"s, and will do the natural thing if you give their "End"s to them — even somewhere someone used to lexically scoped languages wouldn't expect. Sometimes you can do cool things with this.
(I should add that the first image on that page shows one neat effect of non-lexicality: you can put an "Else" statement as the body of an "If", so that it's skipped when the "If"'s condition is false.)
Top comment on LWN is a very interesting read (although neither the commenter nor myself claim any such trickery was involved in this case).
> Trail of Bits were able to craft an input that beats Google's circuit and prove it... by virtue of a bug in the verifier: https://blog.trailofbits.com/2026/04/17/we-beat-googles-zero...
Google patched the vuln and the original proof still stands, but this is a pretty strange path we seem to be walking down [...]
That's the output you get from `git format-patch --stdout -1 dd28283`. The idea is that it's suitable for emailing to a mailing list for review (hence the subject line beginning with [PATCH], and so on).
If you ask for colorized output with `git format-patch --color=always --stdout -1 dd28283` you'll see that `git format-patch` itself knows which bits are the commit message and which bits are the diff. (Well, of course it does, I guess.)
I suspect that if you sent a patch like this to the mailing list, they'd get mad at you. So `git format-patch` is working OK for its intended use-case. Arguably it's GitHub causing the problem here by "misusing" `git format-patch` as a way to deliver patches that are (these days) expected to be machine-readable — something you can just curl and pipe into `patch`. `git format-patch` doesn't do that.
That said, yeah, it's amusing that (as TFA says)
git format-patch -1 HEAD --stdout > 0001 ;
git checkout HEAD~ ;
git am 0001
isn't a clean round-trip. `git am` applies the fake diff.
> If you think I can get you to patch inappropriate files by writing a fake diff into my commit message... wait until you see what I can do by writing those same changes into the real diff.
jolmg points out that if you use a GitHub URL ending in .diff instead of .patch, you get something much more suitable to feed mechanically into `patch`. (And probably not so exploitable.)
Therefore I retract my claim that this is even a "misuse" of `git format-patch` by GitHub. Seems like GitHub provides both a git-am-able endpoint and a (less exploitable) patch-able endpoint, and the issue is just that OP chose the less suitable one of those two endpoints.
The framing in terms of colors helps the reader to interpret the thought experiment in terms of "groups" or "teams" — as if there's a "blue team" that you can join by helping, and help by joining. Many readers will quickly [ https://en.wikipedia.org/wiki/Stroop_effect ] intuitively choose to join the blue team, and then rationalize their choice as a strategy to help their blue teammates.
But in fact the thought experiment doesn't say there are teams or groups at all! The reader imposes that part on their own, unconsciously at first, because of the description's emphasis on colors.
I predict that running the same Twitter poll with flipped colors — so that red means "I die, unless a majority of my fellows pick red" and blue means "I survive no matter what" — would yield a majority for blue too. What was previously justified as the "virtuous" choice (blue) would now be justified as the "only intelligent" choice (blue).
"Scapegoat-Driven Development" is right there! It would have fit OP's message better, too, in that the thing he's complaining about is maybe not worthy of the name "engineering" but is unquestionably some kind of "development."
But "waterfall" and "Agile" are such soft targets. I'd rather have seen a blog post with real war stories about real components/idioms/files/libraries from real codebases, not just another "methodologies" piece.
And is there an inverse problem, "scapegoat-driven stagnation," where we can't even think about addressing X,Y,Z until we have gotten rid of G (or finish the long-planned but as-yet-unstarted migration off of G)? That is, where G itself doesn't actually block these projects, but everyone uses G as a convenient excuse to postpone them anyway.
On the topic of scaling, reversible computations are more energy efficient than non-reversible ones, see also the OP. Outputting the original inputs might seem silly and wasteful superficially but if you discarded them (as "heat"), you'd just be back to building a non-reversible, likely much less efficient gate.
c is an actual input variable, it's not a constant. You can set it to be the constant 1 which the article does in one of the examples, but this isn't mandatory.
How do you mate with N+K? Surely your King can't give check, and if your Knight is giving check then the enemy king can just take a step toward it to get out of check.
Mentioned in TFA: This version of chess is given by Martin Gardner in his "Mathematical Games" column of July 1980 (pages 27 and 31) — https://www.jstor.org/stable/24966361 — and the analysis of White's mate is given in the column of August 1980 (page 18) — https://www.jstor.org/stable/24966383.
I do wonder how things would change if the board were 9 cells long; 10 cells long; etc. Also, it seems "in the spirit" to permit castling if neither K nor R has moved yet: i.e., from the position
K _ R N r _ n k
White ought to be permitted to
_ R K N r _ n k
(Or maybe there's a stronger argument for R K _ N r _ n k, actually. The former was conceptually "rook moves halfway toward king, then king moves to the other side of rook"; but the latter is "rook moves two steps in king's direction while king moves to the other side of rook.")
I'm pretty sure this wouldn't change the analysis on the 8-cell board at all, though. I wonder if it would change the analysis on any size of board.
Maybe I'm not good enough at chess to understand the strategy here, but how would castling be useful in this 1-D game? Castling in a normal game protects your King and activates the Rook. In this 1-D game, your King starts out protected behind the Rook. If you castle and end up in a _ R K N position, your king is exposed and your Rook is trapped behind the King, useless, with no way to ever get it back out. The Rook seems essential for mate, and its power has been eliminated.
Exactly. Feels like R K N would be a more suitable initial position in which castling would swap the king into safety, provided it has not moved and is not in check...
Though maybe in that case the best first move for both is to castle and we are non the wiser (back to the original starting position)
> It looks like white wins for n=6 and n=8 with perfect play, otherwise it is a draw.
For n=6 it's "1. N4 mate," right?
For n=7, "1. R5" is a stalemate; "1. R4 N4 2. N4 r4#" is a loss; "1. N4 n4 2. R2 r6 3. R3 r5 ..." is a draw by repetition; so yeah, it's a draw with best play.
Or did you and your friend also add the lava room? Or (this would be the really interesting case, family-tree-wise) was there already a lava room present in your version?
I can't immediately think of a lava obstacle in any version. (Well, the volcanic rift in GOET0580 and IIRC the very endgame of ROBE0665, in a sense. And the Volcano View is crossable in PLAT0550 and its descendants.)
Infocom's "Hitchhiker's Guide to the Galaxy" (1984) includes an object named "no tea", which is in your inventory for much of the game.
reply