Re: conspiring to do chess programs

Aha ! Actual, nonspam CONTENT here !!

I'll look at your project.

I also suggest you look at my project on sourceforge, ch0, with a view 
to possibly us conspiring.

I don't have the gnu-compatibility features at all, BUT, it does play 
itself including en passant, promotion ( to QRNB ), correct castling 
(including the travel-over-check constraint), and (I think) the 50-move 
rule. It doesn't deal with the 3-repetition rule yet.

It used to do king swaps, but if I recall correctly I solved that.

It was designed to display using the Turbo C equivalent to curses, in 
order to be tolerably informative but machine efficient.


> Date: Thu, 01 Jun 2006 07:31:24 -0400
> From: Ethan A Burns <[email protected]>
> Subject: Re: gnuchess/xboard protocol
> To: [email protected]
> Message-ID: <[email protected]>
> 
> If anyone was curious, I have finally made a sourceforge page for my project.
> I am now going to take a small break from it, however, it is playable with
> gnuchess.  It does castling, capturing, and basic moves but not pawn promotion,
> or en passant.
> 
> 		--Ethan
>  
> 
>>Ethan A Burns wrote:
>>
>>>http://www.tim-mann.org/xboard/engine-intf.html
>>>
>>>Looking at this page and comparing with output from ``gnuchess --xboard''
>>>doesn't match up.
>>>
>>>Does anyone have input for this?  Is this document out dated now?
>>
>>The document is current.
>>
>>Deviations are bugs, or in some cases just missing features.
>>
>>
>>>Chess
>>>Adjusting HashSize to 1024 slots
>>>...
>>
>>>Testing around a bit, sending and reading (reading in a seperate thread), I 
>>>found that gnuchess only seems to send output to my pipe AFTER receiving a 
>>>move from my program.
>>
>>It is easier to look at the source for this, as you'll see where output
>>is done to the stdout, in xboard mode, the pipe is explicitly flushed
>>(the code should have been refactored to stuff this into a subroutine).
>>
>>It isn't flushed for the hash output, so I think this is a clear bug
>>(Indeed I'll have to check if it should be output at all).
>>
>>I think the reason it doesn't cause any issues for most of the programs
>>that work with it because of how they do the communication. Most do a
>>"ping", and check for "pong", and so eat all this dross in the output
>>that shouldn't be there at start-up.
>>
>>I will tidy this up for the next release, but suggest the "ping"/"pong"
>>check is probably worth doing in general and as a workaround if you have
>>to cope with earlier GNU Chess versions.
>>
>>Can I ask what your program does?
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Thu, 01 Jun 2006 07:32:42 -0400
> From: Ethan A Burns <[email protected]>
> Subject: Re: gnuchess/xboard protocol
> To: [email protected]
> Message-ID: <[email protected]>
> 
> sorry to spam but I forgot the sourceforge url:
> 	https://sourceforge.net/projects/glutboard
> 
> 
>>If anyone was curious, I have finally made a sourceforge page for my project.
>>I am now going to take a small break from it, however, it is playable with
>>gnuchess.  It does castling, capturing, and basic moves but not pawn promotion
>>,
>>or en passant.
>>
>>--Ethan
>>
>>
>>>Ethan A Burns wrote:
>>>
>>>>http://www.tim-mann.org/xboard/engine-intf.html
>>>>
>>>>Looking at this page and comparing with output from ``gnuchess --xboard''
>>>>doesn't match up.
>>>>
>>>>Does anyone have input for this?  Is this document out dated now?
>>>
>>>The document is current.
>>>
>>>Deviations are bugs, or in some cases just missing features.
>>>
>>>
>>>>Chess
>>>>Adjusting HashSize to 1024 slots
>>>>...
>>>
>>>>Testing around a bit, sending and reading (reading in a seperate thread), I
>>
>>>>found that gnuchess only seems to send output to my pipe AFTER receiving a 
>>>>move from my program.
>>>
>>>It is easier to look at the source for this, as you'll see where output
>>>is done to the stdout, in xboard mode, the pipe is explicitly flushed
>>>(the code should have been refactored to stuff this into a subroutine).
>>>
>>>It isn't flushed for the hash output, so I think this is a clear bug
>>>(Indeed I'll have to check if it should be output at all).
>>>
>>>I think the reason it doesn't cause any issues for most of the programs
>>>that work with it because of how they do the communication. Most do a
>>>"ping", and check for "pong", and so eat all this dross in the output
>>>that shouldn't be there at start-up.
>>>
>>>I will tidy this up for the next release, but suggest the "ping"/"pong"
>>>check is probably worth doing in general and as a workaround if you have
>>>to cope with earlier GNU Chess versions.
>>>
>>>Can I ask what your program does?
> 
> 
> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> Info-gnu-chess mailing list
> [email protected]
> http://lists.gnu.org/mailman/listinfo/info-gnu-chess
> 
> 
> End of Info-gnu-chess Digest, Vol 36, Issue 1
> *********************************************
>