UCI, xboard protocols and interfaces for Mac OS X Lion

[hgm]

I'm lost with xboard configuration... this "cute chess" look pretty, does it is freely available?

I have no Mac, so I never tested this myself, but I always thought the XBoard package came fully configured, ready to run 'out of the box'.

What exactly is it you get lost in?

[stegemma]

I'm lost with xboard configuration... this "cute chess" look pretty, does it is freely available?

Well, it's definitely free (licensed under the GPL). And it's available in the sense that you can grab a DMG installer here (for 64-bit Intel Macs only): http://koti.mbnet.fi/~ilaripih/bin/cutechess.dmg
But it's not a released product, just a testing snapshot that may contain bugs and lacks some important features like tournaments.

I like this one. I've just downloaded the file, opened the app and it works, without any configuration. Now i add xboard support to Satana and then i can try if the engine embedded setup of your guy works fine.

Just a hint: trying a game human-human, i've seen that castling should be entered moving the king on the rook to castle with (using the mouse). Maybe could be better to move the king to its final square?

[stegemma]

I'm lost with xboard configuration... this "cute chess" look pretty, does it is freely available?

I have no Mac, so I never tested this myself, but I always thought the XBoard package came fully configured, ready to run 'out of the box'.

What exactly is it you get lost in?

I've tried "Xboard 4 - 1.5.3 - macintel" package and install fine. When i run xboard by clicking on it, as i do in windows, it say me that "the first chess program (fairymax) exited unexpectedly" then the obvious errors related to broken pipe, with that program. Then he said that "piece-description file '/usr/share/games/fairymax/fmax.ini' not found". The xboard form appears with this errors on its top. I can't found any ".ini" or ".conf" files in the xboard directory. I've tried even to run "Xboard GUIv1.2.scpt" script: it show me the choosing dialog but if i select "Change default engine" he said me that "permission error in Network document" (but this message is in italian, becomes comes from AppleScript) and it is related to "usr:local:etc:board.conf". The folder use/local/etc is locked, i've no permission to access that folder; i have administrator permission... but i can't access the folder. Because i don't know a lot of the mac os, that is enough to stop me find a solution, but i can try anything that you can suggest, so that it could be helpful to anybody else using the mac.

The other gui seems to run and i haven't problem, since now... but i can use both.

[ilari]

Just a hint: trying a game human-human, i've seen that castling should be entered moving the king on the rook to castle with (using the mouse). Maybe could be better to move the king to its final square?

Yes, the "king captures friendly rook" castling is unconventional for standard chess. It's implemented like that because Cute Chess also supports random variants like Chess960. In random variants the king may have two legal moves to the same target square - normal move and castling move. The "king captures friendly rook" method doesn't suffer from this ambiguity.

[Roger Brown]

Nice marketing speech
But yes, there's not much else one can recommend for Mac OS than Winboard. I think it's the only free GUI that handles tournaments, and both major communication protocols.

With that said, Cute Chess is shaping up to be pretty nice on a Mac:


Once I get tournament support and some GUI polish finished it's going to be good enough for those who like to tinker with bleeding edge stuff.

Hello Ilari,

WHOA!

That looks nice.

I know I probably missed something but is there a Cute Chess gui somewhere for Windows users? I asked you for a gui for the command line challenged years ago so this is good stuff.

Later.

[micron]

I've tried "Xboard 4 - 1.5.3 - macintel" package and install fine. When i run xboard by clicking on it, as i do in windows, it say me that "the first chess program (fairymax) exited unexpectedly" then the obvious errors related to broken pipe, with that program. Then he said that "piece-description file '/usr/share/games/fairymax/fmax.ini' not found". The xboard form appears with this errors on its top. I can't found any ".ini" or ".conf" files in the xboard directory. I've tried even to run "Xboard GUIv1.2.scpt" script: it show me the choosing dialog but if i select "Change default engine" he said me that "permission error in Network document" (but this message is in italian, becomes comes from AppleScript) and it is related to "usr:local:etc:board.conf". The folder use/local/etc is locked, i've no permission to access that folder; i have administrator permission... but i can't access the folder.

I can confirm these problems with the Xboard installer at
http://www.mediafire.com/?9cg7lf31u58b5vo
Vital configuration files are placed in strange non-Mac directories without read permission.

It's some months since I worked around the installation bugs, but I seem to remember that fixing permissions on two directories was enough to get Xboard working with fairymax as the default engine.

Launch Terminal.app and enter these commands (you will be asked for your password):
sudo chmod 755 /usr/share/games
sudo chmod 755 /usr/local/etc

Robert P.

[hgm]

OK, this is useful information. As I have no Mac, and know nothing about Mac OS, I am dependent on user feedback to know about and solve problems. It is the first time that anything like this is reported, and I will surely take it up with the one who created the Mac package.

Having no permission to use the mentioned directories is indeed likely to cause trouble:

/usr/share/games is the directory that according to Debian standards programs in /usr/games should look for their data files. So the Debian package for fairymax does put the fmax.ini file that contains the move-generator tables for all of the supported variants in

/usr/share/games/fairymax/fmax.ini

It could be put anywhere, as long as the hard-coded file name in the Fairy-Max binary would be set to where it is put, through a -DINI_FILE=... compile-time option. (For Windows, for instance, it is placed in the same folder as the binary.) In fact it is even possible to use the standard Linux binary of Fairy-Max by installing it under XBoard with an extra argument in the engine command to indicate the ini file, like

fmax /anywhere/fmax.ini

I kind of dislike that solution, though, because it means you would have to specify the argument also each time you want to run Fairy-Max from the command line.

The directory /usr/local/etc is used to store XBoard's master configuration file, (/usr/local/etc/xboard.conf), which is used to (re)define the defaults for some of the options, including the file name of the user settings file (~/.xboardrc). This is a Debian standard for packages compiled from source. (In their own binary package for XBoard they use /usr/etc/xboard.conf in stead.)

If there are more logical (and less troublesome!) places to put these files on Mac OS, I am open to recommendations. Note, however, that when you would obtain engines as Linux Debian packages (e.g. Fruit, Crafty, Glaurung) they would in general all expect their data files (e.g. opening books, config files) in /usr/share/games, and although they might not be as dependent on these files as Fairy-Max is, it could still mean impaired functionality (e.g. inability to use their books, not being able to remember their settings, etc.)

Note that these are purely engine problems, not directly related to XBoard, which you would encounter under any GUI when you tried to run the particular engine. But of course pretty annoying if they happen to crash XBoard's default engine. Not being able to read its master settings file would not preclude you from running XBoard, but would impair part of its functionality: the default values of all XBoard command-line options would revert to the compiled-in defaults, and saving the user settings would not work at all. (Which is of course just the situation as existed with any XBoard version 4.4.x or earlier, so long-time users might not consider this a crippling problem. But people used to WinBoard would think it pretty bad...)

What would be the best solution here, if we were to make a special compile of XBoard using default file locations tailored to Mac OS?

[Evert]

I have a Mac, but unfortunately for the purpose of this discussion, I treat it pretty much as a generic UNIX system and always run XBoard from the command line in a terminal (and compile and configure it by hand).

/usr/share/games is the directory that according to Debian standards programs in /usr/games should look for their data files. So the Debian package for fairymax does put the fmax.ini file that contains the move-generator tables for all of the supported variants in

/usr/share/games/fairymax/fmax.ini

It could be put anywhere, as long as the hard-coded file name in the Fairy-Max binary would be set to where it is put, through a -DINI_FILE=... compile-time option. (For Windows, for instance, it is placed in the same folder as the binary.) In fact it is even possible to use the standard Linux binary of Fairy-Max by installing it under XBoard with an extra argument in the engine command to indicate the ini file, like

fmax /anywhere/fmax.ini

I kind of dislike that solution, though, because it means you would have to specify the argument also each time you want to run Fairy-Max from the command line.

On OS X, the best "native" location is probably something like /Library/Fairy-Max/ or ~/Library/Fairy-Max. Perhaps ~/Documents/Fairy-Max, although I personally hate it when programs decide that their stuff needs to be in my documents folder.

The directory /usr/local/etc is used to store XBoard's master configuration file, (/usr/local/etc/xboard.conf), which is used to (re)define the defaults for some of the options, including the file name of the user settings file (~/.xboardrc). This is a Debian standard for packages compiled from source. (In their own binary package for XBoard they use /usr/etc/xboard.conf in stead.)

This should probably also be something like /Library/XBoard, although keeping ~/.xboardrc should be ok-ish.

What would be the best solution here, if we were to make a special compile of XBoard using default file locations tailored to Mac OS?

I think looking in /Library and ~/Library is probably the way to go, but I'll have a look (tonight, if I remember) for what we did in another project where we needed to know the the "best match" for standard filesystem locations across platforms.
OS X is like a UNIX system, but it has its (annoying) quirks.
By the way, ultimately the best solution for running XBoard on OS X would be one that doesn't require X11. I have no idea how well cross-platform GUI toolkits do these days in that department (wxWidgets might be ok, Qt I think emulates the native GUI rather than use it, GTK required X11 the last time I tried it)...

[ilari]

Hello Ilari,

WHOA!

That looks nice.

I know I probably missed something but is there a Cute Chess gui somewhere for Windows users? I asked you for a gui for the command line challenged years ago so this is good stuff.

Later.

Cute Chess is cross-platform, so it will be available on Linux, Windows and OSX. But because it's still in development I haven't bothered with creating an easy-to-install package for Windows. Too many missing features and a couple of Windows-specific bugs prevent me from doing a release right now. I'm hoping to get a beta version out before Christmas, but you know how it is with schedules and software projects.

[hgm]

By the way, ultimately the best solution for running XBoard on OS X would be one that doesn't require X11. I have no idea how well cross-platform GUI toolkits do these days in that department (wxWidgets might be ok, Qt I think emulates the native GUI rather than use it, GTK required X11 the last time I tried it)...

The problem is that XBoard is not written in any of these toolkits. People are making a GTK port of XBoard now (actually this is already in an advanced stage, nearly completely working), but as you say, it won't rid us of X11, and therefore to me has always seemed a pretty futile endeavor.

In the past year I significantly reduced the amount of XBoard front-end code, at the same time enormously expanding the nuber of menu dialogs. I would really like to reduce the amount of front-end code to nothing but a few elementary routines (one to pop a menu defined in a platform indepedent list, another to pop up a dialog from a similar list, some basic drawing functions for lines, squares, circles and bitmaps), so that XBoard would be trivial to port to any platform. Apart from having a Mac version, I would like to have an Android version...