[computer-go] GTPv3

[Łukasz Lew]

On 3/2/07, Markus Enzenberger <markus.enzenberger at gmail.com> wrote:
> On Thu March 1 2007 05:22, Łukasz Lew wrote:
> > The most important thing is controller - engine architecture.
> > There are situations that engine would like to have the control. For
>
> these requests come up once in a while, but IMO the clear separation between
> who is the controller and the engine is a big advantage of GTP. It makes both
> the implementation of engines and controllers much easier.

I agree

>
> Can you do simple, single-threaded controller scripts with UCI? Is it used for
> as many use cases as GTP is, ranging from regression testing to any kind of
> automated experiments with Go engines?
>
> The Go server protocols are designed for humans and asynchronous sending of
> messages between them at any time, but does it make sense for a computer
> engine to allow it to start chatting, whenever it feels like it?

I think it is sometimes important to allow the engine to sent some
information including chatting.

>
> I think that GTP should not be extended in a way that makes the implementation
> of engines or controllers more complicated.

I agree.

So is there any solution not using stderr?

>
> > In gogui this is solved by using stderr to send those commands, but:
> > - stderr is not network transparent
>
> Remi Coulom convinced me that it is more convenient for the engine to write to
> standard error and he was right. Typically the GTP interface is only one of
> several interfaces to lower level Go engine code and you don't want to make
> lower level code aware of this.

I would like to have GTP flexible enough to be the only interface needed.

>
> One idea I had in mind to address this was to allow the engine to send comment
> lines before the actual response. Then you could tunnel the standard error
> output through a network connection in these comment lines, maybe starting
> with a special keyword.

That is interesting.
But why before the actual response?
It should be allowed to sent it any time, and it's a matter of server
implementation when
It will parse it.

>
> It would need only a minor modification to existing controllers to ignore all
> text before the response. Alternatively, one could extend the tools GtpServer
> and NetGtp in the GoGui package to internally transmit standard error text in
> such a way, that would be transparent for the engine and controller on
> different hosts.
>
> > 6. Position setup. I had conversation with Marcus about setup in GoGui.
> > And we concluded that there should be a separate command for that.
>
> The coming version 1.0 of GoGui will support a setup command. It is a
> simplified version of a suggestion I made a while ago to the GTP list and
> uses a syntax like:
>
> gogui-setup b A1 b B2 w C3
>
> Originally I had an undoable setup command in mind to incrementally follow
> setup stones in SGF trees, but it is much easier for engine programmers to
> handle only full position setup on empty boards, so GoGui will follow the SGF
> properties incrementally and translate setup nodes into clear_board /
> gogui-setup sequences.
>
> - Markus
> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>