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
On Monday, November 4, 2002, at 01:23 PM, A van Kessel wrote:
*) should the aborted command ("genmove", in most cases) report [...]
The intended use, so far, for this abort command (when the user wants to undo it's last move, or to force a move after some elapsed time) makes me wonder if other optional commands would not be better:
start_thinking stop_thinking best_move
It's not that different from genmove, abort, report_post_abortum_move, but I think the semantics is clearer.
However, one could wish to interrupt other lengthy operations, like scoring or getting a status or another. For instance, in our Goban application for Mac, we use GNU Go to score finished games, using the "final_status_list dead 2" command, and we just kill the process after some time if we don't get an answer.
(Doing this may not be very elegant or efficient, but could also be used when a UI client wants to undo without waiting for the reply: just kill and start a new process. Note that none of our users complained yet that undo was not available while the program was thinking.)
If such changes are introduced to GTP, shouldn't we also take into account the possibility for the engine to use the opponent's time to think?
Marco Scheurer Sen:te, Lausanne, Switzerland http://www.sente.ch
A van Kessel wrote:
*) 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 ?
I still think that there is no need to specify, if the engine should return success or error to an aborted genmove. Both can make sense depending on the kind of engine and its easy for an interactive controlling program to handle both cases correctly.
So I wouldn't overspecify things or complicate the protocol with a whole set of new commands.
Also there is a problem if the user sends an abort, but the engine already sent a success in the short time between the user clicked and the abort is sent.
- Markus
-
A van Kessel -
Marco Scheurer -
Markus Enzenberger