TalkChess.com

It turns out that the enhanced bare-King mating patch of Fairy-Max 4.8U contained a bug, which broke the search depth for orthodox Chess. (It always switched off null move, rather than just against a bare King, as was intended.) Thanks to Colin Jenkins for noticing this!

So I released a new version 4.8V which fixes this. For the time being it can be downloaded only from

http://hgm.nubati.net/fairymax.zip

which contains the fmax.exe, fmax.ini and logo.bmp. In due time I will probably also replace the version in the WinBoard installer.

This time I tested the new version for playing strength in normal Chess; it scored an exact wash (200-200) against 4.8S at 1-min sudden death, and a 56.5-43.5 win at 40 moves/min, which seems OK.

(Just in case you wonder why there doesn't seem to be an improvement in playing strength due to the new features: bare-King mating in Chess is so easy that it doesn't need the patch, because you almost always have a Q or R to do it, and the only difficult case for which the patches were needed, KBNK, does virtually never occur. This is different in Makruk, however, where Pawns promote to an almost equally worthless 1-step diagonal mover, so that almost no game ends with decent mating potential, and you will have to perform a mate with a horde of nearly worthless pieces. The bare-King patch was needed to make that possible.)

Can you upload _versioned_ .tar.gz files in the future, please? It woud be a big help for linux package mainteners.

Hmm, I am not even sure what that means. What is wrong with the tar balls delivered by GitWeb?

Skipper is still not able to beat 4.8S. Last tournament it scored 4-8 with time control one minute per game.

hgm wrote:Hmm, I am not even sure what that means. What is wrong with the tar balls delivered by GitWeb?

Nothing wrong with the .tar.gz _inside_, just it has no version number info in the file name. There can be 2 problems with this from a packager point of view. If a new version appears, the build server of some distrib will not download the newer .tar.gz because it will find the old one in hes download cache. Another problem, if you release a newer version, but they clear the cache and wants to rebuild the older version, it will download the newer .tar.gz not the old one, what they wanted.
All in all it's a good practice to use version numbers in the tarballs file name .

Would it solve the problem if I update the "make dist" target in the Makefile on every release to create a tar ball with a name containing the version number? i.e. replace
by

Yes, thx.

Is the following acceptable?
I equipped Fairy-Max with a -v option to print its version number, and call it during "make dist" to provide it with the tar-ball name. The downside is that this requires compiling of fairymax even when just making a distro tar ball. I couldn't think of a way to extract the version number from the fairymax.c source through a standard command, though.

hgm wrote:I couldn't think of a way to extract the version number from the fairymax.c source through a standard command, though.

Yours is better though.

Well, I wouldn't say that. I like yours. It realy bugs me that you would have to compile just to create a distro tar ball. And that I then remove the binary, which might have been present before.

So I guess I will use your sed method to set a variable
at the top of Makefile, and then use $(VERSION) in the filenames. (Couldn't do that with my method, because the top of Makefile would also be executed for a plain 'make' to create the binary.)