You can subscribe to this list here.
2005 |
Jan
|
Feb
(25) |
Mar
(84) |
Apr
(76) |
May
(25) |
Jun
(1) |
Jul
(28) |
Aug
(23) |
Sep
(50) |
Oct
(46) |
Nov
(65) |
Dec
(76) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2006 |
Jan
(60) |
Feb
(33) |
Mar
(4) |
Apr
(17) |
May
(16) |
Jun
(18) |
Jul
(131) |
Aug
(11) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(5) |
2007 |
Jan
(71) |
Feb
|
Mar
|
Apr
|
May
(6) |
Jun
(19) |
Jul
(40) |
Aug
(38) |
Sep
(7) |
Oct
(58) |
Nov
|
Dec
(10) |
2008 |
Jan
(17) |
Feb
(27) |
Mar
(12) |
Apr
(1) |
May
(50) |
Jun
(10) |
Jul
|
Aug
(15) |
Sep
(24) |
Oct
(64) |
Nov
(115) |
Dec
(47) |
2009 |
Jan
(30) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(5) |
Aug
|
Sep
|
Oct
(4) |
Nov
(132) |
Dec
(93) |
2010 |
Jan
(266) |
Feb
(120) |
Mar
(168) |
Apr
(127) |
May
(83) |
Jun
(93) |
Jul
(77) |
Aug
(77) |
Sep
(86) |
Oct
(30) |
Nov
(4) |
Dec
(22) |
2011 |
Jan
(48) |
Feb
(81) |
Mar
(198) |
Apr
(174) |
May
(72) |
Jun
(101) |
Jul
(236) |
Aug
(144) |
Sep
(54) |
Oct
(132) |
Nov
(94) |
Dec
(111) |
2012 |
Jan
(135) |
Feb
(166) |
Mar
(86) |
Apr
(85) |
May
(137) |
Jun
(83) |
Jul
(54) |
Aug
(29) |
Sep
(49) |
Oct
(37) |
Nov
(8) |
Dec
(6) |
2013 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
(14) |
May
(5) |
Jun
(15) |
Jul
|
Aug
(38) |
Sep
(44) |
Oct
(45) |
Nov
(40) |
Dec
(23) |
2014 |
Jan
(22) |
Feb
(63) |
Mar
(43) |
Apr
(60) |
May
(10) |
Jun
(5) |
Jul
(13) |
Aug
(57) |
Sep
(36) |
Oct
(2) |
Nov
(30) |
Dec
(27) |
2015 |
Jan
(5) |
Feb
(2) |
Mar
(14) |
Apr
(3) |
May
|
Jun
(3) |
Jul
(10) |
Aug
(63) |
Sep
(31) |
Oct
(26) |
Nov
(11) |
Dec
(6) |
2016 |
Jan
|
Feb
(11) |
Mar
|
Apr
|
May
(1) |
Jun
(16) |
Jul
|
Aug
(4) |
Sep
|
Oct
(1) |
Nov
(4) |
Dec
(1) |
2017 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(1) |
Jun
(20) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(6) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
(10) |
May
(10) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(3) |
Apr
(9) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(7) |
Dec
(4) |
2021 |
Jan
(5) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Mike B. <com...@ip...> - 2013-10-23 09:06:31
|
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 |
From: Stefan F. <ste...@we...> - 2013-10-23 06:07:05
|
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" |
From: Erik V. <eri...@xs...> - 2013-10-22 20:51:53
|
> 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. |
From: Martin B. <dr....@t-...> - 2013-10-22 20:19:34
|
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 |
From: Jeff V. <je...@je...> - 2013-10-22 20:00:42
|
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. :-) |
From: Martin B. <dr....@t-...> - 2013-10-20 20:54:09
|
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 |
From: Martin B. <dr....@t-...> - 2013-10-20 16:03:32
|
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 |
From: Erik V. <eri...@xs...> - 2013-10-15 13:58:33
|
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 |
From: Erik V. <eri...@xs...> - 2013-10-15 12:59:56
|
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 |
From: Stefan F. <ste...@we...> - 2013-10-15 11:11:24
|
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 > |
From: Lonny O. <lon...@gm...> - 2013-10-15 10:54:11
|
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 > > |
From: Erik V. <eri...@xs...> - 2013-10-15 10:48:57
|
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 |
From: Phil D. <de...@gm...> - 2013-10-15 09:00:52
|
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 > |
From: Erik V. <eri...@xs...> - 2013-10-14 22:37:39
|
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 |
From: Chris S. <chr...@gm...> - 2013-10-14 22:26:23
|
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 > > |
From: Martin B. <dr....@t-...> - 2013-10-14 22:17:49
|
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 |
From: Stefan F. <ste...@we...> - 2013-10-14 14:30:16
|
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 > |
From: brett l. <bre...@gm...> - 2013-10-14 12:43:54
|
+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 > |
From: Stefan F. <ste...@we...> - 2013-10-14 06:03:55
|
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 > |
From: Martin B. <dr....@t-...> - 2013-10-13 14:56:23
|
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 :)) |
From: brett l. <bre...@gm...> - 2013-10-06 15:16:39
|
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 > > |
From: Martin B. <dr....@t-...> - 2013-10-05 19:25:00
|
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 > > |
From: Martin B. <dr....@t-...> - 2013-10-04 22:27:19
|
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 |
From: brett l. <bre...@gm...> - 2013-10-04 21:58:01
|
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 > > |
From: Michael A. <out...@gm...> - 2013-10-04 21:55:28
|
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 > > |