Proposal for Linux engine standard

[hgm]

I think there is a great need for a btter interaction beteen installing GUIs on Linux and installing engines for those GUIs. Currentlly the burdon of configuring the GUI to use the engine is on the user, who would have to go on instructions provided in the engine docs. This is a very undesirable situation.

What I had in mind is that we would decide upon some standard system directory, like /usr/share/games/engines/, where engines could 'drop' a file during their install to announce their presence, and provide some info about themselves. GUIs could then scan this directory to kno hich engines are on the system, and retrieve the info on how to configure the GUI to use it.

For Chess engines it would obviously be important to kno if the engine is UCI or WB, what command is needed to start up the engine, which game (e.g. Chess variant) it plays, if it plays only one, if it has its own opening book, how it reports the score (white POV or stm POV), what its approximate Elo is, etc. And perhaps if it has special demands for specific GUIs, by recommending some GUI-specific GUI options.

For instance, something like

UCI command = fruit
Game = chess
Book = true
Score POV = stm
XBoard options = -fSAN
SCID options = whatever
...

or

WB command = maxqi
Game = xiangqi
Book = false
Score POV = stm
XBoard options = -fSAN -boardSize 49

Any suggestions?

[diep]

I think there is a great need for a btter interaction beteen installing GUIs on Linux and installing engines for those GUIs. Currentlly the burdon of configuring the GUI to use the engine is on the user, who would have to go on instructions provided in the engine docs. This is a very undesirable situation.

What I had in mind is that we would decide upon some standard system directory, like /usr/share/games/engines/, where engines could 'drop' a file during their install to announce their presence, and provide some info about themselves. GUIs could then scan this directory to kno hich engines are on the system, and retrieve the info on how to configure the GUI to use it.

For Chess engines it would obviously be important to kno if the engine is UCI or WB, what command is needed to start up the engine, which game (e.g. Chess variant) it plays, if it plays only one, if it has its own opening book, how it reports the score (white POV or stm POV), what its approximate Elo is, etc. And perhaps if it has special demands for specific GUIs, by recommending some GUI-specific GUI options.

For instance, something like

UCI command = fruit
Game = chess
Book = true
Score POV = stm
XBoard options = -fSAN
SCID options = whatever
...

or

WB command = maxqi
Game = xiangqi
Book = false
Score POV = stm
XBoard options = -fSAN -boardSize 49

Any suggestions?

You're writing this proposal just for yourself?

Bob just uses crafty and AFAIK no GUI except xboard.
I'm using diep under linux and can connect with linux to windows,
as my GUI can connect to an engine running on a linux box (Diep can act as a TCP server both under windows as well as under linux).
Marcel van Kervinck runs rookie under linux.

So that leaves you as only linux users who runs more than 1 engine under linux, or did i forget someone on this planet who does?

I'd say with 1 user you're at liberty to write whatever proposal you like, though even with more than 1 person using more than 1 engine, i'd guess you'd write whatever you'd like yourself anyway, regardless of what that 2nd person would like.

Note that i never understood those who use at linux a GUI anyway, even though some of my GUI's crosscompile.

X.org is too slow from performance viewpoint i'd argue. Eats too much system time.

I always install machines where i want to run an engine at, without X of course.

[hgm]

I never run engines on Linux. Let's see who bad your counting is, by how many will post here...

[michiguel]

I think there is a great need for a btter interaction beteen installing GUIs on Linux and installing engines for those GUIs. Currentlly the burdon of configuring the GUI to use the engine is on the user, who would have to go on instructions provided in the engine docs. This is a very undesirable situation.

What I had in mind is that we would decide upon some standard system directory, like /usr/share/games/engines/, where engines could 'drop' a file during their install to announce their presence, and provide some info about themselves. GUIs could then scan this directory to kno hich engines are on the system, and retrieve the info on how to configure the GUI to use it.

For Chess engines it would obviously be important to kno if the engine is UCI or WB, what command is needed to start up the engine, which game (e.g. Chess variant) it plays, if it plays only one, if it has its own opening book, how it reports the score (white POV or stm POV), what its approximate Elo is, etc. And perhaps if it has special demands for specific GUIs, by recommending some GUI-specific GUI options.

For instance, something like

UCI command = fruit
Game = chess
Book = true
Score POV = stm
XBoard options = -fSAN
SCID options = whatever
...

or

WB command = maxqi
Game = xiangqi
Book = false
Score POV = stm
XBoard options = -fSAN -boardSize 49

Any suggestions?

You mean that the engines should send those lines at startup?
There are certain things that could be deal with the option feature, right?

Miguel

[bnemias]

Does this facility already exist in windows? I don't recall anything like that.

I like the idea in principle-- however it's somewhat of a chicken/egg problem. What engine will support some new standard that no GUI currently has, and vice versa. Without getting all the major GUI programs onboard, it's all academic.

Also, various distros have substantially different root filesystem structures. It could be very difficult to find a suitable location that spans even 80% of the installed systems, and it's possible many people install their engines w/out root access. In that case, they can't even write in places that might otherwise be attractive.

Finally, although I run many engines in linux, I don't run any of them through a GUI. For connecting to an ICS, they don't need a GUI. Only if some human wants to see what's up graphically does he need anything like that-- and he certainly doesn't care about engine config in that case because he's just watching an engine that is already running perfectly.

[zamar]

I like the idea you proposed.

To keep it simple for engine developers, could we keep the number of mandatory fields at minimum, something like:

Name = Fruit
Game = Chess
Protocol = UCI
Command = fruit

Then one could define a long list of optional fields (and reasonable defaults)...

For GUI Specific options, it might be natural to use <GUI>.<option> = value, like

XBoard.cmdargs = -foo
SCID.cmdargs = -bar

/usr/share/games/engines/ looks like the best directory for me.

[zamar]

I like the idea in principle-- however it's somewhat of a chicken/egg problem. What engine will support some new standard that no GUI currently has, and vice versa. Without getting all the major GUI programs onboard, it's all academic.

If we get XBoard and SCID to support this, others will surely follow...

Also, various distros have substantially different root filesystem structures. It could be very difficult to find a suitable location that spans even 80% of the installed systems, and it's possible many people install their engines w/out root access. In that case, they can't even write in places that might otherwise be attractive.

- I think /usr/share is pretty standard location for every normal Linux-distro.
- It's very difficult to install anything if you don't have root access, so I don't think that this is an issue.

[hgm]

To keep it simple for engine developers, could we keep the number of mandatory fields at minimum,

Sure. Every field would have a default, which would be used if it as not present. So effectively only for commands for which the default is bound to be wrong (line Name) would be mandatory.

something like:

Name = Fruit
Game = Chess
Protocol = UCI
Command = fruit

To allow for multi-protocol engines, which could require different commands to start in either protocol (e.g. gnuchess --uci vs gnuchess) I would prefer to combine Protocol and Command into one option, and allow to have more than one.

An alternative could of course be to have the engine drop several files in the engine directory, one for each protocol it supports (named gnuchess.uci and gnuchess.xb, say. I would not want to put any restrictions on naming, but we would have to make sure different packages would use different names.

Then one could define a long list of optional fields (and reasonable defaults)...

For GUI Specific options, it might be natural to use <GUI>.<option> = value, like

XBoard.cmdargs = -foo
SCID.cmdargs = -bar

/usr/share/games/engines/ looks like the best directory for me.

[hgm]

You mean that the engines should send those lines at startup?

No, I mean the package installer should install a file in /usr/share/games/engines that contains those lines, when people install the engine.

[hgm]

Does this facility already exist in windows? I don't recall anything like that.

No, it doesn't.

I like the idea in principle-- however it's somewhat of a chicken/egg problem. What engine will support some new standard that no GUI currently has, and vice versa. Without getting all the major GUI programs onboard, it's all academic.

We can start with XBoard, and the maintainers for engines that have Linux packages will probably be happy to add such a file to the package.

Also, various distros have substantially different root filesystem structures. It could be very difficult to find a suitable location that spans even 80% of the installed systems, and it's possible many people install their engines w/out root access. In that case, they can't even write in places that might otherwise be attractive.

The differences aren't a problem. In Makefiles you can use symbolic representation of system directories like $(datadir) in Makefile.am. So someone building from source would automatically install in the place that is good for his distro. And maintainers of binary packages would know how to generate packages from those Makefiles, as such packages are usually distro-specific.

Finally, although I run many engines in linux, I don't run any of them through a GUI. For connecting to an ICS, they don't need a GUI. Only if some human wants to see what's up graphically does he need anything like that-- and he certainly doesn't care about engine config in that case because he's just watching an engine that is already running perfectly.

So what? There are also people that would never read the man page of an engine. Yet man files are included in almost every package. Because some people do read them...