On 3/2/07, Markus Enzenberger <[EMAIL PROTECTED]> 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@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
