Fulvio schreef op 11/26/2014 4:08 PM: > In your previous post you talked about apt-get, so i believed that we > were talking about distro packages. > For example when you install scid on a debian machine with: > sudo apt-get install scid > the package manager suggest that you should install also some chess > engine (stockfish, crafty, etc...) but when you launch scid you still > need to add manually those engines, and that is bad. Indeed, this is what I would like to cure. It is not a big deal, but any progress counts. > I think it should be a maintainer task to create the .eng file (the > install script can be reused for all the chess engines in that distro > without the need to modify the source code or makefiles) and i believe > that a single conf file is a lot cleaner and not much more complicated. Well, I approached packagers too, if only for the reason that some packaged engines are no longer developed, so there is no one else that could do it. But my experience so far is that you strongly overestimate what they are willing to do. And not all engines for one distro are packaged by the same maintainer, and there are many distros, for most of which I don't even know the packagers. Logically, files (also install scripts) that are distro-independent (such as man pages) should be supplied by the engine developers, so that every distro can use them, rather than having to re-invent the wheel each one for themselves.
I have discussed this problem with Debina maintainers, and they assured me that editing common files is very undesirable, and told me the proper way to do this is post files, like the Application/*.desktop system. > But now you talk about makefile and i'm a little bit confused: have you > contacted for example stockfish authors? I don't believe they will ever > agree to change their makefile to implement this protocol. Yeah, you can say that again... It was a mistake to contact them, as they seem completely dillusional about modern software practices. They'd for instance rather die (and argue 1000+ lines over it) than add a make-uninstall to their Makefile, and now they even want to remove the make-install, because in their mind no one uses that anymore... Furthermore, letting the user 'register' the engine in the GUI by letting him browse to the engine binary is the only proper way to do it, and GUIs where it would happen automagically are broken by design, and their authors should go back to the drawing board... So for the time being we can forget about Stockfish. It should be treated as a "no-longer-developed" engine, patched further downstream. > > c is even more portable than c++ > Your code can be a starting point, but obviously requires some improvements: > - multi-platform (on Windows and Macs should compile and act like there > is no engine installed) Indeed, this is code that comes from an XBoard-only code section, not compiled for WinBoard. The code is already such that when the directory for the protocol doesn't exist nothing happens. > - should act like a library (just give to the GUI a list of the > available engines; than it can decide if ask the user to confirm, maybe > the engine was already installed by the user with custom options, etc). That makes sense. In XBoard I used the opposite approach, where it always installs, because (1) removing an installed engine there is just as easy as confirming the install of the new one and (2) I expected it to be much more common that the user would want the engine than that he already had made a custom install (which would not be overwritten anyway). But that is just a GUI-design issue; every GUI must be allowed do it in a way that is most suitable for it. Do you have any preference to the format of the list? Each entry would contain multiple infos, like startup command, working directory, protocol. Note that the idea is that only newly installed engines would be presented to the GUI, not engines that already were there last time the user started the GUI. So very often the 'list' would consist of only a single entry. > - how the GUI is informed that an engine was uninstalled? Good question. In XBoard I don't do that yet, because deleting engines by hand is so easy, and I wanted to be conservative in irreveribly altering the engine list, before I knew how much such a feature will in general be received. But it should of course be possible. This would mean that either the library would have to supply a complete list of every engine that is there, so that the GUI can cross-reference it with its own 'engine database' to see which one in there has disappeared from the machine, or convert its engine database to some standard list format that it could pass to the library, so that it can remove all engines from the list that are still there, and return the list with the engines that have disappeared. > - What's "settingsFile" ? If it's the list of all the engines, including > the one installed by the user, i could launch the GUI, keep it open when > i install a couple of chess engine in background with apt-get, manually > add another engine that is not present in the repository, and the > engines will never be automagically discovered. Also a good point. Indeed it is supposed to be the file containing all registered engine. (For XBoard this list goes together with all other settings in one file.) So the code should actually be called both when the GUI is started and when it is closed. Or the GUI should remember the time when it started, and save that later as a time stamp, so that in the next session it can compare the install time to that time stamp to decide if the engine has been seen already. > - should be stable and secure (you forgot to avoid fscanf buffer overflow) OK, thanks. I will fix that. 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 > ------------------------------------------------------------------------------ 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
