gtp

gtp@lists.lysator.liu.se

164 discussions

Re: computer-go: gnugoclient 2.0
by Gunnar Farneb�ck 05 Aug '01

05 Aug '01

Don wrote: > And even if an engine doesn't keep track of the moves, > the driving program could use gtp commands to reset the > state and replay the moves..? > > It's my opinion that this would be poor engineering, a bad way to > implement takeback. This absolutely requires something in the minimal > protocol a lot more complicated that "undo." I'm really against the > idea of requiring a GUI to perform this complicated operation in order > to trick a program into taking back a move. No, this doesn't require anything extra in the protocol, only that the GUI keeps tracks of the moves that have been made. The "black" and "white" commands suffice to set up a position. > Also, some programs will lose important state if the position is just > reset as if it's from a completely different game. Even though this > can be preserved by making the engine more complicated, it's a pretty > ugly hack and the goal is to simplify the engine, not complicate it. > And what if the engine is keeping a log of the game? Is it to view > this a brand new position? This on the other hand is a valid point. My opinion is that the first revision of the GTP needs to be split into one minimal set, containing the absolutely necessary (*) commands for making it useful for tournament kind of use, and an extended set with useful but less critical commands that would be good to standardize early. Undo doesn't get into the first group but well into the second. This message is cross-posted to the computer-go, gnugo, and gtp lists. From now on I will continue discussion about gtp only on the latter list. Those who want to take part in this should subscribe to the gtp list, see http://lists.lysator.liu.se/mailman/listinfo/gtp It's also possible to follow the discussion through the list archive, available from the same page. Currently the list is configured to allow posting from non-members, but this may change later (i.e. if necessary for spam reasons). /Gunnar (*) Plus some completely trivial ones like name and version.

2 1

Re: [gtp] Re: computer-go: gnugoclient 2.0
by Gunnar Farneb�ck 05 Aug '01

05 Aug '01

> I agree there should be an "undo", or as I call it, a "takeback" command. At > worse, the GTP (server) can respond with an "not implemented" error message. Undo is the better name. > Also, we need a way to determine if a command is implemented. I was thinking > that a command prefixed by a question mark, like "[id] ?[command]" would > return either a successful response "=" if implemented, otherwise a "?" if > not. No need for such special cases. This could easily be implemented within the standard syntax with a command "is_implemented" taking a command name as argument. But I think a better solution is to have a command "known_commands" which would return a list of all the known commands, just like the GNU Go "help" command works. > I also think it would be valuable to define a way to pass back error and > status codes, and not just a success or failure and an results or error > messages. We could implement this as an optional field; a number before the > result or error message, prefixed with a colon. I was thinking the the > response format could be: "=[id] [status code]: [result]" or "?[id] [error > code]: [error message]". I have not put too much thought into this, so > feedback would be helpful. Keep the protocol simple! Unless someone can convince me that this really is necessary I'm strongly against it. /Gunnar

1 0

Re: computer-go: gnugoclient 2.0
by Phil 05 Aug '01

05 Aug '01

I agree there should be an "undo", or as I call it, a "takeback" command. At worse, the GTP (server) can respond with an "not implemented" error message. Also, we need a way to determine if a command is implemented. I was thinking that a command prefixed by a question mark, like "[id] ?[command]" would return either a successful response "=" if implemented, otherwise a "?" if not. I also think it would be valuable to define a way to pass back error and status codes, and not just a success or failure and an results or error messages. We could implement this as an optional field; a number before the result or error message, prefixed with a colon. I was thinking the the response format could be: "=[id] [status code]: [result]" or "?[id] [error code]: [error message]". I have not put too much thought into this, so feedback would be helpful. Phil ----- Original Message ----- From: "Heikki Levanto" <heikki(a)lsd.dk> To: <computer-go(a)lists.uoregon.edu> Sent: Friday, August 03, 2001 10:18 PM Subject: Re: computer-go: gnugoclient 2.0 > On Fri, Aug 03, 2001 at 05:03:14PM -0400, Don Dailey wrote: > > Whether a program has "undo" or not isn't really a big deal. But in > > my opinion the real issue is getting this very basic feature > > documented right away. > > A standard is complete not when there is nothing to add, but when there is > nothing to remove! > > I do agree that it is important to specify the behaviour of the undo command > now, to avoid different implementations. But I also agree that the command > is of limited use, probably only in human-computer games, which is but one > use for the protocol. Thus I do not agree that "undo" must belong to the > minimal set of commands all programs must implement. > > Therefore I propose to add another set of commands, that are recommended but > not required. Currently this command would contain the undo command only, > but I can imagine we might want to add stuff later, for example time > controls, ruleset details, and what not. > > > Other recommendations for the standard. Discuss and discard at will. > - Three possible error responses: > - Unknown command > - Not implemented (like undo above) > - Parameter error (like playing outside the board) > - Naming convention for commands that are specific for debugging one > program, for example prefix by program name or abbreviation > (gg_owl_defend). Should we keep an "official" list of those prefixes? > > > Heikki > leaving for off-line vacation for a week > > -- > Heikki Levanto LSD - Levanto Software Development <heikki(a)lsd.dk> >

2 1

Test
by Gunnar Farneb�ck 03 Aug '01

03 Aug '01

Obligatory test to see whether the list is working and in particular whether the archive will be automatically created. /Gunnar

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

gtp