gtp

gtp@lists.lysator.liu.se

164 discussions

Interrupting commands
by Markus Enzenberger 14 Oct '02

14 Oct '02

Hi, I met a problem that occurs when using GTP with a GUI. Sometimes it is necessary to interrupt certain commands like genmove. For example you could want to have your Go engine search for a move for an unlimited amount of time until you (interactively) stop the search. Similarly, if the time limit for searching a move is set to a high value and you played a wrong move, there is no way to interrupt the engine and undo it, you have to wait until the engine returned from genmove before doing that, which can take a long time. First I thought I could work around this by making the engine handle a SIGINT for interrupting long searches. GoGui uses this approach and defines a GTP extension command gogui_sigint to query the engine at startup, if it can handle SIGINTs, so that it does not terminate engines, that do not handle SIGINT, accidentally. However, this approach has 2 drawbacks: - Signals are not very portable. - Does not work, if the engine runs on another computer and GTP is used over socket streams. So here is my proposal how to extend GTP: - The allowed characters includes the ascii control character ETX (03). - This character is usually ignored and filtered out of the input stream. The example implementation gtp.c gets a new function int gtp_interrupt() which can be polled by the Go engine during search. It checks the next character of the input stream for ETX and puts it back, if it is another character. I know this extension sounds a little ugly, but it is the best solution for the problem I could think of. Any comments or other ideas? - Markus

1 0

Second revision of GTP draft
by Gunnar Farneb�ck 12 Oct '02

12 Oct '02

I've put up a second draft for GTP version 2 on the GTP web page, http://www.lysator.liu.se/~gunnar/gtp/ Like the previous version this is available in HTML, postscript, pdf, and LaTeX formats. The postscript and pdf versions are strongly recommended if you want to print it and probably also for online reading. The HTML version is passable but looks worse and has a couple of defects. If you want to quote or comment parts of the draft the LaTeX source is preferrable. There is also a diff of the LaTeX files available for those who want to see exactly what has changed. This draft is mostly complete, in the sense that almost all sections are filled with text. Undoubtedly there is still need for some further revisions though. /Gunnar

1 0

Suggestions for the next draft of the GTP version 2 spec
by Andrew Derrick Balsa 09 Oct '02

09 Oct '02

Hi, I would like to make a few suggestions for the next draft of the GTP version 2 spec. Just my $0.02: a) For consistency reasons, is it possible to rename showboard to show_board? There is already clear_board. b) In section 6.2 Protocol Subsets, could we add subsection 6.2.3 Debug? That would be: --------------------------------------------- 6.2.3 Debug The debug subset adds the commands: show_board --------------------------------------------- c) In subsection 6.2.2 Regression, I would suggest the addition of: get_random_seed, set_random_seed Both commands are already implemented in GNU Go and I assume most, if not all engines would introduce a degree of randomness based on a seed. An engine that does not use pseudo-randomness (?) should output 1 for the get_random_seed command and save the parameter of the set_random_seed command in an otherwise unused variable, returning it if requested by the get_random_seed command. d) For the showboard (or show_board) command, I would like to suggest the following description: * show_board arguments none effects none output the board in human-readable format. See Gnu Go output for example. fails board not cleared comments This command should fail if sent before the board is properly initialized (i.e. using the clear_board command). e) I had some doubts about whether Wallyplus should output the string "pass" or "resign" when it wants to pass. In the end, I implemented "pass", even though I was under the impression that the present spec is "resign". I would be grateful if this issue could be clarified (in the genmove command description). f) Is there a command that tells GNU Go to **explain** why it generated a specific move? Could such a command be included in the protocol? That would be in the Debug command subset, I believe. It could be something like: * comment_last_move arguments none effects none output reason, explanation or comments about the last move generated by the engine. fails no move generated comments This command should fail if sent before the engine is asked to generate any move. Returns an empty string if the engine cannot or does not want to comment its move. I guess that last suggestion could be the matter of some debate, so I would like to explain why I am making it. Wallyplus can output a few lines of comments for every move it generates. I could save these comments in a string variable and just output them as a reply to the above command. It could prove quite useful to understand why an engine makes a particular move, without actually using a debugger while the engine is playing. Again, these are just my $0.02. Please take with a ton of salt, flames to /dev/null, etc. Greetings, -- Andrew D. Balsa andrebalsa(a)mailingaddress.org

3 6

stderr
by A van Kessel 08 Oct '02

08 Oct '02

Please reread my response and the gtp-drafts carefully. The overall design philosophy of GTP is: keep it simple, small and extensible. Only the commands that are common to all implementaions (those needed to make the program play a game) are standardised. Others can be introduced as an extension, and if they become usefull (and their semantics have cristallised ...) they could be added to a newer version of the standard. It is perfectly legal to add private commands. The line-oriented protocol makes it very easy to ignore these commands. Most programmers don't want to create/maintain a gui for debugging purposes. Too error-prone ... Most programmers don't want to support debugging commands (or their output) from *other* programs. To me, the cheapest way to implement debugging is to just dump it to stderr (or a logfile, or both) For me, even fitting the debugging output into the GTP-format ( avoid \n\n ...) is too much work. BTW please don't top-post. Don't cite the message entirely, without responding to it. AvK

2 1

stderr
by A van Kessel 07 Oct '02

07 Oct '02

IMO debugging commands are not needed in the protocol. Everyone can add his/her extensions. A program is free to send output to files/pipes/network -connecions, if it wants to. Or stderr. But stdin/stdout are supposed to obey the standard, which basically says: one line commands -->> responses, ended by empty line. BTW. I have been working on a NNGS<-->gtp gateway which can be controlled via nngs talk/tell. It could dump it's stderr to a NNGS channel (which could be restricted to the operator) In gunnar's case, this is of course nonsense -controlling a machine that is located on his desk via NNGS- , but it is an elegant way to interact with a *playing* go- playing-program. (it *could* be used for cheating: the turk on the desk :-)) AvK

3 2

connecting a go engine to IGS following the gtp rules
by Harsh Aggarwal 04 Oct '02

04 Oct '02

Hi, I have recently designed a go engine that follows the GTP protocol. But I dont know how to connect it to the IGS/ NNGS servers. Can some one help me out. Is there a graphical interface to connect the GTP supporting go engines with IGS servers. Please email me at harsh(a)usa.com Harsh Aggarwal harsh(a)usa.com

2 1

Wallyplus: a GTP version 2 compliant lightweight Go engine
by Andrew Derrick Balsa 27 Sep '02

27 Sep '02

Hello! I have been working on a C++ rewrite of the original wally.c, with a GTP version 2 interface. I have called it Wallyplus. The project has reached the point where wallyplus can play a game against gnugo, using a slightly modified version of the twogtp.py script. I have just uploaded the tarball for the source on ibiblio.org and it should be available within 24 hours: wallyplus-0.1.tar.gz (508K). I am looking for a mirror also. The Python script is called twogtp1or2.py. It can relay commands between GTP version 1 or 2 engines (it uses the prococol_version command to determine which protocol the engine supports). It is included in the wallyplus tarball in the subdirectory Documentation. I have also fixed a small bug in the original script. I don't know if Wallyplus is a worthy opponent to Gnu Go 3.3x, but it plays very quickly and it's interesting to see the two engines battling it out. I would be very interested in your comments and criticism, and I would like to thank Gunnar Farneback for his work on the draft Specification version 2. The specification is very clear and neat and this made the implementation much simpler. Best regards, -- Andrew D. Balsa andrebalsa(a)mailingaddress.org

1 0

GTP command syntax
by David Weiss 24 Aug '02

24 Aug '02

In section 3.3 of the GTP specification version2, draft 1, it is stated that id is an optional field of a command. It seems to me that requiring the id field would not only make parsing easier, it would also greatly simplify the work of a Go engine that plays multiple games simultaneously. I would suggest making id a required field if that does not cause major backward compatibility problems.

2 1

Re: gtp digest, Vol 1 #60 - 1 msg
by William M. Shubert 06 Aug '02

06 Aug '02

On Tue, 2002-08-06 at 03:00, Gunnar Farnebäck wrote: The free handicap commands place_free_handicap and set_free_handicap let you do exactly this, so I suppose you're just opposed to including a fixed_handicap command in the protocol? Sorry, I guess I wasn't clear. I think that "fixed_handicap" implying certain locations for the stones is a terrible mistake; having the command isn't a mistake, just the way it is defined. Better would be to have the locations of the stones explicitly stated, possibly as part of the "fixed_handicap" command ("fixed_handicap 2 d4 q16" for example) and possibly as one or more followup commands (which was my original suggestion, to follow "fixed_handicap 2" with 2 "move b" commands). My suggestions for changing the way that "place_free_handicap" and "set_free_handicap" were just suggestions that I thought would simplify the command set a bit, they aren't nearly so important. That was the worst case scenario. A cleaner solution is to just add a time_system command. A time_system command would be a decent way to allow multiple time systems. Maybe add it now, with "time_system canadian" as the only defined variant, so that programs written now won't freak out later when the command is used?

1 0

Re: gtp digest, Vol 1 #58 - 1 msg
by William M. Shubert 05 Aug '02

05 Aug '02

On Fri, 2002-08-02 at 03:00, gunnar(a)lysator.liu.se wrote: Bill wrote: > KGS does indeed implement free handicaps for Chinese and New Zealand > rule sets and players are using it. It seems to me that the GTP handicap > system is both complex and restrictive. Why not just have a "handicap > <n>" command, which specifies the handicap; then for fixed handicap, > follow that with a series of "play b <location>" commands; for free > handicap, follow the "handicap" command with a series of "genmove b" > commands? It may look simpler but in reality it just exchanges extra commands for higher complexity in other commands. With this construction one would need to have a state keeping track of the number of remaining handicap stones and also specify how to handle, alternatively explicitly forbid, surprising things like mixing play and genmove commands while doing handicap or undoing a couple of handicap stones. > That seems simpler to implement and more flexible, I don't agree. Both when I consider implementation for engines (in particular GNU Go) and controllers, I prefer to handle the whole set of handicap stones as a unit. > because now the arbiter in a game can do the handicap any way it > seems right, the protocol no longer forces a particular handicap > placement system. I don't see where this additional flexibility comes in, except maybe that the controller would be able to place white stones and call them handicap stones. Please give an interesting scenario which my proposal doesn't handle. For flexibility, specifying exactly where handicaps stones go means you can do handcaps not predicted in advance. For example, if you want to do h-5 on a 12x12 board, you don't need to specify as part of the protocol where exactly the 5th stone goes. This means that any handicap setup that an arbiter program wants to use can be done, no need to have the knowledge of this setup in the GTP programs. You can try fixed H-27 on a 19x19 and again, the program authors don't need to program in where all 27 stones go; you just make an arbiter than puts the 27 stones where you think they go, and then *any* GTP program will work fine - they just put the stones where they are told. Another form of flexibility is working with other software. Different internet servers put handicap stones in different places. Specifying exactly where stones go in the protocol means you just can't play handicap games on all servers - even if you get it working on one server, on another you won't be compatible. A last issue, not in flexibility but in removing potential (and probably likely) errors is the need for all GTP implementations to agree on where handicap stones go. The SGF protocol originally did this, and it turned into a nightmare because it was so hard to keep all programs in agreement. Yes, SGF specified that H-3 are placed at positions in corners "a", "b", and "c", leaving "d" blank, but it was so easy for programmers to accidentally leave "c" blank instead of "d", and it was so hard to detect until incompatible SGF files started floating around. SGF files now have "H-3, add black stones at these three locations", which is much easier > Another thing that really stood out to me as troublesome (other than the > protocol telling you where your handicap stones have to be) is the > "time_settings" command. It only supports canadian time and it is not > very extensible. Canadian is AFAIK only common on the IGS/NNGS/etc. go > servers, nowhere else in the world is it the dominant go clock system, > so making it the only time system for GTP seems bizarre. I can say with certainty that Canadian byo yomi is used in all Swedish tournaments. From google searches I get the impression that it is also the dominating time system in the rest of Europe and North and South America. Maybe someone else can comment on that. It is also used at the World Amateur Go Championship. Ah, I have never played go in Sweden. But I can assure you, in the USA at least, Canadian is rare. I have played at many tournaments both in the Northwest corner of the USA and at the annual Congress, and have never even heard of a canadian byo-yomi game in a tournament. All have been either Japanese byo-yomi or fixed time. > At the very least shouldn't there be an argument specifying the time > system? For example "time_settings canadian 30 10 25". Then in later > versions of the GTP spec if necessary we can add "time_settings > japanese" or "time_settings ing" or whatever and it will cleanly fit > alongside the older canadian system. If needed this can be solved anyway, in the worst case by deprecating "time_settings" and introducing one or more new commands. But one should think twice before adding more time systems. As an engine writer I'm not thrilled by the prospects of implementing and maintaining multiple clock systems. Maybe this is easier if the engine is designed to handle time issues from the beginning, but for GNU Go time management is quite complex. So you would rather plan on deprecating a command than make the command extendible? Seems like a foolish decision to me. The nice thing about adding the "canadian" word now is that you don't have to maintain multiple time systems if you don't want to. If you only understand canadian time, and see "time_settings japanese 120 30 5", you just return an error, because you don't understand Japanese. If all GTP tournaments stay with absolute time controls (or canadian), then fine, people who only want to be in tournaments can write code that understands only "canadian" and "absolute". But if you want your client to be able to play against people using other time controls, it would be nice for the protocol to be able to cleanly allow client writers to do so. Deprecating a command and replacing it is *not* clean. PS - I apologize for my last post being in mixed HTML and text. It's so embarassing to forget to switch for a mailing list, makes the digest so ugly. :-(

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
17
Older →

Jump to page:

2025

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