gtp August 2001

gtp@lists.lysator.liu.se

20 participants
58 discussions

Server Commands
by William M. Shubert 04 Sep '01

04 Sep '01

Well things have been quiet lately, so I think I'll put out a set of commands for server play to think about. I've been going from Phil's straw man version of the spec; Phil, you can plug these into the next revision if you want. It seems that only 5 more commands are needed. The trickiest thing is setting up games; and the related problem of specifying the server game exactly when somebody challenges the program. To do things well, we need to be able to tell the engine exactly what the time system is. Engines can choose to ignore this of course. Having written a client for IGS/NNGS/etc. and for KGS, I'm pretty sure that these five commands will give us the functionality we need for all these servers. If anybody has information on dashn, cyberkiwon, etc., and thinks this will have to be changed for them, that's no problem. ********************************************************************** GTP commands for go servers ---------------------------------------------------------------------- Command: play_mode This is the bridge's attempt to find out whether the go engine is looking for games, or if it intends to play a particular game vs. a particular opponent. Engine Responses: If the engine is in general looking for games: any If the engine is looking to play a particular opponent, with particular settings: <color> <user> <handicap> <handicap fixed?> <ko setting> <suicide> <scoring system> <time system> Time system format: <style>[,<main_time>[,<byo-yomi time>,(<stones>|<# of periods>)]] <style> is one of "none", "absolute", "canadian", "byoyomi" ---------------------------------------------------------------------- Command: game_ok <color> <user> <handicap> <handicap fixed?> <ko setting> <suicide> <scoring system> <time> This is the bridge's query to the engine, as to whether a particular game is acceptable. Note that the arguments are exactly the same as the response to "play_mode". Engine Responses: "y" or "n" "y" will probably be followed soon by a serios of "komi", "board_size", etc. commands then finally a "new_game". ---------------------------------------------------------------------- Command: undo_ok Here the bridge is saying that the opponent wants an undo. The engine can allow or disallow. Responses: "y" or "n" ---------------------------------------------------------------------- Command: query_dead The game is over. The brige is asking the engine what stones it thinks are dead. If the engine does not know, then it answering with a not implemented error is OK...in this case, it will be up to the opponent to decide which stones are dead. responses: List all locations on the board that contain dead stones. ---------------------------------------------------------------------- Command: time_left <color> <seconds left in period> [<stones left>] The server is telling the engine how much time is left on the clocks for the color specified. The time reported should be the server's idea of how much time is left, so if there is netlag the engine's clock will not drift from the server's. ---------------------------------------------------------------------- Command: comment The server is telling you that somebody is trying to talk to the engine. Any text in the response will be sent back to the user who was talking. ********************************************************************** -- Bill Shubert (wms(a)igoweb.org) <mailto:wms@igoweb.org> http://www.igoweb.org/~wms/ <http://igoweb.org/%7Ewms/>

2 1

Re: [gtp] Re: Metamachine
by Daniel Bump 28 Aug '01

28 Aug '01

Thanks, David, now it's working. After I saw your message I added fflush(stdout) after the printf to gnugo. That isn't the first thing I tried but I don't really want to tell everyone how stupid I was. But now that I've rebooted my computer ... This may have fixed the other problem too which was apparently caused by the EOF that comes down stdin when you type a ^D (one way to terminate metamachine) not getting flushed. Unclear, but I don't have a lingering gnugo process this time. The current (working) version looks like this. 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. * * 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)) { fprintf(to_gnugo_stream, "%s", "quit\n"); fflush(to_gnugo_stream); 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); fflush(stdout); } } } void error(const char *msg) { fprintf(stderr, "metamachine: %s\n", msg); abort(); }

2 2

Re: Metamachine
by Dave Denholm 28 Aug '01

28 Aug '01

Daniel Bump <bump(a)match.Stanford.EDU> writes: > David wrote: > > > > I have an email from David referring to man IPC::Open2 > > > on the dangers of open2. But I can't say I really > > > understand why this deadlock occurs or how it can be > > > avoided. > > > > The problem is that when you do fprintf(), there is no > > guarantee that the data has actually been written out of > > the process buffers. So process A thinks it has sent the > > command and is blocked waiting for the reply. But the > > message is still in A's stdio buffers, and so process > > is still blocked waiting to read it. => deadlock. > > But in this case the printf is done by the perl twogtp > command: > > print $black_in "boardsize $size\n"; > > Here $black_in is the file descriptor created with: > > $pidb = open2($black_out, $black_in, $black); > > and man IPC::Open2 says: > > The write filehandle will have autoflush turned on. > > Doesn't this mean that the data should have been written > out of the buffer? > (BTW forget about the bit I wrote previously about stdin being set up before files are changed : I had misremembered how the code worked... ) Let's see... I ran strace -f on that command line, and separated the output from the three processes. pid 22039 = perl, starting after the fork. pid 22040 = metamachine pid 22041 = the gnuogo spawned by perl pid 22042 = the gnugo spawned by metamachine (The last few lines of trace are the most useful) We can clearly see that the boardsize command left process 22039 on fid 4, but no reply arrived on fid 5. The boardsize command arrived in pid 22040 on fid 0. It looks like the reply "= \n\n" arrived, but was not send back to the perl process. The boardsize command arrived in pid 22042, and the "= \n\n" reply was sent. So it looks like a buffering problem in metamachine, where it is not flushing the reply from gnugo back to its parent. dd perl ---- [pid 22039] close(3) = 0 [pid 22039] munmap(0x40194000, 4096) = 0 [pid 22039] close(6) = 0 [pid 22039] munmap(0x4019e000, 4096) = 0 [pid 22039] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 [pid 22039] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 [pid 22039] pipe([3, 6]) = 0 [pid 22039] fcntl(3, F_GETFL) = 0 (flags O_RDONLY) [pid 22039] fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22039] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40194000 [pid 22039] _llseek(3, 0, 0xbffff880, SEEK_CUR) = -1 ESPIPE (Illegal seek) [pid 22039] fcntl(6, F_GETFL) = 0x1 (flags O_WRONLY) [pid 22039] fstat(6, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22039] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4019e000 [pid 22039] _llseek(6, 0, 0xbffff878, SEEK_CUR) = -1 ESPIPE (Illegal seek) [pid 22039] fcntl(3, F_SETFD, FD_CLOEXEC) = 0 [pid 22039] fcntl(6, F_SETFD, FD_CLOEXEC) = 0 [pid 22039] pipe([7, 8]) = 0 [pid 22039] fcntl(7, F_GETFL) = 0 (flags O_RDONLY) [pid 22039] fstat(7, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22039] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4019f000 [pid 22039] _llseek(7, 0, 0xbffff880, SEEK_CUR) = -1 ESPIPE (Illegal seek) [pid 22039] fcntl(8, F_GETFL) = 0x1 (flags O_WRONLY) [pid 22039] fstat(8, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22039] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x401a0000 [pid 22039] _llseek(8, 0, 0xbffff878, SEEK_CUR) = -1 ESPIPE (Illegal seek) [pid 22039] fcntl(7, F_SETFD, FD_CLOEXEC) = 0 [pid 22039] fcntl(8, F_SETFD, FD_CLOEXEC) = 0 [pid 22039] fork() = 22041 [pid 22039] close(3) = 0 [pid 22039] munmap(0x40194000, 4096) = 0 [pid 22039] close(8) = 0 [pid 22039] munmap(0x401a0000, 4096) = 0 [pid 22039] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 [pid 22039] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0 [pid 22039] write(4, "boardsize 19\n", 13) = 13 [pid 22039] read(5, <unfinished ...> metamachine ----------- [pid 22040] getpid() = 22040 [pid 22040] close(4) = 0 [pid 22040] munmap(0x40195000, 4096) = 0 [pid 22040] fcntl(3, F_GETFL) = 0 (flags O_RDONLY) [pid 22040] fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22040] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40195000 [pid 22040] _llseek(3, 0, 0xbffff6e0, SEEK_CUR) = -1 ESPIPE (Illegal seek) [pid 22040] fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22040] dup2(3, 0) = 0 [pid 22040] fcntl(0, F_SETFD, 0) = 0 [pid 22040] close(5) = 0 [pid 22040] munmap(0x40196000, 4096) = 0 [pid 22040] fcntl(6, F_GETFL) = 0x1 (flags O_WRONLY) [pid 22040] fstat(6, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22040] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40196000 [pid 22040] _llseek(6, 0, 0xbffff6e0, SEEK_CUR) = -1 ESPIPE (Illegal seek) [pid 22040] fstat(6, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22040] dup2(6, 1) = 1 [pid 22040] fcntl(1, F_SETFD, 0) = 0 [pid 22040] execve("./metamachine", ["./metamachine"], [/* 39 vars */]) = 0 [pid 22040] brk(0) = 0x8049cfc [pid 22040] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 [pid 22040] open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 22040] open("/etc/ld.so.cache", O_RDONLY) = 3 [pid 22040] fstat(3, {st_mode=S_IFREG|0644, st_size=16265, ...}) = 0 [pid 22040] mmap(0, 16265, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 [pid 22040] close(3) = 0 [pid 22040] open("/lib/libc.so.6", O_RDONLY) = 3 [pid 22040] fstat(3, {st_mode=S_IFREG|0755, st_size=4101836, ...}) = 0 [pid 22040] read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210\212"..., 4096) = 4096 [pid 22040] mmap(0, 1001532, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40019000 [pid 22040] mprotect(0x40106000, 30780, PROT_NONE) = 0 [pid 22040] mmap(0x40106000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xec000) = 0x40106000 [pid 22040] mmap(0x4010a000, 14396, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4010a000 [pid 22040] close(3) = 0 [pid 22040] mprotect(0x40019000, 970752, PROT_READ|PROT_WRITE) = 0 [pid 22040] mprotect(0x40019000, 970752, PROT_READ|PROT_EXEC) = 0 [pid 22040] munmap(0x40015000, 16265) = 0 [pid 22040] personality(0 /* PER_??? */) = 0 [pid 22040] getpid() = 22040 [pid 22040] pipe([3, 4]) = 0 [pid 22040] pipe([5, 6]) = 0 [pid 22040] fork() = 22042 [pid 22040] fcntl(4, F_GETFL) = 0x1 (flags O_WRONLY) [pid 22040] brk(0) = 0x8049cfc [pid 22040] brk(0x8049dc4) = 0x8049dc4 [pid 22040] brk(0x804a000) = 0x804a000 [pid 22040] SYS_197(0x4, 0xbffff864, 0x40109d40, 0x8049d08, 0x4) = -1 ENOSYS (Function not implemented) [pid 22040] fstat(4, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22040] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 [pid 22040] _llseek(4, 0, 0xbffff8a4, SEEK_CUR) = -1 ESPIPE (Illegal seek) [pid 22040] fcntl(5, F_GETFL) = 0 (flags O_RDONLY) [pid 22040] fstat(5, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22040] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000 [pid 22040] _llseek(5, 0, 0xbffff8a4, SEEK_CUR) = -1 ESPIPE (Illegal seek) [pid 22040] fstat(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22040] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40017000 [pid 22040] read(0, <unfinished ...> [pid 22040] <... read resumed> "boardsize 19\n", 4096) = 13 [pid 22040] write(4, "boardsize 19\n", 13) = 13 [pid 22040] read(5, <unfinished ...> [pid 22040] <... read resumed> "= \n\n", 4096) = 4 [pid 22040] fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22040] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40018000 [pid 22040] read(0, <unfinished ...> gnugo spawned by perl (not interesting) --------------------- [pid 22041] getpid() = 22041 [pid 22041] close(6) = 0 [pid 22041] munmap(0x4019e000, 4096) = 0 [pid 22041] fcntl(3, F_GETFL) = 0 (flags O_RDONLY) [pid 22041] fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22041] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4019e000 [pid 22041] _llseek(3, 0, 0xbffff6e0, SEEK_CUR) = -1 ESPIPE (Illegal seek) [pid 22041] fstat(3, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22041] dup2(3, 0) = 0 [pid 22041] fcntl(0, F_SETFD, 0) = 0 [pid 22041] close(7) = 0 [pid 22041] munmap(0x4019f000, 4096) = 0 [pid 22041] fcntl(8, F_GETFL) = 0x1 (flags O_WRONLY) [pid 22041] fstat(8, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22041] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4019f000 [pid 22041] _llseek(8, 0, 0xbffff6e0, SEEK_CUR) = -1 ESPIPE (Illegal seek) [pid 22041] fstat(8, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22041] dup2(8, 1) = 1 [pid 22041] fcntl(1, F_SETFD, 0) = 0 [pid 22041] brk(0x81ac000) = 0x81ac000 [pid 22041] execve("./gnugo", ["./gnugo", "--mode", "gtp", "--quiet"], [/* 39 vars */]) = 0 [pid 22041] brk(0) = 0x863c68c [pid 22041] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 [pid 22041] open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 22041] open("/etc/ld.so.cache", O_RDONLY) = 3 [pid 22041] fstat(3, {st_mode=S_IFREG|0644, st_size=16265, ...}) = 0 [pid 22041] mmap(0, 16265, PROT_READ, MAP_PRIVATE, 3, 0) = 0x40015000 [pid 22041] close(3) = 0 [pid 22041] open("/usr/lib/libncurses.so.4", O_RDONLY) = 3 [pid 22041] fstat(3, {st_mode=S_IFREG|0755, st_size=274985, ...}) = 0 [pid 22041] read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\335"..., 4096) = 4096 [pid 22041] mmap(0, 254540, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40019000 [pid 22041] mprotect(0x4004b000, 49740, PROT_NONE) = 0 [pid 22041] mmap(0x4004b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x31000) = 0x4004b000 [pid 22041] mmap(0x40054000, 12876, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40054000 [pid 22041] close(3) = 0 [pid 22041] open("/lib/libm.so.6", O_RDONLY) = 3 [pid 22041] fstat(3, {st_mode=S_IFREG|0755, st_size=527442, ...}) = 0 [pid 22041] read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320F\0"..., 4096) = 4096 [pid 22041] mmap(0, 117208, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40058000 [pid 22041] mprotect(0x40074000, 2520, PROT_NONE) = 0 [pid 22041] mmap(0x40074000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x1b000) = 0x40074000 [pid 22041] close(3) = 0 [pid 22041] open("/lib/libc.so.6", O_RDONLY) = 3 [pid 22041] fstat(3, {st_mode=S_IFREG|0755, st_size=4101836, ...}) = 0 [pid 22041] read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210\212"..., 4096) = 4096 [pid 22041] mmap(0, 1001532, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40075000 [pid 22041] mprotect(0x40162000, 30780, PROT_NONE) = 0 [pid 22041] mmap(0x40162000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0xec000) = 0x40162000 [pid 22041] mmap(0x40166000, 14396, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40166000 [pid 22041] close(3) = 0 [pid 22041] mprotect(0x40075000, 970752, PROT_READ|PROT_WRITE) = 0 [pid 22041] mprotect(0x40075000, 970752, PROT_READ|PROT_EXEC) = 0 [pid 22041] munmap(0x40015000, 16265) = 0 [pid 22041] personality(0 /* PER_??? */) = 0 [pid 22041] getpid() = 22041 [pid 22041] rt_sigaction(SIGTERM, {0x804a614, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 [pid 22041] time(NULL) = 999018803 [pid 22041] brk(0) = 0x863c68c [pid 22041] brk(0x863c6c4) = 0x863c6c4 [pid 22041] brk(0x863d000) = 0x863d000 [pid 22041] mmap(0, 651264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4016a000 [pid 22041] mmap(0, 14307328, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40209000 [pid 22041] mmap(0, 1822720, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40fae000 [pid 22041] SYS_197(0, 0xbfffee04, 0x40165d40, 0x401638a0, 0) = -1 ENOSYS (Function not implemented) [pid 22041] fstat(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22041] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 [pid 22041] read(0, <unfinished ...> gnugo spawned by metamachine ---------------------------- [pid 22042] close(0) = 0 [pid 22042] dup(3) = 0 [pid 22042] close(1) = 0 [pid 22042] dup(6) = 1 [pid 22042] execve("/usr/local/bin/gnugo", ["gnugo", "--mode", "gtp", "--quiet"], [/* 39 vars */]) = 0 [pid 22042] brk(0) = 0x863c68c [pid 22042] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40014000 [pid 22042] open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 22042] open("/etc/ld.so.cache", O_RDONLY) = 7 [pid 22042] fstat(7, {st_mode=S_IFREG|0644, st_size=16265, ...}) = 0 [pid 22042] mmap(0, 16265, PROT_READ, MAP_PRIVATE, 7, 0) = 0x40015000 [pid 22042] close(7) = 0 [pid 22042] open("/usr/lib/libncurses.so.4", O_RDONLY) = 7 [pid 22042] fstat(7, {st_mode=S_IFREG|0755, st_size=274985, ...}) = 0 [pid 22042] read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\335"..., 4096) = 4096 [pid 22042] mmap(0, 254540, PROT_READ|PROT_EXEC, MAP_PRIVATE, 7, 0) = 0x40019000 [pid 22042] mprotect(0x4004b000, 49740, PROT_NONE) = 0 [pid 22042] mmap(0x4004b000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 7, 0x31000) = 0x4004b000 [pid 22042] mmap(0x40054000, 12876, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40054000 [pid 22042] close(7) = 0 [pid 22042] open("/lib/libm.so.6", O_RDONLY) = 7 [pid 22042] fstat(7, {st_mode=S_IFREG|0755, st_size=527442, ...}) = 0 [pid 22042] read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320F\0"..., 4096) = 4096 [pid 22042] mmap(0, 117208, PROT_READ|PROT_EXEC, MAP_PRIVATE, 7, 0) = 0x40058000 [pid 22042] mprotect(0x40074000, 2520, PROT_NONE) = 0 [pid 22042] mmap(0x40074000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 7, 0x1b000) = 0x40074000 [pid 22042] close(7) = 0 [pid 22042] open("/lib/libc.so.6", O_RDONLY) = 7 [pid 22042] fstat(7, {st_mode=S_IFREG|0755, st_size=4101836, ...}) = 0 [pid 22042] read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\210\212"..., 4096) = 4096 [pid 22042] mmap(0, 1001532, PROT_READ|PROT_EXEC, MAP_PRIVATE, 7, 0) = 0x40075000 [pid 22042] mprotect(0x40162000, 30780, PROT_NONE) = 0 [pid 22042] mmap(0x40162000, 16384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 7, 0xec000) = 0x40162000 [pid 22042] mmap(0x40166000, 14396, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40166000 [pid 22042] close(7) = 0 [pid 22042] mprotect(0x40075000, 970752, PROT_READ|PROT_WRITE) = 0 [pid 22042] mprotect(0x40075000, 970752, PROT_READ|PROT_EXEC) = 0 [pid 22042] munmap(0x40015000, 16265) = 0 [pid 22042] personality(0 /* PER_??? */) = 0 [pid 22042] getpid() = 22042 [pid 22042] rt_sigaction(SIGTERM, {0x804a614, [], SA_RESTART|0x4000000}, {SIG_DFL}, 8) = 0 [pid 22042] time(NULL) = 999018803 [pid 22042] brk(0) = 0x863c68c [pid 22042] brk(0x863c6c4) = 0x863c6c4 [pid 22042] brk(0x863d000) = 0x863d000 [pid 22042] mmap(0, 651264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x4016a000 [pid 22042] mmap(0, 14307328, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40209000 [pid 22042] mmap(0, 1822720, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40fae000 [pid 22042] SYS_197(0, 0xbfffee04, 0x40165d40, 0x401638a0, 0) = -1 ENOSYS (Function not implemented) [pid 22042] fstat(0, {st_mode=S_IFIFO|0600, st_size=13, ...}) = 0 [pid 22042] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40015000 [pid 22042] read(0, "boardsize 19\n", 4096) = 13 [pid 22042] fstat(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0 [pid 22042] mmap(0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000 [pid 22042] write(1, "= \n\n", 4) = 4 [pid 22042] read(0, <unfinished ...> dd -- dave.denholm(a)insignia.com http://www.insignia.com

1 0

Re: Metamachine
by Dave Denholm 28 Aug '01

28 Aug '01

Daniel Bump <bump(a)match.stanford.edu> writes: > Back to Problem 2 from my previous message. > > Here's what is happening. Suppose I run: > > perl twogtp-a --black "metamachine" --white "gnugo --mode gtp --quiet" > > (There are two versions of twogtp in interface/gtp_examples, and > twogtp-a is a little easier for me to parse.) > > I can do this from perldb and as soon as pidb is open I can > attach gdb to metamachine and/or gnugo. Metamachine stops > at line 61: > > if (!fgets(client_line, 128, stdin)) > > waiting for a command in stdin. This it should get when > twogtp-a gets up to line 115 and prints "boardsize 19" > but at this point deadlock occurs. Note that there is > no deadlock if metamachine is run from the shell. One difference is that stdin tends to be fully buffered unless it is a shell. I'd guess that the stdio library is being initialised before you drop in your replacements for fileid 0 and 1 (which is possibly a bad idea..?) So when you run from the shell, stdin is set to be line-buffered, and then you drop a pipe into fd 0. But when it is spawned from twogtp, stdin is set fully buffered ? Ditto for stdout. For this sort of application I would tend to use raw reads and writes, omitting the stdio library entirely. Forcing (no more than) line buffering in stdio is probably essential. > > I have an email from David referring to man IPC::Open2 > on the dangers of open2. But I can't say I really > understand why this deadlock occurs or how it can be > avoided. The problem is that when you do fprintf(), there is no guarantee that the data has actually been written out of the process buffers. So process A thinks it has sent the command and is blocked waiting for the reply. But the message is still in A's stdio buffers, and so process is still blocked waiting to read it. => deadlock. dd -- dave.denholm(a)insignia.com http://www.insignia.com

2 1

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

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 August 2001