gtp August 2001

gtp@lists.lysator.liu.se

20 participants
58 discussions

RE: [gtp] GTP Goals, ver. 2
by Cabrera, Alan 13 Aug '01

13 Aug '01

Good point. I'll return to my lurking status. Regards, Alan -----Original Message----- From: Daniel Bump [mailto:bump@match.Stanford.EDU] Sent: Sunday, August 12, 2001 5:15 PM To: gtp(a)lists.lysator.liu.se Subject: Re: [gtp] GTP Goals, ver. 2 Alan Cabrera wrote: > Why not use XML as a basis for GTP? It could handle: > > 1) Private extensions by using namespaces > 2) Newline conventions would be no longer an issue GTP is not XML. If you want to develop an XML based protocol please don't call it GTP. We would object if the name GTP is applied to something too different from what is already implemented and in use. The purpose of this list is to standardize the GTP, not to dream up something different. Daniel Bump _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp

1 0

Re: [gtp] GTP Goals, ver. 2
by William M. Shubert 12 Aug '01

12 Aug '01

For UTF-8 vs. ascii, the beauty of it is that ASCII is a subset of UTF-8 and all non-ascii characters show up as strings of bytes >127 in UTF-8. That means that having the base command set in ASCII but comments in UTF-8 lets people write 100% ASCII lexers if they want, and they only need to worry about UTF-8 if they have non-ascii comments coming in. If they don't care about non-ascii comments looking garbled, then they can write a purely ascii parser and everything works fine. For XML, my question to you is: how would XML be better than what people are talking about now? XML has a few definite drawbacks (XML is much more complex than what has been discussed here so far, so you would need to use an XML library to parse GTP, and integrating another library into your program always requires more time and work). Usually XML's benefit is that you can deduce the structure of your communication without knowing anything about the content, but in the case of GTP, how would that make our lives any easier? Cabrera, Alan wrote: >What was wrong with my idea of using UTF-8 instead of ASCII? Also, what >about XML? Do you have any thoughts on this or am I way out in left field? > > >Regards, >Alan > >-----Original Message----- >From: William M. Shubert [mailto:wms@igoweb.org] >Sent: Sunday, August 12, 2001 2:15 AM >To: GTP Mailing List >Subject: [gtp] GTP Goals, ver. 2 > > >OK, there were some good suggestions, here's take 2 on the GTP goals. My >thoughts... > > * I think a minimal command set is absolutely necessary, but I > clarified the bullet for what most people seem to think is the > need: tournaments. If we leave all things optional, I can see one > programmer saying "Hmm, I don't ever do undos, I can leave that > command out", then if in a tournament an undo is needed (due to > operator error entering a move or some such), one of the programs > is totally screwed. We 100% need to say "you MUST implement these > commands to play in GTP tournaments." > * I clarified many of the points to say more precisely what they mean. > * I added "additional programs that would be nice but aren't > necessary for GTP to be usable" because lots of people were > suggesting programs they wanted to see written. > * I left in the requirement for GMP vs. GTP tournaments. I also see > this as necessary, because we don't want to force all old programs > to get GTP front ends, and we want to let GMP and GTP programs > participate in tournaments together. > * A few items added that people recommended, such as have GMP be > able to do general interfaces. (Seems like a really good idea, > that way one front end can be used by several programs, letting > programmers spend more time on their algorithm and less on front > end programming.) > * Some people were bringing up commands that they wanted, I left all > them out of this document. That belongs in the spec, not in the > goals document...I want the goals to be just what we want to do > with GTP and what we need to do to be successful, not include info > on how GTP will work. > >Well that's enough babbling. Here's the next version of the goals >document. Again, all comments are welcome! >************************ >GTP Goals version 2 > >Part I - Functional Requirements. These are the actions that our command >list must allow go programs to perform. > > 1. Usable to play games vs. other programs head to head. If the protocol > requires some kind of arbiter, that's OK, but see III.1. > 2. Usable for regression tests on programs. > 3. Usable for playing go on a server. > 4. Usable to write full featured interfaces. > >Part II - Implementation Goals. Constraints that we must follow when >designing the exact command list. > > 1. Simple to implement, debug and understand; all commands are ASCII, > all human text (comments etc.) is UTF-8, exactly one line per > command, each command gets an exactly one line response. > 2. Possible to create bridges that let GMP programs play head to head > vs. GTP programs in tournaments. Note that GTP and GMP will not > necessarily have the same feature set - just the possibility of > playing against each other is necessary. > 3. There must be a minimal command set that is exactly enough > commands to play head to head tournament games, no more no less! > All commands required for regression tests or server play should > be optional extensions that programmers need not implement. > 4. It should be possible to design software that gracefully deals > with unimplemented GTP commands/features. > >Part III - Necessary Auxiliary Programs. These are programs that we (the >GTP designers) must write for GTP to be successful. All must be open source. > > 1. An example program that implements the minimal GTP command set > properly and can play a legal game (similar to the goDummy program > for GMP). > 2. An arbiter to be used in head-to-head games, communicating to both > programs, judging legal/illegal rules, etc. Should the arbiter > know how to score a game? > 3. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play > against each other. > >Part IV - Additional Programs. These are programs that are not necessary >for us to call GTP "done" but would be useful to have publicly available. > > 1. A sample GTP program that understands all of the commands. > 2. GTP bridges for various servers. > 3. GUIs and other human-usable front ends so that programmers who > write GTP programs can automatically play against their programs, > query their programs as to evaluations, etc. > 4. A GTP test system/test library to determine whether or not a > program is emitting legal GTP. > >************************ > -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>

1 0

GTP Implementation
by Phil 12 Aug '01

12 Aug '01

I'm making my Go Text Protocol (GTP) over TCP/IP implementation available to those who are interested. You may download it from: http://www.tgiphil.com/ComputerGo/GTPImplementation.htm

1 0

Why not XML?
by Cabrera, Alan 11 Aug '01

11 Aug '01

Why not use XML as a basis for GTP? It could handle: 1) Private extensions by using namespaces 2) Newline conventions would be no longer an issue Alan > Alan Cabrera > Multex.com, Inc. > 100 William Street, 6th Floor > New York, NY 10038 > mailto:adc@multex.com > http://www.multex.com > Tel: 212-607-2422 > Fax: 212-607-2410 > > This email message is for the sole use of the intended recipient(s) and > may contain confidential and privileged information. Any unauthorized > review, use, disclosure or distribution is prohibited. If you are not the > intended recipient, please contact the sender by reply email and destroy > all copies of the original message. > > Any views expressed in the email message are those of the individual > sender except where the sender specifically states them to be the views of > Multex.com, Inc. >

2 1

Goals of GTP?
by William M. Shubert 11 Aug '01

11 Aug '01

Hello everybody. One thing that I haven't seen discussed yet is the exact goals of GTP. It probably seems obvious to everybody what these goals are, but perhaps not everybody's view is exactly the same, so I think it would be good if we could put together a goals document that we can all agree on. Then when we discuss features and commands, we can always refer back to the goals document and use it to help us decide whether or not these commands fit our goals well. Maybe we could even put the goals document on the "lists.lysator.liu.se" web site? In any case, it seems like it would be nice to have a place where more or less permanent documents that we have already agreed on are kept. Anyway, here's my first attempt at a goals document. It's a combination of what I think are goals and what I have seen discussed here in the past week or so. ********************************************************************* GTP Goals Part I - Functional Requirements. These are the actions that our command list must allow go programs to perform. 1. Usable to play games vs. other programs head to head. 2. Usable for regression tests on programs. 3. Usable for playing go on a server. Part II - Implementation Goals. Constraints that we must follow when designing the exact command list. 1. Simple to implement and debug; all ASCII. 2. Possible to create bridges that let GMP programs play head to head vs. GTP programs. 3. There must be a minimal command set that is exactly enough commands to play head to head, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement. Part III - Necessary Auxiliary Programs. These are programs that we (the GTP designers) must write for GTP to be successful. All must be open source. 1. An example program that implements the minimal GTP command set properly and can play a legal game (similar to the goDummy program for GMP). 2. An arbiter to be used in head-to-head games, communicating to both programs, judging legal/illegal rules, etc. Should the arbiter know how to score a game? 3. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play against each other. ********************************************************************* So what does everybody think? Anything I left out/shouldn't have included/got wrong? PS - Hopefully this message will make it to the mailing list in plain text - I think my mailer is set up properly, but I may have made a mistake that will make it send HTML mail. My apologies if this happens, I'll make sure to fix it if it does. -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>

6 7

Terminology
by Phil 11 Aug '01

11 Aug '01

I am drafting up a standards documents and have a terminology question for the group. The GNU description of GTP calls party A the arbiter or relay, and party B the engine. To simplify the terminology I want to call party A the controller, where the controller can be a GUI, an arbiter or relay. Sound reasonable?

1 0

RE: [gtp] Goals of GTP?
by Cabrera, Alan 10 Aug '01

10 Aug '01

Concerning Part II, item 1. Do you plan on players being able to send comments back and forth? If so, then maybe UTF-8 may be better. Alan -----Original Message----- From: William M. Shubert [mailto:wms@igoweb.org] Sent: Friday, August 10, 2001 10:40 AM To: GTP Mailing List Subject: [gtp] Goals of GTP? Hello everybody. One thing that I haven't seen discussed yet is the exact goals of GTP. It probably seems obvious to everybody what these goals are, but perhaps not everybody's view is exactly the same, so I think it would be good if we could put together a goals document that we can all agree on. Then when we discuss features and commands, we can always refer back to the goals document and use it to help us decide whether or not these commands fit our goals well. Maybe we could even put the goals document on the "lists.lysator.liu.se" web site? In any case, it seems like it would be nice to have a place where more or less permanent documents that we have already agreed on are kept. Anyway, here's my first attempt at a goals document. It's a combination of what I think are goals and what I have seen discussed here in the past week or so. ********************************************************************* GTP Goals Part I - Functional Requirements. These are the actions that our command list must allow go programs to perform. 1. Usable to play games vs. other programs head to head. 2. Usable for regression tests on programs. 3. Usable for playing go on a server. Part II - Implementation Goals. Constraints that we must follow when designing the exact command list. 1. Simple to implement and debug; all ASCII. 2. Possible to create bridges that let GMP programs play head to head vs. GTP programs. 3. There must be a minimal command set that is exactly enough commands to play head to head, no more no less! All commands required for regression tests or server play should be optional extensions that programmers need not implement. Part III - Necessary Auxiliary Programs. These are programs that we (the GTP designers) must write for GTP to be successful. All must be open source. 1. An example program that implements the minimal GTP command set properly and can play a legal game (similar to the goDummy program for GMP). 2. An arbiter to be used in head-to-head games, communicating to both programs, judging legal/illegal rules, etc. Should the arbiter know how to score a game? 3. A GMP-to-GTP bridge to allow GMP programs and GTP programs to play against each other. ********************************************************************* So what does everybody think? Anything I left out/shouldn't have included/got wrong? PS - Hopefully this message will make it to the mailing list in plain text - I think my mailer is set up properly, but I may have made a mistake that will make it send HTML mail. My apologies if this happens, I'll make sure to fix it if it does. -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/> _______________________________________________ gtp mailing list gtp(a)lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp

1 0

Minimal GTP command set
by Phil 10 Aug '01

10 Aug '01

So far the minimal GTP command set includes: Boardsize Komi Fixed_Handicap White Black Genmove_Black Genmove_White Undo (* provisional for now) Quit What else?

6 13

RE: [gtp] GTP: making the command set smaller
by Peter.Smith＠Smallworld.co.uk 09 Aug '01

09 Aug '01

> There need never be a command to load an SFG file, because that can > and should be implemented by interface software. As long as there is > some way to set up the position or game, we are ok. > > Don > As I understand it GTP as GnuGo use it currently contains a load SGF file command which means the engine has to understand SGF. So it is reasonable to consider setting things like boardsize by sending the SGF token SZ[] to do it rather than having an explicit GTP command. But when I get to the point of needing to write GTP handling I'll be happy to run with whatever the consensus is providing there's enough functionality, and there is a way to connect GTP and GMP together. Peter. > From: Peter.Smith(a)Smallworld.co.uk > > I'm some way off doing anything with GTP yet so this is > rather commenting > from the sidelines. > > GTP has a command to load a SGF file? Suppose GTP had a > command to pass SGF > elements to an engine like "KM[5.5]" ? Would that remove > the need to have > certain commands as you could pass them as the SGF equivalent? > > I think having a GTP to GMP bridge will be important. > Otherwise if I write > a Go program having a GTP interface isn't going to be > enough to play > matches. Should GTP have equivalents for the main GMP commands? > > Peter Smith. > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp >

2 1

GTP: making the command set smaller
by Peter.Smith＠Smallworld.co.uk 09 Aug '01

09 Aug '01

I'm some way off doing anything with GTP yet so this is rather commenting from the sidelines. GTP has a command to load a SGF file? Suppose GTP had a command to pass SGF elements to an engine like "KM[5.5]" ? Would that remove the need to have certain commands as you could pass them as the SGF equivalent? I think having a GTP to GMP bridge will be important. Otherwise if I write a Go program having a GTP interface isn't going to be enough to play matches. Should GTP have equivalents for the main GMP commands? Peter Smith.

2 1

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