UCCI2WB

[JoshPettus]

Sorry I couldn't reply earlier, I guess you will get this tomorrow.

Everything worked perfectly!

Xboard quits properly and eleeye is nolonger in my activity monitor.

Funny, usually I have problems getting things to run, and quitting is the easy part.

Here is the output confirming.

Code: Select all

command read: xboard

command read: protover 2

command read: option UCI2WB debug output=0

command read: option promotion=0

command read: option batch=0

command read: option debug=0

command read: option usehash=1

command read: option usebook=1

command read: option bookfiles=./BOOK.DAT

command read: option idle=none

command read: option pruning=none

command read: option knowledge=none

command read: option randomness=none

command read: memory 68

command read: cores 1

command read: new

command read: random

command read: variant xiangqi

command read: level 40 5 0

command read: post

command read: hard

command read: ping 1

command read: accepted variants

command read: accepted setboard

command read: accepted usermove

command read: accepted debug

command read: accepted ping

command read: accepted reuse

command read: accepted exclude

command read: accepted pause

command read: accepted done

command read: accepted option

command read: accepted myname

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted option

command read: accepted smp

command read: accepted memory

command read: accepted done

command read: time 30000

command read: otim 30000

command read: usermove g0e2

command read: time 29974

command read: otim 29817

command read: usermove h0g2

command read: time 29955

command read: otim 29306

command read: usermove b2b9

command read: result * {xboard exit}

command read: quit

quit sent

[JoshPettus]

Thanks a lot!
I updated Xboard, XboardSg apps and added XboardXq. All with the menu quit bugfix. Xboard and XboardXq both have eleeye and uci2wb added.

[Daniel Mehrmann]

Are you kidding ?

I think the best way would be to follow the UCI syntax and not using any kind of wb related wording.
The UCI protocol (syntax) should be leave untouched in such cases. Instead of using same keywords and/or extend them, you should follow the offical way to add extensions to the UCI protocol.

That's the way how ChessBase, CA & CO add new features to UCI.

I think you've missing the point here. It's not about adding anything to UCI, it's about unifying the description of several existing UCI dialects (in this particular case, UCCI) to make it easier to add support for them. In particular in the case of UCCI there is no English-language reference.

Now, I do agree that some of these dialects and extensions (USI's byoyomi keyword, UCCI's banmoves mechanic) could have been handled better using existing UCI constructs - but they weren't, so we have to accept that they exist and deal with it.

Also, there's an "official way" to add extensions to the UCI protocol? Do share!

Yes, you're right i missed that point, but it's no good idea to merge three kind of UCI variants into one single text (file). This looks ugly and confused.

However, even if we have three 'stand alone' protocols, UCCI looks broken to me in the manner of the original UCI syntax. Probably we might have a copyright problem as well.

Regards
Daniel

[hgm]

I guess the OSX-Quit-menu bug in XBoard was the real problem. But as a side effect we also caught a real bug in the Linux port of UCI2WB (namely that it was not SIGTERM resistant), and increased its robustness (also sending 'quit' to the engine when it detects EOF from the GUI without having received 'quit' first.)

The problem there is that I repaired the sending of SIGTERM in this XBoard version, which in previous versions was not done (in violation of the specs) because I ported some WinBoard code there. (And Windows does not have such signals at all.)

I guess the better way to not be bothered by the signals is to send feature sigterm=0 sigint=0 at startup, rather than making the adapter insensitive to the signals. Then XBoard would not even send them.

[Evert]

Yes, you're right i missed that point, but it's no good idea to merge three kind of UCI variants into one single text (file). This looks ugly and confused.

You're still not getting it.

What is really annoying and confusing is having three specs for three protocols that are very similar and nearly identical and having to sift through all three to work out what's similar and what's different. Better to have it side-by-side.

However, even if we have three 'stand alone' protocols, UCCI looks broken to me in the manner of the original UCI syntax.

The only things that look broken to me in the UCCI spec are the clumsy "banmoves" command (should have used "go searchmoves" instead, or possibly extended that to "go excludemoves" since the use-case is to only exclude a few moves) and the broken time units (s rather than msec). I'd dump "probe" and "pophash". What it gets right is adding "nobestmove" and the "accapt draw/offer draw/resign" extension (we can quibble over whether it's done in the best way, but in my opinion it could be worse). The simplification of "setoption" is a bit pointless, but I do think the original UCI specification for that is needlessly clumsy. Not sending the full game history but only what's needed is a sensible thing to do as well (personally I think UCI's requirement of sending the full history on every move is absurd).

Probably we might have a copyright problem as well.

Explain?

[hgm]

(personally I think UCI's requirement of sending the full history on every move is absurd).

It is not really a requirement, just a habit. So the engine must have a very long move buffer, to han0dle very long games. (Of course it could clear it when it encounters a capture.)

UCCI engines often crash if you feed them more than 50 moves with the position-moves command.

Of course the motivation for only sending reversible (saving bandwidth) is a bit inconsistent; if you want to save bandwidth, you should not use anything UCI-like, but just send the latest move.

[JoshPettus]

Before we both forget , if you could put the:

Code: Select all

   g_signal_connect(theApp, "NSApplicationWillTerminate", G_CALLBACK(ExitEvent), NULL); 

line in your master branch, I'd be very grateful.

Thanks!

[hgm]

Done!

[Daniel Mehrmann]

(personally I think UCI's requirement of sending the full history on every move is absurd).

It is not really a requirement, just a habit.

Well, the "buffer" is no argument and we talking not about time or ressource critical elements in a chess engine. Further more there is a point, where you need to send all moves to a engine. And who tells you that an engine only pass the moves to update game data and board ?

But basicly, and that's the most importent point, i'm missing the real understanding about UCI, how it works and why is it desigend as it is.

I don't want to waste my time here, but here are some few words:

The main problem is your personal perspective and thoughts about UCI.
A protocol designer shouldn't think about how things would be going on with his own thoughts. A protocol designer needs to think how other developers might think about it and need to calculate the worse case always.

In other (hard) words: Developers are basicly "bitches" in the case of laziness. Sometimes they might think on wrong ways and implement wrong things. That should be the default way how to think on protocol things.

So, what you need is a safe protocol in any stage, any case and any scope. This is the first and most imporent rule. Everything else should never every break this rule and just for example, even if it means that you need to send all moves again, again and again.

I'm out now - Good luck!

Regards
Daniel

[hgm]

I am not sure why you are addressing me. I was not involved in the design of any of these protocols. I am just a user who implemented the GUI side of a driver for them, so I better stick to the specs as their developers have layed them out, or it would simply not work in all cases, or never at all.

And I just observe the fact that there is nothing in the UCI specs that says you always have to load all moves of the game, always starting with "position startpos". It explicitly specifies the posibility of starting from arbitrary positions with "position fen <FEN>", and a GUI designer could elect to send the position after the last irreversible move of the game, and only the moves from there.

This would be a valid UCI implementation, and if there would be engines that cannot handle it, these engines should be considered non-compliant.

And if people are worried about bandwidth, they'd better switch to XBoard protocol...