auto232 help needed
Robert Hyatt
I'm still struggling with the auto232 interface problem in Crafty. While
I'm not exactly frantic to hit the SSDF list, it seems that I should at least
make it possible for them to test Crafty should they want to do so.
Here's the current situation: apparently, with "ponder=off", crafty will
play games perfectly. However, with "ponder=on" it seems to hang, on
occasion, specifically when the opponent makes the move Crafty is expecting.
I can't see any reason for this. I have run this under unix many times,
and found a series of moves where Crafty would make the same move with
ponder=off or on. I used the "autoplay" command which makes crafty open
a file to "PRN" which goes to the printer in DOS, but creates a file in
unix. I then played through the game with and without pondering, and amazingly
the files are identical, byte for byte.
This leads me to believe that it is a timing difficulty in auto232, rather
than something odd in Crafty. Does anyone know anything about any specific
timing requirements? For example, if the opponent makes the move crafty
expects, crafty will echo the move as it is supposed to, but it will defer
the echo for a while, until just before crafty echos its own move. I'm
guessing this is a problem, but I'm not sure.
There's a couple of ways to fix this. One is for anyone with enough info about
specific requirements to give me some suggestions, or if anyone has auto232 and
is also a C programmer, by all means debug/fix this and send me the code. If
anyone has a suggestion, feel free to pass it on. I'd like to see this work
as it should and put this to sleep...
Chris Whittington
--
http://www.demon.co.uk/oxford-soft
Robert Hyatt <hy...@crafty.cis.uab.edu> wrote in article
<5fdls9$6...@juniper.cis.uab.edu>...
> I'm still struggling with the auto232 interface problem in Crafty. While
> I'm not exactly frantic to hit the SSDF list, it seems that I should at
least
> make it possible for them to test Crafty should they want to do so.
>
> Here's the current situation: apparently, with "ponder=off", crafty will
> play games perfectly. However, with "ponder=on" it seems to hang, on
> occasion, specifically when the opponent makes the move Crafty is
expecting.
>
> I can't see any reason for this. I have run this under unix many times,
> and found a series of moves where Crafty would make the same move with
> ponder=off or on. I used the "autoplay" command which makes crafty open
> a file to "PRN" which goes to the printer in DOS, but creates a file in
> unix. I then played through the game with and without pondering, and
amazingly
> the files are identical, byte for byte.
>
> This leads me to believe that it is a timing difficulty in auto232,
rather
> than something odd in Crafty. Does anyone know anything about any
specific
> timing requirements? For example, if the opponent makes the move crafty
> expects, crafty will echo the move as it is supposed to, but it will
defer
> the echo for a while, until just before crafty echos its own move. I'm
> guessing this is a problem, but I'm not sure.
I'm fairly sure there is a timing problem with the 232 software. If CSTal
plays an 'immediate' response (like there was only one legal move), 232
fails to pass it on to the other computer.
And about one game in 30 or so the whole system crashes.
232 is a great piece of software, and has done wonders for programmers and
the ssdf alike, but there are some small problems.
One big problem is a total inability to be able to get to talk to them
about possible new versions or fixes.
Has anybody got a later version of the software than me, perhaps ?
Does anybody know if/when the windows95 version of 232 will be done ?
Rumour said April or March 1997.
Chris Whittington
Amir Ban
Robert Hyatt wrote:
>
> I'm still struggling with the auto232 interface problem in Crafty. While
> I'm not exactly frantic to hit the SSDF list, it seems that I should at least
> make it possible for them to test Crafty should they want to do so.
>
> Here's the current situation: apparently, with "ponder=off", crafty will
> play games perfectly. However, with "ponder=on" it seems to hang, on
> occasion, specifically when the opponent makes the move Crafty is expecting.
>
I had a very similar problem, and it turned out to be my fault. The auto232 interface
will hang if your program falls out of sync with the input. For example, your permanent
brain may poll for input, find it but fail to act on it. You will now continue polling
for input that won't be coming a second time. When you input from the keyboard, it's
easy to ignore this because it seems like you didn't really press that button or click
that mouse. In Junior, it was bit more subtle, in that the permanent brain picked up
the input and cancelled itself, but while going through the motions of cancelling and
returning to the UI, it sometimes continued to poll the input, erasing the original
input and otherwise creating a mess.
Try monitoring your inputs with an acknowledge flag to see if any input gets lost.
Amir
Robert Hyatt
Chris Whittington (chr...@demon.co.uk) wrote:
: --
: http://www.demon.co.uk/oxford-soft
: Robert Hyatt <hy...@crafty.cis.uab.edu> wrote in article
: <5fdls9$6...@juniper.cis.uab.edu>...
: > I'm still struggling with the auto232 interface problem in Crafty. While
: > I'm not exactly frantic to hit the SSDF list, it seems that I should at
: least
: > make it possible for them to test Crafty should they want to do so.
: >
: > Here's the current situation: apparently, with "ponder=off", crafty will
: > play games perfectly. However, with "ponder=on" it seems to hang, on
: > occasion, specifically when the opponent makes the move Crafty is
: expecting.
: >
: > I can't see any reason for this. I have run this under unix many times,
: > and found a series of moves where Crafty would make the same move with
: > ponder=off or on. I used the "autoplay" command which makes crafty open
: > a file to "PRN" which goes to the printer in DOS, but creates a file in
: > unix. I then played through the game with and without pondering, and
: amazingly
: > the files are identical, byte for byte.
: >
: > This leads me to believe that it is a timing difficulty in auto232,
: rather
: > than something odd in Crafty. Does anyone know anything about any
: specific
: > timing requirements? For example, if the opponent makes the move crafty
: > expects, crafty will echo the move as it is supposed to, but it will
: defer
: > the echo for a while, until just before crafty echos its own move. I'm
: > guessing this is a problem, but I'm not sure.
: I'm fairly sure there is a timing problem with the 232 software. If CSTal
: plays an 'immediate' response (like there was only one legal move), 232
: fails to pass it on to the other computer.
This is my glitch then, because if the opponent plays the correct
(predicted) move, crafty will defer echoing this move until it plays
its own move. They will arrive at auto232's doorstep within just
milliseconds of each other at best, probably within a few tens of
microseconds at worst. This says I should probably kludge the
code to echo the move just as soon as it comes in...
But then there's the instant move problem. If the opponent takes a
long time and plays the predicted move, many times crafty will move
instantly. Other times if there is only one legal move, this will
produce an instant reply as well.
I suppose I could add a sleep(2) which would not hurt much except
for blitz games of course. But for long games, that might be the
thing to do...???
: And about one game in 30 or so the whole system crashes.
: 232 is a great piece of software, and has done wonders for programmers and
: the ssdf alike, but there are some small problems.
: One big problem is a total inability to be able to get to talk to them
: about possible new versions or fixes.
: Has anybody got a later version of the software than me, perhaps ?
: Does anybody know if/when the windows95 version of 232 will be done ?
: Rumour said April or March 1997.
: Chris Whittington
: >
: >
: >
ChessBase GmbH
Chris Whittington wrote:
> One big problem is a total inability to be able to get to talk to them
> about possible new versions or fixes.
>
> Has anybody got a later version of the software than me, perhaps ?
>
> Does anybody know if/when the windows95 version of 232 will be done ?
> Rumour said April or March 1997.
>
> Chris Whittington
>
Would it make sense to discuss a new communication standard for chess
programs here so that all DOS and Windows programs in the future simply
implement this? Two machines could play directly against each other
without an intermediate software. The protocol should be
extensible/downward compatible like PGN to allow advanced features like
comparing evaluations etc.
--
Matthias Wuellenweber
mailto:wuelle...@compuserve.com
http://www.chessbase.com
ChessBase GmbH
Suggestion:
Chess Computer Communication Protocol ("CCCP").
** 1. Minimum set of CCCP-commands
OPEN
Start communication
CLOSE
End communication
NEWGAME
BLITZ t, f
Set blitz time control, t = seconds per whole game, f = Fischer-Offset
TOURN t1, m1, t2, m2, t3
Set tournament time control t1 minutes for m1 moves,
t2 minutes for next m2 moves, t3 minutes for rest of game.
MOVE E2E4
four character (+optional promotion char) move
WHITE
Receiver begins.
RESIGN
DRAW
Handshake = "REJECT", "ACCEPT".
KNOW command.
Ask receiver whether he understands the command 'command'.
** 2. Handshake
OK
Command recognized and legal
ERROR "message"
Command recognized but illegal
message is an arbitrary redundant string
"wrong parameter" or "not your move".
UNKNOWN
Command not recognized (in this implementation)
** 3. Example for a CCCP-game, Prog A is master, Prog B is slave as
White.
Prog A: Prog B:
OPEN
OK
NAME
'CHESS 1.0'
TIMEBLITZ 300
OK
NEWGAME
OK
WHITE
OK
MOVE D2D4
OK
MOVE D7D5
OK
MOVE C2C4
OK
MOVE E7E6
OK
DRAW
REJECT
RESIGN
OK
CLOSE
OK
** 4. Timeout
No handshake after n secs <=> receiver not valid.
mclane
hy...@crafty.cis.uab.edu (Robert Hyatt) wrote:
1. ok - ask John stanback, he has IMO fixed the interface working for
his zarkov.
2. Andreas Mader could be asked to inform Chrilly about your problems.
Robert Hyatt
Amir Ban (ami...@msys.co.il) wrote:
: Robert Hyatt wrote:
: >
: > I'm not exactly frantic to hit the SSDF list, it seems that I should at least
: > make it possible for them to test Crafty should they want to do so.
: >
: > Here's the current situation: apparently, with "ponder=off", crafty will
: > play games perfectly. However, with "ponder=on" it seems to hang, on
: > occasion, specifically when the opponent makes the move Crafty is expecting.
: >
: I had a very similar problem, and it turned out to be my fault. The auto232 interface
: will hang if your program falls out of sync with the input. For example, your permanent
: brain may poll for input, find it but fail to act on it. You will now continue polling
: for input that won't be coming a second time. When you input from the keyboard, it's
: easy to ignore this because it seems like you didn't really press that button or click
: that mouse. In Junior, it was bit more subtle, in that the permanent brain picked up
: the input and cancelled itself, but while going through the motions of cancelling and
: returning to the UI, it sometimes continued to poll the input, erasing the original
: input and otherwise creating a mess.
: Try monitoring your inputs with an acknowledge flag to see if any input gets lost.
: Amir
This isn't happening in this case. Everything in Crafty's log looks
perfectly normal. we see the move from auto232, the response back, and
nothing. Auto232 is apparently waiting on something from Crafty, yet
the log shows that it was sent.
I've run this manually to confirm that with ponderong on and off, the output
from crafty is identical... it only seems to fail when the opponent makes the
move crafty predicts. Other moves are read just fine. But when it reads the
move that's predicted, it continues thinking, then, in rapid succession first
echos the move from auto232 back to auto232, then immediately follows this
with crafty's move. On slower machines it seems to happen less frequently,
but on a P6/200, the first correct ponder move hangs...
Any other ideas? Chris mentioned another case I have in that if I get a
move from auto232 and Crafty has only one legal move, I'll fire the move
back within microseconds. He reported that he had had hanging problems there
too. Seen anything like that??
Ed Schroder
hy...@crafty.cis.uab.edu (Robert Hyatt) wrote:
>Amir Ban (ami...@msys.co.il) wrote:
Perhaps you check the keyboard too often?
In Rebel I check the keyboard every 50-500 evaluations depending on the
processor type.
- Ed Schroder -
Robert Hyatt
Ed Schroder (rebc...@xs4all.nl) wrote:
: Perhaps you check the keyboard too often?
: In Rebel I check the keyboard every 50-500 evaluations depending on the
: processor type.
: - Ed Schroder -
In crafty, in "standard" games, I check it about once every 3 seconds or
so... As the time per move goes down, so does this... down to checking it
about every 1 second, to .1 seconds (when the time per move is one sec or
less... etc..)
Vincent Diepeveen
>--
>http://www.demon.co.uk/oxford-soft
>
>Robert Hyatt <hy...@crafty.cis.uab.edu> wrote in article
><5fdls9$6...@juniper.cis.uab.edu>...
>> I'm still struggling with the auto232 interface problem in Crafty. While
>> I'm not exactly frantic to hit the SSDF list, it seems that I should at
>least
>> make it possible for them to test Crafty should they want to do so.
>>
>> Here's the current situation: apparently, with "ponder=off", crafty will
>> play games perfectly. However, with "ponder=on" it seems to hang, on
>> occasion, specifically when the opponent makes the move Crafty is
>expecting.
>>
>> I can't see any reason for this. I have run this under unix many times,
>> and found a series of moves where Crafty would make the same move with
>> ponder=off or on. I used the "autoplay" command which makes crafty open
>> a file to "PRN" which goes to the printer in DOS, but creates a file in
>> unix. I then played through the game with and without pondering, and
>amazingly
>> the files are identical, byte for byte.
>>
>> This leads me to believe that it is a timing difficulty in auto232,
>rather
>> than something odd in Crafty. Does anyone know anything about any
>specific
>> timing requirements? For example, if the opponent makes the move crafty
>> expects, crafty will echo the move as it is supposed to, but it will
>defer
>> the echo for a while, until just before crafty echos its own move. I'm
>> guessing this is a problem, but I'm not sure.
>
>I'm fairly sure there is a timing problem with the 232 software. If CSTal
>plays an 'immediate' response (like there was only one legal move), 232
>fails to pass it on to the other computer.
>
>And about one game in 30 or so the whole system crashes.
>
>232 is a great piece of software, and has done wonders for programmers and
>the ssdf alike, but there are some small problems.
auto232 definitely is a great piece of software.
I introduced a keyspeed variable in Diep for this reason. At fast hardware
Diep asked about 20 - 40 times a second the standard input in auto232 play.
This seemed causing Diep get stuck: it stopped auto232 playing in the
middle of a game.
After removing emm386 from config.sys (diep uses dos4gw) and reducing
the number of calls to the kbhit() function (about 4-8 times a second),
the problem was solved.
Also i need regurarly use scandisk in order to fix IDE drives (SCSI
doesn't give problems) when using auto232. This was not a bug with
Diep, as it happened only after i used auto232, and i also had exactly
the same problem after using auto232 with the other computer where Diep
never has run on, but only Kallisto,Fritz,Genius.
This only happened when autoplay took several days (without stopping
computers in between). Sessions of about 24-36
hours or less never gave problems.
>Has anybody got a later version of the software than me, perhaps ?
>Does anybody know if/when the windows95 version of 232 will be done ?
>Rumour said April or March 1997.
That would be interesting.
>Chris Whittington
>
>>
>> There's a couple of ways to fix this. One is for anyone with enough info
>about
>> specific requirements to give me some suggestions, or if anyone has
>auto232 and
>> is also a C programmer, by all means debug/fix this and send me the code.
> If
>> anyone has a suggestion, feel free to pass it on. I'd like to see this
>work
>> as it should and put this to sleep...
>>
>>
>>
--
+----------------------------------------------------+
| Vincent Diepeveen email: vdie...@cs.ruu.nl |
| http://www.students.cs.ruu.nl/~vdiepeve/ |
+----------------------------------------------------+
Ed Schroder
I forgot to tell that checking the keyboard to less can give the same
problems as I noticed 3 years ago with my own written Autoplayer.
Perhaps you should try a test version that checks the keyboard 20-30
times a second in the permanent brain and see what happens then.
The problem you describe looks timing related.
- Ed Schroder -
Jean-Peter Fendrich
ChessBase GmbH wrote:
> Would it make sense to discuss a new communication standard for chess
> programs here so that all DOS and Windows programs in the future simply
> implement this? Two machines could play directly against each other
> without an intermediate software. The protocol should be
> extensible/downward compatible like PGN to allow advanced features like
> comparing evaluations etc.
>
> --
> Matthias Wuellenweber
> mailto:wuelle...@compuserve.com
I would think that most of the commercial guys are not interrested, even
if the rest of us think this is a great idea. Bruce and Bob does
probably not care, because they have seen the light and acquired the
great wisdom that computer vs computer games is not exactly the same
as computer vs human games and are therefor of no interrest.
Did anyone catch the really bitter sarcasm here??? ... :-)
--
J-P Fendrich
Chris Whittington
--
http://www.demon.co.uk/oxford-soft
ChessBase GmbH <Wuelle...@t-online.de> wrote in article
<5fen6r$2...@news00.btx.dtag.de>...
> Chris Whittington wrote:
>
> > One big problem is a total inability to be able to get to talk to them
> > about possible new versions or fixes.
> >
> > Has anybody got a later version of the software than me, perhaps ?
> >
> > Does anybody know if/when the windows95 version of 232 will be done ?
> > Rumour said April or March 1997.
> >
> > Chris Whittington
> >
>
> Would it make sense to discuss a new communication standard for chess
> programs here so that all DOS and Windows programs in the future simply
> implement this? Two machines could play directly against each other
> without an intermediate software. The protocol should be
> extensible/downward compatible like PGN to allow advanced features like
> comparing evaluations etc.
I'ld be absolutely in favour.
Factors:
1. Must be asy to implement
2. Preferably use network technology, then just dump a file each move, and
search for a file while pondering.
3. Network has advantage of allowing different system types to be connected
(the hard work got done by the network software)
Chris Whittington
Don Fong
In article <5fen6r$2...@news00.btx.dtag.de>,
ChessBase GmbH <Wuelle...@t-online.de> wrote:
>Would it make sense to discuss a new communication standard for chess
>programs here so that all DOS and Windows programs in the future simply
>implement this? Two machines could play directly against each other
>without an intermediate software. The protocol should be
>extensible/downward compatible like PGN to allow advanced features like
>comparing evaluations etc.
here is a slightly different idea.
IMHO it is a good idea for 2 programs to be able to communicate
with each other. but - IMHO it would be better NOT to do it directly,
but with intermediate software instead. the chess programs should be
designed to talk to the intermediate software, NOT to each other.
PROGA <--> AUTOPLAYER <--> PROGB (a)
vs
PROGA <--> PROGB (b)
why is (a) better than (b)? because it is more flexible.
under (a), the AUTOPLAYER software can evolve without requiring
changes to PROGA or PROGB, and vice versa. PROGA and PROGB
would only have to implement generic communication facilities, plus a
command-driven hook of some kind. it does not have to be
THE SAME commands on both sides, as it would under (b),
because the AUTOPLAYER s/w could be programmed asymmetrically.
the whole thing could be script-driven.
AUTOPLAYER could also simplify the problem of interfacing
thru different comms media, because that would be handled
by AUTOPLAYER rather than by PROGA and PROGB.
in this scheme, neither PROGA nor PROGB is the "master";
AUTOPLAYER is the "master".
AUTOPLAYER
/ \ (a) redrawn
/ \
PROGA PROGB
PROGB might be talking thru a directly-connected modem,
an rs232, it might be behind a firewall, or whatever.
it would be the job of AUTOPLAYER to handle these vagaries.
AUTOA <--> AUTOB
/ \ (a) redrawn
/ \
PROGA PROGB
i have never used auto232, but i am guessing it is something similar
though more limited, because many programs were not intentionally
designed to use it.
note that PROGA and PROGB do not have to implement the same set
of commands, they only have to implement the right functionality,
which could be done in different ways. for example, the autoplayer
interface might look like this. assume PROGA has a Game menu,
and Start is the item that starts a game. then the AUTOPLAYER
might send the following to PROGA to start a game.
VALUE Options|TimeControl=2/12
VALUE Options|Autoplayer=1
VALUE Side=White
MENU Game|Start
whereas with PROGB it might be
VALUE Time|PerMove=120
VALUE Time|Increment=12
VALUE Options|Autoplayer=1
MENU Game|Play|Black
this is a lot like a generic recorder/playback facility.
the difference is that the programs would be DESIGNED to
use it, instead of having to use an unreliable playback hack.
note that this scheme gives an obvious way for a program
to export its entire functionality thru the AUTOPLAYER interface.
AUTOPLAYER would also handle timing issues independent of
either program. note that i haven't specified how AUTOPLAYER
itself would be scripted; it could incorporate a fancy
scripting language (or not).
ChessBase GmbH
Jean-Peter Fendrich wrote:
>
> ChessBase GmbH wrote:
>
> > Would it make sense to discuss a new communication standard for chess
> > programs here so that all DOS and Windows programs in the future simply
> > implement this? Two machines could play directly against each other
> > without an intermediate software. The protocol should be
> > extensible/downward compatible like PGN to allow advanced features like
> > comparing evaluations etc.
> >
> if the rest of us think this is a great idea. Bruce and Bob does
> probably not care, because they have seen the light and acquired the
> great wisdom that computer vs computer games is not exactly the same
> as computer vs human games and are therefor of no interrest.
> Did anyone catch the really bitter sarcasm here??? ... :-)
>
> --
> J-P Fendrich
The commercial argument: Good communication between chess software seems
a reasonable incentive to buy more than one program.
Vincent Diepeveen
>In article <5fen6r$2...@news00.btx.dtag.de>,
>ChessBase GmbH <Wuelle...@t-online.de> wrote:
>>Would it make sense to discuss a new communication standard for chess
>>programs here so that all DOS and Windows programs in the future simply
>>implement this? Two machines could play directly against each other
>>without an intermediate software. The protocol should be
>>extensible/downward compatible like PGN to allow advanced features like
>>comparing evaluations etc.
>
> here is a slightly different idea.
>
> IMHO it is a good idea for 2 programs to be able to communicate
>with each other. but - IMHO it would be better NOT to do it directly,
>but with intermediate software instead. the chess programs should be
>designed to talk to the intermediate software, NOT to each other.
>
> PROGA <--> AUTOPLAYER <--> PROGB (a)
This is almost exactly what the auto232 player does.
So your comments only support the auto232 software.
In fact it is more like:
ProgA <--> AutoplayerA === AutoplayerB <--> ProgB
So the auto232 player is more advanced than you guessed.
The problem is that under windows95/97/nt one needs other an other
implementation. the auto232 dos player works perfectly.
My plans are however to also make a windows version of Diep in the
futuer. Graphics under windows simply is nicer. windows95/97 is the way to go,
although DOS support of Diep will remain next years. I simply make an
engine that works with an interface with both DOS and windows.
It seems that the newest version of Diep, where one can manually
set the hashtable size works fine under Memphis/windows95.
Memphis even multitasks the Diep program splendid.
Jean-Peter Fendrich
A nice piece of design in my opinion.
I have a feeling that the output and input to the AUTOPLAYER should be
managed differently.
The programmers need a list of a minimum set of functions needed in
the program to play a succession of games. Then they (the programmers)
have to define which strings the program needs, to fulfill each of the
functions.
The AUTOPLAYER would be configured to send the desired strings (your
script?).
The input however, is another list with the commands possible to send to
the AUTOPLAYER. If this is defined in a protocol fashion, I think a lot
of errors will be avoided and I can't find any reason why this should be
configurable.
--
J-P Fendrich
Don Fong wrote:
>
> here is a slightly different idea.
>
> IMHO it is a good idea for 2 programs to be able to communicate
> with each other. but - IMHO it would be better NOT to do it directly,
> but with intermediate software instead. the chess programs should be
> designed to talk to the intermediate software, NOT to each other.
>
> PROGA <--> AUTOPLAYER <--> PROGB (a)
> vs
> PROGA <--> PROGB (b)
>
> why is (a) better than (b)? because it is more flexible.
> under (a), the AUTOPLAYER software can evolve without requiring
> changes to PROGA or PROGB, and vice versa. PROGA and PROGB
> would only have to implement generic communication facilities, plus a
> command-driven hook of some kind. it does not have to be
> THE SAME commands on both sides, as it would under (b),
> because the AUTOPLAYER s/w could be programmed asymmetrically.
> the whole thing could be script-driven.
>
> AUTOPLAYER could also simplify the problem of interfacing
> thru different comms media, because that would be handled
> by AUTOPLAYER rather than by PROGA and PROGB.
>
> in this scheme, neither PROGA nor PROGB is the "master";
> AUTOPLAYER is the "master".
>
> AUTOPLAYER
> / \ (a) redrawn
> / \
> PROGA PROGB
>
> PROGB might be talking thru a directly-connected modem,
> an rs232, it might be behind a firewall, or whatever.
> it would be the job of AUTOPLAYER to handle these vagaries.
>
ChessBase GmbH
Don Fong wrote:
>
> In article <5fen6r$2...@news00.btx.dtag.de>,
> ChessBase GmbH <Wuelle...@t-online.de> wrote:
> >Would it make sense to discuss a new communication standard for chess
> >programs here so that all DOS and Windows programs in the future simply
> >implement this? Two machines could play directly against each other
> >without an intermediate software. The protocol should be
> >extensible/downward compatible like PGN to allow advanced features like
> >comparing evaluations etc.
>
Don,
your proposal of an independent autoplayer looks general and elegant.
But as often in programming, desire for generality seems to make things
expensive and complicated. For practical and commercial purposes I would
plead for a direct interaction between two programs, a kind of plug and
play thing. I'd be nervous about the multitasking effects between the
independent autoplayer software and the chessprogram in one computer.
Say you have a program on your desktop which supports the Chess Computer
Copulation Protocol CCCP. Now isn't it seducing to simply buy another
CCCP-compatible program for your notebook, plug in the rs232-cable,
start "CCCP-Match" on the desktop-program and "CCCP-responder" on the
notebook-program and off you go. You don't need extra software and it
seems to fulfill the KISS-rule (keep it simple and stupid).
Don Fong
In article <5fovgm$d...@news00.btx.dtag.de>,
ChessBase GmbH <Wuelle...@t-online.de> wrote:
>your proposal of an independent autoplayer looks general and elegant.
>But as often in programming, desire for generality seems to make things
>expensive and complicated. For practical and commercial purposes I would
>plead for a direct interaction between two programs, a kind of plug and
>play thing.
let me put it this way. from the user's standpoint, the two
approaches are functionally equivalent. but from the implementer's
standpoint, it seems much simpler to isolate the interaction in
a separate piece of software.
i have seen a lot of articles about how many commercial chess
programs have "blown" their implementation of PGN support. if they
can't even implement a relatively simple standard like PGN, i have to
doubt how well they would implement your integrated CCCP protocol.
the difference is that it would be easier to fix a separate piece of
software. and the program-specific part would be smaller.
also look at the difficulty that people have had interfacing
crafty and xboard. again a relatively simple protocol.
therefore, it seems to me that a separate s/w is MORE practical.
then there is the political issue. in order for your CCCP to be
successful, a number of programmers have to buy in to it. i think
it would be easier to get agreement on something that is flexible
and can be tailored to the individual programs. if an unforeseen
need arises in the future, it can be met by updating the autoplayer,
(or maybe just a tweaking the autoplayer scripts) rather than by
having to re-release all the programs, or some other inconvenience.
i think your worry about multitasking is legitimate,
but it can be done right. under windows, the autoplayer could
even be a DLL rather than a separate task (depending on what
functionality you wanted in it).
[...]
>Say you have a program on your desktop which supports the Chess Computer
>Copulation Protocol CCCP. Now isn't it seducing to simply buy another
>CCCP-compatible program for your notebook, plug in the rs232-cable,
>start "CCCP-Match" on the desktop-program and "CCCP-responder" on the
>notebook-program and off you go. You don't need extra software and it
>seems to fulfill the KISS-rule (keep it simple and stupid).
IMHO that simplicity is deceptive. it is "simple" as long as you
don't mind putting a lot of comm-specific stuff in your program, and
getting stuck with a limited and inflexible command set. IMHO a quick
and dirty design is often regretted in the long run.
suppose i am a chess programmer, and i want to implement the CCCP.
(a) with the integrated approach, i have to implement the entire command
set and a bunch of comm functions. (b) with the separate s/w approach,
i only have to implement a single communication mechanism (because
the comm functions are built in to the autoplayer). i don't have to
implement the special command set because the autoplayer can be configured
(within reason) to deal with the command set that is natural to my design.
and there is an extra payoff because the autoplayer s/w could be
programmed to automate ANYTHING that my program can do.
since i am not a chess programmer, i don't intend to say much more.
certainly there are reasonable arguments on both sides. this is just
my suggestion, submitted for discussion.
Moritz Berger
On 7 Mar 1997 11:51:50 GMT, Wuelle...@t-online.de (ChessBase GmbH)
wrote:
< snip >
>Say you have a program on your desktop which supports the Chess Computer
>Copulation Protocol CCCP. Now isn't it seducing to simply buy another
>CCCP-compatible program for your notebook, plug in the rs232-cable,
>start "CCCP-Match" on the desktop-program and "CCCP-responder" on the
>notebook-program and off you go. You don't need extra software and it
>seems to fulfill the KISS-rule (keep it simple and stupid).
>
But wouldn't Bobby Fischer complain again about "CCCP-Matches"
in chess?
And since when is Kommunist International Socialist Solidarity (KISS)
one of your goals?
I was always highly sceptical about your all-too-capitalistic
behaviour, now you have unwillingly shown us your true face, comrade
Wuellenweber.
Thanks for postings this in our Komputer Games Board.
;-)))
Moritz
-------------
Moritz...@msn.com
ChessBase GmbH
Moritz Berger wrote:
>
> But wouldn't Bobby Fischer complain again about "CCCP-Matches"
> in chess?
>
> And since when is Kommunist International Socialist Solidarity (KISS)
> one of your goals?
>
> I was always highly sceptical about your all-too-capitalistic
> behaviour, now you have unwillingly shown us your true face, comrade
> Wuellenweber.
>
> Thanks for postings this in our Komputer Games Board.
>
> ;-)))
>
> Moritz
>
Gospodin Berger!
any premature public discussion about the objectives of the
Confederation of Communist Chess Programmers (CCCP) will harm our goals.
So I recommend we remain silent and watchful until our time has come!
Our ranks are growing by the day.
Long live the Common Cause of Computing Power!
Komputer Korner
ChessBase GmbH wrote:
>
>
> Gospodin Berger!
>
> any premature public discussion about the objectives of the
> Confederation of Communist Chess Programmers (CCCP) will harm our goals.
> So I recommend we remain silent and watchful until our time has come!
> Our ranks are growing by the day.
>
> Long live the Common Cause of Computing Power!
>
> --
> Matthias Wuellenweber
> mailto:wuelle...@compuserve.com
> http://www.chessbase.com
Everybody has a mosquito. Goodness knows, enough are trying to bite me.
--
Komputer Korner
The inkompetent komputer.