simon-git: puzzles (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  03d464d tracks.c: draw_clue: Introduce bg parameter
  b98d93a tracks: Greyscale colour initialisation: line up columns
  aafb1b4 tracks: Make error clue background white
  cdf1639 deserialise: use the right one of {,c}params.
  c0503d4 midend_deserialise: keep deserialised data in a struct.
  9e62c71 midend_deserialise: accept an extra validation function.
  b9b73ad midend: Allow "new game" to be undone
  9f6114e Style tweaks to the newgame_undo patch.
  db313b3 Forbid undo of new-game if it would change the params.

Repository:     https://git.tartarus.org/simon/puzzles.git
On the web:     https://git.tartarus.org/?p=simon/puzzles.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2017-10-01 11:14:02

commit 03d464dc658a2dc7048b62c1058aba78125b82d3
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=03d464dc658a2dc7048b62c1058aba78125b82d3;hp=f03e8d30a038f740ea0bfe21474de5df69093893
Author: Ian Jackson <ijackson at chiark.greenend.org.uk>
Date:   Sat Sep 30 19:50:46 2017 +0100

    tracks.c: draw_clue: Introduce bg parameter
    
    No functional change.
    
    Signed-off-by: Ian Jackson <ijackson at chiark.greenend.org.uk>

 tracks.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

commit b98d93ac553687bcebd2232e234975f4cb635d3f
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=b98d93ac553687bcebd2232e234975f4cb635d3f;hp=03d464dc658a2dc7048b62c1058aba78125b82d3
Author: Ian Jackson <ijackson at chiark.greenend.org.uk>
Date:   Sat Sep 30 19:50:47 2017 +0100

    tracks: Greyscale colour initialisation: line up columns
    
    This makes it much easier to see the commonality in these formulaic
    lines.
    
    Whitespace change only.
    
    Signed-off-by: Ian Jackson <ijackson at chiark.greenend.org.uk>

 tracks.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

commit aafb1b4983d4cd2eb2d3465b4ed9ad2d67888bf5
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=aafb1b4983d4cd2eb2d3465b4ed9ad2d67888bf5;hp=b98d93ac553687bcebd2232e234975f4cb635d3f
Author: Ian Jackson <ijackson at chiark.greenend.org.uk>
Date:   Sat Sep 30 19:50:48 2017 +0100

    tracks: Make error clue background white
    
    This makes them stand out more.
    
    Signed-off-by: Ian Jackson <ijackson at chiark.greenend.org.uk>

 tracks.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

commit cdf163953105e37b4c90838227342c4eb2cab670
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=cdf163953105e37b4c90838227342c4eb2cab670;hp=aafb1b4983d4cd2eb2d3465b4ed9ad2d67888bf5
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Oct 1 09:15:49 2017 +0100

    deserialise: use the right one of {,c}params.
    
    The serialised game stores a long-term and a short-term parameter
    structure, which correspond to me->params (the thing that gets used by
    the next New Game command) and me->curparams (the thing that _was_
    used to generate _this_ game). So data relevant to the current game
    ought to be validated against the latter, but in fact I was
    accidentally passing the former to several validation calls.
    
    I think this probably avoided causing a problem because typically
    params and cparams don't differ very much: the usual reason why
    they're not the same is that somebody has manually entered a game
    description involving an incomplete description of the parameters
    (lacking generation-specific details like difficulty level), but by
    the very fact that those incomplete descriptions have to contain
    _enough_ information to understand a specific game description,
    copying just those parts of the description into the long-term params
    structure makes the two similar enough that validation won't fail.
    
    However, testing an upcoming patch which calls midend_deserialise at a
    more difficult moment (specifically, just after midend_set_params,
    meaning that the two params structures can now differ _arbitrarily_)
    reveals my error. Fixed to use cparams where that's the right thing.

 midend.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

commit c0503d48738851ac31cd49ee98afa4f3e431d64a
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=c0503d48738851ac31cd49ee98afa4f3e431d64a;hp=cdf163953105e37b4c90838227342c4eb2cab670
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Oct 1 09:50:22 2017 +0100

    midend_deserialise: keep deserialised data in a struct.
    
    Lots of the local variables in midend_deserialise are now fields of a
    structure which contains everything that is _going_ to be written into
    the midend once we finish validating it all. This makes it easy to
    keep all that data together, and (in future) pass it to other
    functions all in one go.
    
    No functional change.

 midend.c | 238 ++++++++++++++++++++++++++++++++++-----------------------------
 1 file changed, 127 insertions(+), 111 deletions(-)

commit 9e62c710dfba0596eb355b95c46fd5153f5fe13d
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=9e62c710dfba0596eb355b95c46fd5153f5fe13d;hp=c0503d48738851ac31cd49ee98afa4f3e431d64a
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Oct 1 09:59:50 2017 +0100

    midend_deserialise: accept an extra validation function.
    
    This will let me do a 'conditional deserialisation' operation, in
    which we fully decode the serialised data and then (assuming that gave
    no errors) decide whether or not to actually install it based on some
    arbitrary condition.
    
    I don't think there's any possible use for the extra check function
    _outside_ midend.c, so I've left the API for front ends as it is; the
    externally visible midend_deserialise() doesn't have the new
    parameter, and only midend_deserialise_internal() includes it.

 midend.c | 35 +++++++++++++++++++++++++++++++----
 1 file changed, 31 insertions(+), 4 deletions(-)

commit b9b73adb53b3ffb09a2e8c9682351bf892634470
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=b9b73adb53b3ffb09a2e8c9682351bf892634470;hp=9e62c710dfba0596eb355b95c46fd5153f5fe13d
Author: Ian Jackson <ijackson at chiark.greenend.org.uk>
Date:   Sat Sep 30 19:50:49 2017 +0100

    midend: Allow "new game" to be undone
    
    It is annoying when one intends to choose "restart" and chooses "new
    game" instead.  Right now, the puzzle one wanted to try again is
    discarded.
    
    To fix this we are going to have to save a lot more information than a
    normal game state.  Handily, we already have the serialise/deserialise
    machinery.
    
    The advantage of using this is that the previous game is easily saved
    in its entirety, including its own undo history, and also probably in
    a more compact format.
    
    The (de)serialisation interface is rather clunky for use with a memory
    target.  Sadly none of the existing implementations of a resizing
    memory array have been conveniently brought out into puzzles.h, and I
    think that that's beyond the scope of what I wanted to do here.
    
    We don't serialise the new game undo serialisation data.  So
    loading/saving doesn't preserve any "new game" undo, as does "new
    game" twice (and as does context switching on a Palm Pilot).
    
    Signed-off-by: Ian Jackson <ijackson at chiark.greenend.org.uk>

 midend.c | 66 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 65 insertions(+), 1 deletion(-)

commit 9f6114e27236105d64e23e063a17db84389059ba
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=9f6114e27236105d64e23e063a17db84389059ba;hp=b9b73adb53b3ffb09a2e8c9682351bf892634470
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Oct 1 09:15:24 2017 +0100

    Style tweaks to the newgame_undo patch.
    
    I've renamed the new midend variables to match my usual naming
    convention of using 'size' for the total buffer size and 'len' for the
    amount of currently used space (and a couple of other variables to
    match those in turn), partly for consistency and also because the name
    'midend_undo_used' made me half-expect it to be a boolean. The buffer
    itself is called 'midend_undo_buf', again to avoid making it sound
    like a function or flag.
    
    Buffer growth is still geometric but less aggressive (factor of 5/4
    each time instead of 2), in the hope of wasting less memory on low-RAM
    platforms; newgame_undo_deserialise_read should have been static, and
    now is; newgame_undo_buf is initialised using NULL rather than 0 so it
    doesn't look like an integer, and is freed with the rest of the
    midend.
    
    And I think we _should_ enforce by assertion that midend_deserialise
    didn't return an error, because there's no reason it ever should in
    this situation (unlike when reading from a file, where the user might
    have provided the wrong file or a corrupted one). This immediately
    allowed me to spot a bug in the existing deserialisation code :-)

 midend.c | 52 +++++++++++++++++++++++++---------------------------
 1 file changed, 25 insertions(+), 27 deletions(-)

commit db313b3948d27244dd7c34c2609c66d6204d8931
web diff https://git.tartarus.org/?p=simon/puzzles.git;a=commitdiff;h=db313b3948d27244dd7c34c2609c66d6204d8931;hp=9f6114e27236105d64e23e063a17db84389059ba
Author: Simon Tatham <anakin at pobox.com>
Date:   Sun Oct 1 10:22:35 2017 +0100

    Forbid undo of new-game if it would change the params.
    
    The newgame_undo data was being saved on every call to
    midend_new_game, including the one just after midend_set_params when a
    new puzzle preset was selected. So you could select a new preset from
    the menu, and then press 'u', and the midend would _try_ to undo that
    operation and restore the previous game with a different set of
    parameters.
    
    This would do the wrong thing in the front end, because front ends in
    general will not be expecting that a change of game parameters might
    result from an arbitrary keyboard event - they won't be expecting to
    have to call the function that moves the highlight in the game-type
    menu, for example, and they _certainly_ won't be expecting that a
    window resize might be necessary in response to a random keystroke.
    
    One possible response would be to fix all the front ends so that they
    _are_ prepared for either of those consequences of a keystroke event,
    and then it would be possible to undo not only the New Game menu
    option and the 'n' key but also undo any selection of a preset from
    the game-type menu, or even a full re-customisation of the game
    settings. But that would be quite an upheaval even in _my_ front end
    collection, and also probably be awkward for downstream front ends, so
    until I'm convinced of the value of going to all the effort, the
    simpler approach is just to disallow undoing a new game in those
    situations.
    
    (This does mean that re-selecting the _already active_ game preset
    from the type menu will be treated as an undoable new-game event,
    which I think is an acceptable UI oddity.)

 midend.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 80 insertions(+), 4 deletions(-)