Sorry, pressend 'send' by accident on the previous message.
Fulvio schreef op 11/27/2014 4:24 PM:
> typedef int engine_handle;
> int SOMEPREFIX_getEngines(engine_handle*, int max_handles, time_t
> after_timestamp);
>
> and use it like this:
> engine_handle engines[100];
> int n_engines = SOMEPREFIX_getEngines(engines, sizeof engines / sizeof
> engine_handle, 0);
> // if (n_engines < 0) something went wrong, report an error or simply
> ignore autoinstall?
> for (int i = 0; i < n_engines; i++) {
> InstallNewEngine(SOMEPREFIX_getExecutable(engines[i]), etc..);
> }
>
I see. Although in the implementation I had in mind the array engine[i]
would simply get filled with 1, 2, 3...
and would thus seem a needlessly complex way of writing i+1 (or i),
which you have to declare as well.
>
> Let's assume that you send a patch for stockfish that implement the
> protocol.
> They accept your patch and it works fine on the major distributions
> (debian, ubuntu, fedora, arch, etc...).
> Than one day a chinese user decide that he want to try the strongest
> chess engine (that's why stockfish is different from less known
> engines) on his supercomputer (no intel arch, chinese charset, no
> standard linux directory tree) and the make install fails because of
> your patch.
> He contact stockfish authors and they do not even know what he is
> talking about, but fortunately they track down the patch and contact
> you: how do you solve the bug?
Well, I would say: "apparently your distro does not support the
auto-install standard / GNU Makefile standard". Complain to your distro
manager that he should obey standards.
What would you say when someone reported to you: "I installed this Chess
engine SMIRF in SCID, and whether I tick UCI or XBoard, it does not
work"? When you check the SMIRF README.txt it says that it communicates
in TMCI because UCI and XBoard are "not compatible". How would you solve
that 'bug'? And would the possibility that something like that could
happen deter you from supporting UCI and XBoard protocol?
> Will you say to him: you have a very unusual environment, bare with it?
> You'll start messing around with the makefile to exclude all the
> possible peculiar systems?
The make-install only includes two lines, an "install" command to create
the directory, and a "cp" command to copy the file there. So the only
way that it could not work is that these commands don't exist, or that
the pathname contains characters that are invalid on the system.
Non-standard command naming could even be guarded against by making them
symbolic, $(COPY) and $(INSTALL), like the Makefile already uses $(CC)
for gcc. If someone would say "the pathname is not understood, because
for my filesystem '/' is a command separator, and in pathnames I need
'\' to separate the directory levels", I would say he is not using Linux
but MS-DOS. But I still don't see why messing with the Makefile to
exclude MS-DOS would be helpful in any way. So he gets some error
message during "make install", like "cp: not found". So what? That is
not a bug. It is an accurate diagnostics message of the situation. I
couldn't improve on it anyway.
If his problem is that the GUIs of his disto are all patched to not look
in "/usr/local/share/games/plugins/uci", but instead in
"/blup/blip/blap/bloop"... Well, then it is the GUI part of the
auto-registration that fails to observe the standard, and he should
complain to the GUI packagers. I would not see that as a reason to adapt
my Makefile. If people want to break standards, they should not be
surprised that the things for which the standard was developed don't
work anymore. I don't see that as any different from getting a complaint
"I have this GUI, but Stockfish hangs in it because the GUI does not
send "position fen" or "position startpos", but just "fen", and in stead
of "moves" it sends "game so far:". Should the idea that this might
happen, and that you would then have to completely rewrite your UCI
driver to recognize that GUI, and understand the non-compliant commands
it spews out, deter you from making your engine use UCI, and integrate
it with its own GUI? I wouldn't think so. No mercy for non-compliance!
Let them use the InBetween adapter if they insist on using such a
non-compliant GUI.
> I do not think that's the ideal solution, especially if you consider
> that we are not even talking about a stockfish feature.
> We are talking about providing the list of chess engines installed in
> a linux distribution, and that's why in my opinion it should be
> maintained by the distro and not by chess engine developers.
> (the chinese user will never encounter the problem because if he
> installed stockfish from a package it must work, otherwise the
> packager would have noticed; and if he installed stockfish from source
> the protocol is not even there).
Well, for distros that want to redefine standards, and patch their GUI
packages accordingly, you are completely right, of course. Then their
engine packagers should patch the Makefiles of engines in their source
packages as well, to conform to their own standards. And it would give
problems for their users that want to load the latest source from
Stockfish git repository and automatically install that. I would
consider that their problem, self-inflicted by choosing a distro with a
loose attitude to standards. Btw, for a properly written Makefile, this
would not be much of a problem anyway, just an inconvenience. (It would
be 5 lines in stead of 2, though):
plugindir = $(prefix)/share/games/plugins/uci
COPY = cp -u
INSTALL = install -d -m0755
install:
...
$(INSTALL) $(plugindir)
$(COPY) misc/stockfish.eng $(plugindir)
The guy with the non-compliant directory name should now simply run
"sudo make plugindir=/blup/blip/blap/bloop install". It is what the
packagers for that distro would do (automated or not) in the process of
creating their packages. He'd better get used to that if he wants to
install engines from source. But if he doesn't, I would certainly not
see that as a reason to touch my Makefile. Because it contains already
all the handles needed to solve every conceivable sort of
non-compliance. (Non-standard naming of the commands, non-compliant
protocol directory.) That is where my task as developer stops.
Regards,
H.G.
> Bye,
> Fulvio
>
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
Scid-users mailing list
Scid-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/scid-users
