NYT 2022-05-01 crashes

[gkuenning]

The NYT puzzle for 2022-05-01 crashes xword-dl:

Traceback (most recent call last): File "/usr/bin/xword-dl", line 33, in <module> sys.exit(load_entry_point('xword-dl==2022.2.16', 'console_scripts', 'xword-dl')()) File "/usr/lib/python3.6/site-packages/xword_dl-2022.2.16-py3.6.egg/xword_dl.py", line 1096, in main File "/usr/lib/python3.6/site-packages/xword_dl-2022.2.16-py3.6.egg/xword_dl.py", line 63, in by_keyword File "/usr/lib/python3.6/site-packages/xword_dl-2022.2.16-py3.6.egg/xword_dl.py", line 265, in download File "/usr/lib/python3.6/site-packages/xword_dl-2022.2.16-py3.6.egg/xword_dl.py", line 962, in parse_xword IndexError: string index out of range

That line is solution += square[0][0], which happens after some other code that proves the puzzle isn't empty, and after some checks on the shape of the square. I can see that it would fail, for example, if square was multiple characters. So my guess is that the NYT has violated some standard (is there one?) or some assumption about puzzle formats.

[thisisparker]

Thanks for reporting! I was able to repro this and figure out the issues.

That third prong of the conditional set is for rebus answers, and the .puz file requires a single letter in the solution spot. The double slice thing (square[0][0]) grabs the first letter of the first acceptable rebus answer provided.

In this case, and this puzzle's tech was kind of a fiasco, the first acceptable option provided is an empty string. There isn't a public spec that these are built to, so they're not strictly in violation of anything by doing that, but it didn't work well with solvers (and the .puz format doesn't let you use an empty string in that slot anyway.)

The fix for this would be to check whether the first provided acceptable answer is an empty string and if so... provide an X instead of its first character? Or move onto the second string? (In this case, the second acceptable answer was the string NOTHING so this would somewhat confusingly jam N into the solution.)

I'm inclined to say that this is enough of an edge scenario that we shouldn't overfit to it with a special case. But if you have thoughts I'd be happy to hear them!

[gkuenning]

I agree; crossword writers sometimes do things that just aren't "normal". For example, I once did a crossword where the gimmick was that certain squares had a three-letter word (I think it might have been "fun"), with both the across and down answers being words that had that string in them. How could you generalize *that*? Incidentally, the 2022-05-21 version puzzle for the LA Times also won't download; I get an error message "Incorrect padding". I have a copy on paper, so maybe I'll do it and find out whether it's yet another weird gimmick. Perhaps someone needs to write an RFC for online crosswords. Sigh.

…

Thanks for reporting! I was able to repro this and figure out the issues. That third prong of the conditional set is for rebus answers, and the `.puz` file requires a single letter in the solution spot. The double slice thing (`square[0][0]`) grabs the first letter of the first acceptable rebus answer provided. In this case, and this puzzle's tech was kind of a fiasco, the first acceptable option provided is an empty string. There isn't a public spec that these are built to, so they're not strictly in violation of anything by doing that, but it didn't work well with solvers (and the .puz format doesn't let you use an empty string in that slot anyway.) The fix for this would be to check whether the first provided acceptable answer is an empty string and if so... provide an `X` instead of its first character? Or move onto the second string? (In this case, the second acceptable answer was the string `NOTHING` so this would somewhat confusingly jam `N` into the solution.) I'm inclined to say that this is enough of an edge scenario that we shouldn't overfit to it with a special case. But if you have thoughts I'd be happy to hear them! -- Reply to this email directly or view it on GitHub: #44 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

-- Geoff Kuenning ***@***.*** http://www.cs.hmc.edu/~geoff/ If you can't measure it, it's not science. -- Robert A. Heinlein, "The Door Into Summer"

[thisisparker]

The LAT issue should be fixed by the latest release, which you can upgrade through pip or this repo, whichever you've previously done. (The new version with the fix will be 2022.5.21.) In that case it's not a weird gimmick, but a change in how they're read into the online solver.

I'm closing this issue but feel free to open a new one or be in touch if you run into any problems!

[gkuenning]

Shoulda done a git pull before I whined about that one... :-( Yeah, it works now.

…

The LAT issue should be fixed by the latest release, which you can upgrade through pip or this repo, whichever you've previously done. (The new version with the fix will be `2022.5.21`.) In that case it's not a weird gimmick, but a change in how they're read into the online solver. I'm closing this issue but feel free to open a new one or be in touch if you run into any problems! -- Reply to this email directly or view it on GitHub: #44 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

-- Geoff Kuenning ***@***.*** http://www.cs.hmc.edu/~geoff/ If at first you succeed, try to hide your astonishment. -- Harry F. Banks