gtp October 2002

gtp@lists.lysator.liu.se

7 participants
12 discussions

Re: interrupt
by Markus Enzenberger 29 Oct '02

29 Oct '02

William M. Shubert wrote: > There. Now much easier to see in logs, etc. Note that the server is > sending two text commands (genmove and abort) and it always gets two > responses, just like everything else in the GTP protocol. I don't see > any way that this would be harder than using a control character - the single character solution leaves the possibility open for a simple implementation on POSIX systems avoiding the need for a thread. You could use select, getc and putc to poll at certain times during your lengthy command and do a blocking read when waiting for the next real command. Putc allows you to put back only one character. (It does not work if there is still something in stdio's buffer, but this is no problem, since interrupting won't be used in batch mode anyway). I agree that interrupting the search does not make sense for all programs and should be optional. But at least for the two I am working with (NeuroGo and Explorer), it is useful. Maybe we should leave the possibility open if the program answers to an interrupted genmove with a move or an error. If the program does not handle interrupting, it will answer with a move anyway. For example GoGui does not have to know, if the answer will be success or error, it handles both cases correctly automatically, playing the move, on success and showing an error on failure. - Markus

1 0

Re: interrupt
by Markus Enzenberger 28 Oct '02

28 Oct '02

> * The 003 (control-C) character is used to indicate an interrupt. > * a program that does not implement the interrupt feature > can ignore the character. If the 003 character is encountered in > the middle of a (otherwise) valid commandline, the behaviour is > indefined. after reading the latest GTP draft again, I found that a Go program should ignore any control characters not used by GTP anyway, so the interrupting char could be an extension to GTP that should not confuse programs that don't understand it. GnuGo however, does no filtering of control characters so far. > * the aborted command should return an error status like > "?[%d] interrupted\n\n" This would not handle the commands where interruptig is most important correctly, like genmove. genmove should just return the best move found so far in the search. > * Like ordinary commands, the existence of the 003 feature can be > tested by "valid_command gtp_interrupt". I should also be > included in the output from the "list_commands" command. > > * Sending the gtp_interrupt command literally (as text) is allowed. > It should result in the same behaviour as a 003 character. Sending the control character is different from a command, since no answer is expected. I don't think that a command doing the same is useful, but it makes assigning answers to commands more difficult for the controlling program. My proposal is to use gtp_interrupt could to query, if the program really handles the interrupt, so that a GUI can disable its "Stop" button for programs that cannot handle it anyway. > * so, ^C is a bad choice. Any suggestions for an alternative > interrupt character? ESC, DEL, ^A, ^G ^X ^T come to mind. > ^G seems safe to me. Won't interfere with anything. Right, this problem exists. I was preferring ^C, since my program can handle SIGINT. If you are using GTP manually in the shell, the ^C is intercepted by the shell and the shell sends a SIGINT to the program. I thought it would be nice to have the same behaviour if you are using a raw stream. - Markus

2 1

Re: [gtp] interrupt
by William M. Shubert 28 Oct '02

28 Oct '02

I just don't understand the benefit of using a control character as the "break" code. If we agree that break is useful, then I think it should be readable text like the rest of the GTP protocol. For example, the word "abort". So if the server sends (the <id1> and <id2> are of course optional): <id1> genmove blah blah blah // server waits a while, then decides it doesn't need the genmove <id2> abort It will get one of two things back. If the client can handle "abort", and it gets the abort in time to cancel the genmove, then it will reply with: ?<id1> aborted =<id2> abort successful If the client doesn't handle abort, or it doesn't get the abort command in time, it will reply with something like: =<id1> <genmove result> ?<id2> can't abort There. Now much easier to see in logs, etc. Note that the server is sending two text commands (genmove and abort) and it always gets two responses, just like everything else in the GTP protocol. I don't see any way that this would be harder than using a control character - either way you need to use multithreading, signals, or polling to detect the abort/control character. Now, as for is this useful - I think it would be useful as an optional command. If GTP was letting a user play the computer, the user may decide to undo his move and play a different one - without abort, we would need to wait for the computer to finish deciding its move before it can recognize the undo and the alternate move and start coming up with its response. With abort, it will be much more convienient to the user. Because it may be difficult to implement, and is not needed for most GTP functionality, this command does have to be optional I think. On Sat, 2002-10-26 at 03:01, gtp-request(a)lists.lysator.liu.se wrote: Message: 1 Date: Fri, 25 Oct 2002 12:43:38 +0200 (CEST) From: A van Kessel <Adriaan.van.Kessel(a)rivm.nl> To: gtp(a)lists.lysator.liu.se Subject: [gtp] interrupt ... * so, ^C is a bad choice. Any suggestions for an alternative interrupt character? ESC, DEL, ^A, ^G ^X ^T come to mind. ^G seems safe to me. Won't interfere with anything. Does ring a bell, though ... Wake-up call! * In addition, I think there is a place for a similar interrup-feature, but using a signal (interrupt) instead of an in-band character. It could use the same semantics, but a different command name ("signal", "interrupt" ?), making it's implementation independent of the 003 feature. This *could* be useful for engines that don't like polling (but *do* support signals).

1 0

interrupt
by A van Kessel 25 Oct '02

25 Oct '02

After rereading Markus Enzenberger's gtp_interrupt proposal, I think there is a way to include it in GTP in a non-intrusive way, and I can agree with most of it. There are still some complications, which I'll discuss at the end. I 'll try to summarise what I understood it is supposed to be/do. ################################################ Semantics of the GTP-interrupt-feature : * The 003 (control-C) character is used to indicate an interrupt. * a program that does not implement the interrupt feature can ignore the character. If the 003 character is encountered in the middle of a (otherwise) valid commandline, the behaviour is indefined. * upon reception of a 003 character, a program that does implement the feature may (*or may not*) honor the interrupt by stopping it's current processing. * the aborted command should return an error status like "?[%d] interrupted\n\n" * if no command was currently executing, ... * Like ordinary commands, the existence of the 003 feature can be tested by "valid_command gtp_interrupt". I should also be included in the output from the "list_commands" command. * Sending the gtp_interrupt command literally (as text) is allowed. It should result in the same behaviour as a 003 character. ################################################ Discussion. * There is a possible collision here: In unix, the 003 character is (often) used as the interrupt character and translated by the line-discipline into an "interrupt" signal, which is sent to the process attached to the tty. Agreed, this complication is -strictly speaking- not in the GTP domain, but choosing 003 seems to be asking for problems (and confusion), which could have been be avoided. [ I can imagine the FAQ in the future: Q: ^C does not work, it aborts the program. A: stty intr ^G QQ: Huh ? ] * so, ^C is a bad choice. Any suggestions for an alternative interrupt character? ESC, DEL, ^A, ^G ^X ^T come to mind. ^G seems safe to me. Won't interfere with anything. Does ring a bell, though ... Wake-up call! * In addition, I think there is a place for a similar interrup-feature, but using a signal (interrupt) instead of an in-band character. It could use the same semantics, but a different command name ("signal", "interrupt" ?), making it's implementation independent of the 003 feature. This *could* be useful for engines that don't like polling (but *do* support signals). AvK

1 0

Re: interrupt
by Markus Enzenberger 16 Oct '02

16 Oct '02

> This forces the engine to poll the input stream and/or to use non-blocking > I/O. (BTW your method will fail if the 003 is not the first character in > the input stream.) I see that a gtp_interrupt() cannot be added as easily to gtp.c (which using blocking IO) as I thought. Or is there any way to check a blocking stream, if the next read would block? In principle the engine wouldn't be forced to poll the stream. If it doesn't support interrupting it would just eat up any ^C characters before reading the next command. If it does support interrupting, it still could use blocking I/O, (but would have to run it in a separate thread). ^C will always be the first character, since the controlling program can ensure that it does not send ^C in the middle of a command. > TCP/IP allows "out of band data" for this purpose. Telnet uses this > feature to deliver the ^C to the terminal-driver (which generates an > interrupt) I was thinking about this, but it does work only with TCP, not with any kind of stream. So there would be different methods of interrupting for local engines (run with exec from the GUI) and network connections. > Strictly speaking, this is not a text-command. > It will be hard to implement it in a portable way. Some engines Why? Transmitting the interrupt signal as a character over the regular GTP stream is the most portable thing I could think of. > may not like it. But maybe we should just standardise (some) of > the semantics, and leave the implementation to the engine/gtp-driver If the engine does not like it, it should ignore it and just eat all ^C characters before reading the next command. Maybe it would be sufficient if there is a standardized optional GTP command to query the engine, if it supports interrupting, so that the controlling program would use this feature only, if the engine supports it. - Markus

1 0

interrupt
by A van Kessel 15 Oct '02

15 Oct '02

Markus Enzenberger wrote: > Sometimes it is necessary to interrupt certain commands like genmove. ... > It checks the next character of the input stream for ETX and puts it > back, if it is another character. This forces the engine to poll the input stream and/or to use non-blocking I/O. (BTW your method will fail if the 003 is not the first character in the input stream.) TCP/IP allows "out of band data" for this purpose. Telnet uses this feature to deliver the ^C to the terminal-driver (which generates an interrupt) Strictly speaking, this is not a text-command. It will be hard to implement it in a portable way. Some engines may not like it. But maybe we should just standardise (some) of the semantics, and leave the implementation to the engine/gtp-driver - programmer. Given the OOB nature of the command, it's syntax already is standardised :-) AvK

1 0

Interrupting commands
by Markus Enzenberger 15 Oct '02

15 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 13 Oct '02

13 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 09 Oct '02

09 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

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 October 2002