That's what the comment said I'd left it at, but in some kind of editing goof, I failed to actually do so.
I updated Emscripten recently, to version 3.1.54. The result was that none of the WASM puzzles run any more, because they produce a stack trace at startup with the error message "to do setValue(i64) use WASM_BIGINT". I don't fully understand this. The stack trace comes via a JS wrapper around a WASM-compiled function called __main_argc_argv, which sounds like something in the Emscripten library startup. Somewhere in there it goes via _js_get_date_64(), which tries to write an i64 into the WASM memory array, which hits this abort in setValue(). Web searching for the error message turned up https://github.com/godotengine/godot/pull/88594 which gave me the clue that '-s WASM_BIGINT' is a command-line setting for the Emscripten linker. And indeed, setting that makes the startup-time error go away and the puzzles run again. But it also causes older versions of all browsers to be unsupported, presumably on the grounds that they don't have whatever WASM bigint feature this flag causes the code to use. I don't really understand what's going on here. I assume _js_get_date_64 is being called to handle a 64-bit time_t. But the Puzzles code doesn't work with time_t at all, so this is entirely in the Emscripten standard library. And if the pre-main() startup code needs a 64-bit integer write, which won't work without this flag, then surely _nothing_ would work without this flag, and surely someone would have noticed that, and made that flag the default? This all seems confusing and I wonder if I've misunderstood something. However, if I don't fix it in _some_ way, the web puzzles will stay out of action for days and I'll get lots of email complaints. So here's something that makes them basically work again, and maybe we can figure out the rest of the story later.
Emscripten 3.1.51 withdrew support for legacy (pre-Chrome) Edge completely, and this command-line option now provokes an error from the compiler.
This includes the textual version number in its existing form (yyyymmdd followed by an abbreviated git hash). The four-part binary version is set to 1 followed by year, month and day; if I ever want to change that, I can increment the initial 1. FileDescription is taken from the existing DESCRIPTION string provided to each puzzle() statement in CMakeLists.txt. This means that puzzles.rc now always defines at least one resource, so we can remove the workaround for MinGW's windres not being able to cope with an empty .rc file, which added a dummy resource in the absence of an icon.
There's no reason to put the .rc file into developer tools like galaxieseditor at all. Its current job is to add an icon, and those tools don't have any. I'm about to add version information, and they won't have that either (in particular, no description string like the games do). The CLI developer tools already don't include puzzles.rc, and GUI dev tools are more like those than they are like puzzles. puzzles.rc was being added to an aux GUI tool's source file list by get_platform_puzzle_extra_source_files(), which is called for aux GUI tools as well as for puzzles proper. However, it's not as simple as just eliminating that call, because on Unix, we _do_ need to add the same extra source files to GUI dev tools that we do for puzzles, because gtk.c contains external references to either an array of the puzzle's icons or an empty array indicating that there aren't any, so _something_ has to provide that. So instead, get_platform_puzzle_extra_source_files now takes an extra argument saying whether the program is a real puzzle or an aux tool; windows.cmake leaves out puzzles.rc in the latter case, but unix.cmake puts the icon array in unconditionally.
It's horribly repetitive, and we had a list of all the icons' pixel sizes anyway!
That way, any application displaying the .desktop with its icon will pick the icon size it deems the best one for the current rendering. See the Icon Theme Specification: https://specifications.freedesktop.org/icon-theme-spec/latest/ar01s07.html Signed-off-by: Emmanuel Gil Peyrot <linkmauve@linkmauve.fr>
Now using the browser's "copy" operation while the focus is in the puzzle will copy the puzzle state to the clipboard. Browsers seem to have odd ideas about whate element to target with the "copy" event: Firefox targets the parent of the <canvas> while Chromium targets the <body>. To cope with these and possible future weirdness I attach the event handler to the document and then look to see if it's plausibly related to the canvas. Arguably we might want to handle a wider range of "copy" events, maybe any where the selection isn't empty. I'm not sure, though, so we'll start with the minimal change.
The 'core' library contains almost all the same objects as 'common', but leaves out hat.c. And the auxiliary program 'hatgen' now links against that slightly reduced core library instead of 'common'. This avoids a dependency loop: one of hatgen's jobs is to generate hat-tables.h, but hat-tables.h is a dependency of it. Of course, the generated hat-tables.h is already committed, so this doesn't present a bootstrapping problem in a normal build. But if someone modifies hatgen.c in order to regenerate hat-tables.h, and does so in a way that makes it uncompilable, they can't rebuild hatgen and try again! Of course you can always revert changes with git, but it's annoying to have to. Better to keep the dependencies non-cyclic in the first place.
The C stack used by Emscripten is quite small, so passing more than a few klilobytes of data on it tends to cause an overflow. Current versions of puzzles will only generate tiny preferences files, but this might change in future and in any case Puzzles shouldn't crash just because the preferences in local storage have got corrupted. To fix this, we now have JavaScript allocate a suitable amount of C heap memory using malloc() and stick the preferences file in there. This could plausibly fail if the preferences file were really big, but that's unlikely since browsers generally limit an origin to about 5 MB of local storage. In any case, if malloc() does fail, we'll just ignore the preferences file, which is probably the right thing to do.