开云体育

On Jun 21, 2017, at 12:11, Jan Boen jan.boen@... [jmriusers] <jmriusers@...> wrote:

Hi all,

According to IOBit Malware Fighter JMRI contains a backdoor trojan in
the following file "...&#92;JMRI/&#92;lib&#92;x64&#92;intelbth_x64.dll" on PC.
JMRI version for PC 4.6-R81496dc

Is this a legitimate problem or to be ignored?

Thanks,

Jan

Paul

I was able to try the changes you made yesterday and in limited testing the
throttle worked well, i had no engine control problems the function keys
worked as they should. Programming still is working fine.Happy to see the
changes are effective in a straight Z21 setup.

Thanks for your efforts

Bill Lang

Bob,
To give people some idea of how large the JMRI program is could you tell us how many lines of code there are ?
Don

On Jun 23, 2017, at 7:01 PM, Bob Jacobsen rgj1927@... [jmriusers] <jmriusers@...> wrote:


On Jun 22, 2017, at 2:55 AM, leo pesce lpescester@... <mailto:lpescester@...> [jmriusers] <jmriusers@... <mailto:jmriusers@...>> wrote:

First apologies for my tirade about the new version. I could have been more
tactful.

Thanks.

But I’d like to address, again, a misapprehension you have, and perhaps others have:

On Jun 20, 2017, at 9:39 AM, leo pesce lpescester@... <mailto:lpescester@...> [jmriusers] <jmriusers@... <mailto:jmriusers@...>> wrote:

I wish there was a better attention to detail when it comes to "whatever"
releases, ie. releasing versions that "break" a lot of stuff, in the
attempt to fix or improve something else.

We run _tens_ _of_ _thousands_ of tests on every release. The most recent release, for example, ran over 28,000 tests. Those were repeated on macOS, Windows and Linux; with and without attached screens; they include reading and checking over 150 different XML files from different JMRI versions with different panel configurations. We run these _every_ _time_ somebody proposes a change to the code. We also run tests on the results after each update to the code, not just on test releases. Many people have put huge effort into making making this automatic, and making sure that any problems found are fixed.

But clearly problems do sneak through. In large part, that’s why we have test releases.

Clearly, you think that “the developers” should do better so that test releases are perfect. But for large parts of JMRI, “the developers” is a misnomer: large parts of JMRI have _one_ person working on them. (Some have nobody working on them anymore, but they tend to not change hence not break)

Sometimes that person is really interested in code testing. Dan Boudreau, who’s written greater than 99% of the Operations code, is that way. There are hundreds of tests in that area to make sure that problems don’t get into test releases. The update I’m currently working on in the CTC area has more new lines in the tests than in the actual code. Several people who work on JMRI even write some of their tests before they write the code itself!

But not everybody is that way. Some features, like the NX Warrants you mentioned, have just one person working on it, and that person’s style is to spend most of their time on code changes. Sometimes, those changes break things away from the part that’s being worked on. With automated pre-written tests you can see that and fix them before the code goes out; without those, problems away from where the work is being done might not get noticed until users encounter them later in a release.

Note: it’s _absolutely_ _OK_ for people to work on JMRI code that way, because without encouraging & enabling that person to work in the style they find most efficient, you would never have had the feature in the first place.

But this means that we’ve only got about 1/3 of the code tested automatically.

So what to do? Test releases are created so people can contribute to JMRI by _testing_ them. And, when those tests find things, often/usually somebody will dig in and fix them.

So I agree with you that we need to pay “better attention to detail”. But the “we” in that sentence _specifically_ _includes_ _you_. When a test release comes out, _test_ the features you consider important. Do it in a safe environment, so you don’t have to "restage 35 trains manually”. Then, if you find something wrong, make a positive comment and help anybody who _volunteers_ to fix it.

Or even better: Provide some automated tests of the features that you think aren’t being tested enough before release.

It’s up to you. If you want to be able to use new features in JMRI, get involved in testing related changes as JMRI evolves so that production releases are clean. Or expect that you’ll be sticking with something that doesn’t have new features. Either approach should work pretty well.

Or you could stick with the misapprehension that you should never see a problem in a test release because “this here is cupcakes”. To me, that approach seems destined to make you repeatedly unhappy, but I guess everybody gets to pick their own hobby...

Bob

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

------------------------------------
Posted by: Donald Perla <donperla@...>
------------------------------------
------------------------------------
Yahoo Groups Links

On Jun 22, 2017, at 2:55 AM, leo pesce lpescester@... [jmriusers] <
jmriusers@...> wrote:

First apologies for my tirade about the new version. I could have been

more

tactful.

Thanks.

But I’d like to address, again, a misapprehension you have, and perhaps
others have:

On Jun 20, 2017, at 9:39 AM, leo pesce lpescester@... [jmriusers] <
jmriusers@...> wrote:

I wish there was a better attention to detail when it comes to "whatever"
releases, ie. releasing versions that "break" a lot of stuff, in the
attempt to fix or improve something else.

We run _tens_ _of_ _thousands_ of tests on every release. The most recent
release, for example, ran over 28,000 tests. Those were repeated on macOS,
Windows and Linux; with and without attached screens; they include reading
and checking over 150 different XML files from different JMRI versions with
different panel configurations. We run these _every_ _time_ somebody
proposes a change to the code. We also run tests on the results after each
update to the code, not just on test releases. Many people have put huge
effort into making making this automatic, and making sure that any problems
found are fixed.

But clearly problems do sneak through. In large part, that’s why we have
test releases.

Clearly, you think that “the developers” should do better so that test
releases are perfect. But for large parts of JMRI, “the developers” is a
misnomer: large parts of JMRI have _one_ person working on them. (Some have
nobody working on them anymore, but they tend to not change hence not break)

Sometimes that person is really interested in code testing. Dan Boudreau,
who’s written greater than 99% of the Operations code, is that way. There
are hundreds of tests in that area to make sure that problems don’t get
into test releases. The update I’m currently working on in the CTC area has
more new lines in the tests than in the actual code. Several people who
work on JMRI even write some of their tests before they write the code
itself!

But not everybody is that way. Some features, like the NX Warrants you
mentioned, have just one person working on it, and that person’s style is
to spend most of their time on code changes. Sometimes, those changes break
things away from the part that’s being worked on. With automated
pre-written tests you can see that and fix them before the code goes out;
without those, problems away from where the work is being done might not
get noticed until users encounter them later in a release.

Note: it’s _absolutely_ _OK_ for people to work on JMRI code that way,
because without encouraging & enabling that person to work in the style
they find most efficient, you would never have had the feature in the first
place.

But this means that we’ve only got about 1/3 of the code tested
automatically.

So what to do? Test releases are created so people can contribute to JMRI
by _testing_ them. And, when those tests find things, often/usually
somebody will dig in and fix them.

So I agree with you that we need to pay “better attention to detail”. But
the “we” in that sentence _specifically_ _includes_ _you_. When a test
release comes out, _test_ the features you consider important. Do it in a
safe environment, so you don’t have to "restage 35 trains manually”. Then,
if you find something wrong, make a positive comment and help anybody who
_volunteers_ to fix it.

Or even better: Provide some automated tests of the features that you
think aren’t being tested enough before release.

It’s up to you. If you want to be able to use new features in JMRI, get
involved in testing related changes as JMRI evolves so that production
releases are clean. Or expect that you’ll be sticking with something that
doesn’t have new features. Either approach should work pretty well.

Or you could stick with the misapprehension that you should never see a
problem in a test release because “this here is cupcakes”. To me, that
approach seems destined to make you repeatedly unhappy, but I guess
everybody gets to pick their own hobby...

Bob

--
Bob Jacobsen
rgj1927@...

On Jun 23, 2017, at 7:01 PM, Bob Jacobsen rgj1927@... [jmriusers] <jmriusers@...> wrote:


On Jun 22, 2017, at 2:55 AM, leo pesce lpescester@... <mailto:lpescester@...> [jmriusers] <jmriusers@... <mailto:jmriusers@...>> wrote:

First apologies for my tirade about the new version. I could have been more
tactful.

Thanks.

But I’d like to address, again, a misapprehension you have, and perhaps others have:

On Jun 20, 2017, at 9:39 AM, leo pesce lpescester@... <mailto:lpescester@...> [jmriusers] <jmriusers@... <mailto:jmriusers@...>> wrote:

I wish there was a better attention to detail when it comes to "whatever"
releases, ie. releasing versions that "break" a lot of stuff, in the
attempt to fix or improve something else.

We run _tens_ _of_ _thousands_ of tests on every release. The most recent release, for example, ran over 28,000 tests. Those were repeated on macOS, Windows and Linux; with and without attached screens; they include reading and checking over 150 different XML files from different JMRI versions with different panel configurations. We run these _every_ _time_ somebody proposes a change to the code. We also run tests on the results after each update to the code, not just on test releases. Many people have put huge effort into making making this automatic, and making sure that any problems found are fixed.

But clearly problems do sneak through. In large part, that’s why we have test releases.

Clearly, you think that “the developers” should do better so that test releases are perfect. But for large parts of JMRI, “the developers” is a misnomer: large parts of JMRI have _one_ person working on them. (Some have nobody working on them anymore, but they tend to not change hence not break)

Sometimes that person is really interested in code testing. Dan Boudreau, who’s written greater than 99% of the Operations code, is that way. There are hundreds of tests in that area to make sure that problems don’t get into test releases. The update I’m currently working on in the CTC area has more new lines in the tests than in the actual code. Several people who work on JMRI even write some of their tests before they write the code itself!

But not everybody is that way. Some features, like the NX Warrants you mentioned, have just one person working on it, and that person’s style is to spend most of their time on code changes. Sometimes, those changes break things away from the part that’s being worked on. With automated pre-written tests you can see that and fix them before the code goes out; without those, problems away from where the work is being done might not get noticed until users encounter them later in a release.

Note: it’s _absolutely_ _OK_ for people to work on JMRI code that way, because without encouraging & enabling that person to work in the style they find most efficient, you would never have had the feature in the first place.

But this means that we’ve only got about 1/3 of the code tested automatically.

So what to do? Test releases are created so people can contribute to JMRI by _testing_ them. And, when those tests find things, often/usually somebody will dig in and fix them.

So I agree with you that we need to pay “better attention to detail”. But the “we” in that sentence _specifically_ _includes_ _you_. When a test release comes out, _test_ the features you consider important. Do it in a safe environment, so you don’t have to "restage 35 trains manually”. Then, if you find something wrong, make a positive comment and help anybody who _volunteers_ to fix it.

Or even better: Provide some automated tests of the features that you think aren’t being tested enough before release.

It’s up to you. If you want to be able to use new features in JMRI, get involved in testing related changes as JMRI evolves so that production releases are clean. Or expect that you’ll be sticking with something that doesn’t have new features. Either approach should work pretty well.

Or you could stick with the misapprehension that you should never see a problem in a test release because “this here is cupcakes”. To me, that approach seems destined to make you repeatedly unhappy, but I guess everybody gets to pick their own hobby...

Bob

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

On 22 Jun 2017, at 11:35 AM, s.w.yount@... [jmriusers] <jmriusers@...> wrote:

I have a 4.2.1. JMRI and I am having problems programming CVs 200 - 500 . I have a NCE PowerPro system (not a Power Cab). What do I need to do to get these CVs programmed?

On 22 Jun 2017, at 11:35 AM, s.w.yount@... [jmriusers] <jmriusers@...> wrote:

I have a 4.2.1. JMRI and I am having problems programming CVs 200 - 500 . I have a NCE PowerPro system (not a Power Cab). What do I need to do to get these CVs programmed?