Don, Perhaps I'm completelly wrong, but pondering is up to the engine, the controller, nobody outside the engine will know / have to know if the engine is pondering.
I think in the threads we are confusing the fact that the engine and the gtp line controller could be in two different process threads. GTP line could 'answer' questions like: cpu usage, current best move, at realtime comunicating with the engine thread. Also, the engine could publish stats info sending that to the gtp line thread. That is not related to the protocol at all. Adding a couple of new commands will be enough. (and processing them on realtime from another thread). If the engine doesnt supports 'abort' the controller after a couple of seconds will receive 'move blah blah' 'command don't understood'. --- Don Dailey <[EMAIL PROTECTED]> escribió: > I like GTP and I champion it. However, there are > some weaknesses > and they are not easily fixed without a major > paridigm change. > > 1. There is no way to STOP a program from > thinking. This is > needed for a high quality user interface. > > 2. There is no natuaral way to get useful > information from the > go program, such as it's thinking process. A > quality user > interface should be able to show the user the > thinking process > of the program, when it changes it's mind > about the move choice, > it's current opinion of the score, etc. > > This can be implemented with "polling" by > adding a GTP command > to request information from the engine every > second or two, but > this feels like a hack. > > Thinking on the opponents time (pondering) is > supported naturally by > the UCI protocol. Actually, the engine doesn't need > to know much > about this, the controller simply tells the engine > to start thinking > on a given move and so the engine doesn't even know > it's thinking on > the opponents time. However, the engine does > communicate to the > controller what the ponder move is. > > This could ALMOST be implemented directly in GTP, > except for the fact > that you cannot stop the engine from searching once > it begins. If > I'm pondering, but the opponent doesn't play the > ponder move, there > is not way in GTP to say, STOP searching NOW because > the move is not > relevant! > > So GTP could not easily be used to build a high > quality user interface, > say > for a commercial program. At least not one that > had the better > features, > even given that you can extend the command set with > additional commands. > > It COULD be done, just not easily. You would have > to do it all with > polling. You could even implement stop search by > having a GTP command > to do searching in tiny time slices. The contoller > would send > commands such as "continue_search" which must return > in a fraction of > second, possibly with a move. This would be truly > awkward but > possible. > > > - Don > > > > On Thu, 2007-03-01 at 17:10 -0700, Markus > Enzenberger 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. > > > > 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/ > > _______________________________________________ > 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/
