Dave Dyer wrote:
Arguing whether method A or method B rates a program more
correctly is really close to arguing how many angels can dance
on the head of a Pin. Ratings, at best, are based on mathematical
models with many simplifying assumptions. Ratings are not reality.
Nobody really
Mark Boon wrote:
On 6-dec-07, at 19:29, Don Dailey wrote:
Here is an example of why this works so well and why your greedy
approach is so wrong:
Consider a position where there are 2 groups left that are being
fought over. One of these groups is very large and the other is quite
Erik van der Werf wrote:
On Dec 10, 2007 6:48 PM, Don Dailey [EMAIL PROTECTED] wrote:
In Go however, even if the fundamental game is unchanged you may be
playing illegal moves if you are not aware of the superko situation.
And you think superko is part of the fundamental game
There is some
question about how you define a position (a board state, or a board
configuration i.e. SSK or PSK) but you can nitpick if you want and say
that superko has nothing to do with positions repeating but I think when
a position repeats it's superko.
And when you say it's
Raymond Wold wrote:
On Tue, 2007-12-11 at 11:42 -0500, Don Dailey wrote:
In fact, this illustrates a wonderful strength of these programs.
Only it's not strength to ignore a move to your benefit,
Who suggested that it was? The strength of MC programs is how they
deal
terry mcintyre wrote:
Ladders are not hard, especially if one is permitted to place stones
on the (virtual) board to trace the flow. A 20 kyu human can follow
the logic.
Don, you describe some subtle choices of playing one's opponent, and
compare them to MC programs, but you are a fairly
Hi Petri,
I happen to think that MC is the most human like approach currently
being tried.
The reason I say that is that humans DO estimate their winning chances
and tally methods, where you simply tally up features/weights
(regardless of how sophisticated) is not how strong humans think
Are you playing on CGOS? Did you actually build your own GUI for this?
I don't want people playing on CGOS as a general rule except under
controlled circumstance for this purpose, but not just for fun.
I discovered that it's easy to use gtpadapter from gogui and play on
CGOS. The only
, Don Dailey wrote:
Do you know of an approach that evaluates go positions perfectly?You
are attacking the fact that MC programs have errors in their probability
estimates but completely ignoring the fact that SO DOES EVERY OTHER
EVALUATION FUNCTION.
I can code an algorithm
I have had this experience many times:
1. You see a move that sucks.
2. You identify the problem and engineer a solution.
3. The solution indeed works - it cures the problem.
4. The program plays worse than it did before.
By the way, you are being modest, Antigo is not bad on
Christoph,
Let me know when you are finished, what name you are playing under and
I will do the bayeselo thing to get a better figure. Also, I can
throw out any games that were irregular if you can identify them, such
as if a match started when you were not looking or your interface got
11:26 PM, Don Dailey [EMAIL PROTECTED] wrote:
This uncertainity is what gives the less-than-1 confidence you
discussed, but my feeling is that it varies too much with the sequence
length -- the answer would be to add some intelligence, like MoGo and
the other top programs do.
Yes
David
-Original Message-
From: [EMAIL PROTECTED] [mailto:computer-go-
[EMAIL PROTECTED] On Behalf Of Don Dailey
Sent: Tuesday, December 11, 2007 11:53 AM
To: computer-go
Subject: Re: [computer-go] How does MC do with ladders?
Hi Petri,
I happen to think that MC is the most
Russ Williams wrote:
On Dec 11, 2007 8:53 PM, Don Dailey [EMAIL PROTECTED] wrote:
The play-out portion is a crude approximation for imagination. We
basically look at a board and imagine the final position.The MC
play-outs kill the dead groups in a reasonably accurate (but fuzzy
I've looked into this a bit. My preference would be scheme and it's
my understanding that it may be a bit more efficient.
- Don
Urban Hafner wrote:
On Dec 12, 2007, at 10:09 , Nick Apperson wrote:
I've been (and still am) a die hard supporter of C++, but since I
program in C++ for work
are.
- Don
Álvaro.
On Dec 12, 2007 8:18 AM, Don Dailey [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Russ Williams wrote:
On Dec 11, 2007 8:53 PM, Don Dailey [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
The play-out portion is a crude approximation
wrote:
Hear, hear! The question is not one of abandonment of the recognition
of uncertainty. Like Don Dailey, I think it's brilliant that UCT
programs explicitly manage uncertainty and winning probabilities. My
concern is that existing implementations have some serious but
possibly fixable
Dave Dyer wrote:
At 05:24 AM 12/12/2007, Don Dailey wrote:
I've looked into this a bit. My preference would be scheme and it's
my understanding that it may be a bit more efficient.
If you're worried about efficient use of the machine, stay away from lisp
and scheme. Despite
I saw this on the Gambit-C web page:
With appropriate declarations in the source code the executable
programs generated by the compiler run roughly as fast as equivalent C
programs.
This is another way of saying it run pretty fast but not as fast as C.
- Don
Urban Hafner wrote:
On Dec 12,
I thinks it's very difficult to outperform C since C really is just
about at the level of assembly language.
To beat C I think you would have to write a better compiler.It
wouldn't be about the language but about the compiler.I'm sure a
really good language compiler can already beat a
This was right on the mark! It exposed a lot of misconceptions and
wrong thinking about MC and evaluation.
- Don
Magnus Persson wrote:
I just want to make some comments about MC evaluation to remove some
common misunderstandings.
I have seen some complaints about misevaluation such as a
steve uurtamo wrote:
Currently there is no evidence whatsoever that probability estimates
are
inferior and they are the ones playing the best GO right now
are they?
Yes - in both 9x9 and 19x19 go.
- Don
s.
Eric,
Yes, as Magnus also stated MC play-out doesn't really accurately
estimate the real winning probability but it still get the move order
right most of the time.
The situation is that if the position is really a win, it doesn't mean
that a MC is able to find the proof tree. But it
Christoph,
Your bayeselo rating is 1942 on CGOS. I compiled a table that has
all players with 50 games or more which can be found here:
http://cgos.boardspace.net/9x9/hof2.html
- Don
Christoph Birk wrote:
On Tue, 11 Dec 2007, Don Dailey wrote:
Christoph,
Let me know when
humans at the equivalent time control on KGS at
9x9 and we could adjust the difference between ranks accordingly.
I suspect there is more than 100 ELO between ranks at 9x9.
- Don
Don Dailey wrote:
Christoph,
Your bayeselo rating is 1942 on CGOS. I compiled a table that has
all
It would be great if you would provide recommendations for a simple
conversion formula when you are ready based on this study. Also,
if you have any suggestions in general for CGOS ratings the
cgos-developers would be willing to listen to your suggestions.
- Don
Rémi Coulom wrote:
Don
Hi Mark,
It wasn't my intention to sound argumentative about this, I apologize
for this.
Yes, I agree that the shorter mate sequence should be chosen and also
that if all else is equal, the bigger win should be the course to follow.
There is a misconception that MC favors winning by the
different names anyway. I pretty much always use the same
password so I can control this easily with the name.
- Don
Rémi Coulom wrote:
Don Dailey wrote:
It would be great if you would provide recommendations for a simple
conversion formula when you are ready based on this study
From time to time I have put highly experimental and very different
programs on CGOS and I don't care if they play themselves
What I meant to say is that I don't care if they play other programs of
mine.
- Don
Don Dailey wrote:
I am considering to enforce this basic protocol
adjust the difference between ranks accordingly.
I suspect there is more than 100 ELO between ranks at 9x9.
- Don
Don Dailey wrote:
Christoph,
Your bayeselo rating is 1942 on CGOS. I compiled a table that
has
all players with 50 games or more which can be found here
13, 2007 2:37 PM, Don Dailey [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I am considering to enforce this basic protocol on the server soon:
Programs of the same family will not be paired against each
other.
I frequently look at the games between my bot version more
Nice idea and worth a try.I predict that this will weaken the
program no matter what value you use, but that there may indeed be a
reasonable compromise that gives you the better behavior with only a
very small decline in strength.
I think this bother people so much that they would be
Regarding correspondance with human ranks, and handicap value, I cannot
tell yet. It is very clear to me that the Elo-rating model is very wrong
for the game of Go, because strength is not one-dimensional, especially
when mixing bots and humans. The best way to evaluate a bot in terms of
human
a suggestion for a specific mechanism for this?
- Don
Jason House wrote:
On Dec 13, 2007 4:01 PM, Don Dailey [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I don't want to add more mechanisms. You can build your own
mechanism
by making your own password naming
What I mean is that if human player H beats computer C1 65% of the
time, and computer C2 also beats computer C1 65% of the time, then I
would expect that H would be stronger than C2, especially if both C1
and C2 are MC programs. If it is the case, then it would make it
difficult to compare
[EMAIL PROTECTED] wrote:
Impasse: noun,
1. There is no argument so elegant and compelling that it will prove
the negative that making UCT greedier could not possibly lead to more
won games.
I could hardly fail to disagree with you less.
___
breaks during an important point.
- Don
Hideki Kato wrote:
Hi Don,
Don Dailey: [EMAIL PROTECTED]:
I want to clarify this:
The new CGOS chart uses bayeselo to recalculate all the ratings for the
players - it does not use CGOS ratings.
Hm, now I remembered that there were not so
be
sentimental favorite like gnugo.
- Don
-Hideki
Don Dailey: [EMAIL PROTECTED]:
Many strong programs have 100% scores against many opponents and many
games. They cannot be hanging up very often.
When the server hangs, the current game you are playing is not scored.
I don't think
experiments before using the name of 'Hall of fame'.
-Hideki
Don Dailey: [EMAIL PROTECTED]:
Hideki Kato wrote:
Why don't you mention the several versions on one login name
problem?
I don't consider it a major problem. The theory is that a big
improvement against versions
such as Chess
and Go programs.
- Don
Stefan Nobis wrote:
Don Dailey [EMAIL PROTECTED] writes:
I thinks it's very difficult to outperform C since C really is just
about at the level of assembly language.
No, in special cases it's not that hard to outperform C, because the
language spec
it or not I accept it and hope something better
will come along.
- Don
Don Dailey wrote:
Stefan,
Yes, in special cases you can outperform C.
I don't claim that it might not be possible with better compiler
technology to outperform C. I'm keeping my eye on D because it
promises
is currently on D, but it's too early to be able to predict.
- Don
Harald Korneliussen wrote:
Don Dailey wrote:
By the way, I am no fan of C. I don't like C and have tried some of
the languages on your list of languages that are supposedly faster than
C.
I think you must
Gunnar Farnebäck wrote:
Don Dailey wrote:
Also, even though we can ask people to never change their program unless
they give it a new login name, we can't enforce that, nor is it
reasonable to try. I might have a program with an on-line learning
algorithm which improves itself over
Hideki,
It was not my intention to disrespect you.I think the word you are
looking for is condescending which is when you talk down to someone as
a child.
If it came across this way I'm sorry.I tried to make it easy to
understand because it seems to me that English is not your first
The same facts of the invalidity of benchmarks continue to surface, and
it's well understood that they can be misleading - but for me the very
simple truth is straightforward.I have tried many different
languages and in every case so far it has not turned out unclear, C
has always won.
Forrest Curo wrote:
I'd like to know how well MoGo would have played if you let it think
for a week for every move.
Probably diminishing returns. Once a series of random playouts has
given it a selection of the more significant points to consider, I'd
expect move-order, forcing moves, the
Memory is an issue with these programs, since they build tree's and
maintain them in memory. So none of these programs can think for
more
than a few minutes per move.
dimwit gets around this problem by increasing the number of visits
required before a node is added to
I suspect that for very long time controls we would be better off
turning UCT (with, say 10K playouts) into an evaluation function and
then using alpha-beta on top of it.
That is an interesting idea. Usually, when you have to resort to things
like this it means that we need a new way of
Chris Fant wrote:
I suspect that for very long time controls we would be better off
turning UCT (with, say 10K playouts) into an evaluation function and
then using alpha-beta on top of it.
Álvaro.
This is very interesting to me.Not the memory management part, but
the fact
I suspect that for very long time controls we would be better off
turning UCT (with, say 10K playouts) into an evaluation function and
then using alpha-beta on top of it.
Álvaro.
I did do a study once with pure alpha beta where I used play-outs as my
evaluation function. Interestingly,
Álvaro,
I'm going to take another look at alpha-beta with play-outs. I have a
lot of new ideas I want to explore.
- Don
Álvaro Begué wrote:
On Dec 18, 2007 4:21 PM, Don Dailey [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Chris Fant wrote:
I suspect that for very long
Berk,
Why do you need to initialize the seed more than 1 time?You should
use zobrist hashing.
Initialize the random number generator once when you start the programs.
Fill an array with random numbers from the generator at program startup
too. The array looks something like this for a
I actually have a routine in Lazarus that rotates a full board. It's
called transformBoard() and it takes 2 arguments - a board to rotate and
a transformation (0 through 7) and returns a new rotated board.
I don't use it much except for debugging or stuff done at the root,
because there are
Instead of generating a new random number every time I want to pick a
move in a random playout, I fill a large circular array with random
numbers when my go program launches (before it is actually playing a
game) and I have a method that just gets the next number out of the
array instead of
Hold on, I just re-read this.Do you think you must initialize the
generator after each number? You only need to initialize MT once, when
your program starts and then it will provide very good numbers for the
next several billion years.
- Don
Imran Hendley wrote:
A couple of things I
Imran Hendley wrote:
A sorry about that. Glad to hear you fixed the problem. What was your
solution?
It seems you mentioned the global list approach in your email which
I missed too. Why did you think this was an ugly approach? I just put
my random array in a Singleton object (call it
is going to be used in binary tree, you may wish to swap the low-order
bits with the high-order bits to keep the tree more balanced.
On Dec 19, 2007 10:44 AM, Don Dailey [EMAIL PROTECTED] wrote:
I actually have a routine in Lazarus that rotates a full board. It's
called transformBoard
It's also possible to select hash keys such that transformations of
the board's key is the same as recomputing the key for a symmetrical
board position. This will be *much* faster. I came up with a
scheme to do this and documented it on my website, but haven't
actually
I probably go through my entire array 5 times per second during a UCT
search. So far I have been relying on the hope that I do not come back
to the beginning of my array at exactly the same position in a random
playout which would cause a bad cycle. If I come back at a different
position
You are in for quite a learning curve! But we welcome you. I did it
exactly the same as you, I decided to write a go program and the first
thing I had to do was figure out what the rules of the game were!
Tromp/Taylor is really the way to go on this to get started with
computer go.
This
Álvaro Begué wrote:
On Dec 20, 2007 10:19 AM, Jason House [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On Dec 20, 2007 10:15 AM, Arthur Cater [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
With 8 hashes per position, the chance of two different boards
The only way this might help is in the opening or in very nearly
symmetrical positions and this is really rare. The possible slight
benefit would be canceled by even a very small slowdown.
It would be useful on small boards as an opening book however where
exact positions (or hashes) are
Jacques Basaldúa wrote:
Don Dailey wrote:
You can use Zobrist hashing for maintaining all 8 keys incrementally,
but you probably need a fairly good reason to do so. Incrementally
updating of 1 key is almost free, but 8 might be noticeable if you are
doing it inside a tree search
, needlessly favor hash
values that are even or multiples of 4 or 8.
On Dec 20, 2007 1:33 PM, Don Dailey [EMAIL PROTECTED] wrote:
If you are going to compute all 8 hash keys, you can just add them up
at the end instead of picking the minimum. Wouldn't that be better?
I think that's
The watchdog script works great! It has restarted the server several
times over the past month.
However, right now 9x9 is down due to some frequent reboots of the
boardspace server that is being looked into. I still manually run
the watchdog script so it will not recover the server after
Nick,
I was hoping you would have a really long time-control 9x9
tournament.I know you did not get much interest when you mentioned
it before but it might be an impetus to improve the memory behavior of
long running bots.Also, I want to experiment with my alpha/beta
searcher which would
function in a straightforward way and handle the tree portion pretty
much like UCT.You still balance exploitation and exploration like
UCT.Have you considered such an approach?
- Don
David
-Original Message-
[EMAIL PROTECTED] On Behalf Of Don Dailey
The various versions I'm
don't think I
can get the statistics needed for UCT.
- Don
David
-Original Message-
[EMAIL PROTECTED] On Behalf Of Don Dailey
The various versions I'm testing are selective, I use a technique
similar to that used in modern chess programs of aborting the search
at a given
when the reduction parity doesn't match the
re-search parity - so this may not be my final formula. I generally
test everything I try so I usually don't get answers for at least a day
or two.
- Don
Don Dailey wrote:
DF: how many ply is your usual search? I'm getting 3 to 6 ply in the main
This is just to remind anyone playing on CGOS that you need 200 games to
get on the All-Time list which I will publish at the end of each month.
So if some version of your bot does not have at least 200 games, it
will NOT appear on the list. There are some fairly strong bots that
didn't make
Has anyone here taken a serious look at scala the programming language?
It seems (to me) to be a very high level functionally oriented Java.
Part of the reason I don't like Java is because it's such a low level
language (might as well program in C), but this language has a very
nice high level
The http://hsrf-mact.cse.ucsc.edu/~drd/cgosArchives.html site seems to
be down again.
If anyone want to get the December games now, they will be temporarily
available here
but only in bzip2 format:
http://greencheeks.homelinux.org:8015/~drd/2007-12.tar.bz2
- Don
Hi Peter,
CGOS doesn't count the first 1/4 second of thinking time and this could
help a little.
This isn't the same as Fischer time however because you are not given
the time if it adds to your surplus. It is designed so that if you
play fast enough (less than 1/4 second per move) you will
Of course it's also possible to implement the Fischer clock on CGOS.
Fischer clock is where you have a fixed time component (such as 5
minutes) but you also are given an increment - another fixed time
component that is added to your clock EACH MOVE.
So it might be expressed as 2 minutes +
One of my bots will pass if the opponent passes first - if it's a win.
Even if the opponent has dead stones still on the board.But of
course it won't pass if the Tromp Taylor score is not enough for the win.
- Don
Jason House wrote:
If your bot has enough points to win under Tromp
.The program claims
victory - which means that it agrees that every move from now on (for
itself) is a pass move. It would be the counterpart to resignation -
with the provision that you give up all rights to defend yourself if you
are wrong.
- Don
Erik
On Jan 2, 2008 3:02 PM, Don Dailey [EMAIL
Better would be some kind of victory declaration.The program claims
victory - which means that it agrees that every move from now on (for
itself) is a pass move. It would be the counterpart to resignation -
with the provision that you give up all rights to defend yourself if you
are
block the accounts so other programs can
continue while the programmers in question debug their broken
programs.
On Jan 2, 2008 8:22 AM, Don Dailey [EMAIL PROTECTED] wrote:
Hi Peter,
CGOS doesn't count the first 1/4 second of thinking time and this could
help a little.
This isn't
one
time-control or both.
- Don
Jeff Nowakowski wrote:
On Wed, 2008-01-02 at 15:29 -0500, Don Dailey wrote:
I am considering to implement Fischer time on CGOS
How are you going to deal with keeping the games on a fixed schedule?
-Jeff
Thomas Nelson wrote:
On Wed, 2 Jan 2008, Don Dailey wrote:
If we don't like the rules, we can talk about changing them in order to
get behavior that fits our sensibilities better.But we have been
over this ground many times before. It seems like the only reasonable
way to properly
David Fotland wrote:
Japanese rules. I know people on this list don't like them, but the game
plays out almost the same as with Chinese rules, but since there is a one
point penalty for playing inside your own territory, the game ends much
earlier.
The real issue on a server that
Robert Jasiek wrote:
Don Dailey wrote:
This raises an interesting (to me) theoretical question: is there a
ruleset that allows games to end in a more reasonable time without
changing general play?
There is no such rule-set that I know of.
If it is specified more clearly what end
I have to correct this slightly.
Don Dailey wrote:
Just for fun I thought of a simple protocol for ending the game earlier
that I think would work:
Each program, when it sends it's move to the server can optionally send
2 lists of dead stones to the server. The first list represents
Jason House wrote:
On Jan 3, 2008 10:21 AM, Don Dailey [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Robert Jasiek wrote:
Don Dailey wrote:
you can never solve the problem of a
malicious opponent who wants to prolong the game needlessly.
I solved
John Tromp wrote:
On Jan 3, 2008 10:46 AM, Don Dailey [EMAIL PROTECTED] wrote:
Yes, the KGS rules gives only 1 chance to agree. At one point KGS
allowed this to happen repeatedly, but it cause some bots to infinite
loop on the server when they disagreed. So I think it's better than
Dave Dyer wrote:
CGOS uses Chinese scoring with play-outs so that we can get fully
automated scoring with no chance of errors.
No chance of errors is vacuously true. Errors, if any, were made
in the playout leading to the final state. There can be score
differences compared to
Robert Jasiek wrote:
Jason House wrote:
I missed [...] the part about
solving how to end the game in an elegant way.
elegant is an aspect of art, and I have not studied it profoundly in
relation to rules yet because I concentrate on things that can be
derived from definitions and
I think Fischer time is the solution to network lag. I can't give back
the lag time, but I can make it so that you should not lose games as a
result of it (unless it gets ridiculous.)
- Don
Jacques Basaldúa wrote:
The problem is avoiding that an inferior program wins a lost position
on time
[EMAIL PROTECTED] wrote:
After 2000 playouts, AntIgo checks the estimated score. If it's way
ahead, it stops thinking and just plays the best move it has so far.
This way it plays very quickly when the game is won and the opponent
does not resign. (I don't apply this rule in the beginning to
I will ask Olivier if he wants my scripts.
- Don
Gian-Carlo Pascutto wrote:
Chris Fant wrote:
CGOS 19 is has been stuck for a while now.
At the bottom of the page, it says Many Faces is in a game, but does
not show it as currently playing at the top of the page. Perhaps the
problem is
It was my understanding the bot was losing 2 seconds per move. 1/2
second would probably not fix this.
- Don
Christoph Birk wrote:
On Fri, 4 Jan 2008, Don Dailey wrote:
I think Fischer time is the solution to network lag. I can't give back
the lag time, but I can make it so that you
I altered the time gift for CGOS 9x9. I set it to 0.75 seconds.
In other words, the first 3/4 second of each move doesn't count against
your total time used.
- Don
___
computer-go mailing list
computer-go@computer-go.org
Lazarus uses a system very simlar to the original MoGo policy as
documented in the paper. However I did find one significant
improvement.I used Rémi's ELO system to rate patterns and I simply
throw out moves which match the weakest patterns in the play-outs.In
the tree, I also throw out
My guess is that this is a combination of some intransitivity and low
sample size. 100 games isn't very much data in the CS vs MFGO.
As far as intransivity, perhaps Crazy Stone has some particular
strength that works very well against a weakness in MFGO. The
values do not make a
Rémi,
The idea of a non one dimension rating model is interesting. If you
decide to pursue this I can give you the CGOS data in a compact format,
1 line per result.
I thought of this idea too, but I didn't try to produce a model.It
would be easier to test and build such a model however if
Vlad Dumitrescu wrote:
On Jan 6, 2008 11:00 PM, Don Dailey [EMAIL PROTECTED] wrote:
The idea of a non one dimension rating model is interesting. If you
decide to pursue this I can give you the CGOS data in a compact format,
1 line per result.
Hi all,
I'm not sure I get
Hillis
-Original Message-
From: Vlad Dumitrescu [EMAIL PROTECTED]
To: computer-go computer-go@computer-go.org
Sent: Sun, 6 Jan 2008 5:12 pm
Subject: Re: [computer-go] Odd results on 19x19
On Jan 6, 2008 11:00 PM, Don Dailey [EMAIL PROTECTED] mailto:[EMAIL
PROTECTED] wrote
The client does not sent time_left unless time_settings is also
implemented.So your engine must also implement time_settings which
is needed to inform your program of the level it will be playing at.
- Don
Jacques Basaldúa wrote:
Hi..
My gtp program does not receive any time_left
I don't know what to tell you - the command works for everyone else.
I noticed that your list is upper-case. This might be the problem. I
don't remember if GTP is case senstitive or not, but I'm pretty sure
cgos requires lower case in these commands.
- Don
Jacques Basaldúa wrote:
Hi Don
None of the KGS specific extensions are required or used. undo is not
necessary.
- Don
Don Dailey wrote:
I don't know what to tell you - the command works for everyone else.
I noticed that your list is upper-case. This might be the problem. I
don't remember if GTP is case senstitive
701 - 800 of 1773 matches
Mail list logo
