Fulvio schreef op 11/27/2014 10:43 AM:
> Let's go back to the interface i suggested as an example.
> You can rewrite your AutoInstall function like this:
>
> std::string AutoInstall (const std::string& lastTimeStamp)
> {
> //TimeStamp may be a string composed by
> numberofengines_timeofthelastengineinstalled
> std::string timeStamp = AutomagicalEngine::getTimeStamp();
> if (lastTimeStamp != timeStamp) {
> auto available_engines = AutomagicalEngine::getEngines();
> //I think that all the engines available should be returned
> //InstallNewEngine should check if the engine is already
> registered (maybe the user did it manually)
> for (auto& e : available_engines) { // for each
> InstallNewEngine(e.getExecutable(), e.getDir(),
> e.getVariants(), e.getProtocol());
> }
> }
> return timeStamp;
> }
>
OK, clear. It could be made a parameter to the 'get' routines whether
you want to have all available,
or just the new ones (e.g. pass a maximum age).
Letting InstallNewEngine refrain from adding the engine when it is
already there is also what I do
in XBoard, but only if it is installed in exactly the same way.
(Otherwise it would not recognize it
as the 'same engine'.) This would for instance happen when you updated,
say Crafty. You would
already have the previous version of Crafty in your engine list from a
previous automagical install,
but as all versions have the same command, that entry would now
automatically use the updated
Crafty, and there is no reason to add anything. When a 'custom install'
would have existed for the
old crafty (e.g. specifying parameters on its command line that are
non-standard), it would not be
recognized as the same, and a new crafty line with standard settings
would be added.
There is one risk in always asking for all engines: suppose an engine
gets installed that the user
does not want. (He might not be the only user of that machine.) SCID
would see it is not in its
list of registered engines, and prompt the user if it should be added,
and he presses NO. Fine.
(In XBoard it would always be added, and the user would delete it. Also
fine.) Now next time he
starts SCID / XBoard, these see again that same engine, still not being
registered. So they prompt
the user (or let him delete the unwanted engine) again. After this
happend 20 times, that user
will get pretty annoyed... So it is important that the GUI remembers
which engines were already
rejected by each user, and the simplest way to do that is by remembering
the date when the
user last looked.
>
> c++ provide automatic memory management and encapsulation, but the
> same thing can be written in c too (like gtk_widget for example).
>
> Now suppose that you change the .eng file format and add some other
> information, like the engine version.
> You will add a new function to the interface:
> std::string getVersion();
> but all the implementation details, like parsing the .eng file for the
> new format (still need to support the old one, the new getVersion
> function will return an empty string for old eng files) will be
> encapsulated inside the library. If the GUI is not interested in the
> new information there is nothing to change: copy & paste the updated
> library and you have automatic support for the new format.
OK, clear. That sounds straightforward enough. For the returned lists,
would you just
want a string where all data fields are separated by newlines, or an
arry of (char*) ?
>
> About Stockfish: i agree with their point of view.
> They support a wide range of platform, compilers, linux distro:
> implementing your protocol in the makefile will be a nightmare (just
> think about how many linux distro on how many platform need to be
> tested every time you'll change something in the protocol).
Not really. They could just keep using the previous version of the
protocol. And testing doesn't seem the right approach. When you make a
change in SCID's UCI driver, do you test it with every UCI engine in
existence? Or do you just make sure it complies with the UCI specs? And
it seems to me that in the case of "make uninstall" for a software
package with a single file there is nothing to test... I don't see the
'nightmare'. In the Makefile you add two lines to your 'install:' target
install -d -m0755 $(DESTDIR)$(prefix)/share/games/plugins/uci
cp misc/engine.eng $(DESTDIR)$(prefix)/share/games/plugins/uci
and you are done. If you feel very insecure you could run the "make
install" once to see if you get an error message because of a typo, and
if the file appears in the intended place for the distro you are using.
That doesn't sound very nightmarish to me. If an extension of the
standard allows you to also specify a source and version number, you
decide if you are interested to support that in the first place. If not,
you don't change anything. If it was what you always wanted, you add a
line with the version number to the .eng file. Now what would there be
to test, after you cat/typed the file once more on your display to check
if you used your editor properly and the version number is as you
intended? Whether there exist distros where the 'cp' command would
correctly copy a 3-line file, but would crash on a 4-line file? Even if
there were, I would think it is their problem, and not my task to debug
their "cp" or provide work-arounds for it using other commands.
> On the contrary the debian maintainer (for example) need to worry only
> about testing the changes on debian for the platform he is building
> the package for.
> When Steve Jobs returned to Apple it famously reduced the product
> number to 4: you need to focus if you want to create the best.
> Stockfish became the strongest chess engine by trimming all the
> unnecessary fat: the time a developer spend on working and testing
> this protocol is time that he could have spent improving the engine.
Well, focusing on one or a few products is imo not the same as saying
that you cannot be bothered any more to ship your product, and that
anyone who wants to buy it would have to come to the factory himself, to
nicely wrap it in paper, pack it in boxes to become transport-proof, and
carry it away. And then supply it without an instruction guide,
insisting that all retailers should write their own, after figuring out
for themselves how the product works. I somehow doubt that Apple would
have been very succesful if they had adopted that policy.
The focussing argument becomes a bit weak anyway, on an open project
where people are lining up to contribute. I am pretty sure there are
plenty of people that are not programmers and would be willing to write,
say, a decent man page for Stockfish, without putting any burden on
those working on the aspects that deserve focus. So what is the harm in
letting them do it? Why should they be burned at the stakes for even
offering it?
H.G.
------------------------------------------------------------------------------
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
