TLCS and Winboard

[Guenther]

Inspired from the other thread about ChessGui and TLCS I did a retest
under WB after at least 7 or more years.
I guess most here don't know that I was the first one to broadcast chess
games directly that way (before Leo and Olivier and various others coming later...).

At that time I used exclusively PSWBTM together with WB.
There were no tournament functions etc. in WB at that time.

Well now I run into various problems. Some in WB some in TLCS or unknown.

First of all, you need to specify the debugfile in TLCS and as always I liked
to have debugs numbered according to the games (which PSWBTM did automatically).
There is a command for this now e.g. -debug -debugfile %d.deb.
I noticed that there is a problem now for TLCS how it is done.
PSWBTM only changed the name of the debugfile after a game was
finished. WB renames the file now already in the beginning of a game.
Thus a certain file cannot be specified for TLCS.

The next problem is that despite what was said in the other thread I also
get move errors immediately in TLCS when the game starts with start positions
from a pgn file. I thought this only happens when using EPD or FEN?
It still works as before with own books. Haven't tried GUI books yet.

Third problem independent from WB is mailing. Nowadays SSL/TLS
connctions are used by mailservers. In the past I used the mail server
from my regular providers mail address. I gave the changed mailserver,
but I always get error 530 now in the log from TLCS even with a more
recent gbmail(er) version from sourceforge. (2010 vs. 1999)

Code: Select all

gbmail -to  rwbc@gmx.de -file email.txt -h securesmtp.t-online.de -from XXX@t-online.de -s Your_requested_game(s).
GBMailer: SMTP error: 530

Any idea? At least I can try one of my free mailservices. According to
Grahams ini file it seems to work for him with gmail?

Guenther

[hgm]

Unfortunately some of that isn't so easy to solve. E.g. renaming the debug file afterwards. The WinBoard TM function is designed for concurrent play, and if two WB instances would run simultaneously, they would remove each other's debug file. When it writes directly on a %d-containing file you don't have that problem. But then TLCS cannot find them, as you point out.

I am not sure why starting from opening lines would not work anymore. Probably there is some debug output that WinBoard prints nowadays, which interferes with the way TLCS extracts the moves from it. Normally a broadcaster should limit itself to lines marked as communication with the engine (through >first: and similar prefixes), and ignore all other lines. But apparently TLCS doesn't. The format of the debug file was never formally specified, or subject to any standards.

I wonder, however, how useful it is to put effort in reviving TLCS. It is not only that it requires a dedicated client to watch the broadcasts, but it has always been very hard for people to actually get that client running. It requires port translations and such, and many people never managed. I see much more future for browser-based broadcasting, and perhaps we should focus efforts on that.

WinBoard 4.9 has an undocumented feature, where a -debugfile starting with 3 slashes would not be taken as a real file, but in stead as the name of a command to which the text normally written in the debug file would be piped. The idea was that you could then use an external broadcaster program for this, (i.e. the TLCS replacement), which would be reading from the pipe, and dig out the text lines it is interested in. The difference between reading from a pipe and from a file is that on the pipe the reader would automatically wait when it gets to the end of the available info until new info arrives (and then reads that), while on a file you immediately get an end-of-file response, and would have to wait and retry somewhat later. So the pipe is conceptually simpler and more efficient, as it would eliminate unsuccessful polling to see if new text was already added.

Unfortunately this makes the problem for those who want to save the debug file even bigger, as there wouldn't be such a file at all anymore, and all debug output is directly eaten by the broadcaster. This could be solved by having the broadcaster program not only broadcast the info, but also save it. (This means the saving location would now have to be configured in the broadcaster, though. And when it should have a game-dependent name, some method should be available to recognize that name from the debug output.)

November last year I already did some work on creating such a broadcaster program, for broadcasting my own engine's games in the UEC Cup, but when it became clear I could not finish the entire setup in time I lost interest. That broadcaster used an URL GET method to deposit the info to be broadcasted on an external server. The server-side CGI 'script' used to power my turn-based game server would already accept moves in that format, for adding them to a game in progress. And I just equiped it with a 'super-user' feature that would allow some users (in particular the broadcaster) to deposit moves for both players of a game. People could then watch the games through the same interface that would normally show them the games on that turn-based server.

People would connect to the turn-based server using their web browser as client (viewing a HTML page powered by JavaScript, similar to http://hgm.nubati.net/variants/werewolf ). I did not have a chat function in that page yet, however. And chatting is more than half the fun on such events. It shouldnot be too difficult to add that, however. (Like in http://hgm.nubati.net/WCCC/game1/chess.html .)

I suspect that it would be much more productive to continue developing a system like that, than to put effort in TLCS.

[Guenther]

Unfortunately some of that isn't so easy to solve. E.g. renaming the debug file afterwards. The WinBoard TM function is designed for concurrent play, and if two WB instances would run simultaneously, they would remove each other's debug file. When it writes directly on a %d-containing file you don't have that problem. But then TLCS cannot find them, as you point out.

I am not sure why starting from opening lines would not work anymore. Probably there is some debug output that WinBoard prints nowadays, which interferes with the way TLCS extracts the moves from it. Normally a broadcaster should limit itself to lines marked as communication with the engine (through >first: and similar prefixes), and ignore all other lines. But apparently TLCS doesn't. The format of the debug file was never formally specified, or subject to any standards.

I wonder, however, how useful it is to put effort in reviving TLCS. It is not only that it requires a dedicated client to watch the broadcasts, but it has always been very hard for people to actually get that client running. It requires port translations and such, and many people never managed. I see much more future for browser-based broadcasting, and perhaps we should focus efforts on that.

WinBoard 4.9 has an undocumented feature, where a -debugfile starting with 3 slashes would not be taken as a real file, but in stead as the name of a command to which the text normally written in the debug file would be piped. The idea was that you could then use an external broadcaster program for this, (i.e. the TLCS replacement), which would be reading from the pipe, and dig out the text lines it is interested in. The difference between reading from a pipe and from a file is that on the pipe the reader would automatically wait when it gets to the end of the available info until new info arrives (and then reads that), while on a file you immediately get an end-of-file response, and would have to wait and retry somewhat later. So the pipe is conceptually simpler and more efficient, as it would eliminate unsuccessful polling to see if new text was already added.

Unfortunately this makes the problem for those who want to save the debug file even bigger, as there wouldn't be such a file at all anymore, and all debug output is directly eaten by the broadcaster. This could be solved by having the broadcaster program not only broadcast the info, but also save it. (This means the saving location would now have to be configured in the broadcaster, though. And when it should have a game-dependent name, some method should be available to recognize that name from the debug output.)

November last year I already did some work on creating such a broadcaster program, for broadcasting my own engine's games in the UEC Cup, but when it became clear I could not finish the entire setup in time I lost interest. That broadcaster used an URL GET method to deposit the info to be broadcasted on an external server. The server-side CGI 'script' used to power my turn-based game server would already accept moves in that format, for adding them to a game in progress. And I just equiped it with a 'super-user' feature that would allow some users (in particular the broadcaster) to deposit moves for both players of a game. People could then watch the games through the same interface that would normally show them the games on that turn-based server.

People would connect to the turn-based server using their web browser as client (viewing a HTML page powered by JavaScript, similar to http://hgm.nubati.net/variants/werewolf ). I did not have a chat function in that page yet, however. And chatting is more than half the fun on such events. It shouldnot be too difficult to add that, however. (Like in http://hgm.nubati.net/WCCC/game1/chess.html .)

I suspect that it would be much more productive to continue developing a system like that, than to put effort in TLCS.

I mostly agree with all that. It's really better to adapt to sth which is still
in development or sufficiently works already even when not under development.

[Rebel]

I am not sure why starting from opening lines would not work anymore. Probably there is some debug output that WinBoard prints nowadays, which interferes with the way TLCS extracts the moves from it.

Doesn't work with Arena as well hence I started a web-based live viewer. If ChessGui also doesn't support it then the origin likely would be TLCS.

[Graham Banks]

Grahams ini file it seems to work for him with gmail?

Guenther

Hi Guenther,

it depends on whether your internet provider allows emails to go through them. My previous one did, but my current one doesn't.
Therefore 'email game' doesn't work for me at present.

[Guenther]

Grahams ini file it seems to work for him with gmail?

Guenther

Hi Guenther,

it depends on whether your internet provider allows emails to go through them. My previous one did, but my current one doesn't.
Therefore 'email game' doesn't work for me at present.

After some googling it seems gbmail uses a default TCP/IP port of '25', which was the standard mail port in the past.
Now this has changed with SSL/TLS, e.g, my providers mail server must be configured for '465'.
Unfortunately we cannot give the commandline parameter -p (port) which exists for gbmail via TLCS.
Probably it must be recompiled with the exact port number to work with TLCS.

OTH it is no big problem anyway, there are other ways to get the games.
I just don't like it if something does not work as it should ;-)

[Krzysztof Grzelak]

Unfortunately, as I was not able to send any e-mail. Thank you for any advice and assistance.

[Guenther]

Unfortunately some of that isn't so easy to solve. E.g. renaming the debug file afterwards. The WinBoard TM function is designed for concurrent play, and if two WB instances would run simultaneously, they would remove each other's debug file. When it writes directly on a %d-containing file you don't have that problem. But then TLCS cannot find them, as you point out.

I am not sure why starting from opening lines would not work anymore. Probably there is some debug output that WinBoard prints nowadays, which interferes with the way TLCS extracts the moves from it. Normally a broadcaster should limit itself to lines marked as communication with the engine (through >first: and similar prefixes), and ignore all other lines. But apparently TLCS doesn't. The format of the debug file was never formally specified, or subject to any standards.

I wonder, however, how useful it is to put effort in reviving TLCS. It is not only that it requires a dedicated client to watch the broadcasts, but it has always been very hard for people to actually get that client running. It requires port translations and such, and many people never managed. I see much more future for browser-based broadcasting, and perhaps we should focus efforts on that.

WinBoard 4.9 has an undocumented feature, where a -debugfile starting with 3 slashes would not be taken as a real file, but in stead as the name of a command to which the text normally written in the debug file would be piped. The idea was that you could then use an external broadcaster program for this, (i.e. the TLCS replacement), which would be reading from the pipe, and dig out the text lines it is interested in. The difference between reading from a pipe and from a file is that on the pipe the reader would automatically wait when it gets to the end of the available info until new info arrives (and then reads that), while on a file you immediately get an end-of-file response, and would have to wait and retry somewhat later. So the pipe is conceptually simpler and more efficient, as it would eliminate unsuccessful polling to see if new text was already added.

Unfortunately this makes the problem for those who want to save the debug file even bigger, as there wouldn't be such a file at all anymore, and all debug output is directly eaten by the broadcaster. This could be solved by having the broadcaster program not only broadcast the info, but also save it. (This means the saving location would now have to be configured in the broadcaster, though. And when it should have a game-dependent name, some method should be available to recognize that name from the debug output.)

November last year I already did some work on creating such a broadcaster program, for broadcasting my own engine's games in the UEC Cup, but when it became clear I could not finish the entire setup in time I lost interest. That broadcaster used an URL GET method to deposit the info to be broadcasted on an external server. The server-side CGI 'script' used to power my turn-based game server would already accept moves in that format, for adding them to a game in progress. And I just equiped it with a 'super-user' feature that would allow some users (in particular the broadcaster) to deposit moves for both players of a game. People could then watch the games through the same interface that would normally show them the games on that turn-based server.

People would connect to the turn-based server using their web browser as client (viewing a HTML page powered by JavaScript, similar to http://hgm.nubati.net/variants/werewolf ). I did not have a chat function in that page yet, however. And chatting is more than half the fun on such events. It shouldnot be too difficult to add that, however. (Like in http://hgm.nubati.net/WCCC/game1/chess.html .)

I suspect that it would be much more productive to continue developing a system like that, than to put effort in TLCS.

Oops I found an old thread in the WB forum from 2012 when we already
had some exchange about some of this:

http://www.open-aurec.com/wbforum/viewt ... =2&t=52172

One of the most interesting/relevant posts from this thread:

Re: Winboard questions

Postby H.G.Muller » 22 Feb 2012, 16:57
I uploaded a new trial version ( http://hgm.nubati.net/WinBoard-4.5TM.exe ). I equiped it with an extra option -serverFile where you can specify a sort of extra debug file (with a fixed name) that only logs engine communication. Except that at the start it fakes two StartChildProcess lines, so that you can see which engines were playing.

I hope that this will be enough for TLCS to work from. The file will be created for overwrite each time a nw tourney game starts.

Does this still work?

Guenther

[hgm]

I had completely forgotten about this. But the code is still in WinBoard, so I suppose it should still work if it ever worked. It was actually a pretty large patch, because I had to add extra print statements in all places were something was printed to the debug file that could also be of interest to TLCS, to also print it to this -serverFile.

[Guenther]

I had completely forgotten about this. But the code is still in WinBoard, so I suppose it should still work if it ever worked. It was actually a pretty large patch, because I had to add extra print statements in all places were something was printed to the debug file that could also be of interest to TLCS, to also print it to this -serverFile.

I tested it out of interest. The argument -serverFile is accepted or at least not rejected in 4.80, but no file is written (same in the original 4.50TM).