Feedback request: libchessinterface

[diep]

I guess this did not find its way in the official specs yet. Because WB does not implement it yet, I guess I never felt the urgency.

In a discussion here, however, I was convinced that the best way to do it in the protocol would be with multiple triples separated by semi-colons,

Bad solution - it's not downwards compatible and makes implementing the time control for most engines more complicated.

Majority supports just 1 time control anyway.

My vision on protocols is that it should always aim that with a minimal simple set of commands to implement it can work for you rather quickly.

[gbtami]

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.

http://scidb.svn.sourceforge.net/viewvc ... rc/db/cbh/

[JonasThiem]

Sounds like a great idea - the average engine will probably not care about the detailed time phases anyway (hence they won't use xlevel=1 and work as they do now), and for those which do, this spec really covers all variants.

IMHO CECP, due to its feature command, was always about adding it all while UCI is a much more minimal protocol (which I personally think is a downside/negative point, despite UCI being easier to implement for the engine people). So go for the solution that does it all

Why not put this into the winboard specs? Even if winboard doesn't implement it right now, it is of help to engine devs and other GUI devs if it's already specified.

[JonasThiem]

Due to feature xlevel=1 being required to activate it, I don't think there are any backwards compatibility issues involved, are there?

[hgm]

Indeed, the WB-protocol method for ensuring backward compatibility is to use the feature command. There is no restriction on what an engine could send as feature, if it is something the GUI does not know, it simply rejects it. The engine can use the accept / reject reply to figure out if it is allowed to send stuff to the command (although GUIs are typically quite resistant to receiving garbage from engines).

I don't think it is always constructive to insist on 100% backward compatibility, though. If we want to elevate something that already works in practice with most engines to a new standard, allowing it only to be used after it is enabled by a newly defined feature command (which none of these engines would yet send), would just prevent you from using things that work. Sending intra-game level commands seems to be such a case. If it breaks some engines when a GUI does that, so be it. Then the user should simply not request multi-session TC with these engines.

[diep]

Indeed, the WB-protocol method for ensuring backward compatibility is to use the feature command. There is no restriction on what an engine could send as feature, if it is something the GUI does not know, it simply rejects it. The engine can use the accept / reject reply to figure out if it is allowed to send stuff to the command (although GUIs are typically quite resistant to receiving garbage from engines).

I don't think it is always constructive to insist on 100% backward compatibility, though. If we want to elevate something that already works in practice with most engines to a new standard, allowing it only to be used after it is enabled by a newly defined feature command (which none of these engines would yet send), would just prevent you from using things that work. Sending intra-game level commands seems to be such a case. If it breaks some engines when a GUI does that, so be it. Then the user should simply not request multi-session TC with these engines.

I got rid of the feature type stuff from DEP.

There is a few problems with such additions. You just complicate things more.

In fact end 90s, start 21th century there wasn't a single document that properly described some things with respect to winboard protocol, let alone protover2. You just ran with a few commands and then in logfile you saw which commands you got in and fixed engine for that.

Somewhere around 2001 or so i still 'fixed' the way how to claim a draw for Diep.

The protocol never was really well described when it was at its reign peak.

Now we have moved to the other side of things. Overdesign of a protocol.

All what you seem to add to it now, from functional viewpoint seen is not very efficient and it overshoots the original goal.

[hgm]

Yes, well, not much we can do about that now. The protocol is as it is, and hundreds of engines use it. So we better stick to it, no matter what we think of it.

[Don]

Hello fellas,

I'm planning to write a C/C++ engine handling library and would like to hear some comments on its usefulness and the interface.

Why?
I noticed many GUIs support either UCI or Winboard rather incompletely, or even just one of the two. Also, rewriting the code to set up another process with pipes for each new GUI seems to be a bit tedious (as most would probably do it the same way, the major differences lie somewhere else I suppose).

How?
So I thought I would write a library: libchessinterface. It would incorporate close to zero chess knowledge, so all the chess knowledge and support for variants etc etc would be up to the GUI. The library wouldn't be limiting you here, but also not assisting.

All the library would do is launch the process for you and provide a uniform interface that hides the differences between UCI and Winboard/CECP. Since UCI is a bit simpler due to bein stateless, the interface probably looks a bit more like Winboard than UCI.

Interface draft:
Tell me what you think. Would you use this library in your GUI? Also, please comment on the first iteration of my header file: https://github.com/JonasT/libchessinter ... nterface.h

Why not add move generation and move validation? Obviously you do this in a modular way to support chess variants, the idea being that each variant has a separate "plug-in" with the same interface. I call it a plug-in but it could part of the library.

Don

[JonasThiem]

Well the idea is, you tell the engine to move:

Code: Select all

// Calculate initial move as current color:
void chessinterface_Go(struct chessinterfaceengine* engine,
int (*movecallback)(const char* move, void* userdata), void* userdata);
// The provided callback function will be called FROM ANOTHER THREAD
// as soon as the engine finished calculating the move,
// with the move and your provided userdata as parameters.
// Your move callback should return 1 if the move was valid and accepted,
// or 0 if it was invalid.

... and in the move callback, you can reject its move. Inside that callback, you could also call whatever movegen you want to check on the move.

Now I could also add a movegen to libchessinterface so you don't need to write it yourself, but the truth is that I only have optimised/specific FIDE chess movegen code with bitboards and pool allocation for my engine lying around.

Writing a new generic movegen from scratch that can deal with any board size (which I think would be a requirement so it can be adapted for variants more easily) and has nice code would need a bit of time and I'd like to postpone that for now.

If anyone's interested in contributing additional movegen functions to the library with their implementation, I'd be interested in adding them.

[mcostalba]

Now I could also add a movegen to libchessinterface so you don't need to write it yourself

He has already written everithing he needs. Don't assume Don is waiting for your library: he is not.

IMHO also GUI authors are _not_ waiting for your library: you have a solution looking for a problem.

If anyone's interested in contributing additional movegen functions to the library ...

You won't go far IMHO. The only motivation you should rely on is to have fun writing your stuff. If this motivation is not enough for you better even don't start.