I don't think it should work that way either. I was just suggesting that it's possible to do everything required without any anynchronous changes to GTP, but I certainly don't recommend this method.
- Don On Mon, 2007-03-05 at 10:07 -0600, Nick Apperson wrote: > 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 > > > [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/ > _______________________________________________ computer-go mailing list [email protected] http://www.computer-go.org/mailman/listinfo/computer-go/
