gtp

gtp@lists.lysator.liu.se

164 discussions

abort
by A van Kessel 04 Nov '02

04 Nov '02

Markus wrote: > I still think that there is no need to specify, if the engine should > return success or error to an aborted genmove. What I think wms meant (and what I tried to quote ...) was: every command should either succeed or fail. when it succeeds, it could output it results, if any. If it fails, it issues a simple error message/reason. Aborting a command should be considered an error (from the command's perspective): the aborted command should result in an "?123 command aborted\n\n" reply. There is no timing problem possible here: it is either succeed, or fail. If the abort is received too late, the command will already have reported it's success, and the abort will of course fail. I hope I summarised correctly. AvK

1 0

interrupt
by A van Kessel 04 Nov '02

04 Nov '02

My attempt to summarise some of the points of discussion wrt the gtp-interrupt-feature: *) One-character (^C) vs full-command ("abort") interrupt. We seem to agree that this is a non-issue. This involves only the difference between one- character lookahead vs word- line- or bigger lookaheads. For the implementation, the size of the lookahead buffer is less important than the lookahead per se, since that will require the program to use some kind of polling, threading, or event-driven input. (a related issue, the signal-style interrupt has already been abandoned) *) The dialog-style of the command. Bill Schubert's approach produces the cleanest interface: the interrupt command should behave just like any normal command, so the program should report separate results for both the interrupted command and the interrupt command itself. Both of them can either succeed or fail, seemingly independently. *) Semantics. *) should the aborted command ("genmove", in most cases) report the best move found sofar ? *) if so, should it also have "committed" the move to it's internal state ? *) if it doen not have any move yet, what should the reply be ? *) should the abort also undo the aborted command's side-effects ? Personally, I think the aborted command should return an error, and not some partial result. This will keep most of the semantics out of the protocol. a New proposal: Maybe a separate command could be introduced to query the best move post-abortum, but this could also introduce some fuzzy semantics. I could live with the following dialog <1 genmove B <2 abort >?1 aborted <=2 abort successful <3 report_post_abortum_move >=3 B E4 <4 play B E4 =4 Ok Of course, both abort and report_post_abortum_move are optional commands are optional and their presence can be verified with the valid_command command. For the report_post_abortum_move command, IMO it should either succeed and report exactly one move, or fail with an appropriate error message. ("no move available" or "not implemented" seem to be the only plausible errors) WRT the atomicity of other commands than genmove[Andrew Balsa]: IMO, We cannot implicitly expect implementations to support full undo. Allowing abortion of *any* command(reset,boardsize,quit, undo ...) without full undo would make no sense. The engine would be left in an undetermined state, and a reset/boardsize command would be the only way out, anyway. If the command (boardsize, quit, undo) cannot be undone, the cheapest way for the implementation would be to just ignore the abort , execute the command anyway, report it's success or error, and report "nothing to abort" or "can't abort" for the abort command. This will allow the driver program to blindly trust the error/success reply. (most commands will have completed execution before seeing the abort command, so the abort would fail, anyway) AvK

3 2

Re: interrupt
by William M. Shubert 04 Nov '02

04 Nov '02

I think that this "getc/putc works with single-character abort" is not really as big an advantage as it seems. getc/putc are simply a standard 1-character buffer on FILE *'s provided by posix. It would be about 10 lines to write a similar system that can buffer up entire lines, and that will work equally as well with single-character aborts or "abort" as a text command. The advantages of a readable text "abort" outweigh the simuler code in POSIX systems for single character aborts in my opinion. Although I admit, now we're getting into opinions rather than facts, so it is harder to really argue either side of this. One thing I haven't heard discussed, does anybody really dislike having an optional "abort" command? Or is everybody OK with adding a section to the spec that says "If you support aborting commands, this is the way to do it"? On Tue, 2002-10-29 at 03:00, Markus Enzenberger wrote: 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).

2 1

stop_thinking
by A van Kessel 04 Nov '02

04 Nov '02

Marco Scheurer wrote: > makes me wonder if other optional commands would not be better: > start_thinking > stop_thinking > best_move I agree: once we allow "asynchronous" processing of commands, this wil be as easy as the abort-feature. It could have been the interface to the engine. At the moment, it is not. To allow simple implementations to talk GTP, we need the protocol to be "one line at a time" and blocking. The "abort" feature is an exception. It is optional, but we still should try to agree on it's semantics. BTW it is not forbidden to think in the opponebt's time. As long as it responds to the GTP dialog, the program may do anything it chooses to, given it maintains the necessary board state between moves/commands. Implementing start_thinking/stop_thinking/best_move in terms of genmove, abort, report_post_abortum_move is left as an exercise to the reader ... (hint: maybe built-in aliases/macro's would help :-) AvK

2 1

Re: interrupt
by Markus Enzenberger 28 Oct '02

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

15 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

← Newer
1
...
4
5
6
7
8
9
10
...
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