simon-git: puzzles (master): Simon Tatham

[Commits to Tartarus CVS repository.]

TL;DR:
  e917a7d Re-run mkauto.sh from within makedist.sh.
  b31155b Account for disconnected paths in Loopy and Pearl error highlights.

Repository:     git://git.tartarus.org/simon/puzzles.git
On the web:     http://tartarus.org/~simon-git/gitweb/?p=puzzles.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2016-04-28 20:57:05

commit e917a7d03a3570b09ecdf71a638ccc8496341d60
web diff http://tartarus.org/~simon-git/gitweb/?p=puzzles.git;a=commitdiff;h=e917a7d03a3570b09ecdf71a638ccc8496341d60;hp=6a8a53e7235a8621313b792b498ebb43452f9e38
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Apr 28 20:34:59 2016 +0100

    Re-run mkauto.sh from within makedist.sh.
    
    It isn't necessary to cause the right files to _exist_, because
    makedist.sh is run from Buildscr which has already run mkauto. But it
    turns out it _is_ important to get the relative timestamps of
    Makefile.in and Makefile.am the right way round, otherwise somebody
    who unpacks the tarball and runs 'configure' and 'make' will find make
    tries to rebuild Makefile.in because it thinks Makefile.am is newer -
    and if they don't have the right automake installed, or any automake,
    that will fail.

 makedist.sh |    1 +
 1 file changed, 1 insertion(+)

commit b31155b732c1bab2e744a0ebf7532af2de2ce4a5
web diff http://tartarus.org/~simon-git/gitweb/?p=puzzles.git;a=commitdiff;h=b31155b732c1bab2e744a0ebf7532af2de2ce4a5;hp=e917a7d03a3570b09ecdf71a638ccc8496341d60
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu Apr 28 20:42:23 2016 +0100

    Account for disconnected paths in Loopy and Pearl error highlights.
    
    In commits 24848706e and adc54741f, I revamped the highlighting of
    erroneous connected components of those two puzzles' solution graphs
    in cases where a non-solution loop existed, so that the largest
    component was considered correct and the smaller ones lit up in red.
    
    I intended this to work in the cases where you have most of a correct
    solution as one component and a small spurious loop as another (in
    which case the latter lights up red), or conversely where your mostly
    correct component was joined into a loop leaving a few edges out (in
    which case the left-out edges again light up red). However, a user
    points out that I overlooked the case where your mostly correct
    solution is not all one component! If you've got lots of separate
    pieces of path, and one tiny loop that's definitely wrong, it's silly
    to light up all but the longest piece of path as if they're erroneous.
    
    Fixed by treating all the non-loop components as one unit for these
    purposes. So if there is at least one loop and it isn't the only thing
    on the board, then we _either_ light up all loops (if they're all
    smaller than the set of non-loop paths put together), _or_ light up
    everything but the largest loop (if that loop is the biggest thing on
    the board).

 loopy.c |   44 +++++++++++++++++++++++++++-----------------
 pearl.c |   26 +++++++++++++++++---------
 2 files changed, 44 insertions(+), 26 deletions(-)