I should have noticed this since I do most development on a 64-bit
powerpc machine now :(. I'm going to have to talk to Jon about the
best way to fix it for 2.5 but for 2.4 I have merely disabled use of
the cache. This is very crude, but it is fool-proof, which is all I
want for 2.4. There will be a 2.4.2 release soon with this and other
important bug fixes.

Jon, what do you think is the best solution here ? I'm favouring
machine-independent text-based files. A well-defined binary format is
simpler to parse for integers but there can be problems with floating
point since not quite everyone uses IEEE. Caching machine-specific
files at run-time is possible, but leads to setgid problems and the
results would have to go in /var. Compile time is another option, but
if /usr/share is shared this could be a problem. 

Ugh.

My first thought is that caching at run time is best.  The files would
have to be stored in /var.  I don't like the idea of storing machine
dependant files in share or home.  What setgid issues would there be
with /var?

Creating the cache at compile time is tricky, especially for
distributions and cross-compiling.  It also adds bloat.

The permissions thing is ugly. You can use a setgid system like the
scores, but you don't have the luxury of being able to open the files
and drop privileges right at the beginning, especially if they haven't
been created yet. You could just put them in a world-writable
directory and use really good checking on the input, but this can lead
to all sorts of amusing abuse separate from the game.

There is one nasty problem with a raw dumped structures format:
recompiling with a new compiler (think gcc 2.9x->3.x for a common
example) could effectively render the data file corrupt if the data
structures are packed differently. You could check the time-stamps on
the binary and the data file, but even that isn't perfect.

Maybe the solution is to have a fixed binary format (with a version
number !) with all the games in the one file. That way you can make
the game setgid, open the file when the game starts and immediately
drop pivileges. Because it is a binary format the games can be at
fixed places in the file and then just filled out as necessary. e.g.

+------------------------------------------+
| File header                              |
+------------------------------------------+
| Rule Set Header                          |
| (including offset of next header)        |
+------------------------------------------+
| Data                                     |
|                                          |
|                                          |
+------------------------------------------+
| Rule Set Header                          |
+------------------------------------------+
| Data                                     |
    .
    .
    .


If you don't have the time to do this I can probably give it a go. I'd
like to get major code changes like this out of the way since we are
quite close to the absolute feature freeze and I'd like to get some
testing in before 2.6, otherwise I'm just going to have to bypass the
caching for the 2.6 release like I have for 2.4.2 and that wouldn't be
good.

I suppose there is another option.  Disable the probabilities stuff by
default.  The game should play normally except that the dealer and
hand probabilities (and hints) would not be available.  This could be
a preference.  If the user really wants to compute probabilities they
would have to deal with waiting for the computation.

This could likely require more significant code changes.  I will have
to look and see.

Does the connect4 data file work on non-x86 architectures?

Callum, I am starting to think that your suggestion is the best option
for now.  One complication could be that the rule sets are not fixed
and the names are completely arbitrary.  We would have to construct
some kind of unique key from the parameters of each rule set.

connect4 (gnect) works on 32bit powerpc. As far as I understand the
source, this means that the data file (white_ob.cn4) can be read
correctly.

Indexing based on parameters is not a big problem. In fact it usually
works out to be easier in the long run (the card library does this for
the card styles, originally for backwards compatibility, but it also
helped when it came time to translate the names).

I've been having a look at what is saved. The integers are not a
problem, but the floats and doubles are. I suspect we can just save
them as fixed point values (i.e. integers) but I don't know what range
they have to cover. Any hints ?

gnect's opening book file is byte oriented which is why it gets away
with it.

It turns out that a gzipped XML cache file is only about 396KiB.  That
is about 50KiB larger than the current binary cache file.  The
precisions used for the floats and doubles are not very high, yet.  So
when we change this the filesize will get a bit larger.

The code for  saving the XML is done.  The loading is mostly done but
I have a small bug to track down.  I should be able to commit this to
CVS tomorrow (not turned on by default).

I now think this is a good way to go.  Using a platform independent
file will avoid other problems in the future.  It should even be
possible to store this XML file in the users home directory at runtime
if we don't want to ship the file by default.

Sounds good Jon. I'm looking forward to it (even on a G5 the
calculation is not quick).

Ok, I committed the changes.  To test writing out the XML file
uncomment the following in game.cpp:
strategy->saveXML ("/tmp/foo.xml.gz");

I think the issues that need to be resolved now are:

1. are we using adequate precision for floats and doubles?
2. is the DTD reasonable?
3. how should we version the DTD?
4. should we generate or distribute the cache file?

I'll check it tonight, but I can answer some of the questions now.

1. Only you can really know, but I'm willing to bet it doesn't need
high precision.

2. and 3. For private application use the DTD doesn't really matter.
DTD are for checking validity and letting other people write these
documents. Until such time as either of these things are necesary the
DTD can be ignored. XML can avoid versioning problems to an extent by
just adding new tags for new features (or attributes to tags). 

4. I'm leaning towards generation. Generating it won't take that long
compared to the overall compile time of gnome-games and reducing the
tarball size is always good.

I checked in a change to activate the XML load/save.  For now the
cache file is generated as needed by the application and saved in
GNOME_DOT_GNOME/blackjack.d.  This is for a few reasons:

1. avoids setgid issues in var or share
2. avoids problems associated with generating cache files during
compilation (like needing a helper app)
3. doesn't make assumptions about which rule set will be played

I wonder if there should be preferences to disable writing cache
files, and to clear cache files.  Might be good.

Does this seem to be working for you guys?

Callum, any suggestions?

It works fine for me. I'm a little worried about dumping data in the
users home directory, but it will add up to only a megabyte assuming
the user plays everything. At this point any changes before 2.6 can
really only be fine tuning and I don't think the current code needs
any. I'm going to mark this bug fixed, but maybe we should keep
possible better solutions in the back of our heads for 2.7 or later.

Jon, as far as ordinary testing goes, it's working fine for me.

Callum: Completely agree.  

Richard: Good, thanks for testing it.

And for the record, I hate directory names with ".d" at the end. 
Unfortunately, there was already a file in GNOME_DOT_GNOME with the
name blackjack.  So, I am just following precedent.

This bug is being reassigned to the "general" component so we can close the blackjack bugzilla component.  Apologies for the mass email!