Re: [chessx-developer] auto-install of engines on Linux

[Kamil R. <kry...@gm...>]

Hello,

I was already talking (before question entering this list) about this with
Mr. Muller.
I wish it wasn't intact to share my ideas from my private mail. I'm
encouraged by the fact that Jens raised the same objections.

Please see my comments below.

With regards,

2014-11-15 9:00 GMT+00:00 Jens Nissen <jen...@gm...>:

> Dear Mr. Muller,
>
> generally, your idea sounds feasible and easy enough to implement.
>
> I have a few comments:
> 1) ChessX tries to support all three major OS with the same features, so I
> would like engine vendors
> to provide installation information as described in the folder for
> GenericData, which would be
> Mac OS X: "~/Library/Application Support", "/Library/Application Support"
> Windows: "C:/Users/<USER>/AppData/Local", "C:/ProgramData"
> Linux: "~/.local/share", "/usr/local/share", "/usr/share"
> and from there .../games/plugins/uci/<vendor> and ..../xboard/<vendor>
> respectively.
>
>
NetBSD (pkgsrc) adds /usr/pkg/share or any defined --prefix by a user, eg.
in unprivileged mode ~/pkg/share. But the general rule stands for default
directories.


> 2) Your description format would require a dedicated (if simple) parser
> while most development environments support
> either parsing XML or ini-file syntax.
> In this case, I would prefer ini-file syntax, so I think, the eng file
> would better look like this:
> [installation]
> name=Stockfish-5-32 (missing in your description)
> plugin spec=0.0
> command=stockfish
> cd=<installation path>
> variants=chess,chess960
> Using ini files would make import more or less a one-liner in C++.
>
> 3) If I remember correctly, the file suffix .eng was used by Chessbase for
> some engines or engine loaders.
> At least, I remember seeing such files in a Chessbase directory, I
> actually never looked into the file
> if it was a binary or a text file. So using *.eng could confuse users.
>
>
I had the same objections.
A custom format is always tentative to implement (kind of
not-implemented-here syndrome), but it leads to maintainability burden in
long-term (for users and vendors). And in my humble opinion this case is
not worth to reinvent the wheel.

.eng remains me commercial format for binary chess-engines for Windows, I
would pick-up plain INI or .conf. In reality I wouldn't look inside a file
without suffix .ini or .conf..

My new thoughts:
There is already case with polyglot (uci->xboard protocol translator)
configuration resulting in yet another configuration for a simple chess
engine. For me it's already overkill and it's worth to merge polyglot
options into this new configuration file.... It was already overkill to
write (or locate...) some polyglot config when I wanted just to play a few
games for fun...

As I'm not an ambitious player anymore I push the wood just to take the
rest, so any kind of extra thinking or remembering is unwilling ;-)

I see no reason to place engine-configurations in different places
categorized by type of engine, why not just a single one? ... xboard
doesn't make me thinking of a protocol version but a a GUI (even if I used
to know this protocol as I wrote a private chess engine in the past...).

A chess engine is in reality a plain process parsing input stream and
producing output. Please keep it as simple as possible. Users and
power-users don't want to learn new config formats, custom locations, know
that there is a thing like polyglot (for me fruit was just broken...).

So my whisper is to merge polyglot (or UCI native reader) into
xboard-protocol chess engines consumers, even if it's beyond the scope of
this talk and mark the protocol version in the ini config.


> Kind regards,
>
> Jens Nissen
>
> BTW: From
> https://sourceforge.net/p/chessx/feature-requests/
> the button "Create Ticket" creates a change request.
>
> Am 15.11.2014 um 00:13 schrieb H.G. Muller <h.g...@hc...>:
>
> > Dear ChessX developers,
> >
> > sorry that I contact you this way; I could not figure out how to use the
> > sourceforge trackers to submit a feature request.
> >
> > I am the current developer of XBoard, and I am trying to set up a system
> > for Linux to eleminate the need for users to 'install' engines that are
> > already installed by the package-managinging system into the GUIs where
> > they want to use them (as is also needed in ChessX through the
> > Edit->Preferences->Engine tab). The system is very simple, and I hope
> > that ChessX would implement it too.
> >
> > The idea is that engine packages, as part of their install, would drop a
> > small file in a system standard directory reserved for the particular
> > protocol the engine speaks. E.g. Stockfish would drop a file
> >
> > /usr/[local/]share/games/plugins/uci/stockfish.eng
> >
> > A UCI-supporting GUI would then scan this directory for *.eng files to
> > know what UCI engines are currently installed, and from the modify date
> > of the file it could see when it was installed. As it also knows the
> > modify date of its own settings file that contains its engine list, it
> > can know if the engine is newly installed or has been seen before. If it
> > is new, it can add it to the list (possibly under control of a user
> > option to switch such auto-installs on or off).
> >
> > To add it to its engine list, it would of course need to have some info
> > that normally would be provided by the user that installs it. Such as
> > engine startup command (possibly including command-line arguments), and
> > the engine directory. (It would already know the engine is UCI, or it
> > would not have been in that folder.) This info comes from the contents
> > of the .eng file, which (for now) is just 3 lines:
> >
> > plugin spec 0.0
> > stockfish
> > chess,chess960
> >
> > The first line providing some version number that identifies the file
> > format (so that in the future it can easily be extended with more info),
> > the second line being the engine startup command to run it in the
> > applicable protocol, and the third line what games/variants it can play
> > (for now only chess and chess960 are defined). A GUI that only supports
> > Chess would obviously have to ignore any engine that does not list
> > "chess" on the third line.
> >
> > For engines that have to run in a specific directory a cd command to
> > that directory would be prefixed to its startup command on the second
> > line, like
> >
> > cd ENGINEDIR;ENGINECOMMAND
> >
> > This should provide the GUI with some minimal information needed to
> > append the engine to its engine list. I hope to extend the standard in
> > the future by also listing other info that could be relevant for the
> > GUI, e.g. known non-compliancies with the protocol for which the GUI
> > might have work-around options that could correct it. (E.g. when an
> > engine reports scores with the wrong sign when playing black.)
> >
> > For XBoard protocol (CECP) the corresponding directory would be
> >
> > /usr/[local/]share/games/plugins/xboard/
> >
> > Would you be willing to equip ChessX with such an auto-install system?
> > The incentive for engine authors to adopt this system will be
> > proportional to the number of GUI's that do so, and vice versa. So I am
> > trying to collect some critical mass to get it off the ground.
> >
> > Kindest regards,
> > H.G.Muller
> >
> >
> ------------------------------------------------------------------------------
> > Comprehensive Server Monitoring with Site24x7.
> > Monitor 10 servers for $9/Month.
> > Get alerted through email, SMS, voice calls or mobile push notifications.
> > Take corrective actions from your mobile device.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> > _______________________________________________
> > chessx-developer mailing list
> > che...@li...
> > https://lists.sourceforge.net/lists/listinfo/chessx-developer
>
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> chessx-developer mailing list
> che...@li...
> https://lists.sourceforge.net/lists/listinfo/chessx-developer
>