(no subject)

Hi,

I'm Shahram Tabandeh, Ph.D. student at McGill University, experienced
software developer and a lover of strategic games. I like to contribute
to xboard project.

cheers,
Shahram

Re: (no subject)

Hi

> I'm Shahram Tabandeh, Ph.D. student at McGill University, experienced
> software developer and a lover of strategic games. I like to contribute
> to xboard project.

Great! We can always need more people :) Do you have anything in 
particular in mind that you want to work on, if not the GTK version 
(where we want to merge Xboard and Winboard again into one code base) 
needs a lot of work...

There are some formalities to be handled, since XBoard/Winbaord is a GNU 
project, but apart from that feel free to start coding ;)

ARUN

Re: (no subject)

A new feature that is reglarly requested lately is to equip XBoard with
some kind of mode to automatically solve problems given in an EPD file
with an engine, and then let it keep the score of correct and incorrect
solutions. I have done nothing in that respect yet.

This is a feature that is very much related to 'match mode'. It is already
possible to start a match using a FEN / EPD file for starting positions
(auto-incrementing the position index). The difference here would be that
each 'game' of the match would only last for a single move, (i.e. it
should be played as 'Machine White' or 'Machine Black', rather than 'Two
Machines'), after which the move played by the engine should be compared
to the solution move (or 'avoid move') given in the EPD (for which some
additional parsing of the EPD line would have to be added; currently
XBoard only looks at the FEN part). The regular win and loss counters
could be used for keeping the number of correct and incorrect solutions,
which then pop up after the entre file is processed.

In addition there can be reporting in an automatic saveGameFile as usual.
An extension here might actually be to write the entire PV of the engine
as a PGN game, rather than just its move. There have also been requests to
make XBoard auto-play the engine PV on the display before going to the
next problem.

Capability to write an engine PV in the PGN might be generally useful.
Another thing that XBoard currently cannot do (I think) is automatically
annotate an entire file with depth/score and PV information obtained from
an analyzing engine. In match mode it can use the games in a file as
forced opening line, and if the game would run to the end, it would be
immediately finished. But the engine is kept in force mode during this, so
there is no PV info generated. An option could be added to have the engine

master-branch needs some testing

Hi

there are a several new commits that changed code all over the place
(mostly to prevent buffer overflows). Would be great, if people could
test the current master ;)

Arun

Re: master-branch needs some testing

Re: master-branch needs some testing

Re: master-branch needs some testing

At 20:41 7-10-2010 -0700, Arun Persaud wrote:
>Hi
>
>there are a several new commits that changed code all over the place
>(mostly to prevent buffer overflows). Would be great, if people could
>test the current master ;)
>
>Arun

Apart from this (which potentially could cause problems anywere) there were
two specific elaborate code changes, which deserve special testing:

The algorithm for handling the -mps, -tc and -inc parameters was completely 
changed,
in preparation for handling multi-session Time Controls in engine play.
So it would be good to check if every TC type that used to work still works,
also when the -tc parameter is of the form "min:sec", and if the flag is called
at the proper moment in all types of TC. I guess t should be pretty obvious
if something is wrong here, as there are not too many combinations.

The second change is in the the promotion code. The old code did not
protect well against erroneous or spurious promotion characters printed by 
engines
from leaking to the oher engine, or into the PGN, and vice versa. Also the 
default
of promoting to Queen when the promotion suffix was missing was no longer 
correct.
To cure all that the internal representation of promotions was changed.
Of special concern in variants with funny promotion rules (e.g. Shatranj,
Shogi, mini-Shogi). Also untested is if promotion with normal Chess in ICS 
play
still works.

Re: master-branch needs some testing

On 10/07/2010 08:55 PM, Adrian Petrescu wrote:
> Here's something I noticed right away: I have an .icsrc file with my
> FICS username and password, and it works, but now the prompt after I log
> in is a (new) Password: **** one. Of course, I'm already logged in, so
> anything I put in there (including my accurate password) just gives:
> 
> password: fdsfds: Command not found.
> 
> (And no, fdsfds is not my real password ;) After that everything just
> continues working, so it's not a huge deal, but you might want to throw
> in a check for .icsrc files.
> 
> Hope that helps, I'll keep playing with it and let you know what I find!

yep, will fix this in the next few days... thanks for reporting!

Arun

Variation Trees

I would like to have some feedback about the new variation support in 
XBoard 4.5.pre0.
The way it is currently implemented initiates a new variation (pushing the 
tail of the
existing game on a stack) every time you enter a move in Analyze or Edit 
Game mode
when not at the final position of the current line. (In the final position 
it would just append
the move.) Previously, the game would simply be truncated before appending 
the move.

The danger of the new method is that people that are used to analyzing 
without using 'revert',
but in stead by using '<' to step back through the current line, and then 
try an alternative move,
wil pretty quickly run into a 'stack overflow' error popup, as they save 
game tail after game tail
on the stack, and never pop anything. I can imagine they would perceive 
this as extremely
annoying. I never use Analyze mode myself, so I have no idea how it is 
typically used...

I guess people could get used to using 'revert' for retracting an entire 
variation to the point
where they started it. But when they want to try an alternative move from a 
position between
the point where they started the current variation, and its end, that would 
be very inconvenient,
as it would retract some of the moves they still want played. So the use of 
'<' and '>' to step
to the branching point, and enter a new move there, seems natural. This is 
fine if it was just
the first of a number of sub-variations on the current variation they 
wanted to explore:
when they are done with it they can then 'revert', and use '<', '>' to step 
through another
position to try another sub-varation. But it does not provide for the case 
where they want
to abandon the tail of the current variation entirely (because they feel it 
is refuted).
It would then be annoying to them to revert to it every time. Not only 
because they have
to hit 'revert' one extra time, but mostly because this interferes with 
saving the variation
they finaly do want to keep (which is now a sub-variation on a silly line) 
as variation
comment in the PGN through 'annotate'.

The logical way to solve this is to let them use 'truncate game' to 
truncate a current line
they don't want to keep, before entering new moves, so that entering these 
moves will
not start a new (sub-)variation, but simply replace the tail of the current 
line.
However, 'Truncate Game' is now implemented by first discarding the entire 
variation stack,
and making the current variation (after truncation) the main line, making 
it unusable for this
purpose. This might be an undesirable implementation of 'Truncate Game'. 
But if you make
'Truncate Game' just act on the current variation, the problem exists that 
there can be
game tails pushed on the variation stack that branch off on a move after the
truncation point, and an attempt to restore them would then leave a gap in 
the game.
I guess this could be handled by not discarding the complete stack, but 
just all game tails
on it that start behind the truncation point at the moment you truncate.

An alternative would be to not make the starting of a new variation automatic.
('autoTruncate mode', if you want.) Playing a move from within an existing 
line would then
result in the old behavior of truncating the line and appending the move, 
rather than pushing
the tail on the variation stack. A new variation could then be started, for 
example, by holding
the Shift key down while making the move. This might provide better 
backward compatibility,
but it is not essentially different from explicitly having 'Truncate Game'. 
(Just that you have to
press an extra key in the opposite case.) So it will pose the same problems 
w.r.t. game gaps.

An alternative way to solve the gap problem is to not just push game tails, 
but the entire game,
each time you start a variation. This could lead to an explosion of memory 
usage, however,
if you are trying out many short variations at the end of a long game, and 
thus is not very elegant.

I would like to know what people think should be the desired behavior here.

Re: Variation Trees

Hi

I have to say that I never use variations either, but I don't understand
why creating more variations leads into memory problems...

Shouldn't we just have the whole game including variations in a
tree-like structure and then a linked list without any branches that
points to the current/active variation? Going back and forth would just
move along the current list and whenever you add a new variation you add
it to the tree and update the current list and when you move back and
forth and there are multiple branches in the tree they should be shown
somewhere in a windows, so that you can select the branch you like or
you just show the whole tree in a window and people can click on any
leave in it to select the branch they want to be on.

Perhaps it would be good to rewrite this part if there are problems with it?

Arun