Reborn Compile DevC++ but misses GUI commands,works by hand

[markchessman]

Hi I have released Reborn Engine that works but is slow, I have created a DevC++ compile that runs by hand but the program misses the GUI commands. can somebody suggest what may be happening?

I have put the devc source online, its just cpp file no exe file, PM me if you want the exe ? http://www.filedropper.com/reborndevcppnoguiworking

[Daniel White]

Hi I have released Reborn Engine that works but is slow, I have created a DevC++ compile that runs by hand but the program misses the GUI commands. can somebody suggest what may be happening?

I have put the devc source online, its just cpp file no exe file, PM me if you want the exe ? http://www.filedropper.com/reborndevcppnoguiworking

It may be that the GUI is not actually receiving your commands and hence isn't sending back what you would expect. This can be because you are not flushing your output. Terminals usually do this for you which could explain why it works 'by hand' but not with a GUI.

[markchessman]

Hi Daniel, I think Im fflush(stdin) & fflush(stdout) every time needed, and the engine works when I compile with borland. Im trying to get it running faster on devC

where would you fflush?

[kbhearn]

you shouldn't be using fflush(stdin); its operation is undefined, it may throw away pending input. (stdout should be flushed every time you write something though).

[markchessman]

That sounds like what could be the problem Kevin thanks & thanks Daniel.

[Daniel White]

Hi Daniel, I think Im fflush(stdin) & fflush(stdout) every time needed, and the engine works when I compile with borland. Im trying to get it running faster on devC

where would you fflush?

While fflush(stdout) is perfectly fine this might be of interest to you:

Code: Select all

setvbuf(stdout, NULL, _IOLBF, 0);

Simply call this on startup to ensure everything is flushed automatically. Could save you some trouble if you forget an fflush call. This works in C, if it doesn't work in C++ I'm sure there will be something similar.

[markchessman]

thanks Daniel

[Sven]

Hi Daniel, I think Im fflush(stdin) & fflush(stdout) every time needed, and the engine works when I compile with borland. Im trying to get it running faster on devC

where would you fflush?

While fflush(stdout) is perfectly fine this might be of interest to you:

Code: Select all

setvbuf(stdout, NULL, _IOLBF, 0);

Simply call this on startup to ensure everything is flushed automatically. Could save you some trouble if you forget an fflush call. This works in C, if it doesn't work in C++ I'm sure there will be something similar.

It also works in C++, although Mark's program is C (which does not make a difference for the compiler unless you force him to compile the source as C source).

But I think the important part is to switch off INPUT buffering, e.g. by

Code: Select all

setvbuf(stdin, NUL, _IONBF, 0);

at program startup, since otherwise the engine will not receive GUI commands immediately (as it should) but only when the input buffer is filled. This is also in line with Mark's description of his symptoms.

The other earlier comment about avoiding "fflush(stdin)" is correct of course.

@Mark:
1) Please fix line 7930 in Re136.cpp (function alphabeta4()): "if(sd[0] == 2) sd[0] == 0;".

2) Please change all functions with return type "int" but not actually returning a value into return type "void".

3) There are hundreds of places where you use the bitwise "&" operator when the logical "&&" operator would be needed. This can really become a pain as soon as you have an expression like the following, for instance:

Code: Select all

int x;
int y = 2;
// code setting x ...
if ((x > 0) & y) ... // WRONG! Always evaluates to 0

I hope you see the difference!

Even when perfectly avoiding arguments for "&" different from 0 and 1, there is absolutely NO good reason to use "&" instead of "&&" for a logical operation unless you are fighting for the top 3 of the world and need every single ELO point that you can get through speed optimization, and you know perfectly what you are doing - and even then I would not do it since it is a bad and error-prone programming style!

4) Please make your program readable

Sven

[markchessman]

thanks, I can say my program is getting better thanks to theses posts. thanks too sven for your wise info, I will consider it well.

[hgm]

But I think the important part is to switch off INPUT buffering, e.g. by

Code: Select all

setvbuf(stdin, NUL, _IONBF, 0);

at program startup, since otherwise the engine will not receive GUI commands immediately (as it should) but only when the input buffer is filled.

Uh?

None of my engines or adapters has ever done anything like that. (I did not even know this was possible.) So I don't think what you say can be true, for it would certainly prevent them from working.

My experience is that when you issue a read call and there is input, you will get the input. Both from console and pipes.

There is another problem that puzzles me, though. It seems that sometimes the methods to check for pending input (e.g. to decide if you should abort pondering) fail to see the input. In particular this happens when you resume pondering after receiving a time or otim command. You will then never become aware that the opponent has moved.

The time, otim and usermove are all sent by the GUI at the same time (though in different write calls). So what seems to happen is that as soon as you start reading in response to the arrival of 'time', all pending input (including the 'usermove') is read and put into a buffer in the engine. And that the PeekNamedPipe command for checking if there is input only looks at the pipe, and not if there still is stuff left over in the buffer from a previous pipe read.

Perhaps switching of stdin buffering in the way you mention would prevent this. I currently prevent this by skipping ponder code after reception of time and otim. But the preferred way of solving it would be to check if the buffer is empty. Not buffering really makes for very inefficient I/O code.