Date   

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


Re: Multithreading question

danielb987
 

I think I have solved the problem.



class ConditionalNG {

private final ExecuteLock executeLock = new ExecuteLock();

public void execute() {
if (executeLock.get()) {
while (executeLock.loop()) {
ThreadingUtil.runOnGUI(() -> {
object.execute();
});
}
}
}

}





/**
* Protect the ConditionalNG.execute() method.
* That method may be called recursively from different threads.
*/
public class ExecuteLock {

private boolean lock = false;
private boolean again = false;

/**
* Get the status of the lock.
* If the call succeeds, the caller is responsible to loop while the method
* loop() returns true.
* @return true if the caller gets the lock.
*/
public boolean get() {
synchronized(this) {
again = true;
if (! lock) {
lock = true;
return true;
} else {
return false;
}
}
}

/**
* Get the status of the lock during loop.
* The caller is responsible to loop while the method returns true.
* @return true if the caller still has the lock.
*/
public boolean loop() {
synchronized(this) {
if (again) {
again = false;
return true;
} else {
lock = false;
return false;
}
}
}

}





2019-10-04 01:47 skrev danielb987:

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().
I don't want the method object.execute() to be called recursively so I
must protect from that. But if ConditionalNG.execute() is called while
it's running, it must remember that so that it calls object.execute()
again once that method is finished. The method ConditionalNG.execute()
may be called multiple times before object.execute() is finished and
if so, it must call object.execute() only once.
I'm thinking of something like the code below, but need to get it to
work in a multithreading environment.
class ConditionalNG {
boolean isExecuting = false;
boolean executeAgain = false;
public void execute() {
if (isExecuting) {
executeAgain = true;
} else {
do {
isExecuting = true;
executeAgain = false;
ThreadingUtil.runOnGUI(() -> {
object.execute();
}
isExecuting = false;
} while (executeAgain);
executeAgain = false;
}
}
}
Any suggestions on how this method should look like?
ConditionalNG is similar to Conditional in Logix, but I have no
control over the method object.execute().
Daniel


Jenkins builds

Peter Ulvestad
 

There haven't been any new packages built since the 24th of September, is this expected?
http://jmri.tagadab.com/jenkins/job/Development/job/Packages/

--
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/


Multithreading question

danielb987
 

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().

I don't want the method object.execute() to be called recursively so I must protect from that. But if ConditionalNG.execute() is called while it's running, it must remember that so that it calls object.execute() again once that method is finished. The method ConditionalNG.execute() may be called multiple times before object.execute() is finished and if so, it must call object.execute() only once.

I'm thinking of something like the code below, but need to get it to work in a multithreading environment.


class ConditionalNG {

boolean isExecuting = false;
boolean executeAgain = false;

public void execute() {
if (isExecuting) {
executeAgain = true;
} else {
do {
isExecuting = true;
executeAgain = false;

ThreadingUtil.runOnGUI(() -> {
object.execute();
}

isExecuting = false;

} while (executeAgain);
executeAgain = false;
}
}

}

Any suggestions on how this method should look like?

ConditionalNG is similar to Conditional in Logix, but I have no control over the method object.execute().

Daniel


Re: Unused import warnings

RadSolution
 

" Every IDE I have used makes a distinction between “organizing” imports and “removing unused” imports. "

...except Visual Studio, which does both with one mouse click.... ;-)


On Thursday, 3 October 2019, 02:50:39 BST, Randall Wood via Groups.Io <rhwood@...> wrote:


Every IDE I have used makes a distinction between “organizing” imports and “removing unused” imports.

Randall
> On Oct 2, 2019, at 18:47, Bob Jacobsen <rgj1927@...> wrote:
>
> And that’s great so long as those same clicks _don’t_ expand  `import java.util.*` into a flock of individual imports.  In the past, that’s been a collateral consequence.
>
> Note that I agree that reasonable people can differ on imports c.f. https://www.leadingagile.com/2018/12/the-importance-of-imports-in-java/ and I have _no_ problem with people removing individual unused imports; thank you to all that do that.
>
> At the same time, please understand that some of the JMRI development community don’t think that Huge Sequences Of Import Statements are readable, and prefers to remove them.  An `import javax.swing.*` is not a bad thing. Thank you to all that simplify those HSOIS occurrences.  (And, if you’re removing an import in a HSOIS, you can often quickly drag over N-1 of them, delete, and change the last word in the remaining one to a *)
>
> Bob
>
>> On Oct 2, 2019, at 12:24 PM, Randall Wood via Groups.Io <rhwood=mac.com@groups.io> wrote:
>>
>> The reality is that for an IDE user, removing every single unused or redundant (i.e. same package) import in JMRI is something like 4 clicks with a mouse, without touching a single file by hand.
>
> --
> Bob Jacobsen
> rgj1927@...
>
>
>
>
>
>




Re: Unused import warnings

Randall Wood <rhwood@...>
 

Every IDE I have used makes a distinction between “organizing” imports and “removing unused” imports.

Randall

On Oct 2, 2019, at 18:47, Bob Jacobsen <@BobJacobsen> wrote:

And that’s great so long as those same clicks _don’t_ expand `import java.util.*` into a flock of individual imports. In the past, that’s been a collateral consequence.

Note that I agree that reasonable people can differ on imports c.f. https://www.leadingagile.com/2018/12/the-importance-of-imports-in-java/ and I have _no_ problem with people removing individual unused imports; thank you to all that do that.

At the same time, please understand that some of the JMRI development community don’t think that Huge Sequences Of Import Statements are readable, and prefers to remove them. An `import javax.swing.*` is not a bad thing. Thank you to all that simplify those HSOIS occurrences. (And, if you’re removing an import in a HSOIS, you can often quickly drag over N-1 of them, delete, and change the last word in the remaining one to a *)

Bob

On Oct 2, 2019, at 12:24 PM, Randall Wood via Groups.Io <rhwood=mac.com@groups.io> wrote:

The reality is that for an IDE user, removing every single unused or redundant (i.e. same package) import in JMRI is something like 4 clicks with a mouse, without touching a single file by hand.
--
Bob Jacobsen
@BobJacobsen






Re: CodeClimate on Forks

Randall Wood <rhwood@...>
 

Code Climate CLI which runs locally is at https://github.com/codeclimate/codeclimate (note requirement that you be able to run Docker).

To run it on your fork, you will need to associate Code Climate Quality at http://codeclimate.com  with your GitHub accounts (public only—GitHub requires that access to private accounts be full access, and your JMRI fork is public). Note that coverage reporting is not available on forks.

Randall

On Oct 2, 2019, at 19:05, danielb987 <db123@...> wrote:

I'm not sure, but it may be one of my PRs you think about. I'm on phone now and not logged in to GitHub. But search for _closed_ and not merged PRs by user danielb987 with the text LogixNG. It's one of my latest PRs so it should be easy to find.

Daniel


-------- Originalmeddelande --------
Från: Dave Heap <dgheap@...>
Datum: 2019-10-02 22:24 (GMT+01:00)
Till: jmri@jmri-developers.groups.io
Rubrik: [jmri-developers] CodeClimate on Forks

I seem to remember recently some comments about using CodeClimate on our own forks (and possibly even on a local checkout on Mac?). I now can't find anything relevant...
--
Dave




Re: Unused import warnings

Dan Boudreau
 

Found that I can configure Eclipse to automatically consolidate imports to something like `import java.util.*`.  Found under Organize Imports.  Interesting that I found the default to be 99, changed it to 5 and it seems to be doing the right thing.

 

 


Re: CodeClimate on Forks

danielb987
 

I'm not sure, but it may be one of my PRs you think about. I'm on phone now and not logged in to GitHub. But search for _closed_ and not merged PRs by user danielb987 with the text LogixNG. It's one of my latest PRs so it should be easy to find.

Daniel


-------- Originalmeddelande --------
Från: Dave Heap <dgheap@...>
Datum: 2019-10-02 22:24 (GMT+01:00)
Till: jmri@jmri-developers.groups.io
Rubrik: [jmri-developers] CodeClimate on Forks

I seem to remember recently some comments about using CodeClimate on our own forks (and possibly even on a local checkout on Mac?). I now can't find anything relevant...
--
Dave




Re: Unused import warnings

Bob Jacobsen
 

And that’s great so long as those same clicks _don’t_ expand `import java.util.*` into a flock of individual imports. In the past, that’s been a collateral consequence.

Note that I agree that reasonable people can differ on imports c.f. https://www.leadingagile.com/2018/12/the-importance-of-imports-in-java/ and I have _no_ problem with people removing individual unused imports; thank you to all that do that.

At the same time, please understand that some of the JMRI development community don’t think that Huge Sequences Of Import Statements are readable, and prefers to remove them. An `import javax.swing.*` is not a bad thing. Thank you to all that simplify those HSOIS occurrences. (And, if you’re removing an import in a HSOIS, you can often quickly drag over N-1 of them, delete, and change the last word in the remaining one to a *)

Bob

On Oct 2, 2019, at 12:24 PM, Randall Wood via Groups.Io <rhwood=mac.com@groups.io> wrote:

The reality is that for an IDE user, removing every single unused or redundant (i.e. same package) import in JMRI is something like 4 clicks with a mouse, without touching a single file by hand.
--
Bob Jacobsen
@BobJacobsen


CodeClimate on Forks

Dave Heap
 

I seem to remember recently some comments about using CodeClimate on our own forks (and possibly even on a local checkout on Mac?). I now can't find anything relevant...
--
Dave


Re: Unused import warnings

Randall Wood <rhwood@...>
 

The reality is that for an IDE user, removing every single unused or redundant (i.e. same package) import in JMRI is something like 4 clicks with a mouse, without touching a single file by hand.

Randall

On Oct 2, 2019, at 14:58, Bob Jacobsen <@BobJacobsen> wrote:

I think there’s some small N where one transitions from N specific imports to one * import to increase readability and accessibility of the file (the compiler doesn’t care either way[1]). Reasonable people can vary, but I think N of 3 to 5 is reasonable.

c.f.
java/src/jmri/jmrit/display/layoutEditor/LayoutEditor.java

If you’re editing by hand, do you need to add a import? Remove an import?

Bob


[1] Yes, there can be collisions in names, but they’re really quite rare in well-structured JMRI code.

On Oct 2, 2019, at 7:18 AM, danielb987 <db123@...> wrote:

Is this only about "import java.awt.*;" or about any packages, for example "import jmri.*;" ?

Daniel


-------- Originalmeddelande --------
Från: Bob Jacobsen <@BobJacobsen>
Datum: 2019-10-02 14:59 (GMT+01:00)
Till: jmri@jmri-developers.groups.io
Rubrik: Re: [jmri-developers] Unused import warnings



On Oct 1, 2019, at 2:13 PM, Dan Boudreau <daboudreau@...> wrote:

I’m seeing hundreds of unused import warning. I can easily clean them up, anyone object?
Fixing them would be great, but let me recommend that you find that e.g. one of the following lines is unused:

import java.awt.BasicStroke;
import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.Component;
import java.awt.Container;
import java.awt.Cursor;
import java.awt.Dimension;
import java.awt.FlowLayout;
import java.awt.Font;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.MouseInfo;
import java.awt.Point;
import java.awt.PointerInfo;
import java.awt.Rectangle;
import java.awt.RenderingHints;
import java.awt.Stroke;
import java.awt.Toolkit;

You replace the whole thing with

import java.awt.*;

That’s the practice in the standards doc we agreed to (admittedly a long time ago), but it occasionally gets lost due to IDE settings.

(Yes, I understand that there are two List classes in the Java API; that’s an interesting, but not compelling, special case)

Bob

--
Bob Jacobsen
@BobJacobsen






--
Bob Jacobsen
@BobJacobsen






Re: Unused import warnings

Bob Jacobsen
 

I think there’s some small N where one transitions from N specific imports to one * import to increase readability and accessibility of the file (the compiler doesn’t care either way[1]). Reasonable people can vary, but I think N of 3 to 5 is reasonable.

c.f.
java/src/jmri/jmrit/display/layoutEditor/LayoutEditor.java

If you’re editing by hand, do you need to add a import? Remove an import?

Bob


[1] Yes, there can be collisions in names, but they’re really quite rare in well-structured JMRI code.

On Oct 2, 2019, at 7:18 AM, danielb987 <db123@...> wrote:

Is this only about "import java.awt.*;" or about any packages, for example "import jmri.*;" ?

Daniel


-------- Originalmeddelande --------
Från: Bob Jacobsen <@BobJacobsen>
Datum: 2019-10-02 14:59 (GMT+01:00)
Till: jmri@jmri-developers.groups.io
Rubrik: Re: [jmri-developers] Unused import warnings



On Oct 1, 2019, at 2:13 PM, Dan Boudreau <daboudreau@...> wrote:


I’m seeing hundreds of unused import warning. I can easily clean them up, anyone object?
Fixing them would be great, but let me recommend that you find that e.g. one of the following lines is unused:

import java.awt.BasicStroke;
import java.awt.BorderLayout;
import java.awt.Color;
import java.awt.Component;
import java.awt.Container;
import java.awt.Cursor;
import java.awt.Dimension;
import java.awt.FlowLayout;
import java.awt.Font;
import java.awt.Graphics;
import java.awt.Graphics2D;
import java.awt.MouseInfo;
import java.awt.Point;
import java.awt.PointerInfo;
import java.awt.Rectangle;
import java.awt.RenderingHints;
import java.awt.Stroke;
import java.awt.Toolkit;

You replace the whole thing with

import java.awt.*;

That’s the practice in the standards doc we agreed to (admittedly a long time ago), but it occasionally gets lost due to IDE settings.

(Yes, I understand that there are two List classes in the Java API; that’s an interesting, but not compelling, special case)

Bob

--
Bob Jacobsen
@BobJacobsen






--
Bob Jacobsen
@BobJacobsen