Re: [XBoard-devel] Hi from a new member of the xboard team

[h.g. muller]

> Well, the compiler only does what you tell it to do, and all kind of 
> warnings can turned on and off individually (at least so with gcc which I 
> use). I just wonder which warnings you consider to inflict error-prone and 
> difficult to understand code.

The warning that recommends use of parentheses. Unnecessary prentheses IMO 
are very detrimental, and very easily group things in a way that was not 
intended.
E.g.

((((1*2)*3)*4) + (5*(6*(7*(8*9)) + (1*2))))

is very hard to read compared to

1*2*3*4 + 5*(6*7*8*9 + 1*2)

> It would nice to have a roadmap for the development of xboard.
>
> Which features should go into 4.6.0, and which into later versions? Where 
> do this aliennew branch at hgm.nubati.net fit in for this?

Everything that is currently in master is intended to go into 4.6.0, and 
there are not many loose ends. (It was suggested I should add 
-afterTourney, -afterCycle and -afterRound options similar to -afterGame, 
and this seems a good idea, so I would like to include it in 4.6.0. But 
this is quite straightforward,)

The aliennew brach contains a lot of changes directed at making WinBoard 
more generally useful as a GUI for any board game, also games not related 
to Chess (with other capture modes, such as Checkers, Reversi, Go and 
Ultima, with multiple moves per turn, such as Amazons). It implements 
features to give the engine more control over things that now are 
programmed explicitly in the GUI, like move legality checking, move 
interpretation (board update), setting up the initial position, assigning 
piece ID letters to the various pieces, determining the board format. A lot 
of this touches the very core of the back-end code, and could conceivably 
break XBoard completely when not implemented properly. It also requires 
extension of the engine communication protocol, and it is not clear in all 
cases what the consequences of this are. For instance, in the new variant 
'alien', the egine is supposed to send a board update to the GUI after 
every input or output move. This works fine when playing, say, two Ultima 
engines against each other, or human vs Ultima engine. But it causes as yet 
unsolved problems when loading a game from PGN: in this case the moves are 
sent to the engine only after the GUI has loaded the entire game. Because 
WinBoard is not aware of the Ultima capture rules, however, it updates the 
board in a wrong way durig game load, so that it usually runs into an 
illegal move before the end of the game is reached. (There are some moves 
XBoard considers illegal even with legality testing off, such as capturing 
own pieces, or moving empty squares.) To properly fix this would require 
completely changing the logic of loading games, keeping the first engine in 
sync with the game all the way, waiting for its board updates (through 
'setup' commands) before parsing the next move.

Because of these unsolved problems and lack of heavy-duty testing, plus the 
very legitimate question if we really want to expand the scope of XBoard 
beyond being an interface for Chess variants, I don't think it is wise  to 
put anything that is now in aliennew into 4.6.0.

> If we already have everything new for 4.6.0, then it would be time to 
> concentrate on bugfixing so it can be ready for release.

Well, this is pretty much the situation, and there are only very few known 
bugs. (In fact, most were reported by you.) With the emphasis on 'known', 
because we can't really vouch for much testing of the new features. As you 
discovered yourself when you tried translation, one of the new features we 
also never exercise ourselves... I know of an issue with the initialization 
of the black clock, which unfortunately does not occur when I compile it, 
so that debugging is cumbersome. And there seems to be a general problem 
with all versions since 4.4.0 on newer versions of some Linux distributions 
(very large startup delay). It would be good if 4.6.0 would fix that (but 
not strictly necessary, as 4.5.3 has it too).