Doubt about engine initialization

[Kempelen]

Talking with a forum colleage, I saw I was initializing the engine incorrectly. I have implemented xboard (the first as default) and recently uci protocol, and now I have a couple of doubts.

At start up I allocate memory for hash tt size and pawn hash tt size. It take maybe one second or two, but EGBB take nearly 3 to 5 seconds. This colleage told me that I have not to load EGBB in inizialization, so if I return by xboard protocol a 'ready' and only them start egbb, what about if a call to uci is done? then, as the egbb is initializin it is possible that uci dont load at all.

What is the propertly way of load and initialize things?

[bob]

Talking with a forum colleage, I saw I was initializing the engine incorrectly. I have implemented xboard (the first as default) and recently uci protocol, and now I have a couple of doubts.

At start up I allocate memory for hash tt size and pawn hash tt size. It take maybe one second or two, but EGBB take nearly 3 to 5 seconds. This colleage told me that I have not to load EGBB in inizialization, so if I return by xboard protocol a 'ready' and only them start egbb, what about if a call to uci is done? then, as the egbb is initializin it is possible that uci dont load at all.

What is the propertly way of load and initialize things?

xboard handles this just fine.

When you start execution, send "done=0" to xboard. This tells it you are not yet ready to play a game. Now initialize everything including EGTB stuff. When you are finished with that, send "done=1" to xboard and it will recognize that you are now ready to play a game or accept commands.

You can take as long as you want between sending done=0 and done=1.

[Kempelen]

Talking with a forum colleage, I saw I was initializing the engine incorrectly. I have implemented xboard (the first as default) and recently uci protocol, and now I have a couple of doubts.

At start up I allocate memory for hash tt size and pawn hash tt size. It take maybe one second or two, but EGBB take nearly 3 to 5 seconds. This colleage told me that I have not to load EGBB in inizialization, so if I return by xboard protocol a 'ready' and only them start egbb, what about if a call to uci is done? then, as the egbb is initializin it is possible that uci dont load at all.

What is the propertly way of load and initialize things?

xboard handles this just fine.

When you start execution, send "done=0" to xboard. This tells it you are not yet ready to play a game. Now initialize everything including EGTB stuff. When you are finished with that, send "done=1" to xboard and it will recognize that you are now ready to play a game or accept commands.

You can take as long as you want between sending done=0 and done=1.

Ok this is just fine, but the problem seem to be when I am under a uci protocol. As my engine is primary xboard as default, it takes long to start up even with done=0, but the uci gui dont understand of xboard and it see the engine is not responding correctly. The critic question is how can I start the engine in uci if I take long time to start up before the uci command is received under xboard?

[bob]

Talking with a forum colleage, I saw I was initializing the engine incorrectly. I have implemented xboard (the first as default) and recently uci protocol, and now I have a couple of doubts.

At start up I allocate memory for hash tt size and pawn hash tt size. It take maybe one second or two, but EGBB take nearly 3 to 5 seconds. This colleage told me that I have not to load EGBB in inizialization, so if I return by xboard protocol a 'ready' and only them start egbb, what about if a call to uci is done? then, as the egbb is initializin it is possible that uci dont load at all.

What is the propertly way of load and initialize things?

xboard handles this just fine.

When you start execution, send "done=0" to xboard. This tells it you are not yet ready to play a game. Now initialize everything including EGTB stuff. When you are finished with that, send "done=1" to xboard and it will recognize that you are now ready to play a game or accept commands.

You can take as long as you want between sending done=0 and done=1.

Ok this is just fine, but the problem seem to be when I am under a uci protocol. As my engine is primary xboard as default, it takes long to start up even with done=0, but the uci gui dont understand of xboard and it see the engine is not responding correctly. The critic question is how can I start the engine in uci if I take long time to start up before the uci command is received under xboard?

There you will have to ask a UCI expert. That's definitely not me.

[Desperado]

Hello Fermin,

uci: gui sends "uci"

now...

Code: Select all

	 if(!strcmp(c,"uci"))
		{
		 globalUci->uciIsOk = true;

		 comSend(engineInfo());
		 comSend("id author Michael Hoffmann");
		 uciSendOptions();
		 comSend("uciok");
		}

After this is done, you can do initilization for a week if you want .

if you dont response the uci request (immediatelly, or let s say simply too late), the engine may not be loaded.


Now, i dont know Wb-Protocol, but as Robert mentioned with done=0
you also have all time of the world.

A check uci request - > send uciok
B wb set done to 0
C initialize engine (hashtables,bitbases...)
D use the ptc available or which you prefer

you may order B,A,C,D if necessary.

[Kempelen]

Hello Fermin,

uci: gui sends "uci"

now...

Code: Select all

	 if(!strcmp(c,"uci"))
		{
		 globalUci->uciIsOk = true;

		 comSend(engineInfo());
		 comSend("id author Michael Hoffmann");
		 uciSendOptions();
		 comSend("uciok");
		}

After this is done, you can do initilization for a week if you want .

if you dont response the uci request (immediatelly, or let s say simply too late), the engine may not be loaded.


Now, i dont know Wb-Protocol, but as Robert mentioned with done=0
you also have all time of the world.

A check uci request - > send uciok
B wb set done to 0
C initialize engine (hashtables,bitbases...)
D use the ptc available or which you prefer

you may order B,A,C,D if necessary.

I see it if the engine is only xboard or is only uci, but both.....
I dont see the point if ...

1. start the engine in xboard
2. set done=0
3. do init, (egbb, tt, etc)
4. send ready
5. get commands. uci received
6.... is too late, uci gui think engine is not alive. timeout

the ideal would be receive uci command (5) before init (3) and then init...
but if I do it so, how can I do init (3) if I am only under xboard? (the problem seems to be how to receive the uci command in xboard before egbb initialization)

[OliverUwira]

Hello Fermin,

uci: gui sends "uci"

now...

Code: Select all

	 if(!strcmp(c,"uci"))
		{
		 globalUci->uciIsOk = true;

		 comSend(engineInfo());
		 comSend("id author Michael Hoffmann");
		 uciSendOptions();
		 comSend("uciok");
		}

After this is done, you can do initilization for a week if you want .

if you dont response the uci request (immediatelly, or let s say simply too late), the engine may not be loaded.


Now, i dont know Wb-Protocol, but as Robert mentioned with done=0
you also have all time of the world.

A check uci request - > send uciok
B wb set done to 0
C initialize engine (hashtables,bitbases...)
D use the ptc available or which you prefer

you may order B,A,C,D if necessary.

The UCI GUI should wait for your engine to finish initialisation after it has sent you the "isready" command. After you answer that with "readyok" the GUI will assume you're done and ready to "think".

[Desperado]

The UCI GUI should wait for your engine to finish initialisation after it has sent you the "isready" command. After you answer that with "readyok" the GUI will assume you're done and ready to "think".

Excactly.And the gui only will send "isready" if you response uci with
uciok.

===============================================

Well you can do the following (just a little pseudopseudoCode)

1:

- use a variable as identifier for the mode.
- parse -> the protocol identifies itself first!, by "xboard" or by "uci"
just check out this value and store it to variable
- on further communication simple switch the protocol in use.

2:

After the protocol is identified:

if(variable==ptcXboard) {set done=0;initialize();} //dont know what happens here
else if(variable==ptcUci) {responseUci();initialize();} //meanwhile the gui sends _isready_

3:
if(initCompleted && variable==ptcXboard) done=1;
if(initCompleted && variable==ptcUci} responseIsReady with isReadyOk

this way somehow, or similar.

[wgarvin]

Hello Fermin,

uci: gui sends "uci"

now...

Code: Select all

	 if(!strcmp(c,"uci"))
		{
		 globalUci->uciIsOk = true;

		 comSend(engineInfo());
		 comSend("id author Michael Hoffmann");
		 uciSendOptions();
		 comSend("uciok");
		}

After this is done, you can do initilization for a week if you want .

if you dont response the uci request (immediatelly, or let s say simply too late), the engine may not be loaded.


Now, i dont know Wb-Protocol, but as Robert mentioned with done=0
you also have all time of the world.

A check uci request - > send uciok
B wb set done to 0
C initialize engine (hashtables,bitbases...)
D use the ptc available or which you prefer

you may order B,A,C,D if necessary.

I see it if the engine is only xboard or is only uci, but both.....
I dont see the point if ...

1. start the engine in xboard
2. set done=0
3. do init, (egbb, tt, etc)
4. send ready
5. get commands. uci received
6.... is too late, uci gui think engine is not alive. timeout

the ideal would be receive uci command (5) before init (3) and then init...
but if I do it so, how can I do init (3) if I am only under xboard? (the problem seems to be how to receive the uci command in xboard before egbb initialization)

I suggest that you wait until you have received the first string from the GUI before doing anything. That first string should be either "xboard" or "uci" and everything else you do from that point on will depend on which one you receive. (Maybe you can encapsulate this in some kind of protocol handler object, and have that object call engine functions at the right times to do things such as initialization, making a move or being informed of an opponent's move, etc).

I know a lot of people like to start with the move generator, but if I were sitting down to write a chess program, the first piece I would want to get working is the piece of code which handles standard input and output, and protocol selection, and the skeleton code for handling both protocols. (Of course a lot of the details would not make sense to implement until later, when you had a chess engine to hook them up to).

[Desperado]

Look at this...

http://chessprogramming.wikispaces.com/CPW-Engine_com

Michael