Duck Chess

[rgrosz789]

No, I generally don't compile chess engines from source. I was using the standard fairymax engine.

I can NOT explain why it showed the same error message as mayhemduck. I guess it started working again after I rebooted that computer.

[rgrosz789]

It seems this is purely an engine problem. Although it is a bit strange that the third printf was not visible in the debug file. If the format of the mayhemduck file violates the rules for executables, I would expect execvp() to return with an error code, and the following perror() to print the corresponding message. But the behavior is like the system itself prints the message, and then terminates the process, without ever returning from the execvp() call.

I am still curious whether that error message disappears when you delete the perror() call. (And leave in all the printf.)

Here is the resulting xboard.debug:

locale = en_US.UTF-8
recognized 'duck' (-1) as variant duck
recognized 'duck' (-1) as variant duck
recognized 'duck' (-1) as variant duck
shuffleOpenings = 0
shuffleOpenings = 0
Version: xboard 4.9.1 + uci2wb ()
Reset(1, 0) from gameMode 0
recognized 'duck' (-1) as variant duck
GameEnds(0, (null), 2)
shuffleOpenings = 0
StartChildProcess (dir=".") ./uci2wb debug mayhemduck
380 >first : xboard
protover 2
383 <first : # queue 'protover', searching=0
383 <first : # command protover
383 <first : feature setboard=1 usermove=1 debug=1 ping=1 name=1 reuse=0 exclude=1 pause=1 sigint=0 sigterm=0 done=0
383 >first : accepted setboard
383 >first : accepted usermove
383 >first : accepted debug
383 >first : accepted ping
383 >first : accepted name
383 >first : accepted reuse
383 >first : accepted exclude
383 >first : accepted pause
383 >first : accepted sigint
383 >first : accepted sigterm
383 >first : accepted done
383 <first : feature option="UCI2WB debug output -check 1"
383 >first : accepted option
383 <first : feature option="ponder always -check 0"
383 >first : accepted option
383 <first : # uci
383 <first : # engine said: a: {mayhemduck}
383 <first : # engine said: b: {41300000000000}
393 <first : # engine said: /usr/games/mayhemduck: 1: Syntax error: "(" unexpected
393 <first : tellusererror UCI2WB: mayhemduck died on me
GameEnds(30, xboard exit, 2)

[hgm]

The 'Syntax error' message is still there. So it must somehow have been generated by the system during the execvp() call.

An anomaly now is that the second element in argv[] now is not 0, though, as if mayhemduck was called with arguments (which the StartChildProcess denies).

[rgrosz789]

MayhemDuck doesn't send "Syntax error: "(" unexpected". It only complains about bad moves.
I don't have such errors. Running Linux Mint 21.1 Vera. Sometimes it (Xboard) crashes but when it works, it works well.
Did fast grep on xboard and uci2wb. And couldn't find anything...

Anyway released MayhemDuck 2.3. Should be much better.

I tried running some tests of MayhemDuck 2.3 versus earlier versions on my Linux Mint PC. For some reason, version 2.3 always crashes...

I also ran some tests of MayhemDuck 2.1 versus 2.2 on my Linux Mint PC. Version 2.1 wins convincingly with a 3+2 time limit.

[rgrosz789]

I tried running some tests of MayhemDuck 2.3 under Linux Mint, but it doesn't seem to work. Here is the output from xboard.debug:

locale = en_US.UTF-8
recognized 'duck' (-1) as variant duck
recognized 'duck' (-1) as variant duck
recognized 'duck' (-1) as variant duck
shuffleOpenings = 0
shuffleOpenings = 0
Version: xboard 4.9.1 + uci2wb ()
Reset(1, 0) from gameMode 0
recognized 'duck' (-1) as variant duck
GameEnds(0, (null), 2)
shuffleOpenings = 0
StartChildProcess (dir=".") ./uci2wb debug mayhemduck23
255 >first : xboard
protover 2
257 <first : # queue 'protover', searching=0
257 <first : # command protover
257 <first : feature setboard=1 usermove=1 debug=1 ping=1 name=1 reuse=0 exclude=1 pause=1 sigint=0 sigterm=0 done=0
257 >first : accepted setboard
257 >first : accepted usermove
257 >first : accepted debug
257 >first : accepted ping
257 >first : accepted name
257 >first : accepted reuse
257 >first : accepted exclude
257 >first : accepted pause
257 >first : accepted sigint
257 >first : accepted sigterm
257 >first : accepted done
257 <first : feature option="UCI2WB debug output -check 1"
257 >first : accepted option
257 <first : feature option="ponder always -check 0"
257 >first : accepted option
257 <first : # uci
257 <first : # engine said: a: {mayhemduck23}
257 <first : # engine said: b: {0}
257 <first : # engine said: c: execvp failed
257 <first : # engine said: # queue 'uci', searching=0
257 <first : # engine said: # command uci
257 <first : # engine said: Error (unknown command): uci
GameEnds(30, xboard exit, 2)
57920 >first : result * {xboard exit}
57920 >first : quit

[hgm]

What happens when you type:

mayhemduck23
uci

on the command line?

The debug output first was a bit confusing to me, until I noticed that the modification in uci2wb that you posted earlier contains two calls to execvp(): one before, and one after the third debug printf (c). This second one should not have been there. (But would not interfere with normal operation, as then the first execvp() would succeed, and transfer control to the engine, so that the code after it would never be reached.)

As it is, the first execvp() appears to fail executing mayhemduck23, so thatf the uci2wb code after it gets executed, in particular the printf (c). But then something remarkable happens: the second execvp(), which attempts exactly the same as the first, does not appear to fail. If it had the forked off engine process would have reached the exit() call in the uci2wb code, and terminated. Which would have triggered the "... died on me" error message from the original uci2wb process, after printing what the perror() just before the exit() would have coughed up. Instead uci2wb manages to send a 'uci' command to whatever was started by the second execvp(). Which then replies with what looks awfully much like an error message that a CECP engine would give.

[rgrosz789]

This is what I got:
bash: /usr/games/mayhemduck23: Permission denied

OOPS - I forgot to change permissions for mayhemduck23 to allow execution as an executable. Now that I did, it seems to be working.

[hgm]

I suppose that, if it had not been for this spurious execvp(), the following perror() would have relayed this "permission denied" message eventually to XBoard, where it would appear in an error popup.

But the basic lesson is that when and engine command fails, one should always first try to execute that same command from the command line. Because usually XBoard will be accurate in assigning the blame to the engine, and observing how it fails from the command line might give more information.

This was the first thing I suggested when you reprorted the problem with fairymax, but we where misguided there because the problem somehow went away by the time we tried fairymax from the command line (without us realizing it had also gone away under Xboard), so that we falsely concluded it must have been an XBoard or UCI2WB issue.

[rgrosz789]

MayhemDuck doesn't send "Syntax error: "(" unexpected". It only complains about bad moves.
I don't have such errors. Running Linux Mint 21.1 Vera. Sometimes it (Xboard) crashes but when it works, it works well.
Did fast grep on xboard and uci2wb. And couldn't find anything...

Anyway released MayhemDuck 2.3. Should be much better.

I have played a few games against MayhemDuck 2.3 on my main PC running Windows 10. It seems to play slowly compared to other engines.

For example, most of the engines beat me at a 3+2 time limit, because I run out of time. But I just played a 3+2 game against MayhemDuck 2.3, and I still had more than a minute left on the clock when its flag fell. I did not expect that ...

[rgrosz789]

Based on the difficulty with running some executables on my old hardware, I decided to buy a newer PC that will be dedicated to linux. Hope that will allow me to do more testing of Duck chess engines.

One thing I would like to try is playing the linux version against the Windows version of one engine (say Fairy Stockfish or MayhemDuck). I searched on this forum, but didn't see a discussion of setting up a tournament on a local network, between multiple computers.