Yes, it's possible to do all of this with GTP as is and the addition of a few commands that stay blocking, nothing but pure GTP extensions and no asyncronous communication.
I already mentioned this as polling. Instead of genmove, you send inc_genmove, which is designed to return very quickly and does only a partial search. The controller continues to send a long series of consecutive inc_genmove until the engine makes a move. And the controller can stop sending inc_genmove if it wants to abort. In fact it doesn't even need to tell the engine to abort. I think this is really rather ugly however. You are adding a LOT of extra communication and things will be sluggish if you don't send these at least 3 or 4 times per second. - Don On Mon, 2007-03-05 at 09:50 -0300, Eduardo Sabbatella wrote: > 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 > > [email protected] > > > 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 > [email protected] > http://www.computer-go.org/mailman/listinfo/computer-go/ _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
