Actually gen_move blocks because every engine uses the same thread for both the engine and the comm link.
you can have a couple of sub commands for get_move like: get_complete_percent, get_current_best_move, chat, etc. If the engine doesn't support "realtime" gtp, they will be answer after the gen_move response. one at a time. I don't know, perhaps I'm pushing too much the gtp protocol... I don't think so, but perhaps.... --- Nick Apperson <[EMAIL PROTECTED]> escribió: > I think you are mostly correct. But, the problem is > that GTP was designed > to block on the genmove command. This is a problem > because genmove is > usually not quick to return. Therefore, there is no > way with the current > scheme to be able to issue commands while an engine > is thinking. It would > require a redesign perhaps using polling instead if > GTP is to remain > blocking. > > On 3/5/07, Eduardo Sabbatella > <[EMAIL PROTECTED]> wrote: > > > > 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 > === message truncated ===> _______________________________________________ > 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/
