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. 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 that GTP should not be extended in a way that makes the implementation of engines or controllers more complicated. > 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. 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. 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/
