gtp

gtp@lists.lysator.liu.se

164 discussions

Re: Metamachine
by William M. Shubert 28 Aug '01

28 Aug '01

Problem 1 is caused because you are probably overriding the default SIGHUP signal. When a parent process dies, the child process recieves SIGHUP; the default SIGHUP handler calls exit, but if you override it before the fork, then it will stay overridden, and thus you will not die when your parent exits. If you really need SIGHUP to stay overridden in the parent (I can't see why, but you must have a reason), then after the fork you should call "signal(SIGHUP, SIG_DFL)" to return to the standard behavior. Problem 2 I will leave up to somebody else, since I don't have the gnugo code handy. :-) PROBLEM 1: It doesn't kill the gnugo process when it exits. (Run it a few times then ask yourself where all your memory went.) What's the right way to do this? PROBLEM 2: It hangs when called from twogtp. I can't figure out why. -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>

3 2

Metamachine
by Daniel Bump 28 Aug '01

28 Aug '01

I'm enclosing a c file at the end of this. It makes a program called metamachine. I have certain plans for this but that's a long story I'll have to explain later. In a nutshell I want GNU Go to be able to clone itself (hash, persistent cache and all) then ask the clone questions. At the moment, this program is working, or seems to work, but there's a couple of problems I need help with. It emulates a gtp engine by spawning a copy of gnugo and passing commands from stdin to the engine, getting the response, then passing them back to stdout. Though useless in itself, this could be made useful with a bit of work: hack in gmp.c and get a gtp/gmp translator. I'm not a big unix hacker but wrote this after studying Chapter 6 of Rochkind's "Advanced Unix Programming" and the libc doc. As I said, it seems to work: $ metamachine boardsize 9 = komi 5.5 = showboard A B C D E F G H J 9 . . . . . . . . . 9 8 . . . . . . . . . 8 7 . . + . . . + . . 7 6 . . . . . . . . . 6 5 . . . . + . . . . 5 4 . . . . . . . . . 4 3 . . + . . . + . . 3 2 . . . . . . . . . 2 WHITE has captured 0 stones 1 . . . . . . . . . 1 BLACK has captured 0 stones A B C D E F G H J = genmove_black = G7 PROBLEM 1: It doesn't kill the gnugo process when it exits. (Run it a few times then ask yourself where all your memory went.) What's the right way to do this? PROBLEM 2: It hangs when called from twogtp. I can't figure out why. Dan #include <stdio.h> #include <unistd.h> void error(const char *msg); /* This program uses two pipes to communicate with the * GNU Go client. To an external client it appears to * be a gtp engine. It accomplishes this by intercepting * gtp commands and passing them on to GNU Go. * * This program in and of itself is not useful but it * can be the basis of useful programs. Example: hack * in gmp.c and get a gtp / gmp translator. * * Bugs: the spawned process isn't killed when the * program terminates. Hangs when called from twogtp. (Why?) * * Pipe a: client --> gnugo * Pipe b: gnugo --> client */ int main() { int pfd_a[2]; int pfd_b[2]; char gnugo_line[128], client_line[128]; int length = 0; FILE *to_gnugo_stream, *from_gnugo_stream; if (pipe(pfd_a) == -1) error("can't open pipe a"); if (pipe(pfd_b) == -1) error("can't open pipe b"); switch(fork()) { case -1: error("fork failed (try chopsticks)"); case 0: /* Attach pipe a to stdin */ if (close(0) == -1) error("close(0) failed"); if (dup(pfd_a[0]) != 0) error("dup pfd_a[0] failed"); /* attach pipe b to stdout" */ if (close(1) == -1) error("close(1) failed"); if (dup(pfd_b[1]) != 1) error("dup pfd_b[1] failed"); execlp("gnugo", "gnugo", "--mode", "gtp", "--quiet", NULL); error("execlp failed"); } /* We use stderr to communicate with the client since stdout is needed. */ /* Attach pipe a to to_gnugo_stream */ to_gnugo_stream = fdopen(pfd_a[1], "w"); /* Attach pipe b to from_gnugo_stream */ from_gnugo_stream = fdopen(pfd_b[0], "r"); while (1) { int length = 0; if (!fgets(client_line, 128, stdin)) error("can't get command\n"); if (!strncmp(client_line, "quit", 4)) return 1; if (fprintf(to_gnugo_stream, "%s", client_line) < 0) error("can't write command to to_gnugo_stream"); fflush(to_gnugo_stream); while (length != 1) { if (!fgets(gnugo_line, 128, from_gnugo_stream)) error("can't get response"); length = strlen(gnugo_line); printf(gnugo_line); } } } void error(const char *msg) { fprintf(stderr, "metamachine: %s\n", msg); abort(); }

1 0

Re: I like to help with the GO project
by Daniel Bump 25 Aug '01

25 Aug '01

Heikki wrote: > When changing this, could we add human-readable comments to the codes? > Something like > = 1 B8 (Can live) > = 2 B8 (kill with good ko) GNU Go sends most gtp responses to stout but showboard writes to stderr. Perhaps responses intended for human consumption should go to stderr and should not be part of the specification. I see Phil's draft specification is now up on the web in a form I can read (html). It states: > The end-of-line is defined as either CR or LF: > EOL = CR or LF I know Gunnar didn't like this. The GNU Go 3.0.0 doc says this: > Newlines are implemented differently on different operating systems. > On Unix, a newline is just a line feed LF (ascii \012). On DOS/Windows > it is CRLF (\013\012). Thus whether GNU Go sends a carriage return with > the line feed depends on which platform it is compiled for. The arbiter > should silently discard carriage returns. Perhaps the doc should say that EOL is defined as LF and that an optional CR will be silently discarded by the arbiter. Dan

2 1

Re: I like to help with the GO project
by Daniel Bump 25 Aug '01

25 Aug '01

1 0

RE: [gtp] GTP Specification-Draft
by Cabrera, Alan 21 Aug '01

21 Aug '01

You make some good points Don. It seems that the implicit scenario here is that you will always thoroughly know your opponent's engine. Since this may currently be the case, especially in this small computer-go clique, then I see your point. Will that always be true? For non-tournament play, it seems like pickup games will be the norm and hence this group's extended discussion about non-tournament commands. In this case, having a priori knowledge of your opponent's engine may not be reasonable. I think that auto-negotiation would solve that. I guess what I'm really lobbying for is an auto-negotiation phase, using whatever protocol specification. This auto-negotiation phase is not needed for tournament play though. Alan > -----Original Message----- > From: Don Dailey [mailto:drd@supertech.lcs.mit.edu] > Sent: Tuesday, August 21, 2001 9:27 AM > To: adc(a)multex.com > Cc: wms(a)igoweb.org; adc(a)multex.com; gtp(a)lists.lysator.liu.se > Subject: Re: [gtp] GTP Specification-Draft > > > > Hi Alan, > > I seriously doubt this is actually a big problem. I would suggest > that all GTP based tools document the commands they expect and what > the affect those commands would have if they are not implemented. > > Also, I would expect that most GTP based tools will not crash but > simply do whatever is most appropriate and graceful. > > I also agree with William about the relative importance of this. > Really, you shouldn't attach an engine to something at the last minute > without thorough testing if it's something really important. And if > it's really important, such as a tournament autoplayer, it should be > pretty well documented and hopefully freely available beforehand. > > Don > > > > > From: "Cabrera, Alan" <adc(a)multex.com> > Cc: GTP Mailing List <gtp(a)lists.lysator.liu.se> > > > From: William M. Shubert [mailto:wms@igoweb.org] > > > > Yes, this will be irritating. But that's why, if you > choose not to > > implement every GTP command, you should run a few tests when > > you first > > attach your engine to a new GTP system to ensure that > you support all > > the commands needed. Then you do the "real" work with it. > > Well here's where we get to the crux of my point. I'm not > wedded to that > particular protocol snippet, I just have a feeling that > we're glossing over > an important, albeit boring, aspect of this protocol. > When you say "you > should run a few tests when you first attach your engine > to a new GTP system > to ensure that you support all the commands needed", I say > fine, but the > devil is in the details and I want to know how exactly > this gets done. > > > I see your point, I just think that the handshaking you > proposed will > > add a significant complexity and will probably be just as > > error-prone as > > the "try it and see" system I recommend...I know that were I to > > implement this system, I'd probably find my bugs in the > > "main" GTP part > > pretty quick, but it would be easy to screw up the > > protocol-checking and > > never notice since it wouldn't get exercised in as many > different > > situations. > > I don't see where it's more error prone, at least no more > so than any other > command; we're not talking TCP/IP here. All you have to > do is exchange the > hand full of command set names and move on. > > Now let me first state this, not everyone is going to > implement the full > porotocol; that much is clear from what I've been reading > here. To me this > implies that I have a valid concern here. With that said, > let me go over a > use case. If the case isn't relevant, please chime up. > > We hook up, I run through a all of commands that I want to > use to see which > ones you support. Now through dumb luck, I happen to run > through a valid > sequence one quarter of the way through when I present a > command that you > don't support. You return a "not implemented". By the > time we're done, I > have to keep track of all those little commands that you > don't support; this > is quite a complex endevor. Your machine and my machine > are in a wacky > state, because of the testing. You may have even > succeeded in crashing my > machine by sending in that one non-sensical sequence > required to put me into > a bad state. > > Now what if we just exchanged the two or three command set > names? In my GTP > implementation, I'm asumming my protocol, there would be > two or three > command handler classes, one for each command set. If > there's a command set > that you don't handle, I de-register that command set handler. > > Now someone may say, "My gift to the computer go community > shall be a GTP > implementation that will handle all these minor points." > I would reply, at > some point, my engine will still need to keep track of > what commands and > features it can use/support and which ones it can't. > Using named command > sets simplifies this tracking. > > So my point is that for every non-tournement hookup, > almost everyone will > *have* to do this to see what commands they can use. It's > a grey area that > I think needs to be cleared up with me being partial to my > proposal. > > > Alan > > > > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp >

2 1

Re: [gtp] End-of-line
by Dave Denholm 21 Aug '01

21 Aug '01

Gunnar Farnebäck <gunnar(a)lysator.liu.se> writes: > 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. What about lines containing only whitespace ? Are they considered empty, and so not echo-ed, or are they echo-ed ? I have one small niggling concern with this... It sees we wish to allow controlling programs to be lax about how they terminate lines. ie the controller is not required to know exactly what it's sending. However, because the protocol is a request-response protocol, it is vital that both sides know whether a response is expected. If the controller thinks a response is required, but the engine doesn't, then it could deadlock. Being woolley about line termination could possibly result in such a situation. I suspect the current proposal is safe, but it's something to bear in mind... dd -- dave.denholm(a)insignia.com http://www.insignia.com

2 1

RE: [gtp] GTP Specification-Draft
by Cabrera, Alan 21 Aug '01

21 Aug '01

> From: William M. Shubert [mailto:wms@igoweb.org] > > Yes, this will be irritating. But that's why, if you choose not to > implement every GTP command, you should run a few tests when > you first > attach your engine to a new GTP system to ensure that you support all > the commands needed. Then you do the "real" work with it. Well here's where we get to the crux of my point. I'm not wedded to that particular protocol snippet, I just have a feeling that we're glossing over an important, albeit boring, aspect of this protocol. When you say "you should run a few tests when you first attach your engine to a new GTP system to ensure that you support all the commands needed", I say fine, but the devil is in the details and I want to know how exactly this gets done. > I see your point, I just think that the handshaking you proposed will > add a significant complexity and will probably be just as > error-prone as > the "try it and see" system I recommend...I know that were I to > implement this system, I'd probably find my bugs in the > "main" GTP part > pretty quick, but it would be easy to screw up the > protocol-checking and > never notice since it wouldn't get exercised in as many different > situations. I don't see where it's more error prone, at least no more so than any other command; we're not talking TCP/IP here. All you have to do is exchange the hand full of command set names and move on. Now let me first state this, not everyone is going to implement the full porotocol; that much is clear from what I've been reading here. To me this implies that I have a valid concern here. With that said, let me go over a use case. If the case isn't relevant, please chime up. We hook up, I run through a all of commands that I want to use to see which ones you support. Now through dumb luck, I happen to run through a valid sequence one quarter of the way through when I present a command that you don't support. You return a "not implemented". By the time we're done, I have to keep track of all those little commands that you don't support; this is quite a complex endevor. Your machine and my machine are in a wacky state, because of the testing. You may have even succeeded in crashing my machine by sending in that one non-sensical sequence required to put me into a bad state. Now what if we just exchanged the two or three command set names? In my GTP implementation, I'm asumming my protocol, there would be two or three command handler classes, one for each command set. If there's a command set that you don't handle, I de-register that command set handler. Now someone may say, "My gift to the computer go community shall be a GTP implementation that will handle all these minor points." I would reply, at some point, my engine will still need to keep track of what commands and features it can use/support and which ones it can't. Using named command sets simplifies this tracking. So my point is that for every non-tournement hookup, almost everyone will *have* to do this to see what commands they can use. It's a grey area that I think needs to be cleared up with me being partial to my proposal. Alan

2 1

RE: [gtp] GTP Specification-Draft
by Cabrera, Alan 21 Aug '01

21 Aug '01

Fine. I have a tendency to over engineer things at times. But lets say that we're half way through a game and I need a command, one that we haven't encounted in our exchange, that I think is critical. When you return a "not implemented" to that command, my program quits and closes the connection. Wouldn't that be a terribly irritating experience? Maybe this scenario would be seldom encountered. Thoughts? > -----Original Message----- > From: William M. Shubert [mailto:wms@igoweb.org] > Sent: Monday, August 20, 2001 10:28 PM > To: GTP Mailing List > Subject: Re: [gtp] GTP Specification-Draft > > > I agree with Gunnar, this seems needlessly complex. If I write GTP > program, I'll provide a README telling users what commands > they need. If > they return "not implemented" to one of those commands, my > program will > either a) ignore this (if the command isn't terribly imporant) or b) > quit and close the connection (if the command was critical). I'm > definitely not going to spend my time writing my code to try > to figure > out whether or not the engine is "good enough" beforehand. > > The only set of features that we need completely defined IMHO is the > tournament features, because we want to be sure that > everybody can play > in the tournament before they get there. Otherwise, we can design > commands with a use in mind (such as the "load SGF file" > command used by > a test system), but if somebody writes a test system that doesn't use > the "load SGF file" command that's fine, and people who use that test > system can just skip doing that command in their engines. > > Alan wrote: > >/ Well, I think that we may need commands where the machines can > />/ announce to each other what command sets they support. > Once that is > />/ done, each machine will announce what command sets they intend to > />/ use for that session. Maybe something like: > / > I don't see the need for this. > > >/ begin_command_sets_available > />/ tournament > />/ player_to_player > />/ end_command_sets_available > />/ begin_command_sets_used > />/ tournament > />/ end_command_sets_used > />/ > />/ or: > />/ > />/ begin_command_sets_available > />/ tournament > />/ player_to_player > />/ end_command_sets_available > />/ session_rejected > />/ > />/ if the machine does not wish to continue/ > And this is just plain ugly. > > /Gunnar > > > -- > > Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> > http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/> > > > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp >

2 1

Re: [gtp] Re: VC regression failures
by Dave Denholm 21 Aug '01

21 Aug '01

Daniel Bump <bump(a)match.Stanford.EDU> writes: > I'm cc'ing both the GNU Go list and the GTP list because this is > a protocol issue. > > To summarize, Trevor Morris reports that the GNU Go regressions are broke on > Visual C. The reason is that apparently printf on VC++ interprets \n as CRLF > instead of just LF. AFAIK VC is doing the correct thing : \n is defined to expand to whatever line ending is appropriate for the platform. [ I would be inclined to blame the awk for not understanding CRLF when reading in text on a dos-like machine. Possibly a feature of cygwin tools, since someone at work here had similar problems which turned out to be do with the tools not processing CR as I would have expected them to. ] I think I did mention this feature of \n | \r, and pointed out that any portable implementations of GTP code should use \012 explicitly if they mean a LF character. > > I think this is an issue which was discussed in the protocol list > but I do not remember whether any conclusions were reached. > > Trevor Morris wrote: > > > >Do you mean that the gtp output > > >is getting spurious CR's added by the DOS version of the > > >program? > > > > Yes, this is the problem. Spurious CR added by the DOS version of the > > program. An appropriate sed script to strip out the offending ^M > > characters should do it. > > > > Perhaps the GTP needs to explicitly define what the end-of-line character(s) > > should be? > > We can simulate this problem on Linux by replacing all occurrences > of \n by \r\n in gtp.c. I just did that and found that regress.sh > is broke but twogtp is not. That wouldn't help since on windows that would (may) give CRCRLF And on mac, \n is CR \012 is probably safest if you really mean a LF character > > One difference between the two is that regress.sh is awkward where twogtp is > perlward. Perhaps we should reimplement regress.sh in perl. FWIW, the regress script doesn't work properly with /usr/bin/awk on solaris. Need to use nawk instead. perl is probably slightly better defined, and therefore more portable. dd -- dave.denholm(a)insignia.com http://www.insignia.com

6 7

RE: [gtp] GTP Specification-Draft
by Cabrera, Alan 21 Aug '01

21 Aug '01

So what's the point in partitioning the commands into all these sets? Why not just have two buckets, required and optional? > -----Original Message----- > From: Phil Garcia [mailto:PhilippGarcia@Home.com] > Sent: Monday, August 20, 2001 8:46 PM > To: gtp(a)lists.lysator.liu.se > Subject: Re: [gtp] GTP Specification-Draft > > > The help command will return a list of implemented commands. > > ----- Original Message ----- > From: "Cabrera, Alan" <adc(a)multex.com> > To: "'Gunnar Farnebäck'" <gunnar(a)lysator.liu.se>; > <gtp(a)lists.lysator.liu.se> > Sent: Monday, August 20, 2001 5:22 PM > Subject: RE: [gtp] GTP Specification-Draft > > > > From: Gunnar Farnebäck [mailto:gunnar@lysator.liu.se] > > > > Alan wrote: > > > Well, I think that we may need commands where the machines can > > > announce to each other what command sets they support. > Once that is > > > done, each machine will announce what command sets they intend to > > > use for that session. Maybe something like: > > > > I don't see the need for this. > > So when do two programs discover when a command set is not supported? > > > > begin_command_sets_available > > > tournament > > > player_to_player > > > end_command_sets_available > > > begin_command_sets_used > > > tournament > > > end_command_sets_used > > > > > > or: > > > > > > begin_command_sets_available > > > tournament > > > player_to_player > > > end_command_sets_available > > > session_rejected > > > > > > if the machine does not wish to continue. > > > > And this is just plain ugly. > > Ugly in what way? The actual commands or the idea itself? > > > Alan > > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp > > > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp >

2 1

← Newer
1
...
9
10
11
12
13
14
15
16
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

gtp