In the specification, the end-of-line will be either a linefeed or carriage return. Empty lines are to be disregard and no output will be sent back.
Phil
Phil wrote:
In the specification, the end-of-line will be either a linefeed or carriage return. Empty lines are to be disregard and no output will be sent back.
You mean: "In my draft proposal for the specification, the end-of-line will be..."
Just to make things clear, I have no intention of delegating the decisions that needs to be made about the protocol. I do need input from other Go programmers to be able to make good decisions and I do need help with writing a useful standard text. Actually I could write it myself, but it would most likely take longer. Still that's the way I'll go if I have to.
/Gunnar
Point very well taken - and one of which I am aware of. This is the appropriate forum for being up being up such issues. For simplistic and effectiveness, when I see consensus on an issue in this mailing list, I will document it and announce it. We may, of course, change it afterwards through discussion.
Is this a fair way of going about this?
----- Original Message ----- From: "Gunnar Farnebäck" gunnar@lysator.liu.se To: gtp@lists.lysator.liu.se Sent: Monday, August 20, 2001 1:23 PM Subject: Re: [gtp] End-of-line
Phil wrote:
In the specification, the end-of-line will be either a linefeed or carriage return. Empty lines are to be disregard and no output will be sent back.
You mean: "In my draft proposal for the specification, the end-of-line will be..."
Just to make things clear, I have no intention of delegating the decisions that needs to be made about the protocol. I do need input from other Go programmers to be able to make good decisions and I do need help with writing a useful standard text. Actually I could write it myself, but it would most likely take longer. Still that's the way I'll go if I have to.
/Gunnar _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
Phil wrote:
Point very well taken - and one of which I am aware of.
Good.
This is the appropriate forum for being up being up such issues. For simplistic and effectiveness, when I see consensus on an issue in this mailing list, I will document it and announce it. We may, of course, change it afterwards through discussion.
Is this a fair way of going about this?
Committees are not generally known to be very good at making standards, thus consensus is not the key issue here. It's more important to get a technically consistent specification which works well in practice. To this end I will take the liberty of having the final word on the specification. You other people have to trust my judgement and be sure to tell me if I should happen to make some fatal mistake. With the experience of using the (early stages) of the protocol for more than a year and having implemented both ends (in GNU Go and gnugoclient) as well as having written a go server (not released) and a GMP implementation (early unreleased version of gnugoclient), I think I'm fairly well qualified to do this.
In the specification, the end-of-line will be either a linefeed or carriage return. Empty lines are to be disregard and no output will be sent back.
No, it will be my proposal unless someone convinces me that it will cause major problems. The argument that there exists three different newline conventions for text files is not convincing.
In the specification, the commands "white" and "black" will be superceeded by a new command, "move" which takes the "white" or "black' as parameter in addition to the coordinate. Also commands "genmove_black" and "genmove_white" change similarily to "genmove". This also reduces the number of standard commands.
"genmove_black" and "genmove_white" will indeed be replaced by a single "genmove" command. The replacement for "white" and "black" will be called "play".
A "setup" command is also being added to support setting up freely placed handicap positions. The "setup" command is only valid before the first "move" or "genmove" is issued. This is similar to SGF.
Free placement handicap needs some more thinking. Setup should be useful for any kind of position.
A final note, the protocol_version of this specification will be "2" - to distinguish itself from the previous implementations.
Yes, more or less. Protocol version 1 will be whatever is implemented in GNU Go 3.0.0 when this is released and should only be used by other programs which wish to experiment with the gnugoclient 2.0 or twogtp programs. The first fully specified protocol will be version 2. I expect this to be followed by a version 3 and possibly more when it becomes clear what is missing or done wrong in the protocol. This means I definitely don't expect version 2 to be final and complete but I do expect it to be finished in a not too far future.
/Gunnar
-
Gunnar Farneb�ck -
Joan Pons i Semelis -
Phil -
Phil Garcia