UCI extension: nodestime

[hgm]

Anyway, Polyglot, which already supported XBoard's nodes-based TC by using "go nodes", with nodes quota it calculated itself from the TC mode and time left on the clocks to bypass the engine's own time management, will now relay the nps value to engine as the new setting of the UCI_PlayByNodes option on engines that support an option with this name. For engines that don't support it, it would continue to use the old "go nodes" method.

Source (as usual) in the hgm.nubati.net source repository ("learn" branch!).

[Rein Halbersma]

Wow, a seemingly interesting discussion with well written arguments exchanged, and then, boom, two oneliners that completely escalate things. Why??

[hgm]

Because on some people reason just does not have any effect, or even a counter-productive effect. See for instance
https://groups.google.com/forum/#!topic ... vP3sRszzbA[1-25] for how the Stockfish team typically responds to expert advice of respected programmers tgat try to be helpful. (Copy-paste the link, as the forum software truncates it.)

[Daniel Mehrmann]

Because on some people reason just does not have any effect, or even a counter-productive effect. See for instance
https://groups.google.com/forum/#!topic ... vP3sRszzbA[1-25] for how the Stockfish team typically responds to expert advice of respected programmers tgat try to be helpful. (Copy-paste the link, as the forum software truncates it.)

Hmm, there is nothing wrong with your linked thread. The sf team has a unique viewpoint and sometimes you have to accept it easly.

I think your gui <-> engine detection idea is simply bad. Probably you never looked around what other unix applications does in such cases. There are some good solutions already which should work for xboard too.
Maybe a conf.d for xboard.conf would be the best. No need for a new folder struct or changed makefiles.

Regards,
Daniel

[Michel]

[. Probably you never looked around what other unix applications does in such cases.

You should do your homework. Dropping a file with metadata in a known location is standard practice for unix installers. See for example

/usr/share/applications/

[Evert]

Because on some people reason just does not have any effect, or even a counter-productive effect. See for instance
https://groups.google.com/forum/#!topic ... vP3sRszzbA[1-25] for how the Stockfish team typically responds to expert advice of respected programmers tgat try to be helpful. (Copy-paste the link, as the forum software truncates it.)

Hmm, there is nothing wrong with your linked thread.

You have got to be kidding me.

The sf team has a unique viewpoint

Some members of said team also have a rather unique way to present their viewpoint and argue their case. I've seen more reasoned arguments from my four-year old son than some of the tripe in that thread.

I think your gui <-> engine detection idea is simply bad. Probably you never looked around what other unix applications does in such cases.

Care to provide some links? I mean, clearly your google skills are superior here, so enlighten us.

There are some good solutions already which should work for xboard too.

The point is that this is not for XBoard. If it's just about XBoard, I agree, there are a dozen different ways to handle this, and it's not up to engine developers to support any particular GUI. The point is to have a way to announce the availability of an engine to any GUI on the system (that supports the way to do this). If you have a different way of doing that than dumping the information in a well-defined location in a system-wide database (which in practice means dumping a text file in a directory), do tell.

Maybe a conf.d for xboard.conf would be the best. No need for a new folder struct

Yeah, that'd work fine. For XBoard. Again, that's not the point.

[hgm]

I think your gui <-> engine detection idea is simply bad. Probably you never looked around what other unix applications does in such cases. There are some good solutions already which should work for xboard too.
Maybe a conf.d for xboard.conf would be the best. No need for a new folder struct or changed makefiles.

Btw, the thread was not so much about the the general standard for GUI-engine recognition, but whether Stockfish should (continue to) provide an install target in their makefile, or whether it would be better to have "the Debian maintainers to get off their lazy arses, and let them finally do their job of figuring out how the software they package should be installed without any help from the developers". (Title of the discussion: "What is the use of make-install") And of course about the claim that Stockfish needed no packaging for Linux distributions anyway, because it was not a GUI. "Unique viewpoint" is a very nice euphemism for "dillusional", though.

And, on the topic of GUI engine recognition: can you explain us why it would be a good idea when programs like SCID, PyChess, ChessX would have to look in an xboard.conf file for knowing what to do? What if XBoard would not be installed on the system?

[Daniel Mehrmann]

The sf team has a unique viewpoint

Some members of said team also have a rather unique way to present their viewpoint and argue their case. I've seen more reasoned arguments from my four-year old son than some of the tripe in that thread.

I think it's still okay and there are no personal attacks. If you want a comparison you should take hgm and not you. He complained about the thread and i think you know hgm is no child of sadness.
In germany we just say: "Wer austeilt, muß auch einstecken können." (I find no real translation for that)

Of course this is a solution for xboard and all other gaming plattforms. Every application does this on that way. It's just a suggestion and if you don't take it, it's not my problem

can you explain us why it would be a good idea when programs like SCID, PyChess, ChessX would have to look in an xboard.conf file for knowing what to do? What if XBoard would not be installed on the system?

Hmmm, do you really think all these apps should take a look xboard.conf ?
Do you think the earth is a slice ?

no regards
Daniel

[hgm]

can you explain us why it would be a good idea when programs like SCID, PyChess, ChessX would have to look in an xboard.conf file for knowing what to do? What if XBoard would not be installed on the system?

Hmmm, do you really think all these apps should looking for xboard.conf ??

I don't, but you seem to think so. Perhaps you should explain us your idea better, how you think that when a programmer creates a new engine X, what he must do to make that engine automagically would appear in the list of engines people can select from in XBoard, ChessX, SCID, PyChess, etc., for the people that have taken the trouble to download and install his engine?

Btw, your remark about "no personal attacks" seems to miss the point rather widely: I posted the link not as an example for personal attacks, but for how the Stockfish team deals with arguments and reason.

[Daniel Mehrmann]

I don't, but you seem to think so. Perhaps you should explain us your idea better, how you think that when a programmer creates a new engine X, what he must do to make that engine automagically would appear in the list of engines people can select from in XBoard, ChessX, SCID, PyChess, etc., for the people that have taken the trouble to download and install his engineu?

Okay, you've proven that you don't take care of unix "standards" so far. Well, that's basicly not bad, nobody knows everything of course, but at this point you should take your time to learn more about the "conf.d" idea. But instead of showing that, you asking me to tell you the things are going. No and no. I'm not supporting such kind of lazy handling. I'd like to see first that you learn more about the unix world. After that you can come back and ask me if you need so, but i guess you don't need it, because you understand it already.

Btw, your remark about "no personal attacks" seems to miss the point rather widely: I posted the link not as an example for personal attacks, but for how the Stockfish team deals with arguments and reason.

Nope, i missed nothing.