Just an small thought GTP could implement "async" commands. Adding commands like: CHAT ABORT etc.
Its up to the engine to read them as soon as possible, or wait to read/process them after processing a get_move command. I think just adding a couple of new commands that some engines could implement them 'in real time' its good enough for everybody. I wouldn't add complexity adding a true async channel, out of band or whatever. I mean, commands are ordered, as before, as always, that wouldn't break current implementations. By the way, I use a lot of stderr, I love it for debuging purposes, please don't use it as a second stream of comunication with the engine. With stdin/out and a thread with a couple of mutexes is all you need. (or thread safe queues if you like) My 2 cents --- £ukasz Lew <[EMAIL PROTECTED]> escribió: > 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/ __________________________________________________ Preguntá. Respondé. Descubrí. Todo lo que querías saber, y lo que ni imaginabas, está en Yahoo! Respuestas (Beta). ¡Probalo ya! http://www.yahoo.com.ar/respuestas _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
