Crafty problem with cutechess-cli

[hgm]

The logic of that escapes me. You could as wel say that if the GUI is allowed to have a choice, the engine should honor it. Protocol v2 is a negociation between engine and GUI.

Fact is that the way the protocol is defined, the GUI has the last word (acepted / rejected).

The protocol specs don't say that a GUI has to implement every feature of a version to call itself that version. In fact it explicitly says that it doesn't. So a GUI that says protover 2 and subseqently rejects every feature is still perfectly compliant.

The only thing you can hold against it is that it is an incomplete implementation of protocol v2. But that just as much holds of an engine that does not implement the new command and needs a restrart in stead.

Incomplete engine and GUI implementations can be so incomplete in different ways that they no longer can correctly work together. That is the risk inherent in making incomplete implementations.

[michiguel]

The logic of that escapes me. You could as wel say that if the GUI is allowed to have a choice, the engine should honor it. Protocol v2 is a negociation between engine and GUI.

Fact is that the way the protocol is defined, the GUI has the last word (acepted / rejected).

The protocol specs don't say that a GUI has to implement every feature of a version to call itself that version. In fact it explicitly says that it doesn't. So a GUI that says protover 2 and subseqently rejects every feature is still perfectly compliant.

I was assuming from Bob's message that the GUI did not reject the feature, but now that I read the message again it is not clear whether it did or not. Yes, you are right, we need to know this.

BTW, I think that it would be better to have as default reuse=0 (do not reuse) rather than reuse=1, but I digress.

Miguel

The only thing you can hold against it is that it is an incomplete implementation of protocol v2. But that just as much holds of an engine that does not implement the new command and needs a restrart in stead.

Incomplete engine and GUI implementations can be so incomplete in different ways that they no longer can correctly work together. That is the risk inherent in making incomplete implementations.

[hgm]

Why do you think that? Reuse is more efficient (saving time on loading and initializing the code), so I think there is every reason to prefer that over the other when both are possible. And why should the superior mode not be the default?

There really is only one reason to want -xreuse:

It allows lazy programmers to spread around crappy code, and dodge accountability for it.

I don't think that kind of behavior should be encouraged!

[bob]

That is a bit like a double-edged sword. Because you always do it this way you will never become aware of such bugs, and thus never correct them. You convict yourself to a life sentence of inefficient running out of fear for bugs that might not even exist, or would be trivially corrected when they do...

There are some "bugs" that are not worth the effort of fixing. In a program of nearly 50K lines of code, that is under development every day, making sure that "new" initializes every last thing that can be modified internally is a non-trivial task. And one that is done over and over and over and over. With a fixed number of hours in a day, I don't consider it lazy to simply choose to avoid the mess completely and say "for each game, restart the engine." This can be cleaned up on major release dates, which is why the winboard protocol has the reuse feature so that an engine can control this reliably, not to encourage laziness, just to encourage efficiency of development.

[Zach Wegner]

There are some "bugs" that are not worth the effort of fixing. In a program of nearly 50K lines of code, that is under development every day, making sure that "new" initializes every last thing that can be modified internally is a non-trivial task.

It should be very trivial if the program is designed properly.

[Matthias Gemuh]

There are some "bugs" that are not worth the effort of fixing. In a program of nearly 50K lines of code, that is under development every day, making sure that "new" initializes every last thing that can be modified internally is a non-trivial task.

It should be very trivial if the program is designed properly.

That does not apply to a long term project like Crafty, with its countless releases. Are you suggesting that Crafty 8.11 should have been designed in its time and C language standards to look like today's Crafty 23.0 or even better ?

[michiguel]

Why do you think that? Reuse is more efficient (saving time on loading and initializing the code), so I think there is every reason to prefer that over the other when both are possible. And why should the superior mode not be the default?

There really is only one reason to want -xreuse:

It allows lazy programmers to spread around crappy code, and dodge accountability for it.

I don't think that kind of behavior should be encouraged!

I agree with you, In fact I think there is no need to have in the protocol the reuse=0 option in first place. If you give the option, you are not encouraging anybody to reuse properly.

BUT, if the option is there, you tacitly acknowledge that if a valid alternative. Then, the more general choice should be the default based on universal design principles.
http://en.wikipedia.org/wiki/Universal_design.

Miguel

[Zach Wegner]

There are some "bugs" that are not worth the effort of fixing. In a program of nearly 50K lines of code, that is under development every day, making sure that "new" initializes every last thing that can be modified internally is a non-trivial task.

It should be very trivial if the program is designed properly.

That does not apply to a long term project like Crafty, with its countless releases. Are you suggesting that Crafty 8.11 should have been designed in its time and C language standards to look like today's Crafty 23.0 or even better ?

No, I'm suggesting Crafty in general should have been designed with some function that resets its state to the way it was before playing any games (but after reading options such as "do not create log files"). This is very simple stuff, that could be done before there was anything resembling a C language standard. Basic software engineering.

[Matthias Gemuh]

That does not apply to a long term project like Crafty, with its countless releases. Are you suggesting that Crafty 8.11 should have been designed in its time and C language standards to look like today's Crafty 23.0 or even better ?

No, I'm suggesting Crafty in general should have been designed with some function that resets its state to the way it was before playing any games (but after reading options such as "do not create log files"). This is very simple stuff, that could be done before there was anything resembling a C language standard. Basic software engineering.

Crafty can certainly do that. There's just no guarantee that that function in today's Crafty will reset _everything_ as Crafty 8.11 perhaps once did.

[krazyken]

It seems to me that "Log off" should be the default setting in Crafty.