In the so-called Golden Age of Detective Fiction, there was a group of four or five writers considered the Queens of Crime: Margery Allingham, Agatha Christie, Ngiao Marsh, Dorothy L. Sayers, and Josephine Tey. Christie gets most of the glory in the US due to the Hollywood adaptations of her novels, but recently I’ve been reading through Sayers’ Lord Peter Wimsey and Montague Egg mysteries.

Anyone who has read Christie (even the modern, bowdlerized versions) knows they’re chock-a-block with racism, classism, and antisemitism, and, sadly, Sayers suffers from this as well. Unlike Christie, Sayers brings to bear her Oxford education, so her novels and short stories contain frequent allusions to and excerpts from writers ranging back into classic Greece and in a variety of languages. Like Christie, the plots are convoluted with any possible suspects and countless red herrings.

In her 1925 short story, “The Fascinating Problem of Uncle Meleager’s Will” (originally published Pearson’s Magazine, volume 60), Sayers includes a full crossword puzzle that Lord Peter Wimsey and his associates must solve to locate the referenced will. Normally, I let this kind of story just wash over me. I don’t try to solve the murder and I don’t try to analyze the clues. But in this case, I thought I’d try to solve the crossword.

Of course, British crosswords are different than the NY Times style with which I’m more familiar. Furthermore, the number of classical references quickly overwhelmed me. I wasn’t able to complete it. But maybe you will? I took the layout, clues, and solution and laid them out in a convenient PDF for your puzzling pleasure.

Everyone loves to dump on Javascript because of stupid things like [] == ![]; // -> true. Some languages are much better at this. But PHP is not among them. I found the following not quite what I would have expected:

boolval("1");   // returns true
boolval("0");   // returns false
boolval(1);     // returns true
boolval(0);     // returns false
boolval("00");  // returns true
boolval("0.0"); // returns true
boolval(0.0);   // returns false

I had a database corruption event happen in a Docker container, one result of which was that the container was completely wedged and unusable. I spent a lot of time removing containers and images and recreating them, only to have the same problem. In my case, the symptom was I’d create a new MySQL database, and operation would be fine, until part way through a bulk data import or heavy query, and the database would crash and the container would get into an unusable state again. Docker didn’t yield anything in the log, but MySQL showed corruption:

2024-11-27T22:35:38.182396Z 8 [ERROR] [MY-013183] [InnoDB] Assertion failure: os0file.cc:2899:dir_fd != -1 thread 140305764447808
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
2024-11-27T22:35:38Z UTC - mysqld got signal 6 ;
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=511ab47ad6d5dfd73d58eea5860b1c9c9a97ce07
Thread pointer: 0x7f9ad4000fc0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 7f9b7b3febc0 thread_stack 0x100000
/usr/sbin/mysqld(my_print_stacktrace(unsigned char const*, unsigned long)+0x41) [0x15af021]
/...

Once this problem occurred in a container, the database wouldn’t be start-able, often complaining about being unable to update permissions on /var/lib/mysql/mysql.sock.

Eventually, with much futile searching, I found this posting and switched Docker Desktop away from using VirtioFS to using gRPC FUSE for sharing the filesystem between the container and the host machine. This seems to have resolved the issue. I can load big databases again, and heavy transactions work in my development environment again.