rails-devel

[Rails-devel] Release Rails 1.6.3 available

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

A bug release for the 1.6.x branch.

Downloads are available at http://rails.sourceforge.net/ or by the
direct link http://sourceforge.net/projects/rails/files/Rails/1.6.3/

This release fixes one sole bug:
1856: Errors with late-game dit upgrade/downgrade - ID: 3485172

The bug effects all versions since (at least) Rails 1.5.1.

Thanks to Bill Rosgen for fixing the bug and Aliza Panitz for reporting.

Re: [Rails-devel] Release Rails 1.6.3 available

[Schnell, V. <vol...@ar...>]

Hi Stefan,

here is another bug with 1835.
In the SR round one player buys the Bay-director and another  the NF, 
OBB and PB.
The player with the three privates must be the director of then Bayern.
rails did not hand over the director share. see attached example.
The new release has also the bug.

Thanks

Volker


-- 
Volker Schnell
email: vol...@ar...
homepage: home.arcor.de\volker_schnell

Re: [Rails-devel] Release Rails 1.6.3 available

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

Fixed. No presidency check was done in start rounds, this has now been
added.

Erik.

> -----Original Message-----
> From: Schnell, Volker [mailto:vol...@ar...]
> Sent: Tuesday, February 07, 2012 9:29 PM
> To: rai...@li...
> Subject: Re: [Rails-devel] Release Rails 1.6.3 available
> 
> Hi Stefan,
> 
> here is another bug with 1835.
> In the SR round one player buys the Bay-director and another  the NF, OBB
> and PB.
> The player with the three privates must be the director of then Bayern.
> rails did not hand over the director share. see attached example.
> The new release has also the bug.
> 
> Thanks
> 
> Volker
> 
> 
> --
> Volker Schnell
> email: vol...@ar...
> homepage: home.arcor.de\volker_schnell

Re: [Rails-devel] Release Rails 1.6.3 available

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

Erik:
it seems that you forgot to push this fix.
In master the bug still occurs and I have not found
anything in the git logs.
Could you please double-check again?
Thanks,
Stefan

On 02/07/2012 11:03 PM, Erik Vos wrote:
> Fixed. No presidency check was done in start rounds, this has now been
> added.
>
> Erik.
>
>> -----Original Message-----
>> From: Schnell, Volker [mailto:vol...@ar...]
>> Sent: Tuesday, February 07, 2012 9:29 PM
>> To: rai...@li...
>> Subject: Re: [Rails-devel] Release Rails 1.6.3 available
>>
>> Hi Stefan,
>>
>> here is another bug with 1835.
>> In the SR round one player buys the Bay-director and another  the NF, OBB
>> and PB.
>> The player with the three privates must be the director of then Bayern.
>> rails did not hand over the director share. see attached example.
>> The new release has also the bug.
>>
>> Thanks
>>
>> Volker
>>
>>
>> --
>> Volker Schnell
>> email: vol...@ar...
>> homepage: home.arcor.de\volker_schnell
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Release Rails 1.6.3 available

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

Sorry guys, I'm visiting Rome with my wife, which makes me a bit slow in
checking email.

It's commit c60ac2a4 "Fix for 1835 bug: BY presidency not transferred
during start round.", which is in origin/master, so it must exist in the
repo.
And git tells me I have nothing to push. On my side the bug appears to be
fixed.

This commit adds a new statement in StartRound.java line 303:
  if (comp.hasStarted()) comp.checkPresidency();  // Needed for 1835 BY

I hope this helps...

Erik.


> Erik:
> it seems that you forgot to push this fix.
> In master the bug still occurs and I have not found
> anything in the git logs.
> Could you please double-check again?
> Thanks,
> Stefan
>
> On 02/07/2012 11:03 PM, Erik Vos wrote:
>> Fixed. No presidency check was done in start rounds, this has now been
>> added.

Re: [Rails-devel] Release Rails 1.6.3 available

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

Erik:
enjoy your stay in Rome: Hopefully it was/is not as cold as everywhere 
else here in Europe?

Thanks for the info: It was my mistake (again) in using git cli and 
eclipse together. However the existing 1835 and a new test case I have 
added fail now. This is most likely related to the Clemens variant 
change of player priority and rerunning several 1835 in one instance, 
however this usually indicates some probability that it is not undo-proof.

So let us wait for you coming back to solve this jointly.

Stefan


On 02/11/2012 10:31 PM, Erik Vos wrote:
> Sorry guys, I'm visiting Rome with my wife, which makes me a bit slow in
> checking email.
>
> It's commit c60ac2a4 "Fix for 1835 bug: BY presidency not transferred
> during start round.", which is in origin/master, so it must exist in the
> repo.
> And git tells me I have nothing to push. On my side the bug appears to be
> fixed.
>
> This commit adds a new statement in StartRound.java line 303:
>    if (comp.hasStarted()) comp.checkPresidency();  // Needed for 1835 BY
>
> I hope this helps...
>
> Erik.
>
>
>> Erik:
>> it seems that you forgot to push this fix.
>> In master the bug still occurs and I have not found
>> anything in the git logs.
>> Could you please double-check again?
>> Thanks,
>> Stefan
>>
>> On 02/07/2012 11:03 PM, Erik Vos wrote:
>>> Fixed. No presidency check was done in start rounds, this has now been
>>> added.
>
>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Release Rails 1.6.3 available

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

> enjoy your stay in Rome: Hopefully it was/is not as cold as everywhere
else
> here in Europe?

Around freezing point, which is cold for Rome. It snowed a little, which
made the mayor panic and close all municipal musea (and schools and
offices), so we had to change plans.
The good side was that all those Vespa's weren't allowed to ride at all.
The worst was that the last two days the hotel heating was broken down.  The
cause seemed to be that the gas company had added some stuff to prevent the
gas to freeze (or so I understood from the apology that the hotel sent me by
mail in very bad English).

Anyway, I'm back at home now.

> Thanks for the info: It was my mistake (again) in using git cli and
eclipse
> together. However the existing 1835 and a new test case I have added fail
> now. This is most likely related to the Clemens variant change of player
> priority and rerunning several 1835 in one instance, however this usually
> indicates some probability that it is not undo-proof.
> 
> So let us wait for you coming back to solve this jointly.

I haven't looked at the non-standard 1835 variants for a long time, so it's
good to have a test case now.  
I only see 1835_NatDoubleShare failing, all other cases are OK.  Do you have
more failures?

I'll have a closer look later.

Erik.

Re: [Rails-devel] Release Rails 1.6.3 available

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

> > However the existing 1835 and a new test case I have added
> > fail now. This is most likely related to the Clemens variant change of
> > player priority and rerunning several 1835 in one instance, however
> > this usually indicates some probability that it is not undo-proof.
> >
> > So let us wait for you coming back to solve this jointly.
> 
> I haven't looked at the non-standard 1835 variants for a long time, so
it's
> good to have a test case now.
> I only see 1835_NatDoubleShare failing, all other cases are OK.  Do you
have
> more failures?

I don't understand why JUnit does things different from normal running.

The report expects:

BuysItemFor,T3,M5,80
FloatsWithCash,M5,80
BuysItemFor,T2,M1,80  <===
FloatsWithCash,M1,80
BuysItemFor,T1,M3,80
FloatsWithCash,M3,80

and that is exactly what happens in a normal run (extract from log):

2012-02-14 21:08:25 INFO   T3 buys M5 for 80M  (ReportBuffer addMessage 186)

2012-02-14 21:08:25 INFO   M5 floats and receives 80M  (ReportBuffer
addMessage 186) 
2012-02-14 21:08:25 INFO   T2 buys M1 for 80M  (ReportBuffer addMessage 186)
<===
2012-02-14 21:08:25 INFO   M1 floats and receives 80M  (ReportBuffer
addMessage 186) 
2012-02-14 21:08:25 INFO   T1 buys M3 for 80M  (ReportBuffer addMessage 186)

2012-02-14 21:08:25 INFO   M3 floats and receives 80M  (ReportBuffer
addMessage 186) 

so I'm amazed that the JUnit report says that >>T1<< has bought M3 in its
test run.

junit.framework.ComparisonFailure: Reports differ in line 13
expected:<BuysItemFor,T[2],M1,80> but was:<BuysItemFor,T[1],M1,80>

where line 13 corresponds to the lines where I added arrows.

I'm lost.

Erik.

[Rails-devel] 1835 automated game testing (was: Release Rails 1.6.3 available)

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

This mail was sent out earlier today, but I never got it returned from 
the list server. Please apologize if it turns it out to be 
double-posting for some.

Erik:
the issue for the automated game testing is easy to find.

You define the two (state) variables turn and startRoundNumber as static 
variables in StartRound_1835.

Keep in mind that all Junit tests run in sequence in the same JVM: So 
static variables carry over between games and the never get 
re-intialized between test games. In consequence for variants that 
adjust StartRound behavior will behave weird during testruns.

So question is what was your reason to use static (class) variables 
instead of standard (object) variables? I could only guess that the 
StartRound object is not undo-safe, thus you used the static variables 
as a workaround. I do not want submit this a fix, as long as I do not 
know your motivation there.

If I remove the static qualifier the games seem to run correctly, 
however some 1835 tests will be reported as failed, however this is most 
likely to the fact that the stored report is wrong and the newly 
generated one is correct.

I took the opportunity to copy the text of the e-mail that gave some 
detailed instructions on the automated game text into the wiki.
See 
http://sourceforge.net/apps/mediawiki/rails/index.php?title=Automated_game_testing

Stefan

A final remark:
I do not understand is why the Rails engine does not reject the
saved game file if the ordering of players in the save file is different 
to the one in the game engine, but I have not debugged
the whole process yet, as I expect to work everything correctly as soon 
as the static variables are removed.



On 02/14/2012 09:21 PM, Erik Vos wrote:
>>> However the existing 1835 and a new test case I have added
>>> fail now. This is most likely related to the Clemens variant change of
>>> player priority and rerunning several 1835 in one instance, however
>>> this usually indicates some probability that it is not undo-proof.
>>>
>>> So let us wait for you coming back to solve this jointly.
>>
>> I haven't looked at the non-standard 1835 variants for a long time, so
> it's
>> good to have a test case now.
>> I only see 1835_NatDoubleShare failing, all other cases are OK.  Do you
> have
>> more failures?
>
> I don't understand why JUnit does things different from normal running.
>
> The report expects:
>
> BuysItemFor,T3,M5,80
> FloatsWithCash,M5,80
> BuysItemFor,T2,M1,80<===
> FloatsWithCash,M1,80
> BuysItemFor,T1,M3,80
> FloatsWithCash,M3,80
>
> and that is exactly what happens in a normal run (extract from log):
>
> 2012-02-14 21:08:25 INFO   T3 buys M5 for 80M  (ReportBuffer addMessage 186)
>
> 2012-02-14 21:08:25 INFO   M5 floats and receives 80M  (ReportBuffer
> addMessage 186)
> 2012-02-14 21:08:25 INFO   T2 buys M1 for 80M  (ReportBuffer addMessage 186)
> <===
> 2012-02-14 21:08:25 INFO   M1 floats and receives 80M  (ReportBuffer
> addMessage 186)
> 2012-02-14 21:08:25 INFO   T1 buys M3 for 80M  (ReportBuffer addMessage 186)
>
> 2012-02-14 21:08:25 INFO   M3 floats and receives 80M  (ReportBuffer
> addMessage 186)
>
> so I'm amazed that the JUnit report says that>>T1<<  has bought M3 in its
> test run.
>
> junit.framework.ComparisonFailure: Reports differ in line 13
> expected:<BuysItemFor,T[2],M1,80>  but was:<BuysItemFor,T[1],M1,80>
>
> where line 13 corresponds to the lines where I added arrows.
>
> I'm lost.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835 automated game testing (was: Release Rails 1.6.3 available)

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

Ah OK.  StartRound and StartRound_1835 are very old, and I suppose these
static variables have so far been overlooked (in the past we had many more
static variables).
I'll give it another look tomorrow.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Wednesday, February 15, 2012 9:31 PM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] 1835 automated game testing (was: Release Rails
1.6.3
> available)
> 
> This mail was sent out earlier today, but I never got it returned from the
list
> server. Please apologize if it turns it out to be double-posting for some.
> 
> Erik:
> the issue for the automated game testing is easy to find.
> 
> You define the two (state) variables turn and startRoundNumber as static
> variables in StartRound_1835.
> 
> Keep in mind that all Junit tests run in sequence in the same JVM: So
static
> variables carry over between games and the never get re-intialized between
> test games. In consequence for variants that adjust StartRound behavior
will
> behave weird during testruns.
> 
> So question is what was your reason to use static (class) variables
instead of
> standard (object) variables? I could only guess that the StartRound object
is
> not undo-safe, thus you used the static variables as a workaround. I do
not
> want submit this a fix, as long as I do not know your motivation there.
> 
> If I remove the static qualifier the games seem to run correctly, however
> some 1835 tests will be reported as failed, however this is most likely to
the
> fact that the stored report is wrong and the newly generated one is
correct.
> 
> I took the opportunity to copy the text of the e-mail that gave some
detailed
> instructions on the automated game text into the wiki.
> See
> http://sourceforge.net/apps/mediawiki/rails/index.php?title=Automated_g
> ame_testing
> 
> Stefan
> 
> A final remark:
> I do not understand is why the Rails engine does not reject the saved game
> file if the ordering of players in the save file is different to the one
in the
> game engine, but I have not debugged the whole process yet, as I expect to
> work everything correctly as soon as the static variables are removed.
> 
> 
> 
> On 02/14/2012 09:21 PM, Erik Vos wrote:
> >>> However the existing 1835 and a new test case I have added fail now.
> >>> This is most likely related to the Clemens variant change of player
> >>> priority and rerunning several 1835 in one instance, however this
> >>> usually indicates some probability that it is not undo-proof.
> >>>
> >>> So let us wait for you coming back to solve this jointly.
> >>
> >> I haven't looked at the non-standard 1835 variants for a long time,
> >> so
> > it's
> >> good to have a test case now.
> >> I only see 1835_NatDoubleShare failing, all other cases are OK.  Do
> >> you
> > have
> >> more failures?
> >
> > I don't understand why JUnit does things different from normal running.
> >
> > The report expects:
> >
> > BuysItemFor,T3,M5,80
> > FloatsWithCash,M5,80
> > BuysItemFor,T2,M1,80<===
> > FloatsWithCash,M1,80
> > BuysItemFor,T1,M3,80
> > FloatsWithCash,M3,80
> >
> > and that is exactly what happens in a normal run (extract from log):
> >
> > 2012-02-14 21:08:25 INFO   T3 buys M5 for 80M  (ReportBuffer addMessage
> 186)
> >
> > 2012-02-14 21:08:25 INFO   M5 floats and receives 80M  (ReportBuffer
> > addMessage 186)
> > 2012-02-14 21:08:25 INFO   T2 buys M1 for 80M  (ReportBuffer addMessage
> 186)
> > <===
> > 2012-02-14 21:08:25 INFO   M1 floats and receives 80M  (ReportBuffer
> > addMessage 186)
> > 2012-02-14 21:08:25 INFO   T1 buys M3 for 80M  (ReportBuffer addMessage
> 186)
> >
> > 2012-02-14 21:08:25 INFO   M3 floats and receives 80M  (ReportBuffer
> > addMessage 186)
> >
> > so I'm amazed that the JUnit report says that>>T1<<  has bought M3 in
> > its test run.
> >
> > junit.framework.ComparisonFailure: Reports differ in line 13
> > expected:<BuysItemFor,T[2],M1,80>  but was:<BuysItemFor,T[1],M1,80>
> >
> > where line 13 corresponds to the lines where I added arrows.
> >
> > I'm lost.
> >
> > Erik.
> >
> >
> > ----------------------------------------------------------------------
> > -------- Keep Your Developer Skills Current with LearnDevNow!
> > The most comprehensive online learning library for Microsoft
> > developers is just $99.99! Visual Studio, SharePoint, SQL - plus
> > HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when
> you subscribe now!
> > http://p.sf.net/sfu/learndevnow-d2d
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> Virtualization & Cloud Management Using Capacity Planning Cloud computing
> makes use of virtualization - but cloud computing also focuses on allowing
> computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1835 automated game testing (was: Release Rails 1.6.3 available)

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

I have pushed a fix, that made both variables non-static.

The start round number has been moved to GameManager (as have the SR and OR
numbers long ago).
So the start round number now is a generic feature, although it is only used
in some 1835 variants yet.

The tests now work again.  I had to replace the reports of two more cases,
which didn't have the turn order right.

Erik.


> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Thursday, February 16, 2012 12:27 AM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] 1835 automated game testing (was: Release Rails
> 1.6.3 available)
> 
> Ah OK.  StartRound and StartRound_1835 are very old, and I suppose these
> static variables have so far been overlooked (in the past we had many more
> static variables).
> I'll give it another look tomorrow.
> 
> Erik.
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Wednesday, February 15, 2012 9:31 PM
> > To: Development list for Rails: an 18xx game
> > Subject: [Rails-devel] 1835 automated game testing (was: Release Rails
> 1.6.3
> > available)
> >
> > This mail was sent out earlier today, but I never got it returned from
> > the
> list
> > server. Please apologize if it turns it out to be double-posting for
some.
> >
> > Erik:
> > the issue for the automated game testing is easy to find.
> >
> > You define the two (state) variables turn and startRoundNumber as
> > static variables in StartRound_1835.
> >
> > Keep in mind that all Junit tests run in sequence in the same JVM: So
> static
> > variables carry over between games and the never get re-intialized
> > between test games. In consequence for variants that adjust StartRound
> > behavior
> will
> > behave weird during testruns.
> >
> > So question is what was your reason to use static (class) variables
> instead of
> > standard (object) variables? I could only guess that the StartRound
> > object
> is
> > not undo-safe, thus you used the static variables as a workaround. I
> > do
> not
> > want submit this a fix, as long as I do not know your motivation there.
> >
> > If I remove the static qualifier the games seem to run correctly,
> > however some 1835 tests will be reported as failed, however this is
> > most likely to
> the
> > fact that the stored report is wrong and the newly generated one is
> correct.
> >
> > I took the opportunity to copy the text of the e-mail that gave some
> detailed
> > instructions on the automated game text into the wiki.
> > See
> > http://sourceforge.net/apps/mediawiki/rails/index.php?title=Automated_
> > g
> > ame_testing
> >
> > Stefan
> >
> > A final remark:
> > I do not understand is why the Rails engine does not reject the saved
> > game file if the ordering of players in the save file is different to
> > the one
> in the
> > game engine, but I have not debugged the whole process yet, as I
> > expect to work everything correctly as soon as the static variables are
> removed.
> >
> >
> >
> > On 02/14/2012 09:21 PM, Erik Vos wrote:
> > >>> However the existing 1835 and a new test case I have added fail now.
> > >>> This is most likely related to the Clemens variant change of
> > >>> player priority and rerunning several 1835 in one instance,
> > >>> however this usually indicates some probability that it is not undo-
> proof.
> > >>>
> > >>> So let us wait for you coming back to solve this jointly.
> > >>
> > >> I haven't looked at the non-standard 1835 variants for a long time,
> > >> so
> > > it's
> > >> good to have a test case now.
> > >> I only see 1835_NatDoubleShare failing, all other cases are OK.  Do
> > >> you
> > > have
> > >> more failures?
> > >
> > > I don't understand why JUnit does things different from normal
running.
> > >
> > > The report expects:
> > >
> > > BuysItemFor,T3,M5,80
> > > FloatsWithCash,M5,80
> > > BuysItemFor,T2,M1,80<===
> > > FloatsWithCash,M1,80
> > > BuysItemFor,T1,M3,80
> > > FloatsWithCash,M3,80
> > >
> > > and that is exactly what happens in a normal run (extract from log):
> > >
> > > 2012-02-14 21:08:25 INFO   T3 buys M5 for 80M  (ReportBuffer
> addMessage
> > 186)
> > >
> > > 2012-02-14 21:08:25 INFO   M5 floats and receives 80M  (ReportBuffer
> > > addMessage 186)
> > > 2012-02-14 21:08:25 INFO   T2 buys M1 for 80M  (ReportBuffer
> addMessage
> > 186)
> > > <===
> > > 2012-02-14 21:08:25 INFO   M1 floats and receives 80M  (ReportBuffer
> > > addMessage 186)
> > > 2012-02-14 21:08:25 INFO   T1 buys M3 for 80M  (ReportBuffer
> addMessage
> > 186)
> > >
> > > 2012-02-14 21:08:25 INFO   M3 floats and receives 80M  (ReportBuffer
> > > addMessage 186)
> > >
> > > so I'm amazed that the JUnit report says that>>T1<<  has bought M3
> > > in its test run.
> > >
> > > junit.framework.ComparisonFailure: Reports differ in line 13
> > > expected:<BuysItemFor,T[2],M1,80>  but was:<BuysItemFor,T[1],M1,80>
> > >
> > > where line 13 corresponds to the lines where I added arrows.
> > >
> > > I'm lost.
> > >
> > > Erik.
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > -------- Keep Your Developer Skills Current with LearnDevNow!
> > > The most comprehensive online learning library for Microsoft
> > > developers is just $99.99! Visual Studio, SharePoint, SQL - plus
> > > HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when
> > you subscribe now!
> > > http://p.sf.net/sfu/learndevnow-d2d
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> >
>
----------------------------------------------------------------------------
> --
> > Virtualization & Cloud Management Using Capacity Planning Cloud
> > computing makes use of virtualization - but cloud computing also
> > focuses on allowing computing to be delivered as a service.
> > http://www.accelacomm.com/jaw/sfnl/114/51521223/
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> Virtualization & Cloud Management Using Capacity Planning Cloud computing
> makes use of virtualization - but cloud computing also focuses on allowing
> computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] 1835 automated game testing (was: Release Rails 1.6.3 available)

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

Erik:
the issue for the automated game testing is easy to find.

You define the two (state) variables turn and startRoundNumber as static 
variables in StartRound_1835.

Keep in mind that all Junit tests run in sequence in the same JVM: So 
static variables carry over between games and the never get 
re-intialized between test games. In consequence for variants that 
adjust StartRound behavior will behave weird during testruns.

So question is what was your reason to use static (class) variables 
instead of standard (object) variables? I could only guess that the 
StartRound object is not undo-safe, thus you used the static variables 
as a workaround. I do not want submit this a fix, as long as I do not 
know your motivation there.

If I remove the static qualifier the games seem to run correctly, 
however some 1835 tests will be reported as failed, however this is most 
likely to the fact that the stored report is wrong and the newly 
generated one is correct.

I took the opportunity to copy the text of the e-mail that gave some 
detailed instructions on the automated game text into the wiki.
See 
http://sourceforge.net/apps/mediawiki/rails/index.php?title=Automated_game_testing

Stefan

A final remark:
I do not understand is why the Rails engine does not reject the
saved game file if the ordering of players in the save file is different 
to the one in the game engine, but I have not debugged
the whole process yet, as I expect to work everything correctly as soon 
as the static variables are removed.



On 02/14/2012 09:21 PM, Erik Vos wrote:
>>> However the existing 1835 and a new test case I have added
>>> fail now. This is most likely related to the Clemens variant change of
>>> player priority and rerunning several 1835 in one instance, however
>>> this usually indicates some probability that it is not undo-proof.
>>>
>>> So let us wait for you coming back to solve this jointly.
>>
>> I haven't looked at the non-standard 1835 variants for a long time, so
> it's
>> good to have a test case now.
>> I only see 1835_NatDoubleShare failing, all other cases are OK.  Do you
> have
>> more failures?
>
> I don't understand why JUnit does things different from normal running.
>
> The report expects:
>
> BuysItemFor,T3,M5,80
> FloatsWithCash,M5,80
> BuysItemFor,T2,M1,80<===
> FloatsWithCash,M1,80
> BuysItemFor,T1,M3,80
> FloatsWithCash,M3,80
>
> and that is exactly what happens in a normal run (extract from log):
>
> 2012-02-14 21:08:25 INFO   T3 buys M5 for 80M  (ReportBuffer addMessage 186)
>
> 2012-02-14 21:08:25 INFO   M5 floats and receives 80M  (ReportBuffer
> addMessage 186)
> 2012-02-14 21:08:25 INFO   T2 buys M1 for 80M  (ReportBuffer addMessage 186)
> <===
> 2012-02-14 21:08:25 INFO   M1 floats and receives 80M  (ReportBuffer
> addMessage 186)
> 2012-02-14 21:08:25 INFO   T1 buys M3 for 80M  (ReportBuffer addMessage 186)
>
> 2012-02-14 21:08:25 INFO   M3 floats and receives 80M  (ReportBuffer
> addMessage 186)
>
> so I'm amazed that the JUnit report says that>>T1<<  has bought M3 in its
> test run.
>
> junit.framework.ComparisonFailure: Reports differ in line 13
> expected:<BuysItemFor,T[2],M1,80>  but was:<BuysItemFor,T[1],M1,80>
>
> where line 13 corresponds to the lines where I added arrows.
>
> I'm lost.
>
> Erik.
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel