Any WinBoard bugs I missed?

[bob]

Ok, so we agree that the problem is more general... I simply would remark some specific pattern which seems to be common. I will present them here in temporal order (so you will see what you would see on a console window, top = oldest line, bottom = newest line)

case 1: multiple fail lows due to bad AB window. For fail soft frameworks the engine could print the so far best (and bad) move. Fail hard would simply ouput the ? without any move.

Code: Select all

13 +0.20 1:15 e4?
13 +0.10 1:16 e4?
13 -0.10 1:17 e4?
13 -1.45 1:17 d4 blah blah blah

Here the engine fails low three times lowering the best (bad) score, and finally find the best move being d4 with a score of -1.45.

Case 2: two exact scores due to bad move ordering.

Code: Select all

13 +0.20 1:15 e4 blah blah blah
13 +0.25 1:16 f4 blah blah

Here the engine finds two exact scores due to a bad move ordering schema. During search it picks first the "e4" move and find it to be the best move, then picks "f4" and this results in a better move.

Case 3: an exact score, followed by fail high, followed by an exact score again

Code: Select all

13 +0.20 1:15 e4 blah blah
13 +0.90 1:16 f4!
13 +0.20 1:17 e4 blah blah

Here the engine finds a best move, then picks another move which triggers a fail high (due to TT hash hit and lack of depth, typical in distant mates). The research though cannot "complete" the fail high, and the f4 search produces nothing, leaving again e4 as the best move.

Ideally, the thinking output window should display everything that reflects the current preferred choice of the engine, and not what the GUI thinks the engine is actually preferring. How you would display such outputs?

There is another potential problem. When PVS first came along, Ken used it in Belle, and did the following:

(1) get first score for first move.

(2) continue searching with null window.

(3) if a move fails high, remember it and the score (which would be current alpha +1 on the null-window search.

(4) if a second move fails high, re-search the first fail-high move with a relaxed beta value to get a real score.

(5) re-search the second fail-high move with new_score, new_score+1 where new_score is from (4).

(6) if it fails low, keep going with nv, nv+1 over the remaining moves.

(7) if the move fails high, or if any of the remaining moves fail high, go back to step (3).

This allows you to get a PV, a fail high, a second fail high on a different move, a PV from the first move, and nothing or a fail high from the second fail-high move or beyond. That's a lot of out-of-order stuff going on.

In thinking, I wonder if HGM could add a new "feature" like

feature=temporal_order

which says "display the moves in the order they are produced, period" and perhaps

feature=n_best_order

where he sorts to handle the n_best output when it is used. Then he doesn't have to try to figure out which to use, the engine tells him.

[JoshPettus]

Hi Harm, thanks, that seems to fix the problem.

As far as to the .ini system.

We have the master one in DATADIR/Contents/Resources/etc/xboard.conf
and that saves user settings in ~/Library/Preferences/XBoard.conf.

I think the engine should save its settings with the user conf not the master one. If we ever get someone registered as an apple developer, and pays the 100$ fee, they can code sign the app so the app will start right away when clicked on when it's first installed.

Right now people have to right click on the app, click open, and click open on the popup dialog. (only for the first time). After that It will open up on the double click. (or they can disable gatekeeper in the system preferences) Thing about code signing is it breaks if anything is added to the bundle afterwards. So anything the user does, and special config files, must be done outside of the bundle.

One day I'll get the apple certification so we can do this.

[hgm]

The 'chu' file that comes with the Debian HaChu package is not for saving settings, but just for configuring XBoard for a kanji Chu display (specifying the -pid, square colors, default engine, etc.).

XBoard would now seek such a file (in response to "xboard @chu" as DATADIR/themes/conf/chu , which does not seem the right place. But perhaps this system is not needed on OS X at all. It was sort of dubious on Linux in the first place, targeting mainly at command-line users.

[JoshPettus]

Yah, I have a special launching script included with XboardSg.app for Chu shogi.

[sje]

Has the current version of xboard (not WinBoard) been tested on a big-endian CPU like a PowerPC?

Which Mac OS/X versions can run the Mac port of xboard not using X Windows?

Which Mac OS/X versions can run the Mac port of xboard using X Windows?

Can the Mac OS/X 10.4.11 (PowerPC) run any version of xboard?

[JoshPettus]

I have an PowerPC mac 10.4 as well, I really wanted to make a PPC version, But I'm afraid I cannot get gtk2 quartz and gtkmacintegration compiled on anything less then 10.5. Which I won't install on my PPC mac as it looses Classic support. I'm sorry.

You can compile the XAW yourself though. You would need xcode installed, install an old version of macports, install autoconf, automake. Then ./configure
make and make install. and it will work on the command line.

[bob]

Has the current version of xboard (not WinBoard) been tested on a big-endian CPU like a PowerPC?

Which Mac OS/X versions can run the Mac port of xboard not using X Windows?

Which Mac OS/X versions can run the Mac port of xboard using X Windows?

Can the Mac OS/X 10.4.11 (PowerPC) run any version of xboard?

I've had no problems running any version using xQuartz. I have not tried the OS X specific version however.

At least up until 6-8 months ago it ran on big-endian machines just fine, at least the SPARCs. I don't think there is any endian code to deal with beyond the network connected sockets.

[JoshPettus]

The Xboard.app is Intel only I'm afraid.

[JoshPettus]

Hi HGM,

I think your commits with the extra font field seem to have fixed the Tournament window crashing issue as well.

-------------------------------

Here is a minor annoyance. The default position/size of the evalGraph is

Code: Select all

-evalGraphX 0
-evalGraphY 788
-evalGraphW 4
-evalGraphH 2

So whenever I start xboard with a fresh user config file, the Eval Graph pops up in a microscopic window over halfway toward the bottom of the left side of the screen. It's actually almost impossible to see at first, and I can see a few people thinking it's not actually working when it is.

It's not in the master config so I figured it must be hard coded that way somewhere. I thought about changing it in osx config but I'm sure this is a problem in linux as well.

Where as moveHistory and engineOutput have much more reasonable defaults:

Code: Select all

-moveHistoryX 0
-moveHistoryY 0
-moveHistoryW 404
-moveHistoryH 56

Code: Select all

-engineOutputX 0
-engineOutputY 0
-engineOutputW 504
-engineOutputH 163

[bob]

The Xboard.app is Intel only I'm afraid.

I assume you are talking about the os x version only? xboard works on everything I have here as we use the source (x11) distribution and compile for each platform.