Tinkering with Winboard

[Guenther Simon]

Hi Alessandro,

Except the mentioned bug with setting up time in seconds
all new changes seem to work. Thanks!
I have a question though concerning the PGN standard.
Is there yet a way to set up different time controls properly
in a PGN at all? I believe currently the White time is written
in the PGN header, right?

Best,
Guenther

[Alessandro Scotti]

Is there yet a way to set up different time controls properly in a PGN at all? I believe currently the White time is written in the PGN header, right?

Hi Guenter,
there is something about time controls in section 9.6.1 of the PGN standard (quoted below). It seems there is no way to setup (or better, "describe") separate controls for black and white.

9.6: Time control

The follwing tag is used to help describe the time control used with the game.


9.6.1: Tag: TimeControl

This uses a list of one or more time control fields. Each field contains a
descriptor for each time control period; if more than one descriptor is present
then they are separated by the colon character (":"). The descriptors appear
in the order in which they are used in the game. The last field appearing is
considered to be implicitly repeated for further control periods as needed.

There are six kinds of TimeControl fields.

The first kind is a single question mark ("?") which means that the time
control mode is unknown. When used, it is usually the only descriptor present.

The second kind is a single hyphen ("-") which means that there was no time
control mode in use. When used, it is usually the only descriptor present.

The third Time control field kind is formed as two positive integers separated
by a solidus ("/") character. The first integer is the number of moves in the
period and the second is the number of seconds in the period. Thus, a time
control period of 40 moves in 2 1/2 hours would be represented as "40/9000".

The fourth TimeControl field kind is used for a "sudden death" control period.
It should only be used for the last descriptor in a TimeControl tag value. It
is sometimes the only descriptor present. The format consists of a single
integer that gives the number of seconds in the period. Thus, a blitz game
would be represented with a TimeControl tag value of "300".

The fifth TimeControl field kind is used for an "incremental" control period.
It should only be used for the last descriptor in a TimeControl tag value and
is usually the only descriptor in the value. The format consists of two
positive integers separated by a plus sign ("+") character. The first integer
gives the minimum number of seconds allocated for the period and the second
integer gives the number of extra seconds added after each move is made. So,
an incremental time control of 90 minutes plus one extra minute per move would
be given by "4500+60" in the TimeControl tag value.

The sixth TimeControl field kind is used for a "sandclock" or "hourglass"
control period. It should only be used for the last descriptor in a
TimeControl tag value and is usually the only descriptor in the value. The
format consists of an asterisk ("*") immediately followed by a positive
integer. The integer gives the total number of seconds in the sandclock
period. The time control is implemented as if a sandclock were set at the
start of the period with an equal amount of sand in each of the two chambers
and the players invert the sandclock after each move with a time forfeit
indicated by an empty upper chamber. Electronic implementation of a physical
sandclock may be used. An example sandclock specification for a common three
minute egg timer sandclock would have a tag value of "*180".

[Alessandro Scotti]

Hi all,
I've should have fixed the time control bug so there's a new version to download from the usual place. Also, I've fixed several buffer overflows that occurred when displaying very long PV's... there surely are many left in the code, but at least now the crashes that Leo was experiencing should be fixed.

[Greg Simpson]

Thanks Alessandro, it's working fine now.

Perhaps you should have mentioned the asymmetric time controls in your readme, for those who haven't followed this thread.

I would prefer that the time controls in a tournament (/mg N) stayed with the player, instead of the color. That is, that the black and white time controls be swapped after each game in a tournament. I can work around this though, if you don't think it's worthwhile.

[Alessandro Scotti]

Thanks Alessandro, it's working fine now.

Perhaps you should have mentioned the asymmetric time controls in your readme, for those who haven't followed this thread.

I would prefer that the time controls in a tournament (/mg N) stayed with the player, instead of the color. That is, that the black and white time controls be swapped after each game in a tournament. I can work around this though, if you don't think it's worthwhile.

Hi Greg,
I have updated the readme now (and converted it to HTML). You are right that time controls should follow the player, that's what I would like to implement too but I haven't yet found a good way to attach the info to a player...

[Tim Mann]

[quote="Volker Pittlik"]
However, it seems someone at CCC (Michael Yee?) declared that he is willing to do some coordination. As some programmers wrote they are willing to improve Winboard some kind of coordination seems to be important IMO.
[/quote]

Folks who are interested in working on WinBoard, especially if they are willing to cooperate and coordinate their efforts, really should join the xboard/winboard Savannah project at https://savannah.gnu.org/projects/xboard.

Right now the Savannah project is pretty stagnant, but it seems to me that it would be better for folks who want to work on the software to join it and breathe some life into it instead of forming a separate group.

[milix]

Hi Alessandro,
I can confirm that so far there is no problem with the variable initialization issue when I use winboard_x. I think Leo can confirm this also. But I have a font rendering problem. White pawns and white knights are drawn opaque.

Folks who are interested in working on WinBoard, especially if they are willing to cooperate and coordinate their efforts, really should join the xboard/winboard Savannah project at https://savannah.gnu.org/projects/xboard.

There is a problem with this link. I get

Code: Select all

Invalid group: that group does not exist

I think that the problem with joining the xboard project is that these changes will take some time to take effect since there must be a new release (4.2.8?). I made a fix in winboard and I posted the fix here and in Leo's site and I have no problem if someone of the programmers in the xboard group use this fix (Alessandro fixed this bug also in a better way IMHO). The fixes and user requests that Alessandro made released in nearly no-time and now they can be used. This is flexibility.

The truth is that Winboard has the momentum right now. So lets hope that a new and better release will come out soon!

BTW, thanks Tim!

[Rémi Coulom]

Folks who are interested in working on WinBoard, especially if they are willing to cooperate and coordinate their efforts, really should join the xboard/winboard Savannah project at https://savannah.gnu.org/projects/xboard.

There is a problem with this link. I get

Code: Select all

Invalid group: that group does not exist

Remove the dot:
https://savannah.gnu.org/projects/xboard

[Guenther Simon]

Hi Alessandro,

I don't know if you still have time for some tinkering?
A little accident with an undesired overwriting of a WB debug file
remembered me, that I always wished I could specify a different
name for the debug file, when running matches directly in WB.
It would be fine, if I could write e.g. /debug XYZ /mg N or similar
to get a debug file named XYZ.debug. Similar solutions would be
fine too of course.

Best regards,
Guenther

[Alessandro Scotti]

Hi Guenther,
I have uploaded a new version at:

http://www.ascotti.org/programming/chess/zip/winboard_x.zip

For this version, Leo reported some problems that I have not investigated yet but it seemed to work ok in the (few) tests I have run. New parameters are:
- delayBeforeQuit (just ignore it, but it will appear in the .ini file);
- delayAfterQuit (delay in milliseconds between sending a "quit" command and closing an engine);
- nameOfDebugFile or debugfile to specify the name of a debug file.

Let me know how it works. When the major issues and bugs have been fixed, I would like to build a "release" version of the program, which will be smaller in size, and faster (all executables of mine so far have been "debug" builds).

[Roger Brown]

Hello Alessandro Scotti,

THANKS.

Very much.

Your work is appreciated....and not just by the famous TD folk either!

I can hardly wait for your release version.

Thanks again.

Later.

[Thomas Mayer]

Hi Alessandro,

because I made epd2wb in just some hours compatible to UCI I thought that it might be interesting to make winboard also compatible to UCI engines. Because your winboard-improvement-approach seems to me the one the most advanced I would like to work on your source as starting point. What do you think ?

Greets, Thomas

[Alessandro Scotti]

Hi Alessandro,

because I made epd2wb in just some hours compatible to UCI I thought that it might be interesting to make winboard also compatible to UCI engines. Because your winboard-improvement-approach seems to me the one the most advanced I would like to work on your source as starting point. What do you think ?

Greets, Thomas

Hi Thomas,
I'm very interested in UCI, as I would like to add it to Kiwi too (because it's the native protocol of Sigma chess for Mac). Unfortunately I don't know a thing about that protocol, but I will be very happy to help or assist you in anything you may need with the Winboard code. I think having UCI in Winboard will be just GREAT!

[Anonymous]

because I made epd2wb in just some hours compatible to UCI I thought that it might be interesting to make winboard also compatible to UCI engines. Because your winboard-improvement-approach seems to me the one the most advanced I would like to work on your source as starting point. What do you think ?

That would be great, but I fear, it would not be easy. The main problem may not be the protocol, but the engine settings. One has to create all those dialogs at run time. Take care of the size (some engines may chose to have many and long options), ... Looks like a not too easy project.

I guess in epd2wb, you can just ignore all those settings and only use hash and TB path.

How is Polyglot handling this?

Regards,
Dieter

[Anonymous]

Another wish for WB would be - make the ini file synthax easier. I never understood, why I had to put in the same stuff twice - once for white and once for black. Make the working directory default to the path to the engine. So ideally, one line in winboard.ini should be enough to add an engine in general. And of course, adding an engine through the GUI would be even nicer.

Regards,
Dieter

[Thomas Mayer]

Hi Dieter,

because I made epd2wb in just some hours compatible to UCI I thought that it might be interesting to make winboard also compatible to UCI engines. Because your winboard-improvement-approach seems to me the one the most advanced I would like to work on your source as starting point. What do you think ?

That would be great, but I fear, it would not be easy. The main problem may not be the protocol, but the engine settings. One has to create all those dialogs at run time. Take care of the size (some engines may chose to have many and long options), ... Looks like a not too easy project.

I guess in epd2wb, you can just ignore all those settings and only use hash and TB path.

well, I know that some problems might occur. First I tell you how the new epd2wb is doing it.
Initially you can define a textfile where you set some standard options (or everything you want to set) -> after that it parses through the options the engine offers. If one was not defined in the initial textfile it will later just set it with the default value, else it will set what was defined in the textfile. If an option is not supported by the engine but defined in the textfile it will not be sent to the engine, of course.
Current limitations: only up to 100 options are supported. And not more then 255 chars per option (without value, value can also be 255 char long) are supported.
Well, the solution for the 100 limit is easy, I will use a list instead of a fixed array.
So don't await too much, there won't be a nice window where you can define the options. Instead for the engine you can define something like that:

"Shredder9" /fd=c:\chess\shredder9 /firstProtocolVersion U /ucioptions uci.txt

That's how I think currently I will try to implement it. Seems doable for me...

Some might be upset a bit now, but the goal is at first to get them to play in winboard, later some might think about the user interface. (Maybe Alessandro can help here)

Greets, Thomas

[Alessandro Scotti]

I think the protocol part would be the most difficult. In Winboard, this code is not concentrated in a single place, but rather sparsed across many functions, which will complicate things a lot.
On the other hand I wouldn't worry too much about the GUI code. Using Delphi, even the most sophisticated GUI's can be programmed in very little time and I can take care of that when it's needed.

[Daniel Mehrmann]

Hi Alessandro,

because I made epd2wb in just some hours compatible to UCI I thought that it might be interesting to make winboard also compatible to UCI engines. Because your winboard-improvement-approach seems to me the one the most advanced I would like to work on your source as starting point. What do you think ?

Greets, Thomas

Nice idea Thomas ! Well, i have my core uci code already finished, but need some test time that i don't have at the moment. I'm more busy with homer and chess960 as well as debuging stuff.


But i could send a binary or the source version of my current winboard. Its still not loaded up to our cvs server.

greetings
daniel

[Anonymous]

I think the protocol part would be the most difficult. In Winboard, this code is not concentrated in a single place, but rather sparsed across many functions, which will complicate things a lot.
On the other hand I wouldn't worry too much about the GUI code. Using Delphi, even the most sophisticated GUI's can be programmed in very little time and I can take care of that when it's needed.

Alessandro, I am a bit confused, now. AFAIK Winboard/Xboard GUIs are written in C. Do you intend to add GUI stuff in Delphi? Is this easily possible? Will it work under Linux, other Unices, Freebsd, Mac?

Regards,
Dieter

[Dann Corbit]

The Linux version of Delphi is called Kylix
http://www.borland.com/products/downloa ... kylix.html

Won't work on a Mac as far as I know.