simon-git: puzzles (main): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  7799786 Mines: allow params to control first-click location.
  e307c34 Mines: fix a buffer overrun with -DSOLVER_DIAGNOSTICS.
  38b2991 Mines: add extra diagnostics for grid perturbation.
  a7c7826 Mines: fix a hang during grid generation.

Repository:     https://git.tartarus.org/simon/puzzles.git
On the web:     https://git.tartarus.org/?p=simon/puzzles.git
Branch updated: main
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2025-07-29 20:56:57

commit 7799786e640e1462583d82193547dae3152772ed
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=7799786e640e1462583d82193547dae3152772ed;hp=dbe6378e23d573f89de1441ba62740ecb8c69c8b
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Jul 29 18:52:36 2025 +0100

    Mines: allow params to control first-click location.
    
    The string encoding of game_params can now include a location like
    "X0Y5" at the end. This has no effect on interactive play (where the
    game waits to see where the player first clicks), but in command-line
    'mines --generate', it forces the pre-played first click to be at the
    specified coordinates instead of randomised.
    
    The idea is that this makes it easier to reproduce bugs that came up
    in interactive play. For example, I ran across a bug this morning
    which seems to come up more often when the first click is near a
    corner.

 mines.c | 43 +++++++++++++++++++++++++++++++++++++------
 1 file changed, 37 insertions(+), 6 deletions(-)

commit e307c3426a92937724e7ccf97f7a1bf2b554f115
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=e307c3426a92937724e7ccf97f7a1bf2b554f115;hp=7799786e640e1462583d82193547dae3152772ed
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Jul 29 18:50:39 2025 +0100

    Mines: fix a buffer overrun with -DSOLVER_DIAGNOSTICS.
    
    We were printing a value from just outside the grid immediately
    _before_ the bounds check that told us not to.

 mines.c | 16 +++++++++-------
 1 file changed, 9 insertions(+), 7 deletions(-)

commit 38b29910630048acecdbae08bd36f407135dc47c
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=38b29910630048acecdbae08bd36f407135dc47c;hp=e307c3426a92937724e7ccf97f7a1bf2b554f115
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Jul 29 18:52:21 2025 +0100

    Mines: add extra diagnostics for grid perturbation.
    
    A bug I was investigating was still confusing until I made the
    perturber explain what it was doing in more detail.

 mines.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 64 insertions(+), 1 deletion(-)

commit a7c7826bce5cbb9b9c337c11b9b7f8b278e76fba
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=a7c7826bce5cbb9b9c337c11b9b7f8b278e76fba;hp=38b29910630048acecdbae08bd36f407135dc47c
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Jul 29 18:53:32 2025 +0100

    Mines: fix a hang during grid generation.
    
    The hang is reproducible, as of the code before this commit, by
    running 'mines --generate 1 9x15n55X1Y1#2-94'.
    
    What seems to happen is that the combination of [solver with
    perturbations mixed in] gets stuck in a loop. At one end of the loop
    there's a large square area cleared around the initial click, with
    every square on the boundary being a mine. So the player can certainly
    solve up to the boundary - but beyond the boundary they can't tell
    what's a mine and what's not. So the perturber thinks about what to
    do, and decides to fill _everything_ in the already-solved clear area
    with mines from the unsolved area (leaving only a 3×3 region around
    the initial click). That's no better, so the next run of the perturber
    clears one extra row and column, and the next one does the same, and
    so on, until we're back in the first situation. And since every time
    we go round this loop we re-mark some squares as "not solved yet" and
    then solve them, it looks as if progress is being made, and we don't
    abandon the entire effort and restart from scratch, which is the usual
    solution to any "stuck in a local optimum" problem.
    
    This commit applies a simple and hopefully robust fix to get out of
    the rut: we introduce a new notion of "progress" which doesn't count
    re-solving a square that was solved before and then marked as undone
    because of a perturbation. Now, after a couple of iterations around
    that loop, the new nperturbs_since_last_new_open mechanism will notice
    that no square has been opened _that was never opened before_ in too
    long, and pull the plug.
    
    I'm not at all happy with this fix. It should solve the immediate
    hang, but I think probably what I _ought_ to do is rethink the entire
    strategy of perturbation, in the large-scale case where we've run out
    of perturbations we can make within a single 3×3 block and have to
    fall back to either emptying or filling every single unknown square.
    
    But fixing the immediate problem is a start!

 mines.c | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)