rails-devel — List for discussion of Rails development

Re: [Rails-devel] Route calculation for huge runs

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

see below

On Wednesday, August 10, 2011 06:54:58 am John A. Tamplin wrote:
> On Wed, Aug 10, 2011 at 12:04 AM, Bill Rosgen <ro...@gm...> wrote:
> > Is the problem really solvable?  The planar cubic hamiltonian path
> > problem is NP-complete (see Garey, Johnson, and Tarjan 1976, which seems
> > to be available at
> > http://www.cs.princeton.edu/courses/archive/spr04/cos423/handouts/the%20p
> > lanar%20hamiltonian.pdf).  The title of the paper involves cycles, but
> > the text on page 713 claims it holds also for paths.  I have not
> > verified the results of the paper, but it appears in a very good journal
> > and so is likely to be correct.
> > 
> > I think the problem is equivalent to optimizing the run of only one
> > diesel on such a graph.  Given any planar graph with degree 3, it can be
> > implemented as an 18xx map with cities as vertices and track as edges,
> > though the map may get pretty large (though still polynomial in the
> > number of cities).  Imagine such a map with only one company (with a
> > token somewhere) that owns one diesel.  That train can hit every city if
> > and only if there is a Hamiltonian path in the original graph.
> 
> I don't think it is equivalent to Hamiltonian path on an arbitrary graph,
> and there are polynomial solutions for Hamiltonian path on many types of
> restricted graphs.  Also, you aren't actually asking is there a path that
> visits all cities but instead what is the best path that can be obtained.
> 
> > Practically this doesn't say that much, as we don't have arbitrarily
> > large graphs, and many of the trains in 18xx games run for some constant
> > length, but it might imply that a general purpose poly-time algorithm is
> > going to be difficult to find.
> 
> I agree, in particular I think being able to skip stops and double an
> arbitrary stop are things that would make anything short of brute
> force intractable.


This reminds me of getting involved into discussions of asymptotic behaviors 
by the econometrics theory people if I ask a question how to solve an 
econometric problem in an empirical applied context: I feel intimidated and 
stupid ;-)

And usually the number of answers exceeds the number of questions by a large 
multiple...

However what I take from this is that most likely that a polynomial solution 
exists (as John was able to find one 24 years ago) to the diesel/12 train 
scenario and that the existing algorithm covers the exotic train cases.

Re: [Rails-devel] Route calculation for huge runs

[Bill R. <ro...@gm...>]

On 2011-08-10, at 12:54 , John A. Tamplin wrote:

> On Wed, Aug 10, 2011 at 12:04 AM, Bill Rosgen <ro...@gm...> wrote:
>> I think the problem is equivalent to optimizing the run of only one diesel on such a graph.  Given any planar graph with degree 3, it can be implemented as an 18xx map with cities as vertices and track as edges, though the map may get pretty large (though still polynomial in the number of cities).  Imagine such a map with only one company (with a token somewhere) that owns one diesel.  That train can hit every city if and only if there is a Hamiltonian path in the original graph.
>> 
> I don't think it is equivalent to Hamiltonian path on an arbitrary graph, and there are polynomial solutions for Hamiltonian path on many types of restricted graphs.  Also, you aren't actually asking is there a path that visits all cities but instead what is the best path that can be obtained.

But on a cubic planar graph the Hamiltonian path problem remains NP-complete (as shown in the paper of Garey, Johnson, and Tarjan).  Cubic planar graphs can be represented as 18xx maps.  The best path on such a map, if one exists, is the one that visits all cities.  This implies that if there is a general algorithm for 18xx maps that works in the case of one company with one token and one diesel, it also can be used to decide whether or not a cubic planar graph has a Hamiltonian path.

Bill

Re: [Rails-devel] Route calculation for huge runs

[John A. T. <ja...@ja...>]

On Wed, Aug 10, 2011 at 12:04 AM, Bill Rosgen <ro...@gm...> wrote:

> Is the problem really solvable?  The planar cubic hamiltonian path problem
> is NP-complete (see Garey, Johnson, and Tarjan 1976, which seems to be
> available at
> http://www.cs.princeton.edu/courses/archive/spr04/cos423/handouts/the%20planar%20hamiltonian.pdf).  The title of the paper involves cycles, but the text on page 713 claims
> it holds also for paths.  I have not verified the results of the paper, but
> it appears in a very good journal and so is likely to be correct.
>
> I think the problem is equivalent to optimizing the run of only one diesel
> on such a graph.  Given any planar graph with degree 3, it can be
> implemented as an 18xx map with cities as vertices and track as edges,
> though the map may get pretty large (though still polynomial in the number
> of cities).  Imagine such a map with only one company (with a token
> somewhere) that owns one diesel.  That train can hit every city if and only
> if there is a Hamiltonian path in the original graph.
>

I don't think it is equivalent to Hamiltonian path on an arbitrary graph,
and there are polynomial solutions for Hamiltonian path on many types of
restricted graphs.  Also, you aren't actually asking is there a path that
visits all cities but instead what is the best path that can be obtained.


> Practically this doesn't say that much, as we don't have arbitrarily large
> graphs, and many of the trains in 18xx games run for some constant length,
> but it might imply that a general purpose poly-time algorithm is going to be
> difficult to find.


I agree, in particular I think being able to skip stops and double an
arbitrary stop are things that would make anything short of brute
force intractable.

-- 
John A. Tamplin

Re: [Rails-devel] Route calculation for huge runs

[Bill R. <ro...@gm...>]

On 2011-08-09, at 15:41 , Stefan Frey wrote:
> John,
> thanks for your comments. 
> Good thing to know that first you were able to solve it (I hate working on 
> unsolvable problems in my free time) and second that it did not take anything 
> too extraordinary graph theory stuff to solve it. Third it shows the direction 
> to go to adjust the graph to incorporate the train constraints (I have some 
> ideas how to do that). An alternative might be to use a linear programming 
> algorithm to solve the flow problem which (potentially) makes adding other 
> constraints easier.
> 
> Can I ask you for reviewing my proposals, this might even help you retrieve 
> the ideas you had 24 years ago.
> Stefan

Is the problem really solvable?  The planar cubic hamiltonian path problem is NP-complete (see Garey, Johnson, and Tarjan 1976, which seems to be available at http://www.cs.princeton.edu/courses/archive/spr04/cos423/handouts/the%20planar%20hamiltonian.pdf ).  The title of the paper involves cycles, but the text on page 713 claims it holds also for paths.  I have not verified the results of the paper, but it appears in a very good journal and so is likely to be correct.

I think the problem is equivalent to optimizing the run of only one diesel on such a graph.  Given any planar graph with degree 3, it can be implemented as an 18xx map with cities as vertices and track as edges, though the map may get pretty large (though still polynomial in the number of cities).  Imagine such a map with only one company (with a token somewhere) that owns one diesel.  That train can hit every city if and only if there is a Hamiltonian path in the original graph.

Practically this doesn't say that much, as we don't have arbitrarily large graphs, and many of the trains in 18xx games run for some constant length, but it might imply that a general purpose poly-time algorithm is going to be difficult to find.

Bill Rosgen

[Rails-devel] Phase mgmt step 4, and 18TN Civil War (cee06b)

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

I have implemented:

1. Phase management step 4: <Phase> can now have an <Action> child with
(required) name and (optional) value attributes.
Each action causes gameManager.processPhaseAction (name, value) to be called
when that phase is activated.  
GameManager in turn calls processPhaseAction(name, value) in the current
round.

2. This new feature is used to implement 18TN Civil War (except the revenue
calculation).
The new code is in OperatingRound_18TN (updated) and PublicCompany_18TN
(new).
The latter method has a civilWar BooleanState that is set and unset
according to the 18TN rules.  This already works. 

3. To fully implement the 18TN rules, the CivilWar setting also requires
publicCompany.hasRoute() to return true. 
This is a new stub that always returns true (and is not used anywhere else
yet).
I hope we will once be able to detect route existence in the game engine.

Stefan, I trust you will now be able to finish 18TN completely by
implementing the effect of the Civil War on the revenue calculation.

To check the company CivilWar status you could call its isCivilWar() method
directly , but from an architectural POV (client/server separation) it would
be preferable, if at all possible, to create an Observer (ViewObject) per
company to register at the ModelObject (=BooleanState) via the company
getCivilWar() method.  

Erik.

Re: [Rails-devel] Output of failed tests (a3aed4)

[John A. T. <ja...@ja...>]

On Tue, Aug 9, 2011 at 12:25 PM, Stefan Frey <ste...@we...> wrote:

> The encoding (at least accoding to my editor) of the report files is still
> UTF-8 and they open up in the editor correctly.
> All tests report passed as well.
> However to avoid those issues I suggest to remove the currency indicator
> from
> the report files used for testing.
> I can do the code change tomorrow.
>

It won't be just currency characters -- you would have to avoid all names in
the game as well.

Better to make sure everything is always stored as UTF8 and interpreted as
UTF8 and be done with it.

-- 
John A. Tamplin

Re: [Rails-devel] Changed setup of the rails repo

[brett l. <bre...@gm...>]

On Tue, Aug 9, 2011 at 9:21 AM, Stefan Frey <ste...@we...> wrote:
> For some files/folders I do not know exactly why they are created.
>
> * Folder rails:
> My preferred solution here is to create two directories src/ and unit/.
>

I'm okay with doing this. As we're getting more unit tests, it makes
sense to start organizing them.

> Then move the rails/ folder to src/ and over time mirror the directory
> structure of rails/ inside unit/ for unit tests.
>
> I do not really favor to mirror the full java package names in the folder
> structure, but I can live with any outcome.
>

The convention is primarily due to the way Java looks for classes
within the classpath. We've already got a custom class loader to
assist in locating classes outside of the classpath, which helps work
around or obfuscate this issue, depending on your perspective.

I don't really care what our package names are. I do think they should
align with the directory structure in order to help avoid classpath
search issues.

> * Folder test:
> I would like to keep the automated game tests (functional tests) under src/,
> as they are not unit tests and TestGame and TestGameBuilder could in principle
> be tested themselves by unit tests. UI tests and automated tests of revenue
> calculations would find their place there too.
> I do not know if the other classes inside test are used, otherwise I suggest
> removing them.

I disagree. The only thing under src should be actual game code. The
distinction between functional and unit tests may be important enough
to segregate the types of tests, but they should all be under the same
tree outside of src.

How about this:

- src/
- test/
--- unit/
--- functional/


>
> * File 18xx_autosave.rails
> Gets created automatically from a running game as eclipse uses the folder as
> the current working directory.  Should be either ignored or in a working
> directory outside of the repository.
>

Yup. This, the 18xx.log, and any other files created at runtime need
to be in the .git/info/exclude file.

> * File log4j.properties
> Stores the part of my.properties that have to do with logging and were not
> replaced by the new profile mechanism. Should be stored inside the repo to be
> available at the start of Rails.
>
> * File my.properties
> Legacy file to set configurations. Now replaced by the new profil mechanism.
> Can be removed.
>

Ok. Remove it.

> * File user.profiles
> Gets created automatically from a running Rails instance to store a map of
> profile names to the locations of the profile files for a user.
> Same as 18xx_autosave.rails

Yep. Exclude it from the repository, too.

---Brett.

>
> On Monday, August 08, 2011 09:20:29 pm Erik Vos wrote:
>> > Is it ok with you (Erik & Brett) to create an additional layer with src/
>>
>> and
>>
>> > junit/?
>>
>> I was actually wondering why Eclipse/Egit didn't let me create the src/
>> layer, so basically I'm all for it.
>> But what are the consequences? I don't hope I'll have to set it all up yet
>> another time.
>>
>> > EclEmma coverage tool reported an overall code coverage of 40.2% after
>> > running all automated game tests (which is not too bad given that UI and
>> > algorithm packages are not tested by construction, the rails/game package
>> > itself has 73.8% coverage).
>> >
>> > My preferred mock library is JMock, any comments/preferences for this?
>>
>> No.
>>
>> Erik.
>>
>>
>>
>> ---------------------------------------------------------------------------
>> --- BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
>> The must-attend event for mobile developers. Connect with experts.
>> Get tools for creating Super Apps. See the latest technologies.
>> Sessions, hands-on labs, demos & much more. Register early & save!
>> http://p.sf.net/sfu/rim-blackberry-1
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Output of failed tests (a3aed4)

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

Erik,
The encoding (at least accoding to my editor) of the report files is still 
UTF-8 and they open up in the editor correctly.
All tests report passed as well.
However to avoid those issues I suggest to remove the currency indicator from 
the report files used for testing.
I can do the code change tomorrow.
Stefan



On Tuesday, August 09, 2011 03:44:12 pm Erik Vos wrote:
> Stefan,
> 
> Not sure what has changed, but on another attempt to run the JUnit tests
> I'm getting massive differences, all related to one specific special
> character being differently encoded.
> Error messages are like:
> 
> real\1889_A(test.TestGame)
> junit.framework.ComparisonFailure: Reports differ in line 5
> expected:<PlayerCash,[Â]¥420> but was:<PlayerCash,[]¥420>
> 
> and
> 
> real\18EU_A(test.TestGame)
> junit.framework.ComparisonFailure: Reports differ in line 611
> expected:<...OMPANY_LOG,Joakim,KK[ÖB,$70,$140,2,20,KKÖ]B> but
> was:<...OMPANY_LOG,Joakim,KK[ÖB,$70,$140,2,20,KKÖ]B>
> 
> Only 1889 (on the ¥) and 18EU (on the Ö) fail this way.  No more failures
> with other games.
> My best guess for a cause is that Unicode characters in the .report files
> are no longer recognised as such.  Can the formats in the repository have
> changed?
> 
> Erik.
> 
> > -----Original Message-----
> > From: Erik Vos [mailto:eri...@xs...]
> > Sent: Saturday, August 06, 2011 11:48 AM
> > To: 'Development list for Rails: an 18xx game'
> > Subject: Re: [Rails-devel] Output of failed tests (a3aed4)
> > 
> > The nice thing about tools like WinMerge is that you can compare whole
> > directory trees, making it show (for instance) the different files only,
> 
> which
> 
> > obviously must the have the same name to make this work.  I have been
> > using that often to compare different versions of some tree, and have
> > done so with Rails in the past.
> > 
> > But of course it can also load single pairs of files to compare.  Don't
> 
> worry, the
> 
> > Rails test set is still small enough to make the one-by-one comparisons
> 
> easy
> 
> > to do, in particular if only the failed files are saved.
> > 
> > Erik.
> 
> ---------------------------------------------------------------------------
> --- uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Changed setup of the rails repo

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

Erik & Brett,

a quick test showed that it will take a little reconfiguration to get 
everything working. To make life easier for all, I suggest to compile a 
complete list of the items and possible solutions for them jointly in the top 
Rails directory. See below. 

Stefan

Complete list of the files/folders inside:

* folders:
classes
data
doc
html
images
lib
rails
tiles
tools

* files:
18xx.log
18xx_autosave.rails
AUTHORS
LICENSE
LocalisedText.properties
README
Rails-format.xml
build.xml
buildinfo.xml
log4j.properties
manifest
my.properties
rails.bat
rails.sh
user.profiles

For some files/folders I do not know exactly why they are created.

* Folder rails:
My preferred solution here is to create two directories src/ and unit/.

Then move the rails/ folder to src/ and over time mirror the directory 
structure of rails/ inside unit/ for unit tests.

I do not really favor to mirror the full java package names in the folder 
structure, but I can live with any outcome.

* Folder test:
I would like to keep the automated game tests (functional tests) under src/,
as they are not unit tests and TestGame and TestGameBuilder could in principle 
be tested themselves by unit tests. UI tests and automated tests of revenue 
calculations would find their place there too.
I do not know if the other classes inside test are used, otherwise I suggest 
removing them.

* File 18xx_autosave.rails
Gets created automatically from a running game as eclipse uses the folder as 
the current working directory.  Should be either ignored or in a working 
directory outside of the repository.

* File log4j.properties
Stores the part of my.properties that have to do with logging and were not 
replaced by the new profile mechanism. Should be stored inside the repo to be 
available at the start of Rails.

* File my.properties
Legacy file to set configurations. Now replaced by the new profil mechanism.
Can be removed.

* File user.profiles
Gets created automatically from a running Rails instance to store a map of 
profile names to the locations of the profile files for a user.
Same as 18xx_autosave.rails










On Monday, August 08, 2011 09:20:29 pm Erik Vos wrote:
> > Is it ok with you (Erik & Brett) to create an additional layer with src/
> 
> and
> 
> > junit/?
> 
> I was actually wondering why Eclipse/Egit didn't let me create the src/
> layer, so basically I'm all for it.
> But what are the consequences? I don't hope I'll have to set it all up yet
> another time.
> 
> > EclEmma coverage tool reported an overall code coverage of 40.2% after
> > running all automated game tests (which is not too bad given that UI and
> > algorithm packages are not tested by construction, the rails/game package
> > itself has 73.8% coverage).
> > 
> > My preferred mock library is JMock, any comments/preferences for this?
> 
> No.
> 
> Erik.
> 
> 
> 
> ---------------------------------------------------------------------------
> --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Output of failed tests (a3aed4)

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

Stefan,

Not sure what has changed, but on another attempt to run the JUnit tests I'm
getting massive differences, all related to one specific special character
being differently encoded. 
Error messages are like:

real\1889_A(test.TestGame)
junit.framework.ComparisonFailure: Reports differ in line 5
expected:<PlayerCash,[Â]¥420> but was:<PlayerCash,[]¥420>

and 

real\18EU_A(test.TestGame)
junit.framework.ComparisonFailure: Reports differ in line 611
expected:<...OMPANY_LOG,Joakim,KK[ÖB,$70,$140,2,20,KKÖ]B> but
was:<...OMPANY_LOG,Joakim,KK[ÖB,$70,$140,2,20,KKÖ]B>

Only 1889 (on the ¥) and 18EU (on the Ö) fail this way.  No more failures
with other games.
My best guess for a cause is that Unicode characters in the .report files
are no longer recognised as such.  Can the formats in the repository have
changed?

Erik.


> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Saturday, August 06, 2011 11:48 AM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] Output of failed tests (a3aed4)
> 
> The nice thing about tools like WinMerge is that you can compare whole
> directory trees, making it show (for instance) the different files only,
which
> obviously must the have the same name to make this work.  I have been
> using that often to compare different versions of some tree, and have done
> so with Rails in the past.
> 
> But of course it can also load single pairs of files to compare.  Don't
worry, the
> Rails test set is still small enough to make the one-by-one comparisons
easy
> to do, in particular if only the failed files are saved.
> 
> Erik.

Re: [Rails-devel] Route calculation: Train length heuristic

[Phil D. <de...@gm...>]

Ed,

I've forwarded it off-list

Phil

On 9 August 2011 10:48, Edward S. Rustin <ed...@we...> wrote:
> Is there a copy of the rails file that Aliza's problem stems from?
>
> I've been playing around with a few ideas for calculating optimal routes,
> but I'd rather not write a long post explaining them without having tried
> them out on a map which is already known to be tricky - much less risk of
> making an ass out of myself that way :-)
>
> On Tue, Aug 9, 2011 at 06:02, Stefan Frey <ste...@we...> wrote:
>>
>> A year ago I suggested another heuristic to improve the speed of the
>> revenue
>> calculation.
>>
>> The idea is to use what 1830 players automatically do:
>> If you calculate a run for a 4 and a 3 train, you already know that you
>> will
>> end up with a longer route (more stations) for the 4 train and a shorter
>> route
>> for the 3 train. Similar for running a Diesel and a 5 train.
>>
>> However this knowledge is not taken into account by the current algorithm.
>> Things unfortunately are not that easy for all 18xx as it are in 1830.
>> For example in 1835 one cannot tell this ex-ante for a combination of a
>> 5+5
>> and a 6 train. That in fact is one the reasons why calculating the
>> Preussian
>> routes is not an easy task.
>>
>> Another exceptions are: If trains score differently for the same route
>> (Express (xE) and Double (xD) trains) or if hex trains run jointly with
>> standard trains.
>>
>> ** The formal definition of train domination:
>>
>> If the "better" train A can run all routes that the "weaker" train B and
>> train
>> A scores identical revenue on all routes as B, then I define that train A
>> dominates train B.
>>
>> If A dominates B I write this as A>B, otherwise the trains are either
>> identical (A=B) or neither dominates (A<>B).
>>
>> If train A dominates train B, the length of the route of train A will
>> always
>> be longer or at least equally long as that of train B.
>> (Length of the route is the number of stations scored.)
>>
>> ** Examples should make this clearer.
>>
>> In 1830 it is easy:  D>6>5>4>3>2
>>
>> In 1835 it is
>> 6+6 > 5+5 > 4+4 > 3+3 > 2+2
>> 6 > 5 > 4 > 3 > 2
>> 6+6 > 6, 5+5 > 5, 4 +4 > 4, 3+3 > 3, 2+2 > 2
>> 6 > 3+3, 4 > 2+2
>> But for example: 6 <> 5+5, 5 <> 3+3 etc.
>>
>> ** Implementation
>> The implementation is pretty straight forward and only requires a few
>> lines of
>> code in the revenue calculator. The major change is to order the trains by
>> the
>> criteria "train domination". Then the calculator assigns the initial train
>> length for the dominated train not with the maximum length of that train,
>> but
>> with the (current) route length of the dominating train. This ensures that
>> the
>> dominating train will always have the longer route assigned.
>>
>> ** Speed improvement
>> I did run the scenarios of Aliza Panitz 1856 triple Diesel of CGR
>> scenarios
>> and came to the following running times (more statistics on number of
>> routes
>> evaluated and when the best solution was found see below).
>>
>> For the simpler network (A) running times decrease from around 5 minutes
>> to
>> 3.5 minutes (my CPU is more powerful than Alizas ...).
>> For the extensive network (B) running times decrease from around 1 hour to
>> around 30 minutes.
>>
>> Overall the improvement it seems that the speed is improved by around 50%
>> to
>> 200%, so time to wait is down by 33% to 66%, which is not bad.
>>
>> But as it can be clearly seen by comparison with a double Diesel scenarios
>> the
>> exponential characteristic of the algorithm is still very clear.
>>
>> So I still hope that John Tamplin can give some hints on his lost flow
>> algorithm for those who want to run triple Diesel more often.
>>
>> Stefan
>>
>> ** Stats
>>
>> => Aliza Scenario 1856 A:
>> 31 vertices with 41 edges
>> 10 startvertices
>>
>> Values:
>> Single D: 700
>> Double D: 920
>> Triple D: 1120
>>
>> Single D: 0 second / 6.2k Evaluations, 6.2k Predictions
>>
>> Without dominant trains:
>> Double D: 3 seconds / 1.3M Evaluations, 1.4M Predictions
>> Triple D: 290 seconds / 114.9M Evaluations, 129.5M Predictions
>> (Solution: 25 seconds / 13.4M Evaluations, 14.7M Predictions)
>>
>> With dominant trains:
>> Double D: 1 second / 323k Evaluations, 385k Predictions
>> Triple D: 206 seconds / 87.4M Evaluations, 98.0M Predictions
>> (Solution: 20 seconds / 9.1M Evaluations, 10.0M Predictions)
>>
>> => Aliza Scenario 1856 B:
>> 34 vertices with 50 edges
>> 10 startvertices
>>
>> Values:
>> Single D: 790
>> Double D: 1280
>> Triple D: 1440
>>
>> Single D: 0 second / 53.3k Evaluations, 53.3k Predictions
>>
>> Without dominant trains:
>> Double D: 12 seconds / 4.8M Evaluations, 5.1M Predictions
>> Triple D: 3551 seconds / 1473M Evaluations, 1709M Predictions
>> (Solution: 41 seconds / 16.9M Evaluations, 17.7M Predictions)
>>
>> With dominant trains:
>> Double D: 5 seconds / 1.9M Evaluations, 2.3M Predictions
>> Triple D: 1926 seconds / 832M Evaluations, 962M Predictions
>> (Solution: 27 seconds / 11.7M Evaluations, 12.3M Predictions)
>>
>> => Scenario 1870:
>> This is the route network used for testing a year ago,
>>
>> 23 vertices with 57 edges
>> 1 startvertex
>>
>> Values:
>> Single 12: 380
>> Double 12: 690
>> Triple 12: 820
>>
>> Single 12: 0 second / 11.5k Evaluations, 23.7k Predictions
>>
>> Without dominant trains:
>> Double 12: 4 seconds / 1.4M Evaluations, 1.9M Predictions
>> Triple 12: 104 seconds / 23.4M Evaluations, 61.6M Predictions
>> (Solution: 13 seconds / 3.2M Evaluations, 6.2M Predictions)
>>
>> With dominant trains:
>> Double 12: 4 seconds / 1.2M Evaluations, 1.7M Predictions
>> Triple 12: 49 seconds / 8.1M Evaluations, 30.0M Predictions
>> (Solution: 16 seconds / 3.0M Evaluations, 9.3M Predictions)
>>
>>
>> ------------------------------------------------------------------------------
>> uberSVN's rich system and user administration capabilities and model
>> configuration take the hassle out of deploying and managing Subversion and
>> the tools developers use with it. Learn more about uberSVN and get a free
>> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Route calculation: Train length heuristic

[Edward S. R. <ed...@we...>]

Is there a copy of the rails file that Aliza's problem stems from?

I've been playing around with a few ideas for calculating optimal routes,
but I'd rather not write a long post explaining them without having tried
them out on a map which is already known to be tricky - much less risk of
making an ass out of myself that way :-)

On Tue, Aug 9, 2011 at 06:02, Stefan Frey <ste...@we...> wrote:

> A year ago I suggested another heuristic to improve the speed of the
> revenue
> calculation.
>
> The idea is to use what 1830 players automatically do:
> If you calculate a run for a 4 and a 3 train, you already know that you
> will
> end up with a longer route (more stations) for the 4 train and a shorter
> route
> for the 3 train. Similar for running a Diesel and a 5 train.
>
> However this knowledge is not taken into account by the current algorithm.
> Things unfortunately are not that easy for all 18xx as it are in 1830.
> For example in 1835 one cannot tell this ex-ante for a combination of a 5+5
> and a 6 train. That in fact is one the reasons why calculating the
> Preussian
> routes is not an easy task.
>
> Another exceptions are: If trains score differently for the same route
> (Express (xE) and Double (xD) trains) or if hex trains run jointly with
> standard trains.
>
> ** The formal definition of train domination:
>
> If the "better" train A can run all routes that the "weaker" train B and
> train
> A scores identical revenue on all routes as B, then I define that train A
> dominates train B.
>
> If A dominates B I write this as A>B, otherwise the trains are either
> identical (A=B) or neither dominates (A<>B).
>
> If train A dominates train B, the length of the route of train A will
> always
> be longer or at least equally long as that of train B.
> (Length of the route is the number of stations scored.)
>
> ** Examples should make this clearer.
>
> In 1830 it is easy:  D>6>5>4>3>2
>
> In 1835 it is
> 6+6 > 5+5 > 4+4 > 3+3 > 2+2
> 6 > 5 > 4 > 3 > 2
> 6+6 > 6, 5+5 > 5, 4 +4 > 4, 3+3 > 3, 2+2 > 2
> 6 > 3+3, 4 > 2+2
> But for example: 6 <> 5+5, 5 <> 3+3 etc.
>
> ** Implementation
> The implementation is pretty straight forward and only requires a few lines
> of
> code in the revenue calculator. The major change is to order the trains by
> the
> criteria "train domination". Then the calculator assigns the initial train
> length for the dominated train not with the maximum length of that train,
> but
> with the (current) route length of the dominating train. This ensures that
> the
> dominating train will always have the longer route assigned.
>
> ** Speed improvement
> I did run the scenarios of Aliza Panitz 1856 triple Diesel of CGR scenarios
> and came to the following running times (more statistics on number of
> routes
> evaluated and when the best solution was found see below).
>
> For the simpler network (A) running times decrease from around 5 minutes to
> 3.5 minutes (my CPU is more powerful than Alizas ...).
> For the extensive network (B) running times decrease from around 1 hour to
> around 30 minutes.
>
> Overall the improvement it seems that the speed is improved by around 50%
> to
> 200%, so time to wait is down by 33% to 66%, which is not bad.
>
> But as it can be clearly seen by comparison with a double Diesel scenarios
> the
> exponential characteristic of the algorithm is still very clear.
>
> So I still hope that John Tamplin can give some hints on his lost flow
> algorithm for those who want to run triple Diesel more often.
>
> Stefan
>
> ** Stats
>
> => Aliza Scenario 1856 A:
> 31 vertices with 41 edges
> 10 startvertices
>
> Values:
> Single D: 700
> Double D: 920
> Triple D: 1120
>
> Single D: 0 second / 6.2k Evaluations, 6.2k Predictions
>
> Without dominant trains:
> Double D: 3 seconds / 1.3M Evaluations, 1.4M Predictions
> Triple D: 290 seconds / 114.9M Evaluations, 129.5M Predictions
> (Solution: 25 seconds / 13.4M Evaluations, 14.7M Predictions)
>
> With dominant trains:
> Double D: 1 second / 323k Evaluations, 385k Predictions
> Triple D: 206 seconds / 87.4M Evaluations, 98.0M Predictions
> (Solution: 20 seconds / 9.1M Evaluations, 10.0M Predictions)
>
> => Aliza Scenario 1856 B:
> 34 vertices with 50 edges
> 10 startvertices
>
> Values:
> Single D: 790
> Double D: 1280
> Triple D: 1440
>
> Single D: 0 second / 53.3k Evaluations, 53.3k Predictions
>
> Without dominant trains:
> Double D: 12 seconds / 4.8M Evaluations, 5.1M Predictions
> Triple D: 3551 seconds / 1473M Evaluations, 1709M Predictions
> (Solution: 41 seconds / 16.9M Evaluations, 17.7M Predictions)
>
> With dominant trains:
> Double D: 5 seconds / 1.9M Evaluations, 2.3M Predictions
> Triple D: 1926 seconds / 832M Evaluations, 962M Predictions
> (Solution: 27 seconds / 11.7M Evaluations, 12.3M Predictions)
>
> => Scenario 1870:
> This is the route network used for testing a year ago,
>
> 23 vertices with 57 edges
> 1 startvertex
>
> Values:
> Single 12: 380
> Double 12: 690
> Triple 12: 820
>
> Single 12: 0 second / 11.5k Evaluations, 23.7k Predictions
>
> Without dominant trains:
> Double 12: 4 seconds / 1.4M Evaluations, 1.9M Predictions
> Triple 12: 104 seconds / 23.4M Evaluations, 61.6M Predictions
> (Solution: 13 seconds / 3.2M Evaluations, 6.2M Predictions)
>
> With dominant trains:
> Double 12: 4 seconds / 1.2M Evaluations, 1.7M Predictions
> Triple 12: 49 seconds / 8.1M Evaluations, 30.0M Predictions
> (Solution: 16 seconds / 3.0M Evaluations, 9.3M Predictions)
>
>
> ------------------------------------------------------------------------------
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Route calculation: Train length heuristic

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

Stefan,

Do you plan to implement this heuristic in Rails? 
Would it require a new TrainType config attribute, like <TrainType
name="6+6" ... dominates="6,5+5"/>?

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday, August 09, 2011 7:03 AM
> To: Development list for Rails: an 18xx game
> Subject: [Rails-devel] Route calculation: Train length heuristic
> 
> A year ago I suggested another heuristic to improve the speed of the
> revenue calculation.
> 
> The idea is to use what 1830 players automatically do:
> If you calculate a run for a 4 and a 3 train, you already know that you
will end
> up with a longer route (more stations) for the 4 train and a shorter route
for
> the 3 train. Similar for running a Diesel and a 5 train.
> 
> However this knowledge is not taken into account by the current algorithm.
> Things unfortunately are not that easy for all 18xx as it are in 1830.
> For example in 1835 one cannot tell this ex-ante for a combination of a
5+5
> and a 6 train. That in fact is one the reasons why calculating the
Preussian
> routes is not an easy task.
> 
> Another exceptions are: If trains score differently for the same route
> (Express (xE) and Double (xD) trains) or if hex trains run jointly with
standard
> trains.
> 
> ** The formal definition of train domination:
> 
> If the "better" train A can run all routes that the "weaker" train B and
train A
> scores identical revenue on all routes as B, then I define that train A
> dominates train B.
> 
> If A dominates B I write this as A>B, otherwise the trains are either
identical
> (A=B) or neither dominates (A<>B).
> 
> If train A dominates train B, the length of the route of train A will
always be
> longer or at least equally long as that of train B.
> (Length of the route is the number of stations scored.)
> 
> ** Examples should make this clearer.
> 
> In 1830 it is easy:  D>6>5>4>3>2
> 
> In 1835 it is
> 6+6 > 5+5 > 4+4 > 3+3 > 2+2
> 6 > 5 > 4 > 3 > 2
> 6+6 > 6, 5+5 > 5, 4 +4 > 4, 3+3 > 3, 2+2 > 2
> 6 > 3+3, 4 > 2+2
> But for example: 6 <> 5+5, 5 <> 3+3 etc.
> 
> ** Implementation
> The implementation is pretty straight forward and only requires a few
lines
> of code in the revenue calculator. The major change is to order the trains
by
> the criteria "train domination". Then the calculator assigns the initial
train
> length for the dominated train not with the maximum length of that train,
> but with the (current) route length of the dominating train. This ensures
that
> the dominating train will always have the longer route assigned.
> 
> ** Speed improvement
> I did run the scenarios of Aliza Panitz 1856 triple Diesel of CGR
scenarios and
> came to the following running times (more statistics on number of routes
> evaluated and when the best solution was found see below).
> 
> For the simpler network (A) running times decrease from around 5 minutes
> to
> 3.5 minutes (my CPU is more powerful than Alizas ...).
> For the extensive network (B) running times decrease from around 1 hour to
> around 30 minutes.
> 
> Overall the improvement it seems that the speed is improved by around 50%
> to 200%, so time to wait is down by 33% to 66%, which is not bad.
> 
> But as it can be clearly seen by comparison with a double Diesel scenarios
the
> exponential characteristic of the algorithm is still very clear.
> 
> So I still hope that John Tamplin can give some hints on his lost flow
algorithm
> for those who want to run triple Diesel more often.
> 
> Stefan
> 
> ** Stats
> 
> => Aliza Scenario 1856 A:
> 31 vertices with 41 edges
> 10 startvertices
> 
> Values:
> Single D: 700
> Double D: 920
> Triple D: 1120
> 
> Single D: 0 second / 6.2k Evaluations, 6.2k Predictions
> 
> Without dominant trains:
> Double D: 3 seconds / 1.3M Evaluations, 1.4M Predictions Triple D: 290
> seconds / 114.9M Evaluations, 129.5M Predictions
> (Solution: 25 seconds / 13.4M Evaluations, 14.7M Predictions)
> 
> With dominant trains:
> Double D: 1 second / 323k Evaluations, 385k Predictions Triple D: 206
seconds
> / 87.4M Evaluations, 98.0M Predictions
> (Solution: 20 seconds / 9.1M Evaluations, 10.0M Predictions)
> 
> => Aliza Scenario 1856 B:
> 34 vertices with 50 edges
> 10 startvertices
> 
> Values:
> Single D: 790
> Double D: 1280
> Triple D: 1440
> 
> Single D: 0 second / 53.3k Evaluations, 53.3k Predictions
> 
> Without dominant trains:
> Double D: 12 seconds / 4.8M Evaluations, 5.1M Predictions Triple D: 3551
> seconds / 1473M Evaluations, 1709M Predictions
> (Solution: 41 seconds / 16.9M Evaluations, 17.7M Predictions)
> 
> With dominant trains:
> Double D: 5 seconds / 1.9M Evaluations, 2.3M Predictions Triple D: 1926
> seconds / 832M Evaluations, 962M Predictions
> (Solution: 27 seconds / 11.7M Evaluations, 12.3M Predictions)
> 
> => Scenario 1870:
> This is the route network used for testing a year ago,
> 
> 23 vertices with 57 edges
> 1 startvertex
> 
> Values:
> Single 12: 380
> Double 12: 690
> Triple 12: 820
> 
> Single 12: 0 second / 11.5k Evaluations, 23.7k Predictions
> 
> Without dominant trains:
> Double 12: 4 seconds / 1.4M Evaluations, 1.9M Predictions Triple 12: 104
> seconds / 23.4M Evaluations, 61.6M Predictions
> (Solution: 13 seconds / 3.2M Evaluations, 6.2M Predictions)
> 
> With dominant trains:
> Double 12: 4 seconds / 1.2M Evaluations, 1.7M Predictions Triple 12: 49
> seconds / 8.1M Evaluations, 30.0M Predictions
> (Solution: 16 seconds / 3.0M Evaluations, 9.3M Predictions)
> 
>
----------------------------------------------------------------------------
--
> uberSVN's rich system and user administration capabilities and model
> configuration take the hassle out of deploying and managing Subversion and
> the tools developers use with it. Learn more about uberSVN and get a free
> download at:  http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Route calculation for huge runs

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

see below

On Tuesday, August 09, 2011 08:22:38 am John A. Tamplin wrote:
> On Sun, Aug 7, 2011 at 1:55 AM, Stefan Frey <ste...@we...> wrote:
> > > A long, long time ago, I implemented route calculation by transforming
> > 
> > the
> > 
> > > problem to a flow graph and running the max-flow/min-cut algorithm on
> > > it (sorry, I no longer have this code), which avoids exponential time.
> > 
> > I think I can imagine how you approached this: You define the revenue of
> > each
> > node as negative cost of an edge inside the node and then minimize the
> > costs
> > (thus maximizing revenue) of the trains treated as flow.
> > 
> > Even if you do not have the code any longer, can you still remember how
> > you treated the issue of train length? And how did you ensure that each
> > train at
> > least visits one home token. I guess that it was some tricky adjustment
> > of the
> > graph, but maybe you can give some clues here.
> 
> It has been 24 years -- I was taking a Graph Theory class in grad school,
> and one of the things we had to do was transform other traditional problems
> to graphs and solve them using graph theory algorithms.  At the time we
> were studying the Floyd-Fulkerson algorithm, so I am sure I used that. 
> Most of the transforms involved creating extra nodes to represent other
> constraints, or replacing each node in the base graph with a set of nodes
> to represent those constraints.  I don't remember the specifics of how I
> solved it, but it worked for 1830-style trains only (which was all I knew
> about at the time).

John,
thanks for your comments. 
Good thing to know that first you were able to solve it (I hate working on 
unsolvable problems in my free time) and second that it did not take anything 
too extraordinary graph theory stuff to solve it. Third it shows the direction 
to go to adjust the graph to incorporate the train constraints (I have some 
ideas how to do that). An alternative might be to use a linear programming 
algorithm to solve the flow problem which (potentially) makes adding other 
constraints easier.

Can I ask you for reviewing my proposals, this might even help you retrieve 
the ideas you had 24 years ago.
Stefan

Re: [Rails-devel] Route calculation for huge runs

[John A. T. <ja...@ja...>]

On Sun, Aug 7, 2011 at 1:55 AM, Stefan Frey <ste...@we...> wrote:

> > A long, long time ago, I implemented route calculation by transforming
> the
> > problem to a flow graph and running the max-flow/min-cut algorithm on it
> > (sorry, I no longer have this code), which avoids exponential time.
>
> I think I can imagine how you approached this: You define the revenue of
> each
> node as negative cost of an edge inside the node and then minimize the
> costs
> (thus maximizing revenue) of the trains treated as flow.
>
> Even if you do not have the code any longer, can you still remember how you
> treated the issue of train length? And how did you ensure that each train
> at
> least visits one home token. I guess that it was some tricky adjustment of
> the
> graph, but maybe you can give some clues here.


It has been 24 years -- I was taking a Graph Theory class in grad school,
and one of the things we had to do was transform other traditional problems
to graphs and solve them using graph theory algorithms.  At the time we were
studying the Floyd-Fulkerson algorithm, so I am sure I used that.  Most of
the transforms involved creating extra nodes to represent other constraints,
or replacing each node in the base graph with a set of nodes to represent
those constraints.  I don't remember the specifics of how I solved it, but
it worked for 1830-style trains only (which was all I knew about at the
time).

-- 
John A. Tamplin

[Rails-devel] Route calculation: Train length heuristic

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

A year ago I suggested another heuristic to improve the speed of the revenue 
calculation.

The idea is to use what 1830 players automatically do: 
If you calculate a run for a 4 and a 3 train, you already know that you will 
end up with a longer route (more stations) for the 4 train and a shorter route 
for the 3 train. Similar for running a Diesel and a 5 train.

However this knowledge is not taken into account by the current algorithm.
Things unfortunately are not that easy for all 18xx as it are in 1830. 
For example in 1835 one cannot tell this ex-ante for a combination of a 5+5 
and a 6 train. That in fact is one the reasons why calculating the Preussian 
routes is not an easy task.

Another exceptions are: If trains score differently for the same route 
(Express (xE) and Double (xD) trains) or if hex trains run jointly with 
standard trains.

** The formal definition of train domination:

If the "better" train A can run all routes that the "weaker" train B and train 
A scores identical revenue on all routes as B, then I define that train A 
dominates train B.

If A dominates B I write this as A>B, otherwise the trains are either 
identical (A=B) or neither dominates (A<>B).

If train A dominates train B, the length of the route of train A will always 
be longer or at least equally long as that of train B.
(Length of the route is the number of stations scored.)

** Examples should make this clearer.

In 1830 it is easy:  D>6>5>4>3>2

In 1835 it is
6+6 > 5+5 > 4+4 > 3+3 > 2+2
6 > 5 > 4 > 3 > 2
6+6 > 6, 5+5 > 5, 4 +4 > 4, 3+3 > 3, 2+2 > 2
6 > 3+3, 4 > 2+2
But for example: 6 <> 5+5, 5 <> 3+3 etc.

** Implementation
The implementation is pretty straight forward and only requires a few lines of 
code in the revenue calculator. The major change is to order the trains by the 
criteria "train domination". Then the calculator assigns the initial train 
length for the dominated train not with the maximum length of that train, but 
with the (current) route length of the dominating train. This ensures that the 
dominating train will always have the longer route assigned.

** Speed improvement
I did run the scenarios of Aliza Panitz 1856 triple Diesel of CGR scenarios 
and came to the following running times (more statistics on number of routes 
evaluated and when the best solution was found see below).

For the simpler network (A) running times decrease from around 5 minutes to 
3.5 minutes (my CPU is more powerful than Alizas ...).
For the extensive network (B) running times decrease from around 1 hour to 
around 30 minutes.

Overall the improvement it seems that the speed is improved by around 50% to 
200%, so time to wait is down by 33% to 66%, which is not bad.

But as it can be clearly seen by comparison with a double Diesel scenarios the 
exponential characteristic of the algorithm is still very clear.

So I still hope that John Tamplin can give some hints on his lost flow 
algorithm for those who want to run triple Diesel more often.

Stefan

** Stats

=> Aliza Scenario 1856 A:
31 vertices with 41 edges
10 startvertices

Values:
Single D: 700
Double D: 920
Triple D: 1120

Single D: 0 second / 6.2k Evaluations, 6.2k Predictions

Without dominant trains:
Double D: 3 seconds / 1.3M Evaluations, 1.4M Predictions
Triple D: 290 seconds / 114.9M Evaluations, 129.5M Predictions
(Solution: 25 seconds / 13.4M Evaluations, 14.7M Predictions)

With dominant trains:
Double D: 1 second / 323k Evaluations, 385k Predictions
Triple D: 206 seconds / 87.4M Evaluations, 98.0M Predictions
(Solution: 20 seconds / 9.1M Evaluations, 10.0M Predictions)

=> Aliza Scenario 1856 B:
34 vertices with 50 edges
10 startvertices

Values:
Single D: 790
Double D: 1280
Triple D: 1440

Single D: 0 second / 53.3k Evaluations, 53.3k Predictions

Without dominant trains:
Double D: 12 seconds / 4.8M Evaluations, 5.1M Predictions
Triple D: 3551 seconds / 1473M Evaluations, 1709M Predictions
(Solution: 41 seconds / 16.9M Evaluations, 17.7M Predictions)

With dominant trains:
Double D: 5 seconds / 1.9M Evaluations, 2.3M Predictions
Triple D: 1926 seconds / 832M Evaluations, 962M Predictions
(Solution: 27 seconds / 11.7M Evaluations, 12.3M Predictions)

=> Scenario 1870:
This is the route network used for testing a year ago,

23 vertices with 57 edges
1 startvertex

Values:
Single 12: 380
Double 12: 690
Triple 12: 820

Single 12: 0 second / 11.5k Evaluations, 23.7k Predictions

Without dominant trains:
Double 12: 4 seconds / 1.4M Evaluations, 1.9M Predictions
Triple 12: 104 seconds / 23.4M Evaluations, 61.6M Predictions
(Solution: 13 seconds / 3.2M Evaluations, 6.2M Predictions)

With dominant trains:
Double 12: 4 seconds / 1.2M Evaluations, 1.7M Predictions
Triple 12: 49 seconds / 8.1M Evaluations, 30.0M Predictions
(Solution: 16 seconds / 3.0M Evaluations, 9.3M Predictions)

Re: [Rails-devel] Unit testing (8a7aee)

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

> Is it ok with you (Erik & Brett) to create an additional layer with src/
and
> junit/?

I was actually wondering why Eclipse/Egit didn't let me create the src/
layer, so basically I'm all for it.
But what are the consequences? I don't hope I'll have to set it all up yet
another time.

> EclEmma coverage tool reported an overall code coverage of 40.2% after
> running all automated game tests (which is not too bad given that UI and
> algorithm packages are not tested by construction, the rails/game package
> itself has 73.8% coverage).
> 
> My preferred mock library is JMock, any comments/preferences for this?

No.

Erik.

Re: [Rails-devel] Unit testing (8a7aee)

[brett l. <bre...@gm...>]

On Mon, Aug 8, 2011 at 11:48 AM, John A. Tamplin <ja...@ja...> wrote:
> On Mon, Aug 8, 2011 at 2:06 PM, brett lentz <bre...@gm...> wrote:
>>
>> The "java way" would be to have our code under
>> net/sourceforge/rails/{game, test, foo}
>>
>> (See also:
>> http://www.oracle.com/technetwork/java/codeconventions-135099.html )
>>
>> If we're going to add new sub-dirs, we may want to consider moving to
>> the "standard" Java naming conventions.
>
> I don't think that is actually relevant to the choice of directories.
> Most open source Java software I am aware of separates out tests from the
> source above the package structure, so src/org/example/Foo.java and
> tests/org/example/FooTest.java (or different names for src/tests, such as
> maven).  This also has the benefit of tests being able to see
> package-protected members without opening them up.
> --
> John A. Tamplin
>

How is that different from the whole of what I said?

---Brett.

Re: [Rails-devel] Unit testing (8a7aee)

[John A. T. <ja...@ja...>]

On Mon, Aug 8, 2011 at 2:06 PM, brett lentz <bre...@gm...> wrote:

> The "java way" would be to have our code under
> net/sourceforge/rails/{game, test, foo}
>
> (See also:
> http://www.oracle.com/technetwork/java/codeconventions-135099.html )
>
> If we're going to add new sub-dirs, we may want to consider moving to
> the "standard" Java naming conventions.
>

I don't think that is actually relevant to the choice of directories.

Most open source Java software I am aware of separates out tests from the
source above the package structure, so src/org/example/Foo.java and
tests/org/example/FooTest.java (or different names for src/tests, such as
maven).  This also has the benefit of tests being able to see
package-protected members without opening them up.

-- 
John A. Tamplin

Re: [Rails-devel] Unit testing (8a7aee)

[brett l. <bre...@gm...>]

On Mon, Aug 8, 2011 at 10:55 AM, Stefan Frey <ste...@we...> wrote:
> I was wondering where to save unit tests with our setup. Usually I prefer the
> setup with a folder tree for the sources (src/) and a parallel structure for
> the tests (junit/ or test/).
>
> Is it ok with you (Erik & Brett) to create an additional layer with src/ and
> junit/?
>

The "java way" would be to have our code under
net/sourceforge/rails/{game, test, foo}

(See also: http://www.oracle.com/technetwork/java/codeconventions-135099.html )

If we're going to add new sub-dirs, we may want to consider moving to
the "standard" Java naming conventions.

That said, I do prefer to have the tests separate from the regular
code base. I don't really care if we call it "test(s)" or "junit" or
"unit". I will say that if we call the unit test tree "test", we
should remove any other use of that word from the rest of the tree.

> EclEmma coverage tool reported an overall code coverage of 40.2% after running
> all automated game tests (which is not too bad given that UI and algorithm
> packages are not tested by construction, the rails/game package itself has
> 73.8% coverage).
>
> My preferred mock library is JMock, any comments/preferences for this?
>

JMock is fine by me.

> Stefan
>
>

---Brett

[Rails-devel] Unit testing (8a7aee)

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

I have updated the JUnit library to the latest stable release (Junit 4.8.2).

Being backwards compatible the automated game tests based on JUnit 3 still 
work out of the box. However I will still update those in midterm.

I was wondering where to save unit tests with our setup. Usually I prefer the 
setup with a folder tree for the sources (src/) and a parallel structure for 
the tests (junit/ or test/).

Is it ok with you (Erik & Brett) to create an additional layer with src/ and 
junit/?

EclEmma coverage tool reported an overall code coverage of 40.2% after running 
all automated game tests (which is not too bad given that UI and algorithm 
packages are not tested by construction, the rails/game package itself has 
73.8% coverage).

My preferred mock library is JMock, any comments/preferences for this?

The first unit tests are part of my rewrite/refactor of the state/move 
packages.

Stefan

Re: [Rails-devel] Route calculation for huge runs

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

This is a reply to the response of John Tamplin on Aliza's scenario.

On Monday, March 14, 2011 01:02:33 am John A. Tamplin wrote:
> 
> This is a known issue with the current brute-force algorithm -- it was
> brought up when it was being implemented.  Basically, when the number of
> trains and stops goes up, the number of possible routes goes up
> exponentially.

I agree.

The current implementation is a search-tree pruning method on an optimized 
multigraph. The heuristic used for tree-pruning is revenue prediction: Is it 
still possible with the following trains/stops to exceed the already found 
best solution?).

But even if the heuristic speeds up the search drastically, it shares the 
asymptotic behavior of brute force  that search time increases exponentially 
with trains and vertices.

> A long, long time ago, I implemented route calculation by transforming the
> problem to a flow graph and running the max-flow/min-cut algorithm on it
> (sorry, I no longer have this code), which avoids exponential time.

I think I can imagine how you approached this: You define the revenue of each 
node as negative cost of an edge inside the node and then minimize the costs 
(thus maximizing revenue) of the trains treated as flow.

Even if you do not have the code any longer, can you still remember how you 
treated the issue of train length? And how did you ensure that each train at 
least visits one home token. I guess that it was some tricky adjustment of the 
graph, but maybe you can give some clues here.

>  However, I don't know how to adapt this to all the exotic rules that have
> been added since then -- there may not be any better approach than brute
> force to make sure no solutions are missed.

I agree that it potentially  makes it much harder to implement the exotic 
rules. However I would be happy to implement such an algorithm if it allows to 
speed up those scenarios that might see double or triple long trains on an 
extensive network, but have otherwise pretty standard rules.

> 
> Perhaps the best approach is to take advantage of multiple cores by
> sharding testing alternate routes into threads and count on hardware
> getting faster
> 
> :).

That is easy ;-) 

Stefan

Re: [Rails-devel] Route calculation for huge runs

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

As mentioned earlier I had started making my way down to open issues in my 
Rails mail archive, so this mail is from March 2011.

The scenario Aliza mentions is pretty extreme (three D trains for a company 
with 10 tokens) and to my knowledge this is only possible for 1856. 
So in fact my surprise was on the positive side that Rails DID actually came 
up with the final result instead of running forever.

In my tests a pure brute-force search usually already  does not finish in 
reasonable time for double D combinations on similar networks. I will focus on 
the technical details in a response to John Tamplin's reply.

This mail is a reply to Aliza's suggestions on improving the UI behavior.

> when Rails is still calculating a run, there
> should be a note on the screen saying something like "route
> calculation in progress."

This can be done. However I would only display the message if a minimum time 
elapsed (for example 5 seconds).

> The next thing is that I'd like to know what was autocalculated versus
> hand-entered.  A note in the logfile saying what the calculated run
> was would be very useful. (Yes, I could go back in the history and
> look for myself, but that's not always feasible.)

Adding this information is possible. 
(I understand "logfile" here as the game report shown in the UI and not the 
18xx.log which is written by Rails, where this information and many more is 
already included).

However I am strongly interested in your (and all others) experience if and 
how often the experienced that situation: 

As the current algorithm (in theory) guarantees the correct solution, any 
deviation between the calculated result and the correct result should be filed 
as a bug with according save file.

Bugs (especially for example in tile definitions and the code for 
initialization and optimization before the revenue calculation, which exceeds 
the code for the core algorithm by factor 10 at least) can never be ruled out, 
so please report any observed differences.

> Finally, any interrupt between calculating a run and entering it
> restarts the calculation -- even things like saving the file or
> entering the destination of another company.  Highly annoying, though
> not quite a bug.

I considered this solution: However the interruption could have changed 
anything that might have impact on the result.
For example: undo, place token. Thus I decided to restart in any case of 
interruption to be on the safe side.

Stefan

The complete mail:

On Saturday, March 12, 2011 10:02:04 pm Aliza Panitz wrote:
> (Note:  my example is a what-if run-forward of a current PbeM game.
> James, Jevon, Jerry, Breno, Scott, please go away.)
> 
> Rails 1.4.1, 1856, CGR running 3 Diesels. (This is not completely
> absurd -- my plausible choices for the CGR in this game are 5,6; D,5;
> and D,D,D.  The money doesn't work out right for D,D.  This is a very
> odd game where the CGR formed with 4,5,6, and ten excellent tokens)
> 
> At first, run calculations were taking 15-20 minutes on a T60 laptop
> running Windows XP.  Now, though, I've got a calculation that's been
> running for well over an hour, taking 45-55% of my CPU the whole time.
> The map isn't that much more developed! [added - it finally completed.
>  $1440 per 10% share.]
> 
> Earlier, I was all ready to file a Rails bug because I could clearly
> see a better route than what was displayed, but I stepped away from my
> computer and when I came back, a better run was shown instead.  So,
> one simple request:  when Rails is still calculating a run, there
> should be a note on the screen saying something like "route
> calculation in progress."  (Screen shot attached.  Even I can quickly
> see that the light blue train should run towards the WGB tokens for an
> extra $60 on the run, and in fact Rails eventually did $10 or $20
> better than that.)
> 
> The next thing is that I'd like to know what was autocalculated versus
> hand-entered.  A note in the logfile saying what the calculated run
> was would be very useful. (Yes, I could go back in the history and
> look for myself, but that's not always feasible.)
> 
> Finally, any interrupt between calculating a run and entering it
> restarts the calculation -- even things like saving the file or
> entering the destination of another company.  Highly annoying, though
> not quite a bug.

Re: [Rails-devel] Output of failed tests (a3aed4)

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

The nice thing about tools like WinMerge is that you can compare whole
directory trees, making it show (for instance) the different files only,
which obviously must the have the same name to make this work.  I have been
using that often to compare different versions of some tree, and have done
so with Rails in the past.

But of course it can also load single pairs of files to compare.  Don't
worry, the Rails test set is still small enough to make the one-by-one
comparisons easy to do, in particular if only the failed files are saved.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Saturday, August 06, 2011 9:58 AM
> To: Development list for Rails: an 18xx game
> Subject: Re: [Rails-devel] Output of failed tests (a3aed4)
> 
> Erik:
> sure you could:
> 
> However you should be aware that I plan to update the test code to the
> JUnit 4 series soon, as I prefer to write unit tests in JUnit
> 4 instead of JUnit 3 for my new states implementation.
> 
> So you should not simply copy&paste the code, but please add a new entry
> in the configuration files for a failed report directory and use that in
the
> existing code. Then you can apply the new settings in test.profile of your
> own.
> 
> Still wondering: I do not know the diff viewer you are using, but does it
really
> only allow to compare two files with identical names in two different
> directories?
> In my case it as it easy to compare two files with different names in the
same
> directory?
> 
> Stefan
> 
> 
> On Saturday, August 06, 2011 09:36:46 am Erik Vos wrote:
> > > -----Original Message-----
> > > From: Stefan Frey [mailto:ste...@we...]
> > > Sent: Saturday, August 06, 2011 8:01 AM
> > > To: Development list for Rails: an 18xx game
> > > Subject: [Rails-devel] Output of failed tests (a3aed4)
> > >
> > > Erik,
> > > I have added the function.
> > >
> > > I took the freedom to change the details a little to my favored
approach.
> > >
> > > If a test fails the failed report is created in the same directory
> > > put
> >
> > with a
> >
> > > different extension (.failed).
> > > If a test runs correctly again, the failed report is automatically
> >
> > deleted.
> >
> > > The reason for the change is that it is easier to fire up the diff
> > > tool
> >
> > (at least for
> >
> > > me) and it avoids creating new directories which are usually empty.
> >
> > However, it thwarts my intended usage, because I now have to move and
> > rename the failed files. Well, I guess I can create  my own version.
> >
> > Erik.
> >
> > > Stefan
> > >
> > > On Thursday, August 04, 2011 04:19:12 pm Erik Vos wrote:
> > > > Stefan,
> > > >
> > > > I would prefer just a copy of the (new) report, preferably saved
> > > > in a separate directory somewhere in the test tree (for instance
> > > > test/data/newreports). Name should be identical to the 'old'
> > > > report
> >
> > name.
> >
> > > > This way I can load these directories as a whole into a graphical
> > > > tool such as WinMerge that gives a quick overview of the
> > > > (non-)identity of all reports, and allows a side-by-side
> > > > comparison of the two versions of the each report.
> > > >
> > > > Erik.
> > > >
> > > > > -----Original Message-----
> > > > > From: Stefan Frey [mailto:ste...@we...]
> > > > > Sent: Thursday, August 04, 2011 7:52 AM
> > > > > To: Development list for Rails: an 18xx game
> > > > > Subject: Re: [Rails-devel] Automated testing (7e4acf)
> > > > >
> > > > > Erik:
> > > > > fixed the failing tests. The issue was that I did not clear
> > > > > NDC.key after
> > > >
> > > > each
> > > >
> > > > > test so it still contained a reference due to the previous
> > > > > game(manager)
> > > >
> > > > and
> > > >
> > > > > thus confused the mechanism of the initial queue of the report
> > > > > buffer.
> > > > >
> > > > > I do not save the test reports currently, but that was on my
> > > > > wishlist
> > > >
> > > > anyhow.
> > > >
> > > > > Do you prefer simply a copy of the test report or a diff-output
> > > > > to the expected report which would be easy to create using a
> > > > > java diff
> > >
> > > library?
> > >
> > > > > Stefan
> > > > >
> > > > > On Wednesday, August 03, 2011 02:59:35 pm Erik Vos wrote:
> > > > > > See below.
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Stefan Frey [mailto:ste...@we...]
> > > > > > >
> > > > > > > Regarding the failed tests from your phase changes they show
> > > > > > > that
> > > > > > > A) Phase names in 1856 changed
> > > > > >
> > > > > > Ah yes, I should have reported that. With my latest commit I
> > > > > > have also renamed all (distinct) phases after the last bought
> > > > > > train, where that wasn't the case, deferring the "real" (but
> > > > > > not always
> > > > > > usable) phase names to the new "realName" attribute that I
> > > > > > have added recently (and is now shown in square brackets in
> > > > > > the UI).  I think I now did 1856 and 1870,
> > > > > > 1835 had been done before (and 1880 by Martin). Not done 1825.
> > > > > >
> > > > > > > B) All messages "train obsolete" were removed from 1830_A
> > > > > > > (C&R
> > > > >
> > > > > variant).
> > > > >
> > > > > > > C) All messages "train rusted" were removed from both games
> > > > > > > 1889 and 18AL_A.
> > > > > > >
> > > > > > > D) 18EU_A surprisingly kept the train rusted messages, but
> > > > > > > lost the
> > > > > >
> > > > > > message
> > > > > >
> > > > > > > "TrainsAvailable,P".
> > > > > > >
> > > > > > > It seems that A) was an intended change, for B) to D) I am
> > > > > > > not so
> > > >
> > > > sure.
> > > >
> > > > > > > Maybe you should check this.
> > > > > >
> > > > > > Nothing was intentional, I had just forgotten to put these
> > > > > > report lines into the new code.
> > > > > > The message "All X-trains are sold out, Y-trains now available"
> > > > > > wasn't even localised, and had to be split into two lines,
> > > > > > because the second half is now displayed on a separate line in
> > > > > > *all* cases where a new type becomes available. So I have
> > > > > > added a new
> > >
> > > "TrainsSoldOut" entry.
> > >
> > > > > > To check any differences, I would like to be able to compare
> > > > > > the old and new TE_ST reports line by line in a tool like
WinMerge.
> > > > > > Are the new reports saved anywhere?  If not, wouldn't that be
> > > > > > a useful addition, or have you already made that possible in
> > > > > > another
> > >
> > > way?
> > >
> > > > > > Erik
> > > > > >
> > > > > >
> > > > > > --------------------------------------------------------------
> > > > > > ----
> > > > > > ----
> > > > > > -----
> > > > > > --- BlackBerry® DevCon Americas, Oct. 18-20, San
> > > > > > Francisco, CA The must-attend event for mobile developers.
> Connect with experts.
> > > > > > Get tools for creating Super Apps. See the latest technologies.
> > > > > > Sessions, hands-on labs, demos & much more. Register early &
> save!
> > > > > > http://p.sf.net/sfu/rim-blackberry-1
> > > > > > _______________________________________________
> > > > > > Rails-devel mailing list
> > > > > > Rai...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > >
> > > > ------------------------------------------------------------------
> > > > ----
> > > > -----
> > > > - --
> > > >
> > > > > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> > > > > The
> > > > > must- attend event for mobile developers. Connect with experts.
> > > > > Get tools for creating Super Apps. See the latest technologies.
> > > > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > > > http://p.sf.net/sfu/rim-blackberry-1
> > > > > _______________________________________________
> > > > > Rails-devel mailing list
> > > > > Rai...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > >
> > > > ------------------------------------------------------------------
> > > > ----
> > > > -----
> > > > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> > > > The must-attend event for mobile developers. Connect with experts.
> > > > Get tools for creating Super Apps. See the latest technologies.
> > > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > > http://p.sf.net/sfu/rim-blackberry-1
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > - --
> >
> > > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The
> > > must- attend event for mobile developers. Connect with experts.
> > > Get tools for creating Super Apps. See the latest technologies.
> > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > http://p.sf.net/sfu/rim-blackberry-1
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> > ----------------------------------------------------------------------
> > -----
> > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The
> > must-attend event for mobile developers. Connect with experts.
> > Get tools for creating Super Apps. See the latest technologies.
> > Sessions, hands-on labs, demos & much more. Register early & save!
> > http://p.sf.net/sfu/rim-blackberry-1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
>
----------------------------------------------------------------------------
--
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-
> attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Output of failed tests (a3aed4)

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

Erik:
sure you could:

However you should be aware that I plan to update the
test code to the JUnit 4 series soon, as I prefer to write unit tests in JUnit 
4 instead of JUnit 3 for my new states implementation.

So you should not simply copy&paste the code, but please add a new entry in 
the configuration files for a failed report directory and use that in the 
existing code. Then you can apply the new settings in test.profile of your 
own.

Still wondering: I do not know the diff viewer you are using, but does it 
really only allow to compare two files with identical names in two different 
directories? 
In my case it as it easy to compare two files with different names in the same 
directory?

Stefan


On Saturday, August 06, 2011 09:36:46 am Erik Vos wrote:
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Saturday, August 06, 2011 8:01 AM
> > To: Development list for Rails: an 18xx game
> > Subject: [Rails-devel] Output of failed tests (a3aed4)
> > 
> > Erik,
> > I have added the function.
> > 
> > I took the freedom to change the details a little to my favored approach.
> > 
> > If a test fails the failed report is created in the same directory put
> 
> with a
> 
> > different extension (.failed).
> > If a test runs correctly again, the failed report is automatically
> 
> deleted.
> 
> > The reason for the change is that it is easier to fire up the diff tool
> 
> (at least for
> 
> > me) and it avoids creating new directories which are usually empty.
> 
> However, it thwarts my intended usage, because I now have to move and
> rename the failed files. Well, I guess I can create  my own version.
> 
> Erik.
> 
> > Stefan
> > 
> > On Thursday, August 04, 2011 04:19:12 pm Erik Vos wrote:
> > > Stefan,
> > > 
> > > I would prefer just a copy of the (new) report, preferably saved in a
> > > separate directory somewhere in the test tree (for instance
> > > test/data/newreports). Name should be identical to the 'old' report
> 
> name.
> 
> > > This way I can load these directories as a whole into a graphical tool
> > > such as WinMerge that gives a quick overview of the (non-)identity of
> > > all reports, and allows a side-by-side comparison of the two versions
> > > of the each report.
> > > 
> > > Erik.
> > > 
> > > > -----Original Message-----
> > > > From: Stefan Frey [mailto:ste...@we...]
> > > > Sent: Thursday, August 04, 2011 7:52 AM
> > > > To: Development list for Rails: an 18xx game
> > > > Subject: Re: [Rails-devel] Automated testing (7e4acf)
> > > > 
> > > > Erik:
> > > > fixed the failing tests. The issue was that I did not clear NDC.key
> > > > after
> > > 
> > > each
> > > 
> > > > test so it still contained a reference due to the previous
> > > > game(manager)
> > > 
> > > and
> > > 
> > > > thus confused the mechanism of the initial queue of the report
> > > > buffer.
> > > > 
> > > > I do not save the test reports currently, but that was on my
> > > > wishlist
> > > 
> > > anyhow.
> > > 
> > > > Do you prefer simply a copy of the test report or a diff-output to
> > > > the expected report which would be easy to create using a java diff
> > 
> > library?
> > 
> > > > Stefan
> > > > 
> > > > On Wednesday, August 03, 2011 02:59:35 pm Erik Vos wrote:
> > > > > See below.
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Stefan Frey [mailto:ste...@we...]
> > > > > > 
> > > > > > Regarding the failed tests from your phase changes they show
> > > > > > that
> > > > > > A) Phase names in 1856 changed
> > > > > 
> > > > > Ah yes, I should have reported that. With my latest commit I have
> > > > > also renamed all (distinct) phases after the last bought train,
> > > > > where that wasn't the case, deferring the "real" (but not always
> > > > > usable) phase names to the new "realName" attribute that I have
> > > > > added recently (and is now shown in square brackets in the UI).  I
> > > > > think I now did 1856 and 1870,
> > > > > 1835 had been done before (and 1880 by Martin). Not done 1825.
> > > > > 
> > > > > > B) All messages "train obsolete" were removed from 1830_A (C&R
> > > > 
> > > > variant).
> > > > 
> > > > > > C) All messages "train rusted" were removed from both games 1889
> > > > > > and 18AL_A.
> > > > > > 
> > > > > > D) 18EU_A surprisingly kept the train rusted messages, but lost
> > > > > > the
> > > > > 
> > > > > message
> > > > > 
> > > > > > "TrainsAvailable,P".
> > > > > > 
> > > > > > It seems that A) was an intended change, for B) to D) I am not
> > > > > > so
> > > 
> > > sure.
> > > 
> > > > > > Maybe you should check this.
> > > > > 
> > > > > Nothing was intentional, I had just forgotten to put these report
> > > > > lines into the new code.
> > > > > The message "All X-trains are sold out, Y-trains now available"
> > > > > wasn't even localised, and had to be split into two lines, because
> > > > > the second half is now displayed on a separate line in *all* cases
> > > > > where a new type becomes available. So I have added a new
> > 
> > "TrainsSoldOut" entry.
> > 
> > > > > To check any differences, I would like to be able to compare the
> > > > > old and new TE_ST reports line by line in a tool like WinMerge.
> > > > > Are the new reports saved anywhere?  If not, wouldn't that be a
> > > > > useful addition, or have you already made that possible in another
> > 
> > way?
> > 
> > > > > Erik
> > > > > 
> > > > > 
> > > > > ------------------------------------------------------------------
> > > > > ----
> > > > > -----
> > > > > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> > > > > The must-attend event for mobile developers. Connect with experts.
> > > > > Get tools for creating Super Apps. See the latest technologies.
> > > > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > > > http://p.sf.net/sfu/rim-blackberry-1
> > > > > _______________________________________________
> > > > > Rails-devel mailing list
> > > > > Rai...@li...
> > > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > - --
> > > 
> > > > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The
> > > > must- attend event for mobile developers. Connect with experts.
> > > > Get tools for creating Super Apps. See the latest technologies.
> > > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > > http://p.sf.net/sfu/rim-blackberry-1
> > > > _______________________________________________
> > > > Rails-devel mailing list
> > > > Rai...@li...
> > > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> > > 
> > > ----------------------------------------------------------------------
> > > -----
> > > --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The
> > > must-attend event for mobile developers. Connect with experts.
> > > Get tools for creating Super Apps. See the latest technologies.
> > > Sessions, hands-on labs, demos & much more. Register early & save!
> > > http://p.sf.net/sfu/rim-blackberry-1
> > > _______________________________________________
> > > Rails-devel mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> - --
> 
> > BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-
> > attend event for mobile developers. Connect with experts.
> > Get tools for creating Super Apps. See the latest technologies.
> > Sessions, hands-on labs, demos & much more. Register early & save!
> > http://p.sf.net/sfu/rim-blackberry-1
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> ---------------------------------------------------------------------------
> --- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel