What should I support, UCI or Winboard?

[Michel]

but imagine the same protocol needing to have a way to say, "take back 2 moves to get to the same side's turn"

This is the "remove" command in the winboard protocol.

I don't like the undo/remove commands either. I think their effect on the protocol state is complicated to specify.

[Daniel Mehrmann]

Of course no Java rewrite is needed. The adapter runs as an independent process,like the engine.

And we're talking about a cellphone.

Basicly the concept of Android design patterns are not "independent" processes inside a app for some importent (security) reasons. Of course it's possible to run native processes, but in this case it's crazy.

Your plan looks like this:

GUI (Java) -> Polyglot (native unix) -> engine (native unix)

Your modell has no guarantee that the phone might work if it's get a call for example. Specialy the CPU workload might be to high and that's definely a "no go" on a phone.

BTW: GUI (Java) -> engine (native unix) is acceptable of course (but not recommended).

[hgm]

Your plan looks like this:

GUI (Java) -> Polyglot (native unix) -> engine (native unix)

Your modell has no guarantee that the phone might work if it's get a call for example. Specialy the CPU workload might be to high and that's definely a "no go" on a phone.

That does not look like a valid argument at all. For one, whether the engine communicates directly with the GUI, or through a chain of 20 adapters, it will always be the engine that soaks up 99% of the CPU time. Time used by an adapter is totally negligible. And besides, the adapter is only doing things that either the engine or the GUI would have to do otherwise. If a UCI engine is spamming the adapter with info strings, so that it starts to become a significant load to parse and reject them, it does not make the slightest difference whether the GUI of the adapter would have to do that.

BTW: GUI (Java) -> engine (native unix) is acceptable of course (but not recommended).

[Daniel Mehrmann]

That does not look like a valid argument at all.

In fact my argument is one of most importent arguments. You still ignore how android works and that we're talking about a phone and not your home system.

However, it seems to be that no argument will change your mind. (btw that's the main reason why i'm retired from X-/Winboard project and never come back)

Let's end the story here.

Google is smart enough and so does the people... let every one search...

[hgm]

Yet I would be very easily convinced by fact. Have you actually tried this, or is this just uninformed guessing? I must admit that mere guessing never seemed very convincing to me...

[Daniel Mehrmann]

Yet I would be very easily convinced by fact. Have you actually tried this, or is this just uninformed guessing? I must admit that mere guessing never seemed very convincing to me...

Hey, ok, not my last post...
Well, that's gonna be funny. Let's gamble a little bit...

Why should i proof that your idea doesn't work ? I told you that i disagree at all. So, it's on you to proof that it works (your idea - your proof).

I'll give you four weeks and waiting for your results.

Guessing ? Well, just once more: Use Google (maybe add my name, android and chess as keywords)

[hgm]

but imagine the same protocol needing to have a way to say, "take back 2 moves to get to the same side's turn"

This is the "remove" command in the winboard protocol.

I don't like the undo/remove commands either. I think their effect on the protocol state is complicated to specify.

The 'undo' and 'remove' commands are a legacy of GNU Chess, and understandable from the fact that for GNU Chess the user interface was the raw protocol. So verbosity was an extremely undesirable trade, as the user would be expected to type each and every command by hand.

So having to type 'go' after every move to get a reply was (justly) deemed highly undesirable. (Although I think typing an empty line, as I do in native 'micro-Max protocol', would be bearable.) Hence the fact that WB protocol always uses 'auto-go' (= non-force) mode. And that again makes simply giving two 'undo' commands in a row to retract the last move impossible, because after the first 'undo' it wuld again be the engine's turn, and it would spontaneously redo the move. So you would have to type something like "force; undo; undo; usermove XXXX; go", and I can imagine why the designers thought that "remove" was more user friendly...

For use as a communication protocol between automated entities such arguments of course no longer play a role. I think it would indeed be highly preferable if GUIs would implement a user takeback by simply resending the game, starting with 'new' (or 'setboard'). Problem is that for many existing engines 'new' could cause hash-table clearing, or even require a complete relaunching of the engine process (for reuse=0 engines). Which I think would still be acceptable after takeback in a human-engine game, but would be very undesirable for stepping through a game / variation tree during analysis.

How about adding an "undo=0" feature to the protocol? Which engines could use to indicate they don't support undo / remove (which we would then label 'deprecated'), and let the GUI simply resend the game (new; force; usermove MOVE1; ....; usermove MOVEN; playother;) in case the user requests an 'undo'? It would then be the responsibility of the engine to make sure it does not erase its hash table during such reloading.

As I already wrote above, this is exactly the way how I implement 'undo' now in my engines. Just keep a record of all moves played or entered, and stuff that list (appropriately clipped) back into the input buffer when the engine receives 'undo'/'remove'. We might as well have the GUI do it for us...

[hgm]

Why should i proof that your idea doesn't work ?

Were did you even get the idea that you were asked to prove anything? I asked you a simple question: "did you try this?".

If you want to be un-helpful, well, be un-helpful... I am not the one building the Android app. I would advice anyone to which it matters to take the statement that "a task that once every few seconds would consume a few micro-seconds of CPU time, running on a Linux kernel, would overload the system so much that your phone no longer would ring" with a respectable grain of salt. Especially since it is a bit suspect that you did not answer my question with a simple "yes, I tried that"...

[Evert]

How about adding an "undo=0" feature to the protocol? Which engines could use to indicate they don't support undo / remove (which we would then label 'deprecated'), and let the GUI simply resend the game (new; force; usermove MOVE1; ....; usermove MOVEN; playother;) in case the user requests an 'undo'? It would then be the responsibility of the engine to make sure it does not erase its hash table during such reloading.

I fail to see how this is in any way easier than a "takeback" command - especially considering that "takeback"/"unmake"/"undo" (whatever you call it) is a function that already exists in the engine because the search uses it all the time. Jazz (and Sjaak) simply call "takeback()" once when they receive "undo" and twice when they receive "remove".
UCI resending the movelist is actually one of the things I dislike about the protocol: I need extra code to make sure that I don't trash the hash table/killer lists/other information I might have stored and it isn't a smooth fit to the way Jazz works.

All of this of course depends on how the engine is designed and works internally.

As I already wrote above, this is exactly the way how I implement 'undo' now in my engines. Just keep a record of all moves played or entered, and stuff that list (appropriately clipped) back into the input buffer when the engine receives 'undo'/'remove'. We might as well have the GUI do it for us...

Sounds horribly convoluted to me...

[Daniel Mehrmann]

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