IMO debugging commands are not needed in the protocol. Everyone can add his/her extensions. A program is free to send output to files/pipes/network -connecions, if it wants to. Or stderr. But stdin/stdout are supposed to obey the standard, which basically says: one line commands -->> responses, ended by empty line. BTW. I have been working on a NNGS<-->gtp gateway which can be controlled via nngs talk/tell. It could dump it's stderr to a NNGS channel (which could be restricted to the operator) In gunnar's case, this is of course nonsense -controlling a machine that is located on his desk via NNGS- , but it is an elegant way to interact with a *playing* go- playing-program. (it *could* be used for cheating: the turk on the desk :-)) AvK
Dear Adriaan,
Thanks for your comments.
However, I beg to disagree that debugging commands are not needed in the protocol.
IMHO stderr should be reserved for programming errors, not engine debug/fine-tuning.
And if everyone starts adding his/her extensions, that would defeat the the purpose of a standard protocol, wouldn't it?
If we include some well thought-out debug commands in the standard, then a nice GUI client can be used to debug any number of engines, without having to rewrite its back-end.
But if each engine has a different way of communicating debug messages to the "outer world", then the GUI client will have to be partly rewritten for each engine. That is a waste of time and energy, and would discourage any programmer.
Since we are starting with a new protocol now, and engines will be written for it in the future, it seems more logical to provide a framework for engine debugging at this stage.
Well, that is just my $0.02, after rewriting Wally and AmiGo to conform to GTP V 2.
Regards,
Andrew
On Saturday 05 October 2002 00:04, A van Kessel wrote:
IMO debugging commands are not needed in the protocol. Everyone can add his/her extensions. A program is free to send output to files/pipes/network -connecions, if it wants to. Or stderr. But stdin/stdout are supposed to obey the standard, which basically says: one line commands -->> responses, ended by empty line. BTW. I have been working on a NNGS<-->gtp gateway which can be controlled via nngs talk/tell. It could dump it's stderr to a NNGS channel (which could be restricted to the operator) In gunnar's case, this is of course nonsense -controlling a machine that is located on his desk via NNGS- , but it is an elegant way to interact with a *playing* go- playing-program. (it *could* be used for cheating: the turk on the desk :-)) AvK _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
Just my 2 cents, and only my opinion ...
The debug protocol would definitely be useful, but my personal preference is that we shouldn't add it to the protocol just yet.
We still need to "consolidate" which means we need to finalize it, gain a lot of experience using it, and certainly we need to focus on gaining wide acceptance of it.
Based on my latest viewing of the protocol, it seems quite well done, and obviously well thought out. It seems to be complete without being bloated or overdone.
Don
Content-Type: text/plain; charset="iso-8859-1" From: Andrew Derrick Balsa andrebalsa@mailingaddress.org User-Agent: KMail/1.4.3 X-Spam-Status: No, hits=-4.1 required=5.0 tests=IN_REP_TO,DEAR_SOMEBODY version=2.31 Sender: gtp-admin@lists.lysator.liu.se X-BeenThere: gtp@lists.lysator.liu.se X-Mailman-Version: 2.0.11 Precedence: bulk List-Unsubscribe: http://lists.lysator.liu.se/mailman/listinfo/gtp, mailto:gtp-request@lists.lysator.liu.se?subject=unsubscribe List-Id: Discussion about the computer-go protocol GTP. <gtp.lists.lysator.liu.se> List-Post: mailto:gtp@lists.lysator.liu.se List-Help: mailto:gtp-request@lists.lysator.liu.se?subject=help List-Subscribe: http://lists.lysator.liu.se/mailman/listinfo/gtp, mailto:gtp-request@lists.lysator.liu.se?subject=subscribe List-Archive: http://lists.lysator.liu.se/pipermail/gtp/ Date: Mon, 7 Oct 2002 15:35:33 +0800 X-MIME-Autoconverted: from quoted-printable to 8bit by theory.lcs.mit.edu id g977uMgr017221
Dear Adriaan,
Thanks for your comments.
However, I beg to disagree that debugging commands are not needed in the protocol.
IMHO stderr should be reserved for programming errors, not engine debug/fine-tuning.
And if everyone starts adding his/her extensions, that would defeat the the purpose of a standard protocol, wouldn't it?
If we include some well thought-out debug commands in the standard, then a nice GUI client can be used to debug any number of engines, without having to rewrite its back-end.
But if each engine has a different way of communicating debug messages to the "outer world", then the GUI client will have to be partly rewritten for each engine. That is a waste of time and energy, and would discourage any programmer.
Since we are starting with a new protocol now, and engines will be written for it in the future, it seems more logical to provide a framework for engine debugging at this stage.
Well, that is just my $0.02, after rewriting Wally and AmiGo to conform to GTP V 2.
Regards,
Andrew
On Saturday 05 October 2002 00:04, A van Kessel wrote:
IMO debugging commands are not needed in the protocol. Everyone can add his/her extensions. A program is free to send output to files/pipes/network -connecions, if it wants to. Or stderr. But stdin/stdout are supposed to obey the standard, which basically says: one line commands -->> responses, ended by empty line. BTW. I have been working on a NNGS<-->gtp gateway which can be controlled via nngs talk/tell. It could dump it's stderr to a NNGS channel (which could be restricted to the operator) In gunnar's case, this is of course nonsense -controlling a machine that is located on his desk via NNGS- , but it is an elegant way to interact with a *playing* go- playing-program. (it *could* be used for cheating: the turk on the desk :-)) AvK _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
-- Andrew D. Balsa andrebalsa@mailingaddress.org _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp
-
A van Kessel -
Andrew Derrick Balsa -
Don Dailey