[Top][All Lists]

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

Re: [Gnushogi-devel] Start of review of branch "hgm"

From: Yann Dirson
Subject: Re: [Gnushogi-devel] Start of review of branch "hgm"
Date: Sat, 24 May 2014 01:03:22 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Tue, May 20, 2014 at 08:52:06AM +0200, Yann Dirson wrote:
> I started to get a look at your branch (did not find time to go
> through all of them yet), and pushed to branch hgm+ a set of new
> patches, with various further improvements, as well as some comments
> and questions about some of your chages in a handful of
> otherwise-empty commits.

Since there are many topics in your branch, I splitted them into
separate branches (a handful based on maint, the remaining on master),
and created "proposed updates" branches "maint-pu" and "pu" merging
everything (using git-integrate).  "pu" is equivalent to "hgm+",
"maint-pu" is a preparation for a 1.4.3 release.

The easiest way to look at it is something like
"gitk origin/master..origin/pu".

Most noticeable is probably the split of the sudden-death fix between
xboard-specific part (in pu) and non-xboard-specific (in maint-pu).
This and the other TC-related fixes are unfortunately not obvious to
check as I'm not so familiar overall with TC - does they look OK to
you as they are in maint-pu ?

I have squashed a couple of fixes into the commits they fix, but "Fix
InputCommand patch" still remains for now, as I was unsure which of
the patches - my guess would be "Implement periodic updates", as it is
the one implementing the backlog, is that correct ?  But if we squash
them, the explanation about that change becomes lost, a small comment
in the code around this change would probably help.

Also note your setting is not configured on the account you
used for those patches, resulting on "<address@hidden(none)>"

One problem I noticed when playing with changes around commands, is
that when an innocuous command like "help" or even "xboard" is given
as first, gnushogi will act as if the player had passed, and will
issue his own move:

$ ./BUILD/gnushogi/gnushogi -X
GNU Shogi 1.4.2+
#  0. moves=40,40 time=30000,30000 ResponseTime=100+46
move g7g6

git-bisect allowed to pinpoint the problem to the "Refactor
InputCommand" commit, thus I've merged the hgm/refactor/inputcommand
branch last in "pu", and pu^ is not impacted by this problem.

reply via email to

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