What should I support, UCI or Winboard?

[hgm]

...did you try this?".

Come on, if i would say i tried that you'll wanna see a prove of course. It's more or less the same. Even if i would show you a proof you wouldn't accept it anyway.


I don't need to answer the rest of your post, because I never wrote it exactly like your summing-up.


Once again: Why should i spend any time of your stuff ? Ok, if you pay me, we can talk about it.

And again: This thread blows up - Your target ?

Well, that certainly is all guessing, (although a by nature less friendly person than I might consider it vicious bad-mouthing... ) and shows that you are extremely poor at it...

And what is this silly notion about "my stuff"? Someone is asking for help, and I am trying to give him some useful advice.

OK, so you are only prepared to give 'help' if you are payed. We took note of that. So you can butt out now.

[Rebel]

HGM, as Miguel already pointed out the documentation is Winboard's Achilles heel. If you make a quick_guide for starting programmers with the absolute minimum of code (plus some example code) to get the basic things started within a couple of hours (or one day) then you would be winning many starting souls. My engine is WB and the documentation back then (2003) was a royal pain. It still is.

Keep up the good work.

[jdart]

The problem with Winboard pondering is that you have to monitor incoming commands both when pondering and when not, and some of them need different processing depending on what state you are in, and there are cases where just processing them one at a time in order is not correct. For example, what if you get a user move that happens to be a ponder hit, but then the opponent immediately resigns (or quits)? You have to handle this regardless of when "result" arrives. If you ponder, move, then process "result," that is not correct, because "result" must always end the game.

UCI IMO has a simpler state model. You can look at Fruit's implementation, which is practically the reference one. It is not a lot of code.

--Jon

[hgm]

HGM, as Miguel already pointed out the documentation is Winboard's Achilles heel. If you make a quick_guide for starting programmers with the absolute minimum of code (plus some example code) to get the basic things started within a couple of hours (or one day) then you would be winning many starting souls.

Well, this was basically what the description here was supposed to be.But I guess I will have t work on it some more.

[hgm]

The problem with Winboard pondering is that you have to monitor incoming commands both when pondering and when not, and some of them need different processing depending on what state you are in, and there are cases where just processing them one at a time in order is not correct.

Yes, but that is in the engine. So not very relevant for someone like the OP, who is only interested in building a GUI...

For example, what if you get a user move that happens to be a ponder hit, but then the opponent immediately resigns (or quits)? You have to handle this regardless of when "result" arrives. If you ponder, move, then process "result," that is not correct, because "result" must always end the game.

I don't see the latter as an incorrect implementation of WB protocol. I also don't see this problem as specific to pondering: in a ponder-off game, it can also happen that you get a move that starts you thinking, and immediately after it the 'result' because of opponent resign. The question is if you expect instant response from commands send during search. This might have been the original intention of WB protocol, but I think it has long since bowed to the reality that almost every engine will 'move first, ask questions later'. So 'ping' was introduced to solve all problems that could result from this.

The problem really is that engines that want to resign send a move before they do. This is reproachable behavior, that perhaps should be more explicitly condemned in the protocol specs.

UCI IMO has a simpler state model. You can look at Fruit's implementation, which is practically the reference one. It is not a lot of code.

Well, the model WB driver I gave the link to in the previous post does not strike me as terribly long or complex either.

[Christopher Conkie]

if I were an esper that could read other peoples mind (which I cannot).......

........You would support both?

Alas we cannot have everything.......



Chris

[hgm]

Both?

I support all four! So people can actually have truly everything.

But of course I wouldn't expect you to know. No need to be an esper for that...

Btw, have you already done the test which GUI has better performance in UCI support, WinBoard or Arena, using my GUI- timing toolkit?

[Christopher Conkie]

Please, implement both.
WB protocoll is more better, but UCI are implemented in ChessBase gui, seems that this are the important for much people here.

Smart comment. We cannot be sure. Both do the same thing......in different ways and to different degrees.

No. dont do the same. An engine of UCI its not a complete engine. Its gui dependant.
Under winboard you have ALL with o without a gui..i imagine that a programer dont want to develop an engine "under the orders" of a "board"

Both are interfaces. They both facilitate the communication between engine and GUI, hence why I said they are both the same. I think that the problem here is less about the specific protocol but more about adaptability. If you have to use an adapter to make something work is that being "adaptable", user friendly? One could integrate both protocols into the GUI and remove from the user the pain in ass that is configuration. That is what Arena does.

You know the problem with Winboard is that it is called Winboard and they cannot see past the end of their noses. They (but who are they) should integrate UCI into it and rename it "Winbuci". They should show some understanding of how it feels to be an end user and not require some degree in configuration of a GUI to play a game of bloody chess.

I don't know about you but for us user friendly is the best way to encourage as many people as possible to play chess.

We at Arena are quite happy that any engine that uses Winboard 1/2, UCI will be easily usable to someone who wants to just play chess.

That is why our website is called......

playwitharena

It is not called "Win"board or any other such nonsense. There are no winners if you don't get to play chess.

Chris

[hgm]

Nice little fantasy. But of course those that actually know what they are talking about, because they have seen WinBoard, rather than just fabricate nonsense about it, know that it is actually easier to install and configure a UCI engine in WinBoard than in Arena. And, more importantly, that it then actually works, rather than suffering random time losses when you start to push the TC a little...

Btw, did you know that 'arena' means 'sand' in Latin? A very apt name, considering how you guys like to stick your head in it!

[Christopher Conkie]

Nice little fantasy. But of course those that actually know what they are talking about, because they have seen WinBoard, rather than just fabricate nonsense about it, know that it is actually easier to install and configure a UCI engine in WinBoard than in Arena. And, more importantly, that it then actually works, rather than suffering random time losses when you start to push the TC a little...

You walk around with your eyes shut? Please explain how setting up Polyglot is easier than using a GUI that understands UCI already.

The only fantasy that is apparent is the one that assumes that the proper integration of UCI into a GUI is less important than the implementation of say for example Xiangqi......

Winboard_F is a good name Harm. You can guess what the F stands for......



Chris