hgm wrote: ↑Thu Feb 23, 2023 7:10 am
OK, so XBoard seems to finally work. And now there is a problem with the move format of the engine. To know exactly what the engines do wrong, I would have to know what they do. I.e. see the log. Unfortunately XBoard was not sized large enough to see the full error mesage in the second case. And if the move in the first case really was d4,d4, that would seem illegal to me, and I am surprised XBoard accepts it.
So try to run the games again with the option -debug, and post the resulting xboard.debug file here.
I did not get xboard to run with the option -debug (see image). It won't load any of the engines.
Here is the contents of the debug file:
locale = en_US.UTF-8
recognized 'normal' (-1) as variant normal
recognized 'normal' (-1) as variant normal
recognized 'normal' (-1) as variant normal
shuffleOpenings = 0
shuffleOpenings = 0
Version: xboard 4.9.1 + fairymax ()
Reset(1, 0) from gameMode 0
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
shuffleOpenings = 0
StartChildProcess (dir=".") fairymax
304 >first : xboard
protover 2
304 <first : fairymax: No such file or directory
GameEnds(30, xboard exit, 2)
When I run xboard -debug it copied all the piece images into /usr/games.
Retired actuary and software developer. I love chess, coffee, wine and food
Oops. That was a patch I made for my own use, to create a set of PNG piece images for on chessvariants.com. I forgot to remove it for thhe version I compiled for you. I wii compile a new binary.
Otherwise XBoard runs just fine. It just reports that the engine you requested (in this case by default) does not exist. That should not prevent you to select other engines through the menu.
But you cannot run any engines that you have not installed on your computer. Which appears to be the case for fairymax. I don't know how you otherwise run XBoard, but you should run it the same way, with -debug as extra argument.
My starting point was to install the "official" version of xboard using apt-get. I relplaced the executable file for xboard with the "debug" version you sent me. When I check the path to xboard, it is given as /usr/games/xboard.
If I try to start xboard from the terminal with sudo ./xboard (or with -debug), then it can not load any engines. But it works fine if I click on the executable from the file manager.
Retired actuary and software developer. I love chess, coffee, wine and food
When you download binary packages from the official repositories, the binaries are installed in /usr/bin (or /usr/games for some), and use data files from /usr/shared/*. But source packages are constructed such that a "make install" puts them in /usr/local/bin (and the accompanying data files in /usr/local/shared/*). Which in the system's search path occurs before /usr/bin, so that local installs 'eclips' any official versions, without actualy un-installing those. Your own home directory is usually searched last, and only for commands that start with "./".
Why are you trying to run XBoard as super-user? This is probably your main problem: XBoard saves its persistent settings for each user separately, in the file .xboardrc in their home directory. This to make sure different users will not spoil each other's saved settings when they both use XBoard. But when you use sudo, XBoard would look in the home directory of user 'root' for the user settings file. And that is probably not where your settings are. In particular the engine list is stored in the settings file, so the engines you installed when you stil was yourself will not appear in the list when you use XBoard as root. Root's engine list looks like the hard-coded default list of XBoard, (probably because root does not even have a settings file), without actually looking whether those engines are really present on the computer. Most likely they are not, and then of course they would not run if you select them, but produce a "no such file or directory" error message.
If you run XBoard by clicking it in the file manager, you would run it as yourself, not as root. So then you see your own engine list, and everything works fine.
I was already wondering how you could get the image files in /usr/games; normal users would not be able to create any files there. Anyway, I now uploaded an XBoard binary that does not store any images ( at http://hgm.nubati.net/transfer/xboard.gz ).
I can't explain why my system operates differently - maybe because I'm using Linux Mint Cinnamon. When I installed the standard xboard 4.9.1 (from 2016), it located everything in /usr/games.
I would not run any program as super-user unless it was required. It is not necessary to run xboard. But I can't run xboard with the -debug option unless I use sudo:
Retired actuary and software developer. I love chess, coffee, wine and food
Well, that is because you set /usr/games as current directory, and you have no write permission in that directory as an ordinary user. And XBoard would create the xboard.debug file in the current directory. Even as super-user you would be very ill adviced to create scratch files or other data files in /usr/games. Because that is a special system directory for holding binaries that are installed directly from the distro repository. There should be no need to ever do anything in that directory; you should leave that to apt-get. If you want to run binaries in that directory you can type their name as command from any directory, as /usr/games is in the system's search path (if that is not corrupted). Even if you would like to replace system programs by your own versions, you should do that by placing those in /usr/local/bin, and leave /usr/games alone.
So just stay in your own home directory, and run XBoard there.
This totally baffles me. You did manage to run the previous version, and there is no doubt that this must have been the one I compiled for you, as it did support Duck Chess, and did show the ducky after you moved the piece images to its data directory. Can you still reproduce the conditions that allowed it to work? Do you still have that xboard file that inadvertantly stored the piece images? I overwrote it with the one that didn't, but by uncommenting a single line I could make the old one again that did seem to work.
I don't see how commenting out a single line that saved the images could suddenly cause this error in a library routine. So my guess is that it should somehow be caused by the circumstances under which it runs. But I don't know what those were when it was working.
