Release of XBoard 4.9.0 soon

[hgm]

Note this has to be:

-initString "cores %\nnew\nrandom"

(The 'n' in the example you quoted was not part of the cores command, but part of the '\n' newline specified directly before it.)

You would have to write that command as 'Special WinBoard option' in the Load Engine dialog when you are installing an engine you don't want to obey the general setting for the number of CPUs specified in the Common Engine dialog, but run at a fixed number of cores. (When you already installed the engine, you can use the 'Edit Engine list' menu item to append this option to the line for that engine.)

[Werner]

Note this has to be:
-initString "cores %\nnew\nrandom"
(The 'n' in the example you quoted was not part of the cores command, but part of the '\n' newline specified directly before it.)
You would have to write that command as 'Special WinBoard option' in the Load Engine dialog when you are installing an engine you don't want to obey the general setting for the number of CPUs specified in the Common Engine dialog, but run at a fixed number of cores. (When you already installed the engine, you can use the 'Edit Engine list' menu item to append this option to the line for that engine.)

This is the line I got:
"Stockfish 1.5.1 x64 2CPU" -fcp "stockfish_151_intel_x64.exe" -fd "C:\Users\Werner\Arena\Engines\Stockfish\stockfish_151_ja" -fn "Stockfish 1.5.1 x64 2CPU" -fUCI -initString "cores 2\nnew\nrandom"

Thanks, it works here now - not with a click - with knowledge (after starting the GUI new). But when I add a memory command, both engines use only one core:
"Stockfish 1.5.1 x64 2CPU" -fcp "stockfish_151_intel_x64.exe" -fd "C:\Users\Werner\Arena\Engines\Stockfish\stockfish_151_ja" -fn "Stockfish 1.5.1 x64 2CPU" -fUCI -initString "memory 512\cores 2\nnew\nrandom"

I am learning how to use Winboard to replace other GUIs when I have problems with an engine there.

[hgm]

Thanks, it works here now - not with a click - with knowledge (after starting the GUI new).

Well, sorry about that. Core odds really seems a very outlandish application to me, and I did not build any support for that in WinBoard. Supporting too much will confuse people to the point of not being able to use it anymore. Normally people want the engines to use all cores they have available, and when they want to weaken one engine time odds (which is supported) is a better method than core odds.

But when I add a memory command, both engines use only one core:
"Stockfish 1.5.1 x64 2CPU" -fcp "stockfish_151_intel_x64.exe" -fd "C:\Users\Werner\Arena\Engines\Stockfish\stockfish_151_ja" -fn "Stockfish 1.5.1 x64 2CPU" -fUCI -initString "memory 512\cores 2\nnew\nrandom"

I am learning how to use Winboard to replace other GUIs when I have problems with an engine there.

Well, you omitted an n: '\n' is an 'escape' for a newline, but after the 512 you just wrote a backslash. Not sure how WinBoard would interpret that, but in any case it will not take a new line at that point, so 'cores' or 'ores' will be appended somewhere to the memory size, and not recognized as an individual command. The correct string would be:

-initString "memory 512\ncores 2\nnew\nrandom"

But why do you want to need a 'memory' command in there? Do you also want the two engines to play with different hash-table size?

[Werner]

Thanks,
Looks not easy
CEGT rules: 1core 256 mb, 4 or 2core 512 mb.
We seldom use different cores, e.g. an engine is very strong and needs more opponents which are not much weaker. I think a result 100 - 0 is not good for the list.
...and sorry, we tester are not normal

[hgm]

OK, I see. Yes, then you got it right, if you want to run an occasional 2CPU/512MB engine amidst a field of 1CPU/256MB engines then you can install that one engine with the mentioned -initString option as 'Special Winboard option', and let the others be controlled by the GUI-wide Hash and CPUs settings.

I admit this is not trivial, but it is only hard when you don't know how to do it yet. Once you know how to do it it is not really very much work to type that extra option when installing the engine that you want to be treated special. (And for UCI engines you could even leave out the '\nrandom' part, as UCI does not have a command to switch engine randomization on or off, so Polyglot would just ignore it.) So -initString "memory 512\ncores 2\nnew" would already do it.

I am aware that testers are a 'special breed', who often need to do things that normal users would not even think of. But because they do it so frequently, they can also be expected to learn and remember a few tricks.

[hgm]

While waiting for all translations to come in I added a new feature:

When browsing for a board texture or piece theme, XBoard will now provide instant preview of the possible choices. When you select a file in the file-chooser dialog (by single clicking it) that contains a png image, or a folder that contains pieces, XBoard will instantly adapt the board display to what it would become when you really picked that texture / piece theme. The board will revert to the originalsettings when you close the file chooser or Board dialog without selecting any new texture or pieces.

One as yet unsolved problem is that for people with small displays (or who use a small board size for other reasons) the Board dialog and File Chooser pop up such that they completely cover the board. So that you would never become aware that this feature exists (although you could easily move the dialogs away to expose the board under it).

This XBoard version can be found in my 'backup repository' at http://winboard.nl . (Due to problems with the ssh key I currently cannot push changes to the usual git repository at hgm.nubati.net.)

This whole issue also touches on the way we intend to distribute alternative board textures and piece themes for XBoard. I put together two tentative packages for this:

http://hgm.nubati.net/xb_textures.tar.gz
http://hgm.nubati.net/xb_pieces.tar.gz

These contain a Makefile that you can run after unpacking the tar balls, to move the textures and piece themes where they belong, by running

sudo make install

in the directory where they were unpacked. You can then easily navigate with the File Chooser invoked by the Browse buttons in the View->Board dialog to the places where you can select them, by clicking on 'textures' or 'themes' on the left aongst the 'Places'. The Makefile also contains an 'uninstall' target.

Packages with other themes (xb_pieces_fancy and xb_pieces_exotic) are also in preparation. I started a new branch 'themes' in the xboard source repository to contain the image files from which these packges are built.

Comments and suggestions are welcome.


XBoard with Condal pieces and Beryl-Eclipse board texture


XBoard with Freak pieces and Mayan board texture

[Canoike]

The new feature to preview the textures and pieces work well.
The ICS dialog box is far better than the console.
Now, it's time to make an official release.

[hgm]

I agree that what we have is very close to 'release quality'. (I did find and fix a bug this morning, though, where 1x1 textures like the 'Mayan' above at some sizes were scaled one pixel too small to cover the entire square, probably due to unfavorable rounding, and left white lines on their right and bottom edges.)

Anyway, Arun was traveling this week, and we have to wait for him to be back before he can make the official release. That gives us the opportunity to iron out a few more glitches. E.g. browsing for textures now usually starts at the installed textures, but when I want to try out one of my own, it is in a directory quite deep in the tree of my own files, and the closest I can get with 'Places' is in my own home directory (where I am immediately overwhelmed by a zillion of hidden directories with names starting with '.'). So it might be good to have an entry there that would direct the file chooser to the folder from where you started XBoard (the 'CHESSDIR').

[Guenther]

I agree that what we have is very close to 'release quality'.
...

Would it be possible to add a switch to PGN saving or for just displaying in the move history (if it could be copied from there) something like accumulated time?
I am asking this because it is very helpful when testing new/weak programs to show bad time management at once, especially in mps and inc games, or do you think it is too odd to add?

For now I went through some search of the forum because I noticed that my old tool (LGDEBPGN last version 1.42) did not work anymore on Win 7.
After installing the suggested DOSBOX in the thread below I could again derive an example created from a current debug file.
(BTW I was really surprised that it still could read a current debug file)

Note that this is the full one with all possible switches, but I think the time sum would be the most interesting here, also because depth and nodes are just what is reported.
One can see immediately that player A used only 99 and player B 219 seconds at least from 300 for this tc at move 40.
http://talkchess.com/forum/viewtopic.ph ... yapko+tool

Code: Select all

[Event "?"]
[Site "?"]
[Date "2016.04.18"]
[Round "1"]
[White "?"]
[Black "?"]
[Result "0-1"]
[TimeControl "40/240"]
[PlyCount "115"]
[Annotator " 8.9- 8.2"]

1. c4  c5  2. g3  Nc6  3. Bg2  g6  4. Nc3  Bg7  5. Nf3  Nf6  6. O-O  O-O  7. d3
{0.-6s} Ng4 {+0.03/6 6.14s 492.5Knps} 8. h3 {+0.13/6 1.15s 916.5Knps} Nge5
{+0.01/6 11.93s 635.2Knps} 9. Nxe5 {+0.20/6 2.57s 767.4Knps} Nxe5
{+0.00/6 17.51s 660.7Knps} 10. Be3 {+0.20/6 4.58s 831.2Knps} d6
{+0.05/5 23.50s 631.9Knps} 11. Qd2 {+0.11/6 8.90s 788.2Knps} Re8
{+0.02/5 29.18s 662.7Knps} 12. Rfb1 {+0.28/6 11.87s 699.7Knps} Rb8
{+0.04/4 36.03s 580.0Knps} 13. f4 {+0.50/5 16.87s 826.1Knps} Nd7
{+0.26/6 41.14s 676.6Knps} 14. g4 {+0.24/6 19.02s 889.0Knps} Bxc3
{+1.58/6 47.89s 665.9Knps} 15. Qxc3 {+0.64/7 24.02s 1039.5Knps} e6
{-0.14/6 48.41s 666.9Knps} 16. b4 {+0.73/6 26.18s 900.8Knps} Qc7
{-0.14/7 52.04s 771.9Knps} 17. bxc5 {+1.34/7 29.75s 1106.6Knps} dxc5
{-0.14/7 59.19s 741.4Knps} 18. d4 {+0.80/6 31.64s 752.0Knps} cxd4
{-0.14/6 66.30s 723.1Knps} 19. Qxd4 {+1.27/7 34.37s 1019.2Knps} b6
{-0.14/6 66.47s 530.1Knps} 20. f5 {+0.70/6 38.68s 413.5Knps} gxf5
{+0.79/5 73.26s 870.9Knps} 21. gxf5 {+0.96/7 40.76s 1300.3Knps} exf5
{+0.70/7 80.07s 890.8Knps} 22. Bf4 {-0.01/6 42.15s 767.9Knps} Ne5
{+0.84/6 86.79s 821.8Knps} 23. Rb3 {-0.01/6 44.05s 790.2Knps} f6
{+0.84/6 90.66s 799.7Knps} 24. Bd5+ {-0.23/6 45.72s 738.6Knps} Kh8
{+0.84/6 98.23s 769.4Knps} 25. Rg3 {-0.23/6 48.92s 782.2Knps} Qd6
{+0.84/6 104.01s 802.0Knps} 26. Rd1 {-0.37/6 52.36s 820.5Knps} Bb7
{+0.84/5 111.59s 851.2Knps} 27. Qa1 {+0.33/7 55.09s 1172.2Knps} Bxd5
{+0.89/5 118.86s 807.6Knps} 28. Rxd5 {+0.54/7 56.82s 1272.9Knps} Qc7
{+0.69/5 122.03s 893.7Knps} 29. Qb1 {-0.38/7 61.28s 1163.3Knps} Qc8
{+0.26/6 129.55s 979.7Knps} 30. Qb2 {+0.51/7 65.22s 1241.6Knps} Qc7
{+0.39/6 137.73s 1010.7Knps} 31. Qc2 {-0.38/6 70.22s 810.2Knps} Qc8
{+0.39/7 142.66s 995.8Knps} 32. Qc3 {+0.64/7 73.47s 1270.0Knps} Qc7
{+0.39/7 151.48s 1008.2Knps} 33. Qd3 {+0.30/7 76.47s 1205.7Knps} Nxd3
{+0.64/7 158.31s 1039.4Knps} 34. Bxc7 {-0.07/8 77.81s 851.1Knps} Nb4
{+0.62/7 159.60s 1127.1Knps} 35. Bxb8 {+1.69/9 84.31s 812.9Knps} Nxd5
{+0.63/8 161.81s 1280.9Knps} 36. cxd5 {+2.41/10 88.27s 1048.5Knps} Rxb8
{+0.74/10 164.55s 1196.4Knps} 37. d6 {+3.16/9 90.87s 1293.1Knps} Rd8
{+1.17/10 178.05s 1047.8Knps} 38. Rd3 {+3.25/9 92.92s 1213.8Knps} Kg8
{+1.20/9 193.03s 1103.2Knps} 39. e3 {+3.33/7 97.92s 1229.0Knps} Kf7
{+1.74/10 200.86s 1205.2Knps} 40. h4 {+1.25/7 99.40s 1208.9Knps} Ke6
{+2.05/10 219.55s 1015.6Knps} 41. h5 {-2.37/10 103.12s 1209.8Knps} Rxd6
{+2.16/9 224.83s 1069.9Knps} 42. Rxd6+ {+0.35/11 104.96s 1184.1Knps} Kxd6
{+2.16/9 224.92s 464.2Knps} 43. h6 {-0.99/11 113.03s 287.5Knps} Ke5
{+2.96/10 225.12s 1185.8Knps} 44. Kf2 {-3.84/13 114.90s 1213.5Knps} Ke4
{+3.08/11 225.38s 1264.3Knps} 45. a4 {-3.94/14 120.24s 620.1Knps} a6
{+2.95/12 225.79s 1469.4Knps} 46. Ke2 {-3.90/15 124.34s 584.6Knps} b5
{+2.43/13 226.25s 1554.1Knps} 47. axb5 {-3.98/16 129.68s 702.1Knps} axb5
{+3.11/14 226.55s 1426.3Knps} 48. Kd2 {-3.98/14 133.22s 619.4Knps} b4
{+11.25/14 227.21s 1546.7Knps} 49. Ke2 {-6.61/15 139.38s 699.4Knps} b3
{+11.73/14 228.75s 1506.3Knps} 50. Kd2 {-7.43/14 141.99s 1401.7Knps} b2
{+11.95/14 231.74s 1517.6Knps} 51. Kc2 {-10.42/15 144.75s 1227.5Knps} Kxe3
{+12.26/14 232.96s 1508.2Knps} 52. Kb1 {-10.58/14 147.34s 829.5Knps} f4
{+12.26/14 233.41s 1340.5Knps} 53. Kxb2 {-11.96/14 152.93s 649.7Knps} f3
{+12.51/14 235.28s 1513.7Knps} 54. Kc2 {-11.96/12 155.73s 1155.9Knps} f2
{+100.00/13 237.18s 1513.1Knps} 55. Kb2 {-12.30/11 158.15s 830.5Knps} f1=Q
{+100.00/11 237.25s 55.6Knps} 56. Kb3 {-325.11/10 163.01s 468.3Knps} Qd3+
{+100.00/6 237.31s 5.4Knps} 57. Kb4 {-325.11/10 168.23s 505.1Knps} Kd4
{+100.00/4 237.37s 0.7Knps} 58. Ka5 {-325.11/12 175.54s 824.1Knps} 
0-1 {Xboard adjudication}

[hgm]

The reason I am a bit hesitant is that I consider the {score/depth time} comments as a kind of standard (although formally they are just comments). So it should not become amenable to mis-interpretation, because the meaning of the 'time' parameter is ambiguous. So if the item following score-depth is not the time for the move itself it must be somehow distinguishable from it. E.g. by preceding it with a + sign to indicate cumulative time.

Wouldn't it be better to print the time left on the clock, btw?