gtp November 2001

gtp@lists.lysator.liu.se

3 participants
3 discussions

GTP and Gothic
by Tanguy Urvoy 28 Nov '01

28 Nov '01

Hello, I accept your decision not to include a "dump" extension to avoid a break in the protocol. For the same reason, the first version of Gothic will only use GTP 1.0 commands. Gothic will also include a GTP shell for non standard commands like dump board or list_stones :) -- ---------------------------------------------------- Tanguy Urvoy http://www.irisa.fr/prive/Tanguy.Urvoy/ ----------------------------------------------------

1 0

Re: [gnugo-devel] GTP extension for passive GUI
by Daniel Bump 28 Nov '01

28 Nov '01

Tanguy Urvoy has been advocating an extension to the GTP. The place for this discussion is the GTP list, not the GNU Go list. The proposal being discussed is at: http://www.irisa.fr/prive/Tanguy.Urvoy/gnugo/tanguy-3.1.15.1 See also http://mail.gnu.org/pipermail/gnugo-devel/2001-November/000650.html In http://mail.gnu.org/pipermail/gnugo-devel/2001-November/000656.html Tanguy wrote: > I admit that the list representation is good for certain things like > listing the stones of a dragon or giving the list of best moves. > I also admit that everything can be done with list of positions, > but please also consider the other approach. We can do three things: (1) Disallow this change; (2) Allow it but consider it a GNU Go extension; (3) Allow it and make it to be part of the protocol. Gunnar doesn't like this because it is inconsistent with the overall approach of the protocol. Also, Tanguy's reasons don't seem convincing to me. I'll comment on those below. That said, there seems to be no real harm to exercising option (2) above, adding it but considering it a GNU Go extension. However that would mean that the client you write works with GNU Go but not other GTP engines. However is (2) really an option? Other client writers will discover that by making a nonstandard protocol extension they can use GoThic which will create pressure to break the standard leading to a fragmented protocol. I stated that Tanguy's reasons don't seem convincing. > - To keep a humand readable format. > (this is one the GOALS of GTP to be human readable and this is why > people prefer C language to assembly language). We can get an image of the board using the showboard command. It comes over stderr so as not to pollute the stdout channel. It does not show which moves are illegal, and that might be a nice extension. It is not designed for communicating with a client. > - To reduce the traffic in the pipe. This was a goal with the gmp but never with the gtp. > - To use an easy to parse format (no need to use bison nor flex) Both formats are very easy to parse. GNU Go does not use bison or flex to parse the GTP. You are talking about a few lines of C code. > - To use an easy to extend format What extensions do you have in mind? > - To use a color independant representation of legal moves. > ('.' is legal for all, 'x' only for black and 'o' only for white) This point is somewhat valid. Basically the advantage I see to your format is that it makes it harder for the engine to produce inconsistent data. One might imagine a bogus engine returning a list of vertices to the commands list_stones_black, list_stones_white, all_legal_black, all_legal_white which do not represent a valid board. Tanguy's format would make inconsistent data easier to detect. But that doesn't seem an adequate reason to me. Dan

1 0

Reciprocal Links
by Gloria 26 Nov '01

26 Nov '01

1 0

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 November 2001