Date   

dispose on JComponents

Svata Dedic
 

Hi,

a newbie question: where exactly dispose() is supposed to be called ?
I understand that dispose() was meant to do a cleanup, and understand the function in a top-down hierarchies.

But JComponent has its removeNotify() called when it gets off the parent; so is there are a part of JComponent lifecycle, when the component was *already* removed, but can be activated again ?

Asking because the cascading of dispose() in DecoderPro duplicates the same cascade of removeNotify() and it be unnecessary to track 'components to dispose' if the same is already tracked by the component hierarchy itself.

Thanks,
-Svata


Re: Inline photos? (was Status colors vs icons in DecoderPro I (was: Re: GTK L&F and DecoderPro)

Ken Cameron
 

Yep, picture works. Seems like color coded status example.

But as we see with Randal's message, care is needed to make sure the graphic
sent retains useful resolution.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org


Re: Changes to code coverage?

Paul Bender
 

On Oct 5, 2019, at 11:59 AM, Randall Wood via Groups.Io <rhwood=mac.com@groups.io> wrote:
I can’t tell if this is a sign that using Code Climate for total coverage is a mistake (I suggested it, so it’s my mistake), or if this reveals some other possibly transient issue with our testing (is some state sometimes being retained between tests)?
This isn’t any different from what we see on coveralls.

We have cleaned up a lot of this, but some tests are still leaving threads behind, which is at least a part of the problem.

There are a couple of tests that have wide fluctuations ( 10s of lines ), but most of them are just a line or two.

As far as total coverage is concerned, we currently have coveralls set to fail on more than a 0.25% drop in coverage. Code climate is currently set to fail at a smaller coverage drop, so it will flag things coveralls does not. They should probably be set to the same value.

Paul


Re: Changes to code coverage?

Randall Wood <rhwood@...>
 

Sorry about the first attachment, I let my phone compress it too much.


Randall

On Oct 5, 2019, at 11:59, Randall Wood <rhwood@...> wrote:

PR https://github.com/JMRI/JMRI/pull/7475 makes no changes to any code (it updates a library), and yet Code Climate coverage shows these changes to coverage (screenshot if this works):
<image0.png>


I can’t tell if this is a sign that using Code Climate for total coverage is a mistake (I suggested it, so it’s my mistake), or if this reveals some other possibly transient issue with our testing (is some state sometimes being retained between tests)?

Randall


Changes to code coverage?

Randall Wood <rhwood@...>
 

PR https://github.com/JMRI/JMRI/pull/7475 makes no changes to any code (it updates a library), and yet Code Climate coverage shows these changes to coverage (screenshot if this works):


I can’t tell if this is a sign that using Code Climate for total coverage is a mistake (I suggested it, so it’s my mistake), or if this reveals some other possibly transient issue with our testing (is some state sometimes being retained between tests)?

Randall


Inline photos? (was Status colors vs icons in DecoderPro I (was: Re: GTK L&F and DecoderPro)

Bob Jacobsen
 

Let’s try it!


Bob

On Oct 5, 2019, at 6:32 AM, Peter Ulvestad <ulvestad@...> wrote:

Bob, 
From what I see, attachmenst are allowed in this group. The below is from the group guidelines.

Messages, Files and Photos

Messages in either plain text or HTML are permitted. Attachments are allowed also but, where appropriate, please upload any relevant files to the Files section.
Please sign messages with your name as it makes the group friendlier and much easier to follow messages. Nicknames or Handles are fine, just try to stay consistent.
Any pictures that you wish to share should be uploaded to the Photos section. Large photos will be resized to a maximum size of 2048x2048 pixels.
Archives of messages are publicly visible, but email addresses are hidden within the online archive.
Files and Photos are only visible to group members.
There are limits for the amount of Photos and Files that can be stored. As a result, old Photos and Files may be removed from the archive to keep within these limits.


On Fri, Oct  4, 2019 at 05:55 PM, Bob Jacobsen wrote:


1) Maybe it’s time to allow embedded graphics on the developers list? Spam
filtering has advanced a bit since 2003… If anybody wants to discuss that,
please start another thread.



-- 
Peter Ulvestad

JMRI Users Group Moderator - http://www.jmri.org ( http://www.jmri.org )
Tam Valley Group Moderator - https://tamvalleydepot.com/ ( http://tamvalleydepot.com/ )
Sprog-DCC Group Moderator - http://www.sprog-dcc.co.uk/ ( http://www.sprog-dcc.co.uk/ )
Edmonton Model Railroad Association - http://www.emra.club/




--
Bob Jacobsen
rgj1927@...




Re: Status colors vs icons in DecoderPro I (was: Re: GTK L&F and DecoderPro)

Peter Ulvestad
 

Bob,
From what I see, attachmenst are allowed in this group. The below is from the group guidelines.

Messages, Files and Photos

Messages in either plain text or HTML are permitted. Attachments are allowed also but, where appropriate, please upload any relevant files to the Files section.
Please sign messages with your name as it makes the group friendlier and much easier to follow messages. Nicknames or Handles are fine, just try to stay consistent.
Any pictures that you wish to share should be uploaded to the Photos section. Large photos will be resized to a maximum size of 2048x2048 pixels.
Archives of messages are publicly visible, but email addresses are hidden within the online archive.
Files and Photos are only visible to group members.
There are limits for the amount of Photos and Files that can be stored. As a result, old Photos and Files may be removed from the archive to keep within these limits.

On Fri, Oct 4, 2019 at 05:55 PM, Bob Jacobsen wrote:


1) Maybe it’s time to allow embedded graphics on the developers list? Spam
filtering has advanced a bit since 2003… If anybody wants to discuss that,
please start another thread.
--
Peter Ulvestad

JMRI Users Group Moderator - http://www.jmri.org ( http://www.jmri.org )
Tam Valley Group Moderator - https://tamvalleydepot.com/ ( http://tamvalleydepot.com/ )
Sprog-DCC Group Moderator - http://www.sprog-dcc.co.uk/ ( http://www.sprog-dcc.co.uk/ )
Edmonton Model Railroad Association - http://www.emra.club/


Re: Status colors vs icons in DecoderPro I

Svata Dedic
 

Hi,

Just a correction - from your response I feel I didn't express my thoughts well.

I was not going to suggest to *move away* from colors. Or to *abandon* high-saturation scheme. The rough idea was to allow for *additional* and *opt-int* behaviour - somehow combine in Randall's requirement. Do not expect the suggestions to be super-bright.

-S.

BTW thanks, please keep explaining since some points allowed me to recall almost forgotten things, and also industrial/railway context here is almost certainly different from yours. Some associations are good to keep.

Dne 05. 10. 19 v 1:55 Bob Jacobsen napsal(a):

2) JMRI is not a word processor. It’s more like a process control system. As such, certain user expectations (which mostly come from document-related UIs) make sense, and others don’t. Coloring to represent status of controls and values has a _long_ and well-understood history in process control. It predates computer screens (here’s where I’d embed a picture of a 60’s process panel, see item 1) but has lasted through them to even now (would embed another picture). I think a unified methodology for presenting the status underlying values is fine, having common code is great, but not being in some set of HI-specification docs is _not_ sufficient reason to move away from color as a way of indicating actionable status (and, yes, I’m am very color blind).


Re: Status colors vs icons in DecoderPro I (was: Re: GTK L&F and DecoderPro)

Bob Jacobsen
 

Working through all the great info in the email while on a phone, it’ll take a bit to compose a reply, but want to make two points:

1) Maybe it’s time to allow embedded graphics on the developers list? Spam filtering has advanced a bit since 2003… If anybody wants to discuss that, please start another thread.

2) JMRI is not a word processor. It’s more like a process control system. As such, certain user expectations (which mostly come from document-related UIs) make sense, and others don’t. Coloring to represent status of controls and values has a _long_ and well-understood history in process control. It predates computer screens (here’s where I’d embed a picture of a 60’s process panel, see item 1) but has lasted through them to even now (would embed another picture). I think a unified methodology for presenting the status underlying values is fine, having common code is great, but not being in some set of HI-specification docs is _not_ sufficient reason to move away from color as a way of indicating actionable status (and, yes, I’m am very color blind).

Bob

On Oct 4, 2019, at 4:25 PM, Svata Dedic <svatopluk.dedic@...> wrote:

Sorry for the delay with this continuation response. It took some time to sort out thoughts, and one needs also do some coding, not just dicussions. There's a lot to say on several story lines.
Let's start with some implementation observations.

BTW the reason I am so obsessed by validation, icons, colors etc isn't that I want to be a moron. I wanted to make an UI experiment with DecoderPro, and adding validation w/ feedback was on the list.

Dne 01. 10. 19 v 2:40 Randall Wood via Groups.Io napsal(a):
Its meant for any scenario where the state of something needs to be shown
[...]
I’m more suggesting the Border in that API be used for showing reading/writing/pending change states
I attempted to use Border in that API as suggested. I was already playing with some tweaks to the PaneProgPane's layout - just experiments. So I've at least aligned some controls, but I didn't space them according to JLF guidelines yet. So the 'standard' Basic panel looks like: https://www.dropbox.com/s/tsub76fit7697vx/controls-aligned.png?dl=0 (red line shows control alignment)

When 'status border' is applied, the tab comes up like this: https://www.dropbox.com/s/1a8t2odmyy4xyj1/startup.png?dl=0. Also alignment of the control's active area seems broken; see the red line. Only when hovering the mouse over combos, dropdown buttons are painted like: https://www.dropbox.com/s/7z539metrca0s2y/partial-combos.png?dl=0 . That's on the Metal L&F, which may be not a focus, but is the Java default. In GTK L&F, it's even worse as combo dropdowns do not appear at all.

There are other drawing issues with controls other than textfields: right margin gets misaligned, icon appears *within* textfield border, but *outside* of combo box leading line - at least on Metal L&F. I wonder how a JTree would look like.

While I absolutely agree that "just color backgrounds" are not complete solution, I (repeating myself, sorry) need to strongly disagree with preenting DecoderPro statuses as icons. Not only because the support is not ready yet, but because validity and CVval state are different concepts. Imagine two nested Borders around an edit box, providing two icons. The user would need to get used to differentiate between icon categories, yet next to each other.
In addition, I remember that our HIE/UEXes insisted in the past, that we should use graphics sparingly, to attract the eye to important parts of the UI. Having 20+ icons in a dialog is (in *standard* conditions) not a good idea.

For statuses (not validation results !) I've got some idea(s), but would like to have two or three completely different approaches to compare/evaluate/discuss/combine so it will be probably incremental. More in a separate message.

Architectural note:
JInput-Validator is a rather young and tiny library. I still isn't t obvious to me why it's built again from scratch, but concepts seem very similar to old good JGoodies Validation - maybe that was an inspiration in fact ? Some other concepts from JGoodies could be investigated as well; for example their idea to tag components with meta-data, which allows dialog traversal to collect & present issues in a concise list is something to consider.

I have touched briefly (in Github issue) the topic the *non-standard* glyph paint approach, taken because of supposed need to scale images, thus the image is painted from a vector font. I remember being told in the past to avoid painting "just to the Graphics2D", but use proper objects in Swing hierarchy, if possible. We were required to use Swing A11Y support at that time, which is (I think) an overkill for JMRI, but anyway: since the screenreaders etc can read the accessible description and relations - is that par of technology already dead or superseded ?

Questions:
Is there a consensus an established (developer rule) that this particular style of feedback is to be spread through the UI ? Or the JInputValidator impl rather a 'slow start' experiment (introduced only recently) ?

I need to emphasize here, that requiring all(?) icons to be drawn using font glyphs may be a barrier for UI polishing development. Is it absolutely necessary to have scalable iconographics in the entire UI ? Is there a consensus that developers are required not to produce regular icons that Swing has already support for, but have font resource as primary ?

Dne 02. 10. 19 v 1:10 Randall Wood via Groups.Io napsal(a):
we didn’t concern ourselves (and maybe some developers still don’t) with making the application behave as normally as possible on Windows and macOS and GTK-based Linux.
Focusing on native-like appearance is a great idea. Consistency is another one.
I took a tour trough https://docs.microsoft.com/en-us/windows/win32/uxguide/mess-error, but there are also other resources, which I think generally recommend to reserve an extra space in the dialog layout directly for feedback.

What style guide or desktop app UEX design was taken as basis for the JInputValidator ? I didn't find any such examples in MS UX or JLF resources; and I don't know GTK or MacOS enough to know where I should look.
Maybe I can find some other inspiration in that guide that will pass the consistency review at JMRI. Microsoft's idea to popup modal dialogs is not the way to go.


=========================
Dne 29. 09. 19 v 22:42 Bob Jacobsen napsal(a):
please note that the color values applied as the DecoderPro highlights are known to work for the most common forms of dichromacy and anomalous trichromacy
[...]
I don’t have a strong opinion about other forms of cuing, but if you do use colors, please try to stick to the java.awt.Color red.brighter(), yellow, orange and blue forms. If you need color discrimination, don’t pick non-standard color values, and don’t use pink, green, cyan, or magenta.
Two observations:
1/ the red.brighter() actually obscurs the input / combo text. The color is easily recognize, but the text isn't much readable. See the picture (https://www.dropbox.com/s/0gjpotufyltf275/error-with-text.png?dl=0). The fact is that jawa.awt.Color.red is 0xffff0000 (alpha-rgb), and red.brigter() is ... 0xffff0000 to my surprise (and it's that way on JDK6..JDK11).
Whether it is necessary to have red.brighter() (not just red) for proper contrast, I can't tell, but if so, should be derived differently (and maybe the black text would be more readable).

1/ yellow seems actually too bright (I am used to work with white background and light color themes, and it shines even there). It is good for *highlight* to call attention; but even Google uses #ffeb3b, rather than #ffff00. Various visual guidelines suggest, that a yellow (or orange) should be used for something like warning or alert states.

Please do not take the above as the red/yellow "do not work". They do, because JMRI wants to cover as much users as possible by default.

Implementation-wise, I'd suggest to consider reading the colors from UIManager, then fallback to hardcoded defaults. Maybe some abstract naming, that could allow to share colors across the application.

A weird idea how to combine "pastel" mild colors (bad heritage from my HIE/UEx colleagues), intensive colors (eliminate color vision issues) AND icons (works for b/w vision) could be combined will follow (after/if it settles a bit).

Thanks to anyone who managed to read up to this line,
-Svata


--
Bob Jacobsen
@BobJacobsen


Status colors vs icons in DecoderPro I (was: Re: GTK L&F and DecoderPro)

Svata Dedic
 

Sorry for the delay with this continuation response. It took some time to sort out thoughts, and one needs also do some coding, not just dicussions. There's a lot to say on several story lines.
Let's start with some implementation observations.

BTW the reason I am so obsessed by validation, icons, colors etc isn't that I want to be a moron. I wanted to make an UI experiment with DecoderPro, and adding validation w/ feedback was on the list.

Dne 01. 10. 19 v 2:40 Randall Wood via Groups.Io napsal(a):
Its meant for any scenario where the state of something needs to be shown
[...]
I’m more suggesting the Border in that API be used for showing reading/writing/pending change states
I attempted to use Border in that API as suggested. I was already playing with some tweaks to the PaneProgPane's layout - just experiments. So I've at least aligned some controls, but I didn't space them according to JLF guidelines yet. So the 'standard' Basic panel looks like: https://www.dropbox.com/s/tsub76fit7697vx/controls-aligned.png?dl=0 (red line shows control alignment)

When 'status border' is applied, the tab comes up like this: https://www.dropbox.com/s/1a8t2odmyy4xyj1/startup.png?dl=0. Also alignment of the control's active area seems broken; see the red line. Only when hovering the mouse over combos, dropdown buttons are painted like: https://www.dropbox.com/s/7z539metrca0s2y/partial-combos.png?dl=0 . That's on the Metal L&F, which may be not a focus, but is the Java default. In GTK L&F, it's even worse as combo dropdowns do not appear at all.

There are other drawing issues with controls other than textfields: right margin gets misaligned, icon appears *within* textfield border, but *outside* of combo box leading line - at least on Metal L&F. I wonder how a JTree would look like.

While I absolutely agree that "just color backgrounds" are not complete solution, I (repeating myself, sorry) need to strongly disagree with preenting DecoderPro statuses as icons. Not only because the support is not ready yet, but because validity and CVval state are different concepts. Imagine two nested Borders around an edit box, providing two icons. The user would need to get used to differentiate between icon categories, yet next to each other.
In addition, I remember that our HIE/UEXes insisted in the past, that we should use graphics sparingly, to attract the eye to important parts of the UI. Having 20+ icons in a dialog is (in *standard* conditions) not a good idea.

For statuses (not validation results !) I've got some idea(s), but would like to have two or three completely different approaches to compare/evaluate/discuss/combine so it will be probably incremental. More in a separate message.

Architectural note:
JInput-Validator is a rather young and tiny library. I still isn't t obvious to me why it's built again from scratch, but concepts seem very similar to old good JGoodies Validation - maybe that was an inspiration in fact ? Some other concepts from JGoodies could be investigated as well; for example their idea to tag components with meta-data, which allows dialog traversal to collect & present issues in a concise list is something to consider.

I have touched briefly (in Github issue) the topic the *non-standard* glyph paint approach, taken because of supposed need to scale images, thus the image is painted from a vector font. I remember being told in the past to avoid painting "just to the Graphics2D", but use proper objects in Swing hierarchy, if possible. We were required to use Swing A11Y support at that time, which is (I think) an overkill for JMRI, but anyway: since the screenreaders etc can read the accessible description and relations - is that par of technology already dead or superseded ?

Questions:
Is there a consensus an established (developer rule) that this particular style of feedback is to be spread through the UI ? Or the JInputValidator impl rather a 'slow start' experiment (introduced only recently) ?

I need to emphasize here, that requiring all(?) icons to be drawn using font glyphs may be a barrier for UI polishing development. Is it absolutely necessary to have scalable iconographics in the entire UI ? Is there a consensus that developers are required not to produce regular icons that Swing has already support for, but have font resource as primary ?

Dne 02. 10. 19 v 1:10 Randall Wood via Groups.Io napsal(a):
we didn’t concern ourselves (and maybe some developers still don’t) with making the application behave as normally as possible on Windows and macOS and GTK-based Linux.
Focusing on native-like appearance is a great idea. Consistency is another one.
I took a tour trough https://docs.microsoft.com/en-us/windows/win32/uxguide/mess-error, but there are also other resources, which I think generally recommend to reserve an extra space in the dialog layout directly for feedback.

What style guide or desktop app UEX design was taken as basis for the JInputValidator ? I didn't find any such examples in MS UX or JLF resources; and I don't know GTK or MacOS enough to know where I should look.
Maybe I can find some other inspiration in that guide that will pass the consistency review at JMRI. Microsoft's idea to popup modal dialogs is not the way to go.


=========================
Dne 29. 09. 19 v 22:42 Bob Jacobsen napsal(a):
please note that the color values applied as the DecoderPro highlights are known to work for the most common forms of dichromacy and anomalous trichromacy
[...]
I don’t have a strong opinion about other forms of cuing, but if you do use colors, please try to stick to the java.awt.Color red.brighter(), yellow, orange and blue forms. If you need color discrimination, don’t pick non-standard color values, and don’t use pink, green, cyan, or magenta.
Two observations:
1/ the red.brighter() actually obscurs the input / combo text. The color is easily recognize, but the text isn't much readable. See the picture (https://www.dropbox.com/s/0gjpotufyltf275/error-with-text.png?dl=0). The fact is that jawa.awt.Color.red is 0xffff0000 (alpha-rgb), and red.brigter() is ... 0xffff0000 to my surprise (and it's that way on JDK6..JDK11).
Whether it is necessary to have red.brighter() (not just red) for proper contrast, I can't tell, but if so, should be derived differently (and maybe the black text would be more readable).

1/ yellow seems actually too bright (I am used to work with white background and light color themes, and it shines even there). It is good for *highlight* to call attention; but even Google uses #ffeb3b, rather than #ffff00. Various visual guidelines suggest, that a yellow (or orange) should be used for something like warning or alert states.

Please do not take the above as the red/yellow "do not work". They do, because JMRI wants to cover as much users as possible by default.

Implementation-wise, I'd suggest to consider reading the colors from UIManager, then fallback to hardcoded defaults. Maybe some abstract naming, that could allow to share colors across the application.

A weird idea how to combine "pastel" mild colors (bad heritage from my HIE/UEx colleagues), intensive colors (eliminate color vision issues) AND icons (works for b/w vision) could be combined will follow (after/if it settles a bit).

Thanks to anyone who managed to read up to this line,
-Svata


Re: Jenkins builds

Randall Wood <rhwood@...>
 

Did figure out that build 101 of Java 1.8 introduced support for the root CA that signed LetEncrypt’s CA; as well as support for some new certificate signing algorithms; and removal of some no longer trusted signing algorithms, so it could simply be that something is not trusted somewhere if using an older Java 1.8.

Randall

On Oct 4, 2019, at 09:11, Bob Jacobsen <@BobJacobsen> wrote:

Matt, thanks for the PR.

I’m looking into this on Jenkins.

It _seems_ to be related to Jenkins still being standardized on a very early Java 8 JDK.

Bob


On Oct 4, 2019, at 4:24 AM, Matthew Harris <@mattharris> wrote:

On Fri, Oct 4, 2019 at 08:43 AM, danielb987 wrote:
2019-10-04 08:33 skrev Matthew Harris:
Looks like the upstream job has failing tests since then so, yes,
that's expected.

...

So, we need to figure out what's causing the test failure and fix it.
https://github.com/JMRI/JMRI/issues/7465

Randall Wood is working on it.
https://github.com/JMRI/JMRI/issues/7465#issuecomment-538185307

Daniel
Looks like that might be a different issue.

The test failure right now can be seen at:

http://builds.jmri.org/jenkins/job/Development/job/Builds/3632/testReport/jmri/ArchitectureTest/checkStandardStreams/

I've put together what I think should resolve this in https://github.com/JMRI/JMRI/pull/7472 but we should really dig further into why local builds and Jenkins builds seem to end-up with different behaviours with the compilation of `jmri.jmrit.XmlFile.dumpElement`: https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrit/XmlFile.java#L281

Hopefully, once merged, this will resolve that specific test failure and allow packages to build again (other errors not withstanding).

Best regards,

Matt H
--
Bob Jacobsen
@BobJacobsen






Re: Jenkins builds

Bob Jacobsen
 

Matt, thanks for the PR.

I’m looking into this on Jenkins.

It _seems_ to be related to Jenkins still being standardized on a very early Java 8 JDK.

Bob


On Oct 4, 2019, at 4:24 AM, Matthew Harris <@mattharris> wrote:

On Fri, Oct 4, 2019 at 08:43 AM, danielb987 wrote:
2019-10-04 08:33 skrev Matthew Harris:
Looks like the upstream job has failing tests since then so, yes,
that's expected.

...

So, we need to figure out what's causing the test failure and fix it.
https://github.com/JMRI/JMRI/issues/7465

Randall Wood is working on it.
https://github.com/JMRI/JMRI/issues/7465#issuecomment-538185307

Daniel
Looks like that might be a different issue.

The test failure right now can be seen at:

http://builds.jmri.org/jenkins/job/Development/job/Builds/3632/testReport/jmri/ArchitectureTest/checkStandardStreams/

I've put together what I think should resolve this in https://github.com/JMRI/JMRI/pull/7472 but we should really dig further into why local builds and Jenkins builds seem to end-up with different behaviours with the compilation of `jmri.jmrit.XmlFile.dumpElement`: https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrit/XmlFile.java#L281

Hopefully, once merged, this will resolve that specific test failure and allow packages to build again (other errors not withstanding).

Best regards,

Matt H
--
Bob Jacobsen
@BobJacobsen


Re: Turnout Table

Bob Jacobsen
 

There are a _lot_ of different ways in JMRI to drive outputs. As Steve mentioned, Lights in the Light Table drives outputs in a slightly different way than Turnouts; I’ve also seen people use two-aspect SignalHeads to drive panel lamps. Wouldn’t surprise me if there were others. That’s just a result of people using their tools to do what they want: Sometimes it’s just really convenient to hit a screw with a hammer.

What _might_ be worthwhile is an _additional_ Output Table that contains a set of very simple Output objects. Turnouts and Lights have some complicated behaviors and options that can, sometimes, be seen as getting in the way.

Before Dave Duchamp created Lights, there was a vestigial Output concept, in addition to Turnouts, in a couple systems. Lights was such a clear advance, completely coded, that it really caught on right away and filled the “but Turnout isn’t quite right for want I want to do” ecological niche.

Bob

On Oct 4, 2019, at 3:54 AM, RadSolution via Groups.Io <radsolution=yahoo.co.uk@groups.io> wrote:

All,

I read recently on the MERG forum:
“The turnout table is used for outputs from JMRI, in addition to just turnouts.”

Isn’t it, therefore, time that item was renamed?
--
Bob Jacobsen
@BobJacobsen


Re: Turnout Table

steve young
 


Imho, there are higher priorities for both JMRI and the CBUS support,
I've also got a feeling that renaming the Turnout Table in MERG CBUS will end up in a support mess.
Overnight, all of the tutorials would go out of date.

The Light Table is another preferred way of sending outputs with CBUS,
hoping to add variable Light support ( both incoming and outgoing ) using the extra event data bytes.

Technically Sensors in the CBUS Sensor Table can also be used for outputs, though easier user support to not encourage this ;-)

Steve.


Re: Multithreading question

Bob Jacobsen
 

I’m really not sure what you mean by ' calls the method object.execute() on the GUI thread’, but the usual way to do this is to use standard methods to run `object.execute()` _later_ on the thread. You queue is as a later action on the GUI thread:

https://www.jmri.org/JavaDoc/doc/jmri/util/ThreadingUtil.html#runOnGUIEventually-jmri.util.ThreadingUtil.ThreadAction-

"Run some GUI-specific code at some later point.
If invoked from the GUI thread, the work is guaranteed to happen only after the current routine has returned."

By doing it later, it serializes anything that might otherwise be a recursion.

Bob

On Oct 3, 2019, at 4:47 PM, danielb987 <db123@...> wrote:

I have a method ConditionalNG.execute() that may be called from any thread. This method calls the method object.execute() on the GUI thread. The method object.execute() calls other methods that in turn may call the method ConditionalNG.execute().
--
Bob Jacobsen
@BobJacobsen


Re: Jenkins builds

Matthew Harris
 

On Fri, Oct 4, 2019 at 08:43 AM, danielb987 wrote:
2019-10-04 08:33 skrev Matthew Harris:
Looks like the upstream job has failing tests since then so, yes,
that's expected.

...

So, we need to figure out what's causing the test failure and fix it.
https://github.com/JMRI/JMRI/issues/7465

Randall Wood is working on it.
https://github.com/JMRI/JMRI/issues/7465#issuecomment-538185307

Daniel
Looks like that might be a different issue.

The test failure right now can be seen at:

http://builds.jmri.org/jenkins/job/Development/job/Builds/3632/testReport/jmri/ArchitectureTest/checkStandardStreams/

I've put together what I think should resolve this in https://github.com/JMRI/JMRI/pull/7472 but we should really dig further into why local builds and Jenkins builds seem to end-up with different behaviours with the compilation of `jmri.jmrit.XmlFile.dumpElement`: https://github.com/JMRI/JMRI/blob/master/java/src/jmri/jmrit/XmlFile.java#L281

Hopefully, once merged, this will resolve that specific test failure and allow packages to build again (other errors not withstanding). 

Best regards,

Matt H


Turnout Table

RadSolution
 

All,

I read recently on the MERG forum:
“The turnout table is used for outputs from JMRI, in addition to just turnouts.”

Isn’t it, therefore, time that item was renamed?


Re: Multithreading question

Svata Dedic
 

Dne 04. 10. 19 v 8:22 danielb987 napsal(a):
                ThreadingUtil.runOnGUI(() -> {
                    object.execute();
If it is absolutely necessary for the executed code to (potentially) block the GUI thread... (sorry don't know the intended use, perhaps UI feedback is provided)

public class ExecuteLock {
    private boolean lock = false;
    private boolean again = false;
[...]
1/ In a situation, when object.execute() recursively execute()s AND an external thread ALSO execute()s (tries to) before current execution completes, object.execute() will be run just once more. Is that according to your requirements ?

2/ Rigidly, the object job's execution is determined at the monitor exit in loop(). If by a chance a contending thread attempts to execute() in between monitor exit in loop() and actual object.execute() start within GUI thread, an additional object.execute() will run. OK ?

3/ If the thread, that (initializes ConditionNG ?) assigns `object' could be different from *first* thread that enters execute(), either declare `object' final, or have at least one ExecuteLock's monitor exit on the thread that assigns `object' before any execution can reach execute().

-S.

Nitpick: if the guard will be exposed as API, consider renaming get() to something like once(), single(). In the API case, I'd consider to implement j.u.concurrent.Executor, if possible.


Re: Jenkins builds

danielb987
 

2019-10-04 08:33 skrev Matthew Harris:
Looks like the upstream job has failing tests since then so, yes,
that's expected.
...
So, we need to figure out what's causing the test failure and fix it.
https://github.com/JMRI/JMRI/issues/7465

Randall Wood is working on it.
https://github.com/JMRI/JMRI/issues/7465#issuecomment-538185307

Daniel


Re: Jenkins builds

Matthew Harris
 

Peter,

Looks like the upstream job has failing tests since then so, yes, that's expected. 

Basically, the 'Packages' job is kicked-off after a successful 'Builds':
http://builds.jmri.org/jenkins/job/Development/job/Builds/

This is so that only builds that pass our unit tests are packaged up as installable artifacts.

So, we need to figure out what's causing the test failure and fix it.

Hope that makes sense.

Best regards, 

Matt H