winboard debug file

[Fermin Serrano]

Winboard debug file logs everything, even internal variables.
Is there any way to tell winboard only to write in the debug file the log of comunication with engine, I mean, only to write >first, <first, >second and <second lines.....?
That will allow winboard to play better very fast games and also it will ocupy less space.... when I only want to catch bugs of my engine, not winboard

thanks.

[Leo Dijksman]

Hi Fermin,

I agree with you, the debugfiles are junk!

For example, before the engines are starting you get:

Code: Select all

recognized 'normal' (-1) as variant normal
recognized 'normal' (-1) as variant normal
WinBoard 4.5.2a + ChadsChess015
Reset(1, 0) from gameMode 0
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
shuffleOpenings = 0
TC string = ':40/300'
mps=40 tc=300000 inc=0
TC string = ':40/300'
mps=40 tc=300000 inc=0

That is:
3x "recognized 'normal' (-1) as variant normal"
2x "TC string = ':40/300'
mps=40 tc=300000 inc=0"
And the last 2 lines repeats after each move!?
Total unnecessary IMHO, same for all the other repeated internal messages, maby they are interresting to test a beta version of WinBoard but not if one test a engine or play a tournament!

So I support your idea to have a possibillity to set it off!

Best wishes,
Leo.

[F. Bluemers]

Hi Fermin,

I agree with you, the debugfiles are junk!

For example, before the engines are starting you get:

Code: Select all

recognized 'normal' (-1) as variant normal
recognized 'normal' (-1) as variant normal
WinBoard 4.5.2a + ChadsChess015
Reset(1, 0) from gameMode 0
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
shuffleOpenings = 0
TC string = ':40/300'
mps=40 tc=300000 inc=0
TC string = ':40/300'
mps=40 tc=300000 inc=0

That is:
3x "recognized 'normal' (-1) as variant normal"
2x "TC string = ':40/300'
mps=40 tc=300000 inc=0"
And the last 2 lines repeats after each move!?
Total unnecessary IMHO, same for all the other repeated internal messages, maby they are interresting to test a beta version of WinBoard but not if one test a engine or play a tournament!

So I support your idea to have a possibillity to set it off!

Best wishes,
Leo.

Well,the debug files do what they should do.
Other than adding yet another opton to winboard (logging),
a solution would be to write a small utilitie to strip out the stuff you don't need.

[Fermin Serrano]

Hi Fermin,

I agree with you, the debugfiles are junk!

For example, before the engines are starting you get:

Code: Select all

recognized 'normal' (-1) as variant normal
recognized 'normal' (-1) as variant normal
WinBoard 4.5.2a + ChadsChess015
Reset(1, 0) from gameMode 0
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
shuffleOpenings = 0
TC string = ':40/300'
mps=40 tc=300000 inc=0
TC string = ':40/300'
mps=40 tc=300000 inc=0

That is:
3x "recognized 'normal' (-1) as variant normal"
2x "TC string = ':40/300'
mps=40 tc=300000 inc=0"
And the last 2 lines repeats after each move!?
Total unnecessary IMHO, same for all the other repeated internal messages, maby they are interresting to test a beta version of WinBoard but not if one test a engine or play a tournament!

So I support your idea to have a possibillity to set it off!

Best wishes,
Leo.

Well,the debug files do what they should do.
Other than adding yet another opton to winboard (logging),
a solution would be to write a small utilitie to strip out the stuff you don't need.

Maybe two verbose level would be reasonable. Actually, when thousand of game are played, storing debug files in disk ocupy a lot of space (for me, 200MB per tourney)

[H.G.Muller]

Well, the primary reason for the existence of the debug file is to debug WinBoard. Not to debug engines. If people run into problems, they can send us the debug file, and we should be able to deduce from them what went wrong. For this it is often important to not only see what WinBoard received from the engine, but also how it reacted to it, and not only what it sent, but also why.

I do admit that I am a bit tardy in removing messages related to features that by now should be considered fully debugged, though. Especially in versions that have been declared 'stable', most of the debug output should simply be removed.

However, I am not sure there is that much to save, in terms of space. There might be a lot of lines, but they are mostly quite short. My impression is always that the bulk of the contents is the engine thinking output. These grow to very long lines, and some engine print multiple lines per iteration (e.g. each time they overturn the best-so-far root move). When I want to step through the debug file for the purpose of seeing what an engine did, I simply search for the words 'first' or 'second'. Just deleting the lines that you don't need, like every line not containing these lines, seems a very competative option, if the storage overhead of initially writing those lines is only minor.

Why would you want to save 1000 debug files from a tournament anyway? If you were testing an engine that was faulty, you should know it already after far fewer games, I would think.

[Fermin Serrano]

Well, the primary reason for the existence of the debug file is to debug WinBoard. Not to debug engines. If people run into problems, they can send us the debug file, and we should be able to deduce from them what went wrong. For this it is often important to not only see what WinBoard received from the engine, but also how it reacted to it, and not only what it sent, but also why.

I do admit that I am a bit tardy in removing messages related to features that by now should be considered fully debugged, though. Especially in versions that have been declared 'stable', most of the debug output should simply be removed.

However, I am not sure there is that much to save, in terms of space. There might be a lot of lines, but they are mostly quite short. My impression is always that the bulk of the contents is the engine thinking output. These grow to very long lines, and some engine print multiple lines per iteration (e.g. each time they overturn the best-so-far root move). When I want to step through the debug file for the purpose of seeing what an engine did, I simply search for the words 'first' or 'second'. Just deleting the lines that you don't need, like every line not containing these lines, seems a very competative option, if the storage overhead of initially writing those lines is only minor.

Why would you want to save 1000 debug files from a tournament anyway? If you were testing an engine that was faulty, you should know it already after far fewer games, I would think.

It is OK. I said because for engine fix it is easier to look on a file which dooes not have polution from another process. I can look for a grep-type tool for windows anyway.

[H.G.Muller]

Indeed, grep would be very useful for this, and it would automatically filter out the lines of the engine you are not interested in as well, when you grep on 'first' or 'second'. I have it available under Windows because I have Cygwin installed. I don't know if there is a pure Windows tool that performs a similar function.

But it would be good to remove some of the debug prints; the new TC stuff seems to work without problems, and so are the variants. I should just run through a debug file to see which are the most commonly printed messages, and then remove or comment-out the source code responsible for those.

This must be done with care, though. I am pretty sure that I would break a lot of debug-file using tools when I would suppress everything that is not engine I/O. (Like 'GameEnds'...)

[tvt2020]

UCIPlug can capture messages between UCI engine and GUI.

[matematiko]

UCIPlug can capture messages between UCI engine and GUI.

I think "inbetween" those the same thing.

Good weekend!!!