WinBoard + xboard 4.3.14 released (finally)!

[bob]

One question. You had, at one point, mentioned that this was going to be both winboard/xboard. Have you tested the xboard stuff on any different platforms to confirm library compatibilities and such? Does it require any odd packages? Sometimes installing a new X program turns into an enormous snowball effect that leads to digging up dozens of packages...

[bnemias]

I built it from source after having used the --with-Xaw3d switch in configure.

It seemed to work using this test command:

Code: Select all

./xboard -size middling -variant xiangqui

[After I realized it needed the Fairy-Max subdir, heh.]

[hgm]

Perhaps Zach Wegner should answer this question, as he is the one that did most work on the xboard.c file (on a BSD Unix system). Until last week I did not even have a Linux installed on any of my computers.

Especially for the purpose, though, I did install an Ubuntu ("hardy" distribution) in a virtual machine (VirtualBox) on my laptop, and I can confirm that I could configure and make xboard there. The packages I needed was x-windows (X11), which seems to be standard, but not in the directory where the xboard 'configure' could find it. (So I had to use the options --x-includes=... and --x-libraries=... on it.) In addition it needed the Athena widgets package (Xaw), which I obtained as libxaw7-dev (IIRC). I think these are exactly the same packages as that xboard 4.2.7 needed.

Note that the xboard we produced does none of the fancy graphics shown in the WinBoard screenshots (Yet...). The only way you would note anything different in its appearance is when you use the '-variant' command-line option to select one of the newly supported variants with unorthodox board formats or pieces, or with crazyhouse-type holdings.

Otherwise the accompanying xboard will look unremarkable. But as it shares the back-end code with WinBoard, it is fully castling and -e.p. aware, can do the mate detection / RESULT-claim verification, and draw adjudications (50-move, rep-draws, insuff-material, trivial draws), all under control of command-line options. It also has the improved PGN features (score/depth in PGN comments) and time-control options.

To know exactly what should work and what not, take a look at this list, which marks all (new) options that also do work with xboard with an 'x'.

Note that this xboard is a hardly tested beta version. I certainly did not do any testing on it myself, other than confirming that I could play against Faity-Max with white and black, and could make it play an engine-engine game.

So the only screenshot that can show this xboard is really different, is one from a variant. If you type

./xboard -variant xiangqi -size middling -ncp

you get this:



If you actually wanted to play, you would have to type something like

./xboard -variant xiangqi -size middling -fcp ./Hoixiangqi -fd ./HoiChess

[Zach Wegner]

One question. You had, at one point, mentioned that this was going to be both winboard/xboard. Have you tested the xboard stuff on any different platforms to confirm library compatibilities and such? Does it require any odd packages? Sometimes installing a new X program turns into an enormous snowball effect that leads to digging up dozens of packages...

As the other Bob and H.G. say, it is generally easy. I had to add some code to the makefile for it to find libXaw. I also had to change the name there to libXaw8 (I don't know why...) This isn't installed by default on my machine, but it was added as a dependency in /usr/pkg/lib when I installed xboard from the package system. Xboard was looking for it in /usr/X11R6/lib, so I added this:

LDFLAGS = -Wl,-R/usr/pkg/lib
LIBS = -L/usr/pkg/lib -lXaw8 -lXmu -lXt -lXext \
-lXpm -lSM -lICE -lX11 -lm

But this is probably better to handle with symbolic links...?

I will note that the screenshots I posted were made with KDE with the settings configured to look sort of like a mix between pre-X Mac OS and Windows.

[bob]

Perhaps Zach Wegner should answer this question, as he is the one that did most work on the xboard.c file (on a BSD Unix system). Until last week I did not even have a Linux installed on any of my computers.

Especially for the purpose, though, I did install an Ubuntu ("hardy" distribution) in a virtual machine (VirtualBox) on my laptop, and I can confirm that I could configure and make xboard there. The packages I needed was x-windows (X11), which seems to be standard, but not in the directory where the xboard 'configure' could find it. (So I had to use the options --x-includes=... and --x-libraries=... on it.) In addition it needed the Athena widgets package (Xaw), which I obtained as libxaw7-dev (IIRC). I think these are exactly the same packages as that xboard 4.2.7 needed.

Note that the xboard we produced does none of the fancy graphics shown in the WinBoard screenshots (Yet...). The only way you would note anything different in its appearance is when you use the '-variant' command-line option to select one of the newly supported variants with unorthodox board formats or pieces, or with crazyhouse-type holdings.

Otherwise the accompanying xboard will look unremarkable. But as it shares the back-end code with WinBoard, it is fully castling and -e.p. aware, can do the mate detection / RESULT-claim verification, and draw adjudications (50-move, rep-draws, insuff-material, trivial draws), all under control of command-line options. It also has the improved PGN features (score/depth in PGN comments) and time-control options.

To know exactly what should work and what not, take a look at this list, which marks all (new) options that also do work with xboard with an 'x'.

Note that this xboard is a hardly tested beta version. I certainly did not do any testing on it myself, other than confirming that I could play against Faity-Max with white and black, and could make it play an engine-engine game.

So the only screenshot that can show this xboard is really different, is one from a variant. If you type

./xboard -variant xiangqi -size middling -ncp

you get this:



If you actually wanted to play, you would have to type something like

./xboard -variant xiangqi -size middling -fcp ./Hoixiangqi -fd ./HoiChess

Once I get past the current checks in q-search coding and start a cluster test run, I will try to play with this. I had an issue with a couple of the last versions Tim wrote that had some sort of deadlock issue I could not find. It appeared to be related to the done=x stuff, but I lost some games on ICC when the next game would sort of start but crafty was not running. I hated to look at xboard code to try to track that stuff down, it was sort of a hack on a hack on a hack since so many had contributed (myself included) which made it hard to follow at times.

Hopefully this won't croak, which will be a plus.

The separate windows for game history, etc did look nice however. Would be nice to have in linux.

[hgm]

I built it from source after having used the --with-Xaw3d switch in configure.

It seemed to work using this test command:

Code: Select all

./xboard -size middling -variant xiangqui

[After I realized it needed the Fairy-Max subdir, heh.]

Note you made a typo there (xiangqui): let it not confuse other people.

Indeed I defined "./Fairy-Max", rather than "." as defaults for the -fd and -sd options. It seemed to make no sense to me to put all engines in the same directory as xboard (similar to what was done with GNUChess in the 4.2.7 distribution), as many engines need support files in their home directory, which often have the same name for different engines ("Book", etc.). So I assumed there would be a subdirectory for each engine in the xboard home directory. The distribution includes the Fairy-Max subdirectory in its directory tree.

You can of course install other engines simply in the xboard directory (as long as you get no filename collissions), but to run them the options "-fd ." (and possibly "-sd .") would be mandatory.

Fairy-Max would not mind if you installed other engines in its directory, as they are not likely to use a file called fmax.ini. (You would likely overwrite the readme file, though...) But I highly recommend to install all engines in their own directory, and pass this directory name with the -fd and -sd option to xboard when you run it.

I know this is a pain; but the ultimate solution to this pain is the use of a tournament manager. I don't know if there are tournament managers that run under Linux with xboard. I tried to compile PSWBTM (which is available in source) with the aid of Pradu on my Ubuntu, but we could not do it, as it requires non-existent, non-obtainable llinker libraries. I also tried to run a version he compiled for me, but that doesn't work either, as it requires non-existent, non-obtainable shared object libraries. If anyone can help me to a PSWBTM Linux executable that is self-sufficient enough to run on my Ubuntu, it would make me ecstatic. It probably would not work with this xboard (as Pradu notes on his website), but if I could run it, I could at least diagnose the problem, and fix it on the xboard side.

[hgm]

... I had an issue with a couple of the last versions Tim wrote that had some sort of deadlock issue I could not find. It appeared to be related to the done=x stuff, but I lost some games on ICC when the next game would sort of start but crafty was not running. I hated to look at xboard code to try to track that stuff down, it was sort of a hack on a hack on a hack since so many had contributed (myself included) which made it hard to follow at times.

I agree. Especially the ICS code is awful. I am not sure if you can expect any improvements from this version, though; I did only touch the ICS code on the issue of switching between variants, and to properly extract castling rights from what the ICS sends in FRC (wild22).

I do know that after any feature command that does not end in done=0 or done=1 there is a time-out event scheduled to wait and see if more feature commands are coming, before continuing with the remaining xboard initialization. Perhaps there is a race condition there, when a new feature comes in at the same time as the time-out expired. It should not happen if every feature command ends with a done=N.

Note that the handshaking on the features only happens at xboard startup. If you start a new game on an xboard that is already running, there is only a 'new' command to the engine. Problems here (e.g. engine still searching on a move of the previous game, while the opponent already resigned and tries to start a new one) should be solved by 'ping', though.

Hopefully this won't croak, which will be a plus.

The separate windows for game history, etc did look nice however. Would be nice to have in linux.

Indeed, and it is high on our list of priorities. But that list is rather crowded at the top, unfortuately. Making all new options available through menus will probably get priority. This requires a nasty unmingling of code, to make it possible to change board size and format during a run, in stead of fixing it once and for all at startup.

[mathmoi]

Great works!

I can't wait for the changes to be ported to xboard

[swami]

Older version of winboard didn't seem user friendly, is the newer ones made by H.G user friendly? Ofcourse Thanks H.G for all the work you have done, you seem to be enthusiastic on developing softwares, although I wish you'd develop chess GUI features in Winboard more than variants section.

[hgm]

WinBoard is part of a modular software package, and it is the part responsible for conducting and displaying an ongoing game between two engines. It is not meant to be an engine manager for maintaining a database of engines, or a tournament manager. So if you try to use it for that purpose, you might experience it as user unfriendly.

With PSWBTM, which is both engine manager and tournament manager, I I have never experienced any user-unfriendliness. To run a tournament, you just double-click all the engines from the list of available engines, set the time control and number of games per pairing (if these are different from your previous tourney), press "resume" and you are running.