Sjaak II - beta release!

[Evert]

Note that I was the one who wrote that in the Wikipedia... Originally the sente-loses-on-rep rule was not mentioned at all in that article.

Oh well… so much for me trying to find multiple sources for double-checking some details…

When I replace the line by #if 0 I can compile.

That's good to know. Still, I'll need to find a proper fix… thing is, if I understand the manpage for clock_gettime correctly, that line should have worked, suggesting a problem with Ubuntu, but if that's the case you'd expect to find posts about that too.

EDIT:
Ok, I apparently need to improve my reading skills. From the man page:

Link with -lrt (only for glibc versions before 2.17).

The logo and .eng file are perfectly placed. The binary, however, is put in /usr/local/games/bin/ rather than /usr/local/games/ (as other game binaries compiled from source are), and this is not in the search path, so that the command "sjaakii" does not work.

That surprises me. I checked my local tree, and saw that it has a bin/ subdirectory, which seemed like the normal place to put binaries (it actually contains xboard, for instance). The FHS says to put binaries in games/ though, so I'll do that.

[hgm]

For me installing XBoard from sources puts it in /usr/local/bin/. This is to be considered a bug in the build process. Debian binary packages install it in /usr/games/, not /user/bin/.

Having a /usr/games/bin/ would make no sense. What would be left to go into /usr/games/? It would just be a superfluous level. All game data goes into /usr/share/games/, the manual pages in /usr/share/man/, other docs in /usr/share/doc/...

[Michel]

The /usr/local/games situation is a mess (it is often not in the default path). Even /usr/games is not in the default search path on CentOS.

I would just put the binary in /usr/local/bin.

Packagers can then put the binary in a location suitable for their distro,

[hgm]

Ah, perhaps this is the reason why XBoard make-installs in /usr/local/bin/.

[Evert]

EDIT:
Ok, I apparently need to improve my reading skills. From the man page:

Link with -lrt (only for glibc versions before 2.17).

Should be fixed now.

[Evert]

For me installing XBoard from sources puts it in /usr/local/bin/. This is to be considered a bug in the build process. Debian binary packages install it in /usr/games/, not /user/bin/.

Having a /usr/games/bin/ would make no sense. What would be left to go into /usr/games/? It would just be a superfluous level. All game data goes into /usr/share/games/, the manual pages in /usr/share/man/, other docs in /usr/share/doc/...

Don't ask me why, but I have a /usr/games/share/ next to /usr/games/bin/. Doesn't contain anything useful though, and surely whatever you'd put there should really be in /usr/share/games/ instead...

[Evert]

The /usr/local/games situation is a mess (it is often not in the default path). Even /usr/games is not in the default search path on CentOS.

I don't think it is on Gentoo either, unless a user belongs to group "games".

I would just put the binary in /usr/local/bin.

I could go with that too.

[Evert]

Having a /usr/games/bin/ would make no sense. What would be left to go into /usr/games/? It would just be a superfluous level. All game data goes into /usr/share/games/, the manual pages in /usr/share/man/, other docs in /usr/share/doc/...

Is there a standard location for storing engine data files? Or should I just appropriate /usr/share/games/sjaakii for that purpose?

Not that there's anything to install right now...

[Michel]

Is there a standard location for storing engine data files? Or should I just appropriate /usr/share/games/sjaakii for that purpose?

Normally it would be /usr/local/share/sjaakii .

Usually one works with a makefile with a prefix variable. They default prefix is /usr/local but packagers will change that into /usr .

[hgm]

Sjaak's data files should go into /usr/[local/]share/games/sjaakii/.

I found some weirdness in switching variant with Sjaak under XBoard: it seems initially to refuse the change, and only do it when you press 'New Game'. I think the problem is that you print a setup command in response to "new":

Code: Select all

Reset(1, 1) from gameMode 0
recognized 'embassy' (-1) as variant embassy
GameEnds(0, (null), 2)
31994 >first : force
31994 >first : ping 4
shuffleOpenings = 0
32280 <first : pong 4
32325 >first : memory 132
32325 >first : new
random
32325 >first : variant embassy
32325 >first : level 40 1 0
32325 >first : post
32325 >first : hard
32325 >first : ping 5
Impossible move , type = 0
32343 <first : setup (P.BR.S...G.+.++.+Kp.br.s...g.+.++.+k) 5x5+5_shogi rbsgk/4p/5/P4/KGSBR [-] w 0 1
recognized 'shogi' (-1) as variant embassy
shuffleOpenings = 0
32610 <first : piece P& fW
32610 <first : piece S& FfW
32610 <first : piece B& B
32610 <first : piece R& R
32610 <first : piece G& WfF
32610 <first : piece K& K
32610 <first : piece +P& WfF
32610 <first : piece +S& WfF
32610 <first : piece +B& BW
32610 <first : piece +R& RF
32610 <first : setup (PNBRQFEACWMOHIJGDVLSUKpnbrqfeacwmohijgdvlsuk) 10x8+0_capablanca rnbqkcabnr/pppppppppp/10/10/10/10/PPPPPPPPPP/RNBQKCABNR w KQkq -
32610 <first : piece N& N
32610 <first : piece B& B
32610 <first : piece R& R
32610 <first : piece Q& Q
32610 <first : piece A& BN
32610 <first : piece C& RN
32610 <first : piece K& KisO3
32610 <first : piece P& fmWfceFifmW2
32610 <first : pong 5

You should not do that, and certainly not print a mini-Shogi setup in response to 'new'. The user might have switched back to variant normal, and then you would never get a variant command to correct it. According to the specs 'new' always puts you back in variant normal.

As it is, XBoard gets confused by this because it only accepts the first. This is probably because I had legality testing on: then the first puts it back from VariantUnknown to VariantShogi, and because the latter is a standard variant with known rules, it would ignore setup commands when legality testing is on. With legality testing off it does eventually end up in the selected variant, but after a lot of visible unrest.

I accidentally also noticed that you are very generous with pieceToChars in embassy. The extra defined pieces are not entirely without consequence: they will all be offered as promotion choice. This should also be a reason not to leave the Bishops defined in Los Alamos Chess.