Topics

Serious Crash of fairly latest source code 4.19.7.ish.....


wombat_rrnut
 

All:

I fairly recently downloaded the JMRI source 4.19.7.ish around 5/25/2020 (Not sure the exact date).
I've been updating my LayoutEditor panel with modifications from the layout changes.  I have a
crossover that requires a left and a right switch.  So I have to use two switches vs. selecting
crossover when I create it.

As I've never used the INVERT checkbox (below), I don't know when this problem
was introduced.

If I select "also throw switch" and DO NOT check "Invert", when I (on the panel)
change either, the other changes fine (of course wrongly since "Invert" not checked).
See Crash1.jpg attachment for configuration.

If however, I "also throw switch" with INVERT checked, the first time
I throw the switch, JMRI crashes with over 1000's lines of output.
The first line is most instructive:

2020-05-31 10:01:39,002 ptionhandler.UncaughtExceptionHandler ERROR - Uncaught Exception caught by jmri.util.exceptionhandler.UncaughtExceptionHandler [AWT-EventQueue-0]
java.lang.StackOverflowError

See Crash1.txt for full details....


I've also attached (I believe) everything you need to reproduce this problem on you own
machine (GNP.zip and LayoutEditor_Simulation.zip").

However. in the distribution, I DID NOT tie the two together, in case that helps with the
debugging.

The switch being modified is about in the middle on the panel.
See  "Panel2.jpg" for which switch you should edit and perform
the Crash1.jpg procedure on it.

This is for an operating layout, but "luckily" due to Covid-19, I probably won't operate
this for a few months yet (if not longer).  So there is time to fix this.

Sincerely
Greg


Dave Sand
 

Greg,

I have come to the conclusion that "also throw", "inverted" and "feedback" don't like each other. This situation is even more complicated since SW35 itself is defined in the turnout table as Inverted.

My recommendation is to do the inverting at the hardware level.  Use the LE Continuing Route feature to make the panel image match the layout.

Dave Sand


----- Original message -----
From: wombat_rrnut <gbedlek001@...>
Subject: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....
Date: Sunday, May 31, 2020 10:31 AM

All:

I fairly recently downloaded the JMRI source 4.19.7.ish around 5/25/2020 (Not sure the exact date).
I've been updating my LayoutEditor panel with modifications from the layout changes.  I have a
crossover that requires a left and a right switch.  So I have to use two switches vs. selecting
crossover when I create it.

As I've never used the INVERT checkbox (below), I don't know when this problem
was introduced.

If I select "also throw switch" and DO NOT check "Invert", when I (on the panel)
change either, the other changes fine (of course wrongly since "Invert" not checked).
See Crash1.jpg attachment for configuration.

If however, I "also throw switch" with INVERT checked, the first time
I throw the switch, JMRI crashes with over 1000's lines of output.
The first line is most instructive:

2020-05-31 10:01:39,002 ptionhandler.UncaughtExceptionHandler ERROR - Uncaught Exception caught by jmri.util.exceptionhandler.UncaughtExceptionHandler [AWT-EventQueue-0]
java.lang.StackOverflowError

See Crash1.txt for full details....


I've also attached (I believe) everything you need to reproduce this problem on you own
machine (GNP.zip and LayoutEditor_Simulation.zip").

However. in the distribution, I DID NOT tie the two together, in case that helps with the
debugging.

The switch being modified is about in the middle on the panel.
See  "Panel2.jpg" for which switch you should edit and perform
the Crash1.jpg procedure on it.

This is for an operating layout, but "luckily" due to Covid-19, I probably won't operate
this for a few months yet (if not longer).  So there is time to fix this.

Sincerely
Greg

Attachments:
  • Crash1.jpg
  • Crash1.txt
  • GNP.zip
  • LayoutEditor_Simulation.jmri.zip
  • Panel2.jpg


Bob Jacobsen
 

I’ve spent the last few hours creating tests for the inverted option in combination with various feedback implementations in the hardware classes, and tracking how they operate through the code.

It would be very hard to get these to all work for every possible combination.

Is there anything that “inverted” does in Layout Editor itself that can’t be handled via the inverted option on the jmri.Turnout object itself?

The only thing I can think of would multiple LayoutEditor objects controlling the same Turnout and needing different inverted settings. But (a) I don’t think that’s possible now, (b) I can’t see how that’s useful and (c) it can be done with routes/logix if needed in some specific case.

Or does is it somehow necessary that signaling or some other upstream use know that here vs in the jmri.Turnout?

If there isn’t, I’d like to remove the option as Too Complicated To Live in the 4.21 series, with a Kind and Gentle message if a file is found to have it set.

Bob

On May 31, 2020, at 9:08 AM, Dave Sand <@davesand> wrote:

Greg,

I have come to the conclusion that "also throw", "inverted" and "feedback" don't like each other. This situation is even more complicated since SW35 itself is defined in the turnout table as Inverted.

My recommendation is to do the inverting at the hardware level. Use the LE Continuing Route feature to make the panel image match the layout.

Dave Sand


----- Original message -----
From: wombat_rrnut <gbedlek001@...>
To: jmri@jmri-developers.groups.io
Subject: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....
Date: Sunday, May 31, 2020 10:31 AM

All:

I fairly recently downloaded the JMRI source 4.19.7.ish around 5/25/2020 (Not sure the exact date).
I've been updating my LayoutEditor panel with modifications from the layout changes. I have a
crossover that requires a left and a right switch. So I have to use two switches vs. selecting
crossover when I create it.

As I've never used the INVERT checkbox (below), I don't know when this problem
was introduced.

If I select "also throw switch" and DO NOT check "Invert", when I (on the panel)
change either, the other changes fine (of course wrongly since "Invert" not checked).
See Crash1.jpg attachment for configuration.

If however, I "also throw switch" with INVERT checked, the first time
I throw the switch, JMRI crashes with over 1000's lines of output.
The first line is most instructive:

2020-05-31 10:01:39,002 ptionhandler.UncaughtExceptionHandler ERROR - Uncaught Exception caught by jmri.util.exceptionhandler.UncaughtExceptionHandler [AWT-EventQueue-0]
java.lang.StackOverflowError

See Crash1.txt for full details....


I've also attached (I believe) everything you need to reproduce this problem on you own
machine (GNP.zip and LayoutEditor_Simulation.zip").

However. in the distribution, I DID NOT tie the two together, in case that helps with the
debugging.

The switch being modified is about in the middle on the panel.
See "Panel2.jpg" for which switch you should edit and perform
the Crash1.jpg procedure on it.

This is for an operating layout, but "luckily" due to Covid-19, I probably won't operate
this for a few months yet (if not longer). So there is time to fix this.

Sincerely
Greg

Attachments:
• Crash1.jpg
• Crash1.txt
• GNP.zip
• LayoutEditor_Simulation.jmri.zip
• Panel2.jpg

--
Bob Jacobsen
@BobJacobsen


whmvd
 

Bob,

Woud it not be considerably more painless to incorporate that message as soon as possible (without further action, just a required 'OK' at most once for every load, while keeping the invert option fully functional or at least as fully as it is now) and only remove the option one production release later? That at least gives people who use it, if any, to make the required change in their own time instead of leaving them in the lurch suddenly.

Wouter


On Sun, 31 May 2020 at 21:48, Bob Jacobsen <rgj1927@...> wrote:
I’ve spent the last few hours creating tests for the inverted option in combination with various feedback implementations in the hardware classes, and tracking how they operate through the code.

It would be very hard to get these to all work for every possible combination.

Is there anything that “inverted” does in Layout Editor itself that can’t be handled via the inverted option on the jmri.Turnout object itself?

The only thing I can think of would multiple LayoutEditor objects controlling the same Turnout and needing different inverted settings.  But (a) I don’t think that’s possible now, (b) I can’t see how that’s useful and (c) it can be done with routes/logix if needed in some specific case.

Or does is it somehow necessary that signaling or some other upstream use know that here vs in the jmri.Turnout?

If there isn’t, I’d like to remove the option as Too Complicated To Live in the 4.21 series, with a Kind and Gentle message if a file is found to have it set.

Bob

> On May 31, 2020, at 9:08 AM, Dave Sand <ds@...> wrote:
>
> Greg,
>
> I have come to the conclusion that "also throw", "inverted" and "feedback" don't like each other. This situation is even more complicated since SW35 itself is defined in the turnout table as Inverted.
>
> My recommendation is to do the inverting at the hardware level.  Use the LE Continuing Route feature to make the panel image match the layout.
>
> Dave Sand
>
>
> ----- Original message -----
> From: wombat_rrnut <gbedlek001@...>
> To: jmri@jmri-developers.groups.io
> Subject: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....
> Date: Sunday, May 31, 2020 10:31 AM
>
> All:
>
> I fairly recently downloaded the JMRI source 4.19.7.ish around 5/25/2020 (Not sure the exact date).
> I've been updating my LayoutEditor panel with modifications from the layout changes.  I have a
> crossover that requires a left and a right switch.  So I have to use two switches vs. selecting
> crossover when I create it.
>
> As I've never used the INVERT checkbox (below), I don't know when this problem
> was introduced.
>
> If I select "also throw switch" and DO NOT check "Invert", when I (on the panel)
> change either, the other changes fine (of course wrongly since "Invert" not checked).
> See Crash1.jpg attachment for configuration.
>
> If however, I "also throw switch" with INVERT checked, the first time
> I throw the switch, JMRI crashes with over 1000's lines of output.
> The first line is most instructive:
>
> 2020-05-31 10:01:39,002 ptionhandler.UncaughtExceptionHandler ERROR - Uncaught Exception caught by jmri.util.exceptionhandler.UncaughtExceptionHandler [AWT-EventQueue-0]
> java.lang.StackOverflowError
>
> See Crash1.txt for full details....
>
>
> I've also attached (I believe) everything you need to reproduce this problem on you own
> machine (GNP.zip and LayoutEditor_Simulation.zip").
>
> However. in the distribution, I DID NOT tie the two together, in case that helps with the
> debugging.
>
> The switch being modified is about in the middle on the panel.
> See  "Panel2.jpg" for which switch you should edit and perform
> the Crash1.jpg procedure on it.
>
> This is for an operating layout, but "luckily" due to Covid-19, I probably won't operate
> this for a few months yet (if not longer).  So there is time to fix this.
>
> Sincerely
> Greg
>
> Attachments:
>       • Crash1.jpg
>       • Crash1.txt
>       • GNP.zip
>       • LayoutEditor_Simulation.jmri.zip
>       • Panel2.jpg
>
>

--
Bob Jacobsen
rgj1927@...







Randall Wood <rhwood@...>
 

It is surprising how easy it is for a user to train themselves to simply click through error or warning messages without reading them. Do you want to deal with a user who gets used to blindly clicking through the message and then mistakes a slightly different message that leads to damage (loss of data in JMRI or physical damage to a model railroad) by clicking through it?

On 31-May-2020, at 17:03, whmvd <vandoornw@...> wrote:

Bob,

Woud it not be considerably more painless to incorporate that message as soon as possible (without further action, just a required 'OK' at most once for every load, while keeping the invert option fully functional or at least as fully as it is now) and only remove the option one production release later? That at least gives people who use it, if any, to make the required change in their own time instead of leaving them in the lurch suddenly.

Wouter

On Sun, 31 May 2020 at 21:48, Bob Jacobsen <rgj1927@...> wrote:
I’ve spent the last few hours creating tests for the inverted option in combination with various feedback implementations in the hardware classes, and tracking how they operate through the code.

It would be very hard to get these to all work for every possible combination. 

Is there anything that “inverted” does in Layout Editor itself that can’t be handled via the inverted option on the jmri.Turnout object itself?

The only thing I can think of would multiple LayoutEditor objects controlling the same Turnout and needing different inverted settings.  But (a) I don’t think that’s possible now, (b) I can’t see how that’s useful and (c) it can be done with routes/logix if needed in some specific case.

Or does is it somehow necessary that signaling or some other upstream use know that here vs in the jmri.Turnout?

If there isn’t, I’d like to remove the option as Too Complicated To Live in the 4.21 series, with a Kind and Gentle message if a file is found to have it set.

Bob

> On May 31, 2020, at 9:08 AM, Dave Sand <ds@...> wrote:
> 
> Greg,
> 
> I have come to the conclusion that "also throw", "inverted" and "feedback" don't like each other. This situation is even more complicated since SW35 itself is defined in the turnout table as Inverted.
> 
> My recommendation is to do the inverting at the hardware level.  Use the LE Continuing Route feature to make the panel image match the layout.
> 
> Dave Sand
> 
> 
> ----- Original message -----
> From: wombat_rrnut <gbedlek001@...>
> To: jmri@jmri-developers.groups.io
> Subject: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....
> Date: Sunday, May 31, 2020 10:31 AM
> 
> All:
> 
> I fairly recently downloaded the JMRI source 4.19.7.ish around 5/25/2020 (Not sure the exact date).
> I've been updating my LayoutEditor panel with modifications from the layout changes.  I have a
> crossover that requires a left and a right switch.  So I have to use two switches vs. selecting
> crossover when I create it.
> 
> As I've never used the INVERT checkbox (below), I don't know when this problem
> was introduced.
> 
> If I select "also throw switch" and DO NOT check "Invert", when I (on the panel)
> change either, the other changes fine (of course wrongly since "Invert" not checked).
> See Crash1.jpg attachment for configuration.
> 
> If however, I "also throw switch" with INVERT checked, the first time
> I throw the switch, JMRI crashes with over 1000's lines of output.
> The first line is most instructive:
> 
> 2020-05-31 10:01:39,002 ptionhandler.UncaughtExceptionHandler ERROR - Uncaught Exception caught by jmri.util.exceptionhandler.UncaughtExceptionHandler [AWT-EventQueue-0]
> java.lang.StackOverflowError
> 
> See Crash1.txt for full details....
> 
> 
> I've also attached (I believe) everything you need to reproduce this problem on you own
> machine (GNP.zip and LayoutEditor_Simulation.zip").
> 
> However. in the distribution, I DID NOT tie the two together, in case that helps with the
> debugging.
> 
> The switch being modified is about in the middle on the panel.
> See  "Panel2.jpg" for which switch you should edit and perform
> the Crash1.jpg procedure on it.
> 
> This is for an operating layout, but "luckily" due to Covid-19, I probably won't operate
> this for a few months yet (if not longer).  So there is time to fix this.
> 
> Sincerely
> Greg 
> 
> Attachments:
>       • Crash1.jpg
>       • Crash1.txt
>       • GNP.zip
>       • LayoutEditor_Simulation.jmri.zip
>       • Panel2.jpg
> 
> 

--
Bob Jacobsen
rgj1927@...








whmvd
 

Randall,

Yes, I would (though I don't see how the physical damage would occur in my scenario, to be honest, and not in the one you propose) because it is infinitely more defensible. Those users currently having the invert option active (for whatever reason, good or bad, it apparently did something useful for them) would be seriously upset if, without warning, from one release to the next their panels developed malfunctions that are going to be difficult to trace - and fix. I'd expect a process similar to deprecation in code. If they ignore the warnings, then at least they'll have taken the DECISION to ignore them. That sort of method does not, of course, work for those skipping releases, but you can take it only so far.

Wouter


On Sun, 31 May 2020 at 22:17, Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:
It is surprising how easy it is for a user to train themselves to simply click through error or warning messages without reading them. Do you want to deal with a user who gets used to blindly clicking through the message and then mistakes a slightly different message that leads to damage (loss of data in JMRI or physical damage to a model railroad) by clicking through it?

On 31-May-2020, at 17:03, whmvd <vandoornw@...> wrote:

Bob,

Woud it not be considerably more painless to incorporate that message as soon as possible (without further action, just a required 'OK' at most once for every load, while keeping the invert option fully functional or at least as fully as it is now) and only remove the option one production release later? That at least gives people who use it, if any, to make the required change in their own time instead of leaving them in the lurch suddenly.

Wouter

On Sun, 31 May 2020 at 21:48, Bob Jacobsen <rgj1927@...> wrote:
I’ve spent the last few hours creating tests for the inverted option in combination with various feedback implementations in the hardware classes, and tracking how they operate through the code.

It would be very hard to get these to all work for every possible combination. 

Is there anything that “inverted” does in Layout Editor itself that can’t be handled via the inverted option on the jmri.Turnout object itself?

The only thing I can think of would multiple LayoutEditor objects controlling the same Turnout and needing different inverted settings.  But (a) I don’t think that’s possible now, (b) I can’t see how that’s useful and (c) it can be done with routes/logix if needed in some specific case.

Or does is it somehow necessary that signaling or some other upstream use know that here vs in the jmri.Turnout?

If there isn’t, I’d like to remove the option as Too Complicated To Live in the 4.21 series, with a Kind and Gentle message if a file is found to have it set.

Bob

> On May 31, 2020, at 9:08 AM, Dave Sand <ds@...> wrote:
> 
> Greg,
> 
> I have come to the conclusion that "also throw", "inverted" and "feedback" don't like each other. This situation is even more complicated since SW35 itself is defined in the turnout table as Inverted.
> 
> My recommendation is to do the inverting at the hardware level.  Use the LE Continuing Route feature to make the panel image match the layout.
> 
> Dave Sand
> 
> 
> ----- Original message -----
> From: wombat_rrnut <gbedlek001@...>
> To: jmri@jmri-developers.groups.io
> Subject: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....
> Date: Sunday, May 31, 2020 10:31 AM
> 
> All:
> 
> I fairly recently downloaded the JMRI source 4.19.7.ish around 5/25/2020 (Not sure the exact date).
> I've been updating my LayoutEditor panel with modifications from the layout changes.  I have a
> crossover that requires a left and a right switch.  So I have to use two switches vs. selecting
> crossover when I create it.
> 
> As I've never used the INVERT checkbox (below), I don't know when this problem
> was introduced.
> 
> If I select "also throw switch" and DO NOT check "Invert", when I (on the panel)
> change either, the other changes fine (of course wrongly since "Invert" not checked).
> See Crash1.jpg attachment for configuration.
> 
> If however, I "also throw switch" with INVERT checked, the first time
> I throw the switch, JMRI crashes with over 1000's lines of output.
> The first line is most instructive:
> 
> 2020-05-31 10:01:39,002 ptionhandler.UncaughtExceptionHandler ERROR - Uncaught Exception caught by jmri.util.exceptionhandler.UncaughtExceptionHandler [AWT-EventQueue-0]
> java.lang.StackOverflowError
> 
> See Crash1.txt for full details....
> 
> 
> I've also attached (I believe) everything you need to reproduce this problem on you own
> machine (GNP.zip and LayoutEditor_Simulation.zip").
> 
> However. in the distribution, I DID NOT tie the two together, in case that helps with the
> debugging.
> 
> The switch being modified is about in the middle on the panel.
> See  "Panel2.jpg" for which switch you should edit and perform
> the Crash1.jpg procedure on it.
> 
> This is for an operating layout, but "luckily" due to Covid-19, I probably won't operate
> this for a few months yet (if not longer).  So there is time to fix this.
> 
> Sincerely
> Greg 
> 
> Attachments:
>       • Crash1.jpg
>       • Crash1.txt
>       • GNP.zip
>       • LayoutEditor_Simulation.jmri.zip
>       • Panel2.jpg
> 
> 

--
Bob Jacobsen
rgj1927@...








Dave Sand
 

Greg,

The invert for the second turnout works as long as BOTH turnouts specific invert for their partner.  When only one is specified, they both throw each other continuously until the stack overflow occurs.

Dave Sand


----- Original message -----
From: whmvd <vandoornw@...>
Subject: Re: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....
Date: Sunday, May 31, 2020 4:34 PM

Randall,

Yes, I would (though I don't see how the physical damage would occur in my scenario, to be honest, and not in the one you propose) because it is infinitely more defensible. Those users currently having the invert option active (for whatever reason, good or bad, it apparently did something useful for them) would be seriously upset if, without warning, from one release to the next their panels developed malfunctions that are going to be difficult to trace - and fix. I'd expect a process similar to deprecation in code. If they ignore the warnings, then at least they'll have taken the DECISION to ignore them. That sort of method does not, of course, work for those skipping releases, but you can take it only so far.

Wouter

On Sun, 31 May 2020 at 22:17, Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:
It is surprising how easy it is for a user to train themselves to simply click through error or warning messages without reading them. Do you want to deal with a user who gets used to blindly clicking through the message and then mistakes a slightly different message that leads to damage (loss of data in JMRI or physical damage to a model railroad) by clicking through it?

On 31-May-2020, at 17:03, whmvd <vandoornw@...> wrote:

Bob,

Woud it not be considerably more painless to incorporate that message as soon as possible (without further action, just a required 'OK' at most once for every load, while keeping the invert option fully functional or at least as fully as it is now) and only remove the option one production release later? That at least gives people who use it, if any, to make the required change in their own time instead of leaving them in the lurch suddenly.

Wouter

On Sun, 31 May 2020 at 21:48, Bob Jacobsen <rgj1927@...> wrote:
I’ve spent the last few hours creating tests for the inverted option in combination with various feedback implementations in the hardware classes, and tracking how they operate through the code.

It would be very hard to get these to all work for every possible combination. 

Is there anything that “inverted” does in Layout Editor itself that can’t be handled via the inverted option on the jmri.Turnout object itself?

The only thing I can think of would multiple LayoutEditor objects controlling the same Turnout and needing different inverted settings.  But (a) I don’t think that’s possible now, (b) I can’t see how that’s useful and (c) it can be done with routes/logix if needed in some specific case.

Or does is it somehow necessary that signaling or some other upstream use know that here vs in the jmri.Turnout?

If there isn’t, I’d like to remove the option as Too Complicated To Live in the 4.21 series, with a Kind and Gentle message if a file is found to have it set.

Bob

> On May 31, 2020, at 9:08 AM, Dave Sand <ds@...> wrote:
> 
> Greg,
> 
> I have come to the conclusion that "also throw", "inverted" and "feedback" don't like each other. This situation is even more complicated since SW35 itself is defined in the turnout table as Inverted.
> 
> My recommendation is to do the inverting at the hardware level.  Use the LE Continuing Route feature to make the panel image match the layout.
> 
> Dave Sand
> 
> 
> ----- Original message -----
> From: wombat_rrnut <gbedlek001@...>
> Subject: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....
> Date: Sunday, May 31, 2020 10:31 AM
> 
> All:
> 
> I fairly recently downloaded the JMRI source 4.19.7.ish around 5/25/2020 (Not sure the exact date).
> I've been updating my LayoutEditor panel with modifications from the layout changes.  I have a
> crossover that requires a left and a right switch.  So I have to use two switches vs. selecting
> crossover when I create it.
> 
> As I've never used the INVERT checkbox (below), I don't know when this problem
> was introduced.
> 
> If I select "also throw switch" and DO NOT check "Invert", when I (on the panel)
> change either, the other changes fine (of course wrongly since "Invert" not checked).
> See Crash1.jpg attachment for configuration.
> 
> If however, I "also throw switch" with INVERT checked, the first time
> I throw the switch, JMRI crashes with over 1000's lines of output.
> The first line is most instructive:
> 
> 2020-05-31 10:01:39,002 ptionhandler.UncaughtExceptionHandler ERROR - Uncaught Exception caught by jmri.util.exceptionhandler.UncaughtExceptionHandler [AWT-EventQueue-0]
> java.lang.StackOverflowError
> 
> See Crash1.txt for full details....
> 
> 
> I've also attached (I believe) everything you need to reproduce this problem on you own
> machine (GNP.zip and LayoutEditor_Simulation.zip").
> 
> However. in the distribution, I DID NOT tie the two together, in case that helps with the
> debugging.
> 
> The switch being modified is about in the middle on the panel.
> See  "Panel2.jpg" for which switch you should edit and perform
> the Crash1.jpg procedure on it.
> 
> This is for an operating layout, but "luckily" due to Covid-19, I probably won't operate
> this for a few months yet (if not longer).  So there is time to fix this.
> 
> Sincerely
> Greg 
> 
> Attachments:
>       • Crash1.jpg
>       • Crash1.txt
>       • GNP.zip
>       • LayoutEditor_Simulation.jmri.zip
>       • Panel2.jpg
> 
> 

--
Bob Jacobsen









George Warner
 

>When only one is specified, they both throw each other continuously until the stack overflow occurs.

I suspected that this was the case but hadn't the opportunity to confirm it. 

The "fix" in this case should be to test for this condition and if it exist allow the user to ether abort the operation or flip both turnouts to match their invert states.

Note: This same type of overflow could happen with more than two turnouts if there are an odd number of inverts.


Bob Jacobsen
 

You have misunderstood.

As far as I know, nobody is suggesting " without warning, from one release to the next their panels developed malfunctions that are going to be difficult to trace - and fix.”

My original note that proposed removing it _also_ proposed a message to explain what has to be done to fix it should a panel file have the option set. There’s nothing difficult to trace or fix here. Plus, although not everybody reads it, there would also be a discussion in the release note.

Bob

On May 31, 2020, at 2:34 PM, whmvd <@WouterVanDoorn> wrote:

Yes, I would (though I don't see how the physical damage would occur in my scenario, to be honest, and not in the one you propose) because it is infinitely more defensible. Those users currently having the invert option active (for whatever reason, good or bad, it apparently did something useful for them) would be seriously upset if, without warning, from one release to the next their panels developed malfunctions that are going to be difficult to trace - and fix. I'd expect a process similar to deprecation in code. If they ignore the warnings, then at least they'll have taken the DECISION to ignore them. That sort of method does not, of course, work for those skipping releases, but you can take it only so far.
--
Bob Jacobsen
@BobJacobsen


Bob Jacobsen
 

There are also some difficult-to-handle conditions when turnout feedback is in use. I thought that proper use of knownState and commandedState could clean those up, but wan’t able to make that work reliably because events run through the system asynchronously.

Bob

On May 31, 2020, at 3:04 PM, Dave Sand <@davesand> wrote:

Greg,

The invert for the second turnout works as long as BOTH turnouts specific invert for their partner. When only one is specified, they both throw each other continuously until the stack overflow occurs.

Dave Sand


----- Original message -----
From: whmvd <@WouterVanDoorn>
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....
Date: Sunday, May 31, 2020 4:34 PM

Randall,

Yes, I would (though I don't see how the physical damage would occur in my scenario, to be honest, and not in the one you propose) because it is infinitely more defensible. Those users currently having the invert option active (for whatever reason, good or bad, it apparently did something useful for them) would be seriously upset if, without warning, from one release to the next their panels developed malfunctions that are going to be difficult to trace - and fix. I'd expect a process similar to deprecation in code. If they ignore the warnings, then at least they'll have taken the DECISION to ignore them. That sort of method does not, of course, work for those skipping releases, but you can take it only so far.

Wouter

On Sun, 31 May 2020 at 22:17, Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:
It is surprising how easy it is for a user to train themselves to simply click through error or warning messages without reading them. Do you want to deal with a user who gets used to blindly clicking through the message and then mistakes a slightly different message that leads to damage (loss of data in JMRI or physical damage to a model railroad) by clicking through it?

On 31-May-2020, at 17:03, whmvd <@WouterVanDoorn> wrote:

Bob,

Woud it not be considerably more painless to incorporate that message as soon as possible (without further action, just a required 'OK' at most once for every load, while keeping the invert option fully functional or at least as fully as it is now) and only remove the option one production release later? That at least gives people who use it, if any, to make the required change in their own time instead of leaving them in the lurch suddenly.

Wouter

On Sun, 31 May 2020 at 21:48, Bob Jacobsen <@BobJacobsen> wrote:
I’ve spent the last few hours creating tests for the inverted option in combination with various feedback implementations in the hardware classes, and tracking how they operate through the code.

It would be very hard to get these to all work for every possible combination.

Is there anything that “inverted” does in Layout Editor itself that can’t be handled via the inverted option on the jmri.Turnout object itself?

The only thing I can think of would multiple LayoutEditor objects controlling the same Turnout and needing different inverted settings. But (a) I don’t think that’s possible now, (b) I can’t see how that’s useful and (c) it can be done with routes/logix if needed in some specific case.

Or does is it somehow necessary that signaling or some other upstream use know that here vs in the jmri.Turnout?

If there isn’t, I’d like to remove the option as Too Complicated To Live in the 4.21 series, with a Kind and Gentle message if a file is found to have it set.

Bob

On May 31, 2020, at 9:08 AM, Dave Sand <@davesand> wrote:

Greg,

I have come to the conclusion that "also throw", "inverted" and "feedback" don't like each other. This situation is even more complicated since SW35 itself is defined in the turnout table as Inverted.

My recommendation is to do the inverting at the hardware level. Use the LE Continuing Route feature to make the panel image match the layout.

Dave Sand


----- Original message -----
From: wombat_rrnut <gbedlek001@...>
To: jmri@jmri-developers.groups.io
Subject: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....
Date: Sunday, May 31, 2020 10:31 AM

All:

I fairly recently downloaded the JMRI source 4.19.7.ish around 5/25/2020 (Not sure the exact date).
I've been updating my LayoutEditor panel with modifications from the layout changes. I have a
crossover that requires a left and a right switch. So I have to use two switches vs. selecting
crossover when I create it.

As I've never used the INVERT checkbox (below), I don't know when this problem
was introduced.

If I select "also throw switch" and DO NOT check "Invert", when I (on the panel)
change either, the other changes fine (of course wrongly since "Invert" not checked).
See Crash1.jpg attachment for configuration.

If however, I "also throw switch" with INVERT checked, the first time
I throw the switch, JMRI crashes with over 1000's lines of output.
The first line is most instructive:

2020-05-31 10:01:39,002 ptionhandler.UncaughtExceptionHandler ERROR - Uncaught Exception caught by jmri.util.exceptionhandler.UncaughtExceptionHandler [AWT-EventQueue-0]
java.lang.StackOverflowError

See Crash1.txt for full details....


I've also attached (I believe) everything you need to reproduce this problem on you own
machine (GNP.zip and LayoutEditor_Simulation.zip").

However. in the distribution, I DID NOT tie the two together, in case that helps with the
debugging.

The switch being modified is about in the middle on the panel.
See "Panel2.jpg" for which switch you should edit and perform
the Crash1.jpg procedure on it.

This is for an operating layout, but "luckily" due to Covid-19, I probably won't operate
this for a few months yet (if not longer). So there is time to fix this.

Sincerely
Greg

Attachments:
• Crash1.jpg
• Crash1.txt
• GNP.zip
• LayoutEditor_Simulation.jmri.zip
• Panel2.jpg

--
Bob Jacobsen
@BobJacobsen








--
Bob Jacobsen
@BobJacobsen


wombat_rrnut
 

Dave Sand:

 

Good Eyes Dave!  Thank you!

I didn’t realize I had “invert” in the HW (Table->Turnouts) checked also for “Real” turnout LT77/SW35,

And not (of course) for pseudo turnout SW35b/IT:SW335b.

(See attached file TurnoutTable.jpg).

 

George W.: It would take someone like me to “find” it.  If you want to read below “raw” thoughts for why….

 

 

Now for my “raw” (2 cents worth) thoughts about this “situation”:

 

When I built this huge layout around 2003, I didn’t have JMRI in mind at that time

(probably I didn’t even know about it).  So two things were “ignored”: Switch Commanded State and

Switch Feedback.  So wiring the Tortoises (pin 1 and 8, Commanded) were “whatever”,

since I used a pushbutton to “flip” it back and forth (no software, just DS54 and DS64 internal

capabilities).  And as for feedback, if I got it wrong, it was easier to just swap the two

LEDS in the control panel than get under the layout and desolder / solder correctly

(say pins 2 & 3 on the Tortoise).  There are about 100+ “automated” turnouts (like this) on the layout,

of which JMRI (via my CTC software) only cares about 50 or so of them.

If I were CONSISTENT, I would not have done that, but easily correct both issues by (say) using SNAPS!

on a Tortoise.

 

The reason I got so “lazy” was because WAY back in 1992, I build another large “N” scale layout,

in which I ultimately wrote >60K+ lines of C++ to automate it totally in 1993 (similar to JMRI today), with the same

problems of wiring “randomly”.  I decided to at the equivalent level of JMRI’s “Turnouts->Table”, have two

checkboxes to fix the problem: Invert Command and Invert Feedback.  Internally, in my

equivalent JMRI, it was the “low” level driver that did the bit flipping just before sending

the command out on the wire and / or immediately after receiving a feedback message.

At that point, everything was “normalized”, and the rest of my software didn’t even

worry about bit flipping or inverting etc.

 

Now, having said that, I never did distribute my thing-a-ma-bob back in ’93 to see

how people (like me now with your software) would “screw” it up.  So the situation

today probably didn’t occur back then, since my system was more like PanelEditor.

 

I suspect you’ve all thought of this in various forms over all of the intervening years:

I just provide this as “thought processes”, not any answers to any of your discussions.

 

I don’t believe any of you would want to force people to wire things correctly,

ergo your “Invert” in many places to help us “whacko’s”. J :-)

 

However, in the prior version of my JMRI CTC panel, I used PanelEditor instead of LayoutEditor,

and to fix this similar situation, I just reversed the images by editing the .xml file directly,

especially when my “feedback” was backwards.  By doing this, I “simulated” what I did

with my own C++ source code.  I dare say that LayoutEditor is a little more picky, as it

should be.

 

Sincerely

Greg

 

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Dave Sand
Sent: Sunday, May 31, 2020 5:04 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....

 

Greg,

 

The invert for the second turnout works as long as BOTH turnouts specific invert for their partner.  When only one is specified, they both throw each other continuously until the stack overflow occurs.

 

Dave Sand

 

 

----- Original message -----

From: whmvd <vandoornw@...>

Subject: Re: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....

Date: Sunday, May 31, 2020 4:34 PM

 

Randall,

 

Yes, I would (though I don't see how the physical damage would occur in my scenario, to be honest, and not in the one you propose) because it is infinitely more defensible. Those users currently having the invert option active (for whatever reason, good or bad, it apparently did something useful for them) would be seriously upset if, without warning, from one release to the next their panels developed malfunctions that are going to be difficult to trace - and fix. I'd expect a process similar to deprecation in code. If they ignore the warnings, then at least they'll have taken the DECISION to ignore them. That sort of method does not, of course, work for those skipping releases, but you can take it only so far.

 

Wouter

 

On Sun, 31 May 2020 at 22:17, Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:

It is surprising how easy it is for a user to train themselves to simply click through error or warning messages without reading them. Do you want to deal with a user who gets used to blindly clicking through the message and then mistakes a slightly different message that leads to damage (loss of data in JMRI or physical damage to a model railroad) by clicking through it?

 

On 31-May-2020, at 17:03, whmvd <vandoornw@...> wrote:

 

Bob,

 

Woud it not be considerably more painless to incorporate that message as soon as possible (without further action, just a required 'OK' at most once for every load, while keeping the invert option fully functional or at least as fully as it is now) and only remove the option one production release later? That at least gives people who use it, if any, to make the required change in their own time instead of leaving them in the lurch suddenly.

 

Wouter

 

On Sun, 31 May 2020 at 21:48, Bob Jacobsen <rgj1927@...> wrote:

I’ve spent the last few hours creating tests for the inverted option in combination with various feedback implementations in the hardware classes, and tracking how they operate through the code.

 

It would be very hard to get these to all work for every possible combination. 

 

Is there anything that “inverted” does in Layout Editor itself that can’t be handled via the inverted option on the jmri.Turnout object itself?

 

The only thing I can think of would multiple LayoutEditor objects controlling the same Turnout and needing different inverted settings.  But (a) I don’t think that’s possible now, (b) I can’t see how that’s useful and (c) it can be done with routes/logix if needed in some specific case.

 

Or does is it somehow necessary that signaling or some other upstream use know that here vs in the jmri.Turnout?

 

If there isn’t, I’d like to remove the option as Too Complicated To Live in the 4.21 series, with a Kind and Gentle message if a file is found to have it set.

 

Bob

 

> On May 31, 2020, at 9:08 AM, Dave Sand <ds@...> wrote:

> Greg,

> I have come to the conclusion that "also throw", "inverted" and "feedback" don't like each other. This situation is even more complicated since SW35 itself is defined in the turnout table as Inverted.

> My recommendation is to do the inverting at the hardware level.  Use the LE Continuing Route feature to make the panel image match the layout.

> Dave Sand

> ----- Original message -----

> From: wombat_rrnut <gbedlek001@...>

> Subject: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....

> Date: Sunday, May 31, 2020 10:31 AM

> All:

> I fairly recently downloaded the JMRI source 4.19.7.ish around 5/25/2020 (Not sure the exact date).

> I've been updating my LayoutEditor panel with modifications from the layout changes.  I have a

> crossover that requires a left and a right switch.  So I have to use two switches vs. selecting

> crossover when I create it.

> As I've never used the INVERT checkbox (below), I don't know when this problem

> was introduced.

> If I select "also throw switch" and DO NOT check "Invert", when I (on the panel)

> change either, the other changes fine (of course wrongly since "Invert" not checked).

> See Crash1.jpg attachment for configuration.

> If however, I "also throw switch" with INVERT checked, the first time

> I throw the switch, JMRI crashes with over 1000's lines of output.

> The first line is most instructive:

> 2020-05-31 10:01:39,002 ptionhandler.UncaughtExceptionHandler ERROR - Uncaught Exception caught by jmri.util.exceptionhandler.UncaughtExceptionHandler [AWT-EventQueue-0]

> java.lang.StackOverflowError

> See Crash1.txt for full details....

> I've also attached (I believe) everything you need to reproduce this problem on you own

> machine (GNP.zip and LayoutEditor_Simulation.zip").

> However. in the distribution, I DID NOT tie the two together, in case that helps with the

> debugging.

> The switch being modified is about in the middle on the panel.

> See  "Panel2.jpg" for which switch you should edit and perform

> the Crash1.jpg procedure on it.

> This is for an operating layout, but "luckily" due to Covid-19, I probably won't operate

> this for a few months yet (if not longer).  So there is time to fix this.

> Sincerely

> Greg 

> Attachments:

>       • Crash1.jpg

>       • Crash1.txt

>       • GNP.zip

>       • LayoutEditor_Simulation.jmri.zip

>       • Panel2.jpg

 

--

Bob Jacobsen

 

 

 

 

 

 

 

 


wombat_rrnut
 

All:

 

After all I said, I just thought that

“Invert” at the LayoutEditor level

(vs Turnout Table) would just

reverse the image on the screen

(Like I did by reversing the images

in the .xml file in PanelEditor)

and not affect the rest of the system.

That’s what I “assumed”, which I guess

is my bad thinking.

 

Am I not understanding what Invert

does at the LayoutEditor level?

It seems to do more.  A naive question:

Should it?  And to become more

educated: What does it do?

Or should I look at the source code

(if I can find it….)?

 

Greg

 

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of wombat_rrnut
Sent: Sunday, May 31, 2020 8:13 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....

 

Dave Sand:

 

Good Eyes Dave!  Thank you!

I didn’t realize I had “invert” in the HW (Table->Turnouts) checked also for “Real” turnout LT77/SW35,

And not (of course) for pseudo turnout SW35b/IT:SW335b.

(See attached file TurnoutTable.jpg).

 

George W.: It would take someone like me to “find” it.  If you want to read below “raw” thoughts for why….

 

 

Now for my “raw” (2 cents worth) thoughts about this “situation”:

 

When I built this huge layout around 2003, I didn’t have JMRI in mind at that time

(probably I didn’t even know about it).  So two things were “ignored”: Switch Commanded State and

Switch Feedback.  So wiring the Tortoises (pin 1 and 8, Commanded) were “whatever”,

since I used a pushbutton to “flip” it back and forth (no software, just DS54 and DS64 internal

capabilities).  And as for feedback, if I got it wrong, it was easier to just swap the two

LEDS in the control panel than get under the layout and desolder / solder correctly

(say pins 2 & 3 on the Tortoise).  There are about 100+ “automated” turnouts (like this) on the layout,

of which JMRI (via my CTC software) only cares about 50 or so of them.

If I were CONSISTENT, I would not have done that, but easily correct both issues by (say) using SNAPS!

on a Tortoise.

 

The reason I got so “lazy” was because WAY back in 1992, I build another large “N” scale layout,

in which I ultimately wrote >60K+ lines of C++ to automate it totally in 1993 (similar to JMRI today), with the same

problems of wiring “randomly”.  I decided to at the equivalent level of JMRI’s “Turnouts->Table”, have two

checkboxes to fix the problem: Invert Command and Invert Feedback.  Internally, in my

equivalent JMRI, it was the “low” level driver that did the bit flipping just before sending

the command out on the wire and / or immediately after receiving a feedback message.

At that point, everything was “normalized”, and the rest of my software didn’t even

worry about bit flipping or inverting etc.

 

Now, having said that, I never did distribute my thing-a-ma-bob back in ’93 to see

how people (like me now with your software) would “screw” it up.  So the situation

today probably didn’t occur back then, since my system was more like PanelEditor.

 

I suspect you’ve all thought of this in various forms over all of the intervening years:

I just provide this as “thought processes”, not any answers to any of your discussions.

 

I don’t believe any of you would want to force people to wire things correctly,

ergo your “Invert” in many places to help us “whacko’s”. J :-)

 

However, in the prior version of my JMRI CTC panel, I used PanelEditor instead of LayoutEditor,

and to fix this similar situation, I just reversed the images by editing the .xml file directly,

especially when my “feedback” was backwards.  By doing this, I “simulated” what I did

with my own C++ source code.  I dare say that LayoutEditor is a little more picky, as it

should be.

 

Sincerely

Greg

 

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Dave Sand
Sent: Sunday, May 31, 2020 5:04 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....

 

Greg,

 

The invert for the second turnout works as long as BOTH turnouts specific invert for their partner.  When only one is specified, they both throw each other continuously until the stack overflow occurs.

 

Dave Sand

 

 

----- Original message -----

From: whmvd <vandoornw@...>

Subject: Re: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....

Date: Sunday, May 31, 2020 4:34 PM

 

Randall,

 

Yes, I would (though I don't see how the physical damage would occur in my scenario, to be honest, and not in the one you propose) because it is infinitely more defensible. Those users currently having the invert option active (for whatever reason, good or bad, it apparently did something useful for them) would be seriously upset if, without warning, from one release to the next their panels developed malfunctions that are going to be difficult to trace - and fix. I'd expect a process similar to deprecation in code. If they ignore the warnings, then at least they'll have taken the DECISION to ignore them. That sort of method does not, of course, work for those skipping releases, but you can take it only so far.

 

Wouter

 

On Sun, 31 May 2020 at 22:17, Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:

It is surprising how easy it is for a user to train themselves to simply click through error or warning messages without reading them. Do you want to deal with a user who gets used to blindly clicking through the message and then mistakes a slightly different message that leads to damage (loss of data in JMRI or physical damage to a model railroad) by clicking through it?

 

On 31-May-2020, at 17:03, whmvd <vandoornw@...> wrote:

 

Bob,

 

Woud it not be considerably more painless to incorporate that message as soon as possible (without further action, just a required 'OK' at most once for every load, while keeping the invert option fully functional or at least as fully as it is now) and only remove the option one production release later? That at least gives people who use it, if any, to make the required change in their own time instead of leaving them in the lurch suddenly.

 

Wouter

 

On Sun, 31 May 2020 at 21:48, Bob Jacobsen <rgj1927@...> wrote:

I’ve spent the last few hours creating tests for the inverted option in combination with various feedback implementations in the hardware classes, and tracking how they operate through the code.

 

It would be very hard to get these to all work for every possible combination. 

 

Is there anything that “inverted” does in Layout Editor itself that can’t be handled via the inverted option on the jmri.Turnout object itself?

 

The only thing I can think of would multiple LayoutEditor objects controlling the same Turnout and needing different inverted settings.  But (a) I don’t think that’s possible now, (b) I can’t see how that’s useful and (c) it can be done with routes/logix if needed in some specific case.

 

Or does is it somehow necessary that signaling or some other upstream use know that here vs in the jmri.Turnout?

 

If there isn’t, I’d like to remove the option as Too Complicated To Live in the 4.21 series, with a Kind and Gentle message if a file is found to have it set.

 

Bob

 

> On May 31, 2020, at 9:08 AM, Dave Sand <ds@...> wrote:

> Greg,

> I have come to the conclusion that "also throw", "inverted" and "feedback" don't like each other. This situation is even more complicated since SW35 itself is defined in the turnout table as Inverted.

> My recommendation is to do the inverting at the hardware level.  Use the LE Continuing Route feature to make the panel image match the layout.

> Dave Sand

> ----- Original message -----

> From: wombat_rrnut <gbedlek001@...>

> Subject: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....

> Date: Sunday, May 31, 2020 10:31 AM

> All:

> I fairly recently downloaded the JMRI source 4.19.7.ish around 5/25/2020 (Not sure the exact date).

> I've been updating my LayoutEditor panel with modifications from the layout changes.  I have a

> crossover that requires a left and a right switch.  So I have to use two switches vs. selecting

> crossover when I create it.

> As I've never used the INVERT checkbox (below), I don't know when this problem

> was introduced.

> If I select "also throw switch" and DO NOT check "Invert", when I (on the panel)

> change either, the other changes fine (of course wrongly since "Invert" not checked).

> See Crash1.jpg attachment for configuration.

> If however, I "also throw switch" with INVERT checked, the first time

> I throw the switch, JMRI crashes with over 1000's lines of output.

> The first line is most instructive:

> 2020-05-31 10:01:39,002 ptionhandler.UncaughtExceptionHandler ERROR - Uncaught Exception caught by jmri.util.exceptionhandler.UncaughtExceptionHandler [AWT-EventQueue-0]

> java.lang.StackOverflowError

> See Crash1.txt for full details....

> I've also attached (I believe) everything you need to reproduce this problem on you own

> machine (GNP.zip and LayoutEditor_Simulation.zip").

> However. in the distribution, I DID NOT tie the two together, in case that helps with the

> debugging.

> The switch being modified is about in the middle on the panel.

> See  "Panel2.jpg" for which switch you should edit and perform

> the Crash1.jpg procedure on it.

> This is for an operating layout, but "luckily" due to Covid-19, I probably won't operate

> this for a few months yet (if not longer).  So there is time to fix this.

> Sincerely

> Greg 

> Attachments:

>       • Crash1.jpg

>       • Crash1.txt

>       • GNP.zip

>       • LayoutEditor_Simulation.jmri.zip

>       • Panel2.jpg

 

--

Bob Jacobsen

 

 

 

 

 

 

 

 


Dave Sand
 

Greg,

Similar to substituting icons on panel editor, for layout editor use the "Continuing Route". feature.  All that does is draw the turnout legs flipped when Thrown is selected.  For that approach, do not specify inverted with the also throw turnout option.

So you have two options.  Invert both on the edit screen or neither and use the continuing route.  The turnout table entries are not affected with either approach.

Dave Sand


----- Original message -----
From: wombat_rrnut <gbedlek001@...>
Subject: Re: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....
Date: Sunday, May 31, 2020 8:22 PM

All:

 

After all I said, I just thought that

“Invert” at the LayoutEditor level

(vs Turnout Table) would just

reverse the image on the screen

(Like I did by reversing the images

in the .xml file in PanelEditor)

and not affect the rest of the system.

That’s what I “assumed”, which I guess

is my bad thinking.

 

Am I not understanding what Invert

does at the LayoutEditor level?

It seems to do more.  A naive question:

Should it?  And to become more

educated: What does it do?

Or should I look at the source code

(if I can find it….)?

 

Greg

 

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of wombat_rrnut
Sent: Sunday, May 31, 2020 8:13 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....

 

Dave Sand:

 

Good Eyes Dave!  Thank you!

I didn’t realize I had “invert” in the HW (Table->Turnouts) checked also for “Real” turnout LT77/SW35,

And not (of course) for pseudo turnout SW35b/IT:SW335b.

(See attached file TurnoutTable.jpg).

 

George W.: It would take someone like me to “find” it.  If you want to read below “raw” thoughts for why….

 

 

Now for my “raw” (2 cents worth) thoughts about this “situation”:

 

When I built this huge layout around 2003, I didn’t have JMRI in mind at that time

(probably I didn’t even know about it).  So two things were “ignored”: Switch Commanded State and

Switch Feedback.  So wiring the Tortoises (pin 1 and 8, Commanded) were “whatever”,

since I used a pushbutton to “flip” it back and forth (no software, just DS54 and DS64 internal

capabilities).  And as for feedback, if I got it wrong, it was easier to just swap the two

LEDS in the control panel than get under the layout and desolder / solder correctly

(say pins 2 & 3 on the Tortoise).  There are about 100+ “automated” turnouts (like this) on the layout,

of which JMRI (via my CTC software) only cares about 50 or so of them.

If I were CONSISTENT, I would not have done that, but easily correct both issues by (say) using SNAPS!

on a Tortoise.

 

The reason I got so “lazy” was because WAY back in 1992, I build another large “N” scale layout,

in which I ultimately wrote >60K+ lines of C++ to automate it totally in 1993 (similar to JMRI today), with the same

problems of wiring “randomly”.  I decided to at the equivalent level of JMRI’s “Turnouts->Table”, have two

checkboxes to fix the problem: Invert Command and Invert Feedback.  Internally, in my

equivalent JMRI, it was the “low” level driver that did the bit flipping just before sending

the command out on the wire and / or immediately after receiving a feedback message.

At that point, everything was “normalized”, and the rest of my software didn’t even

worry about bit flipping or inverting etc.

 

Now, having said that, I never did distribute my thing-a-ma-bob back in ’93 to see

how people (like me now with your software) would “screw” it up.  So the situation

today probably didn’t occur back then, since my system was more like PanelEditor.

 

I suspect you’ve all thought of this in various forms over all of the intervening years:

I just provide this as “thought processes”, not any answers to any of your discussions.

 

I don’t believe any of you would want to force people to wire things correctly,

ergo your “Invert” in many places to help us “whacko’s”. J :-)

 

However, in the prior version of my JMRI CTC panel, I used PanelEditor instead of LayoutEditor,

and to fix this similar situation, I just reversed the images by editing the .xml file directly,

especially when my “feedback” was backwards.  By doing this, I “simulated” what I did

with my own C++ source code.  I dare say that LayoutEditor is a little more picky, as it

should be.

 

Sincerely

Greg

 

 

 

From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Dave Sand
Sent: Sunday, May 31, 2020 5:04 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....

 

Greg,

 

The invert for the second turnout works as long as BOTH turnouts specific invert for their partner.  When only one is specified, they both throw each other continuously until the stack overflow occurs.

 

Dave Sand

 

 

----- Original message -----

From: whmvd <vandoornw@...>

Subject: Re: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....

Date: Sunday, May 31, 2020 4:34 PM

 

Randall,

 

Yes, I would (though I don't see how the physical damage would occur in my scenario, to be honest, and not in the one you propose) because it is infinitely more defensible. Those users currently having the invert option active (for whatever reason, good or bad, it apparently did something useful for them) would be seriously upset if, without warning, from one release to the next their panels developed malfunctions that are going to be difficult to trace - and fix. I'd expect a process similar to deprecation in code. If they ignore the warnings, then at least they'll have taken the DECISION to ignore them. That sort of method does not, of course, work for those skipping releases, but you can take it only so far.

 

Wouter

 

On Sun, 31 May 2020 at 22:17, Randall Wood via groups.io <rhwood=mac.com@groups.io> wrote:

It is surprising how easy it is for a user to train themselves to simply click through error or warning messages without reading them. Do you want to deal with a user who gets used to blindly clicking through the message and then mistakes a slightly different message that leads to damage (loss of data in JMRI or physical damage to a model railroad) by clicking through it?

 

On 31-May-2020, at 17:03, whmvd <vandoornw@...> wrote:

 

Bob,

 

Woud it not be considerably more painless to incorporate that message as soon as possible (without further action, just a required 'OK' at most once for every load, while keeping the invert option fully functional or at least as fully as it is now) and only remove the option one production release later? That at least gives people who use it, if any, to make the required change in their own time instead of leaving them in the lurch suddenly.

 

Wouter

 

On Sun, 31 May 2020 at 21:48, Bob Jacobsen <rgj1927@...> wrote:

I’ve spent the last few hours creating tests for the inverted option in combination with various feedback implementations in the hardware classes, and tracking how they operate through the code.

 

It would be very hard to get these to all work for every possible combination. 

 

Is there anything that “inverted” does in Layout Editor itself that can’t be handled via the inverted option on the jmri.Turnout object itself?

 

The only thing I can think of would multiple LayoutEditor objects controlling the same Turnout and needing different inverted settings.  But (a) I don’t think that’s possible now, (b) I can’t see how that’s useful and (c) it can be done with routes/logix if needed in some specific case.

 

Or does is it somehow necessary that signaling or some other upstream use know that here vs in the jmri.Turnout?

 

If there isn’t, I’d like to remove the option as Too Complicated To Live in the 4.21 series, with a Kind and Gentle message if a file is found to have it set.

 

Bob

 

> On May 31, 2020, at 9:08 AM, Dave Sand <ds@...> wrote:


> Greg,


> I have come to the conclusion that "also throw", "inverted" and "feedback" don't like each other. This situation is even more complicated since SW35 itself is defined in the turnout table as Inverted.


> My recommendation is to do the inverting at the hardware level.  Use the LE Continuing Route feature to make the panel image match the layout.


> Dave Sand



> ----- Original message -----

> From: wombat_rrnut <gbedlek001@...>

> Subject: [jmri-developers] Serious Crash of fairly latest source code 4.19.7.ish.....

> Date: Sunday, May 31, 2020 10:31 AM


> All:


> I fairly recently downloaded the JMRI source 4.19.7.ish around 5/25/2020 (Not sure the exact date).

> I've been updating my LayoutEditor panel with modifications from the layout changes.  I have a

> crossover that requires a left and a right switch.  So I have to use two switches vs. selecting

> crossover when I create it.


> As I've never used the INVERT checkbox (below), I don't know when this problem

> was introduced.


> If I select "also throw switch" and DO NOT check "Invert", when I (on the panel)

> change either, the other changes fine (of course wrongly since "Invert" not checked).

> See Crash1.jpg attachment for configuration.


> If however, I "also throw switch" with INVERT checked, the first time

> I throw the switch, JMRI crashes with over 1000's lines of output.

> The first line is most instructive:


> 2020-05-31 10:01:39,002 ptionhandler.UncaughtExceptionHandler ERROR - Uncaught Exception caught by jmri.util.exceptionhandler.UncaughtExceptionHandler [AWT-EventQueue-0]

> java.lang.StackOverflowError


> See Crash1.txt for full details....



> I've also attached (I believe) everything you need to reproduce this problem on you own

> machine (GNP.zip and LayoutEditor_Simulation.zip").


> However. in the distribution, I DID NOT tie the two together, in case that helps with the

> debugging.


> The switch being modified is about in the middle on the panel.

> See  "Panel2.jpg" for which switch you should edit and perform

> the Crash1.jpg procedure on it.


> This is for an operating layout, but "luckily" due to Covid-19, I probably won't operate

> this for a few months yet (if not longer).  So there is time to fix this.


> Sincerely

> Greg 


> Attachments:

>       • Crash1.jpg

>       • Crash1.txt

>       • GNP.zip

>       • LayoutEditor_Simulation.jmri.zip

>       • Panel2.jpg



 

--

Bob Jacobsen

 

 

 

 

 

 

 

 




Ken Cameron
 

I would agree with Greg that the concept of invert in LE (or other editors)
would be simply the icon used for the display. Same effect would be swapping
the icons in CPE/PE. Since there is also the 'continuing route' option, I
would say picking invert doesn't change the concept of the normal route, you
have to pick another option to change the concept of normal route.

The issue that LE has on this is that it is doing more than just drawing
something on the screen. It is building other details for things like normal
or diverging for the speed options and I think that's where the invert was
going down the rabbit hole. The upshot may mean more options so the user can
be explicit on what they are doing or we being more educational on when you
would invert at the sensor, turnout, or editor levels and if the 'right
thing' is doing certain things at certain levels, it just becomes
educational to correct. Downside will be that whatever we do to get out of
the loop, some existing layouts may be impacted. A query against all the
panels we've every collected to look for the us of that invert in the editor
might show us just how few might be impacted.

But I also agree with Bob that sometimes there are ideas that are very hard
to make right. The number of panels I've had to debug that trace to improper
use of the invert either in sensors or turnouts (most problems with
turnouts) is considerable. His plan for making the visual part separate from
the layout information side is the right direction.

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


George Warner
 

Invert with the "also throw turnout" option has nothing to do with inverted turnout commands or status.

The point of the "also throw turnout" option is to have one turnouts state change effect a second turnouts state.

Initially there wasn't an invert option; when turnout #1's state became thrown then turnout #2 would be thrown (and likewise for closed/closed). IOW: turnout #1's state was forwarded exactly to turnout #2.

At some point a user requested that they be able to send the inverted state to the 2nd turnout and that feature was added. IOW: When turnout #1 became thrown then turnout #2 would be closed; #1 closed -> #2 thrown..

Still not a problem unless a loop is setup where turnout #1 sets turnout #2 AND turnout #2 sets turnout #1 inverted. In this case #1 closing sets #2 closed which sets #1 open which sets #2 open which sets #1 closed… and you have an infinite loop.

Just as a side: Why does checking the checkbox effect the layout in any way? IMHO: The "also throw turnout" checkbox should only change if this option is enabled or not. The actual state forwarding shouldn't happen until the 1st turnouts state changes.
The only problem with this is that it will defer the infinite loop (stack overflow) situation to runtime when the state of ether turnout changes.

The optimum solution (IMHO) is to detect the infinite loop condition at checkbox select time and give the user the option to ether abort the invert OR apply it to both turnouts.