[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Byrial Jensen
Subject: Re: [XBoard-devel] Hi from a new member of the xboard team
Date: Tue, 20 Dec 2011 22:58:11 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110922 Thunderbird/3.1.15

Den 20-12-2011 21:49, h.g. muller wrote:

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.

((((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)

That is a bad example as no compiler that I can imagine would suggest more parentheses in the latter expression.

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

Interesting. I am not sure that it would be a good idea to give more tasks to the game engines. It would make it harder to make engines, and make the engines less portable to other interface programs as the distinction between gui and engine would be weakened.

But I also agree that it is a problem that xboard have to know the rules of many different games. Already now all this knowledge about many chess variants complicates the code too much, I think.

I would consider taking specific game knowledge out of xboard, and instead make a plugin-structure, so a module for the actual game can be loaded at run time. That would in some ways simplify the core code, and make it possible for everyone to write plugins for any game - much in the same way as everyone can now build their own engines if they wish to do so and have the necessary programming skills.

At the moment that is just a thought. But I think it is worth to consider.

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.

It could a long term goal for 5.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).

I can confirm from own experience with xboard 4.6 on Linux that it is somewhat slow to start up. I can do some profiling to see what is taking the time.

- Byrial

reply via email to

[Prev in Thread] Current Thread [Next in Thread]