Re: WinBoard sources missing

[Arun Persaud]

Hi

Tim Mann wrote:
> Hmm, why aren't we including the WinBoard-only sources in the tarball
> too?  I don't see a reason to remove them.  Arun?
>
> On Thu, 05 Nov 2009 12:53:36 +0100, "h.g. muller" <h.g.muller@...> wrote:
>> I see that the source tar ball we now offer from the GNU download section
>> is not the same as the one in the git repository, but is now completely
>> cleansed of WinBoard sources. I had not really planned on distributing
>> sources from the WinBoard forum, so people that were looking for them
>> are now looking in the wrong place, and complaining about it.

oops. I'll add them back. Guess they were kicked out when I rewrote
parts  of the configure mechanism and nobody caught it up to now...

I'll add the winboard directory back in, so that it will be included in
a "make distcheck". Guess I'll release a 4.4.1a for this by latest this
weekend with just the winboard sources added (might have time today, but
should be able to do it on the weekend for sure).

>> As an aside: I see now that the Shogi bitmaps are included in the root of
>> the tar ball (and have thus ended up in the XBoard-only distribution),
>> while these are simply duplicats of those in the winboard/shogibitmaps
>> directory. They are not used in building XBoard, and even have the wrong
>> format for that. (They are Windows .bmp files.)

so xboard/shogibitmaps can be deleted from git and we keep only
xboard/winboard/shogibitmaps?

ARUN

[Eric Mullins]

> Guess I'll release a 4.4.1a for this by latest this ...
>  

Why don't we just call it 4.4.1, and 4.4.1.1?  This conforms with
windows versioning, and keeps everything numeric.


When we release a beta, we'd just bump the last suffix (unless it was 0
and thus omitted), and name it beta in the tarball.

[Arun Persaud]

Hi

Eric wrote:
> Why don't we just call it 4.4.1, and 4.4.1.1?  This conforms with
> windows versioning, and keeps everything numeric.

would be fine with me, but I think that came up already a while ago and
people wanted to stay with 3 digits... I would also be ok, just calling
this 4.4.2 that way we go a bit faster through version numbers, but then
again, we don't really do releases that often...

> When we release a beta, we'd just bump the last suffix (unless it was 0
> and thus omitted), and name it beta in the tarball.

I think for betas I prefer the 4.4.2.20091105 numbers... since that
allows for easy continues releases independent of alpha/beta status and
it is also one of the ways suggested for GNU projects...

ARUN

[h.g. muller]

>Why don't we just call it 4.4.1, and 4.4.1.1?  This conforms with windows
>versioning, and keeps everything numeric.

Well, we should perhaps make a distinction between new XBoard versions,
and new packaging (tar balls or installers). The a, b, c is good for the
package numbering.

By studying the sources I discovered a bad bug, btw. I noted that
pasing a FEN simulates the EditPosition menu, by calling
EditPosition() and EditPositionDone(). I had not anticipated that.
So I put code in EditPositionDone() to fake castling rights,
as the user cannot enter those. But the faked castling rights
now overwrite those of the FEN. This bug was masked in
XBoard, but the wrog castling rights were sent to the engine.

If we make a new tar ball, shal we also put a new WinBoard in it,
with a fix for this bug?

[Arun Persaud]

Hi

h.g. muller wrote:
>
>> Why don't we just call it 4.4.1, and 4.4.1.1?  This conforms with
>> windows versioning, and keeps everything numeric.
>
> Well, we should perhaps make a distinction between new XBoard versions,
> and new packaging (tar balls or installers). The a, b, c is good for the
> package numbering.

I think a forth digit is a standard way to indicate small changes, e.g.
packaging...

> By studying the sources I discovered a bad bug, btw. I noted that
> pasing a FEN simulates the EditPosition menu, by calling
> EditPosition() and EditPositionDone(). I had not anticipated that.
> So I put code in EditPositionDone() to fake castling rights,
> as the user cannot enter those. But the faked castling rights
> now overwrite those of the FEN. This bug was masked in
> XBoard, but the wrog castling rights were sent to the engine.
>
> If we make a new tar ball, shal we also put a new WinBoard in it,
> with a fix for this bug?

in that case we could also just call it 4.4.2 ;) 4.3.x went up to 16?
and I don't think that we will get a lot more than that and even if we
would it would be ok... no real reason to save version numbers...

ARUN

[Arun Persaud]

Hi

Tim Mann wrote:
> Hmm, why aren't we including the WinBoard-only sources in the tarball
> too?  I don't see a reason to remove them.  Arun?

added them in, just waiting for a clarification from HGM on another
issue before uploading to git...

Is the directory winboard/install used for anything? Or can I delete
that one? The windows installer has it's own branch now in git...

ARUN

[h.g. muller]

>n that case we could also just call it 4.4.2 ;) 4.3.x went up to 16?
>and I don't think that we will get a lot more than that and even if we
>would it would be ok... no real reason to save version numbers...

OK, I am in favor of an immediate 4.4.2 release, then.
Problem is that I submitted the patches in the wrong order,
as I discovered the bug I introduced in the FEN pasting
only when doing the refctoring of e.p. and castling rights.
I would prefer that refactoring to go into a beta version,
and not dump it completely untested in a "stable release".

Is there any easy way for you to invert the order of patches,
when they are to the same file? Solving the bug is reasonably
easy and low-risk; it is just a matter of equiping EditPositionDone()
with a Boolean argument fakeRights, and putting an
if(fakeRights) { ... } around the castling-rights code.
It is called quite a few times, though, and all except the last call
should be with argument value TRUE.

Should I make a seprate version of the 4.4.1 backend.c / backend.h
that has just this patch?

[Arun Persaud]

Hi

HGM wrote:

> OK, I am in favor of an immediate 4.4.2 release, then.
> Problem is that I submitted the patches in the wrong order,
> as I discovered the bug I introduced in the FEN pasting
> only when doing the refctoring of e.p. and castling rights.
> I would prefer that refactoring to go into a beta version,
> and not dump it completely untested in a "stable release".
>
> Is there any easy way for you to invert the order of patches,
> when they are to the same file? Solving the bug is reasonably
> easy and low-risk; it is just a matter of equiping EditPositionDone()
> with a Boolean argument fakeRights, and putting an
> if(fakeRights) { ... } around the castling-rights code.
> It is called quite a few times, though, and all except the last call
> should be with argument value TRUE.

should be relatively easy... as an alternative I could also just add the
winboard sources and put a tar-ball with the winboard source up for
download without any other modifications and we just don't change
version numbers yet. Or we get just test your refactoring patch to
include it too in 4.4.2 ;)

What does everyone else think about those three options?

Anyway, it will have to wait until tomorrow or Sunday until I will have
time to do it.

ARUN

[h.g. muller]

Is there any special reason why switching to Edit-Game mode
clears the game result and resultDetails? I guess if you really are going
to edit the game by playing another move somewhere, the tail of the
game will disappear anyway, and the result with it. So it just speeds
up the unavoidable, although the user could change his mind,
and save the game unaltered after all (with spoiled tags).

But now that I allow the user to explore variations, perhaps for the
purpose of adding them as comments to the main line when he
reverts to the latter, it is a bit inconvenient that the result is already
gone even before I shelve the main line by entering a move.
I did include code to shelve result and resultDetails as well, and
restore them on Revert, but now there is nothing to save.

Would it break any other behavior when I defer the calling of
SetGameInfo() from EditGameEvent() until the user actually
alters the game? Perhaps I should shelve the entire gameInfo,
as when the user finally decides to Revert to the main line,
it ceases to be an "edited game", (although it might be a more
annotated one), and all the original tags would still be applicable?

[h.g. muller]

>should be relatively easy... as an alternative I could also just add the
>winboard sources and put a tar-ball with the winboard source up for
>download without any other modifications and we just don't change
>version numbers yet. Or we get just test your refactoring patch to
>include it too in 4.4.2 ;)
>
>What does everyone else think about those three options?
>
>Anyway, it will have to wait until tomorrow or Sunday until I will have
>time to do it.

I will probably not be able to get back in touch before the 11th.
I think we should rethink our release policy, and perhaps
include forking as a standard procedure. With this I mean that
I would like to have a version where I experiment with large code
changes, in parallel with a version where we only fix minor
bugs, that we of course also fix in the alpha version, but which
we can clear for release then much earlier.

The 4.4.1 with two simple bug fixes (castling rights on FEN pasting
and crash on engine crash) should in this scheme go out as 4.4.2
in the new tar ball with WinBoard sources; the other stuff I have
produced should then be called 4.4.2.<date> when we tag it
as beta.

[Tim Mann]

On Fri, 06 Nov 2009 19:49:13 +0100, "h.g. muller" <h.g.muller@...> wrote:
> Is there any special reason why switching to Edit-Game mode
> clears the game result and resultDetails?

I think it's only because once you've edited the game, the old result
isn't valid anymore.  As far as I know, what you propose below should
work fine.

> I guess if you really are going
> to edit the game by playing another move somewhere, the tail of the
> game will disappear anyway, and the result with it. So it just speeds
> up the unavoidable, although the user could change his mind,
> and save the game unaltered after all (with spoiled tags).
>
> But now that I allow the user to explore variations, perhaps for the
> purpose of adding them as comments to the main line when he
> reverts to the latter, it is a bit inconvenient that the result is already
> gone even before I shelve the main line by entering a move.
> I did include code to shelve result and resultDetails as well, and
> restore them on Revert, but now there is nothing to save.
>
> Would it break any other behavior when I defer the calling of
> SetGameInfo() from EditGameEvent() until the user actually
> alters the game? Perhaps I should shelve the entire gameInfo,
> as when the user finally decides to Revert to the main line,
> it ceases to be an "edited game", (although it might be a more
> annotated one), and all the original tags would still be applicable?

--
Tim Mann  tim@...  http://tim-mann.org/