I know it's usually not good practice, but...

[yoshiharu]

Hi everybody,

in the attempt to simplify the relay of a game, I developed a small node.js program, using the undocumented /serverMoves option: basically my program watches the file produced by winboard, parses and converts it in pgn, and sends the result of the conversion via ftp to a server running pgn4web or anything else that can read pgn files.
The stuff is working fine, but there is at least one problem: when the file passed as argument to serverMoves does already exist, winboard apparently freezes at startup.
When issuing a "New Game" command, instead, the GUI takes a long time (much longer than usual) to restart the game, but it eventually succeeds, and the text file is overwritten as a result.
I looked into the source but I couldn't find the point where the GUI opens the file, so I couldn't figure out whether the problem was only mine or was it a bug.

Thanks in advance.

Cheers, Mauro

[yoshiharu]

when the file passed as argument to serverMoves does already exist, winboard apparently freezes at startup.

Nevermind, I just found out: xboard waits 15 seconds before overwriting the file.
Ok, now I have a second problem: when playing on an ICS xboard only writes to the text file the moves from the engine, and not the moves sent by the opponent.
Reading the source I haven't figured out yet why it behaves this way: any hints?

Thanks in adv.

Cheers, Mauro

[H.G.Muller]

You can get rid of the 15 sec by using /serverPause=0. I use the pause to give everyone that watches the opportunity to see the end of the previous game, when they are probing only once every 10 sec. The delay is not written in a very clean way: it does busy waiting in an event handler, which effectively freezes WinBoard completely. But I never got to fix that. (It is an undocumented option, after all.)

The moves are written to the file in WinBoard's routine MakeMove, which performs moves gotten from the engine or entered by the user. Unfortunately, in ICS play, WinBoad does not make moves for the ICS side. It just receives the boards the ICS sends it, and stores/displays those.

[yoshiharu]

You can get rid of the 15 sec by using /serverPause=0.

Ok, thanks! I missed it.

The moves are written to the file in WinBoard's routine MakeMove, which performs moves gotten from the engine or entered by the user. Unfortunately, in ICS play, WinBoad does not make moves for the ICS side. It just receives the boards the ICS sends it, and stores/displays those.

Hmm, I see.
But isn't the server sending (together with the board) also the last move played?
Also, since at some point xboard has to put the move into the move list, that could maybe be the best time to update the text file, IMHO.
I'm not into xboard/winboard internals, really, but it seems to me that the moment the moves go into the move list is the most appropriate one to update that file too, as that shouldn't depend on the source of the moves themselves, be it a local engine, a human, somebody through FICS etc.
What do you think about it?

Cheers, Mauro

[H.G.Muller]

Yes, the move is in the 'board' the ICS sends. Twice, actually, in SAN and a long format (like 'P/e2-e4', which surprisingly always omits the promotion suffix). And indeed, code could be put in to also save that move into the /serverMoves file. It is just that I never did that. There is no single place in WinBoard where moves are written into the move list; this is just coded several times independently. But of course it would be possible to put the code for updating the /serverMoves file into its own subroutine, (currently it i just in-lined it in MakeMove), and call that twice.

It is just that I never did this. I mainly included this feature for 'private consumption', to enable me to broadcast variant games that TLCV cannot handle. And I never had the need to broadcast ICS games. There seemed little need to do that, as ICS are broadcasting devices themselves, of a highly superior nature compared to what I could ever achieve with WinBoard + ChessLive!.

So I have some doubt as to the usefulness of this. Games can also be extracted from the winboard.debug file, which contains a full transcript of all communication with engines and ICS, and is updated in real time. There actually exists debug->PGN converter software (for normal Chess, so I never used it).

[yoshiharu]

There is no single place in WinBoard where moves are written into the move list; this is just coded several times independently.

I see. Xboard/Winboard source to me is surprisingly complicated, browsing it I wasn't able to completely figure out the logic of it. I was sort of hoping there was some point of "confluence" in the many "streams of moves".

I never had the need to broadcast ICS games. There seemed little need to do that, as ICS are broadcasting devices themselves, of a highly superior nature compared to what I could ever achieve with WinBoard + ChessLive!.

I see, but to get those relays from the ICS every watcher must be logged in onto the ICS, plus some other complication: our aim is actually to popularise computer chess in our country, making it much more visible than today among chess players. See it as "a hobby within a hobby"
Actually one idea some month ago was to use a custom ICS to play our (OTB) tournaments, to have an automatic relay mechanism, but that was not suitable for classic OTB tournaments (I mean those with pushing wood involved ), and was perhaps a little bit overshooting

So I have some doubt as to the usefulness of this. Games can also be extracted from the winboard.debug file, which contains a full transcript of all communication with engines and ICS, and is updated in real time. There actually exists debug->PGN converter software (for normal Chess, so I never used it).

Yes, I know that: indeed with some small modifications the program I wrote is able to do that, too. But actually winboard.debug is a big file, while the file produced by /serverMoves is much smaller, so it is lighter to parse.
I must say also that last time I tried to use winboard.debug - while in the source I can see it is updated move by move (actually "event by event" as every thing is logged) - from the outside it looked like as if there was quite some delay in the update (at least on my system): is this possibly caused by normal OS buffering and such?

One thing I wished would be available on every system (and not just Unix-like ones) is the named pipe mechanism: that would pretty much simplify a lot of things...

Cheers, Mauro

[H.G.Muller]

I see. Xboard/Winboard source to me is surprisingly complicated, browsing it I wasn't able to completely figure out the logic of it. I was sort of hoping there was some point of "confluence" in the many "streams of moves".

The code is mostly awful, and contains lots of copy-paste duplications. Especially the ICS code is almost compleletey divorced from the rest of the code, like it is a completely independent program.

I see, but to get those relays from the ICS every watcher must be logged in onto the ICS, plus some other complication: our aim is actually to popularise computer chess in our country, making it much more visible than today among chess players. See it as "a hobby within a hobby"

Do you mean you want to have a browser-based solution, so that people do not need to download any client software to connect, and can just click the link? The problem with that the user will constantly have to poll if the page is refreshed. This is what the ChessLive! viewer does automatically through the JavaScropt program in it, but it is technically a quite poor solution. TLCV works much better in that respect, by inverting the client-server relationship, and let TLCV just sit and wait until it is approached by TLCS with a new move. But of course that gives lots of problems with firewalls, port mapping etc. at the client side.

Actually one idea some month ago was to use a custom ICS to play our (OTB) tournaments, to have an automatic relay mechanism, but that was not suitable for classic OTB tournaments (I mean those with pushing wood involved ), and was perhaps a little bit overshooting

I am not sure what would be the problem with that, Surely WinBoard would not fare any better than an ICS in wood-pushing tourneys.

Yes, I know that: indeed with some small modifications the program I wrote is able to do that, too. But actually winboard.debug is a big file, while the file produced by /serverMoves is much smaller, so it is lighter to parse.
I must say also that last time I tried to use winboard.debug - while in the source I can see it is updated move by move (actually "event by event" as every thing is logged) - from the outside it looked like as if there was quite some delay in the update (at least on my system): is this possibly caused by normal OS buffering and such?

Hmm, this is strange. I thought the buffer size of the debug file was set to zero, to force immediate flushing of anything that was written. I don't do this any differently from the /serverMoves file, btw.

One thing I wished would be available on every system (and not just Unix-like ones) is the named pipe mechanism: that would pretty much simplify a lot of things...

Well, Windows has named pipes, isn't it? I never used one, but in my Windows engines I always use a Windows API call 'PeekNamedPipe' to probe the (unnamed) pipe to WinBoard to see if there is input, so that I have to abort pondering.