XBoard for Mac: Zippy problems

[sje]

Bug tales

I had disabled the setboard directive via the feature command as I hadn't yet implemented the code. Unfortunately, I had forgotten or somehow deleted the dispatch case for setboard. and this was hidden for the moment. But I had included a bit of code in the select statement to print a diagnostic to stderr, then die if the default were hit.

Trying to resume an ICC game caused a crash. Looking at the log, XBoard tried to send the a2a3 edit kludge to set up a position. But since my program wanted only SAN, it failed to recognize a2a3 and said so. XBoard ignored the complaint and continued with sending an edit directive which Symbolic does not know how to handle.

Because I didn't want to waste time implementing the edit directive, I installed the setboard code. But because I had missed the setboard dispatch, my default code did what it was supposed to do: wrote the switch fault location and called abort(). Most unfortunately, I'd forgotten that XBoard seizes control of stderr along with stdout when it sets up the piping, and that made the diagnostic vanish.

I need to be more careful writing dispatch code.

And XBoard should not seize stderr.

[hgm]

Forgot to add: Two extra XBoard instances were launched with that one shell script for a total of three XBoard copies running at the same time. Very strange.

The gtkosx build of XBoard has to deal with the OS X habit to not directly pass the arguments to a program (as the usual argc, argv), but just start programs without arguments, and then send them an OSX-specific signal, which you can catch to get to receive the command line as an argument to the signal handler. And when you attempt to start a second instance of XBoard, it will not start it at all. Instead it will send the signal with the new command line to the already running instance. OS X is very much written on the philosophy that there should never rn more than one instance of any program, and that this instance should then be able to multi-task itself. This is not what you would want for XBoard, though.

So we were forced to put code in the signal handler that, on reception of a command line, would force launching of a new XBoard instance with that command line. (This can be done by forking off an "open -n xboard ..." command, IIRC.) The problem is that you have to distinguish the case where XBoard gets the signal because of its own command line, or where you receive the command line of a new instance the user wants to start. If you start a new instance to handle your own command line you get in an infinite regression. This is now done based on timing: if you receive the signal that transfers the command line shortly after startup, it assumes it was the command line meant for itself, so it just applies it during the startup. If it arrives later it assumes it has nothing to do with itself, and forks off a new instance with the given command line. (Which will then again be launched as a are 'xboard' command, and receive the signal with that same command line shortly after, facing again the same dilemma.)

It seems that in your case something went wrong in this process, like that for some reason the sending of the OSX command-line signal was delayed, so that it was mistaken for a request to startup a new instance, rather than supplying the command line of the current instance.

[hgm]

Trying to resume an ICC game caused a crash. Looking at the log, XBoard tried to send the a2a3 edit kludge to set up a position. But since my program wanted only SAN, it failed to recognize a2a3 and said so.

I really abhor that kludge. For one, XBoard plays many variants now where the initial position does not have a Pawn on a2 (Xiangqi, Shogi, Makruk). For this reason I undeprecated the 'black' command, so that XBoard can fall back on it when the kludge cannot be applied. There seems to be no good reason for deprecation of the 'black' command; it is a perfectly logical partner to 'white', and both are necessary complements to 'edit'. Only when engines implement the optional 'setboard' you can do without them. That not all engines implemented the command correctly is not a good reason to resort to a kludge to avoid it, and I think implementing it was the worst decision in the design of XBoard.

I guess logically speaking sending a2a3 to an engine that announced 'feature san=1' should be considered an XBoard bug. OTOH, not implementing setboard in combination with requiring SAN is a very unusual and illogical engine setting. The protocol specs warn about this kludge, so if you insist to have your engine use the 'edit' command rather than 'setboard', you should be prepared to understand a2a3 in coordinate notation as a move. I don't feel much like making the kludge more fancy by supplying a SAN version of it. (IMO the existence of 'feature san=1' is the second-largest mistake in the design of XBoard.) I'd rather remove the kludge alltogether, and re-instate the 'black' command.

Note that the 'edit' command does fail to specify a complete game state not only w.r.t. side to move, (which then requires either 'white'/'black' commands or the a2a3 kludge), but also w.r.t. castling and e.p. rights. Kludges similar to the a2a3 kludge would exist (e.g. for e.p. rights set up the position for one move earlier, and send the double-push as move to the engine), and are also not implemented. So why bother about the side to move?

[bob]

Forgot to add: Two extra XBoard instances were launched with that one shell script for a total of three XBoard copies running at the same time. Very strange.

The gtkosx build of XBoard has to deal with the OS X habit to not directly pass the arguments to a program (as the usual argc, argv), but just start programs without arguments, and then send them an OSX-specific signal, which you can catch to get to receive the command line as an argument to the signal handler. And when you attempt to start a second instance of XBoard, it will not start it at all. Instead it will send the signal with the new command line to the already running instance. OS X is very much written on the philosophy that there should never rn more than one instance of any program, and that this instance should then be able to multi-task itself. This is not what you would want for XBoard, though.

So we were forced to put code in the signal handler that, on reception of a command line, would force launching of a new XBoard instance with that command line. (This can be done by forking off an "open -n xboard ..." command, IIRC.) The problem is that you have to distinguish the case where XBoard gets the signal because of its own command line, or where you receive the command line of a new instance the user wants to start. If you start a new instance to handle your own command line you get in an infinite regression. This is now done based on timing: if you receive the signal that transfers the command line shortly after startup, it assumes it was the command line meant for itself, so it just applies it during the startup. If it arrives later it assumes it has nothing to do with itself, and forks off a new instance with the given command line. (Which will then again be launched as a are 'xboard' command, and receive the signal with that same command line shortly after, facing again the same dilemma.)

It seems that in your case something went wrong in this process, like that for some reason the sending of the OSX command-line signal was delayed, so that it was mistaken for a request to startup a new instance, rather than supplying the command line of the current instance.

Actually it seems that something went wrong in Apple-land. That is just about the most ridiculous thing I have ever heard. A signal to get argv/argc? REALLY?

YARTDOSX

(Yet another reason to dump os x)

I can't even call that brain-dead it is so bad...

[sje]

Actually it seems that something went wrong in Apple-land. That is just about the most ridiculous thing I have ever heard. A signal to get argv/argc? REALLY?

Yes, that's pretty bad, but it looks like a lot of the grief in this situation comes from wanting gtk to do more than what it was designed to do. By itself it can't magically turn a non-Mac application into a native Mac application which behaves like a typical Mac application.

And gtk has other problems on the Mac. Specifically, unresponsive dialogs. In my trials with Mac/XBoard. it was very easy to get an XBoard option dialog to freeze -- no response on check boxes, no response on the OK button, or no response on anything but the close (red) button.

The answer is to use OS/X development tools to build the GUI portion of any application while bundling all the real do-the-job code into a Unix-style program which can run on any Unix system with all the user interface tasks done by indirection to the GUI code. But this takes work and some forethought to do it right.

[bob]

Just run macports as root, I generally do this:

port self update

then

port upgrade outdated

Anything you have installed will be updated to the most recent.

To install xboard:

port install xboard

and sit for a minute or two. I have also installed gcc 4.8, and quite a few other things like wine, csh, you-name-it...

Okay, I'm giving it a try.

For those following this, instead of

Code: Select all

port self update

use:

Code: Select all

port selfupdate

The dependency list for xboard is very long:

Code: Select all

bash-3.2# port install xboard 
--->  Computing dependencies for xboard
--->  Dependencies to be installed: cairo expat fontconfig freetype bzip2 libpng zlib xz gettext libiconv gperf ncurses glib2 libffi libpixman xorg-libXext xorg-libX11 xorg-kbproto xorg-libXau pkgconfig xorg-xproto xorg-libXdmcp xorg-libxcb python27 db48 libedit openssl python2_select python_select sqlite3 xorg-libpthread-stubs xorg-xcb-proto libxml2 xorg-xextproto xorg-xcb-util xrender xorg-renderproto gdk-pixbuf2 autoconf automake gobject-introspection libtool py27-mako py27-beaker py27-setuptools py27-markupsafe jasper jpeg shared-mime-info tiff librsvg gtk-doc docbook-xml docbook-xml-4.1.2 docbook-xml-4.2 xmlcatmgr docbook-xml-4.3 docbook-xml-4.4 docbook-xml-4.5 docbook-xml-5.0 docbook-xsl fop itstool gawk readline py27-libxml2 libxslt openjade opensp perl5.22 gdbm source-highlight boost icu ctags libcroco pango Xft2 harfbuzz graphite2 vala xorg-libXaw xorg-libXmu xorg-libXt xorg-libsm xorg-libice xorg-xtrans xpm

Sorry. Safari loves to correct things that are not broken.

[bob]

Gosh, it worked.

Well, except that I had to fiddle with the various options like killing the sound.

You can edit the options to remove the "aplay" (you should try to type that word in Safari). Or you can just make an empty file that is executable, and give it that name, to get rid of the incessant complaints about that executable being missing.

[sje]

Or you can just make an empty file that is executable, and give it that name, to get rid of the incessant complaints about that executable being missing.

Which is what I'd done before; a noop aplay.

But the better solution is to have the XBoard dialog include a master switch that can disable all sound and all bogus invocations of a sound playing program.

[sje]

Or you can just make an empty file that is executable, and give it that name, to get rid of the incessant complaints about that executable being missing.

I forgot to add:

On Mac OS/X 10.5 through 10.7 at least, the command line sound player is named afplay:

Code: Select all

AFPLAY(1)                 BSD General Commands Manual                AFPLAY(1)

NAME
     afplay -- Audio File Play

SYNOPSIS
     afplay [-h] audiofile

DESCRIPTION
     Audio File Play plays an audio file to the default audio output

OPTIONS
     -h       print help text

Darwin                         February 13, 2007                        Darwin

Which will handle WAV files and maybe some other formats.

[hgm]

It suffices to set the sound program to an empty string. Then their will be no sounds and no bogus invocations (and can be done through the Sound Options menu dialog). Is that not good enough?

In XBoard the Options menu contains a toggle menu item "Mute All Sounds", which is intended for quickly and temporarily silencing it for the purpose of answering a phone call (say). It is not saved in the settings file, and allows sounds by default. I could make something like that in XBoard too.