UCCI2WB

[JoshPettus]

Quite true! And OSX compiled ones are even rarer .

I keep thinking, "If you build it, they will come" But I guess we will see. It seems on OSX, people don't seem to mind making their own lousy GUIs for their engine.

[hgm]

Just for the record, do you have a problem with this version of UCI2WB when you let Elephant Eye play a ponder-on game using its own book?

I did find a simple fix for this, which is ignoring the ponder search altogether, and just fake the engine never pondered at all. When the opponent move then finally comes in, it will be a miss by definition, so even if it was a hit in reality the engine is just set to redo the ponder search as a real search.

It would still benefit from the ponder search, because presumably everything would be hashed. And even if not, this situation of dropping out of ponder too early tpically occurs only when there wasn't anything to search. Like when in book, or close to mate. In both cases redoing the search should be very fast as well.

I wonder if I should somehow emit a warning that the engine is misbehaving, though. I could throw up an error box through tellusererror, but this might be too annoying in comp-comp games. I guess I could emit a line of thinking output that prints an error message, which would then appear in the Engie Output window at the end of the ponder search.

[JoshPettus]

It doesn't seem to stay in book with ponder on. But no errors.

[JoshPettus]

has the fix been uploaded?

[hgm]

I pushed it just now. It should make UCI2WB resistant against this kind of non-compliancy. (Which, for all we know, might actually be allowed in UCCI.) It just ignores the prematurely finished ponder search, and prints an info string in the Thinking Output to notify the user.

I upped the version number to 2.0. I figured that supporting a whole new protocol that was non-trivially different would be worth a new major version number!

[JoshPettus]

Works great!

On the other hand, we have been at Xboard v4 since the dark ages

If you could change the USI checkbox in Load #Engine to USI/UCCI and add the -%variant to the UCI2WB launch command. (UCI2WB is technically in path on the OSX app, so it should be ok as is)

Plus sync with savanah to remove that OSXtheme
I'll put up a new 4.8.0b app with Eleeye.

[JoshPettus]

Gahh, I found a bug. When Xboard closes it doesn't seem to close Eleeye, before I know it i got 20 Eleeye processes in my activity monitor. I was wondering why my computer was slowing down

[hgm]

Make sure -delayAfterQuit is set to a non-zero value. This gives UCI2WB time to send a quit command to the engine before it is killed itself by XBoard. In principle it should send a quit immediately when it receives one, but it is very possible that it doesn't even get the chance to start running before XBoard also sends the kill signal (if the system is loaded by CPU hogging engines).

I updated my master branch, and changed the text on the USI checkbox. The new default -uxiAdapter command uses -%variant. Beware that I changed the name of the adapter to "uci2wb" in lower case, as is more conventional on Linux.

[JoshPettus]

I tried -delayAfterQuit 1000 and -delayBeforeQuit 1000, eleeye still stays open. Does it need to be larger? UCI2WB closes, but eleeye stays open. somehow running the engine as white or black yields two Eleeye processes? Not sure what's going on there. I eventually just have to do a killall eleeye.

Strange you think a simple quit command would do it.

[JoshPettus]

Also USI gpsfish (shogi) quits properly.