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.
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.
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.
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
Hi,
On Monday 28 October 2002 06:39, Markus Enzenberger wrote: [...]
I am afraid this is implied behaviour on the part of the engine. Some engines cannot return a "partial" answer, even if you could interrupt their move generation algorithm. Also, it seems undesirable to specify a different engine response depending on whatever the engine was doing when it received the abort command. [...]
All in all, IMHO Mr. Schubert's suggestions seem to be the easiest to implement and more in line with the general "spirit" of GTP.
I'l try to add a very simple implementation of his "abort" command to the -plus programs (even though they don't think long enough for this to be of any use), just as a feasibility demo/test.
I would keep the command optional, though.
Regards,