Don Dailey drd@supertech.lcs.mit.edu writes:
However, I'm not sure whether error messages need to be standardized.
I agree 100% with this.
By the way, "not_implemented" is not an error message, it's a legitimate response that does NOT indicated an error. It's a way of saying, "I have not implemented that command."
There has been a tremendous amount of resistance to adding even very simple commands, the main argument being that it's extra work to implement more than the very most basic 4 or 5 commands. Having a set of standardized error codes for each command is certainly not very compatible with this philosophy.
It may not just be that it seems to be too much work. Another problem is that requiring that engines implement apparently simple commands is that they may constrain the engine to work in certain ways. Implementing lots of commands just because they are trivial in some implementations does not necessarily mean they will be easy in all possible implementations.
As I think I've mentioned before, it was a long, long time before gnugo implemented undo. The priority was on getting a strong go-playing engine rather than making a good user experience. Of course, it's different now...
It's not impossible to imagine an engine with so much complex state and cache information that undo is simply not possible, other than by going back and regenerating the moves from scratch.
Incidentally, I can't remember the current state of things, but IIRC, there were proposals to separate the commands to generate a move from committing that move. So the contoller would ask the engine for its move, then tell the engine later to place a move, which would usually be the move the engine asked for.
ISTR that one objection to *not* having undo was that it could destroy an engine's incremental state by clearing the board and playing all the previous moves.
However, could it not be argued that asking for the engine to make a move without allowing it to update its state has just the same effect ?
Apologies if you've all moved on from here...
And FWIW, one nice feature of the smtp/http response scheme is that you can distinguish success/temporary failure / permanent failure without needing to understand the text of the message. Just the first digit is enough. If we are using plain text responses, perhaps we should use a standard textual prefix (OK, WARN, ERROR, ...) in a similar way. So then even if the exact text of the response is not understood, the controller knows if the engine is reporting an error or not.
dd
I think there are about 4 commands that should be included in any protocol no matter what. Why can't the rest be up to the go engine programmers to implement? We can define a reasonable set of very useful commands and you can just return "not_implemented" if your engine cannot deal with this. I can't see why this should be viewed as unreasonable.
Consider:
1. 'unmove'. Big deal. Don't implement it. You can still use the Gee Whiz super duper interface and it just says "Sorry, this command unsupported by engine." No big deal.
2. 'version' If this taxes the ability of programmers to implement, the Gee Whiz super duper interface returns, "unknown version." Why is this a big deal?
3. 'setup' Don't implement it. The engine will work with any tools that don't care about setup. The programmers know which ones these are. The Uber Interface will say, "Sorry, not implemented" but not stop you from using the other features.
If I write the "problem tester" tool, you won't be able to get along without "setup." (I'm sorry, there is no way around this for you minimalist's.) But as I'm starting to understand, this is pretty difficult for most of you to implement, so the solution is simple, don't implement it unless you want to.
4. 'time_control' Again, big deal. You can implement this to default to a single level (no matter what is selected), or just not bother. A full featured interface will function without it, and the programs that do have this implemented will benefit.
5. 'komi' So what if an engine doesn't have the ability to be told what komi to use? The end user will have to configure the engine with some default komi. If you try to change it, the engine reports "Sorry, cannot change komi for engine: unknown version"
Every command is like this. You either implement it, or you don't. You can be as lazy as you want to be. There is no virtue in defining a tiny set that isn't capable of anything, and not being able to write very useful tools just to be able to make it really easy to implement the whole set!
There is very little that will stop any tool from begin written or designed as long as it support the 4 basic commands "genmove_white, genmove_black, white and black." Let everything else be optional. I don't think the issue is to try to force people to implement things they don't want, the REAL issue is how do we prevent people from implementing a bunch of non-standard commands jsut to support very basic features.
Don
Cc: william.newman@airmail.net, gtp@lists.lysator.liu.se From: Dave Denholm dave.denholm@insignia.com
Don Dailey drd@supertech.lcs.mit.edu writes:
However, I'm not sure whether error messages need to be standardized.
I agree 100% with this.
By the way, "not_implemented" is not an error message, it's a legitimate response that does NOT indicated an error. It's a way of saying, "I have not implemented that command."
There has been a tremendous amount of resistance to adding even very simple commands, the main argument being that it's extra work to implement more than the very most basic 4 or 5 commands. Having a set of standardized error codes for each command is certainly not very compatible with this philosophy.
It may not just be that it seems to be too much work. Another problem is that requiring that engines implement apparently simple commands is that they may constrain the engine to work in certain ways. Implementing lots of commands just because they are trivial in some implementations does not necessarily mean they will be easy in all possible implementations.
As I think I've mentioned before, it was a long, long time before gnugo implemented undo. The priority was on getting a strong go-playing engine rather than making a good user experience. Of course, it's different now...
It's not impossible to imagine an engine with so much complex state and cache information that undo is simply not possible, other than by going back and regenerating the moves from scratch.
Incidentally, I can't remember the current state of things, but IIRC, there were proposals to separate the commands to generate a move from committing that move. So the contoller would ask the engine for its move, then tell the engine later to place a move, which would usually be the move the engine asked for.
ISTR that one objection to *not* having undo was that it could destroy an engine's incremental state by clearing the board and playing all the previous moves.
However, could it not be argued that asking for the engine to make a move without allowing it to update its state has just the same effect ?
Apologies if you've all moved on from here...
And FWIW, one nice feature of the smtp/http response scheme is that you can distinguish success/temporary failure / permanent failure without needing to understand the text of the message. Just the first digit is enough. If we are using plain text responses, perhaps we should use a standard textual prefix (OK, WARN, ERROR, ...) in a similar way. So then even if the exact text of the response is not understood, the controller knows if the engine is reporting an error or not.
dd -- dave.denholm@insignia.com http://www.insignia.com
Don wrote:
I think there are about 4 commands that should be included in any protocol no matter what. Why can't the rest be up to the go engine programmers to implement? We can define a reasonable set of very useful commands and you can just return "not_implemented" if your engine cannot deal with this. I can't see why this should be viewed as unreasonable.
Consider:
- 'unmove'. Big deal. Don't implement it. You can still use
the Gee Whiz super duper interface and it just says "Sorry, this command unsupported by engine." No big deal.[Snipped.]
Enough. You are repeating yourself. We don't need any more recapitulations of these arguments.
/Gunnar
From: Gunnar Farnebäck gunnar@lysator.liu.se
Don wrote:
I think there are about 4 commands that should be included in any protocol no matter what. Why can't the rest be up to the go engine programmers to implement? We can define a reasonable set of very useful commands and you can just return "not_implemented" if your engine cannot deal with this. I can't see why this should be viewed as unreasonable.
Consider:
- 'unmove'. Big deal. Don't implement it. You can still use
the Gee Whiz super duper interface and it just says "Sorry, this command unsupported by engine." No big deal.[Snipped.]
Enough. You are repeating yourself. We don't need any more recapitulations of these arguments.
/Gunnar
No thank you. The GTP standard is something that I expect to affect myself and the whole computer Go community in significant ways. Since this list is for discussing these ideas, no one needs to be silenced by you.
When you actually break it down, the idea of several individual command sets really boils down to something very close to the idea you want to stop discussion on:
. Aggregated together, we indeed have one larger set.
. Programmers WILL implement what they want and won't care how you or me decide to partition them as long as it does what they want.
Don
-
Dave Denholm -
Don Dailey -
Gunnar Farneb�ck