It's a pain having it in a rule in Makefile.gtk, which isn't even the
recommended makefile these days - it can't be re-run conveniently, and
there's no way to parametrise it. Now it can be run no matter which
makefile you're using, and it lets you narrow down to a subset of
games (though not presets). Other options could easily be added.
Chris Boyle reports that if you right-drag a numbered cell off the
grid, _all_ numbered cells (except the immutable initial clues) get
reset to blank, because this is treated as an attempt to erase a whole
chain of linked cells (of the form a,a+1,...,a_k) and the cells with
definite numbers are all treated as 'chain 0'.
In that situation, I now substitute the same behaviour you'd get by
left-dragging the numbered cell off the board, i.e. erase _just_ that
cell and not the whole of the rest of the puzzle.
(The previous unintended behaviour was a UI action you surely never
want - and Chris also reports that due to the Android front end's way
of representing right-drags, it's especially easy to hit by mistake.)
My Mac has just upgraded itself to include a version of clang which
warns if you use abs() on a floating-point value, or fabs() on an
integer. Fixed the two occurrences that came up in this build (and
which were actual build failures, because of -Werror), one in each
direction.
I think both were benign. The potentially dangerous one was using abs
in place of fabs in grid_find_incentre(), because that could actually
lose precision, but I think that function had plenty of precision to
spare (grid point separation being of the order of tens of pixels) so
nothing should have gone seriously wrong with the old code.
Each game's .R file should append the binary to $(GAMES) in both the
'am' and 'gtk' makefiles, but presumably due to copy-and-paste from an
out-of-date version, tracks.R only did 'gtk'.
Also clarified CHECKLST.txt in the hope that I won't miss that again.
Aapo Rantalainen points out that comparing 'char c' against zero gives
rise to gcc's "comparison is always false" warning, which escalates to
an error under -Werror.
This is one of those situations where the warning is doing more harm
than good, but here's a rephrasing which casts to unsigned so that
both negative numbers and positive out-of-range ones can be caught by
the same comparison.
Not sure how I managed to write the former by mistake, but I didn't
notice because browsers didn't immediately complain. Still, James
Harvey points out, it ought to be turned into the actually
standards-compliant spelling of the tag. Ahem.
A load of source files in the icons subdirectory were being left out
of the distribution tarball because I tried to include them using a
combined wildcard and bash brace expansion - but makedist cites
/bin/sh, so can't get away with bashisms. Expanded the braces.
Previously it simply chose every move based on the static evaluation
function 'minimise the pair (longest shortest-path to any square,
number of squares at that distance)'. Now it looks three moves ahead
recursively, and I've also adjusted the evaluation function to tie-
break based on the number of squares brought to distance zero (i.e.
actually in control).
The result isn't an unconditional improvement on the old solver; in a
test run based on 'flood --generate 1000 12x12c6m0#12345' I found that
57 out of 1000 grids tested now had longer solutions. However, about
three quarters had shorter ones, and solutions are more than a move
shorter on average.
It was getting conscientiously escaped by the new webpage.pl :-) but
in any case it's better to have the puzzle descriptions be plain text
usable in any context.
This should simplify the process of adding a new puzzle, by automating
the part where I have to manually edit index.html separately from the
main build step.
The ones I started with were a bit under-varied and over-orthogonal.
Get rid of some of the more pointless things like 16x16 with lots of
extra moves, and add some with different colour counts. While I'm
here, make the menu descriptions nicer.
Based on a web game I saw a few years ago, and dashed off this weekend
after I thought of a way to write a good (though not quite optimal)
heuristic solver, here's a random little thing not quite in the same
line as the most usual kind of Puzzles fare: instead of making you
scratch your head to find any move to make at all, it's easy to find
solutions in principle, and the challenge comes from having to do so
within a move limit.
Thanks to Stephen Norman for most of the work, particularly working
out what all the metadata had to be in the first place. This patch is
mostly his work, and all I've done is fiddle with the plumbing that
gets the right version number into the right places.
Unity hijacks the menu bar and prevents it from appearing in the main
puzzle window. And we wait for the menu bar to appear before reducing
the puzzle drawing area's size request. These two behaviours go
together badly.
Fixed by detecting the extra GTK property that the Unity patches
invented, and using that to know whether to expect the menu bar to
show up at all.
I unthinkingly transplanted into Net the same loop-finding algorithm
used in Loopy and Slant, which identifies the connected components
into which the grid lines divide the plane, and marks an edge as part
of a loop iff it separates two different components. This works fine
for a planar graph, but in Net's wrapping mode, it's possible to have
loops which do not have this property - e.g. a loop can go off the top
of the grid and back on the bottom to join up with itself, and then
it _doesn't_ disconnect the surface into two components.
(In principle, this kind of problem can turn up in any topological
space with a non-trivial H_1 homology group, which is why it fails on
the torus to which Net's wrapping mode corresponds, but not on the
plane or sphere. I think it's forgivable that I hadn't expected
homology to be the cause of any bug in practical code ever!)
Fixed by inventing yet another dsf-based loop-finding algorithm, this
one based on tracing round the outside of connected components of the
graph. It's still not _fully_ general, in that this one still depends
on the graph being drawn on an orientable surface (so it'll need
another rewrite if I ever add Mobius strip or Klein bottle modes for
Net...), but it's fairly simple to state and implement, and detects
loops that the previous implementation did not, such as the one in the
starting position of 3x3w:1a39ac6a8 .
Loops are detected using the same dsf technique I ended up using in
Slant, and highlighted in red (whether or not the connected component
they belong to is currently powered).
Should make life a little bit easier for someone who's filled in most
of the grid to a nice uniform cyan and finds one piece left over - now
they have some idea where to start looking for their mistake.
We also take care not to generate any loops in the starting position,
on grounds of politeness (don't accuse the user of a mistake before
they've even had a chance to make one).
Loop detection does not contribute to the code that decides whether
the puzzle is complete, because there's no need - if all squares are
connected together, then there can't be any loops anyway, by graph
theory.
When filling in a cyclic subgroup or one of its cosets, I've often
found I wanted to set an entire diagonal to the same thing at once
(usually SW-NE, but the other way round too in non-abelian groups),
and it's a pain having to do that to each square individually.
Restricting multiple selection to diagonals makes it easy to get the
selection I really wanted.
This is probably slightly nicer anyway, in that it specifies exactly
_which_ ANSI standard I'm talking about; but the main reason for
making the change is that it means I can now build the Unix puzzles
with clang.
It's not that clang doesn't _support_ -ansi; it accepts it just fine
on any command line that's actually doing some compiling. But on a
link-only command line, i.e. with only object files as input and no
sources, clang emits the annoying warning "argument unused during
compilation: '-ansi", and if you have -Werror as well then that
warning becomes an error.
You'd think there would be some makefile flags variable I could
nonetheless put -ansi in, but apparently not - automake passes CFLAGS
to both compiles and to link-only commands.
And you'd also think that surely I should be able to work around this
by having my configure.ac do a test link and stop trying to use that
option if it didn't work - especially since configure.ac already tests
a bunch of compile options to make sure they don't object to system
header files, after the time I found that a GTK header was
incompatible with my usual -Werror. But in fact, if I change that
AC_COMPILE_IFELSE to an AC_LINK_IFELSE, autoconf generates a single
compile-and-link command line, and hence does not expose the problem
using -ansi on link-only command lines.
Fortunately, -std=c89 does not generate this same warning from clang.
I don't know why not - surely the two options are more or less
equivalent - but it makes my build work again for the moment.
In conversation with a user last week, it emerged that the command
'solo --generate 1 9jk#12345' was giving a different game from the one
it gave when I ran it, and it turns out that this is because I've set
SOLO_DEFAULT=7jxdi in my environment to make GUI Solo automatically
start up in my (current) favourite mode. And the difficulty setting
from that parameter string was being reused to fill in the unspecified
difficulty slot in the '9jk', so that the same params string was being
interpreted differently by our two machines.
This is certainly wrong - the whole point of random seed strings like
that is to be interpreted the same way everywhere. But it's a side
effect of something I did do on purpose, for people switching back and
forth between playing randomly generated games and playing a game id
pasted (or typed) in from elsewhere. So this fix, with a giant comment
explaining it, I _think_ should retain the behaviour I originally
wanted while getting rid of the behaviour I didn't.
spec_to_dsf() should not report invalid input by failing an assertion,
because one of the contexts it's called from is validate_desc(), in
which the whole point is to present a useful error message to the user
before getting to the point where an assertion might go off at all.
Game description 5j:c1_5o4_3c,c___aba___cca_a_a_aca now fails
validation cleanly, where previously it would trigger this bug.
Due to a copy-and-paste error, I was accidentally treating 'y' as the
special-case character which puts no 1 bit after the run of 0s, which
should have been 'z'. Game id 9jk#12345-5994 failed an assertion as a
result (because it generates a y which was accidentally treated as
special).
When I did the recent rewrite of the Bridges drawing code, I spotted
and replicated the code in game_redraw that set G_WARN at redraw time
on an island with unsatisfiable clues, but didn't spot the code
elsewhere (e.g. map_group_check) which might have set G_WARN ahead of
time, so I failed to check for that. As a result, if you join some
islands together into a subgraph with no further room for expansion
(e.g. connect a pair of 1s together, or a pair of 2s with a double
bridge) then all the bridges in that subgraph light up red but the
islands themselves forget to.
Trivial one-line fix.
