Remaining XBoard API

[Mk-Chan]

I wanted to make a checklist of the remaining API (xboard commands). Sorry if this is a little large but it's taken directly from the spec. Xboard -> Engine commands:

• [x] xboard
• [x] protover
• [ ] accepted/rejected
• [x] new
• [x] variant
• [x] quit
• [x] random
• [x] force
• [x] go
• [x] playother
• [x] white
• [x] black
• [x] level
• [x] st
• [x] sd
• [x] nps
• [x] time
• [x] otim
• [x] usermove
• [x] ? - implemented as stop()
• [x] ping
• [x] draw
• [x] result
• [x] setboard
• [ ] edit
• [ ] hint
• [ ] bk
• [x] undo
• [x] remove
• [x] hard
• [x] easy
• [x] post
• [x] nopost
• [x] exit
• [x] analyze
• [x] name
• [x] rating
• [ ] ics
• [x] computer
• [x] pause/resume
• [x] memory
• [x] cores
• [x] egtpath
• [x] option

Engine -> Xboard commands (Parsing required):

• [x] feature \<features>
• [x] Illegal move/Illegal move (REASON): MOVE
• [x] Error (ERRORTYPE): COMMAND
• [x] move
• [ ] \<result> {COMMENT}
• [x] resign
• [x] offer draw
• [ ] ics messages

[Mk-Chan]

No wonder it's much easier to code UCI, this is quite a mess!

[PedanticHacker]

I looked into this and found out that it is an overkill to implement the whole XBoard specification in Python and support the old XBoard spec and the new spec. You must realize that XBoard only runs on *nix machines (Mac, Linux). You have to take Windows users into consideration, too. Well, then you need to implement the WinBoard specification as well. So much code!

My proposal is this. Since we have UCI specification fully implemented, we can just implement a UCI adapter. Take a look at this: http://wbec-ridderkerk.nl/html/details1/PolyGlot.html

[niklasf]

Sure, adapters are cool, and some already exist. But XBoard also has some features that UCI does not have, so I think a direct protocol implementation is good to have.

[Mk-Chan]

Interestingly enough, we were joking around in HG Muller's monthly tourney and he told me that uci engines can send xboard commands to the GUI via info string xboard <any xboard cmd>

Want to take a stab at it @niklasf ?

[PedanticHacker]

Interesting stuff! Is this ment for Winboard as well?

[Mk-Chan]

As I said before, Xboard and Winboard are the same thing. Winboard is simply the windows version of Xboard.

[gbtami]

@PedanticHacker xboard and winboard are chess GUI programs communicating with engines via CECP protocol.

Btw. there is a newer CECP document maintained by HGM here http://hgm.nubati.net/CECP.html It organized in a different way and contains some stuff not in the old one.

[Mk-Chan]

@gbtami there are some new options yea and it looks much better presented. Thanks for this.

[Mk-Chan]

So I've been getting quite busy and haven't really found the time to get to the two major features(non ics related): pondering and variants. I'll get to them soon but i just wanted to comment here as a reminder.

[Ravenslofty]

Something important that's forgotten here is the # command for debugging. python-chess tries to parse lines beginning with # when they should be ignored, which makes it choke on the debugging/statistics code in Dorpsgek.

[gbtami]

@ZirconiumX @Mk-Chan fixed it in python-chess right now.

[Mk-Chan]

As of #272 pondering is left

[Mk-Chan]

Pondering is handled by #277 but testing is remaining. The difficulties I faced have been mentioned at the bottom of that PR. So now that main commands for protover 2 should be handled completely.

[niklasf]

I couldn't find a good way to test this easier. I guess it's fine for now ... maybe we'll find something eventually.

[niklasf]

I think the remaining commands should only be implemented if specifically requested.

[thomasahle]

How is "Error (ERRORTYPE): COMMAND" handled? It seems that currently we just throw

<XBoardProtocol (pid=97059)>: Unexpected engine output: Error (ERRORTYPE): COMMAND

and crash. Maybe exiting quickly is the best option.

[Mk-Chan]

This API is deprecated in favor of the engine one. Are you using an older version of python-chess?