rails-devel

Re: [Rails-devel] Junit reports broken test cases

[Stefan F. <ste...@we...>]

Erik:
I did a quick test game for 1830 to verify the revenue calculation and it 
seems that the token lay mechanism is also broken for the OO-tiles. 

And I assume you have not changed the definition of those.

I have attached two example files:
A) Erie tile lay
If you have NYC lay the brown tile on the Erie base, the Erie token will be 
beamed to the other city.

B) Token lay on the C&A hex
If you have the NYC lay the brown tile on the C&A hex, then it replaces the 
PRR token on the wrong station. In addition the route awareness graph thinks 
that the station on the C&A hex is tokened out, thus it seems that the 
graphical representation and the internal ones are swapped.

In both cases playing around with undo can make things even worse.

Another issue arose, which might be connected: If I lay the NYC home base 
brown and undo that, then the revenue code assumes that NYC has no token 
anymore to start with.

Stefan

PS: to the list as it impacts the testing of other parts of rails as well 
(especially revenue calculation)

On Thursday 15 April 2010 23:02:27 Erik Vos wrote:
> Stefan,
>
> The problem was caused by the Toronto tile change, but remained hidden
> until I implemented reserved token space avoidance.
> Now that I think about it, I remember that at some point (probably just
> after the Toronto change) the CV token spot had moved to the NE side of
> Toronto. At that time I changed the CV home station number, which in
> hindsight was stupid: I should have changed (or rotated) the tile. I'm
> afraid the only way to fix the test cases is to replay the games, at least
> from the point of failure.
>
> Erik.
>
> -----Original Message-----
> From: ste...@we... [mailto:ste...@we...]
> Sent: Thursday 15 April 2010 22:32
> To: Erik Vos
> Subject: Re: Junit reports broken test cases
>
> The one thing I do not fully understand: I uploaded the Junit class after
> the
> 1.2.2 release: Thus the cases were constructed with the a version that is
> after that latest release and they worked at that time.
>
> You suspect that this is related to the change of Toronto tile, which was
> released with 1.2.  Thus one of your changes combined with the new Toronto
> tile works differently as with the old (NY - if I remember correctly?).
> That
>
> seems to be a pretty subtle problem. It also means that all 1856 plays from
> before 1.2. are potentially suspect to this problem.
>
> Would it help to open the test cases under 1.2.2. and then save it there
> and
>
> then open with the current HEAD?
>
> Stefan
>
> On Thursday 15 April 2010 22:07:59 you wrote:
> > OK, I have uploaded the fix (and another few minor ones).
> >
> > I'm afraid that about all my 1856 saved files (including the ones I sent
> > you) are now invalid. I could fix it by reversing the city numbers in the
> > new Toronto tile -56001, but that would invalidate any later saved games,
> > so that might not be a very good idea. However, this now makes regression
> > testing of 1856 rather difficult.
> >
> > Not sure if have sent you any 1835 saved files, but some of mine are also
> > invalid now (for a different reason).
> >
> > Erik.
> >
> >
> > -----Original Message-----
> > From: Erik Vos [mailto:eri...@xs...]
> > Sent: Wednesday 14 April 2010 23:30
> > To: 'ste...@we...'
> > Subject: RE: Junit reports broken test cases
> >
> > It's about token laying on reserved city spots.
> >
> > The 18EU case was a bug, which I have fixed.
> >
> > In the 1856 case (at least the one that I could check) a GT token was
> > laid on the Toronto CV spot. This may be caused by the recent replacement
> > of
>
> the
>
> > Toronto tile; I might have swapped the station numbers on that tile, and
>
> if
>
> > so, that would explain it.
> > If this is the explanation, all older 1856 saved games that have this
>
> token
>
> > lay are invalid and must be removed from the test set.
> >
> > In another test I'm hitting on problems with the 1835 PR formation, which
> > suddenly does not work anymore for unclear reasons.
> > I will first sort that out before I upload any changes.
> >
> > Erik.
> >
> >
> >
> > -----Original Message-----
> > From: ste...@we... [mailto:ste...@we...]
> > Sent: Wednesday 14 April 2010 18:48
> > To: Erik Vos
> > Subject: Junit reports broken test cases
> >
> > Erik:
> > in your latest commit you changed something which broke several test
>
> games.
>
> > Most likely related to some lay tile or token activity.
> > Have attached the junit report.
> > Hope it helps to track it down, if it was not an intentional change.
> > Stefan

Re: [Rails-devel] Junit reports broken test cases

[Erik V. <eri...@xs...>]

Fixed two bugs in the Erie tile-laying and token-jumping case:

- the code to prevent one brown OO city to pick up both green OO
connections, had been commented out in Rails 1.0.5 for unexplained reasons.
Guess it's my error (mea culpa).

- City.relatedStation should have been a State variable but wasn't. This
occasionally caused the cities (and hence the tokens) to be swapped after an
Undo (or rather: not be unswapped by the Undo). 
I haven't seen any token-swapping cases yet that are not caused by an Undo.
Sorry, no time for thorough testing these days.

Erik.

-----Original Message-----
From: Erik Vos [mailto:eri...@xs...] 
Sent: Friday 16 April 2010 23:30
To: 'ste...@we...'; 'Development list for Rails: an 18xx game'
Subject: RE: Junit reports broken test cases

These two files reflect identical game positions, both having Erie green and
C&A brown. 
Indeed one brown OO tile lay let the Erie token jump, but perhaps even worse
is that several wrong brown tile lays are allowed.
That wasn't so in the past, so I wonder what might have broken that logic.

Re: [Rails-devel] Junit reports broken test cases

[Erik V. <eri...@xs...>]

These two files reflect identical game positions, both having Erie green and
C&A brown. 
Indeed one brown OO tile lay let the Erie token jump, but perhaps even worse
is that several wrong brown tile lays are allowed.
That wasn't so in the past, so I wonder what might have broken that logic.

Anyway, work to do. This was one of the real hard parts to get right...

But before I can even think of sorting this out, I must get rid of all that
DEBUG logging that Stefan has added.
Fortunately, there is a simple way to do that.
HINT FOR EVERYONE: if you can, add the following line to your version of
my.properties:
log4j.logger.rails.algorithms=INFO

Erik. 

-----Original Message-----
From: ste...@we... [mailto:ste...@we...] 
Sent: Friday 16 April 2010 18:00
To: Development list for Rails: an 18xx game
Cc: Erik Vos
Subject: Re: Junit reports broken test cases

Erik:
I did a quick test game for 1830 to verify the revenue calculation and it 
seems that the token lay mechanism is also broken for the OO-tiles. 

And I assume you have not changed the definition of those.

I have attached two example files:
A) Erie tile lay
If you have NYC lay the brown tile on the Erie base, the Erie token will be 
beamed to the other city.

B) Token lay on the C&A hex
If you have the NYC lay the brown tile on the C&A hex, then it replaces the 
PRR token on the wrong station. In addition the route awareness graph thinks

that the station on the C&A hex is tokened out, thus it seems that the 
graphical representation and the internal ones are swapped.

In both cases playing around with undo can make things even worse.

Another issue arose, which might be connected: If I lay the NYC home base 
brown and undo that, then the revenue code assumes that NYC has no token 
anymore to start with.

Stefan

PS: to the list as it impacts the testing of other parts of rails as well 
(especially revenue calculation)

On Thursday 15 April 2010 23:02:27 Erik Vos wrote:
> Stefan,
>
> The problem was caused by the Toronto tile change, but remained hidden
> until I implemented reserved token space avoidance.
> Now that I think about it, I remember that at some point (probably just
> after the Toronto change) the CV token spot had moved to the NE side of
> Toronto. At that time I changed the CV home station number, which in
> hindsight was stupid: I should have changed (or rotated) the tile. I'm
> afraid the only way to fix the test cases is to replay the games, at least
> from the point of failure.
>
> Erik.
>
> -----Original Message-----
> From: ste...@we... [mailto:ste...@we...]
> Sent: Thursday 15 April 2010 22:32
> To: Erik Vos
> Subject: Re: Junit reports broken test cases
>
> The one thing I do not fully understand: I uploaded the Junit class after
> the
> 1.2.2 release: Thus the cases were constructed with the a version that is
> after that latest release and they worked at that time.
>
> You suspect that this is related to the change of Toronto tile, which was
> released with 1.2.  Thus one of your changes combined with the new Toronto
> tile works differently as with the old (NY - if I remember correctly?).
> That
>
> seems to be a pretty subtle problem. It also means that all 1856 plays
from
> before 1.2. are potentially suspect to this problem.
>
> Would it help to open the test cases under 1.2.2. and then save it there
> and
>
> then open with the current HEAD?
>
> Stefan
>
> On Thursday 15 April 2010 22:07:59 you wrote:
> > OK, I have uploaded the fix (and another few minor ones).
> >
> > I'm afraid that about all my 1856 saved files (including the ones I sent
> > you) are now invalid. I could fix it by reversing the city numbers in
the
> > new Toronto tile -56001, but that would invalidate any later saved
games,
> > so that might not be a very good idea. However, this now makes
regression
> > testing of 1856 rather difficult.
> >
> > Not sure if have sent you any 1835 saved files, but some of mine are
also
> > invalid now (for a different reason).
> >
> > Erik.
> >
> >
> > -----Original Message-----
> > From: Erik Vos [mailto:eri...@xs...]
> > Sent: Wednesday 14 April 2010 23:30
> > To: 'ste...@we...'
> > Subject: RE: Junit reports broken test cases
> >
> > It's about token laying on reserved city spots.
> >
> > The 18EU case was a bug, which I have fixed.
> >
> > In the 1856 case (at least the one that I could check) a GT token was
> > laid on the Toronto CV spot. This may be caused by the recent
replacement
> > of
>
> the
>
> > Toronto tile; I might have swapped the station numbers on that tile, and
>
> if
>
> > so, that would explain it.
> > If this is the explanation, all older 1856 saved games that have this
>
> token
>
> > lay are invalid and must be removed from the test set.
> >
> > In another test I'm hitting on problems with the 1835 PR formation,
which
> > suddenly does not work anymore for unclear reasons.
> > I will first sort that out before I upload any changes.
> >
> > Erik.
> >
> >
> >
> > -----Original Message-----
> > From: ste...@we... [mailto:ste...@we...]
> > Sent: Wednesday 14 April 2010 18:48
> > To: Erik Vos
> > Subject: Junit reports broken test cases
> >
> > Erik:
> > in your latest commit you changed something which broke several test
>
> games.
>
> > Most likely related to some lay tile or token activity.
> > Have attached the junit report.
> > Hope it helps to track it down, if it was not an intentional change.
> > Stefan