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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
Ł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
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
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
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
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
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
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
40 matches
Mail list logo
