Model railroad software
For more information, see JMRI.org
For development information, see Technical Info
User discussions are on the JMRI users Groups.io group
JMRI model railroad digital command & control software
Home Page: https://www.jmri.org
License: Other
Model railroad software
For more information, see JMRI.org
For development information, see Technical Info
User discussions are on the JMRI users Groups.io group
Paragon 2 and most of Paragon 3 definitions missing in index of 4.2.1, recreating index fixes issue.
4.3.1 appears okay.
Suggest adding comments to the releases notes about missing definitions and the easy fix.
Peter
The Travis-CI tests occasionally fail with:
Testcase: testSearchOrder(jmri.implementation.DefaultSignalAppearanceMapTest): Caused an ERROR
[junit] Signal definition not found: JUnitTestSignals
[junit] java.lang.IllegalArgumentException: Signal definition not found: JUnitTestSignals
[junit] at jmri.implementation.AbstractSignalMast.configureSignalSystemDefinition(AbstractSignalMast.java:129)
[junit] at jmri.implementation.SignalHeadSignalMast.configureFromName(SignalHeadSignalMast.java:75)
[junit] at jmri.implementation.SignalHeadSignalMast.(SignalHeadSignalMast.java:55)
[junit] at jmri.managers.DefaultSignalMastManager.provideSignalMast(DefaultSignalMastManager.java:74)
[junit] at jmri.implementation.DefaultSignalAppearanceMapTest.testSearchOrder(DefaultSignalAppearanceMapTest.java:35)
[junit]
[junit]
[junit] Test jmri.HeadLessTest FAILED
Currently, the installer for MS Windows performs a merge operation with any existing JMRI installation.
Whilst this gives slight advantages with respect to speed of installation, it does mean that we need to remember to include explicit deletions of any files that are no longer necessary.
An example of this would be with the effect of PR #358 that, unless we change behaviour, will require that we add explicit deletions of the superseded library files.
There are a number of approaches that could be taken:
lib
treeInstallJMRI.nsi
file when encountedThoughts?
See initial discussion in #422
AbstractMRTrafficController uses invokeAndWait instead of InvokeLater to put events into the system via the Swing event queue.
Easy to change, but what are its consequences?
The children of AbstractMRTrafficController are:
and some of those have connection-specific subclasses within their package (c.g. the powerline package). Many of them get lot of use (C/MRI, NCE, Lenz) but others have just a couple of users (maple, SECSI) and very little developer support.
#422 made the synchronization a run-time variable (which someday might be a sub-classed method). Should we roll it out to more systems, and if so, how?
Some tests that used to run standalone (e.g. by using runtest.csh to invoke the main() in the test class) no longer do. A typical traceback is below. Is there some initialization step that's needed to prevent this error?
The test does pass when run via e.g. alltest, which makes me think that some global initialization is happening earlier. But I haven't been able to track it down.
Thanks
junit.framework.AssertionFailedError: Exception in constructor: testShow (java.util.ServiceConfigurationError: jmri.spi.PreferencesProvider: Provider apps.StartupActionsManager not a subtype
at java.util.ServiceLoader.fail(ServiceLoader.java:239)
...
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at jmri.implementation.JmriConfigurationManager.<init>(JmriConfigurationManager.java:40)
at jmri.configurexml.LoadStoreBaseAction.<init>(LoadStoreBaseAction.java:33)
...
at jmri.jmrit.display.panelEditor.PanelEditor.<init>(PanelEditor.java:120)
at jmri.jmrit.display.LinkingLabelTest.<init>(LinkingLabelTest.java:20)
I want to tighten up the XML Schema for the decoder definition. Specifically, I want to make sure that constructs like this (simplified):
<variable>
<decVal/>
<splitVal/>
</variable>
donโt validate. They donโt work, in any meaningful sense, and worse they fail silently. So Iโd like them to fail vocally in the validation step.
Right now, the modifiers like โlabelโ and โqualifierโ can appear before or after the variable type:
<variable>
<label/>
<decVal/>
<label/>
</variable>
<variable>
<decVal/>
<label/>
</variable>
<variable>
<label/>
<decVal/>
</variable>
all validate and work assuming that the labels are different, e.g. different languages. The schema can check for โcanโt have multiple labels in the same languageโ (which doesnโt work, and a quick check found a couple) if theyโre always before or always after. It canโt check (and doesnโt now) if they can be in either place.
For a long time, labels had to be after, and most of them are. (The change to allow them before was inadvertent). Iโm planning to restore that constraint, so that label, comment and tooltip have to be after the variable type. Iโll fix any existing files that donโt validate with that, and commit them all together. Then Iโll (slowly) work through solutions to duplicate labels, and eventually commit those along with a constraint on that too.
But thatโs not why Iโm writing. Iโm writing because Iโd like to also constrain qualifiers to be either before or after the variable type. I need to do that to restore the โjust one variable type elementโ constraint due to a part of the schema vocabulary called the โUnique Particle Attribution Constraintโ, but we donโt have to go into detail on that.
What matters is choosing either โbeforeโ or โafterโ.
There are a few files that have the qualifier before. I like the way that looks, because first you see the conditions where the variable exists, then you see itโs type, and the details follow. That seems easiest to read.
But there are more files with the qualifier after the variable type. That might be historical, but it looks a bit harder to read, at least to me.
Does anybody have a strong preference on this? Iโm happy to edit and commit all that files that donโt validate either way, itโs probably only an hour of editing to do that (if there are too many, I might just do a XSLT macro to fix it)
Thanks for your thoughts.
Bob
As most decoders now work in Direct Bit mode, and all modern sound decoders do so, please can the default mode out-of-the-box be changed to Direct Bit.
Ideally, there will be a user defined Preference, (or the users selected value be saved, for instance by saving Window, or some such,) but keeping the default to the antique Paged mode is no longer useful for most users.
In a new Profile, creating an NCE simulator connection using the initial configuration wizard in DecoderPro (HEAD from master) throws a NullPointerException that blocks further activity. Creating an NCE simulator connection in the Preferences window does not throw a NullPointerException. Subsequent launches do not cause the Preferences window to open (#229).
Creating a LocoNet simulator connection in either the wizard or the Preferences window does not have this effect.
Font size is saved correctly, but doesn't take effect on restart.
I encounter a number of problems migrating any existing profile from V4.1.3 or earlier to a build showing V4.1.3ish-Rd2d3fee.
I created a test profile under 4.1.3 that was unremarkable except for the following:
After migration and restart, i have the following:
Using Preferences to correct:
It would be beneficial to users to be able to have profiles store per-node (or per-computer) configurations, so the entire profile can be stored in DropBox, on a thumb drive, or shared across computers in some other fashion without having to reconfigure the profile on almost every use.
Working on this is at https://github.com/rhwood/JMRI/tree/multi-node-profiles
When I enable hardware flow control with DCC++ it breaks in master branch. After receiving the initial message from the Arduino it hangs. Here is a snip from the log
2015-12-29 15:12:30,585 dccpp.DCCppReply DEBUG - DCCppReply.toString(): char i i msg iDCC++ BASE STATION FOR ARDUINO MEGA / ARDUINO MOTOR SHIELD: BUILD Dec 25 2015 12:40:17 [Receive]
2015-12-29 15:12:30,585 jmrix.AbstractMRTrafficController DEBUG - dispatch reply of length 87 contains iDCC++ BASE STATION FOR ARDUINO MEGA / ARDUINO MOTOR SHIELD: BUILD Dec 25 2015 12:40:17 state 25 [Receive]
2015-12-29 15:12:50,139 dccpp.DCCppSerialPortController DEBUG - CTS: false [Transmit]
2015-12-29 15:12:50,139 dccpp.DCCppPacketizer DEBUG - DCC++ port not ready to receive [Transmit]
2015-12-29 15:12:50,139 jmrix.AbstractMRTrafficController DEBUG - Retry message: s attempts remaining: 5 [Transmit]
In dccpp.DCCppSerialPortController
public boolean okToSend
With flow control enabled it returns activeSerialPort.isCTS() which always stays at false.
With flow control disabled things work.
In Realease-4.2 even with flow control enabled. activeSerialPort.getFlowControlMode() is false. so it never returns activeSerialPort.isCTS().
I looked at the code on the Arduino and I couldn't see any mention of hardware flow control, so perhaps its off by default or simply not supported?
Martin Jahner opened a bug report on the SF.net bug tracker that says:
I've encountered an issue in the way JMRI throttles update the slots in a Digitrax command station. If two throttles are selected to control the same engine/slot, and one of them releases the address, both throttles suddenly lose control and the slot is set back to "Common". The fact that one throttle can affect the other is already a bit of a concern, but the more important problem is this: Once this has happened, no JMRI throttle is able to take control of that slot anymore. Selecting the same address again on either throttle (or a new one) will not set the slot back to "In Use". This also affects WiFi throttles. Only Digitrax throttles on LocoNet are not affected, and they will be able to set the slot back to "In Use".
The attached log file shows a brief test session where I am selecting the same engine on two separate throttles first separately, then together, and then release them to cause the issue. I put comments with "INFO" into the log to describe what I did and what happened.
I hope this is enough information for someone with knowledge of the internals to debug and monitorLog_DETAIL.txt hopefully fix this. I'll be happy to provide more information and/or test things if needed.
I'm pulling this over to GitHub partly to see how these issues work for JMRI bug tracking, and partly to get it a bit more attention.
We are currently uploading failed tests in the after_test
phase, but after_test
is not run if any tests fail.
Start this issue for any communications related to 4.1.7.
Note: 4.1.7 is based upon the 4.1.6 branch and NOT master.
Only explicit commits will be brought in by request
Prior to adding the "quiet" macro, the ci-tests could be run in NetBeans (and provide output integrated into NetBeans). Now I get this error:
ant -f /Users/rhwood/Developer/JMRI/JMRI/JMRI ci-test
init:
/Users/rhwood/Developer/JMRI/JMRI/JMRI/build.xml:277: The following error occurred while executing this line:
/Users/rhwood/Developer/JMRI/JMRI/JMRI/build.xml:220:
javax.script.ScriptException: TypeError: org.apache.tools.ant.module.bridge.impl.NbBuildLogger@6cfdb295 has no such function "setMessageOutputLevel" in <eval> at line number 2
at jdk.nashorn.api.scripting.NashornScriptEngine.throwAsScriptException(NashornScriptEngine.java:455)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:439)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:401)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:397)
at jdk.nashorn.api.scripting.NashornScriptEngine.eval(NashornScriptEngine.java:152)
at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108)
at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81)
at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103)
at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67)
at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor315.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor315.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:396)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:292)
at sun.reflect.GeneratedMethodAccessor315.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:435)
at org.apache.tools.ant.Target.performTasks(Target.java:456)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1393)
at org.apache.tools.ant.Project.executeTarget(Project.java:1364)
at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1248)
at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:286)
at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:555)
at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:153)
Caused by: <eval>:2 TypeError: org.apache.tools.ant.module.bridge.impl.NbBuildLogger@6cfdb295 has no such function "setMessageOutputLevel"
at jdk.nashorn.internal.runtime.ECMAErrors.error(ECMAErrors.java:57)
at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:213)
at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:185)
at jdk.nashorn.internal.runtime.ECMAErrors.typeError(ECMAErrors.java:172)
at jdk.nashorn.internal.runtime.linker.NashornBottomLinker.linkBean(NashornBottomLinker.java:103)
at jdk.nashorn.internal.runtime.linker.NashornBottomLinker.getGuardedInvocation(NashornBottomLinker.java:71)
at jdk.internal.dynalink.support.CompositeGuardingDynamicLinker.getGuardedInvocation(CompositeGuardingDynamicLinker.java:124)
at jdk.internal.dynalink.support.LinkerServicesImpl.getGuardedInvocation(LinkerServicesImpl.java:149)
at jdk.internal.dynalink.DynamicLinker.relink(DynamicLinker.java:233)
at jdk.nashorn.internal.scripts.Script$\^eval\_.:program(<eval>:2)
at jdk.nashorn.internal.runtime.ScriptFunctionData.invoke(ScriptFunctionData.java:636)
at jdk.nashorn.internal.runtime.ScriptFunction.invoke(ScriptFunction.java:229)
at jdk.nashorn.internal.runtime.ScriptRuntime.apply(ScriptRuntime.java:387)
at jdk.nashorn.api.scripting.NashornScriptEngine.evalImpl(NashornScriptEngine.java:437)
... 42 more
BUILD FAILED (total time: 1 second)
Place to discuss need for and content of a possible JMRI 4.2.1 updated-production release.
A nonexistent Profile catalog generates an error and stack trace, but this should be allowed, since it can be an expected situation on a new JMRI installation.
The interesting part of a stack trace from Travis-CI:
[junit] ERROR - /home/travis/.jmri/profiles.xml (No such file or directory) [main] jmri.profile.ProfileManager.?()
[junit] java.io.FileNotFoundException: /home/travis/.jmri/profiles.xml (No such file or directory)
[junit] at java.io.FileOutputStream.open(Native Method)
[junit] at java.io.FileOutputStream.<init>(FileOutputStream.java:213)
[junit] at java.io.FileOutputStream.<init>(FileOutputStream.java:162)
[junit] at java.io.FileWriter.<init>(FileWriter.java:90)
[junit] at jmri.profile.ProfileManager.writeProfiles(ProfileManager.java:475)
[junit] at jmri.profile.ProfileManager.readProfiles(ProfileManager.java:411)
...
If I change the connection from NCE simulator to serial or any other connection and press "Save" it causes an NPE. Afterwards I'm not able to restore the connection back to simulator, as that also causes an NPE. So I'm not able to close the preferences window.
Here's the trace:
2015-11-21 09:55:34,793 jmrix.AbstractSerialPortController ERROR - No usable ports returned [AWT-EventQueue-0]
2015-11-21 09:55:34,793 ptionhandler.UncaughtExceptionHandler ERROR - Unhandled Exception: java.lang.NullPointerException [AWT-EventQueue-0]
java.lang.NullPointerException
at jmri.jmrix.configurexml.AbstractConnectionConfigXml.storeCommon(AbstractConnectionConfigXml.java:37)
at jmri.jmrix.configurexml.AbstractSerialConnectionConfigXml.store(AbstractSerialConnectionConfigXml.java:44)
at jmri.jmrix.configurexml.AbstractConnectionConfigXml.store(AbstractConnectionConfigXml.java:33)
at jmri.configurexml.ConfigXmlManager.elementFromObject(ConfigXmlManager.java:515)
at jmri.jmrix.ConnectionConfigManager.savePreferences(ConnectionConfigManager.java:101)
at jmri.jmrix.ConnectionConfigManager.savePreferences(ConnectionConfigManager.java:90)
at jmri.jmrix.swing.ConnectionsPreferencesPanel.savePreferences(ConnectionsPreferencesPanel.java:283)
at apps.gui3.TabbedPreferences.invokeSaveOptions(TabbedPreferences.java:230)
at apps.gui3.TabbedPreferences.lambda$0(TabbedPreferences.java:147)
at apps.gui3.TabbedPreferences$$Lambda$29/1092348790.actionPerformed(Unknown Source)
at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2022)
at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2346)
at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252)
at java.awt.Component.processMouseEvent(Component.java:6525)
at javax.swing.JComponent.processMouseEvent(JComponent.java:3321)
at java.awt.Component.processEvent(Component.java:6290)
at java.awt.Container.processEvent(Container.java:2234)
at java.awt.Component.dispatchEventImpl(Component.java:4881)
at java.awt.Container.dispatchEventImpl(Container.java:2292)
at java.awt.Component.dispatchEvent(Component.java:4703)
at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4898)
at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4533)
at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4462)
at java.awt.Container.dispatchEventImpl(Container.java:2278)
at java.awt.Window.dispatchEventImpl(Window.java:2739)
at java.awt.Component.dispatchEvent(Component.java:4703)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:746)
at java.awt.EventQueue.access$400(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:697)
at java.awt.EventQueue$3.run(EventQueue.java:691)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.awt.EventQueue$4.run(EventQueue.java:719)
at java.awt.EventQueue$4.run(EventQueue.java:717)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:716)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
Starting process.
This is a try at adding an issue. I don't have write access to JMRI/JMRI, it have s clone.
I can edit this. But can't find a way to add a label.
The first time a Profile is used in DecoderPro, after the First Time Wizard is used to configure the first connection, that connection panel is empty, but present, in the Preferences window until after DecoderPro is restarted.
From the 02f2236 commit message:
Note that these changes do not stop the preferences window from displaying an empty pane for the first connection until after JMRI is restarted. I suspect we need a repaint or similar call when the
TabbedPreferences window is opened to fix that.
This is confirmed to be present in 3.8 (that's as far back as I tested).
Deleting a configuration profile can be a time-consuming task, so the cursor needs to change to a wait cursor while the profile is being deleting.
Does anybody know where the "collaborator" tags come from?
For example, in #29, I see:
but others don't have that "collaborator" tag visible. What property of somebody's account drives that?
Recently introduced bug.
UNIX (Linux and OS X) systems exhibit the following errors when listing serial adaptors:
Tests on AppVeyor need to be run differently than the tests for Travis CI.
While Travis CI has no mechanism for explicitly displaying tests outside its log, AppVeyor does, and so AppVeyor needs a different ant task for testing than Travis CI.
For any communications related to 4.3.1.
Start this issue for any communications related to 4.1.6.
Note: 4.1.6 is based upon the 4.1.5 branch and NOT master.
Only explicit commits will be brought in by request
I have run into a snag while trying to develop a WebSockets-based JMRI app. Here is an explanation of what causes it:
This could be due to an issue in my own code, but I'm not sure. The only thing I'm not sure about is "letting go" of the throttle. On disconnecting, is there a certain JSON command I have to send to "drop" my throttle(s), or should JMRI just do that automatically?
Interestingly, following the exact same procedure with the exact same roster entry, I am unable to reproduce the bug in JMRI 3.10.1.
See discussion by @devel-bobm in pull request #66 for some key background.
We set up file-level attributes in SVN to use local line-ends, keeping Linux/Mac line-ends in the repository. (I think we did this file-by-file mostly for historical reasons) The SVN command was
svn propset svn:eol-style native <file-path-name>
We probably need to do something about line ends for Git.
GitHub's help as a page on dealing with line endings: https://help.github.com/articles/dealing-with-line-endings/
It shows how to issue a command on each user machine to "properly handle line endings" (That references Mac OS X on my Mac OS X machine; could somebody on Windows please check what it says on a Windows-resident browser?)
There is a per-repository setting, but the process to set it up is a bit fierce.
How do we want to handle this?
Bob
Currently, the release notes are in the releasenotes/ directory in the website repo.
I'd like to move those to the help/ directory in the main JMRI/JMRI code repository so that it's easier to include release note updates along with the code in a pull request.
There are lots of links to the old location already on the web, so I'll convert the existing files to redirects.
I'd like to do this during the next test release.
The following tests are causing #213 to fail:
The logs are:
[junit] Testcase: testOptionFrameWrite(jmri.jmrit.operations.setup.OperationsSetupGuiTest): FAILED
[junit] rfid
[junit] junit.framework.AssertionFailedError: rfid
[junit] at jmri.jmrit.operations.setup.OperationsSetupGuiTest.testOptionFrameWrite(OperationsSetupGuiTest.java:157)
[junit] at junit.extensions.jfcunit.JFCTestCase$5.run(JFCTestCase.java:580)
[junit] at junit.extensions.jfcunit.JFCTestCase$3.run(JFCTestCase.java:478)
[junit] at java.lang.Thread.run(Thread.java:745)
[junit]
[junit]
[junit] Testcase: testCarsTableFrame(jmri.jmrit.operations.rollingstock.cars.CarsTableFrameTest): FAILED
[junit] 1st car in sort by rfid list expected:<NH 5> but was:<SP 2>
[junit] junit.framework.AssertionFailedError: 1st car in sort by rfid list expected:<NH 5> but was:<SP 2>
[junit] at jmri.jmrit.operations.rollingstock.cars.CarsTableFrameTest.testCarsTableFrame(CarsTableFrameTest.java:182)
[junit] at junit.extensions.jfcunit.JFCTestCase$5.run(JFCTestCase.java:580)
[junit] at junit.extensions.jfcunit.JFCTestCase$3.run(JFCTestCase.java:478)
[junit] at java.lang.Thread.run(Thread.java:745)
[junit]
[junit]
[junit] Testcase: testTrainSwitchListEditFrame(jmri.jmrit.operations.trains.OperationsTrainsGuiTest): FAILED
[junit] Real Time
[junit] junit.framework.AssertionFailedError: Real Time
[junit] at jmri.jmrit.operations.trains.OperationsTrainsGuiTest.testTrainSwitchListEditFrame(OperationsTrainsGuiTest.java:583)
[junit] at junit.extensions.jfcunit.JFCTestCase$5.run(JFCTestCase.java:580)
[junit] at junit.extensions.jfcunit.JFCTestCase$3.run(JFCTestCase.java:478)
[junit] at java.lang.Thread.run(Thread.java:745)
[junit]
[junit]
[junit] Testcase: testCreateHorizontalNone(jmri.jmrit.progsupport.ProgServiceModePaneTest): Caused an ERROR
[junit] null
[junit] java.lang.NullPointerException
[junit] at jmri.jmrit.progsupport.ProgServiceModePane.<init>(ProgServiceModePane.java:102)
[junit] at jmri.jmrit.progsupport.ProgServiceModePane.<init>(ProgServiceModePane.java:83)
[junit] at jmri.jmrit.progsupport.ProgServiceModePaneTest.testCreateHorizontalNone(ProgServiceModePaneTest.java:27)
[junit]
[junit]
[junit] Testcase: testCreateVerticalNone(jmri.jmrit.progsupport.ProgServiceModePaneTest): Caused an ERROR
[junit] null
[junit] java.lang.NullPointerException
[junit] at jmri.jmrit.progsupport.ProgServiceModePane.<init>(ProgServiceModePane.java:102)
[junit] at jmri.jmrit.progsupport.ProgServiceModePaneTest.testCreateVerticalNone(ProgServiceModePaneTest.java:51)
[junit]
[junit]
[junit] Test apps.tests.AllTest FAILED
The run up to JMRI 4.2 has found another problem with panel icon graphics. (See #316 for more info)
This particular problem is that SensorIcons don't display animated gifs properly. The attached SensorIconTest.xml.txt file demonstrates the problem. The lower icon flashes in JMRI 4.1.3 and doesn't in the candidate 4.2 build.
There's work in #316 about what to do for the immediate issue, which is deciding what code to include in JMRI 4.2. Please discuss that over there, not here.
This issue is to create a set of test cases that we can define and implement, and then start to refactor the jmrit.display code into a maintainable state. Please add things that I've not thought of. I'm going to do some test coding (for the 4.3 series) over the holiday break.
Please add a comment if I've missed anything.
Bob
Having trouble with the Git support in NetBeans 8.0.2.
JMRI GitHub users should be set up like:
% git remote -v
origin https://github.com/JMRI/JMRI (fetch)
origin https://github.com/bobjacobsen/JMRI (push)
with split fetch/pull and push. This appears in the git .config (which NetBeans shows as config) as
[branch "master"]
[remote "origin"]
url = https://github.com/JMRI/JMRI
fetch = +refs/heads/*:refs/remotes/origin/*
pushurl = https://github.com/username/JMRI
NetBeans seems to only store the "url" term, It also seems to insist on putting the user name in (though I don't know if that's a problem specifically), and in the process rewrites the .config:
[branch "master"]
[remote "origin"]
url = https://[email protected]/bobjacobsen/JMRI
url = https://[email protected]/JMRI/JMRI
pushurl = https://github.com/bobjacobsen/JMRI
fetch = +refs/heads/*:refs/remotes/origin/*
The work-around is to always use the full "Pull..." or "Push..." and fill out the form, but that's a pain.
(See #67 and #66 for some earlier context)
We might still have a problem with line-ends in the repository.
For an example, see:
https://github.com/JMRI/JMRI/blame/master/java/src/jmri/jmrix/rfid/serialdriver/SerialDriverAdapter.java
We've lost easy access to the history for that file because a line-end mismatch makes Git think that the entire file was replaced. But note the date on the commit: Sept 9. That's slightly before we moved to GitHub.
Another example
https://github.com/JMRI/JMRI/blame/master/java/src/jmri/jmrix/loconet/LnTurnout.java
Here, it's not obvious that the whole file is replaced, so one might not suspect that a lot of history has been lost. You'd be misled by the history you're looking at. But again the date is before the move.
Do we have a problem now? Or is this just an artifact of the conversion process?
Here's the list of files that currently have CRLF line ends (I've removed a few that just got committed that way, see commit #425):
modified: java/src/jmri/jmrit/display/controlPanelEditor/shape/LocoLabel.java
modified: java/src/jmri/jmrit/display/controlPanelEditor/shape/configurexml/LocoLabelXml.java
modified: java/src/jmri/jmrix/can/cbus/CbusConfigurationManager.java
modified: java/src/jmri/jmrix/can/cbus/CbusReporter.java
modified: java/src/jmri/jmrix/can/cbus/CbusReporterManager.java
modified: java/src/jmri/jmrix/can/cbus/configurexml/CbusReporterManagerXml.java
modified: java/src/jmri/jmrix/loconet/Intellibox/IBLnPacketizer.java
modified: java/src/jmri/jmrix/loconet/LnPacketizer.java
modified: java/src/jmri/jmrix/loconet/LnTurnout.java
modified: java/src/jmri/jmrix/loconet/LnTurnoutManager.java
modified: java/src/jmri/jmrix/loconet/lnsvf2/LnSv2MessageContents.java
modified: java/src/jmri/jmrix/loconet/uhlenbrock/UhlenbrockPacketizer.java
modified: java/src/jmri/jmrix/loconet/uhlenbrock/UhlenbrockSystemConnectionMemo.java
modified: java/src/jmri/jmrix/rfid/protocol/em18/COPYING
modified: java/src/jmri/jmrix/rfid/protocol/em18/Em18RfidProtocol.java
modified: java/src/jmri/jmrix/rfid/protocol/em18/package.html
modified: java/src/jmri/jmrix/rfid/serialdriver/SerialDriverAdapter.java
I'm unhappy that the "blame" history in those jmrix/loconet files have been lost, and really don't want to lose any more. If this is just an unfortunate artifact of the SVN-to-Git conversion process, then I guess it is what it is. But I really don't want any more of this to be happening.
Should I recommit those files with LF ends? Or is there some other way forward?
Bob
I am trying to get a railroad crossing working on my layout, and I'd like to use Arduino to do it so the occupancy detection system will function within JMRI. I know about the Arduino CMRI library, but it only works with certain Arduino models with an FTDI chip due to some incompatibility in JMRI.
I tried to set up the connection type "Others" today, but it was very buggy and crashed pretty frequently. How should I go about setting this up? Could JMRI maybe make a guide to do this?
Starting process
For some (possibly incorrect) background, see: http://jmri.org/help/en/html/doc/Technical/GitFAQ.shtml#CVSCookies (Sorry, don't know how to get it to automatically open at the item)
This Issue comes from the discussion in pull #29 where Paul Bender @pabender said:
I'm not ready to say the SVN keywords should be deprecated yet.
It looks like we can get them to work using got attributes.
https://git-scm.com/book/en/v2/Customizing-Git-Git-Attributes
I need to look at that page more closely later to get the proper keyword expansions.
Other than the ID keyword, the one we use most frequently is revision....
and Randall @rhwood replied:
Note that per the documentation:
- keyword expansions in git are not included in the commits, so it's retained only locally in the working copy
- it can get ugly if you require certain applications (i.e. bash) to expand keywords, and not everyone is capable of using those applications.
My feeling on this is that there are certain files, esp. decoder files, that people will pass around outside Git (as they did with SVN). When they finally come back to us with useful and valuable changes, having a reliable internal version identification can be very helpful. But an unreliable one is worse than none at all. So I think we should not use them unless we can be sure that they work reliably when un-sophisticated (e.g. non-programmer) users pick them up any of the possible sources: A JMRI distribution, our website, Git or GitHub, or anywhere else they usually do this.
I don't know how to achieve that with the existing tags and Git.
It might be possible to pull the existing tags and replace them with something new. I'm certainly open to that. Would be easy to e.g. insert something in every XML file as a one time operation.
Place for discussion around the creation of test release 4.3.2
(This has been discussed in jmri-developers, but I wanted to make sure the files were available here)
With the current HEAD of JMRI/JMRI master, certain old profiles convert to new ones that have the roster directory reference pointing to the jython (!) subdirectory of the program directory.
Here's a .zip version of the profile before conversion and a .zip version of the results of the conversion. The easiest way to check is to set the "before" in place, run the program, let it convert (it gives a message about that), and check the locations via the Help menu.
I am developing a software to simulate realistic acceleration/deceleration and controls for models, similar to what Bruce Kingsley has done with his "Ultimate Throttle" project. I'm building this based around JMRI's WebSockets server, which has worked excellent so far.
Obviously to simulate scale speed correctly, information that is specific to a particular model is needed. There are also a few other things that it would be very nice to store in the JMRI roster.
I am wondering if there is a way to create a custom roster entry via WebSockets. Can someone shed some light on this? It does not seem to be documented on the WebSockets page on the JMRI.org site.
The AppVeyor CI tests are failing, and it's not our fault.
It loads and installs ant and the Java SDK on each run. Sometime yesterday, that process updated from Java 1.8 65 to 66, which is not currently working.
Don't worry about AppVeyor CI test fails until further notice.
See https://github.com/JMRI/JMRI/blob/master/scripts/HOWTO-distribution.md for the current proposal.
First pass at release note for 4.2 has been submitted.
Please review this (it's just a concatenation of pretty much everything from the 4.1.x series).
Thanks.
We should upgrade to Jetty 9.3.x. It is the current stable and recommended release of Jetty and includes both performance and security-related fixes.
The last couple of Travis tests have failed. There's a typical log section below.
This is happening even when rerunning a previously-passed test, so I don't think it's in our code.
Each of the failures have been in a "Test schema valid" step. Because it's only showing 1 test run, it appears that the failure is during the pass through the tests to decide which will be run and which will not, because the tests themselves. But it's a little mysterious why it's failing in different places. Could this be a new timeout in Travis?
ci-test:
[junit] Running apps.tests.AllTest
[junit] Testsuite: apps.tests.AllTest
[junit] Testsuite: apps.tests.AllTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit]
[junit] Testcase: apps.tests.AllTest:Test schema valid: xml/signals/BNSF-1996/appearance-SE-2S.xml: Caused an ERROR
[junit] Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.
[junit] junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please note the time in the report does not reflect the time until the VM exit.
[junit]
[junit]
[junit] Running apps.tests.AllTest
[junit] Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0 sec
[junit] Test apps.tests.AllTest FAILED (crashed)
BUILD FAILED
/home/travis/build/JMRI/JMRI/build.xml:1020: condition satisfied
Total time: 3 minutes 19 seconds
/home/travis/build.sh: line 112: 1956 Terminated travis_jigger $! $timeout $cmd
This is a test of access to the GitHub Issue system. It is only a test.
Whhhhheeeeeeeeeeeeeee
We now return you to your normally scheduled issues.
Seriously, the idea of this is to start an issue, and see whether people with regular GitHub accounts can:
Could somebody without Git write access please try these? Thanks.
Here is some text.
It says I can attach files. Markdown is permitted.
No options for labeling is evident.
Adding a text file.
ANothingFile.txt
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.