[computer-go] GTPv3

[Nick Apperson]

perhaps since every command is numbered we could have a command that tells
the engine to abort a command by number.  The engine can ofcourse reply with
a failure if it already processed the command and can not abort it.  Genmove
still seems to be somewhat of an issue, but atleast this way defines clear
behavior that will work well as long as engines don't take too long to
replay to an abort with a success or failure.

On 3/8/07, Markus Enzenberger <markus.enzenberger at gmail.com> wrote:
>
> I am still frightened by your plans, how to permit asynchronous commands
> in
> GTP. Here are some remarks and questions:
>
> genmove is only one of many commands that the user might want to abort. We
> use
> GTP extension commands for starting life and death searches or other
> lengthy
> computations and many of them can be aborted at any time. Do you really
> want
> a sync and async version and a different abort command for each of them?
> Potentially every GTP command can be a candidate for aborting. If a
> controller provides support for engine-specific extension commands without
> specifically knowing what they do (like GoGui's Analyze Commands), there
> should still be a way to let the user send an abort request and let those
> commands abort that are able to.
>
> Why is it necessary that the async genmove returns an immediate response?
>
> - Markus
> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://computer-go.org/pipermail/computer-go/attachments/20070308/d1013d48/attachment.htm