Gothmog 0.4.7 winboard protocol problem?

[Sune Fischer]

Geschrieben von:/Posted by: Sune Fischer at 29 March 2004 16:24:05:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Fabien Letouzey at 29 March 2004 15:29:12:

Not sure if this is a problem, I don't think winboard initializes more than
one engine at a time. Hard to say, usually they initialize so fast I have not
noticed.

IME "engine 2" is initialised "in a hurry" when a game starts.
I have had problems related to that in the past.

If they do get initialized simultaniously they should get about 50% cpu each.
I would think this should be sufficient for winboard to recieve the done command.
-S.

The point again is that it is a race condition. You can never be 100% sure that Winboard is going to receive any feature in time. Therefore each engine should be "protover 1"-compatible as well.
Fabien.

I think WBII was not just an extension of WBI, but also a substitution.
E.g. why would you want to implement both edit and setboard when
edit offers no advantages over setboard?
As I see it, edit was just a "mistake" and this mistake was repaired in
protover 2 by replacing it with setboard.
Same with the "usermove".
If you support protover 1 then the usermove feature is completely obsolete.
So again "usermove" was introduced in protover 2 to repair on a bad design choice of protover 1.
The only point that I can see is that supporting protover 1 is not a requirement.
-S.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 16:32:01:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Sune Fischer at 29 March 2004 16:24:05:

The point again is that it is a race condition. You can never be 100% sure that Winboard is going to receive any feature in time. Therefore each engine should be "protover 1"-compatible as well.

I think WBII was not just an extension of WBI, but also a substitution.
E.g. why would you want to implement both edit and setboard when
edit offers no advantages over setboard?
As I see it, edit was just a "mistake" and this mistake was repaired in
protover 2 by replacing it with setboard.
Same with the "usermove".
If you support protover 1 then the usermove feature is completely obsolete.
So again "usermove" was introduced in protover 2 to repair on a bad design choice of protover 1.
The only point that I can see is that supporting protover 1 is not a requirement.

The way it is designed (timeout for xb1 vs. "feature" for xb2, the substitution cannot be guaranteed).
This is unrelated but I agree with all of it, of course.
I've never implemented edit, and never will.
Unfortunately the "timeout" "mistake" cannot be replaced so easily.
No but as you can see, any engine can break then.
Maybe advanced users will recognise the problem and use a larger timeout at startup, but I wouldn't count on it.
Just to make sure the situation is clear, I agree with all you say about how protover 2 is better; my point is that it's not enough to guarantee that the engine will work, especially as "engine 2".
Look at the log file in the main post of this thread, WinBoard starts sending stuff without receiving anything from "engine 2". There is no way to prevent that from happening from time to time.
My recommendation is to fully implement "protover 2", and add a few lines of code to partly handle the most important "protover 1" feature such as "black/white" and move without "usermove". That's about 10 lines of code and it works when things go wrong.
Fabien.

[Sune Fischer]

Geschrieben von:/Posted by: Sune Fischer at 29 March 2004 16:54:36:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Fabien Letouzey at 29 March 2004 16:32:01:

Unfortunately the "timeout" "mistake" cannot be replaced so easily.

The only point that I can see is that supporting protover 1 is not a requirement.

No but as you can see, any engine can break then.
Maybe advanced users will recognise the problem and use a larger timeout at startup, but I wouldn't count on it.
Just to make sure the situation is clear, I agree with all you say about how protover 2 is better; my point is that it's not enough to guarantee that the engine will work, especially as "engine 2".
Look at the log file in the main post of this thread, WinBoard starts sending stuff without receiving anything from "engine 2". There is no way to prevent that from happening from time to time.
My recommendation is to fully implement "protover 2", and add a few lines of code to partly handle the most important "protover 1" feature such as "black/white" and move without "usermove". That's about 10 lines of code and it works when things go wrong.
Fabien.

The requirement for an engine is to work under all protover X versions where X
is greater than the number it was designed with.
Ie. a protover 1 engine should work in a GUI that does both protocols, but
you cannot expect a protover 2 engine to work in a protover 1 GUI.
Backwards compability is not required of the engine,
that would also defeat most of the innovations in protover 2.
I have never suffered from these problems.
What I do is after getting protover 2 I send done=0 and all the feature flags
and initialize.
Then I send done=1 and starts to read all the stuff winboard has sent.
It may be my done=0 is received by winboard after it has sent white/black, but
since I just ignore white/black it causes no harm.
What you say couldn't hurt, but AFAIK the engine is expected to ignore all
commands it doesn't understand.
By doing this there should be no need to feature disable the white/black commands.
-S.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 17:04:17:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Sune Fischer at 29 March 2004 16:54:36:

Unfortunately the "timeout" "mistake" cannot be replaced so easily.

The only point that I can see is that supporting protover 1 is not a requirement.

No but as you can see, any engine can break then.
Maybe advanced users will recognise the problem and use a larger timeout at startup, but I wouldn't count on it.
Just to make sure the situation is clear, I agree with all you say about how protover 2 is better; my point is that it's not enough to guarantee that the engine will work, especially as "engine 2".
Look at the log file in the main post of this thread, WinBoard starts sending stuff without receiving anything from "engine 2". There is no way to prevent that from happening from time to time.

The requirement for an engine is to work under all protover X versions where X
is greater than the number it was designed with.
Ie. a protover 1 engine should work in a GUI that does both protocols, but
you cannot expect a protover 2 engine to work in a protover 1 GUI.
Backwards compability is not required of the engine,
that would also defeat most of the innovations in protover 2.
I have never suffered from these problems.
What I do is after getting protover 2 I send done=0 and all the feature flags
and initialize.
Then I send done=1 and starts to read all the stuff winboard has sent.

I am talking about how things work in practice, not how they should be in theory. Of course you should be right about compatibility, but that does not work so will with the xboard protocol.
If you want to guarantee that your engine works with Winboard, you have to support the "move without usermove" which is a protover-1 feature.
Look at the log again (advice: read the main post of this thread, then click on "Reply" so that the HTML tag feature does not cripple the log), you will see that engine 2 received "e2e4" although it does send "feature usermove=1". The feature arrived too late; nothing we can do about that.
You are lucky then, hope you stay lucky in the future ...
The problem is not just some fantasy about what could happen, it did happen (again, see the log) and will happen again, sometime, somewhere.
Fabien.

[Sune Fischer]

Geschrieben von:/Posted by: Sune Fischer at 29 March 2004 17:16:33:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Fabien Letouzey at 29 March 2004 17:04:17:

that would also defeat most of the innovations in protover 2.
Then I send done=1 and starts to read all the stuff winboard has sent.

I am talking about how things work in practice, not how they should be in theory. Of course you should be right about compatibility, but that does not work so will with the xboard protocol.
If you want to guarantee that your engine works with Winboard, you have to support the "move without usermove" which is a protover-1 feature.
Look at the log again (advice: read the main post of this thread, then click on "Reply" so that the HTML tag feature does not cripple the log), you will see that engine 2 received "e2e4" although it does send "feature usermove=1". The feature arrived too late; nothing we can do about that.
You are lucky then, hope you stay lucky in the future ...
The problem is not just some fantasy about what could happen, it did happen (again, see the log) and will happen again, sometime, somewhere.
Fabien.

You don't have too.
I've played for years without supporting anything in protocol 1, never had
a problem with it.
The problem must be due to something else.
The first thing I notice is the time, it goes from 600 to 10602.
This means, if I'm not mistaken, that winboard has waited 10 seconds before
it sent new.
Here is my debug for an engine start (you might have to click reply to see it
correctly):
recognized 'normal' (-1) as variant normal
WinBoard 4.2.6 + frenzee
Reset(1, 0) from gameMode 0
recognized 'normal' (-1) as variant normal
GameEnds(0, (null), 2)
StartChildProcess (dir="") code/frenzee
610 >first : xboard
protover 2
641 first : hard
860 >first : easy
860 >first : ping 1
954 first : name Ruleren
1782 >first : time 6000
You see winboard doesn't send anything until I tell it to with done=1.
Winboard waits for 2 seconds, you have 2 seconds to finalize initialization and
send the features or you can send done=0.
This works for me without any problems.
Of course it would be better if winboard waited an hour by default or until it
got done=1, but due to backwards compability with protover 1 this isn't
possible.
-S.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 17:25:13:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Sune Fischer at 29 March 2004 17:16:33:

that would also defeat most of the innovations in protover 2.

I am talking about how things work in practice, not how they should be in theory. Of course you should be right about compatibility, but that does not work so will with the xboard protocol.
If you want to guarantee that your engine works with Winboard, you have to support the "move without usermove" which is a protover-1 feature.
Look at the log again (advice: read the main post of this thread, then click on "Reply" so that the HTML tag feature does not cripple the log), you will see that engine 2 received "e2e4" although it does send "feature usermove=1". The feature arrived too late; nothing we can do about that.

You don't have too.
I've played for years without supporting anything in protocol 1, never had
a problem with it.
The problem must be due to something else.
The first thing I notice is the time, it goes from 600 to 10602.
This means, if I'm not mistaken, that winboard has waited 10 seconds before
it sent new.
Here is my debug for an engine start (you might have to click reply to see it
correctly):
(snipped)
You see winboard doesn't send anything until I tell it to with done=1.

The problem never happens with the first engine, only the second one.
Furthermore, even successfully launching your engine 1000 times in a row does not contradict with the fact that things can sometimes go wrong.
Please prove that the problem can never occur taking the log file that started this thread into account.
Fabien.

[Sune Fischer]

Geschrieben von:/Posted by: Sune Fischer at 29 March 2004 17:33:20:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Fabien Letouzey at 29 March 2004 17:25:13:

that would also defeat most of the innovations in protover 2.

I am talking about how things work in practice, not how they should be in theory. Of course you should be right about compatibility, but that does not work so will with the xboard protocol.
If you want to guarantee that your engine works with Winboard, you have to support the "move without usermove" which is a protover-1 feature.
Look at the log again (advice: read the main post of this thread, then click on "Reply" so that the HTML tag feature does not cripple the log), you will see that engine 2 received "e2e4" although it does send "feature usermove=1". The feature arrived too late; nothing we can do about that.

You don't have too.
I've played for years without supporting anything in protocol 1, never had
a problem with it.
The problem must be due to something else.
The first thing I notice is the time, it goes from 600 to 10602.
This means, if I'm not mistaken, that winboard has waited 10 seconds before
it sent new.
Here is my debug for an engine start (you might have to click reply to see it
correctly):
(snipped)
You see winboard doesn't send anything until I tell it to with done=1.

The problem never happens with the first engine, only the second one.
Furthermore, even successfully launching your engine 1000 times in a row does not contradict with the fact that things can sometimes go wrong.
Please prove that the problem can never occur taking the log file that started this thread into account.
Fabien.

Can you prove the apple will always fall to the ground?
I think empiricly I have proven it is a non-issue because I have not had
this problem in 100000 games.
Theoreticly I cannot guarantee that an engine will not need more than 2
seconds to send a message to winboard.
Unfortunately I think there is no way to solve it without breaking compability
with protover 1.
Let's see if the problem doesn't go away when gothmog sends done=0, it seems
to work for all other engines.
-S.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 17:38:52:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Sune Fischer at 29 March 2004 17:33:20:

that would also defeat most of the innovations in protover 2.

I am talking about how things work in practice, not how they should be in theory. Of course you should be right about compatibility, but that does not work so will with the xboard protocol.
If you want to guarantee that your engine works with Winboard, you have to support the "move without usermove" which is a protover-1 feature.
Look at the log again (advice: read the main post of this thread, then click on "Reply" so that the HTML tag feature does not cripple the log), you will see that engine 2 received "e2e4" although it does send "feature usermove=1". The feature arrived too late; nothing we can do about that.

You don't have too.
I've played for years without supporting anything in protocol 1, never had
a problem with it.
The problem must be due to something else.
The first thing I notice is the time, it goes from 600 to 10602.
This means, if I'm not mistaken, that winboard has waited 10 seconds before
it sent new.
Here is my debug for an engine start (you might have to click reply to see it
correctly):
(snipped)
You see winboard doesn't send anything until I tell it to with done=1.

The problem never happens with the first engine, only the second one.
Furthermore, even successfully launching your engine 1000 times in a row does not contradict with the fact that things can sometimes go wrong.
Please prove that the problem can never occur taking the log file that started this thread into account.
Fabien.

Can you prove the apple will always fall to the ground?
I think empiricly I have proven it is a non-issue because I have not had
this problem in 100000 games.
Theoreticly I cannot guarantee that an engine will not need more than 2
seconds to send a message to winboard.
Unfortunately I think there is no way to solve it without breaking compability
with protover 1.
Let's see if the problem doesn't go away when gothmog sends done=0, it seems
to work for all other engines.
-S.

My way of programming is not based on empirical results.
If a race condition is discovered, I will try to handle it.
The most difficult part is usually to detect the possibility.
I should add that log file to the collection of things that can happen to "engine 2", although I have seen a few already.
Fabien.

[Sune Fischer]

Geschrieben von:/Posted by: Sune Fischer at 29 March 2004 17:45:54:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Fabien Letouzey at 29 March 2004 17:38:52:

that would also defeat most of the innovations in protover 2.

I am talking about how things work in practice, not how they should be in theory. Of course you should be right about compatibility, but that does not work so will with the xboard protocol.
If you want to guarantee that your engine works with Winboard, you have to support the "move without usermove" which is a protover-1 feature.
Look at the log again (advice: read the main post of this thread, then click on "Reply" so that the HTML tag feature does not cripple the log), you will see that engine 2 received "e2e4" although it does send "feature usermove=1". The feature arrived too late; nothing we can do about that.

You don't have too.
I've played for years without supporting anything in protocol 1, never had
a problem with it.
The problem must be due to something else.
The first thing I notice is the time, it goes from 600 to 10602.
This means, if I'm not mistaken, that winboard has waited 10 seconds before
it sent new.
Here is my debug for an engine start (you might have to click reply to see it
correctly):
(snipped)
You see winboard doesn't send anything until I tell it to with done=1.

The problem never happens with the first engine, only the second one.
Furthermore, even successfully launching your engine 1000 times in a row does not contradict with the fact that things can sometimes go wrong.
Please prove that the problem can never occur taking the log file that started this thread into account.
Fabien.

Can you prove the apple will always fall to the ground?
I think empiricly I have proven it is a non-issue because I have not had
this problem in 100000 games.
Theoreticly I cannot guarantee that an engine will not need more than 2
seconds to send a message to winboard.
Unfortunately I think there is no way to solve it without breaking compability
with protover 1.
Let's see if the problem doesn't go away when gothmog sends done=0, it seems
to work for all other engines.
-S.

My way of programming is not based on empirical results.
If a race condition is discovered, I will try to handle it.
The most difficult part is usually to detect the possibility.
I should add that log file to the collection of things that can happen to "engine 2", although I have seen a few already.
Fabien.

The 2 second time-out is there to handle the race condition.
Just remember to send done=0 before you do the initialization and you will
have 1.999 seconds to spare.
I don't know what you mean by that.
What else can happen to engine 2?
-S.

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 29 March 2004 17:53:37:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Sune Fischer at 29 March 2004 17:45:54:

that would also defeat most of the innovations in protover 2.

I am talking about how things work in practice, not how they should be in theory. Of course you should be right about compatibility, but that does not work so will with the xboard protocol.
If you want to guarantee that your engine works with Winboard, you have to support the "move without usermove" which is a protover-1 feature.
Look at the log again (advice: read the main post of this thread, then click on "Reply" so that the HTML tag feature does not cripple the log), you will see that engine 2 received "e2e4" although it does send "feature usermove=1". The feature arrived too late; nothing we can do about that.

You don't have too.
I've played for years without supporting anything in protocol 1, never had
a problem with it.
The problem must be due to something else.
The first thing I notice is the time, it goes from 600 to 10602.
This means, if I'm not mistaken, that winboard has waited 10 seconds before
it sent new.
Here is my debug for an engine start (you might have to click reply to see it
correctly):
(snipped)
You see winboard doesn't send anything until I tell it to with done=1.

The problem never happens with the first engine, only the second one.
Furthermore, even successfully launching your engine 1000 times in a row does not contradict with the fact that things can sometimes go wrong.
Please prove that the problem can never occur taking the log file that started this thread into account.
Fabien.

Can you prove the apple will always fall to the ground?
I think empiricly I have proven it is a non-issue because I have not had
this problem in 100000 games.
Theoreticly I cannot guarantee that an engine will not need more than 2
seconds to send a message to winboard.
Unfortunately I think there is no way to solve it without breaking compability
with protover 1.
Let's see if the problem doesn't go away when gothmog sends done=0, it seems
to work for all other engines.
-S.

My way of programming is not based on empirical results.
If a race condition is discovered, I will try to handle it.
The most difficult part is usually to detect the possibility.
I should add that log file to the collection of things that can happen to "engine 2", although I have seen a few already.

The 2 second time-out is there to handle the race condition.
Just remember to send done=0 before you do the initialization and you will
have 1.999 seconds to spare.
I don't know what you mean by that.
What else can happen to engine 2?

It appears that I don't have those logs anymore, as I had too many of them.
They don't worry me as long as PolyGlot handles them.
Fabien.

[Dieter Bürßner]

Geschrieben von:/Posted by: Dieter Bürßner at 29 March 2004 20:50:49:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Fabien Letouzey at 29 March 2004 15:26:13:

Absolutely. Also the requirement to never stop the search in infinite or ponder mode makes the engine more complex than necessary; this should be a "GUI" problem.

I thought the same, when I was implementing UCI. However, if this were a GUI task, one would need to carefully think about new possible complications, possibly even races. Engine in infinite Analysis, and stops by itself (and sends bestmove). Just at the same time GUI sends stop. Engines sees stop, while it is not searching, and is confused ...
The complication of the engine seems small to me (at least for an engine, without a seperate search thread). Just doing a "busy read" (instead of polling) when it wants to finish search will be enough.
BTW. I think some of the disadvantages mentioned about the UCI-protocol will be fixed soon.
I implemented both, xboard and UCI. Both work. I would guess, for a basic start of an engine, UCI will be much easier to implement. There is no need to think of different modes (search, analyse, force), etc. It makes the "main loop" of the engine much easier. Think of all the special cases in Xboard - as white, you have to wait for go, as black not. setboard, new and moves are allowed in analyse mode, and complicate handling of the engine. It is not clear, which commands are allowed during search/ponder. Tim Mann says all. But the exact action to be taken might not always be easy to get. I remember, I had even after 2 years or so a bug, when processing "result" while pondering. IIRC, there was a subtle difference in Xboard and Winboard, and under Xboard I had to switch to force mode implicetly. Jon Dart reported a similar problem for Arasan, not too long ago (and Arasan was one of the first Xboard engines). So, it is at least not trivial. IIRC even Sune had quite some problems at the start (didn't he have the problem with the go assymetry for black/white, too).
No doubt, currently learning is more difficult under UCI. Implementation of pondering should be much easier, when the engine wants to do it in a normal way (no need to be able to parse moves during search, which may need, that you have rememberd the board at the start of the search). But more creative pondering methods may be difficult/impossible.
All in all I think, implementing UCI from scratch should be significantly easier/faster, than implementing Winboard from scratch. Especially when the goal is to reach a reliable and bugfree implementation. But, for example I never figured out, how to run the engine under a GUI inside a debugger. Is it possible? I find it useful, to have a "console mode", especially for debugging. Such a console mode will naturally be very similar (or identical) to Xboard. So many engines might want to have such a mode anyway. Or there are of course very good other reasons to support Winboard (for example, I do almost all testing under WB, it has a very reliable and stable interface to the ICSes, etc.)

[Sune Fischer]

Geschrieben von:/Posted by: Sune Fischer at 29 March 2004 21:20:33:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Dieter Bürßner at 29 March 2004 20:50:49:

Absolutely. Also the requirement to never stop the search in infinite or ponder mode makes the engine more complex than necessary; this should be a "GUI" problem.

I thought the same, when I was implementing UCI. However, if this were a GUI task, one would need to carefully think about new possible complications, possibly even races. Engine in infinite Analysis, and stops by itself (and sends bestmove). Just at the same time GUI sends stop. Engines sees stop, while it is not searching, and is confused ...
The complication of the engine seems small to me (at least for an engine, without a seperate search thread). Just doing a "busy read" (instead of polling) when it wants to finish search will be enough.
BTW. I think some of the disadvantages mentioned about the UCI-protocol will be fixed soon.
I implemented both, xboard and UCI. Both work. I would guess, for a basic start of an engine, UCI will be much easier to implement. There is no need to think of different modes (search, analyse, force), etc. It makes the "main loop" of the engine much easier. Think of all the special cases in Xboard - as white, you have to wait for go, as black not.
setboard, new and moves are allowed in analyse mode, and complicate handling of the engine.
It is not clear, which commands are allowed during search/ponder. Tim Mann says all. But the exact action to be taken might not always be easy to get. I remember, I had even after 2 years or so a bug, when processing "result" while pondering. IIRC, there was a subtle difference in Xboard and Winboard, and under Xboard I had to switch to force mode implicetly. Jon Dart reported a similar problem for Arasan, not too long ago (and Arasan was one of the first Xboard engines).
So, it is at least not trivial. IIRC even Sune had quite some problems at the start (didn't he have the problem with the go assymetry for black/white, too).
No doubt, currently learning is more difficult under UCI. Implementation of pondering should be much easier, when the engine wants to do it in a normal way (no need to be able to parse moves during search, which may need, that you have rememberd the board at the start of the search). But more creative pondering methods may be difficult/impossible.
All in all I think, implementing UCI from scratch should be significantly easier/faster, than implementing Winboard from scratch. Especially when the goal is to reach a reliable and bugfree implementation.
But, for example I never figured out, how to run the engine under a GUI inside a debugger. Is it possible? I find it useful, to have a "console mode", especially for debugging. Such a console mode will naturally be very similar (or identical) to Xboard. So many engines might want to have such a mode anyway. Or there are of course very good other reasons to support Winboard (for example, I do almost all testing under WB, it has a very reliable and stable interface to the ICSes, etc.)

This is not so difficult even with threads.
What I do is to check for live search threads, if there are any I set their kill flags and wait for them to die.
So there will be a new version of UCI soon?
After setting up a position you just set the engine to be the other side to move.
It's not color specific IIRC.
With setboard and new you have to make sure the search is dead, ie. I call StopThreads(). I would do the same even if I only had UCI, just to be on the
safe side.
Making a move in analysis is a pain, IMO, but can be solved.
I do it by dropping out of search to make the root move and return to search.
It would be nice if winboard could simulate this for you by sending exit,usermove,analyze. But it can also be simulated by the engine.
I think I do the same when getting result, first StopThreads() and then
GameEnd().
Of course it is not always easy to think of all these things that can "go wrong" but they get patched little by little as they are found.
I don't remember the specifics, but I had lots of problems
I agree UCI is easier, but easier is does not always equal better
And that is probably one of the most important reasons to have WB support
-S.

[Dieter Bürßner]

Geschrieben von:/Posted by: Dieter Bürßner at 30 March 2004 00:13:11:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Sune Fischer at 29 March 2004 21:20:33:

Absolutely. Also the requirement to never stop the search in infinite or ponder mode makes the engine more complex than necessary; this should be a "GUI" problem.

I thought the same, when I was implementing UCI. However, if this were a GUI task, one would need to carefully think about new possible complications, possibly even races. Engine in infinite Analysis, and stops by itself (and sends bestmove). Just at the same time GUI sends stop. Engines sees stop, while it is not searching, and is confused ...
The complication of the engine seems small to me (at least for an engine, without a seperate search thread). Just doing a "busy read" (instead of polling) when it wants to finish search will be enough.

This is not so difficult even with threads.
What I do is to check for live search threads, if there are any I set their kill flags and wait for them to die.
So there will be a new version of UCI soon?
After setting up a position you just set the engine to be the other side to move.
It's not color specific IIRC.
Making a move in analysis is a pain, IMO, but can be solved.
I do it by dropping out of search to make the root move and return to search.
It would be nice if winboard could simulate this for you by sending exit,usermove,analyze. But it can also be simulated by the engine.
Of course it is not always easy to think of all these things that can "go wrong" but they get patched little by little as they are found.
I agree UCI is easier, but easier is does not always equal better

Sure, it should also be easy with threads. What I would fear, is the possibility of some races under rare circumstances, when one doesn't think of the problem properly (but I really cannot judge it)
It seems likely.
Well, depends how you see it. It is somewhat assymetric. One color needs a go, the other not (and I am almost sure, I remember various engine bugs discussed in this forum, that seemed to be because of such an assymetry).
BTW. I think a WB like protocol, that always defaults to force mode would be better/easier to implement. For non ponder games, every search would be started with go.
Yes. And there is really no need, to have such comlication in the protocol. exit should be the only command allowed during analyse. Everything else can be done with other means (already existing in the protocol). Of course, typing in moves in console mode while analyzing would be more convenient, than exit, ...
But any engine that wants this, could do it anyway. I would see no problem at the moment, when protover 3 only allowed exit in analyze mode.
Similarly, coming back to a thought of Fabien: Just do not clear HTs ever (unless really told so, by another command, like the suggested reset). Undoing moves would be easy for analyze: exit new force movelist (and GUI will handle the undo). Several engines had (have) bugs with undo. Every engine must handle it, instead of only the GUI.
I don't like this method. I think, it should be easier (by more constricted/better documented protocol). Of course, most engines will work well under WB under normal circumstances. How about pressing move now at several stages of the search? Takebacks, things that just not happen in a normal engine match? Perhaps another GUI does it slightly different ... Also, think of some discussions about level during the game (many GUIs really want to give more time controls, than WB/XB do).
I did not want to emphasize (or even say) which is better. I think, I mainly mentioned critics for both ...
Regards,
Dieter

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 30 March 2004 10:41:37:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Dieter B�r�ner at 29 March 2004 20:50:49:

Absolutely. Also the requirement to never stop the search in infinite or ponder mode makes the engine more complex than necessary; this should be a "GUI"

I thought the same, when I was implementing UCI. However, if this were a GUI task, one would need to carefully think about new possible complications, possibly even races. Engine in infinite Analysis, and stops by itself (and sends bestmove). Just at the same time GUI sends stop. Engines sees stop, while it is not searching, and is confused ...

problem.
I don't understand. IMO engines must be ready to receive stop anytime. What if the game ends while the engine is thinking on its move? The GUI has to send a "stop" then, and the engine might already have answered.
My point was about special code in the engine to *not* send a move in special cases. In Fruit I have a "sent" flag, with dirty tests at think two places. Gothmog loops forever at depth 60. I guess each engine has a special trick to deal with that problem.
Fabien.

[Dieter Bürßner]

Geschrieben von:/Posted by: Dieter Bürßner at 30 March 2004 20:01:33:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Fabien Letouzey at 30 March 2004 10:41:37:

I don't understand. IMO engines must be ready to receive stop anytime. What if the game ends while the engine is thinking on its move? The GUI has to send a "stop" then, and the engine might already have answered.
My point was about special code in the engine to *not* send a move in special cases. In Fruit I have a "sent" flag, with dirty tests at think two places. Gothmog loops forever at depth 60. I guess each engine has a special trick to deal with that problem.

I agree, and stand corrected. I don't see a problem anymore, if the GUI would handle this (engine exits early from a search in infinite analysis or pondering). The engine would also need to prepared to receive "ponderhit" outside of the search (and simply ignore it).
Yes.
Regards,
Dieter

[Fabien Letouzey]

Geschrieben von:/Posted by: Fabien Letouzey at 31 March 2004 18:45:32:
Als Antwort auf:/In reply to: Re: Gothmog 0.4.7 winboard protocol problem? geschrieben von:/posted by: Dieter B�r�ner at 30 March 2004 20:01:33:

I don't understand. IMO engines must be ready to receive stop anytime. What if the game ends while the engine is thinking on its move? The GUI has to send a "stop" then, and the engine might already have answered.

I agree, and stand corrected. I don't see a problem anymore, if the GUI would handle this (engine exits early from a search in infinite analysis or pondering). The engine would also need to prepared to receive "ponderhit" outside of the search (and simply ignore it).

Yes, that's an argument. With UCI as it stands, the engine can receive "stop" anytime but not "ponderhit" right?
Fabien.

[Dieter Bürßner]

Geschrieben von:/Posted by: Dieter Bürßner at 01 April 2004 23:30:42:
Als Antwort auf:/In reply to: Re: UCI geschrieben von:/posted by: Fabien Letouzey at 31 March 2004 18:45:32:

Yes, that's an argument. With UCI as it stands, the engine can receive "stop" anytime but not "ponderhit" right?

It is better explained in the update of the UCI-protocol which just appeared http://www.shredderchess.de/uci.zip
--
* if the engine or the GUI receives an unknown command or token it should just i
gnore it and try to
parse the rest of the string.
* if the engine receives a command which is not supposed to come, for example "s
top" when the engine is
not calculating, it should also just ignore it.
--
So, this will also include ponderhit.
Regards,
Dieter