XBoard for Mac: failure to launch

[bob]

ah... Oops. Yes, my system isn't case sensitive as are most I imagine. It is the default, and to me sensative just seems to be asking for trouble somewhere down the road. That said, It should still work. Thanks for letting me know. I hope it's as simple as an edit of the /Xboard.app/Contents/MacOS/xboard. (open it with a text editor and line 73) I'll see if I can take a look at it when I get home.

Hopefully the launch command is the only thing effected... What about other elements? Do all the textures appear? Do you see the OSX style gtk theme? or is it default gtk theme? If your system is non-engish, does it find the localization files? I prey yes to all of these.

Case sensitivity makes perfect sense to me. "A" and "a" are NOT the same characters, they should not be the same "file". I run case-sensitive since that matches every linux/unix/etc box on planet earth. OS X has enough warts that if they were all moved to Jennifer Anniston, nobody would touch her with a 100' vaccinated pole. This is a big one, but there are many others.

[JoshPettus]

I understand, but then I'm sure there is software incompatibility elsewhere you have to deal with as a result of idiots like me who forgot case-sensitive-journaled was a thing... Hopefully i didn't shoot myself in the foot too badly.

I reuploaded the package, if you would be willing to try it out and make sure it all works, I'd be very grateful.

http://www.open-aurec.com:8080/wbforum/ ... 19&t=53274

[sje]

Thank you for looking at the CS bug.

I'll download and try a new version, perhaps after a few more problems have been addressed.

What I haven't tested are the old bugs associated with automated ICS play: 1) random segfaults and 2) false illegal move conditions caused by spurious take-backs if an end-of-game was not properly recognized. Trying to evade these problems when running the X Window version on a Mac ate a lot of time and caused bad feelings at the ICC when opponents were stuck waiting for my program to respond. Indeed, that's the main reason that Symbolic has not run on an ICS for over three years.

[JoshPettus]

If you can help narrow such issues down and report it to Harm, I'm sure he will be very grateful! Hopefully it'll run smoothly. I haven't run into any segfaults myself, and I use to run chess engines against other chess engine's on Pogo using matematiko's YaYp script. But then I never ran into a situation that required take backs. Your mileage may vary.

[hgm]

I was aware of the ICS crashes, but I have never been able to reproduce them. In the past I tried to debug this in cooperation with Steven, but IIRC the problem seemed to disappear if we switched on the debug log.

I don't quite understand what this problem with recognizing 'end of game' is about. Is that message sent by the ICS?

[sje]

I was aware of the ICS crashes, but I have never been able to reproduce them. In the past I tried to debug this in cooperation with Steven, but IIRC the problem seemed to disappear if we switched on the debug log.

I don't quite understand what this problem with recognizing 'end of game' is about. Is that message sent by the ICS?

Running in debug mode seemed to help get rid of the segfaults, but was of no use in pointing out why the segfaults occurred. I tried looking at the code and my opinion was that the string allocation/deallocation was fundamentally Messed Up.

As I recall, there was a problem with XBoard running on a Mac under X Windows where a new game was somehow corrupted with a prior game. I think that what happened was that a spurious move was sent by XBoard to the program and then taken back after a new game was started. This would cause the program to wait until it got flagged, and on several times this happened, the ICC administrator staff banned Symbolic because of opponent complaints. As the stiffed opponents couldn't quit without a forfeit, you can see where the hard feeling came from.