¿ªÔÆÌåÓý

  1. Jmriusers
  2. Topics

Locked Does the order of elements in JMRI's panel files matter to you?

 

Originally, JMRI did not preserve the order of elements when writing its XML panel files. The order of turnout definitions could and did change when you loaded and stored a file.

By user request, pretty early on, that was changed to make an effort (but not guarantee!) that the order would be preserved from one store to another. The code to do this was complicated, and there were various things that could cause an item to be written in a different order, but it basically worked.

But does anybody really care?

It would simplify the code, and significantly speed up certain operations, if we stopped trying to maintain the load-by order. In that case, elements (turnouts, sensors, etc) would be written into the file in order by system name.

This seems like a reasonable change to me. JMRI isn¡¯t a word processor: the panel files are a record of JMRI¡¯s internal state, not a document that¡¯s being written. Having that record be in the order that JMRI maintains internally is a simplification. (For a while, JMRI has maintained its internal lists in order by system name to speed up access in tables, etc)

But perhaps this would cause a significant problem for some use case. Maybe somebody has another app that needs a particular order in files from JMRI?

If this would be a problem for you, please let me know how and why. Otherwise, we¡¯ll likely make this change in the current set of test releases.

Thanks!

Bob
--
Bob Jacobsen
rgj1927@...
 

I don't really care.

You can take the lack of response as either people don't care or it's the long weekend and few are watching emails or the list website.

--
Peter Ulvestad

JMRI Users Group Moderator - ( )
Tam Valley Group Moderator - ( )
Sprog-DCC Group Moderator - ( )
Edmonton Model Railroad Association -

 

I think I¡¯ll wait a few more days before deciding that nobody needs that order to be preserved, just in case people are staying off email over the long weekend in the US. (Which is probably a good idea!)

Bob

On Sep 2, 2019, at 11:23 AM, Peter Ulvestad <ulvestad@...> wrote:

You can take the lack of response as either people don't care or it's the long weekend and few are watching emails or the list website.
--
Bob Jacobsen
rgj1927@...
 

Whenever I had to do with xml design, I made very certain that any required ordering was enforced in the xml content, and not in the order the xml happened to be in. Which means that there were attributes like 'sequence_no=<integer>' in there. I still think that's the preferred option. It makes the whole thing a lot robuster when anyone decides to use an external tool that - rightly or wrongly, though I think rightly - does not care about element ordering (xml by itself is unordered). Explicit ordering is the way to go!

A new release introducing those attributes could easily be made to read the input in file-order and create the new attributes on the fly.

Wouter


On Mon, 2 Sep 2019 at 20:03, Bob Jacobsen <rgj1927@...> wrote:
I think I¡¯ll wait a few more days before deciding that nobody needs that order to be preserved, just in case people are staying off email over the long weekend in the US. (Which is probably a good idea!)

Bob

> On Sep 2, 2019, at 11:23 AM, Peter Ulvestad <ulvestad@...> wrote:
>
> You can take the lack of response as either people don't care or it's the long weekend and few are watching emails or the list website.

--
Bob Jacobsen
rgj1927@...
 

I don't know if it applies to panel files, but in general please try to
keep files the same if they stay the same. Makes working with version
control systems so much easier if you can find the changes and don't
have to sift through a hundred unrelated ordering changes to find a
single actual change.

Second best option would be a single big change once, worst would be
random order, changing on every save.

As I started this eMail, I don't know if this applies to panel files,
aka if anyone actually uses git/svn/choose your pick to work with them.

Just my two cents (€),
Heiko

On 9/2/19 9:19 PM, whmvd wrote:
Whenever I had to do with xml design, I made very certain that any
required ordering was enforced in the xml content, and not in the order
the xml happened to be in. Which means that there were attributes like
'sequence_no=<integer>' in there. I still think that's the preferred
option. It makes the whole thing a lot robuster when anyone decides to
use an external tool that - rightly or wrongly, though I think rightly -
does not care about element ordering (xml by itself is unordered).
Explicit ordering is the way to go!

A new release introducing those attributes could easily be made to read
the input in file-order and create the new attributes on the fly.

Wouter

On Mon, 2 Sep 2019 at 20:03, Bob Jacobsen <rgj1927@...
<mailto:rgj1927@...>> wrote:

I think I¡¯ll wait a few more days before deciding that nobody needs
that order to be preserved, just in case people are staying off
email over the long weekend in the US. (Which is probably a good idea!)

Bob

> On Sep 2, 2019, at 11:23 AM, Peter Ulvestad <ulvestad@...
<mailto:ulvestad@...>> wrote:
>
> You can take the lack of response as either people don't care or
it's the long weekend and few are watching emails or the list website.

--
Bob Jacobsen
rgj1927@... <mailto:rgj1927@...>






--
eMails verschl¨¹sseln mit PGP - privacy is your right!
Mein PGP-Key zur Verifizierung:

 

By design, the order of elements within a type doesn¡¯t matter to JMRI. That¡¯s why we can switch from the current ¡°whatever order we¡¯ve found¡± to writing them in the order they¡¯re held internally.

Bob

On Sep 2, 2019, at 12:19 PM, whmvd <vandoornw@...> wrote:

Whenever I had to do with xml design, I made very certain that any required ordering was enforced in the xml content, and not in the order the xml happened to be in. Which means that there were attributes like 'sequence_no=<integer>' in there. I still think that's the preferred option. It makes the whole thing a lot robuster when anyone decides to use an external tool that - rightly or wrongly, though I think rightly - does not care about element ordering (xml by itself is unordered). Explicit ordering is the way to go!

A new release introducing those attributes could easily be made to read the input in file-order and create the new attributes on the fly.

Wouter
--
Bob Jacobsen
rgj1927@...
 

There¡¯s one local layout that I configure via files stored on GitHub (). I like the way that lets me control exactly what¡¯s going to be used for e.g. an operating session while I¡¯m working on something else.

The current code for writing panel files is an imperfect hybrid. It¡¯ll preserve the order from one load-store cycle to the next _unless_ items were added and/or deleted. Then, depending on exactly what was done, some reordering can happen.

The proposed new approach, writing in system name order, would be One Big Change the first time the file was stored with an updated JMRI version. After that, it should be much more stable against arbitrary ordering changes.

Bob


On Sep 2, 2019, at 12:40 PM, Heiko Rosemann <heiko.rosemann@...> wrote:

I don't know if it applies to panel files, but in general please try to
keep files the same if they stay the same. Makes working with version
control systems so much easier if you can find the changes and don't
have to sift through a hundred unrelated ordering changes to find a
single actual change.

Second best option would be a single big change once, worst would be
random order, changing on every save.

As I started this eMail, I don't know if this applies to panel files,
aka if anyone actually uses git/svn/choose your pick to work with them.

Just my two cents (€),
Heiko
--
Bob Jacobsen
rgj1927@...
 

My panel file is large enough, I occasionally have to diff things, to figure out what changed, and when something went wrong (I lose signal mast logic for unknown reasons) . The current model, as noted seems to change order if add something. It sounds like the new idea would make diffs much easier to see what was addred/subtracted, so I'm for it.



On Mon, Sep 2, 2019 at 8:35 PM Bob Jacobsen <rgj1927@...> wrote:
There¡¯s one local layout that I configure via files stored on GitHub (). I like the way that lets me control exactly what¡¯s going to be used for e.g. an operating session while I¡¯m working on something else.

The current code for writing panel files is an imperfect hybrid.? It¡¯ll preserve the order from one load-store cycle to the next _unless_ items were added and/or deleted.? Then, depending on exactly what was done, some reordering can happen.

The proposed new approach, writing in system name order, would be One Big Change the first time the file was stored with an updated JMRI version.? After that, it should be much more stable against arbitrary ordering changes.

Bob


> On Sep 2, 2019, at 12:40 PM, Heiko Rosemann <heiko.rosemann@...> wrote:
>
> I don't know if it applies to panel files, but in general please try to
> keep files the same if they stay the same. Makes working with version
> control systems so much easier if you can find the changes and don't
> have to sift through a hundred unrelated ordering changes to find a
> single actual change.
>
> Second best option would be a single big change once, worst would be
> random order, changing on every save.
>
> As I started this eMail, I don't know if this applies to panel files,
> aka if anyone actually uses git/svn/choose your pick to work with them.
>
> Just my two cents (€),
> Heiko
>

--
Bob Jacobsen
rgj1927@...

1 - 8 of 8