> I am repeatedly impressed by the combination of clarity and 
> conciseness

Thanks, Eric! I had actually buried the code link at the bottom of the 
article because I didn't feel it wasn't quite up to my usual standards, 
and that was because I wasn't planning to discuss the code, just the 
concepts. I'm glad to hear it wasn't so unreadable as I feared!

Thanks for reaching out, Gour! Despite all my time with Emacs, I've just 
never gotten into Org. I suppose I'm just not that organized! Elfeed's 
Org integration was mostly the work of Matus Goljer and Remy Honig, and 
I just avoid breaking it, so it's not reflection of my own habits. I 
have no comments about Org integration with email.

> So, moving toward vim/mutt/mu would be simplification of my workflow 
> in comparison with the Emacs based ones...

Per my article about Mutt, I'm happier without Emacs playing a central 
role in my email workflow. It's been over three years, and I still feel 
that way. Better to compose independent tools than to duct-tape tools 
together in Emacs. With Mutt I could easily swap Vim out for Emacs+Evil 
or any other editor. But when I was using Notmuch, each component was

Thanks for the information, Andrew. I *did* see the GitHub issue, but 
when I saw I needed to catch up on the terminology (which you had kindly 
linked), I set aside replying until I had done so. Then I put off that 
reading. Sorry!  However, I'm now caught up.

> I'd guess that a subpart of the game is reducible to Nim

What subpart did you have in mind? I had at one point considered a 
bottom-up approach with dynamic programming, but I didn't have the 
exhaustive list of 6,955 terminal states from which to start, at least 
not with without first taking a different approach.

As a kind of stretch goal, I would like to reduce the CPU and memory 
requirements needed for perfect play. Since I now have the exhaustive

To help clarify, here's a scan of the original rules:
https://images-na.ssl-images-amazon.com/images/I/81F-UCwOiYL._SX569_.jpg

> but can he play there *after* the first turn (in which case presumably 
> the second player would have a winning strategy, since he can't 
> continue to mirror at that point)?

Yes, the center rule only applies to the first player's first turn. The 
first player is free to play in the center on his second turn. The rule 
never applies to the second player. The ternary expression in my 
"valid()" function checks if it's the first turn and, if so, permits 
play anywhere except the center. On any other turn it consults the 
player's mask.

> If you can, could you send details, so that we can fix it?

The error is "multiple definition" of osPlatformId, osMinorVersion, and 
osMajorVersion. There are definitions in both winmisc.c and winpgnt.c. 
The latter is caused by setting PUTTY_DO_GLOBALS before including 
putty.h, which includes puttyps.h, which includes winstuff.h, which 
normally tries to use GLOBAL to avoid the definition.

This is with PuTTY 0.74, the "Unix source archive" download.

Thanks for the tip, though it's not quite what I need. Normally when GDB 
takes control all threads are stopped, but I only want to stop the 
thread calling open(). Fortunately GDB supports "non-stop mode" that 
only pauses the trapped thread.

Unfortunately it appears to be broken in my version of GDB (8.2.1). I 
used the non-thread-specific version of your breakpoint, enabled 
non-stop mode, then ran my aopen.py. GDB aborted as soon as the second 
thread hit the breakpoint, with, "A problem internal to GDB has been 
detected, further debugging may prove unreliable."

gdb$ break open64 if $_memeq($rdi, "/tmp", 4)
gdb$ set non-stop on
gdb$ r

Half the various GNU utilities have at least one. Any that produce color 
output (ls, grep, etc.) have a --color option with an optional "WHEN" 
argument. ln, install, and mv have a --backup with optional CONTROL 
argument. df --output has an optional FIELD_LIST argument. mkdir, 
install, mkfifo, and mknod have --context with an optional CTX argument. 
ls and vdir have --hyperlink with an optional WHEN argument. mkdir 
--tmpdir has an optional DIR argument. rm has --interactive with an 
optional WHEN argument and --preserve-root with an optional ALL 
argument. sched has --remove with an optional HOW. od has --width with 
an optional BYTES, and it also comes with a short option version -w also 
taking optional BYTES. pr also has a whole bunch like this. I could keep 
going since GNU has so many examples, but I'll stop here!

Git has a ton of them, too. Its --exec-path option takes an optional

I was just having a discussion with someone the other day about "smart" 
behavior, and I had said I preferred simpler, intuitive behaviors that 
have easily-understood failure modes. Your own latest article about 
Matlab range handling is a perfect example!

Typically the long and short options are associated and so the option 
parser treats them as if they were the same option. The program should 
not care which form, short or long, was actually used, and typically 
there's no way to tell.

Fixed. Thanks, Jakub! I *had* tested all the concepts in a real program, 
but when writing the article I retyped all the code from memory. Even 
with years of working with it, I'm still routinely caught off-guard by 
Python's global and nonlocal declarations.