I do not think that genmove should work that way. It makes more sense for you to have a genmove command and an async_endsearch command or somethinglike that. The program is allowed to keep searching as long as it doesn't receive that command. genmove doesn't need to have an async mode really. You could have async_genmove return the programs best guess at the moment, but it wouldn't be considered final until genmove returns.
On 3/5/07, Don Dailey <[EMAIL PROTECTED]> wrote:
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 > > 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/ _______________________________________________ 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/
