gtp

gtp@lists.lysator.liu.se

164 discussions

Example java parser for gtp v2
by Mike Kelley 03 May '03

03 May '03

I've cleaned up the java parsing code I have been using enough that I feel it's ready to post. I'd like feedback if anyone has a look! This is purely a parser, designed for easy integration with an engine. It uses an adaptor class that can be subclassed to implement command methods. Some basic self-tests are included as well as stdio and tcp connection examples. The code can be found on: http://www.huchley.com/nerds/go.jsp mwk --------------------------------- Mike Kelley mwk(a)huchley.com

1 0

GUIs that implement GTP?
by David 29 Apr '03

29 Apr '03

I've been searching all over for a GUI that implements GTP, but I haven't found a single one. Are there any? Regards, David

4 3

Re: [gtp] GUIs that implement GTP?
by Mike Kelley 26 Apr '03

26 Apr '03

I was just looking as well. Did you try any of the clients listed on http://www.gnu.org/software/gnugo/gnugo.html ? I just joined the maillist, so here's my ritual first-and-probably-dumb question: I tried gGo because the gnugo page said it supported GTP, and it does something similar to GTP V2 spec, but with differences such as: "black A1" instead of "play black A1" "genmove_black" instead of "genmove black" Is it just wrong, or is this an earlier GTP version? BTW I'm doing some go code in java so I have put together a GTP V2 parser java package; if there's interest I'll make it available. mwk On Sat, 26 Apr 2003 20:54:18 +0200, David wrote: > > I've been searching all over for a GUI that implements > GTP, but I > haven't found a single one. Are there any? > > Regards, > David > > _______________________________________________ > gtp mailing list > gtp(a)lists.lysator.liu.se > http://lists.lysator.liu.se/mailman/listinfo/gtp --------------------------------- Mike Kelley mwk(a)huchley.com

2 1

Interrupting commands + GMP to GTP adapter
by Markus Enzenberger 27 Feb '03

27 Feb '03

thanks to all people who sent me private email to discuss this topic. I finally introduced the following convention to allow interrupting commands: If the controlling program sends a special comment line (# interrupt), while a command is running, the engine should interrupt the running command (which success or failure whatever makes sense). This allows engines to implement interrupting, while engines who don't support this convention will read the comment line after the current command is finished (and simply ignore it). I adopted this convention for GoGui, if the interrupt button on the toolbar is pressed. GoGui also includes a GMP to GTP adapter program now, but the implementation is still in an early stage. - Markus

1 0

Interrupting commands
by Markus Enzenberger 24 Feb '03

24 Feb '03

Recently I started implementing a GMP to GTP adapter. This is tricky, since GMP is asynchronous. For example, I implemented the "genmove" GTP command so, that if no GMP command has arrived, the adapter waits until a move arrives. However, if the other side sends no move, the adapter would wait forever or at least a long time, since a timeout would have to be set to a very high value, because you don't really know how long the opponent could take for a move. So there again is a big need to make genmove interruptible. After trying to implement the "abort" command (as suggested in earlier postings on this list) on a server as well as a client side, I am more convinced than before, that my first idea is better. The abort command is inherently asynchronous (potentially overlapping with another command), whereas the regular GTP command stream is synchronous. So it is not very convenient to see abort as a regular command. If you do so, things become unnessesarily complicated on the server side. The read thread needs to remember all abort commands received while a regular command was processed to be able to answer them correctly after printing the answer of the regular command. Same on the client side, e.g. a graphical user interface which sends an abort command if the use presses a stop button needs to remember that, to be able to collect the responses. This makes conventional serialization technics with a read thread and event based GUIs not work and the code becomes really messy. Also, what should the program do with a failure response? The response to it will be received after the response to the regular command anyway? So IMO an abort command should not be seen as a regular command and should *not* need a response. It is not very important whether the abort command is a word or a character. The only advantage of a character is, that if you take a control character not used by GTP, you could make interruption an optional extension to GTP that is simply ignored by clients that don't know it (from the GTP specs: clients must discard control characters not used by GTP). - Markus

2 2

GTP vs SGF
by A van Kessel 20 Jan '03

20 Jan '03

We have had this discussion before. The point is, IMHO that gunnar is very strict about adding features that are not obviously needed by even the most minimalistic implementation. The "standard" is extendable: feel free to implement th {AB,AW,MN,PL,C} sgf commands into your own GTP programs. Given unlimited undo, you could even remove the sgf-reader from the engine, and leave that to the GTP-driver. If you want to use gtp for controlling (otherwise hidden) state in your program, just create a private extension to the protocol for getting/setting the variables. One such command could be "SGF AB dd qq" AvK

1 0

Setup commands?
by Marco Scheurer 20 Jan '03

20 Jan '03

Hi, Shouldn't the GTP protocol include setup commands such as those found in SGF to add black or white stones to the board, clear points, AB, AW, AE (PL is probably redundant)? It would help to create a position and ask the engine to generate a move from there. Of course, this could be done with the loadsgf command but there are times when there is no sgf file. I would prefer to have these commands in GTP rather than writing a temp sgf file just for that purpose. Also, the current GTP spec on laodsgf is not explicit about this: are all setup nodes and properties allowed and taken into account when replaying the game record? Marco Scheurer Sen:te, Lausanne, Switzerland http://www.sente.ch

2 2

Sample implementation of "abort"
by Andrew Derrick Balsa 06 Nov '02

06 Nov '02

Hi, OK, I have something that works and that seems half-decently coded. Here is a sample output for Randyplus with threaded genmove: ----- 30 genmove black =30 d1 40 genmove white 50 abort ?40 aborted =50 60 genmove white =60 e11 ----- If you ask me how I managed to type the abort: I introduced a 10-second "thinking" delay in the separate genmove thread. ;-) The implementation is coded using basic POSIX pthreads calls, so the basic algorithm should work on anything that has POSIX pthreads. To abort the separate genmove thread, I have used the pthreads call pthreads_cancel( ). In the threaded genmove, I use the call: pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, NULL); when I reach the commit point. Beyond that point, the cancel request is not honoured anymore. All the changes to my original code were made in gtp.cpp. Limitations: 1) Presently only genmove can be aborted (this can be extended easily but I didn't try it). 2) Abort only works if it is the first command following the genmove. Other commands will block, waiting for genmove to finish. 3) There must be a clearly established "commit point" in the genmove routine, beyond which it should not be cancelled. Thanks to Bill and Gunnar for the necessary clarifying. Up to you now if you want to include "abort" as an optional GTP command! Rather than packaging Randyplus again, I am attaching the bzipped diff file (2KB) if anyone wants to try it out. -- Andrew D. Balsa andrebalsa(a)mailingaddress.org

1 0

Re: gtp digest, Vol 1 #76 - 2 msgs
by William M. Shubert 06 Nov '02

06 Nov '02

I think you are making this more complex than it needs to be: * If the command completes before the engine gets the abort, then the command succeeds and the abort fails. Commands which happen instantly, like "quit" or "boardsize", the abort never comes in time, so it's always the abort that fails. This makes sense because the whole point of the abort is not to undo things - instead, it is to get the GTP client to stop what it is doing and start listening to commands from the server again. Whether the client stops because it completed the command (in which case the command returns success & the abort returns an error) or because it has aborted the command (in which case the command returns an error & the abort returns success) doesn't matter. * Since "abort" causes the previous command to fail (if the abort succeeds), and the GTP spec says that a failed command should not change the state of the engine, that does imply that if you can't return to the original engine state, you should continue working on the genmove then return an error for the abort. This is fine with me, but if we explicitly say that an aborted genmove can change the engine state that is fine with me also; I don't see that it matters whether you undo your engine state or not after an abort to a genmove. If you can, fine, if you can't, fine, as long as these state changes don't leave you with a broken engine! For example, in a "genmove/abort/genmove", if you have worked out some life&death situations in the first genmove, why not be able to use them in the 2nd? I do agree that abort needs to be 100% optional. That makes it easier; anything you can't abort, just finish the command and error out the abort. If you can't abort anything, just treat abort as an unrecognized command. A server must treat abort as a "hint" that it doesn't care about the output of the current command, so this "hint" is only needed to save time, not needed for correctness. On Mon, 2002-11-04 at 03:00, Andrew Derrick Balsa: I have thought about implementing it in the various small "xxxplus" engines. But I immediately hit a snag: it's quite obvious that the engine has to react differently according to what it was doing when it receives the "abort" command. What should it do if it receives the "abort" just after it received a "quit"? Or after receiving a "boardsize"? Let's assume it can only receive an "abort" after it has received a "genmove"... Should it "undo" anything it has done until now? What if it can't undo changes to some data structures? Should it fail? But the spec says that any failed command should not change the state of the engine... I confess I gave up after a few minutes. Receiving an "abort", either as a single character or as an (IMHO preferable) full word, in a separate thread, is easy in Linux. Making the engine react in a consistent manner, compatible with the rest of the GTP command set, would certainly require a lot of work. Perhaps I am wrong and somebody can come up with an unambiguous one-paragraph GTP spec for the "abort" command. I couldn't think of any way to do that. :-( Regards, -- Andrew D. Balsa andrebalsa(a)mailingaddress.org

4 3

Re: gtp digest
by A van Kessel 05 Nov '02

05 Nov '02

I still don't think we should allow the engine to return half-baked results when interrupted during genmove. Either succeed or fail. Bill schubert's scheme is cleaner , IMO. wrt the ordering of commands and responses: there is nothing new here: if we treat abort like any other command, it's responses should come in the right order. The reason I proposed the (optional) report_post_abortem_move is a previous post was to avoid the three valued logic that creeps in if we allow the genmove to produce half-baked moves. My program falls in category 1a or 1b. It does not have a move generator yet, and it is pretty hard to maintain state even without asynchronous commands ... Since I am not concerned with portability, it would be relatively easy to get upto step 3. Counter-question to gunnar: would it be easyer to implement te abort command in Gnugo, if it were allowed to use a SIGINT instead ? (my guess is: yes) AvK

2 1

← Newer
1
2
3
4
5
6
7
8
9
...
17
Older →

Jump to page:

2025

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