rails-devel — List for discussion of Rails development

Re: [Rails-devel] Release Management for Rails 2.x

[Mike B. <com...@ip...>]

The only thing that I can see wrong with this proposal is the question of
what happens if you get hit by a bus or something, Stefan. Not that I wish
you any ill, but some sort of contingancy should be built into the plan :)

Mike Bourke
Campaign Mastery http://www.campaignmastery.com
Co-author, Assassin's Amulet http://www.legaciescampaignsetting.com

[Rails-devel] Release Management for Rails 2.x

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

Hi all,
as there was some discussion and confusion on how release management 
should work I have created the proposal below for Rails release 
management for Rails 2.x. I tried to keep it as simple as possible.

I propose myself as a release manager for Rails 2.x. This implies
that the only one which eventually merges new features and bug-fixes 
into the official branches will be me.

However if you look carefully into the proposal this will require no 
active intervention as I require that the new code is rebased on the 
branch it will be merged into. Thus there will never be any merge 
conflicts, it is merely a kind of giving the "final go".

This is not a bad thing because after the "final go", all other 
developers have to rebase on the new feature changes before they can get 
their stuff in. So the "final go" will always be the chance to identify 
and discuss potential future merge conflicts.

I will write something about Rails 1.x release management later today.

Stefan


Proposal for Rails 2.x Release Management:

Rails release management for Rails 2.x will follow the "Gitflow" Workflow:

https://www.atlassian.com/git/workflows#!workflow-gitflow

There will be two official branches:

** Name conventions:
- Official branches will be called "rails_#_".
- Branches for new features can use any name, except those starting with 
"rails_".
- Branches for bug fixes start with "fix_".

** Official Rails 2 branches
- rails_2_master
- rails_2_develop

** Working on bug fixes:
Create a branch from master, fix the bug, run tests, commit and push.
Finished: Ask to be merged into master by release manager.

** Working on new features:
Create a branch from develop.
Iterate on: Code, rebase on develop, run tests, commit and push.
Finished: Ask to be merged into develop by release manager.

** Optional (later): Release branch
If there is the need, develop will be separated into the long-running
develop branch and a short-running release branch.

** Further Remarks:
- Whitespace issues should be taken care by the .gitattributes file 
settings in the repo.
- I will only merge features that are rebased against the current 
develop branch (so usually "git rebase rails_2_develop")
- You can set git to use rebase for new branches on pull with "git 
config --global branch.autosetuprebase always", or use "git pull --rebase"

Re: [Rails-devel] 1880 and 1846

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

> Erik has gone a little bit quiet 

Indeed.

> (probably waiting for Stefan to pop up with Rails Rewrite 2.0). 

That's one of the factors, others are last year's repo move and the new
multiple branch development approach. But the main cause is that I have been
spending/wasting my time with other activities.  
When I tried last week to pick up again, I ran into some merge conflicts,
and I'm not sure where to find the courage to address these. Fact is that I
have never managed to come to grips with Git except some very basic tasks.

> So maybe he has some more info on whats conceptually done in that case. 

I haven't worked on the dual trains since I wrote the words quoted by Jeff,
so I'm afraid I can't add anything useful now.  But it's indeed the subject
that I would like to pick up, should I ever  resume development. But the
latter is far from sure, if only because I'm 67, and counting...

Erik.

Re: [Rails-devel] 1880 and 1846

[Martin B. <dr....@t-...>]

Am 22.10.2013 21:32, schrieb Jeff VanDorp:
> Hello,
> I'm new to the list, and new to sourceforge in general, but have some
> experience with 18xx (have been playing for about 3 years now, with
> approximately 15 plays of about 8 different titles).  I have some
> software programming background (although I'm a little rusty), and may
> be able to recruit others from our newly formed West Michigan 18xx
> group
> <https://groups.google.com/forum/?hl=en#%21forum/west-michigan-18xx-players> to
> help.
>  
> 1. First, Thank you for getting 1880 completed!  This is one of my
> favorite titles, and I'm excited to try it out.  I'll be organizing a
> PBEM game soon.
>  
> 2. Second, I'd like to request (and possibly participate in) the
> development of 1846 - my favorite title.  I searched the archives and
> saw some talk about 1846 a couple years ago (see below), and I'm
> wondering about any updated status.  Has anyone worked on the map or
> tile set yet?  Has the n/m train code been developed?  How about the
> separation of trains from train certificates, to allow a player to
> choose one of two options?
>  
> Looking forward to hearing back from you.
>  
> Jeff VanDorp 
>  

Hi Jeff,

Have fun playing 1880 and please notify us if something is wrong and
send us a savefile in that case :)

1846 is not yet in the data section of the code. So theres no public
work on that yet.  I am currently working on 1837/1824 and will be
working on 1830(Mayfair/Lookout Games) from time to time.

If you got some time to spare you are more than welcome to pull the
code, create a local repo and start working in there. I would suggest
that you create a local branch for the specific version you are keen on
(in this case 1846).

The Train code i havent checked yet as i dont own that game personally
and havent investigated it. Erik has gone a little bit quiet (probably
waiting for Stefan to pop up with Rails Rewrite 2.0). So maybe he has
some more info on whats conceptually done in that case.

I consider myself a game implementer and lacking a professional software
development education i am not that fond of trying to implement core
concepts :). If i can be of help i'll gladly do whatever i can though.

I would be willing to check in your additions into the sourceforge repo,
if i can verify the content.

If you got any questions feel free to adress them.

Regards,
Martin

[Rails-devel] 1880 and 1846

[Jeff V. <je...@je...>]

Hello,
I'm new to the list, and new to sourceforge in general, but have some
experience with 18xx (have been playing for about 3 years now, with
approximately 15 plays of about 8 different titles).  I have some software
programming background (although I'm a little rusty), and may be able to
recruit others from our newly formed West Michigan 18xx
group<https://groups.google.com/forum/?hl=en#!forum/west-michigan-18xx-players>
to
help.

1. First, Thank you for getting 1880 completed!  This is one of my favorite
titles, and I'm excited to try it out.  I'll be organizing a PBEM game soon.

2. Second, I'd like to request (and possibly participate in) the
development of 1846 - my favorite title.  I searched the archives and saw
some talk about 1846 a couple years ago (see below), and I'm wondering
about any updated status.  Has anyone worked on the map or tile set yet?
Has the n/m train code been developed?  How about the separation of trains
from train certificates, to allow a player to choose one of two options?

Looking forward to hearing back from you.

Jeff VanDorp


   *Re: [Rails-devel] 1846*
From: Erik Vos <erik.vos@xs...> - 2011-05-04 20:41

Scott,



I would certainly be willing to work on the 1846 special rules over time,
but you shouldn't expect quick progress.

Several people (including you) are/have been working on other games, like
18GA, 18TN, 18VA, 1880, 1830 Coalfields, all of which need more work, and
much of that work will in all likelihood be waiting for me to pick it up.

Then we have 1870, 1825, both barely started, and 1835, which still may need
the finishing touch.



And on my own wish list I have more of the Hecht games, generally my
favourites, where I'm in particular looking at 1826 and 18Scan.



Reworking train management is not so easy, but high on my priority list as
it is clearly the next fundamental architectural change to implement.

For the rest, I'm generally doing easy bits first, so you'll probably find
me cherry-picking elements from many of these games over time.



So much to do.



Erik.



Van: Scott Petersen [mailto:scott@...]
Verzonden: woensdag 4 mei 2011 21:44
Aan: Development list for Rails: an 18xx game
Onderwerp: [Rails-devel] 1846



Erik, 1846 has a plethora of special rules and the X/Y trains will make it
difficult to implement the revenue calculation...but I like the game and
would be willing to assemble the XML files.  Would you be up for
implementing the special rules?  This would also be a good chance to
implement the dual type trains that apply to many other games (possibly
including the OS 2-train from 18GA).



I don't expect that your 1846 question will get an answer here, but I'll
post it to BGG and probably get an answer within an hour or so. :-)

Re: [Rails-devel] [Rails-users] Bug with Prussian dividends in 1835?

[Martin B. <dr....@t-...>]

Am 15.10.2013 15:58, schrieb Erik Vos:
> Stefan,
>
> Prussian operation looks correct to me, it's the payout process that gets
> mangled.  
> Here I have tried to implement the rule that one share can never earn income
> twice in an OR. 
>
> The problem surfaces in OperatingRound_1835.countSharesPerRecipient(), where
> a subtraction occurs. 
> I guess there is some error in handling the sharesPerRecipient and/or
> deniedIncomeShare maps.  
> One point to note is that Stan occurs twice in the payout report of the PR
> turn.  That looks wrong too, and may be a starting point for analysis.
>
> Erik
>
>
Hi Erik & Stefan,

    protected  Map<CashHolder, Integer>  countSharesPerRecipient () {

        Map<CashHolder, Integer> sharesPerRecipient =
super.countSharesPerRecipient();

        if
(operatingCompany.get().getName().equalsIgnoreCase(GameManager_1835.PR_ID))
{
            for (Player player : deniedIncomeShare.keySet()) {
                if (!sharesPerRecipient.containsKey(player)) continue;
                int share = deniedIncomeShare.get(player);
                int shares = share / operatingCompany.get().getShareUnit();
                sharesPerRecipient.put (player,
sharesPerRecipient.get(player) - shares);
               
ReportBuffer.add(LocalText.getText("NoIncomeForPreviousOperation",
                        player.getName(),
                        share,
                        GameManager_1835.PR_ID));

The Map sharesPerRecipient contains the actual exchanged Prussian shares
plus the IPO shares.

The map deniedIncomeShare contains the Shares that have operated that
round and are NOT included in sharesPerRecipient. So by subtracting
those from the SharesPerRecipient in this case (shares have not been
exchanged..) its bringing wrong results.


    protected void initTurn() {

        super.initTurn();

        List<SpecialPropertyI> sps =
operatingCompany.get().getSpecialProperties();
        if (sps != null && !sps.isEmpty()) {
            ExchangeForShare efs = (ExchangeForShare) sps.get(0);
            addIncomeDenialShare (operatingCompany.get().getPresident(),
efs.getShare());
        }
    }

Here the code adds the shares related to the Minors (still operating) to
the DeniedShares but ... nowhere is checked if those are exchanged later
on and thus land as Prussianshares in the wallet of the players.

What should be done then is on Prussian starting to operate if those
deniedshares are still operating and then clear the map
deniedIncomeShares, or reduce the amount if not all shares are converted...

I think i found a solution here...


        Map<CashHolder, Integer> sharesPerRecipient =
super.countSharesPerRecipient();

        if
(operatingCompany.get().getName().equalsIgnoreCase(GameManager_1835.PR_ID))
{
            for (Player player : deniedIncomeShare.keySet()) {
                if (!sharesPerRecipient.containsKey(player)) continue;
                int share = deniedIncomeShare.get(player);
                int shares = share / operatingCompany.get().getShareUnit();
  -->>>>              if (this.wasInterrupted()) { //Assuming that an OR
Interruption was caused by a Formationround for the Prussian..
                sharesPerRecipient.put (player,
sharesPerRecipient.get(player) - shares);
               
ReportBuffer.add(LocalText.getText("NoIncomeForPreviousOperation",
                        player.getName(),
                        share,
                        GameManager_1835.PR_ID));
                }
Only then count the deniedshares against shares in the wallet.

Comments ?

Regards,
Martin

[Rails-devel] Rails-commits not working anymore

[Martin B. <dr....@t-...>]

Hi Guys,

since the switch from cvs to git last autumn the rails-commit
mailinglist has died. The git commits arent shown there anymore. I have
no access to the mechanismn, so i cant fix (if thats fixable at all).

Anyone wanting to keep on top of the commits should go to the following
link and Subscribe to Updates under Update Notifications.

http://sourceforge.net/projects/rails/


Kind Regards

Martin

Re: [Rails-devel] [Rails-users] Bug with Prussian dividends in 1835?

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

Stefan,

Prussian operation looks correct to me, it's the payout process that gets
mangled.  
Here I have tried to implement the rule that one share can never earn income
twice in an OR. 

The problem surfaces in OperatingRound_1835.countSharesPerRecipient(), where
a subtraction occurs. 
I guess there is some error in handling the sharesPerRecipient and/or
deniedIncomeShare maps.  
One point to note is that Stan occurs twice in the payout report of the PR
turn.  That looks wrong too, and may be a starting point for analysis.

Erik

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, October 14, 2013 4:30 PM
> To: Development list for Rails: an 18xx game
> Cc: pie...@ho...
> Subject: Re: [Rails-devel] [Rails-users] Bug with Prussian dividends in
1835?
> 
> Erik:
> I will try to cover the remaining 1835 bugs in the near future.
> 
> This new one below seems tricky as I remember some discussion in the past
> on the 18xx yahoo list about when and how the minors/privates merge into
> the Prussian major.
> 
> Could you tell me how you determine when the Prussian is allowed to
> operate and who gets dividends paid out?
> 
> In any case paying negative amounts seems plain wrong or is this some kind
> of a workaround?
> 
> Thanks,
> Stefan
> 
> On 10/14/2013 11:49 AM, Pieter Lust wrote:
> > Hi
> >
> > In a recent game of 1835 with Rails the following occurred:
> >
> > The Prussian was started in operating round 8.1 . Some privates and
> > minors merged, but not all. The Prussian didn't operate.
> > At the start of operating round 8.2, one minor merged into the Prussian.
> > Player holdings were:
> > Stan: 10% Prussian, M1 (not converted yet), BB private
> > Dave: no Prussian shares, M6
> > Neil: 20% Prussian
> > Pier: 15% Prussian, M3, PfB private
> > Easterly1: 30%, no minors
> >
> > The Prussian then operated, and paid dividends. This was the output
> > from
> > rails:
> >
> > PR pays out full dividend of 150M
> > Stan gets no income for 15% PR shares as precursors have operated Pier
> > gets no income for 5% PR shares as precursors have operated Stan
> > receives -7M for -1 5% shares Pier receives 15M for 2 5% shares
> > Easterly1 receives 45M for 6 5% shares Neil receives 30M for 4 5%
> > shares
> >
> > This seems wrong: the minors didn't operate in the current operating
> > round, so all converted shares should receive a dividend.
> >
> > Is this a bug?
> >
> > Sincerely
> >
> > Pieter
> >
> >
> > ----------------------------------------------------------------------
> > -------- October Webinars: Code for Performance Free Intel webinars
> > can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> > most from the latest Intel processors and coprocessors. See abstracts
> > and register >
> > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.c
> > lktrk
> >
> >
> >
> > _______________________________________________
> > Rails-users mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-users
> >
> 
> 
>
----------------------------------------------------------------------------
--
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
register
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clk
> trk
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] Change git repo url (was: Bug with Prussian dividends in 1835?)

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

Thanks, that works. 
Although I'm now getting a bunch of merge conflicts, which surprises me, as
I haven't changed anything since my last pull. 
Erik

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Tuesday, October 15, 2013 1:11 PM
> To: rai...@li...
> Subject: [Rails-devel] Change git repo url (was: Bug with Prussian
dividends in
> 1835?)
> 
> Erik:
> I assume how to move to the changed URL of the git repo, as sourceforge
> changed that:
> 
> Take a look here:
> http://stackoverflow.com/questions/2432764/how-to-change-a-remote-
> repository-uri-using-git
> 
> Your remote URL (including your username) is shown under Code after you
> have logged into sourceforge.
> 
> https://sourceforge.net/p/rails/code/ci/master/tree/
> 
> Hope this works for you.
> 
> Stefan
> 
> On 10/15/2013 12:48 PM, Erik Vos wrote:
> > Can anyone remind me how to configure the new Git repo location in git
> bash?
> > I can't find the config file, and there doesn't seem to be a lot of
> > help on this matter.
> > Erik
> >
> >> -----Original Message-----
> >> From: Erik Vos [mailto:eri...@xs...]
> >> Sent: Tuesday, October 15, 2013 12:38 AM
> >> To: 'Development list for Rails: an 18xx game'
> >> Subject: Re: [Rails-devel] [Rails-users] Bug with Prussian dividends
> >> in
> > 1835?
> >>
> >> Clearly negative amounts are erroneous.  But without a saved file
> >> it's
> > hard to
> >> track down such bugs.
> >> I'll try to provide some answers tomorrow.
> >> Erik
> >>
> >>> -----Original Message-----
> >>> From: Stefan Frey [mailto:ste...@we...]
> >>> Sent: Monday, October 14, 2013 4:30 PM
> >>> To: Development list for Rails: an 18xx game
> >>> Cc: pie...@ho...
> >>> Subject: Re: [Rails-devel] [Rails-users] Bug with Prussian dividends
> >>> in
> >> 1835?
> >>>
> >>> Erik:
> >>> I will try to cover the remaining 1835 bugs in the near future.
> >>>
> >>> This new one below seems tricky as I remember some discussion in the
> >>> past on the 18xx yahoo list about when and how the minors/privates
> >>> merge into the Prussian major.
> >>>
> >>> Could you tell me how you determine when the Prussian is allowed to
> >>> operate and who gets dividends paid out?
> >>>
> >>> In any case paying negative amounts seems plain wrong or is this
> >>> some kind of a workaround?
> >>>
> >>> Thanks,
> >>> Stefan
> >>>
> >>> On 10/14/2013 11:49 AM, Pieter Lust wrote:
> >>>> Hi
> >>>>
> >>>> In a recent game of 1835 with Rails the following occurred:
> >>>>
> >>>> The Prussian was started in operating round 8.1 . Some privates and
> >>>> minors merged, but not all. The Prussian didn't operate.
> >>>> At the start of operating round 8.2, one minor merged into the
> > Prussian.
> >>>> Player holdings were:
> >>>> Stan: 10% Prussian, M1 (not converted yet), BB private
> >>>> Dave: no Prussian shares, M6
> >>>> Neil: 20% Prussian
> >>>> Pier: 15% Prussian, M3, PfB private
> >>>> Easterly1: 30%, no minors
> >>>>
> >>>> The Prussian then operated, and paid dividends. This was the output
> >>>> from
> >>>> rails:
> >>>>
> >>>> PR pays out full dividend of 150M
> >>>> Stan gets no income for 15% PR shares as precursors have operated
> >>>> Pier gets no income for 5% PR shares as precursors have operated
> >>>> Stan receives -7M for -1 5% shares Pier receives 15M for 2 5%
> >>>> shares
> >>>> Easterly1 receives 45M for 6 5% shares Neil receives 30M for 4 5%
> >>>> shares
> >>>>
> >>>> This seems wrong: the minors didn't operate in the current
> >>>> operating round, so all converted shares should receive a dividend.
> >>>>
> >>>> Is this a bug?
> >>>>
> >>>> Sincerely
> >>>>
> >>>> Pieter
> >>>>
> >>>>
> >>>> -------------------------------------------------------------------
> >>>> -
> >>>> --
> >>>> -------- October Webinars: Code for Performance Free Intel webinars
> >>>> can help you accelerate application performance.
> >>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> >>>> most from the latest Intel processors and coprocessors. See
> >>>> abstracts and register >
> >>>>
> >> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg
> >>>> .c
> >>>> lktrk
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Rails-users mailing list
> >>>> Rai...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/rails-users
> >>>>
> >>>
> >>>
> >>>
> >>
> > ----------------------------------------------------------------------
> > ------
> >> --
> >>> October Webinars: Code for Performance Free Intel webinars can help
> >>> you accelerate application performance.
> >>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> >>> most from the latest Intel processors and coprocessors. See
> >>> abstracts and
> >> register
> >>>>
> >>>
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg
> >>> .c
> >>> lk
> >>> trk
> >>> _______________________________________________
> >>> Rails-devel mailing list
> >>> Rai...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >>
> >>
> >>
> > ----------------------------------------------------------------------
> > ------
> > --
> >> October Webinars: Code for Performance Free Intel webinars can help
> >> you accelerate application performance.
> >> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> >> most from the latest Intel processors and coprocessors. See abstracts
> >> and
> > register
> >>>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.
> >> clk
> >> trk
> >> _______________________________________________
> >> Rails-devel mailing list
> >> Rai...@li...
> >> https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> > ----------------------------------------------------------------------
> > -------- October Webinars: Code for Performance Free Intel webinars
> > can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> > most from the latest Intel processors and coprocessors. See abstracts
> > and register >
> > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.c
> > lktrk _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> 
>
----------------------------------------------------------------------------
--
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
register
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clk
> trk
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

[Rails-devel] Change git repo url (was: Bug with Prussian dividends in 1835?)

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

Erik:
I assume how to move to the changed URL of the git repo, as sourceforge
changed that:

Take a look here:
http://stackoverflow.com/questions/2432764/how-to-change-a-remote-repository-uri-using-git

Your remote URL (including your username) is shown under Code after you
have logged into sourceforge.

https://sourceforge.net/p/rails/code/ci/master/tree/

Hope this works for you.

Stefan

On 10/15/2013 12:48 PM, Erik Vos wrote:
> Can anyone remind me how to configure the new Git repo location in git bash?
> I can't find the config file, and there doesn't seem to be a lot of help on
> this matter.
> Erik
> 
>> -----Original Message-----
>> From: Erik Vos [mailto:eri...@xs...]
>> Sent: Tuesday, October 15, 2013 12:38 AM
>> To: 'Development list for Rails: an 18xx game'
>> Subject: Re: [Rails-devel] [Rails-users] Bug with Prussian dividends in
> 1835?
>>
>> Clearly negative amounts are erroneous.  But without a saved file it's
> hard to
>> track down such bugs.
>> I'll try to provide some answers tomorrow.
>> Erik
>>
>>> -----Original Message-----
>>> From: Stefan Frey [mailto:ste...@we...]
>>> Sent: Monday, October 14, 2013 4:30 PM
>>> To: Development list for Rails: an 18xx game
>>> Cc: pie...@ho...
>>> Subject: Re: [Rails-devel] [Rails-users] Bug with Prussian dividends
>>> in
>> 1835?
>>>
>>> Erik:
>>> I will try to cover the remaining 1835 bugs in the near future.
>>>
>>> This new one below seems tricky as I remember some discussion in the
>>> past on the 18xx yahoo list about when and how the minors/privates
>>> merge into the Prussian major.
>>>
>>> Could you tell me how you determine when the Prussian is allowed to
>>> operate and who gets dividends paid out?
>>>
>>> In any case paying negative amounts seems plain wrong or is this some
>>> kind of a workaround?
>>>
>>> Thanks,
>>> Stefan
>>>
>>> On 10/14/2013 11:49 AM, Pieter Lust wrote:
>>>> Hi
>>>>
>>>> In a recent game of 1835 with Rails the following occurred:
>>>>
>>>> The Prussian was started in operating round 8.1 . Some privates and
>>>> minors merged, but not all. The Prussian didn't operate.
>>>> At the start of operating round 8.2, one minor merged into the
> Prussian.
>>>> Player holdings were:
>>>> Stan: 10% Prussian, M1 (not converted yet), BB private
>>>> Dave: no Prussian shares, M6
>>>> Neil: 20% Prussian
>>>> Pier: 15% Prussian, M3, PfB private
>>>> Easterly1: 30%, no minors
>>>>
>>>> The Prussian then operated, and paid dividends. This was the output
>>>> from
>>>> rails:
>>>>
>>>> PR pays out full dividend of 150M
>>>> Stan gets no income for 15% PR shares as precursors have operated
>>>> Pier gets no income for 5% PR shares as precursors have operated
>>>> Stan receives -7M for -1 5% shares Pier receives 15M for 2 5% shares
>>>> Easterly1 receives 45M for 6 5% shares Neil receives 30M for 4 5%
>>>> shares
>>>>
>>>> This seems wrong: the minors didn't operate in the current operating
>>>> round, so all converted shares should receive a dividend.
>>>>
>>>> Is this a bug?
>>>>
>>>> Sincerely
>>>>
>>>> Pieter
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> --
>>>> -------- October Webinars: Code for Performance Free Intel webinars
>>>> can help you accelerate application performance.
>>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>>> most from the latest Intel processors and coprocessors. See
>>>> abstracts and register >
>>>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg
>>>> .c
>>>> lktrk
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Rails-users mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-users
>>>>
>>>
>>>
>>>
>>
> ----------------------------------------------------------------------------
>> --
>>> October Webinars: Code for Performance Free Intel webinars can help
>>> you accelerate application performance.
>>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>>> most from the latest Intel processors and coprocessors. See abstracts
>>> and
>> register
>>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.c
>>> lk
>>> trk
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>>
> ----------------------------------------------------------------------------
> --
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from the latest Intel processors and coprocessors. See abstracts and
> register
>>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clk
>> trk
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
> 

Re: [Rails-devel] 1880 SCR home hex position

[Lonny O. <lon...@gm...>]

As Chris said: Any orientation us allowed. 
Lonny

Am 15.10.2013 um 00:17 schrieb Martin Brumm <dr....@t-...>:

> Hello Lonny,
> 
> regarding the SCR home base token on N12 we hit an interesting problem
> in rails. Your original game map has the home base on the western hex.
> 
> So the question arose here, is the tile lay for #235 valid where the
> only track is leaving that hex on the eastern edge ?
> Or should it leave the hex at the western or northwestern or
> southwestern edge only ?
> 
> Is the painted home hex meant as SCR starts on the western side of the
> hex ? or can a player choose the orientation of #235 freely and will in
> all cases use the city with the track ?
> 
> Kind regards und schöne Grüsse nach Österreich :)
> 
> Martin
> 
> 

Re: [Rails-devel] [Rails-users] Bug with Prussian dividends in 1835?

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

Can anyone remind me how to configure the new Git repo location in git bash?
I can't find the config file, and there doesn't seem to be a lot of help on
this matter.
Erik

> -----Original Message-----
> From: Erik Vos [mailto:eri...@xs...]
> Sent: Tuesday, October 15, 2013 12:38 AM
> To: 'Development list for Rails: an 18xx game'
> Subject: Re: [Rails-devel] [Rails-users] Bug with Prussian dividends in
1835?
> 
> Clearly negative amounts are erroneous.  But without a saved file it's
hard to
> track down such bugs.
> I'll try to provide some answers tomorrow.
> Erik
> 
> > -----Original Message-----
> > From: Stefan Frey [mailto:ste...@we...]
> > Sent: Monday, October 14, 2013 4:30 PM
> > To: Development list for Rails: an 18xx game
> > Cc: pie...@ho...
> > Subject: Re: [Rails-devel] [Rails-users] Bug with Prussian dividends
> > in
> 1835?
> >
> > Erik:
> > I will try to cover the remaining 1835 bugs in the near future.
> >
> > This new one below seems tricky as I remember some discussion in the
> > past on the 18xx yahoo list about when and how the minors/privates
> > merge into the Prussian major.
> >
> > Could you tell me how you determine when the Prussian is allowed to
> > operate and who gets dividends paid out?
> >
> > In any case paying negative amounts seems plain wrong or is this some
> > kind of a workaround?
> >
> > Thanks,
> > Stefan
> >
> > On 10/14/2013 11:49 AM, Pieter Lust wrote:
> > > Hi
> > >
> > > In a recent game of 1835 with Rails the following occurred:
> > >
> > > The Prussian was started in operating round 8.1 . Some privates and
> > > minors merged, but not all. The Prussian didn't operate.
> > > At the start of operating round 8.2, one minor merged into the
Prussian.
> > > Player holdings were:
> > > Stan: 10% Prussian, M1 (not converted yet), BB private
> > > Dave: no Prussian shares, M6
> > > Neil: 20% Prussian
> > > Pier: 15% Prussian, M3, PfB private
> > > Easterly1: 30%, no minors
> > >
> > > The Prussian then operated, and paid dividends. This was the output
> > > from
> > > rails:
> > >
> > > PR pays out full dividend of 150M
> > > Stan gets no income for 15% PR shares as precursors have operated
> > > Pier gets no income for 5% PR shares as precursors have operated
> > > Stan receives -7M for -1 5% shares Pier receives 15M for 2 5% shares
> > > Easterly1 receives 45M for 6 5% shares Neil receives 30M for 4 5%
> > > shares
> > >
> > > This seems wrong: the minors didn't operate in the current operating
> > > round, so all converted shares should receive a dividend.
> > >
> > > Is this a bug?
> > >
> > > Sincerely
> > >
> > > Pieter
> > >
> > >
> > > --------------------------------------------------------------------
> > > --
> > > -------- October Webinars: Code for Performance Free Intel webinars
> > > can help you accelerate application performance.
> > > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> > > most from the latest Intel processors and coprocessors. See
> > > abstracts and register >
> > >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg
> > > .c
> > > lktrk
> > >
> > >
> > >
> > > _______________________________________________
> > > Rails-users mailing list
> > > Rai...@li...
> > > https://lists.sourceforge.net/lists/listinfo/rails-users
> > >
> >
> >
> >
>
----------------------------------------------------------------------------
> --
> > October Webinars: Code for Performance Free Intel webinars can help
> > you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> > most from the latest Intel processors and coprocessors. See abstracts
> > and
> register
> > >
> > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.c
> > lk
> > trk
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
>
----------------------------------------------------------------------------
--
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
register
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clk
> trk
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1880 SCR home hex position

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

Same here, it didn't occur to me that it could be limited to only one
side, it's a fairly bad company anyway, that restriction would make it
terrible.

Phil

On 14 October 2013 23:26, Chris Shaffer <chr...@gm...> wrote:
> Everyone I've ever played the game with used the "any orientation is
> allowed" option.
>
>
> --
> Chris
>
> Warning! NSA analysts could be reading this email. And because there’s
> hardly any accountability, we have no idea how they may use it. If that
> bothers you, click here to do something about it.
>
>
>
> On Mon, Oct 14, 2013 at 3:17 PM, Martin Brumm <dr....@t-...>
> wrote:
>>
>> Hello Lonny,
>>
>> regarding the SCR home base token on N12 we hit an interesting problem
>> in rails. Your original game map has the home base on the western hex.
>>
>> So the question arose here, is the tile lay for #235 valid where the
>> only track is leaving that hex on the eastern edge ?
>> Or should it leave the hex at the western or northwestern or
>> southwestern edge only ?
>>
>> Is the painted home hex meant as SCR starts on the western side of the
>> hex ? or can a player choose the orientation of #235 freely and will in
>> all cases use the city with the track ?
>>
>> Kind regards und schöne Grüsse nach Österreich :)
>>
>> Martin
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] [Rails-users] Bug with Prussian dividends in 1835?

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

Clearly negative amounts are erroneous.  But without a saved file it's hard
to track down such bugs.
I'll try to provide some answers tomorrow.
Erik

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Monday, October 14, 2013 4:30 PM
> To: Development list for Rails: an 18xx game
> Cc: pie...@ho...
> Subject: Re: [Rails-devel] [Rails-users] Bug with Prussian dividends in
1835?
> 
> Erik:
> I will try to cover the remaining 1835 bugs in the near future.
> 
> This new one below seems tricky as I remember some discussion in the past
> on the 18xx yahoo list about when and how the minors/privates merge into
> the Prussian major.
> 
> Could you tell me how you determine when the Prussian is allowed to
> operate and who gets dividends paid out?
> 
> In any case paying negative amounts seems plain wrong or is this some kind
> of a workaround?
> 
> Thanks,
> Stefan
> 
> On 10/14/2013 11:49 AM, Pieter Lust wrote:
> > Hi
> >
> > In a recent game of 1835 with Rails the following occurred:
> >
> > The Prussian was started in operating round 8.1 . Some privates and
> > minors merged, but not all. The Prussian didn't operate.
> > At the start of operating round 8.2, one minor merged into the Prussian.
> > Player holdings were:
> > Stan: 10% Prussian, M1 (not converted yet), BB private
> > Dave: no Prussian shares, M6
> > Neil: 20% Prussian
> > Pier: 15% Prussian, M3, PfB private
> > Easterly1: 30%, no minors
> >
> > The Prussian then operated, and paid dividends. This was the output
> > from
> > rails:
> >
> > PR pays out full dividend of 150M
> > Stan gets no income for 15% PR shares as precursors have operated Pier
> > gets no income for 5% PR shares as precursors have operated Stan
> > receives -7M for -1 5% shares Pier receives 15M for 2 5% shares
> > Easterly1 receives 45M for 6 5% shares Neil receives 30M for 4 5%
> > shares
> >
> > This seems wrong: the minors didn't operate in the current operating
> > round, so all converted shares should receive a dividend.
> >
> > Is this a bug?
> >
> > Sincerely
> >
> > Pieter
> >
> >
> > ----------------------------------------------------------------------
> > -------- October Webinars: Code for Performance Free Intel webinars
> > can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> > most from the latest Intel processors and coprocessors. See abstracts
> > and register >
> > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.c
> > lktrk
> >
> >
> >
> > _______________________________________________
> > Rails-users mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-users
> >
> 
> 
>
----------------------------------------------------------------------------
--
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
register
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clk
> trk
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] 1880 SCR home hex position

[Chris S. <chr...@gm...>]

Everyone I've ever played the game with used the "any orientation is
allowed" option.


--
Chris

*Warning! NSA analysts could be reading this email. And because there’s
hardly any accountability, we have no idea how they may use it. If that
bothers you, click here to do something about
it.<https://www.aclu.org/secure/stopnsa>
*


On Mon, Oct 14, 2013 at 3:17 PM, Martin Brumm
<dr....@t-...>wrote:

> Hello Lonny,
>
> regarding the SCR home base token on N12 we hit an interesting problem
> in rails. Your original game map has the home base on the western hex.
>
> So the question arose here, is the tile lay for #235 valid where the
> only track is leaving that hex on the eastern edge ?
> Or should it leave the hex at the western or northwestern or
> southwestern edge only ?
>
> Is the painted home hex meant as SCR starts on the western side of the
> hex ? or can a player choose the orientation of #235 freely and will in
> all cases use the city with the track ?
>
> Kind regards und schöne Grüsse nach Österreich :)
>
> Martin
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

[Rails-devel] 1880 SCR home hex position

[Martin B. <dr....@t-...>]

Hello Lonny,

regarding the SCR home base token on N12 we hit an interesting problem
in rails. Your original game map has the home base on the western hex.

So the question arose here, is the tile lay for #235 valid where the
only track is leaving that hex on the eastern edge ?
Or should it leave the hex at the western or northwestern or
southwestern edge only ?

Is the painted home hex meant as SCR starts on the western side of the
hex ? or can a player choose the orientation of #235 freely and will in
all cases use the city with the track ?

Kind regards und schöne Grüsse nach Österreich :)

Martin

Re: [Rails-devel] [Rails-users] Bug with Prussian dividends in 1835?

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

Erik:
I will try to cover the remaining 1835 bugs in the near future.

This new one below seems tricky as I remember some discussion in the 
past on the 18xx yahoo list about when and how the minors/privates merge 
into the Prussian major.

Could you tell me how you determine when the Prussian is allowed to 
operate and who gets dividends paid out?

In any case paying negative amounts seems plain wrong or is this some 
kind of a workaround?

Thanks,
Stefan

On 10/14/2013 11:49 AM, Pieter Lust wrote:
> Hi
>
> In a recent game of 1835 with Rails the following occurred:
>
> The Prussian was started in operating round 8.1 . Some privates and
> minors merged, but not all. The Prussian didn't operate.
> At the start of operating round 8.2, one minor merged into the Prussian.
> Player holdings were:
> Stan: 10% Prussian, M1 (not converted yet), BB private
> Dave: no Prussian shares, M6
> Neil: 20% Prussian
> Pier: 15% Prussian, M3, PfB private
> Easterly1: 30%, no minors
>
> The Prussian then operated, and paid dividends. This was the output from
> rails:
>
> PR pays out full dividend of 150M
> Stan gets no income for 15% PR shares as precursors have operated
> Pier gets no income for 5% PR shares as precursors have operated
> Stan receives -7M for -1 5% shares
> Pier receives 15M for 2 5% shares
> Easterly1 receives 45M for 6 5% shares
> Neil receives 30M for 4 5% shares
>
> This seems wrong: the minors didn't operate in the current operating
> round, so all converted shares should receive a dividend.
>
> Is this a bug?
>
> Sincerely
>
> Pieter
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Rails-users mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-users
>

Re: [Rails-devel] Whitespace Problems

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

+1.  A .gitattributes file sounds like it solves the issue.

---Brett


---Brett.


On Mon, Oct 14, 2013 at 2:03 AM, Stefan Frey <ste...@we...> wrote:

> Sorry for replying so late, I took me some time to understand how git is
> working exactly. And as it is usual for difficult problems, there are
> legacy issues involved, in this case it is an legacy issue of git to
> solve a legacy issue of text files ;-)
>
> Best explanation I found was:
> http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
>
> Best stackoverflow entry (which points to the article above)
>
> http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git
>
> Best template for of .gitattributes for a java repo:
> https://github.com/Danimoth/gitattributes/blob/master/Java.gitattributes
>
> And the man page for gitattributes is very instructive as well.
>
> So for me it seems best way to solve that for future problems to add a
> .gitattributes file similar to the java template above to the repo and
> then commit the normalization to the repo. This has to be done once by
> one user of the repo.
>
> I would to do this change, as soon as I have the "go ahead" command from
> at least Erik and Brett.
>
> Stefan
>
> PS:
> A) Interesting detail is the the best answer and the best article still
> differ in best practice for including a default line in .gitattributes:
>
> # Auto detect text files and perform LF normalization
> *        text=auto
>
> Article discourages such a strategy (see bottom paragraph), however
> Stackoverflow answer example includes it:
>
> B) It seems that git normalizes to LF internally always. What you get on
> checkout from the repo (or more precisely from your local copy of
> the git object database) depends first on the setting of "eol" in
> .gitattributes (if specified) and then on the local core.autocrlf
> definition of the user.
>
> Thus in our scenario we would have LF internally, but still converting
> to CRLF for the windows users.
>
>
>
> On 10/06/2013 05:16 PM, brett lentz wrote:
> > The issue is that we want line endings to be consistent in the
> > repository, regardless of platform.
> >
> > Text=auto just sets all of the line endings to whatever your platform is
> > using.
> >
> > See the documentation on the core.autocrlf and core.safecrlf config
> > options:
> https://www.kernel.org/pub/software/scm/git/docs/git-config.html
> >
> > Basically, we just need to agree whether LF or CRLF will be the
> > "standard" for the repository, and ensure the repository is configured
> > to auto-convert in the correct direction when committing and pushing
> > changes.
> >
> > ---Brett.
> >
> >
> > ---Brett.
> >
> >
> > On Sat, Oct 5, 2013 at 3:25 PM, Martin Brumm
> > <dr....@t-... <mailto:dr....@t-...>>
> wrote:
> >
> >     Hi Brett,
> >
> >     i rather thought it should be
> >     * text=auto ?
> >
> >     Rgrds,
> >     Martin
> >
> >     Am 04.10.2013 15:32, schrieb brett lentz:
> >>     +1 from me.
> >>
> >>     IMO, it should be:
> >>
> >>
> >>             text eol=lf
> >>
> >>
> >>
> >>     ---Brett.
> >>
> >>
> >>     On Fri, Oct 4, 2013 at 7:13 AM, Martin Brumm
> >>     <dr....@t-... <mailto:dr....@t-...>>
> >>     wrote:
> >>
> >>         Hi,
> >>
> >>         i am running into repeated whitespace problems again and again.
> >>
> >>         Please have  a look at the following article and lets discuss
> >>         if that is
> >>         a valid way to avoid them in the future :)
> >>
> >>         https://help.github.com/articles/dealing-with-line-endings
> >>
> >>         Kind Regards,
> >>         Martin
> >>
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> >     October Webinars: Code for Performance
> >     Free Intel webinars can help you accelerate application performance.
> >     Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
> >     most from
> >     the latest Intel processors and coprocessors. See abstracts and
> >     register >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> >     _______________________________________________
> >     Rails-devel mailing list
> >     Rai...@li...
> >     <mailto:Rai...@li...>
> >     https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> > the latest Intel processors and coprocessors. See abstracts and register
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> >
> >
> >
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> >
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134071&iu=/4140/ostg.clktrk
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

Re: [Rails-devel] Whitespace Problems

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

Sorry for replying so late, I took me some time to understand how git is 
working exactly. And as it is usual for difficult problems, there are 
legacy issues involved, in this case it is an legacy issue of git to 
solve a legacy issue of text files ;-)

Best explanation I found was:
http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/

Best stackoverflow entry (which points to the article above)
http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git

Best template for of .gitattributes for a java repo:
https://github.com/Danimoth/gitattributes/blob/master/Java.gitattributes

And the man page for gitattributes is very instructive as well.

So for me it seems best way to solve that for future problems to add a 
.gitattributes file similar to the java template above to the repo and 
then commit the normalization to the repo. This has to be done once by 
one user of the repo.

I would to do this change, as soon as I have the "go ahead" command from 
at least Erik and Brett.

Stefan

PS:
A) Interesting detail is the the best answer and the best article still 
differ in best practice for including a default line in .gitattributes:

# Auto detect text files and perform LF normalization
*        text=auto

Article discourages such a strategy (see bottom paragraph), however 
Stackoverflow answer example includes it:

B) It seems that git normalizes to LF internally always. What you get on 
checkout from the repo (or more precisely from your local copy of
the git object database) depends first on the setting of "eol" in 
.gitattributes (if specified) and then on the local core.autocrlf 
definition of the user.

Thus in our scenario we would have LF internally, but still converting 
to CRLF for the windows users.



On 10/06/2013 05:16 PM, brett lentz wrote:
> The issue is that we want line endings to be consistent in the
> repository, regardless of platform.
>
> Text=auto just sets all of the line endings to whatever your platform is
> using.
>
> See the documentation on the core.autocrlf and core.safecrlf config
> options: https://www.kernel.org/pub/software/scm/git/docs/git-config.html
>
> Basically, we just need to agree whether LF or CRLF will be the
> "standard" for the repository, and ensure the repository is configured
> to auto-convert in the correct direction when committing and pushing
> changes.
>
> ---Brett.
>
>
> ---Brett.
>
>
> On Sat, Oct 5, 2013 at 3:25 PM, Martin Brumm
> <dr....@t-... <mailto:dr....@t-...>> wrote:
>
>     Hi Brett,
>
>     i rather thought it should be
>     * text=auto ?
>
>     Rgrds,
>     Martin
>
>     Am 04.10.2013 15:32, schrieb brett lentz:
>>     +1 from me.
>>
>>     IMO, it should be:
>>
>>
>>             text eol=lf
>>
>>
>>
>>     ---Brett.
>>
>>
>>     On Fri, Oct 4, 2013 at 7:13 AM, Martin Brumm
>>     <dr....@t-... <mailto:dr....@t-...>>
>>     wrote:
>>
>>         Hi,
>>
>>         i am running into repeated whitespace problems again and again.
>>
>>         Please have  a look at the following article and lets discuss
>>         if that is
>>         a valid way to avoid them in the future :)
>>
>>         https://help.github.com/articles/dealing-with-line-endings
>>
>>         Kind Regards,
>>         Martin
>>
>>
>
>
>     ------------------------------------------------------------------------------
>     October Webinars: Code for Performance
>     Free Intel webinars can help you accelerate application performance.
>     Explore tips for MPI, OpenMP, advanced profiling, and more. Get the
>     most from
>     the latest Intel processors and coprocessors. See abstracts and
>     register >
>     http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>     _______________________________________________
>     Rails-devel mailing list
>     Rai...@li...
>     <mailto:Rai...@li...>
>     https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>

[Rails-devel] Announcing Release .1.8.1 Bugfixes and enhancements to rails for 1880

[Martin B. <dr....@t-...>]

Hello fellow rails fans,

please find the excerpt from the readme accompagnying Release 1.8.1. below:

Rails release 1.8.1

This is a minor release fixing a number of minor glitches:

IPO shares of not started companies were highlighted as possible actions
even though the player was
lacking the money to start a corporation.
Fixing Tiles definitions and display tiles for 1880. Numerous
connections and positions were wrong. (8887 and 8888 for sure).
Fixed 2R train availability. (Michael)
Fixed updating problem with parSlots. (Michael)
Adjusting Gameslist.xml to reflect new status of 1880, moved the game
up in the list to the historical lineup.
Added Frederick Weld as Contributor to gameslist.xml

And some nice enhancement:
Added new pane to show par slots and last company to purchase a train.
(Michael)
 
Please report any bugs you find on the mailinglist as usual.

Thank you for the patience and feedback.

Martin & Michael (together with the rest of the rails crew :))

Re: [Rails-devel] Whitespace Problems

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

The issue is that we want line endings to be consistent in the repository,
regardless of platform.

Text=auto just sets all of the line endings to whatever your platform is
using.

See the documentation on the core.autocrlf and core.safecrlf config
options: https://www.kernel.org/pub/software/scm/git/docs/git-config.html

Basically, we just need to agree whether LF or CRLF will be the "standard"
for the repository, and ensure the repository is configured to auto-convert
in the correct direction when committing and pushing changes.

---Brett.


---Brett.


On Sat, Oct 5, 2013 at 3:25 PM, Martin Brumm <dr....@t-...>wrote:

>  Hi Brett,
>
> i rather thought it should be
> * text=auto ?
>
> Rgrds,
> Martin
>
> Am 04.10.2013 15:32, schrieb brett lentz:
>
> +1 from me.
>
>  IMO, it should be:
> text eol=lf
>
>
> ---Brett.
>
>
> On Fri, Oct 4, 2013 at 7:13 AM, Martin Brumm <dr....@t-...>wrote:
>
>> Hi,
>>
>> i am running into repeated whitespace problems again and again.
>>
>> Please have  a look at the following article and lets discuss if that is
>> a valid way to avoid them in the future :)
>>
>> https://help.github.com/articles/dealing-with-line-endings
>>
>> Kind Regards,
>> Martin
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] Whitespace Problems

[Martin B. <dr....@t-...>]

Hi Brett,

i rather thought it should be
* text=auto ?

Rgrds,
Martin

Am 04.10.2013 15:32, schrieb brett lentz:
> +1 from me.
>
> IMO, it should be:   
>
>
>         text eol=lf
>
>
>
> ---Brett.
>
>
> On Fri, Oct 4, 2013 at 7:13 AM, Martin Brumm
> <dr....@t-... <mailto:dr....@t-...>> wrote:
>
>     Hi,
>
>     i am running into repeated whitespace problems again and again.
>
>     Please have  a look at the following article and lets discuss if
>     that is
>     a valid way to avoid them in the future :)
>
>     https://help.github.com/articles/dealing-with-line-endings
>
>     Kind Regards,
>     Martin
>
>

[Rails-devel] Rails now supports the 1880 variant of Double O - Release 1.8.0 is now available

[Martin B. <dr....@t-...>]

Hello Rails-Community,

after a long time we are now able to present you with a new variant
being fully supported (at least we think so :)) by rails.

1880 is now fully supported by rails 1.8.0. Our tests didnt bring up
bugs sofar. If you find some or think you found one, please send the
save game based on 1.8.0.

There shouldnt be any problems with other savegames from the
1.7.10-1.7.12 releases either.

I would like to thank Erik Vos, Brett Lentz and Stefan Frey for their
support in the past 2 years.

And of course i have to thank Michael Alexander for the finishing
touches of the more complex code parts needed to make 1880 work in rails
finally.

Have fun,

Martin Brumm

Re: [Rails-devel] FW: [rails:bugs] #170 1856: Companies float too soon.

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

Michael -

This might be a good opportunity to clarify the javadoc for the
hasFloated() method. It'll make future looks at the code easier.

---Brett.


---Brett.


On Fri, Oct 4, 2013 at 5:55 PM, Michael Alexander
<out...@gm...>wrote:

> My sincere apologies - I completely jumped the gun based on what I thought
> was meant.  It seems to be working perfectly.
>
> Mike
>
>
> On Fri, Oct 4, 2013 at 4:59 PM, Erik Vos <eri...@xs...> wrote:
>
>> The term “floating” does not occur in the 1856 rules, only ”operating” is
>> used. Having floated has no meaning in 1856.****
>>
>> ** **
>>
>> In Rails, setFloated() is called in the SR as usual, as Rails requires
>> it, but that does not imply that the company actually will operate.****
>>
>> At the start of each 1856 OR, Rails does an additional check if each
>> company can operate, including the check on number of shares. If it fails
>> that test, the company will not be included in the list of operating
>> companies for that OR.****
>>
>> ** **
>>
>> A similar thing occurs when the CGR has been formed but at least one of
>> its precursors has operated: it has “floated” but does not yet operate.**
>> **
>>
>> ** **
>>
>> So I don’t think there is a bug – unless you can prove it with an actual
>> saved game.  ****
>>
>> ** **
>>
>> Erik.****
>>
>> ** **
>>
>> *From:* Michael Alexander [mailto:out...@us...]
>> *Sent:* Friday, October 04, 2013 7:39 AM
>> *To:* Ticket 170
>> *Subject:* [rails:bugs] #170 1856: Companies float too soon.****
>>
>> ** **
>> ------------------------------
>>
>> *[bugs:#170] <http://sourceforge.net/p/rails/bugs/170/> 1856: Companies
>> float too soon.*****
>>
>> *Status:* open
>> *Created:* Fri Oct 04, 2013 05:38 AM UTC by Michael Alexander
>> *Last Updated:* Fri Oct 04, 2013 05:38 AM UTC
>> *Owner:* nobody****
>>
>> In 1856, companies are floating during the stock round. They should only
>> check to see if they float when it is their turn in the operating round. It
>> is very possible by the rules, for example, for a company to open with 2
>> shares in the initial stock round, but when it is their turn to operate for
>> the first time, no 2-trains are left. In this case, the company does not
>> actually open or operate.****
>> ------------------------------
>>
>> Sent from sourceforge.net because you indicated interest in
>> https://sourceforge.net/p/rails/bugs/170/****
>>
>> To unsubscribe from further messages, please visit
>> https://sourceforge.net/auth/subscriptions/****
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>

Re: [Rails-devel] FW: [rails:bugs] #170 1856: Companies float too soon.

[Michael A. <out...@gm...>]

My sincere apologies - I completely jumped the gun based on what I thought
was meant.  It seems to be working perfectly.

Mike


On Fri, Oct 4, 2013 at 4:59 PM, Erik Vos <eri...@xs...> wrote:

> The term “floating” does not occur in the 1856 rules, only ”operating” is
> used. Having floated has no meaning in 1856.****
>
> ** **
>
> In Rails, setFloated() is called in the SR as usual, as Rails requires it,
> but that does not imply that the company actually will operate.****
>
> At the start of each 1856 OR, Rails does an additional check if each
> company can operate, including the check on number of shares. If it fails
> that test, the company will not be included in the list of operating
> companies for that OR.****
>
> ** **
>
> A similar thing occurs when the CGR has been formed but at least one of
> its precursors has operated: it has “floated” but does not yet operate.***
> *
>
> ** **
>
> So I don’t think there is a bug – unless you can prove it with an actual
> saved game.  ****
>
> ** **
>
> Erik.****
>
> ** **
>
> *From:* Michael Alexander [mailto:out...@us...]
> *Sent:* Friday, October 04, 2013 7:39 AM
> *To:* Ticket 170
> *Subject:* [rails:bugs] #170 1856: Companies float too soon.****
>
> ** **
> ------------------------------
>
> *[bugs:#170] <http://sourceforge.net/p/rails/bugs/170/> 1856: Companies
> float too soon.*****
>
> *Status:* open
> *Created:* Fri Oct 04, 2013 05:38 AM UTC by Michael Alexander
> *Last Updated:* Fri Oct 04, 2013 05:38 AM UTC
> *Owner:* nobody****
>
> In 1856, companies are floating during the stock round. They should only
> check to see if they float when it is their turn in the operating round. It
> is very possible by the rules, for example, for a company to open with 2
> shares in the initial stock round, but when it is their turn to operate for
> the first time, no 2-trains are left. In this case, the company does not
> actually open or operate.****
> ------------------------------
>
> Sent from sourceforge.net because you indicated interest in
> https://sourceforge.net/p/rails/bugs/170/****
>
> To unsubscribe from further messages, please visit
> https://sourceforge.net/auth/subscriptions/****
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>