From: Bill R. <ro...@gm...> - 2012-02-07 03:41:47
|
Hello, I've attached a patch to fix the recently reported 1856 upgrade bug regarding which phases dits can be upgraded/downgraded in. The problem is in the data files, where the phase names for these tile lays is incorrect (Phases 5,6 should be 6,D). I've also attached two savegames of a test game that show the problem: in the first, dits can be upgraded too early, as a 6 train has not yet been purchases, and in the second dits cannot be upgraded once a diesel has been bought. There are two patches, the first (0001-...) is in git format and the second (1856%3A...) is in Eclipse format. Both patches are against the rails1.6.x branch, as with the recent UI work in master, I'm currently unable to get 1856 to work. The patches should apply cleanly to master as well, but I'm not sure how hard it is to persuade git to do this without a cherry-pick. If it is difficult to apply these patches, it may be easier to simply correct the data files by hand. Bill |
From: Stefan F. <ste...@we...> - 2012-02-07 09:34:14
|
Bill: thanks for the patch. The git one works perfectly, so you can restrict yourself to that one in the future. There will be another another bug-fix release later today. Frederick could look into the issue of 1856 not running in master? Most likely that is due to customized UI classes? Interestingly this is another case where there is no ex-post check for illegal actions in the game engine. Thus games can be loaded without an error even if the tile upgrade is considered illegal due to the changed data files. Stefan On 02/07/2012 04:41 AM, Bill Rosgen wrote: > Hello, > > I've attached a patch to fix the recently reported 1856 upgrade bug regarding which phases dits can be upgraded/downgraded in. The problem is in the data files, where the phase names for these tile lays is incorrect (Phases 5,6 should be 6,D). > > I've also attached two savegames of a test game that show the problem: in the first, dits can be upgraded too early, as a 6 train has not yet been purchases, and in the second dits cannot be upgraded once a diesel has been bought. > > There are two patches, the first (0001-...) is in git format and the second (1856%3A...) is in Eclipse format. Both patches are against the rails1.6.x branch, as with the recent UI work in master, I'm currently unable to get 1856 to work. The patches should apply cleanly to master as well, but I'm not sure how hard it is to persuade git to do this without a cherry-pick. If it is difficult to apply these patches, it may be easier to simply correct the data files by hand. > > Bill > > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Frederick W. <fre...@go...> - 2012-02-07 10:07:37
|
Bill: What symptom have you seen when running 1856 in master? - Is it that some class is not found? (the new libs have to added to the java project...) - Does the symptom only occur for the attached save games or also for new games? -- Frederick |
From: Bill R. <ro...@gm...> - 2012-02-07 14:11:50
|
On 2012-02-07, at 18:07 , Frederick Weld wrote: > Bill: > What symptom have you seen when running 1856 in master? > - Is it that some class is not found? (the new libs have to added to > the java project...) > - Does the symptom only occur for the attached save games or also for new games? I tried to create a (new) test game on the master branch. The Private Auction and SR1 seemed to go well, but when I passed to end the stock round I could not seem to do anything for the operating rounds. Upon trying again, there's a NullPointerException being thrown: see the stack trace below. This is possibly some kind of Java version issue: I'm using the 1.6 that seems to have shipped with my operating system (Mac OS 10.6). The same thing happens when I try to start a game of 1830 too, so I don't think it's 1856-specific. If it's useful, the behaviour I see is: upon passing for the last player in the SR, all that seemed to happen was the cash totals per player were increased (as the privates had paid out). At this point I was left looking at the main status screen with no indication of what to do next. The 'autopass' button was still available, but pressing it seemed to have no effect. I could locate the map window, but I wasn't able to operate the first company. The home token was laid, but I could not select any hexes for track laying: clicking on the map seemed to have no effect. The stack trace is: Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException at rails.ui.swing.GridPanel$FieldBorder.<init>(GridPanel.java:257) at rails.ui.swing.GridPanel.addField(GridPanel.java:125) at rails.ui.swing.ORPanel.initFields(ORPanel.java:606) at rails.ui.swing.ORPanel.recreate(ORPanel.java:266) at rails.ui.swing.ORWindow.activate(ORWindow.java:287) at rails.ui.swing.ORUIManager.initOR(ORUIManager.java:127) at rails.ui.swing.GameUIManager.updateUI(GameUIManager.java:433) at rails.ui.swing.GameUIManager.processAction(GameUIManager.java:300) at rails.ui.swing.StatusWindow.process(StatusWindow.java:683) at rails.ui.swing.StatusWindow.actionPerformed(StatusWindow.java:632) at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2028) at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2351) at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:387) at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:242) at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:236) at java.awt.Component.processMouseEvent(Component.java:6373) at javax.swing.JComponent.processMouseEvent(JComponent.java:3267) at java.awt.Component.processEvent(Component.java:6138) at java.awt.Container.processEvent(Container.java:2085) at java.awt.Component.dispatchEventImpl(Component.java:4735) at java.awt.Container.dispatchEventImpl(Container.java:2143) at java.awt.Component.dispatchEvent(Component.java:4565) at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4621) at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4282) at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4212) at java.awt.Container.dispatchEventImpl(Container.java:2129) at java.awt.Window.dispatchEventImpl(Window.java:2478) at java.awt.Component.dispatchEvent(Component.java:4565) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:679) at java.awt.EventQueue.access$000(EventQueue.java:85) at java.awt.EventQueue$1.run(EventQueue.java:638) at java.awt.EventQueue$1.run(EventQueue.java:636) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87) at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:98) at java.awt.EventQueue$2.run(EventQueue.java:652) at java.awt.EventQueue$2.run(EventQueue.java:650) at java.security.AccessController.doPrivileged(Native Method) at java.security.AccessControlContext$1.doIntersectionPrivilege(AccessControlContext.java:87) at java.awt.EventQueue.dispatchEvent(EventQueue.java:649) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:296) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:211) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:196) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:188) at java.awt.EventDispatchThread.run(EventDispatchThread.java:122) The output of java -version: java version "1.6.0_29" Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) |
From: Frederick W. <fre...@go...> - 2012-02-07 16:45:52
|
Bill: Thanks for the details. Unfortunately, I wasn't able to reproduce the exception, even when disabling the grid table layout option. But the details you provided were enough to identify the symptom (getBorderInsets returns null on the field to be added). Now, the GridPanel should be robust enough to handle that. The problem is that this perhaps does not really help you as you reported that the OR window didn't proceed to OR 1.1. I can't tell why this is the case unless being able to reproduce the issue... Would you mind checking what happens now on your local installation? --Frederick |
From: Stefan F. <ste...@we...> - 2012-02-07 18:18:21
|
Bill: I tried to recreate the error too, but this was not possible for me either. Could you please provide a game file, which is stored just before this occurs (or even at the time of error, if saving is still possible). Two weeks ago I got the same behavior reported by friends playing a face-to-face game, however no save file received for that occasion too. Thanks, Stefan On 02/07/2012 05:45 PM, Frederick Weld wrote: > Bill: > Thanks for the details. > Unfortunately, I wasn't able to reproduce the exception, even when > disabling the grid table layout option. > But the details you provided were enough to identify the symptom > (getBorderInsets returns null on the field to be added). Now, the > GridPanel should be robust enough to handle that. > > The problem is that this perhaps does not really help you as you > reported that the OR window didn't proceed to OR 1.1. I can't tell why > this is the case unless being able to reproduce the issue... > > Would you mind checking what happens now on your local installation? > > --Frederick > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Bill R. <ro...@gm...> - 2012-02-08 01:27:47
Attachments:
1830_gridpanel_NullPointerException.rails
|
On 2012-02-08, at 0:45 , Frederick Weld wrote: > Bill: > Thanks for the details. > Unfortunately, I wasn't able to reproduce the exception, even when > disabling the grid table layout option. > But the details you provided were enough to identify the symptom > (getBorderInsets returns null on the field to be added). Now, the > GridPanel should be robust enough to handle that. > > The problem is that this perhaps does not really help you as you > reported that the OR window didn't proceed to OR 1.1. I can't tell why > this is the case unless being able to reproduce the issue... > > Would you mind checking what happens now on your local installation? > > --Frederick Frederik and Stefan, I am still seeing the problem. Looking at it in the debugger, when the exception is thrown it is not because getBorderInsets returns null, it is because innerBorder (and thus nativeInnerBorder) is null. Digging further, this happens when GridPanel.addField is called to add a Spinner, which has a null border, and so passes in a null value to the constructor. I can make this problem go away by adding the following test to the FieldBorder constructor, just above line 257 where I get the exception: if (innerBorder == null) return; Once I do this, the interface works as expected, but I do not know what side effects are likely to occur as a result. I've attached a savegame, but as far as I can tell the problem is completely generic. This happens when I create new games and when I load existing games. Bill |
From: Stefan F. <ste...@we...> - 2012-02-08 14:10:31
|
Bill & Frederick, on my system the error does not occur. Neither with the attached file, nor any other save file and not after creating a new game. I even setup a new default configuration profile that should be identical to the on that Bill uses (or do you have any changes to your configuration active?). However I believe the error is real and most likely the fix below seems to be reasonable, so if Frederick confirms that it has no side-effects I would release 1.6.4 hot-fix with that and the 1835 bug adressed. Stefan > > Frederik and Stefan, > > I am still seeing the problem. Looking at it in the debugger, when the exception is thrown it is not because getBorderInsets returns null, it is because innerBorder (and thus nativeInnerBorder) is null. > > Digging further, this happens when GridPanel.addField is called to add a Spinner, which has a null border, and so passes in a null value to the constructor. > > I can make this problem go away by adding the following test to the FieldBorder constructor, just above line 257 where I get the exception: > > if (innerBorder == null) return; > > Once I do this, the interface works as expected, but I do not know what side effects are likely to occur as a result. > > I've attached a savegame, but as far as I can tell the problem is completely generic. This happens when I create new games and when I load existing games. > > Bill > > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > > > > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Frederick W. <fre...@go...> - 2012-02-08 16:48:14
|
Bill: Thanks for the additional information. It appears that, on your local machine, JSpinner gets a null border by default (whereas it gets a non-null border on other machines) - very weird. Master should now be able to cope with that. Stefan: No need for a hotfix because the lack of robustness only applies to master/1.7. btw: Have you pushed bill's tile fix to master yet? -- Frederick |
From: Bill R. <ro...@gm...> - 2012-02-08 16:56:47
|
On 2012-02-09, at 0:48 , Frederick Weld wrote: > Bill: > Thanks for the additional information. > It appears that, on your local machine, JSpinner gets a null border by > default (whereas it gets a non-null border on other machines) - very > weird. > Master should now be able to cope with that. Frederick: Thanks for the fix, master now works as expected on my machine. Bill |
From: Stefan F. <ste...@we...> - 2012-02-09 08:44:48
|
Frederick: thanks I thought that the 1.6.x branch was effected too. At some point in time we should consider which of the many UI changes you did (and most of them I like) should be made the default option. Otherwise they will be lost for most players as no one will actually turn them on. This also implies that they do not get really tested. Additionally this again highlights the problem that there is no automatic testing of the UI part of Rails. Have you thought about automatically UI testing, this would really be helpful for changing the UI and even more important to check if the UI and game engine still cooperate as they should. Stefan PS: Have not pushed the tile fix yet to master, will do so soon. On 02/08/2012 05:48 PM, Frederick Weld wrote: > Bill: > Thanks for the additional information. > It appears that, on your local machine, JSpinner gets a null border by > default (whereas it gets a non-null border on other machines) - very > weird. > Master should now be able to cope with that. > > Stefan: > No need for a hotfix because the lack of robustness only applies to master/1.7. > btw: Have you pushed bill's tile fix to master yet? > > -- Frederick > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Frederick W. <fre...@go...> - 2012-02-09 10:22:11
|
Stefan: > At some point in time we should consider which of the many UI > changes you did (and most of them I like) should be made the default > option. I leave this to the rails-devel community or the release manager since my judgement would be too subjective. (I use all of the new options...) Putting new functionality to off by default is my standard way of adding features to rails that I would like but others potentially would not. > Have you thought about automatically UI testing I would advocate against building UI units (as regression tests) right now because - units would have to be adjusted too frequently (UIs are currently altered far more frequently than the game engine) - the number of regressions has been very low - additional technology is required to do UI units right - UI units wouldn't have helped with javac/jvm issues as those reported in this thread What is true is that the increasing level of UI variability (added options) hurts our ability to achieve sufficient code coverage by manual testing. But this would be alleviated if aforementioned point (about including new UI options as default) is agreed upon. -- Frederick |
From: Stefan F. <ste...@we...> - 2012-02-09 13:15:14
|
> > I would advocate against building UI units (as regression tests) right > now because > - units would have to be adjusted too frequently (UIs are currently > altered far more frequently than the game engine) > - the number of regressions has been very low > - additional technology is required to do UI units right > - UI units wouldn't have helped with javac/jvm issues as those > reported in this thread > Frederick: one could argue about the ratios between regressions and frequency of changes in the UI and you are right that the recent bug would not have been catched, however that was not the reason for me to bring up the topic: The GUI is not yet covered by any test, so it has marginal gain is largest here to add tests there. And for each release I do some manual testing (e.g. if Rails still starts and allows to finish an auction and load a game). This is the only manual task in the release process and I would be glad to automate that as well. Have you any experience in the choice of a Java/Swing ui framework? I have only limited experience with Mercury testing (from my professional past), but there should be much more focused/integrated open source tools. Maybe Brett has some recommendations too? What I have seen recently was Cucumber's approach, but most likely that is an overkill, but I am curious about it, especially as it seems to be (in all respects) language-agnostic. Stefan |
From: Frederick W. <fre...@go...> - 2012-02-09 17:15:37
|
Stefan: Perhaps you are able to create a UI test automate when letting one of these tools record the steps of your manual release tests? For my part, I don't have any knowledge of UI test automates for Java. But from my professional experience, I would advise to only build UI automates once the right (eg., layout agnostic) technology is available _and_ the tradeoff between finding regressions and the effort (creating and, especially, maintaining/adjusting the automates) is right. -- Frederick |
From: Frederick W. <fre...@go...> - 2012-02-09 17:34:12
|
Stefan: As an additional thought, we could change the release procedure such that major/minor releases (eg. 1.7.0) are tagged as beta at first. By doing so, we could close the gap between our current alpha testing and the release consumption by the end-users. I think we would have enough users that would be willing to use a beta release / report bugs but who fall short of setting up / maintaining a local git clone. What's your take on this? -- Frederick |
From: Stefan F. <ste...@we...> - 2012-02-10 12:04:43
|
Frederick: the current release cycle makes the x.x.0 a kind of beta release already as this is the moment where program changes get exposed to the users. I do not like tagging (open source) releases as beta, as either they are releases or not. Open source/GPL software is run on your own risk anyway. But I have an idea that might work in that direction: Sourceforge allows to tag the "latest version" manually and this is the offered default download. For a x.x.0 release this tag would not be applied and thus only users actively looking for the x.x.0 release would get that. Are there any objections to this procedure? Stefan On 02/09/2012 06:34 PM, Frederick Weld wrote: > Stefan: > As an additional thought, we could change the release procedure such > that major/minor releases (eg. 1.7.0) are tagged as beta at first. By > doing so, we could close the gap between our current alpha testing and > the release consumption by the end-users. I think we would have enough > users that would be willing to use a beta release / report bugs but > who fall short of setting up / maintaining a local git clone. > > What's your take on this? > > -- Frederick > > ------------------------------------------------------------------------------ > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Rails-devel mailing list > Rai...@li... > https://lists.sourceforge.net/lists/listinfo/rails-devel |
From: Frederick W. <fre...@go...> - 2012-02-10 15:17:29
|
Stefan: Sounds good. Then, the rails newbies will probably get the x.x.>0 release and the rails-devel/announce followers the x.x.0 releases. --Frederick. |