Symbolic vs tscp: more match results

[hgm]

There's also:

Code: Select all

ld: warning: option -s is obsolete and being ignored

Well, that is just a warning. It is not obsolete on the version of the C compiler I am using, so it serves some purpose, and I therefore would ratherwant to not remove it. That is the sort of thing you have to live with when you use just a simple Makefile, and no ./configure script that could adapt it to the properties of your C compiler.

[sje]

I was able to get the install target to run to completion, but for some reason xboard can't find the default FairyMax executable at start time. So I made a copy of FairyMax and put that into its own battle directory and it successfully locates its initialization file. But I have to manually select FairyMax via dialog.

The relevant chunk of .xboardrc:

Code: Select all

-firstChessProgramNames {
"MatchSymbolic" -fcp "/Users/sje/Arena/Matches/Symbolic -c X" -fd "/Users/sje/Arena/Matches"
"FairyMax" -fcp "/Users/sje/Arena/FairyMax/FairyMax" -fd "/Users/sje/Arena/FairyMax"
"OldSymbolic" -fcp "/Users/sje/Arena/OldSymbolic/OldSymbolic -c X" -fd "/Users/sje/Arena/OldSymbolic"
"Symbolic" -fcp "/Users/sje/Arena/Symbolic/Symbolic -c X" -fd "/Users/sje/Arena/Symbolic"
"TSCP" -fcp "/Users/sje/Arena/TSCP/tscp" -fd "/Users/sje/Arena/TSCP"
}

----

I'm now running a 100 game match with a 5 minute/game time control. So far, the score in Symbolic vs FairyMax is 26-16-13 (+64 elo).

Sample game:
[pgn][Event "XBoard Event"]
[Site "gail"]
[Date "2015-09-29"]
[Round "4"]
[White "Fairy-Max 4.8V"]
[Black "Symbolic 2015-09-29"]
[Result "1-0"]
[FinalFEN "kr6/p1B1PR2/P7/1p6/8/1KP5/2P5/8 b - - 0 71"]
[Termination "Black resigns"]

1. d4 Nf6 2. Bf4 g6 3. h4 e6 4. Nc3 Bb4 5. Qd2 Ne4 6. Qe3 d5 7. a3 Bxc3+ 8. bxc3 Nd7 9. Nf3 Ndf6 10. Ne5 Bd7 11. f3 Nd6 12.
Nxd7 Nxd7 13. Qd3 Qe7 14. g3 c5 15. Bg2 c4 16. Qd2 O-O-O 17. O-O f5 18. a4 Nf6 19. Rfb1 Kb8 20. a5 Ka8 21. a6 b6 22. Be3 Nf7
23. Qe1 e5 24. Qc1 Nh5 25. Bf2 exd4 26. g4 fxg4 27. fxg4 Nf6 28. Bxd4 Rhf8 29. Qa3 Qxa3 30. Rxa3 Ne4 31. Rb5 Rfe8 32. e3 Rd7
33. g5 h6 34. h5 gxh5 35. g6 Nfg5 36. g7 Rdd8 37. Kh2 Kb8 38. Ra2 Kc7 39. Ra1 Kc6 40. Rb2 Kd7 41. Rf1 Kc7 42. Rf5 h4 43. Ra2
Kb8 44. Rf4 h3 45. Bxh3 Nxh3 46. Kxh3 Ka8 47. Kg4 Rc8 48. Rf3 Rg8 49. Rf7 Ng5 50. Rd7 Rgd8 51. Re7 Rd6 52. Be5 Re6 53. Rxe6
Nxe6 54. Kh5 Re8 55. Kxh6 Rc8 56. Ra1 Re8 57. Rg1 Nxg7 58. Rxg7 Rh8+ 59. Kg5 Rd8 60. Kf5 Re8 61. Kf6 Rh8 62. Ke6 Rf8 63. Kxd5
Rc8 64. Bc7 Re8 65. Kxc4 Rc8 66. e4 Rf8 67. e5 Rf4+ 68. Kb3 Rf8 69. e6 b5 70. Rf7 Rb8 71. e7 1-0[/pgn]

[hgm]

Well, the new Makefile by default puts the executable in /usr/local/bin. Perhaps that is not in your PATH, and then XBoard would not be able to find it. It should of course have been possible to browse there from the Load Engine dialog if you would know where to find the binary yourself. No need to copy it else where.

[sje]

I haven't tried the new Makefile yet, because what I have at this point is working with a little manual assist at start time. I'll wait until there's a new version of FairyMax.

What I should do is to invoke xboard with explicit command line parameters as I do for ICS play. That way, no engine information is hidden in an initialization file.

----

Here's another game:
[pgn][Event "XBoard Event"]
[Site "gail"]
[Date "2015-09-29"]
[Round "1"]
[White "Symbolic 2015-09-29"]
[Black "Fairy-Max 4.8V"]
[Result "1-0"]
[FinalFEN "r3k2r/pR2Q2p/5p2/3pp2p/8/5KP1/P1P4P/4R3 b kq - 1 25"]
[Termination "Black is checkmated"]

1. Nf3 d5 2. g3 Be6 3. d4 c6 4. Nc3 Nd7 5. Bf4 Qb6 6. Qd3 Nh6 7. Bxh6 gxh6 8. Bg2 Qxb2 9. Rb1 Qa3 10. Rxb7 Nb6 11. Ne5 Qd6 12.
e4 f6 13. exd5 Bxd5 14. Nxd5 Nxd5 15. Nc4 Qe6+ 16. Kd2 h5 17. Re1 Qg8 18. Qa3 e5 19. Nd6+ Bxd6 20. Qxd6 Qg4 21. Bxd5 Qxd4+ 22.
Ke2 Qg4+ 23. f3 Qxf3+ 24. Kxf3 cxd5 25. Qe7# 1-0[/pgn]
Current match score: 27-16-14 (+68 elo).

[hgm]

The old Makefile would have put the Fairy-Max binary in /usr/bin . I would expect that to be in your path. So it would be strange if

xboard -fcp fairymax

would not work. In fact it would already be strange if plain

xboard

would not work, as Fairy-Max is the default engine of XBoard. So both first and second engine should normally be Fairy-Max if you don't specify anything.

Does it also not work if you type "fairymax" on the command line?

[sje]

The old Makefile would have put the Fairy-Max binary in /usr/bin . I would expect that to be in your path. So it would be strange if

xboard -fcp fairymax

would not work. In fact it would already be strange if plain

xboard

would not work, as Fairy-Max is the default engine of XBoard. So both first and second engine should normally be Fairy-Max if you don't specify anything.

Does it also not work if you type "fairymax" on the command line?

No, it doesn't.

Code: Select all

sje$ echo $PATH
/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin

[sje]

The init file was installed as /usr/share/games/fairymax/fmax.ini

[hgm]

The init file was installed as /usr/share/games/fairymax/fmax.ini

Yes, this is normal, and that path is hard-coded in the Fairy-Max binary. So as long as you can start the binary, it doesn't matter what the current directory is.

Ah, I see. The old Makefile put the binary in /usr/games . Which is apparently not in your path. I guess this is a convention specific to Debian. The new Makefile would place in in /usr/local/bin , which should have worked with your PATH.

[sje]

To have a chance of providing for a correct installation on a particular platform type, an actual machine of that type is a requirement for testing and verification. Otherwise, it's all just guesswork and will likely fail.

[hgm]

Well, I happily leave testing to those who actually own such a platform. That seems a more reasonable distribution of effort.

The problem in this case was that I made the old file when I didn't know anything about Makefiles and GNU standards, and had no idea how packaging by organizations like Debian worked. So I made a rather rigid Makefile, which exactly did what would be needed to create a binary Debian package for the repositories, but was unsuitable for anything else.

The new Makefile is flexible through symbolic referece to the installation directories, in a way that complies with the GNU standard. By default it does not target a distro repository, but users of general Linux-like systems that want to install from source, as packaging usually involves overruling these defaults through the defined standard symbols.