UCCI2WB

[Daniel Mehrmann]

I am not sure why you are addressing me. I was not involved in the design of any of these protocols.

I'm adressing you both!

I add you too, because your persistent negative thoughts about UCI. But i know it's more or less waste of time.

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"....

If it's a fact for you or not is irrelevant. The keyword "safe" is the point. Send startpos with all moves just fills this purpose.

Much more importent is the fact, that you, like your role as GUI designer, should not decide things what the engine should get or not get on game information (in our case all moves instead of a fen string (with a few moves or no moves)). It should up to engine , like UCI does, what the engine want to do with it.

This is an excellent example what i mean if i wrote to you that i'm missing the "understanding" point of view. And i still leave the commercial point of view untouched right now.

Regards
Daniel

[hgm]

Joshua, note I still made a minor fix to UCI2WB:

Forward Pawn moves now also act as staring point for a new position FEN, not just captures.

[Evert]

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 ?

Well, bear in mind that the starting point for this particular point is the UCCI spec, which states that the GUI should send the position after the last irreversible move, and the moves since that point. My initial suggestion was to simply ignore that, since the only difference it should make is in the number of moves that are sent to the engine.

As HGM pointed out, that's no good, since there are (apparently) many UCCI engines out there that will crash if you do that. Now, you can say that that's their problem, but first of all, that's not very useful for a user who wants to run them (especially if chances are slim that the UCCI engine author will fix the problem) and second of all, we're not actually following the protocol spec.

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.

No disrespect, but I have the distinct impression that the one who is missing a part of the discussion is you. This isn't about what UCI is or how it should be, or how we can abuse it. This is about UCI, USI and UCCI, which are all basically UCI dialects, and how to write an adapter that can be used to communicate with engines using these protocols.

Now, clearly, if you have something constructive to add here, please do! But I get the impression you just want to make some vaguely negative comments and not be constructive, and I don't really understand why.

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.

True, but again: we're not designing anything here. These are existing protocols developed by other people.

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.

Funny you say that, because half the issues that were discussed are work-arounds for faulty engines.

The sanest way to handle communication through a communication protocol is to strictly follow the protocol in what you send to the engine, and cutting the engine some (or a lot of) slack when you interpret what it sends back. Same for communication the other way.
But again, what do you do with USI engines that crash when you send them "winc" commands?

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.

Sending all moves again and again does not imply a robust protocol.

But the reason it annoys me personally is that all my programs keep track of their own game history, so when I receive a UCI "go" command I need to first unwind my game history, then step forward through the game again. It would be far easier (for me) if it just sent the last move instead. Obviously that's simply how my programs work, and it turns out to be a poor fit to UCI. That's why I think it's annoying, but I'm not pretending that it's anything other than my personal opinion.

[hgm]

If it's a fact for you or not is irrelevant. The keyword "safe" is the point. Send startpos with all moves just fills this purpose.

If the purpose is to crash the engines, yes...

Because UCCI protocol explicitly forbids you to do this it would be foolhardy to do it anyway. It gives an entirely new meaning to the word 'safe'.

Tresspassers will be shot... Well, that sounds like a really safe shortcut, through someones garden, where I am not likely to get mugged!

[Evert]

I'm adressing you both!

You're still missing the point that we're not designing anything here. Just documenting existing practice.

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"....

If it's a fact for you or not is irrelevant. The keyword "safe" is the point. Send startpos with all moves just fills this purpose.

But it's irrelevant.
Why would a GUI ever want to send a FEN+moves rather than startpos+moves? For UCI/USI, I don't know. It's more work than just sending startpos+move history, so that's what I'd do. For UCCI, it's a different matter, because it's apparently expected by engines (and stated in the spec), and causes problems if not followed.
Either way - a GUI is not breaking the protocol spec if it would send FEN+moves rather than startpos+moves.

Much more importent is the fact, that you, like your role as GUI designer, should not decide things what the engine should get or not get on game information (in our case all moves instead of a fen string (with a few moves or no moves)). It should up to engine , like UCI does, what the engine want to do with it.

Of course the GUI designer gets to decide what information to send to the engine, in fact I'd say that's pretty much the job description.
What I think you mean to say is that you don't think the GUI should intentionally limit what it sends. And it probably shouldn't. But again, here's the thing: you do have to deal with engines that simply cannot cope with certain input.

This is an excellent example what i mean if i wrote to you that i'm missing the "understanding" point of view. And i still leave the commercial point of view untouched right now.

Again, I think it's you that's not understanding the context.

[JoshPettus]

Joshua, note I still made a minor fix to UCI2WB:

Forward Pawn moves now also act as staring point for a new position FEN, not just captures.

Sure, I'll make a silent update, I figure there will be a few down the road.

[JoshPettus]

Done!

[hgm]

My initial suggestion was to simply ignore that, since the only difference it should make is in the number of moves that are sent to the engine.

That is a dangerous assumption. Because the specs guarantee that the engine will never receive a Pawn push or capture from the GUI, it could very well be that the author has taken a shortcut in implementing the code that performs the moves to create the current position. E.g. he could simply update the board, but not delete captured pieces from the piece list, creating an inconsistent state that causes illegal moves later. Or when the engine internally uses a different piece code for Pawns on either side of the River, not upgrade the piece while moving.

[Evert]

My initial suggestion was to simply ignore that, since the only difference it should make is in the number of moves that are sent to the engine.

That is a dangerous assumption. Because the specs guarantee that the engine will never receive a Pawn push or capture from the GUI, it could very well be that the author has taken a shortcut in implementing the code that performs the moves to create the current position. E.g. he could simply update the board, but not delete captured pieces from the piece list, creating an inconsistent state that causes illegal moves later. Or when the engine internally uses a different piece code for Pawns on either side of the River, not upgrade the piece while moving.

I didn't say it was a good suggestion.

[Daniel Mehrmann]

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 ?

Well, bear in mind that the starting point for this particular point is the UCCI spec, which states that the GUI should send the position after the last irreversible move, and the moves since that point. My initial suggestion was to simply ignore that, since the only difference it should make is in the number of moves that are sent to the engine.

Well, i was onlytalking about UCI in my last two posts. I wasn't talking about UCCI or USI. This thread might be doing techical stuff, but in this thread http://talkchess.com/forum/viewtopic.ph ... 11&t=54167 you're talking about adding some things. I'm sorry, but i'm to lazy to wrote in both threads.

I don't think it makes any sense to share some information about UCI extension on an official way at this point.

Regards
Daniel