Re: Hi from a new member of the xboard team

>>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.

Well,replace * by && and + by || and it will complain all the time...


>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.

Indeed, much of what you say is true. But this is mainly meant for games 
where just a hand full, or perhaps even only a single engine exists. Now 
people programming such a game typically have to program the entire GUI 
with it, including the graphical part, or use text interfaces. For them it 
would be a huge simplification if they can control a fully graphical GUI 
through the text interface of the protocol.

>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.
Using plug-ins is a good idea. But a plug-in would duplicate many functions 
of the engine, as the latter would definitely have to be able to do 
move-legality checking or generate lists of moves. In fact what we now call 
engine initially was nothing but a plug-in responsible for maintaining the 
game rules, and XBoard still uses the first engine as such (keeping it in 
sync in EditGame mode, for instance). So I think this idea would eventually 
pan out to using a 'referee engine' for the plug-in, which would just be a 
normal engine that fully implements the new protocol features (which in 
principle are optional, controlled by 'feature highlight=1'), so that other 
engines don't have to bother with that.

The advntage would be that the person writing the first engine for a game 
would not have to code a eparate plug-in, but could draw on the engine for 
that.

>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.

In the case I ws referring to this was a 12-20 sec delay during which the 
main window stayed blank, and we were able to trace it to calls to the 
X-server. There is already a lot of e-mail correspondence about this, but I 
am not sure it is visible in a public place...