nissy-core/src/solvers/solutions.h, branch python-callbackThe "engine" of nissy, including the H48 optimal solver.https://git.tronto.net/nissy-core/atom?h=python-callback2025-08-07T13:28:01ZAdded API function for solution variations2025-08-07T13:28:01ZSebastiano Trontosebastiano@tronto.net2025-08-07T13:09:46Zurn:sha1:5355de2921126e2b75e24abd57e17556e22a6ed0Fix bug2025-07-31T11:09:42ZSebastiano Trontosebastiano@tronto.net2025-07-31T11:09:42Zurn:sha1:bf3497420c9a12397dc13a34faf3ce3e456f3aa7Fixed bug with counting solutions for coordinate solver2025-07-30T14:35:25ZSebastiano Trontosebastiano@tronto.net2025-07-30T14:35:25Zurn:sha1:36c317ebd1cf1dba8a8cbec494f4d3971e6cefd3Cleanup some TODOs2025-07-29T08:55:29ZSebastiano Trontosebastiano@tronto.net2025-07-29T08:55:29Zurn:sha1:52c21640508c3fc668107778ae027ff4428ebd89Removed VLA notation from function parameters.2025-05-27T07:03:51ZSebastiano Trontosebastiano@tronto.net2025-05-27T07:03:51Zurn:sha1:7c934801f88c640970ad41b5ddd39f4e39609f28
I found out that this gives undefined behavior when then size is 0.
Better not to have it at all, it is confusing for other developers anyway.
Do all loggin in main thread2025-05-23T14:54:59ZSebastiano Trontosebastiano@tronto.net2025-05-23T14:48:58Zurn:sha1:c6a77f30f64be73a5e55e06336975f2ecfbb2324
Before this committ, the solver (via the generic solution-appender
routines in src/solve/solutions.h) and the H48 data generator did some
logging in the worker threads, without using any locks. This was not nice,
but in practice it did not cause any problem, because the log messages
were rare.
However, this turned out to be a problem when building to WASM, because
web workers do not have access to the main JS memory, and therefore
they cannot call functions from the main JS. This includes not only the
callback functions for logging, but also those for polling the status
of the solver (run / pause / stop).
This commit fixes this at the cost or being somewhat inelegant: the
solutions are not logged as they are found, but only every 500ms.
Adjusted solvers, fixed bug2025-04-23T12:52:58ZSebastiano Trontosebastiano@tronto.net2025-04-23T12:42:28Zurn:sha1:039267a278bb9e0580e8aebd85ef5f3ed774688fImprove order of moves in NISS solutions2025-04-20T14:57:38ZSebastiano Trontosebastiano@tronto.net2025-04-20T14:47:52Zurn:sha1:f1575ed335166a0897f2cfd314a0f4bade6a10fc
Now the side that has more moves is written first.
For example: write (U L F) B instead of B (U L F)
This also fixes the test on appendsolutions, which used an older version
of the function's signature.
Improved logging, especially for solve2025-04-19T10:28:52ZSebastiano Trontosebastiano@tronto.net2025-04-19T10:28:52Zurn:sha1:3485be851f4fff1c9c6fe621f0619d2b4103bc06Small rework of optimal vs maxsols2025-04-17T12:36:27ZSebastiano Trontosebastiano@tronto.net2025-04-17T08:50:57Zurn:sha1:0ece4b72db22139db51e8f5f37c25f24c84f3e43
I wanted to make the "optimal" and "maxsolutions" options mutually
exclusive, but in the end I decided there is value in keeping both
(e.g. for specifying a limit to the number of solutions when asking
for "all" optimal").
Now optimal cannot be negative anymore, for the same reason of maxsolutions.
The interface user (shell, UI) will have to take care of handling this
in a way that makes sense for the user. Usually this means setting
the maximum number of solutions to UINT_MAX (or a similar very high
number) when the user wants "all optimal".