Re: [computer-go] GTPv3
On 3/7/07, Paul Pogonyshev [EMAIL PROTECTED] wrote: Don Dailey wrote: On Wed, 2007-03-07 at 22:53 +0100, Gunnar Farneback wrote: * To abort the asynchronous genmove, the controller should send the (synchronous) command abort_async_genmove. If the engine has not returned the asynchronous genmove response before responding to the abort command, it is no longer allowed to return a move. I'm open for discussion on the exact name and whether it should return an error if the move had already been sent (I don't think it should). But what about race conditions here? The engine may be responding to the async_genmove command an instant before it realizes an abort command just arrived. In this case it would be violating your rule but it wouldn't be anyone's fault. There is no race condition because commands _are_ read synchronously. But responses _may be_ sent asynchronously. Paul I'm not sure that I understand Paul's explanation, so I'll try out my own: Any race condition that occurs here is entirely the fault of the engine. The engine is already responsible for serializing all of the responses that it makes. Any failure to do so would allow interleaved responses, which could not possibly be understood by the controller. So, at the time that the async_genmove is permitted to write its asynchronous response, (it may have to acquire a lock in order for this to be the case) it is unambiguous whether or not the response to abort_async_genmove has been sent. Weston ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [gtp] Re: [computer-go] GTPv3
On 3/7/07, Paul Pogonyshev [EMAIL PROTECTED] wrote: Gunnar Farneback wrote: Example 3: Like example 2, but abort command comes too late. ... Maybe it should then read ?2 not in progress It also makes sense to forbid an async_genmove (or simple genmove for that matter) until the previous genmove/async_genmove has finished. The engine should just fail with a predefined error string; I think it is really cumbersome for the engine to try synchronization here and serves little purpose. Paul Although Gunnar specifies async_genmove to return zero or one responses, I believe that it may be more useful to allow it to return any number. This allows the possibility for the controller to update a current best display while it has still not accepted a single definitive response. From the controller's point of view, the command could still be in effect until a response to the abort_async_genmove has been received. (although perhaps end_async_genmove would be more appropriate name in this case.) I don't feel strongly either way on this, but I thought that I should mention the possibility. Does it also make sense to forbid commands that modify the engine's state? If the board state changes before async_genmove generates a response, to which board does the response apply? Weston ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
I am still frightened by your plans, how to permit asynchronous commands in GTP. Here are some remarks and questions: genmove is only one of many commands that the user might want to abort. We use GTP extension commands for starting life and death searches or other lengthy computations and many of them can be aborted at any time. Do you really want a sync and async version and a different abort command for each of them? Potentially every GTP command can be a candidate for aborting. If a controller provides support for engine-specific extension commands without specifically knowing what they do (like GoGui's Analyze Commands), there should still be a way to let the user send an abort request and let those commands abort that are able to. Why is it necessary that the async genmove returns an immediate response? - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
perhaps since every command is numbered we could have a command that tells the engine to abort a command by number. The engine can ofcourse reply with a failure if it already processed the command and can not abort it. Genmove still seems to be somewhat of an issue, but atleast this way defines clear behavior that will work well as long as engines don't take too long to replay to an abort with a success or failure. On 3/8/07, Markus Enzenberger [EMAIL PROTECTED] wrote: I am still frightened by your plans, how to permit asynchronous commands in GTP. Here are some remarks and questions: genmove is only one of many commands that the user might want to abort. We use GTP extension commands for starting life and death searches or other lengthy computations and many of them can be aborted at any time. Do you really want a sync and async version and a different abort command for each of them? Potentially every GTP command can be a candidate for aborting. If a controller provides support for engine-specific extension commands without specifically knowing what they do (like GoGui's Analyze Commands), there should still be a way to let the user send an abort request and let those commands abort that are able to. Why is it necessary that the async genmove returns an immediate response? - 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/
Re: [computer-go] GTPv3
Don Dailey wrote: On Thu, 2007-03-08 at 12:27 -0500, Weston Markham wrote: There is no race condition because commands _are_ read synchronously. But responses _may be_ sent asynchronously. Paul I'm not sure that I understand Paul's explanation, so I'll try out my own: Any race condition that occurs here is entirely the fault of the engine. The engine is already responsible for serializing all of the responses that it makes. Any failure to do so would allow interleaved responses, which could not possibly be understood by the controller. So, at the time that the async_genmove is permitted to write its asynchronous response, (it may have to acquire a lock in order for this to be the case) it is unambiguous whether or not the response to abort_async_genmove has been sent. I think I am confused. So what you might get is this: 1. controller sends async_genmove 2. controller (after some period of time) sends abort. 3. engine responds to aysnc_genmove 4. engine responds to the abort search In my example, I'm assuming the engine send it's response to asyn_genmove at the same instant the controller wanted to abort the search, so the engine didn't see the abort comming before it was too late. Isn't this a race condition? I believe this should cause no problems because the controller can simply ignore the non-relevant response to genmove (it knows it send abort.) But I don't think that is what you are talking about. [Please CC to GTP list] Engine should send response in this way: acquire response lock check if asynchronous command hasn't been aborted/completed if not, send response release lock In other words, there is potential for race condition, as with anything asynchronous. But properly implemented engine doesn't have a race condition situation. Yes, it is more complicated. That's why I'm against making asynchronous stuff required, only optional. Paul ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
Don Dailey wrote: 1. controller sends async_genmove 2. controller (after some period of time) sends abort. 3. engine responds to aysnc_genmove 4. engine responds to the abort search A effect might be that the engine has a gamestate where it's move has taken place, while in the controllers state it hasn't. A general rule would be that an aborted async_genmove (or any other async command that changes anything withing the engine) requires a resync between the controller and the engine. eph ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
On 3/8/07, Don Dailey [EMAIL PROTECTED] wrote: On Thu, 2007-03-08 at 12:27 -0500, Weston Markham wrote: I think I am confused. I may be confused as well. I see that Paul has responded as well, but just in case this doesn't clear up on it's own: So what you might get is this: 1. controller sends async_genmove 2. controller (after some period of time) sends abort. 3. engine responds to aysnc_genmove 4. engine responds to the abort search ... Isn't this a race condition? I believe this should cause no problems because the controller can simply ignore the non-relevant response to genmove (it knows it send abort.) But I don't think that is what you are talking about. I didn't think that this is what you were talking about, either, so now it is not clear to me what race condition you are worried about. What behavior in this example depends on the timing? (I see no constraint on the actual ordering of #2, and #3, but no matter what order they occur in, the engine's responses would be the same, wouldn't they? I assume, by the way, that #3 is the asynchronous response to #1, and not the initial synchronous one.) You are claiming that there is some case where this scenario violates some rule of Gunnar's proposed protocol, correct? (The proposal did not constrain the responses based on what additional commands had already been sent, but rather what other responses had already been sent.) What exactly is that violation? Weston ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
Paul wrote (on the computer-go list): About asynchronous move generation. I'd propose something like this. Add some form for asynchronous responses. E.g. '=[id] ...' means success, '?[id] ...' means error (this is as now) and '%[id] ...' means asynchronous response. Maybe for asynchronous commands it makes sense to make id mandatory. Responses must not be mixed, i.e. you cannot start a synchronous response inside asynchronous or vice versa (else they will be impossible to parse properly.) This is in the same direction I've been thinking. To make it consistent with GTP version 2 and fully backwards compatible it can be designed like this: * Asynchronous responses from the engine are encoded like Paul proposes but with ! as first character (there is precedence in a protocol GTP was originally inspired by). Naturally one response must be complete before starting on another, whether synchronous or asynchronous. * Asynchronous messages may only be sent as responses to asynchronous commands. Thus a GTP version 2 controller would never become confused by asynchronous responses it knows nothing about since it would only send synchronous commands. * Asynchronous responses have the same id as the command initiating them. The id may as usual be omitted by the controller if it is confident that it don't need it. * An asynchronous command must first be acknowledged by a synchronous response (would usually be an empty response if there are no problems and otherwise an error response). * An asynchronous command may additionally have zero, one, or multiple asynchronous responses, depending on the nature of the command and the situation. For example an asynchronous genmove command would normally have one asynchronous response, but zero if the command is aborted. A command requesting debug output could produce any number of asynchronous responses. * Whether an engine is capable of doing asynchronous responses can as usual be tested by known_command or list_commands to see whether it supports specific (asynchronous) commands. * The asynchronous genmove command would be named async_genmove. In contrast to the normal genmove command it would only generate a move, not actually play it. (To keep sanity and avoid undos when the ordering of move generation and abort command depends on race conditions.) * To abort the asynchronous genmove, the controller should send the (synchronous) command abort_async_genmove. If the engine has not returned the asynchronous genmove response before responding to the abort command, it is no longer allowed to return a move. I'm open for discussion on the exact name and whether it should return an error if the move had already been sent (I don't think it should). Example 1: Asynchronous genmove with an intervening synchronous command. Command 3 is sent after receiving the asynchronous move. Controller: 1 async_genmove black 2 version 3 play black E5 Engine: =1 =2 4.0 !1 E5 =3 Example 2: Asynchronous genmove, aborted. The controller plays an own move instead. Controller: 1 async_genmove black 2 abort_async_genmove 3 play black C3 Engine: =1 =2 =3 Example 2b (BAD): Like example 2, but the engine makes an incorrect response. Controller: 1 async_genmove black 2 abort_async_genmove 3 play black C3 Engine: =1 =2 !1 E5 =3 Example 3: Like example 2, but abort command comes too late. Controller: 1 async_genmove black 2 abort_async_genmove 3 play black C3 Engine: =1 !1 E5 =2 =3 Example 4: Asynchronous genmove sent to an engine not supporting it. Controller: 1 async_genmove black Engine: ?1 unknown command /Gunnar ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [gtp] Re: [computer-go] GTPv3
Gunnar Farneback wrote: Example 3: Like example 2, but abort command comes too late. Controller: 1 async_genmove black 2 abort_async_genmove 3 play black C3 Engine: =1 !1 E5 =2 =3 Maybe it should then read ?2 not in progress It also makes sense to forbid an async_genmove (or simple genmove for that matter) until the previous genmove/async_genmove has finished. The engine should just fail with a predefined error string; I think it is really cumbersome for the engine to try synchronization here and serves little purpose. Paul ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
Don Dailey wrote: On Wed, 2007-03-07 at 22:53 +0100, Gunnar Farneback wrote: * To abort the asynchronous genmove, the controller should send the (synchronous) command abort_async_genmove. If the engine has not returned the asynchronous genmove response before responding to the abort command, it is no longer allowed to return a move. I'm open for discussion on the exact name and whether it should return an error if the move had already been sent (I don't think it should). But what about race conditions here? The engine may be responding to the async_genmove command an instant before it realizes an abort command just arrived. In this case it would be violating your rule but it wouldn't be anyone's fault. There is no race condition because commands _are_ read synchronously. But responses _may be_ sent asynchronously. Paul ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
I have not been following this discussion closely, but let me throw few ideas in. First about a new protocol --- I'm strongly against. I remember it was a real pain to force GTP over backward GMP. Now you want to force some (probably better but more likely more complicated) protocol over GTP which works and has many uses. I'd say you'll spend several years on this and yet it might not succeed. And it will most likely only hurt computer go community, not bring an advantage. About asynchronous move generation. I'd propose something like this. Add some form for asynchronous responses. E.g. '=[id] ...' means success, '?[id] ...' means error (this is as now) and '%[id] ...' means asynchronous response. Maybe for asynchronous commands it makes sense to make id mandatory. Responses must not be mixed, i.e. you cannot start a synchronous response inside asynchronous or vice versa (else they will be impossible to parse properly.) So, for old or not sophisticated engine it could look like this: 1 genmove white 2 best_so_far 3 abort_thinking =1 F14 ?2 unknown command ?3 unknown command But for engine with support for asynchronous responses: 1 genmove white 2 best_so_far 3 abort_thinking %2 D17 =3 ?1 aborted Clients can easily distinguish between two scenarios. To make it even easier, one can add one command: supports_async_protocol (optional command) -- returns 0 or 1, if not implemented, 0 is assumed by controllers and they may opt to never send commands meant to be replied asynchronously. Paul ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
It would be nice to have a reference implementation. I can do that on Java (yes Its not C but its reference implementation and for free, I would do a lot of JUnits in exchange). What do you think ? --- £ukasz Lew [EMAIL PROTECTED] escribió: Hi, There are some issues that are not so well defined in GTP v2. Maybe GTP v3 should be released to avoid too much legacy later? 1. The most important thing is controller - engine architecture. There are situations that engine would like to have the control. For instance When he want to send commands to GUI to draw something while he is working. In gogui this is solved by using stderr to send those commands, but: - stderr is not network transparent - syntax is not standardized - there is no confirmation about success / failure for those commands. 2. The second thing is that there are many variables in the engine (komi, board size, time, etc). Developers tend to have more of them to control various parameters of the engine. End users could like to have some control over strength of the algorithm, etc. 3. If GTP would supports chats, KGS would probably implement it. 4. Opponent identification. 5. Interrupt. Users do not always want to wait until the program finish work. GoGui uses comment #interrupt to do it, but this is a hack. (this is somewhat related to 1.) 6. Position setup. I had conversation with Marcus about setup in GoGui. And we concluded that there should be a separate command for that. Would You like to have those issues solved? I hope we can get somewhere. :) Best Regards, £ukasz ___ 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/
Re: [computer-go] GTPv3
Just an small thought GTP could implement async commands. Adding commands like: CHAT ABORT etc. Its up to the engine to read them as soon as possible, or wait to read/process them after processing a get_move command. I think just adding a couple of new commands that some engines could implement them 'in real time' its good enough for everybody. I wouldn't add complexity adding a true async channel, out of band or whatever. I mean, commands are ordered, as before, as always, that wouldn't break current implementations. By the way, I use a lot of stderr, I love it for debuging purposes, please don't use it as a second stream of comunication with the engine. With stdin/out and a thread with a couple of mutexes is all you need. (or thread safe queues if you like) My 2 cents --- £ukasz Lew [EMAIL PROTECTED] escribió: On 3/2/07, Markus Enzenberger [EMAIL PROTECTED] 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. I agree 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 it is sometimes important to allow the engine to sent some information including chatting. I think that GTP should not be extended in a way that makes the implementation of engines or controllers more complicated. I agree. So is there any solution not using stderr? 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. I would like to have GTP flexible enough to be the only interface needed. 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. That is interesting. But why before the actual response? It should be allowed to sent it any time, and it's a matter of server implementation when It will parse it. 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/
Re: [computer-go] GTPv3
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
Re: [computer-go] GTPv3
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 output through a network connection in these comment lines, maybe starting with a special keyword.
Re: [computer-go] GTPv3
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
Re: [computer-go] GTPv3
On Mon, Mar 05, 2007 at 09:50:30AM -0300, Eduardo Sabbatella wrote: Actually gen_move blocks because every engine uses the same thread for both the engine and the comm link. Yes. That is not a bug, it is a feature, when using GTP for debugging, automatic tests, or something else that is based on scripts. As has been said before, it would be possible to add a command like 'start-thinking', which would return quickly, while the engine would be thinking in the background. While in this state, more asynchrnous commands could be issued. Perhaps the engine could also send status responses and/or chat messages without a status request. If an engine (or controller) does not support the new commands, they can always fall back to the old, synchronous, commands. If the engine doesn't support realtime gtp, they will be answer after the gen_move response. one at a time. I think it would be better to create new commands, and leave genmove as it is, for maximizing the compatibility with old programs, and with new ones that haven't got around to implementing the asynch stuff yet. - Heikki -- Heikki Levanto In Murphy We Turst heikki (at) lsd (dot) dk ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
On Mon, 2007-03-05 at 10:10 +0100, Heikki Levanto wrote: On Sat, Mar 03, 2007 at 04:10:16PM -0500, Don Dailey wrote: And you CAN compare GTP directly to UCI because both are designed for the same purpose and both are simple text based protocols and the similarities are much greater than the differences. GTP has many purposes. One of them is to sit betwene an engine and an UI, but that is not the only one. It is also used for test scripts to validate engines, and to debug them. So, what even asynchronous extensions you are adding to GTP, please keep the simple synchronous mode still available, for it has many uses too! If I were designing the asynchronous extentions I was mandate that the core doesn't change - that you can continue to use GTP as is without any suprises. - Don -Heikki ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
I agree with you. My idea is to not have a specific aync command, but to have anycronous versions of commands. The engine is free to accept or reject them. Having an async command doesn't do anything if you haven't implemented the useful needed extensions.Of course it could change the meaning of existing commands but I think it's cleaner to simply have new GTP commands that are understood to be asyncrounous. Even UCI doesn't allow the engine to say anything it wants whenever it wants. It is still semi-syncronous. All communication sent from an engine is still a response to some command sent from the controller. The rule is that you ignore any communication sent out of context and this avoids syncronization issues such as when the controller says to stop searching but the engine sends a move before this is noticed. So it's really not as complicated as you might think. chat I assume is about informational messages from a searching engine. So it's a legitimate response to an asyncronous command to search a position, but if you are not searching a position it would be ignored by the controller. Abort is the same, it really means stop searching if you are currently searching and so is ignored if you happen to have stopped at almost the same instant you recieved the command. - Don On Mon, 2007-03-05 at 09:08 -0300, Eduardo Sabbatella wrote: Just an small thought GTP could implement async commands. Adding commands like: CHAT ABORT etc. Its up to the engine to read them as soon as possible, or wait to read/process them after processing a get_move command. I think just adding a couple of new commands that some engines could implement them 'in real time' its good enough for everybody. I wouldn't add complexity adding a true async channel, out of band or whatever. I mean, commands are ordered, as before, as always, that wouldn't break current implementations. By the way, I use a lot of stderr, I love it for debuging purposes, please don't use it as a second stream of comunication with the engine. With stdin/out and a thread with a couple of mutexes is all you need. (or thread safe queues if you like) My 2 cents ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
We got consensus :-) Yes some messages are async, some are synqued. If an async message/reply is received in the wrong time, it could be ignored as they use to be information only values, no state change of the game. cool :-) --- Don Dailey [EMAIL PROTECTED] escribió: I agree with you. My idea is to not have a specific aync command, but to have anycronous versions of commands. The engine is free to accept or reject them. Having an async command doesn't do anything if you haven't implemented the useful needed extensions.Of course it could change the meaning of existing commands but I think it's cleaner to simply have new GTP commands that are understood to be asyncrounous. Even UCI doesn't allow the engine to say anything it wants whenever it wants. It is still semi-syncronous. All communication sent from an engine is still a response to some command sent from the controller. The rule is that you ignore any communication sent out of context and this avoids syncronization issues such as when the controller says to stop searching but the engine sends a move before this is noticed. So it's really not as complicated as you might think. chat I assume is about informational messages from a searching engine. So it's a legitimate response to an asyncronous command to search a position, but if you are not searching a position it would be ignored by the controller. Abort is the same, it really means stop searching if you are currently searching and so is ignored if you happen to have stopped at almost the same instant you recieved the command. - Don On Mon, 2007-03-05 at 09:08 -0300, Eduardo Sabbatella wrote: Just an small thought GTP could implement async commands. Adding commands like: CHAT ABORT etc. Its up to the engine to read them as soon as possible, or wait to read/process them after processing a get_move command. I think just adding a couple of new commands that some engines could implement them 'in real time' its good enough for everybody. I wouldn't add complexity adding a true async channel, out of band or whatever. I mean, commands are ordered, as before, as always, that wouldn't break current implementations. By the way, I use a lot of stderr, I love it for debuging purposes, please don't use it as a second stream of comunication with the engine. With stdin/out and a thread with a couple of mutexes is all you need. (or thread safe queues if you like) My 2 cents ___ 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/
Re: [computer-go] GTPv3
just a thought... prefix all async commands with async_ so that it is clear. Also, that way there can be a version of the command that is async and one that blocks and an engine can support one or both. This could be useful for commands that query on state (or estimated score or whatever). An engine might not be able to easily support that async, but another engine might be able to. The controller can query using get_commands (or whatever the function is called) and know that it can call it anytime or only when the engine isn't thinking. Also, it would make it clearer how a command operates and a command can be assumed to be blocking unless it has that prefix and if we change the behavior of the async versions from the blocking ones an engine can still support both. - Nick On 3/5/07, Eduardo Sabbatella [EMAIL PROTECTED] wrote: We got consensus :-) Yes some messages are async, some are synqued. If an async message/reply is received in the wrong time, it could be ignored as they use to be information only values, no state change of the game. cool :-) --- Don Dailey [EMAIL PROTECTED] escribió: I agree with you. My idea is to not have a specific aync command, but to have anycronous versions of commands. The engine is free to accept or reject them. Having an async command doesn't do anything if you haven't implemented the useful needed extensions.Of course it could change the meaning of existing commands but I think it's cleaner to simply have new GTP commands that are understood to be asyncrounous. Even UCI doesn't allow the engine to say anything it wants whenever it wants. It is still semi-syncronous. All communication sent from an engine is still a response to some command sent from the controller. The rule is that you ignore any communication sent out of context and this avoids syncronization issues such as when the controller says to stop searching but the engine sends a move before this is noticed. So it's really not as complicated as you might think. chat I assume is about informational messages from a searching engine. So it's a legitimate response to an asyncronous command to search a position, but if you are not searching a position it would be ignored by the controller. Abort is the same, it really means stop searching if you are currently searching and so is ignored if you happen to have stopped at almost the same instant you recieved the command. - Don On Mon, 2007-03-05 at 09:08 -0300, Eduardo Sabbatella wrote: Just an small thought GTP could implement async commands. Adding commands like: CHAT ABORT etc. Its up to the engine to read them as soon as possible, or wait to read/process them after processing a get_move command. I think just adding a couple of new commands that some engines could implement them 'in real time' its good enough for everybody. I wouldn't add complexity adding a true async channel, out of band or whatever. I mean, commands are ordered, as before, as always, that wouldn't break current implementations. By the way, I use a lot of stderr, I love it for debuging purposes, please don't use it as a second stream of comunication with the engine. With stdin/out and a thread with a couple of mutexes is all you need. (or thread safe queues if you like) My 2 cents ___ 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/
Re: [computer-go] GTPv3
On Mon, 2007-03-05 at 09:32 -0300, Eduardo Sabbatella 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. My program Lazarus ponders on CGOS, without any help from the cgos client program, so you are right, extensions are not necessary to implement pondering. However, UCI explicity supports pondering and it makes it a no-brainer to implement. If you implement pondering you will discover that it's far from trivial, but with help from UCI (or GTP) it comes for free. This does not prevent you from implementing it internally your own way. The model UCI uses is that your program informs the controller about which move it would ponder and the controller, at the appropriate time just sends the command to start thinking on the appopriate position. Your program does not have to manage the complexity of when to abort, etc. However, it can if it wants to. So extensions to GTP do not have to support this notion of supported pondering, however there is something that cannot be faked that GTP does not support. In a commercial quality product, there is no GTP endorsed way to stop a program from thinking. Imagine playing a program at a super high level and getting impatient and wanting to see a move.Sorry, not possible with GTP. Another cool feature that is not possible is what chess people call analysis mode. You sit in front of the program with your mouse making moves and the program is following the game. It constantly updates it's opinion of the position, showing you scores, principal variations, etc. But you can make a move anytime you want for either side and the program instantly adjusts, starting a new infinite level search from the new position. It's just sitting in the background watching you place stones. It's a very cool and useful feature. Sorry, can't do this with GTP. 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. I'm not confusing this issue, you can implement pondering this way but this still doesn't address the above issues. We still need to have some asyncronous commands to get cool user interfaces. I don't really care if GTP holds your hand with pondering, it's just a nice feature UCI has and it lowers the barrier for implementing pondering for newer less experienced programmers. 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'. I may have lost you here. Are you suggesting that we can do all of this without any asyncronous commands? - Don --- 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
Re: [computer-go] GTPv3
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
Re: [computer-go] GTPv3
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
Re: [computer-go] GTPv3
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
Re: [computer-go] GTPv3
Don Dailey wrote: On Mon, 2007-03-05 at 10:10 +0100, Heikki Levanto wrote: On Sat, Mar 03, 2007 at 04:10:16PM -0500, Don Dailey wrote: And you CAN compare GTP directly to UCI because both are designed for the same purpose and both are simple text based protocols and the similarities are much greater than the differences. GTP has many purposes. One of them is to sit betwene an engine and an UI, but that is not the only one. It is also used for test scripts to validate engines, and to debug them. So, what even asynchronous extensions you are adding to GTP, please keep the simple synchronous mode still available, for it has many uses too! If I were designing the asynchronous extentions I was mandate that the core doesn't change - that you can continue to use GTP as is without any suprises. I'm entering this discussion a bit late, but what about the following idea? Perhaps we could start from scratch and create the protocol we want with no compromises based perhaps on an async event message model - a model everyone probably is quite familiar with. It could move beyond ASCII messages on stdout and be designed for extensibility. Add all the common features we are looking for to really make a modern, robust and complete system. Since something like this would be a superset of GTP, a reference implementation of the new protocol could also include a proxy implementation of GTP using the new protocol. This would allow the best of both worlds - programs can continue to use GTP if they wanted, operating in a more constrained context than programs that implement and use the new protocol. Years into the future we won't have the baggage of GTP still as likely all programs would eventually move to the new standard. Just a thought... -Matt ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
On Mon, 2007-03-05 at 20:00 -0600, Matt Gokey wrote: I'm entering this discussion a bit late, but what about the following idea? Perhaps we could start from scratch and create the protocol we want with no compromises based perhaps on an async event message model - a model everyone probably is quite familiar with. It could move beyond ASCII messages on stdout and be designed for extensibility. Add all the common features we are looking for to really make a modern, robust and complete system. Since something like this would be a superset of GTP, a reference implementation of the new protocol could also include a proxy implementation of GTP using the new protocol. This would allow the best of both worlds - programs can continue to use GTP if they wanted, operating in a more constrained context than programs that implement and use the new protocol. Years into the future we won't have the baggage of GTP still as likely all programs would eventually move to the new standard. Just a thought... -Matt Hi Matt, There are two potential problems with this. 1. If you get too far away from the current GTP protocol, it won't be accepted. 2. In either case, if you push for the new protocol you will hurt the computer go community. I don't pretend to know how likely these scenario's are, but it's my fear. If I WERE to do something from scratch, I would start with UCI from the chess world and make only minor changes to make it more appropriate for GO. Not because I'm also a chess programmer, but because it's a fully tested protocol and because it rocks. I would point out that the chess world has 2 main protocols, one that wasn't really planned but evolved from the xboard/winboard projects. This is still a problem - if you get a chess engine and a chess user-interface you have to make sure they are compatible, because some engines use only one or the other and some interfaces use one or the other although most good interfaces try to work with both. But I don't really want this to happen with computer go. (Of course there is GMP, but it's not a serious contender for a quality user interface.) I also hate to break away from the gnu project - it's their good work that has set the standard for GTP.I believe if they solve this problem with some kind of asynchronous protocol and build it into gnugo, it will be accepted. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
try() and expect() to suffer() or install() signal_handlers() everywhere(). s. - Original Message From: Markus Enzenberger [EMAIL PROTECTED] To: computer-go computer-go@computer-go.org Sent: Saturday, March 3, 2007 12:39:28 PM Subject: Re: [computer-go] GTPv3 On Saturday 03 March 2007, Stuart A. Yeates wrote: In an ideal world I'd love to see go move to RFC 3920, but that would be quite a disruptive shift. this RFC describes an asynchronous message passing system; GTP is more like a simple remote procedure call at Go engines. These are different things and therefore you cannot really compare GTP to UCI or call UCI more advanced. I cringe, when I think about how to write tools that need to access functionality of Go engines, but have to deal with unexpected messages or state changes at any time. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
On 3, Mar 2007, at 2:50 AM, Stuart A. Yeates wrote: Personally I'd love to see functionality improvements, including: * moving from file to generic URI references * interruption of thinking engines I can see the point of sending a message that *requests* the interruption of a thinking engine, but would not like a protocol that has the power to force it. Acceptance of this request should still be at the discretion of the engine. * moving beyond ASCII * handicap and ruleset negotiation Cheers, David ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
On Sat, 2007-03-03 at 10:39 -0700, Markus Enzenberger wrote: These are different things and therefore you cannot really compare GTP to UCI or call UCI more advanced. Yes I can. I have had a lot of experience coding up engines for both protocols and I have no reservations about this, UCI is more advanced. And you CAN compare GTP directly to UCI because both are designed for the same purpose and both are simple text based protocols and the similarities are much greater than the differences. I cringe, when I think about how to write tools that need to access functionality of Go engines, but have to deal with unexpected messages or state changes at any time. This is one of those things things that turns out to be much easier than you imagined. From the engine side, it's only slightly more difficult to implement than GTP. You have a loop that listens for commands and executes them when they come. This is no different than GTP. Here is what IS different: 1. Your input routine must be non-blocking unless it runs in a separate thread (but this is not necessary and probably ill-advised.) 2. Your engine should be prepared to respond fairly quickly to any command. Both of these are easily accomplished. The I/O loop can be handled as a simple function that that can be called repeatedly from anywhere in the program, like a simplified co-routine. This is nothing like the complexity of programming with threads with deadlock possiblities and difficult debugging sessions. It's very easy to get this working right.With UCI (as well as GTP) I spent more time looking at the specification and making sure I understood it than I did implementing it. When I say it's more advanced, a good example is thinking on the opponents time. You can get this pretty much for free if you implement the protocol in your engine since the GUI can handle this for you. You simply honor the commands sent and you will have thinking on the opponents time. That's worth it's weight in gold if you want pondering for your program. I'm not suggesting we move to UCI, but a GTP asycronous mode would accomplish everything needed with the addition of a couple of more GTP commands. Then it would be pretty much the same as UCI except in the mundane details. You simply cannot have a sophisticated GO program GUI using GTP. At least not as it currently exists. Unless of course you implement your own non-standard hacks, but then it's not GTP. My suggestion is to offer asycronous versions of a few commands as extensions to the protocol, while taking great care NOT to deprecate any of the current commands.I do not recommend a major unheaval of the standard - it will hurt computer go. I cannot help but remember the initial resistance to the far superior GTP over GMP protocol. But in this case, it doesn't have to be a distruptive improvement, just an improvement. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
On 3/2/07, Markus Enzenberger [EMAIL PROTECTED] 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. I agree 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 it is sometimes important to allow the engine to sent some information including chatting. I think that GTP should not be extended in a way that makes the implementation of engines or controllers more complicated. I agree. So is there any solution not using stderr? 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. I would like to have GTP flexible enough to be the only interface needed. 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. That is interesting. But why before the actual response? It should be allowed to sent it any time, and it's a matter of server implementation when It will parse it. 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/
Re: [computer-go] GTPv3
On Fri, 2007-03-02 at 17:31 +0100, Łukasz Lew wrote: I also have a strong feelings about variables. I believe there should be standard GTP command, var seems to be a good name, that would write list of variables (with types?) var var_x would print value of var_x var var_x value would set the value. What do You think? It's a bad idea for a protocol like this in my opinon. What purpose does it serve to give variables unless you also have a protocol to agree on what the variables mean?If I send var x = 7 what is the controller supposed to do with that? With UCI there is a provision for a program to communicate to the controller all the settable options. These do not have to be pre-defined options although many are common. Your program may have a special setting unique to it alone and you can tell the interface about it, and the end use of the program can change that parameter or option via the interface. It's really quite nice and simple. This is the closest thing I can think of to what you are talking about.There are several classes of options and you can provide ranges. The options can be boolean such as turning something on and off, values with ranges, etc. UCI is significantly more advanced compared to GTP but I'm really hesitant to change a standard, even if it's not perfect. To go forward, GTP has to be completely changed and I have mixed feelings about this. - Don Łukasz On 3/2/07, Markus Enzenberger [EMAIL PROTECTED] wrote: On Thursday 01 March 2007, Phil G wrote: I would like to suggest using the command setup_sequence instead to miror the play_sequence command which was introduced by GoGui (I believe). I finally followed the GTP (draft) standard and used a prefix separated by a hyphen for non-standard extension commands, so play_sequence became gogui-play_sequence. setup_sequence wouldn't be a good name, because the setup stones are not a sequence, you can specify them in any order. There will also be a second command gogui-setup_player for setting the color to play, but support for that is optional, since it is not strictly necessary that the engine is informed about the color to play. The genmove and play commands are sent with a color argument anyway. If an engine does not support gogui-setup, setup stones will be sent as moves as previously. - 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/ ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
On Fri, 2007-03-02 at 13:45 -0500, Don Dailey wrote: 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. Of course, a good GO program doesn't have to STOP searching just because it's responding to a continue_search command. It could anticipate that it will soon be getting another continue_search command. But you see things start getting much more complicated, what if it doesn't get another continue_search command? You lose the simplicty of GTP where you get a command, respond to it, wait for the next command etc. With UCI this is trivial from the engines perspective. The program simply responds to commands, pretty much the same as GTP but it's also allowed to send informational messages along the way. It's actually really simple to implement. - Don ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
Łukasz, Yes, I would like to see some of these problems solved. As I mentioned, UCI doesn't have any of these issues. After thinking about this, there is perhaps a backwards compatible solution: 1. Don't change GTP, just add to it. 2. Have a command called asyncronous which tells the engine that it supports the new asyncronous protocol. (Or maybe the response to the protocol_version command is enough) 3. If the engine suports this, then it can accept commands like stop_search and it can send certain informational commands. If the controller is asyncronous, the engine could still SEND informational commands even if it was not capable of ACCEPTING commands out of order. You could get all the benefits of UCI without breaking backward compatibility. One issue is that the engine canont assume the more advanced GTP protocol, it must remain in backward compatible mode (should not send informational messages) unless that is directed by the controller. One way around this is to define a different set of commands that are designed to be asyncronous. Then the engine can feel free to accept or reject them. For example instead of using genmove, the new protocol could send begin_search, which is understood to be an asymetric command. If your program gets a begin_search command it is allowed to send informational messages while searching.Those informational messages must be specified by the protocol and contain information such as nodes searched, score, current best move, search depth, etc. But the program doesn't have to send information it doesn't want to. If your program doesn't do a search it is not required to send a search depth, etc. If your engine accepts and responds to begin_search it is understood that it will accept and respond to stop_search - Don On Thu, 2007-03-01 at 13:22 +0100, Łukasz Lew wrote: Hi, There are some issues that are not so well defined in GTP v2. Maybe GTP v3 should be released to avoid too much legacy later? 1. The most important thing is controller - engine architecture. There are situations that engine would like to have the control. For instance When he want to send commands to GUI to draw something while he is working. In gogui this is solved by using stderr to send those commands, but: - stderr is not network transparent - syntax is not standardized - there is no confirmation about success / failure for those commands. 2. The second thing is that there are many variables in the engine (komi, board size, time, etc). Developers tend to have more of them to control various parameters of the engine. End users could like to have some control over strength of the algorithm, etc. 3. If GTP would supports chats, KGS would probably implement it. 4. Opponent identification. 5. Interrupt. Users do not always want to wait until the program finish work. GoGui uses comment #interrupt to do it, but this is a hack. (this is somewhat related to 1.) 6. Position setup. I had conversation with Marcus about setup in GoGui. And we concluded that there should be a separate command for that. Would You like to have those issues solved? I hope we can get somewhere. :) Best Regards, Łukasz ___ 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/
Re: [computer-go] GTPv3
On 2-mrt-07, at 16:34, Don Dailey wrote: Łukasz, Yes, I would like to see some of these problems solved. As I mentioned, UCI doesn't have any of these issues. After thinking about this, there is perhaps a backwards compatible solution: 1. Don't change GTP, just add to it. 2. Have a command called asyncronous which tells the engine that it supports the new asyncronous protocol. (Or maybe the response to the protocol_version command is enough) 3. If the engine suports this, then it can accept commands like stop_search and it can send certain informational commands. I think this may be a viable solution. Better in my opinion than defining asynchronous commands. Of course the current division betweem controller and engine make things easy. But it also inhibits some more sophisiticated behaviour. If the two parts can communicate what they do and don't support I think it's should be possible to allow for two-way communication. Whoever doesn't want to go through the trouble can still only support the simpe master-slave setup that it currently is. Mark ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
[computer-go] GTPv3
Hi, There are some issues that are not so well defined in GTP v2. Maybe GTP v3 should be released to avoid too much legacy later? 1. The most important thing is controller - engine architecture. There are situations that engine would like to have the control. For instance When he want to send commands to GUI to draw something while he is working. In gogui this is solved by using stderr to send those commands, but: - stderr is not network transparent - syntax is not standardized - there is no confirmation about success / failure for those commands. 2. The second thing is that there are many variables in the engine (komi, board size, time, etc). Developers tend to have more of them to control various parameters of the engine. End users could like to have some control over strength of the algorithm, etc. 3. If GTP would supports chats, KGS would probably implement it. 4. Opponent identification. 5. Interrupt. Users do not always want to wait until the program finish work. GoGui uses comment #interrupt to do it, but this is a hack. (this is somewhat related to 1.) 6. Position setup. I had conversation with Marcus about setup in GoGui. And we concluded that there should be a separate command for that. Would You like to have those issues solved? I hope we can get somewhere. :) Best Regards, Łukasz ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
Hi Łukasz, Maybe something could be borrowed from UCI, the universal chess interface. It is a really well designed protocol that serves the same purpose as GTP does for go, but it's for chess. It's about at the same point GTP is, most chess programs support it and interfaces are available for it. http://www.uciengines.de/UCI_Protocol/uci_protocol.html I'm not suggesting we switch protocols, but perhaps we could take a look at UCI and borrow some of it's better features for an updated GTP. Now, it's about time someone posts that we should be on the GTP list :-) - Don On Thu, 2007-03-01 at 13:22 +0100, Łukasz Lew wrote: Hi, There are some issues that are not so well defined in GTP v2. Maybe GTP v3 should be released to avoid too much legacy later? 1. The most important thing is controller - engine architecture. There are situations that engine would like to have the control. For instance When he want to send commands to GUI to draw something while he is working. In gogui this is solved by using stderr to send those commands, but: - stderr is not network transparent - syntax is not standardized - there is no confirmation about success / failure for those commands. 2. The second thing is that there are many variables in the engine (komi, board size, time, etc). Developers tend to have more of them to control various parameters of the engine. End users could like to have some control over strength of the algorithm, etc. 3. If GTP would supports chats, KGS would probably implement it. 4. Opponent identification. 5. Interrupt. Users do not always want to wait until the program finish work. GoGui uses comment #interrupt to do it, but this is a hack. (this is somewhat related to 1.) 6. Position setup. I had conversation with Marcus about setup in GoGui. And we concluded that there should be a separate command for that. Would You like to have those issues solved? I hope we can get somewhere. :) Best Regards, Łukasz ___ 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/
Re: [computer-go] GTPv3
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/
Re: [computer-go] GTPv3
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 I would like to suggest using the command setup_sequence instead to miror the play_sequence command which was introduced by GoGui (I believe).___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
Re: [computer-go] GTPv3
On Thursday 01 March 2007, Phil G wrote: I would like to suggest using the command setup_sequence instead to miror the play_sequence command which was introduced by GoGui (I believe). I finally followed the GTP (draft) standard and used a prefix separated by a hyphen for non-standard extension commands, so play_sequence became gogui-play_sequence. setup_sequence wouldn't be a good name, because the setup stones are not a sequence, you can specify them in any order. There will also be a second command gogui-setup_player for setting the color to play, but support for that is optional, since it is not strictly necessary that the engine is informed about the color to play. The genmove and play commands are sent with a color argument anyway. If an engine does not support gogui-setup, setup stones will be sent as moves as previously. - Markus ___ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
