TalkChess.com

hgm wrote:It doesn't. This is why protover 2 / ping was invented.

The move from the previous game will be taken as a move for the new game, which usually leads to an immediate forfeit. If it happens to be legal in the opening position, the true move will be ignored by XBoard as an out-of-turn move, and as it usually will be a different on this will cause a discrepancy between XBoard's idea of the position and the engine's, leading to an illegal move later.

The only remedy is to specify a pause between games long enough that the engine would typically have moved before the new game starts.

hgm wrote:There is a general work-around option in XBoard to make it believe the engine has features that it doesn't:

-firstFeatures "ping=1 setboard=1"

would make XBoard believe the engine supports ping and setboard. (This is processed after the engine has send feature done=1 or the features timeout, so it would overrule whatever the engine really said, in case these were duplicats.) This way you can force XBoard to send ping even to v1 engines.

Of course this will thouroughly wreck things if the engine does not reply with 'pong'. But perhaps InBetween can be used to substitute pong for the engine's error response to 'ping' (whether it considers it an Illegal move or an Unknown command). But this would only work if the error-response preserves the number. E.g. in the Phalanx case you could have InBetween replace 'Illegal move: ping' by 'pong' in the engine->GUI channel.

hgm wrote:How do you solve the problem of multiple input sources and timer events? Create a separate input thread for every engine, and let it do blocking input? And use SIGALRM to set up the next timer event?

If you have solved these problems, it might be easier to just hack the GUI-dependence out of XBoard. By making all non-static routines in gtk/xoptions.c into dummies (and deleting the static ones). Basically you would only have to provide a new routines AddInputSource and RemoveInputSource, and rewite the timer handling in gtk/xtimer.c. And delete all the gtk-referring code out of gtk/xboard.c.

The timer handling seems the most tricky, as there can be several timeouts pending simultaneously in XBoard. (A dedicated one for making the clock tick, and a general one for all other events.)

while (game_still_ongoing)
{
	select(both_engine’s_input, timeout = 100ms);

	// these are asynchronous - they will only process what’s available already
	// in the pipes, and not block
	engine1.process_pending_inputs();
	engine2.process_pending_inputs();

	if (either_engine_made_a_move_or_made_draw_offer)
	{
		pass_it_on_to_the_other_engine();
	}

	check_clocks();
}

matthewlai wrote:

hgm wrote:How do you solve the problem of multiple input sources and timer events? Create a separate input thread for every engine, and let it do blocking input? And use SIGALRM to set up the next timer event?

If you have solved these problems, it might be easier to just hack the GUI-dependence out of XBoard. By making all non-static routines in gtk/xoptions.c into dummies (and deleting the static ones). Basically you would only have to provide a new routines AddInputSource and RemoveInputSource, and rewite the timer handling in gtk/xtimer.c. And delete all the gtk-referring code out of gtk/xboard.c.

The timer handling seems the most tricky, as there can be several timeouts pending simultaneously in XBoard. (A dedicated one for making the clock tick, and a general one for all other events.)

For multiple input sources I am using select(). It's easier for me because I don't need to support Windows.

I am doing select() with timeouts, and check the clocks at each timeout.

I think the main difference is that I am not making it event driven. So my main loop looks like this (pseudo code) -

Code: Select all

while (game_still_ongoing)
{
	select(both_engine’s_input, timeout = 100ms);

	// these are asynchronous - they will only process what’s available already
	// in the pipes, and not block
	engine1.process_pending_inputs();
	engine2.process_pending_inputs();

	if (either_engine_made_a_move_or_made_draw_offer)
	{
		pass_it_on_to_the_other_engine();
	}

	check_clocks();
}

It's very different from how xboard is organized (since xboard is event driven and need to handle user input).

bob wrote:

matthewlai wrote:

hgm wrote:How do you solve the problem of multiple input sources and timer events? Create a separate input thread for every engine, and let it do blocking input? And use SIGALRM to set up the next timer event?

If you have solved these problems, it might be easier to just hack the GUI-dependence out of XBoard. By making all non-static routines in gtk/xoptions.c into dummies (and deleting the static ones). Basically you would only have to provide a new routines AddInputSource and RemoveInputSource, and rewite the timer handling in gtk/xtimer.c. And delete all the gtk-referring code out of gtk/xboard.c.

The timer handling seems the most tricky, as there can be several timeouts pending simultaneously in XBoard. (A dedicated one for making the clock tick, and a general one for all other events.)

For multiple input sources I am using select(). It's easier for me because I don't need to support Windows.

I am doing select() with timeouts, and check the clocks at each timeout.

I think the main difference is that I am not making it event driven. So my main loop looks like this (pseudo code) -

Code: Select all

while (game_still_ongoing)
{
	select(both_engine’s_input, timeout = 100ms);

	// these are asynchronous - they will only process what’s available already
	// in the pipes, and not block
	engine1.process_pending_inputs();
	engine2.process_pending_inputs();

	if (either_engine_made_a_move_or_made_draw_offer)
	{
		pass_it_on_to_the_other_engine();
	}

	check_clocks();
}

It's very different from how xboard is organized (since xboard is event driven and need to handle user input).

One other note. I decided to give up on passing draw offers between programs. Too many do it wrong, so I just gave up. My referee ends a game when a draw state is seen (50 moves, 3-fold rep, stalemate, insufficient material) otherwise "draw" is ignored, which solved a lot of problems. I can disable this, but it only seems to be safe with Crafty vs Crafty matches, to specifically test accepting draw offers which I do a bit differently from some.