Feedback request: libchessinterface

[JonasThiem]

I haven't examined many UCI2WB adapters, but I always assumed that was a rather hacky process (UCI2WB is a process in between with stdin/stdout that translates to WB, right?).

Even if it works well in a clean way, you still need one additional entity in between and I'd personally prefer a direct implementation of each protocol. But that's probably a matter of personal preference.

In the end, the idea is probably the same as yours: implementing just one protocol (in your case WB) directly, then have UCI work with that somehow aswell. I just think doing one common protocol dll and then doing UCI/WB directly from there (with the GUI not caring about those details) is a bit more of a direct and cleaner way (personal opinion) than things like UCI2WB.

And I hoped maybe others would be interested in such a library too

[diep]

In particular, PyChess lacked a proper CECPv2 feature implementation for quite some time. It also didn't support rather simple features like colors=0 or debug=1. For UCI, it still gives a FEN for each position instead of startpos + all moves leading up to it which would allow the engine to evaluate 3-fold repetition and other things properly.

I think older Arena versions (<=2) also just accepted features and never rejected any (it just ignored those it didn't know).

XBoard/WinBoard seem pretty awesome with CECP (naturally), but the UCI seems to be a bit hackish with polyglot (although I don't know enough about polyglot to really confirm that).

What is pychess?
Wasn't Arena that thing supported by Quisinsky, the guy who got via via some easy to copy engines and sold them illeally further for money as if he was an official reseller of engines? Also i remember Quisinsky sold the winboard2 engines CD some years ago - no one ever got paid by Quisinsky.

He looks like a criminal anyway.

Those type of guys you refer to?

Why don't you ship them an email?

[JonasThiem]

PyChess is, while not immensively popular, a good example because it reimplements everything and then lacks some protocol details because it just takes a large amount of time to implement all those details. (and it is quite a nice GUI from the interface point of view, so that lack of various protocol things is a bit sad)

While I agree that Arena people are a bit of a strange bunch in a way, it is still a popular GUI.

[diep]

What would be interesting to some is being able to read the chessbase CTG book and even more their databases. But i don't know whether that's legal to build - you have to figure that out first.

[diep]

PyChess is, while not immensively popular, a good example because it reimplements everything and then lacks some because it just takes a large amount of time to implement all those details. (and it is quite a nice GUI from the interface point of view, so that lack of various protocol things is a bit sad)

While I agree that Arena people are a bit of a strange bunch in a way, it is still a popular GUI.

Thanks for saving me the effort to see what pychess is!

[JonasThiem]

I guess that should go into another library since I'm focussing on GUI <-> engine communication. It would be still possible to write a separate library for the task you suggest and use it at the same time, so for the sake of modularity etc it would probably be best to put that into a different library and keep this one focussed on its task.

[diep]

I guess that should go into another library since I'm focussing on GUI <-> engine communication. It would be still possible to write a separate library for the task you suggest and use it at the same time, so for the sake of modularity etc it would probably be best to put that into a different library and keep this one focussed on its task.

Why don't you join a helpdesk in India?

[hgm]

I haven't examined many UCI2WB adapters, but I always assumed that was a rather hacky process (UCI2WB is a process in between with stdin/stdout that translates to WB, right?).

Even if it works well in a clean way, you still need one additional entity in between and I'd personally prefer a direct implementation of each protocol. But that's probably a matter of personal preference.

Indeed, personal preference also plays a role. My preference lies with the separate process. Also because it makes it easier to distribute the task over different machines. (UCI is rather verbose, while WB protocol is extremely compact. So it is very convenient to use WB protocol over the network, and run Polyglot + engine on the remote machine.)

Even locally, there is hardly any measurable performance degradation by using a different process. I measured this with the GUI timing toolkit. It is true that WB + UCI2WB + UCIengine was a bit slower than WB + WBengine. But so was cutechess-cli + UCIengine compared to cutechess-cli + WB engine. It is just a consequence of the relative inefficiency of UCI. WB+UCI2WB was hardly slower than cutechess-cli handling UCI natively, and the difference was sub-millisec on a slow machine.

So I think a separate process is the superior technical solution, and I will never consider implementing UCI in WB natively.

In the end, the idea is probably the same as yours: implementing just one protocol (in your case WB) directly, then have UCI work with that somehow aswell. I just think doing one common protocol dll and then doing UCI/WB directly from there (with the GUI not caring about those details) is a bit more of a direct and cleaner way (personal opinion) than things like UCI2WB.

And I hoped maybe others would be interested in such a library too

Isn't PyChess written in Python?

That old versions of a GUI have shortcomings is not really an argument, because this is something you can never cure. By fixing them they would be no longer the old versions... And the latest Arena versions do have a full WB implementation, as far as I know. So you should not count them as prospctive 'customers'...

[JonasThiem]

It is a valid argument I think because it shows they all needed quite some time to get it right (e.g. PyChess is pretty complete interface-wise for quite a while already with quite some advanced functions, while IMHO important protocol details were missing - although that has been fixed by now), and this time can be saved by doing it centrally for everyone to use

I'm not so much aiming at existing GUI interfaces, I don't expect everyone to rewrite their existing interfaces to use this library.

[hgm]

What would be interesting to some is being able to read the chessbase CTG book and even more their databases. But i don't know whether that's legal to build - you have to figure that out first.

The book format has been decoded. I have a program that can read it.

Knowing what is in the book (mostly raw statistics) is not enough to emulate it, however. You would have to know how the probing code uses the raw stats to convert it to playing probabilities. (Which is furthermore dependent on user settings.)