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?
Proposal for Linux engine standard
Moderators: hgm, Rebel, chrisw
-
- Posts: 27807
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
-
- Posts: 1822
- Joined: Thu Mar 09, 2006 11:54 pm
- Location: The Netherlands
Re: Proposal for Linux engine standard
You're writing this proposal just for yourself?hgm wrote: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?
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.
-
- Posts: 27807
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Proposal for Linux engine standard
I never run engines on Linux. Let's see who bad your counting is, by how many will post here...
-
- Posts: 6401
- Joined: Thu Mar 09, 2006 8:30 pm
- Location: Chicago, Illinois, USA
Re: Proposal for Linux engine standard
You mean that the engines should send those lines at startup?hgm wrote: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?
There are certain things that could be deal with the option feature, right?
Miguel
-
- Posts: 373
- Joined: Thu Aug 14, 2008 3:21 am
- Location: Albuquerque, NM
Re: Proposal for Linux engine standard
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.
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.
-
- Posts: 613
- Joined: Sun Jan 18, 2009 7:03 am
Re: Proposal for Linux engine standard
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.
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.
Joona Kiiski
-
- Posts: 613
- Joined: Sun Jan 18, 2009 7:03 am
Re: Proposal for Linux engine standard
If we get XBoard and SCID to support this, others will surely follow...bnemias wrote: 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.
- I think /usr/share is pretty standard location for every normal Linux-distro.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.
- It's very difficult to install anything if you don't have root access, so I don't think that this is an issue.
Joona Kiiski
-
- Posts: 27807
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Proposal for Linux engine standard
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.zamar wrote:To keep it simple for engine developers, could we keep the number of mandatory fields at minimum,
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.something like:
Name = Fruit
Game = Chess
Protocol = UCI
Command = fruit
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.
-
- Posts: 27807
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Proposal for Linux engine standard
No, I mean the package installer should install a file in /usr/share/games/engines that contains those lines, when people install the engine.michiguel wrote:You mean that the engines should send those lines at startup?
-
- Posts: 27807
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: Proposal for Linux engine standard
No, it doesn't.bnemias wrote:Does this facility already exist in windows? I don't recall anything like that.
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.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.
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.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.
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...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.