You've replied while I was editing, so see that regarding what I mean by side effects.

As far as throwing an error when you try to create "31st February", this wouldn't actually help much, since the error would still only occur on some days of the year, because your original code doesn't account for the range of outputs from Date() when called without arguments.

To perform correctly, your code needs to normalise the day of the month, or just create the date more explicitly to begin with, but this is a calendrical issue, not a JavaScript one.

If you had a book which had on its Contents page:

Chapter 1 . . . . . . . . . . page 1

and you crossed it out, then wrote:

Chapter 1 . . . . . . . . . . page 1

Chapter 2 . . . . . . . . . . page 50

someone looking for Chapter 1 is still going to find all the text in the right place (as long as it was less than 50 pages).

Changing the partitition table is like changing the Contents page; it doesn't mess with the rest of the data. And if the new table points to the same place it did before, the data can still be found.

That said, if the filesystem still thinks it's 1TB, you may end up with future problems unless you resize it to fit the reduced partition.

If it ain't broke…

You have regular backups already. Unless you want to add fault tolerance with something like RAID, I don't see why you need to buy anything right now.

I think the assumption is not that adblockers alter the user agent info, but that they also block other resources, so StatCounter won't see those users at all, leading to under-reporting.

Which sampling bias do you think will be ignored by the RETVRN types?

• Worse movies are less likely to survive and be distributed.
• Only 'classics' will overcome a preference for watching newer movies.

The end of "Cogenitor", where Archer blames Trip for the death of Charles.

I don't see them in the app, so not yet, I guess.

Uh, the XiBucks, obviously.

Look, I get it. Hexbear is a demanding place to be. It expects you to not be a complete asshole almost all the time. You're regularly tested on knowledge of an emoji system so complex, it's been known to make London cab drivers cry. If you unthinkingly parrot talking points, you'll be pounced on with annoying facts and aggressive reasonable concern for the value of other people. And if you emit the slightest Hitler particle, you'll be outright banned. How authoritarian! Honesty, sometimes I wonder why I signed up, never mind stay around.

But then I remember that the folks there are a deeply caring lot, who see the problems in the world and actually want to do something about it—even though the goal often seems barely possible—and, in spite of everything, retain a sense of humour and try to make improvements for each other, even if, for now at least, it can only be a :meow-hug:.

Oh, and the XiBucks, of course. Some of us even get roubles, too!

So Jealous, Tegan and Sara

The problem with notable examples is that they're pretty much never representative examples.

Ah, Enhanced, the folks that brought us interrogation.

2. The ordering of each row should not matter.

This is true for your abstracted rows, but is maintaining eight sets of three square states, two or three of which must be updated with every move, really a better model than a single sequence of nine, where only one needs to change at a time? It's more complex to think about, and is less efficient to update. When you throw in steps to canonicalize the rotation and reflection, which may produce different transformations from the input/output grid on the first three moves, you may need to change even more set items with each move.

It's true that, mathematically, the mapping from grid to sequence is arbitrary and the only thing that matters is consistency, but if you view programming languages as a way to communicate with humans, then clarity of purpose, rather than mathematical idealism, should be your goal. Use a nine-item array or a three-by-three nested array for the underlying storage and treat your eight win-checking sets as views into that more ordered structure. These views could well be functions that return a set and are themselves held in a set to be applied in any order. Similarly, treat canonicalization as another way to view the underlying board.

You could sidestep the mutable borrowing by not mutating individual squares. Take a leaf from the functional-programming books and use a function that takes a board and a move and returns an entirely new board. Or takes a board and returns one of the abstracted row sets. There are only nine squares and nine moves. The win-checking views aren't needed before move six. A bit of copying isn't going be a problem.