Any joker1114w Updates?

[mhalstern]

A question to H.G. Muller:

I like joker1114w. It plays openings quickly and well, and against top engines, holds it's own, for a while. When it loses, it starts to go wrong in the late middlegame and early endgame.

I know you are working on variants. I was wondering if there are any planned updates to Joker.

[Graham Banks]

A question to H.G. Muller:

I like joker1114w. It plays openings quickly and well, and against top engines, holds it's own, for a while. When it loses, it starts to go wrong in the late middlegame and early endgame.

I know you are working on variants. I was wondering if there are any planned updates to Joker.

It would be good, but I think HG is working on a newer engine.

[hgm]

Joker loses because it lacks search depth. This is mainly because it has no true move sorting.

I stopped working on Joker because:
*) it was too heavily based on a 0x88 board, making it a nightmare to implement 10x8 or 10x10 boards
*) The move generator relied too much on pieces being either leapers or sliders
*) the code was not suitably structured for implementing SMP
*) the code had become a mess, making it almost impossible to make bug-free changes

So I started writing a new engine from sratch (which I named Spartacus) based on a 24x10 board (half of it usable, like the 16x8 board of 0x88). The idea was to base the move generator on an incrementally updated attack map, so that it would naturally generate moves in MVV/LVA order, but this has so far only worked for short periods in test runs (before I changed something in the engine that broke it again). Anyway, unlike Joker, Spartacus has a material table, and a (make-shift) Pawn hash.

Progress is a bit slow, though, because 80% of my Chess-programming time is soaked up by WinBoard, and Spartacus is currently only my 4th engine, priority-wise (after Fairy-Max, Shokidoki and HaQiKi D). I hope that the upcoming Battle of the Goths tournament will inspire me to do some work on Spartacus, after I am done with the ICGA Olympiad.

[Michel]

Speaking of joker111w.exe. For me joker crashes under xboard, when it is going to make its second move. I think this might be because xboard probably sends SIGINT to the engine (since joker1114.exe, being a windows engine, does not send sigint=0).

The Linux version of joker does send sigint=0, and it does not crash.

Is there a way to force xboard not so send SIGINT even if the engine does
not declare sigint=0? This is useful for windows engines.

Code: Select all

18361 <second&#58; move d7d5
machine move 1, castling = 7 0 4 7 0 4
move to parse&#58; d7d5
&#40;7,0&#41; &#40;0,0&#41; &#40;4,0&#41; &#40;7,7&#41; &#40;0,7&#41; &#40;4,7&#41; castling rights
TC string = '+40/5'
mps=40 tc=300000 inc=0
move&#58; d7d5
, parse&#58; d5 (
)
time odds&#58; 1.000000 1.000000
Interrupting first
18362 >first &#58; time 29224
18362 >first &#58; otim 29358
book hit = &#40;NULL&#41;
18362 >first &#58; d7d5
AnimateMove&#58; piece 22 slides from 3,6 to 3,4
GameEnds&#40;38, Error&#58; first chess program (/home/vdbergh/SRC/CHESS/GNUCHESS/ENGINES/joker1114w.exe&#41; exited unexpectedly, 2&#41;

[hgm]

Is there a way to force xboard not so send SIGINT even if the engine does
not declare sigint=0? This is useful for windows engines.

Apparently not! The engine can switch it off by printing "kibitz Hello from Crafty", but that is hardly an improvement over sending feature sigint=0...

I guess an option for this is badly needed. Arguably this silly and non-portable feature should even be switched off by default... There once has been talk if there should not be a command-line option to let the user force features as if the egine set them, so you could say -firstFeatures "sigint=0 variants="normal,nocastle"" to trickXBoard into thinking the engine said that. This could be implemented in two flavors, namely altering the default of the mentioned features, or overruling even what the engine says. Perhaps the first flavor would make more sense as a global (non-engine-specific) option, because on a known engine it would either be equivalent to forcing the option (when you know the engine does not send the feature), or it would be overruled (when it does send it). So we could have -featureDefaults for altering defaults, and -firstFeature, -secondFeature for forcing settings (processed after receiving feature done=1).

Anyway, none of this is currently implemented. Note that current XBoards are strictly speaking broken, for a combination of historic reasons and me not properly reading the specs. It sends SIGKILL in stead of SIGTERM to engines that do not promptly react to the quit command, (you can specify a delay, however) and does not pay attention to sigterm=0 for that...

Funny thing is that the (Windows) Joker source does contain the line

Code: Select all

	signal(SIGINT, SIG_IGN);

Apparently this is a no-op in a MinGW compile...

Perhaps I should make a Windows compile of the source I used to make the Linux version (which should be platform independent). This is probably a slightly more modern version (1.1.14h) than the Windows binary I spread around, as it actually is a WB v2 engine implementing setboard (the old one was v1 and did not implement setting up a position at all, but when I made a 10x8 derivative I could not do without that, as 10x8 Chess has several commonly used opening positions, and I then ported that patch back to the 8x8 version.)

[Michel]

Code: Select all

   signal(SIGINT, SIG_IGN);

Apparently this is a no-op in a MinGW compile...

No the compile is ok. I started up joker.exe in wineconsole and then it indeed ignored ctrl-C (wineconsole implements windows signals).

However if you run joker.exe in wine then wine receves the ctrl-C and quits.
One may argue whether this is the correct behaviour of wine, but that is the way it is.

[hgm]

Indeed, it seems a wine bug. Currently I always let my engines request sigint=0, rather than making them insensitive to SIGINT, because I find it extremely annoying when you cannot Ctrl-C them from the command line.

[hgm]

OK, with the latest version in the hgmaster branch of the hgm.nubati.net repository, the (persistent) option -featureDefaults "sigint=0" should make XBoard refrain from using SIGINT unless the engine explicitly requests it through feature sigint=1. To suppress it even in that case you can use -firstFeatures "sigint=0" (a volatile option).

This should work with an arbitrary list of features, but including done=... or option="..." will have (currently pretty bad) undefined effects.

[Michel]

Thanks very much!

Michel