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