Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

2019-06-20 Thread Eric Barnhill 
>
> > If additional context is required it fails to meet the definition of
> > a unit test and is instead an integration test,  and the function being
> > tested may require rethinking.
>
> Depends what you define as a unit test. I'd say the unit was BigFraction
> or Fraction. An integration test is something that must be tested with
> coherant components working together to provide functionality. You are
> not doing that.
>

Well, I totally agree with both of you that this is the superior approach
for architecture and maintainability. Maybe I should think about adding a
bit more setup to my own unit tests.

I think it is not quite right to say that Fraction is the unit. I think
unit tests test atomic behaviors in the code that ideally can only fail one
way; those are the units. But this is just semantics.

So if you are both in agreement I can change to a +1.

Re: Re: Re: Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

2019-06-20 Thread Heinrich Bohne 

By the way, I've worked a bit on the draft in the meantime and pushed
the changes I've made so far, in case anyone is interested in
(re-)viewing them. Here's the link to the branch again:
https://github.com/Schamschi/commons-numbers/tree/FractionCommonTestCases

On 6/20/19 6:13 PM, Heinrich Bohne wrote:

Hello Eric,

I'm not sure if I understand what you mean by "context" when you say
that all context has to be within the unit test.Do you mean that the
test should not rely on the functionality of other
modules/methods/"units" than the one to be tested? If so, I agree with
you, but I don't think that this would be the case in this scenario.

The test methods in FractionTest would still only test the functionality
of Fraction, and those in BigFractionTest only that of BigFraction. It's
just that, in cases where similar/analogous functionality is tested,
they don't "come up" with test cases, i.e. combinations of input and
expected output values, themselves, but rather draw these from an
outside source that just happens to be queried by unit tests of a
different, entirely unrelated class as well.

The class FractionTest does not care that the class BigFractionTest
retrieves some of its test cases from the same source as FractionTest
does and vice versa. Likewise, the hypothetical class CommonTestCases
does not care what FractionTest or BigFractionTest do with the test
cases it provides, or if they use them at all. What matters is that
FractionTest and BigFractionTest each take responsibility for ensuring
that the test cases provided by CommonTestCases are applicable to the
functionality they want to test. Of course, this requires that
CommonTestCases clearly documents the test cases it provides. If, for
example, CommonTestCases were to provide test cases that are completely
useless to both FractionTest and BigFractionTest, then it would be the
responsibility of FractionTest and BigFractionTest to disregard them.

So the tests performed by FractionTest and BigFractionTest would not
rely on any functionality outside the unit they test, except for the
validity of the test cases. But erroneous test cases can happen
regardless of whether they are declared in the test class itself or
outside.


On 6/20/19 5:07 PM, Eric Barnhill wrote:

Sorry for the slow reply, I thought I sent this yesterday.

I agree from a code architecture standpoint such a refactoring makes
sense.
However from the perspective of unit tests it makes it no longer a unit
test.

IIUC it's best practice for a unit test that all context be within the
test. If additional context is required it fails to meet the
definition of
a unit test and is instead an integration test,  and the function being
tested may require rethinking.

This results in unit tests often being clunkily and awkwardly coded,
but I
think it is the way they are typically written and it has its reasons.

  So I am +0 .

On Thu, Jun 20, 2019, 02:01 Heinrich Bohne 
wrote:


A quick looks shows that the BigFractionTest does have test cases for

very large numbers. However the add, subtract, divide and multiply
tests
and a few others just use values that would work with Fraction.
Possibly
these can be moved to a shared common tests location too.

That's what I was thinking too – the draft was by no means intended
to be
complete, I just created it to give a general idea of how I would go
about
implementing this. I'll work some more on it before I create an
actual pull
request.


On 6/20/19 10:40 AM, Alex Herbert wrote:

On 20 Jun 2019, at 00:54, Heinrich Bohne 
wrote:

An awful lot of code is duplicated between FractionTest and
BigFractionTest. Often, the test cases in the two classes only
differ in
the types they use (e.g. Fraction vs. BigFraction), but the actual
values the tests use are the same.

I think this could be mitigated by adding a new class that stores the
values for these common test cases, and the classes FractionTest and
BigFractionTest retrieve the values from this class and only
implement
the test patterns.

I created a draft here:


https://github.com/Schamschi/commons-numbers/commit/53906afd991cd190f1a05beb0952a40ae6c6ea3f


Any opinions on this?

1. BigFraction should work the same way as Fraction when the
numbers are

the same

So collecting the common tests together makes sense. The change in the

PR looks good.

2. BigFraction should work with numbers that cannot be handled by

Fraction

A quick looks shows that the BigFractionTest does have test cases for

very large numbers. However the add, subtract, divide and multiply
tests
and a few others just use values that would work with Fraction.
Possibly
these can be moved to a shared common tests location too.

Then variants added using BigInteger arguments just to make sure
the Big

part of BigFraction is working.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Re: Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

2019-06-20 Thread Heinrich Bohne 

Hello Eric,

I'm not sure if I understand what you mean by "context" when you say
that all context has to be within the unit test.Do you mean that the
test should not rely on the functionality of other
modules/methods/"units" than the one to be tested? If so, I agree with
you, but I don't think that this would be the case in this scenario.

The test methods in FractionTest would still only test the functionality
of Fraction, and those in BigFractionTest only that of BigFraction. It's
just that, in cases where similar/analogous functionality is tested,
they don't "come up" with test cases, i.e. combinations of input and
expected output values, themselves, but rather draw these from an
outside source that just happens to be queried by unit tests of a
different, entirely unrelated class as well.

The class FractionTest does not care that the class BigFractionTest
retrieves some of its test cases from the same source as FractionTest
does and vice versa. Likewise, the hypothetical class CommonTestCases
does not care what FractionTest or BigFractionTest do with the test
cases it provides, or if they use them at all. What matters is that
FractionTest and BigFractionTest each take responsibility for ensuring
that the test cases provided by CommonTestCases are applicable to the
functionality they want to test. Of course, this requires that
CommonTestCases clearly documents the test cases it provides. If, for
example, CommonTestCases were to provide test cases that are completely
useless to both FractionTest and BigFractionTest, then it would be the
responsibility of FractionTest and BigFractionTest to disregard them.

So the tests performed by FractionTest and BigFractionTest would not
rely on any functionality outside the unit they test, except for the
validity of the test cases. But erroneous test cases can happen
regardless of whether they are declared in the test class itself or outside.


On 6/20/19 5:07 PM, Eric Barnhill wrote:

Sorry for the slow reply, I thought I sent this yesterday.

I agree from a code architecture standpoint such a refactoring makes sense.
However from the perspective of unit tests it makes it no longer a unit
test.

IIUC it's best practice for a unit test that all context be within the
test. If additional context is required it fails to meet the definition of
a unit test and is instead an integration test,  and the function being
tested may require rethinking.

This results in unit tests often being clunkily and awkwardly coded, but I
think it is the way they are typically written and it has its reasons.

  So I am +0 .

On Thu, Jun 20, 2019, 02:01 Heinrich Bohne  wrote:


A quick looks shows that the BigFractionTest does have test cases for

very large numbers. However the add, subtract, divide and multiply tests
and a few others just use values that would work with Fraction. Possibly
these can be moved to a shared common tests location too.

That's what I was thinking too – the draft was by no means intended to be
complete, I just created it to give a general idea of how I would go about
implementing this. I'll work some more on it before I create an actual pull
request.


On 6/20/19 10:40 AM, Alex Herbert wrote:

On 20 Jun 2019, at 00:54, Heinrich Bohne  wrote:

An awful lot of code is duplicated between FractionTest and
BigFractionTest. Often, the test cases in the two classes only differ in
the types they use (e.g. Fraction vs. BigFraction), but the actual
values the tests use are the same.

I think this could be mitigated by adding a new class that stores the
values for these common test cases, and the classes FractionTest and
BigFractionTest retrieve the values from this class and only implement
the test patterns.

I created a draft here:


https://github.com/Schamschi/commons-numbers/commit/53906afd991cd190f1a05beb0952a40ae6c6ea3f

Any opinions on this?

1. BigFraction should work the same way as Fraction when the numbers are

the same

So collecting the common tests together makes sense. The change in the

PR looks good.

2. BigFraction should work with numbers that cannot be handled by

Fraction

A quick looks shows that the BigFractionTest does have test cases for

very large numbers. However the add, subtract, divide and multiply tests
and a few others just use values that would work with Fraction. Possibly
these can be moved to a shared common tests location too.

Then variants added using BigInteger arguments just to make sure the Big

part of BigFraction is working.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail:

Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

2019-06-20 Thread Alex Herbert 

On 20/06/2019 16:07, Eric Barnhill wrote:

Sorry for the slow reply, I thought I sent this yesterday.

I agree from a code architecture standpoint such a refactoring makes sense.
However from the perspective of unit tests it makes it no longer a unit
test.
It is still testing a unit. Just the test code is spread out over 
multiple files so it can be reused.


IIUC it's best practice for a unit test that all context be within the
test.


If the purpose of the test is to ensure two pieces of code do the same 
thing then perhaps a rewrite as a parameterized test. Unfortunately 
BigFraction and Fraction do not share a common interface that the test 
is checking. So a parameterized test is not as simple as passing in an 
instance of one or the other (or a reference to the factory constructor 
method). Putting all the test cases in a single place rather than 
duplicating them in two files seems like the most maintainable going 
forward.



If additional context is required it fails to meet the definition of
a unit test and is instead an integration test,  and the function being
tested may require rethinking.


Depends what you define as a unit test. I'd say the unit was BigFraction 
or Fraction. An integration test is something that must be tested with 
coherant components working together to provide functionality. You are 
not doing that.


I'd say that if you executed the all the tests in the Test file and it 
achieves 100% coverage of the class it is aimed at then it is a unit 
test. Even if your Test file uses code from other places.


In this instance the code from other places amounts to a list of 
arguments and expected results. Duplicating this data just to make the 
Test file standalone is less maintainable.




This results in unit tests often being clunkily and awkwardly coded, but I
think it is the way they are typically written and it has its reasons.

  So I am +0 .

On Thu, Jun 20, 2019, 02:01 Heinrich Bohne  wrote:


A quick looks shows that the BigFractionTest does have test cases for

very large numbers. However the add, subtract, divide and multiply tests
and a few others just use values that would work with Fraction. Possibly
these can be moved to a shared common tests location too.

That's what I was thinking too – the draft was by no means intended to be
complete, I just created it to give a general idea of how I would go about
implementing this. I'll work some more on it before I create an actual pull
request.


On 6/20/19 10:40 AM, Alex Herbert wrote:

On 20 Jun 2019, at 00:54, Heinrich Bohne  wrote:

An awful lot of code is duplicated between FractionTest and
BigFractionTest. Often, the test cases in the two classes only differ in
the types they use (e.g. Fraction vs. BigFraction), but the actual
values the tests use are the same.

I think this could be mitigated by adding a new class that stores the
values for these common test cases, and the classes FractionTest and
BigFractionTest retrieve the values from this class and only implement
the test patterns.

I created a draft here:


https://github.com/Schamschi/commons-numbers/commit/53906afd991cd190f1a05beb0952a40ae6c6ea3f

Any opinions on this?

1. BigFraction should work the same way as Fraction when the numbers are

the same

So collecting the common tests together makes sense. The change in the

PR looks good.

2. BigFraction should work with numbers that cannot be handled by

Fraction

A quick looks shows that the BigFractionTest does have test cases for

very large numbers. However the add, subtract, divide and multiply tests
and a few others just use values that would work with Fraction. Possibly
these can be moved to a shared common tests location too.

Then variants added using BigInteger arguments just to make sure the Big

part of BigFraction is working.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

2019-06-20 Thread Eric Barnhill 
Sorry for the slow reply, I thought I sent this yesterday.

I agree from a code architecture standpoint such a refactoring makes sense.
However from the perspective of unit tests it makes it no longer a unit
test.

IIUC it's best practice for a unit test that all context be within the
test. If additional context is required it fails to meet the definition of
a unit test and is instead an integration test,  and the function being
tested may require rethinking.

This results in unit tests often being clunkily and awkwardly coded, but I
think it is the way they are typically written and it has its reasons.

 So I am +0 .

On Thu, Jun 20, 2019, 02:01 Heinrich Bohne  wrote:

> > A quick looks shows that the BigFractionTest does have test cases for
> very large numbers. However the add, subtract, divide and multiply tests
> and a few others just use values that would work with Fraction. Possibly
> these can be moved to a shared common tests location too.
>
> That's what I was thinking too – the draft was by no means intended to be
> complete, I just created it to give a general idea of how I would go about
> implementing this. I'll work some more on it before I create an actual pull
> request.
>
>
> On 6/20/19 10:40 AM, Alex Herbert wrote:
> >
> >> On 20 Jun 2019, at 00:54, Heinrich Bohne  wrote:
> >>
> >> An awful lot of code is duplicated between FractionTest and
> >> BigFractionTest. Often, the test cases in the two classes only differ in
> >> the types they use (e.g. Fraction vs. BigFraction), but the actual
> >> values the tests use are the same.
> >>
> >> I think this could be mitigated by adding a new class that stores the
> >> values for these common test cases, and the classes FractionTest and
> >> BigFractionTest retrieve the values from this class and only implement
> >> the test patterns.
> >>
> >> I created a draft here:
> >>
> https://github.com/Schamschi/commons-numbers/commit/53906afd991cd190f1a05beb0952a40ae6c6ea3f
> >>
> >> Any opinions on this?
> > 1. BigFraction should work the same way as Fraction when the numbers are
> the same
> >
> > So collecting the common tests together makes sense. The change in the
> PR looks good.
> >
> > 2. BigFraction should work with numbers that cannot be handled by
> Fraction
> >
> > A quick looks shows that the BigFractionTest does have test cases for
> very large numbers. However the add, subtract, divide and multiply tests
> and a few others just use values that would work with Fraction. Possibly
> these can be moved to a shared common tests location too.
> >
> > Then variants added using BigInteger arguments just to make sure the Big
> part of BigFraction is working.
> >
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [VOTE] Release Apache Commons Daemon 1.1.1

2019-06-20 Thread Mark Thomas 
On 20/06/2019 13:34, Gary Gregory wrote:
> I do not understand the lack of reply to my requests to follow our release
> process:
> 
> - Hashes to files on dist/dev

Not necessary.
The revision number for the dist repo is sufficient for traceability.

> - Link to site

Not part of the release.

> - Link to KEYS file

Not part of the release.
That said, it is trivial to include the link. I'll try and remember to
do that for 1.2.0.

> - Link to apache.org instead of github.com for the tag

Not necessary. The hash is sufficient.
That said, it is trivial to reference gitbox.a.o rather than GitHub.
I'll try and remember to do that for 1.2.0.

For a longer response, see the Daemon 1.1.0 vote thread.

Mark


> 
> Gary
> 
> On Wed, Jun 19, 2019 at 6:30 AM Mark Thomas  wrote:
> 
>> On 19/06/2019 10:44, Jonathan Gallimore wrote:
>>> This works well in my tests, many thanks for the release.
>>
>> Thanks for the confirmation.
>>
>> Mark
>>
>>>
>>> (non-binding) +1.
>>>
>>> Jon
>>>
>>> On Mon, Jun 17, 2019 at 1:13 PM Mark Thomas  wrote:
>>>
 It has been ~18 months since the last Commons Daemon release. After the
 recent flurry of activity, I think we are ready for a release.

 Notable changes include:
 - Improved JRE/JDK detection to support increased range of both JVM
   versions and vendors.
 - Procrun. Change the default service from LocalSystem to
   'NT Authority\LocalService'

 The full set of changes is in the changelog

 1.1.1 can be obtained from (r34537):
 https://dist.apache.org/repos/dist/dev/commons/daemon/

 The git tag is:
 https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
 4319f482e1ff6ea7655e1377120750fd6ecc3810
 <
>> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_14319f482e1ff6ea7655e1377120750fd6ecc3810
>>>

 The Maven Staging repo is:

>> https://repository.apache.org/content/repositories/orgapachecommons-1441/

 The Windows binaries have been signed by the Symantec code signing
>> service.



 [ ] Approved - go ahead and release Commons Daemon 1.1.1
 [ ] Broken   - do not release because...

 -
 To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
 For additional commands, e-mail: dev-h...@commons.apache.org


>>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[CANCEL][VOTE] Release Apache Commons Daemon 1.1.1

2019-06-20 Thread Mark Thomas 
Given the discussions around 1.1.1 vs 1.2.0 I'm cancelling this release
vote.

I'll start preparing for a 1.2.0 RC now (I think things are pretty much
there but a final check won't hurt) with a view to tagging sometime
between late tomorrow and early next week.

If anyone has any objections to this plan then please speak up in the
next 24 hours.

Mark


On 17/06/2019 13:13, Mark Thomas wrote:
> It has been ~18 months since the last Commons Daemon release. After the
> recent flurry of activity, I think we are ready for a release.
> 
> Notable changes include:
> - Improved JRE/JDK detection to support increased range of both JVM
>   versions and vendors.
> - Procrun. Change the default service from LocalSystem to
>   'NT Authority\LocalService'
> 
> The full set of changes is in the changelog
> 
> 1.1.1 can be obtained from (r34537):
> https://dist.apache.org/repos/dist/dev/commons/daemon/
> 
> The git tag is:
> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
> 4319f482e1ff6ea7655e1377120750fd6ecc3810
> 
> The Maven Staging repo is:
> https://repository.apache.org/content/repositories/orgapachecommons-1441/
> 
> The Windows binaries have been signed by the Symantec code signing service.
> 
> 
> 
> [ ] Approved - go ahead and release Commons Daemon 1.1.1
> [ ] Broken   - do not release because...
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [bcel] LRU Cache for ClassPathRepository

2019-06-20 Thread Tomo Suzuki 
Hi Gary and BCEL maintainers,

I created a PR for LruCacheClassPathRepository
https://github.com/apache/commons-bcel/pull/28 . I appreciate if you can
review them.

Regards,
Tomo


On Mon, Jun 17, 2019 at 12:11 PM Tomo Suzuki  wrote:

> Hi Gary and BCEL maintainers,
>
> My OutOfMemoryError problem that motivated BCEL-317
>  ticket has been resolved
> by a custom ClassPathRepository and I'm thinking to contribute this
> solution to BCEL library:
>
> BCEL-320  A new
> ClassPathRepository that can scan many JAR files without OutOfMemoryError
>
>
> Test cases to reproduce OutOfMemoryError:
> https://github.com/suztomo/bcel-oome-example
>
> What do you think?
>
> Regards,
> Tomo
>
> On Wed, May 22, 2019 at 11:23 AM Tomo Suzuki  wrote:
>
>> Hi Gary and BCEL maintainers,
>>
>> I've added Javadoc for the enhancement.
>> https://github.com/apache/commons-bcel/pull/26
>> I appreciate if you can check the direction of the implementation is good
>> or bad.
>>
>> Regards,
>> Tomo
>>
>>
>> On Sun, May 19, 2019 at 11:40 PM Tomo Suzuki  wrote:
>>
>>> Hi Gary (and BCEL maintainers),
>>>
>>> Thank you for the comment. It has been addressed. Would you check the
>>> pull request?
>>> https://github.com/apache/commons-bcel/pull/26/files
>>>
>>> Regards,
>>> Tomo
>>>
>>> On Wed, May 8, 2019 at 17:46 Tomo Suzuki  wrote:
>>>
 Hi Gary,
 Created a draft PR to receive feedback.
 https://github.com/apache/commons-bcel/pull/26/files . What do you
 think?

 Regards,
 Tomo

 From: Gary Gregory 
 Date: Wed, May 8, 2019 at 9:40 AM
 To: Commons Developers List

 > Great. I look forward to seeing what you'll come up with :-)
 >
 > On Tue, May 7, 2019 at 4:27 PM Tomo Suzuki >>> >
 > wrote:
 >
 > > I found the discussion on getInstance method had incurred
 performance
 > > degradation https://issues.apache.org/jira/browse/BCEL-186 .
 > >
 > > From the JIRA:
 > > > This feature could return as a pluggable cache if someone wants to
 > > provide a patch
 > >
 > > I'll think about the approach.
 > >
 > > Regards,
 > > Tomo
 > >
 > >
 > > On Thu, May 2, 2019 at 1:22 PM Gary Gregory >>> >
 > > wrote:
 > >
 > > > On Thu, May 2, 2019 at 10:59 AM Tomo Suzuki
 
 > > > wrote:
 > > >
 > > > > Gary,
 > > > > I didn't find ConstantUtf8.getCachedInstance
 > > > > <
 > > >
 > >
 https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java#L94
 > > > >
 > > > > is used in BCEL (latest 6.3.1). I tried my custom ConstantUtf8
 > > > modification
 > > > > to leverage getCachedInstance method and it worked well:
 > > > >
 > > > > Before
 > > > >
 > > > > Without getCachedInstance, my tool created 2,6 million
 ConstantUtf8
 > > > > instances (before failing OutOfMemoryError: GC overhead limit
 exceeded)
 > > > to
 > > > > check ~200 jar files
 > > > > [image: 2644k_constantutf8_without_getCachedInstance.png]
 > > > >
 > > > >
 > > > > After
 > > > >
 > > > > With getCachedInstance, my tool created just 0.6 million
 ConstantUtf8
 > > > > instances. It didn't throw the OutOfMemoryError.
 > > > > [image: 621k_constantutf8_with_getCachedInstance.png]
 > > > >
 > > > > My modification was to use getCachedInstance for
 > > > > ConstantUtf8.getInstance(DataInput)
 > > > > <
 > > >
 > >
 https://github.com/apache/commons-bcel/blob/master/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java#L123
 > > > >
 > > > > .
 > > > >
 > > > >
 > > > > Do you know why ConstantUtf8.getCachedInstance is unused?
 > > > >
 > > >
 > > > I do not.
 > > >
 > > > Gary
 > > >
 > > >
 > > > >
 > > > > Regards,
 > > > > Tomo
 > > > >
 > > > >
 > > > >
 > > > > On Wed, May 1, 2019 at 7:02 PM Gary Gregory <
 garydgreg...@gmail.com>
 > > > > wrote:
 > > > >
 > > > >> On Wed, May 1, 2019 at 6:37 PM Tomo Suzuki
 >>> > > >
 > > > >> wrote:
 > > > >>
 > > > >> > Gary,
 > > > >> > That’s right. I missed it. I think I just need to find a way
 to
 > > > leverage
 > > > >> > the getCachedInstance method. Thank you for quick response.
 > > > >> >
 > > > >>
 > > > >> YW. Please let us know your outcome.
 > > > >>
 > > > >> Gary
 > > > >>
 > > > >>
 > > > >> >
 > > > >> > On Wed, May 1, 2019 at 18:00 Gary Gregory <
 garydgreg...@gmail.com>
 > > > >> wrote:
 > > > >> >
 > > > >> > > Why not use getCachedInstance() ?
 > > > >> > >
 > > > >> > > Gary
 > > > >> > >
 > > > >> > > On Wed, May 1, 2019 at 5:20 PM Tomo Suzuki
 > > > >>> > > > >> >
 > > > >> > > wrote:
 > > > >> > >

Re: [Rng] Jenkins JDK 1.6 failing

2019-06-20 Thread Alex Herbert 



On 20/06/2019 13:47, Gilles Sadowski wrote:

Hello Gary.

Le jeu. 20 juin 2019 à 14:31, Gary Gregory  a écrit :

Java 6? Really?

You ask this recurrently. ;-)

[I know this is not the right thread to answer it but anyways...]

That [RNG] still supports Java 6 is a tribute to what I've been
advocating for ages:  Better create small and focused components
rather than pile up code in big monolithic libraries.  That way, we
can have both stability (for components that *really* don't need the
bleeding edge features of the JDK), and fun (developing functionality
that benefits staying in sync with the newer JDK features).

Regards,
Gilles
Random number generation is just arithmetic. The main routines could 
probably be done in Java 1.


There is nothing outside of the main routines that absolutely requires 
newer features. It does use generics from 1.5.


I'm not sure why it is Java 1.6 and not Java 1.5. Probably due to EOL 
for Java 1.5.


There are some things that could be picked from the Streams API (as 
discussed recently on a thread about dynamic shuffling). But that 
reached no conclusion as to whether it was a feature with real merit.


Alex



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Rng] Jenkins JDK 1.6 failing

2019-06-20 Thread Gilles Sadowski 
Hello Gary.

Le jeu. 20 juin 2019 à 14:31, Gary Gregory  a écrit :
>
> Java 6? Really?

You ask this recurrently. ;-)

[I know this is not the right thread to answer it but anyways...]

That [RNG] still supports Java 6 is a tribute to what I've been
advocating for ages:  Better create small and focused components
rather than pile up code in big monolithic libraries.  That way, we
can have both stability (for components that *really* don't need the
bleeding edge features of the JDK), and fun (developing functionality
that benefits staying in sync with the newer JDK features).

Regards,
Gilles

>
> Gary
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Rng] Jenkins JDK 1.6 failing

2019-06-20 Thread Alex Herbert 


On 20/06/2019 13:30, sebb wrote:

On Thu, 20 Jun 2019 at 13:06, Alex Herbert  wrote:

On 20/06/2019 12:45, Apache Jenkins Server wrote:

The Apache Jenkins build system has built commons-rng (build #361)

Status: Still Failing

Check console output at https://builds.apache.org/job/commons-rng/361/ to view 
the results.

Jenkins is failing the RAT check on JDK 1.6 with apparently 332
unapproved licences.

It passes on the JDK 1.9 build.

A vanilla git clone of the repo builds fine with this many files
included by rat:

[INFO] 81 implicit excludes (use -debug for more details).
[INFO] 19 explicit excludes (use -debug for more details).
[INFO] 138 resources included (use -debug for more details)

The same log output from Jenkins reads:

[INFO] 80 implicit excludes (use -debug for more details).
[INFO] 19 explicit excludes (use -debug for more details).
[INFO] 627 resources included (use -debug for more details)

The last successful build on Jenkins reads:

[INFO] 81 implicit excludes (use -debug for more details).
[INFO] 19 explicit excludes (use -debug for more details).
[INFO] 136 resources included (use -debug for more details)

Since this build I added two files so that matches with the 138
resources in the vanilla build.

So for some reason the latest builds have a lot more files in the
working directory.

Is there a way to see the working directory that Jenkins is using and
the rat.txt report? There is something that should not be there.

https://builds.apache.org/job/commons-rng/ws/

However AFAIK this will be updated for each build, so you may need to
suspend builds temporarily.

Thanks. The rat.txt shows that there is now the following directory

.repository

It belongs to Maven and contains poms, jars and sha1 hashes.

I'll add it to .gitignore.





Is this something for INFRA to fix?

Unlikely, most likely the job does not tidy up properly.


Alex



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [VOTE] Release Apache Commons Daemon 1.1.1

2019-06-20 Thread Gary Gregory 
I do not understand the lack of reply to my requests to follow our release
process:

- Hashes to files on dist/dev
- Link to site
- Link to KEYS file
- Link to apache.org instead of github.com for the tag

Gary

On Wed, Jun 19, 2019 at 6:30 AM Mark Thomas  wrote:

> On 19/06/2019 10:44, Jonathan Gallimore wrote:
> > This works well in my tests, many thanks for the release.
>
> Thanks for the confirmation.
>
> Mark
>
> >
> > (non-binding) +1.
> >
> > Jon
> >
> > On Mon, Jun 17, 2019 at 1:13 PM Mark Thomas  wrote:
> >
> >> It has been ~18 months since the last Commons Daemon release. After the
> >> recent flurry of activity, I think we are ready for a release.
> >>
> >> Notable changes include:
> >> - Improved JRE/JDK detection to support increased range of both JVM
> >>   versions and vendors.
> >> - Procrun. Change the default service from LocalSystem to
> >>   'NT Authority\LocalService'
> >>
> >> The full set of changes is in the changelog
> >>
> >> 1.1.1 can be obtained from (r34537):
> >> https://dist.apache.org/repos/dist/dev/commons/daemon/
> >>
> >> The git tag is:
> >> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_1
> >> 4319f482e1ff6ea7655e1377120750fd6ecc3810
> >> <
> https://github.com/apache/commons-daemon/commits/COMMONS_DAEMON_1_1_14319f482e1ff6ea7655e1377120750fd6ecc3810
> >
> >>
> >> The Maven Staging repo is:
> >>
> https://repository.apache.org/content/repositories/orgapachecommons-1441/
> >>
> >> The Windows binaries have been signed by the Symantec code signing
> service.
> >>
> >>
> >>
> >> [ ] Approved - go ahead and release Commons Daemon 1.1.1
> >> [ ] Broken   - do not release because...
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [Rng] Jenkins JDK 1.6 failing

2019-06-20 Thread Gary Gregory 
Java 6? Really?

Gary

On Thu, Jun 20, 2019 at 8:06 AM Alex Herbert 
wrote:

> On 20/06/2019 12:45, Apache Jenkins Server wrote:
> > The Apache Jenkins build system has built commons-rng (build #361)
> >
> > Status: Still Failing
> >
> > Check console output at https://builds.apache.org/job/commons-rng/361/
> to view the results.
>
> Jenkins is failing the RAT check on JDK 1.6 with apparently 332
> unapproved licences.
>
> It passes on the JDK 1.9 build.
>
> A vanilla git clone of the repo builds fine with this many files
> included by rat:
>
> [INFO] 81 implicit excludes (use -debug for more details).
> [INFO] 19 explicit excludes (use -debug for more details).
> [INFO] 138 resources included (use -debug for more details)
>
> The same log output from Jenkins reads:
>
> [INFO] 80 implicit excludes (use -debug for more details).
> [INFO] 19 explicit excludes (use -debug for more details).
> [INFO] 627 resources included (use -debug for more details)
>
> The last successful build on Jenkins reads:
>
> [INFO] 81 implicit excludes (use -debug for more details).
> [INFO] 19 explicit excludes (use -debug for more details).
> [INFO] 136 resources included (use -debug for more details)
>
> Since this build I added two files so that matches with the 138
> resources in the vanilla build.
>
> So for some reason the latest builds have a lot more files in the
> working directory.
>
> Is there a way to see the working directory that Jenkins is using and
> the rat.txt report? There is something that should not be there.
>
> Is this something for INFRA to fix?
>
> Alex
>
>
>

Re: [Rng] Jenkins JDK 1.6 failing

2019-06-20 Thread sebb 
On Thu, 20 Jun 2019 at 13:06, Alex Herbert  wrote:
>
> On 20/06/2019 12:45, Apache Jenkins Server wrote:
> > The Apache Jenkins build system has built commons-rng (build #361)
> >
> > Status: Still Failing
> >
> > Check console output at https://builds.apache.org/job/commons-rng/361/ to 
> > view the results.
>
> Jenkins is failing the RAT check on JDK 1.6 with apparently 332
> unapproved licences.
>
> It passes on the JDK 1.9 build.
>
> A vanilla git clone of the repo builds fine with this many files
> included by rat:
>
> [INFO] 81 implicit excludes (use -debug for more details).
> [INFO] 19 explicit excludes (use -debug for more details).
> [INFO] 138 resources included (use -debug for more details)
>
> The same log output from Jenkins reads:
>
> [INFO] 80 implicit excludes (use -debug for more details).
> [INFO] 19 explicit excludes (use -debug for more details).
> [INFO] 627 resources included (use -debug for more details)
>
> The last successful build on Jenkins reads:
>
> [INFO] 81 implicit excludes (use -debug for more details).
> [INFO] 19 explicit excludes (use -debug for more details).
> [INFO] 136 resources included (use -debug for more details)
>
> Since this build I added two files so that matches with the 138
> resources in the vanilla build.
>
> So for some reason the latest builds have a lot more files in the
> working directory.
>
> Is there a way to see the working directory that Jenkins is using and
> the rat.txt report? There is something that should not be there.

https://builds.apache.org/job/commons-rng/ws/

However AFAIK this will be updated for each build, so you may need to
suspend builds temporarily.

> Is this something for INFRA to fix?

Unlikely, most likely the job does not tidy up properly.

> Alex
>
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Rng] Jenkins JDK 1.6 failing

2019-06-20 Thread Alex Herbert 

On 20/06/2019 12:45, Apache Jenkins Server wrote:

The Apache Jenkins build system has built commons-rng (build #361)

Status: Still Failing

Check console output at https://builds.apache.org/job/commons-rng/361/ to view 
the results.


Jenkins is failing the RAT check on JDK 1.6 with apparently 332 
unapproved licences.


It passes on the JDK 1.9 build.

A vanilla git clone of the repo builds fine with this many files 
included by rat:


[INFO] 81 implicit excludes (use -debug for more details).
[INFO] 19 explicit excludes (use -debug for more details).
[INFO] 138 resources included (use -debug for more details)

The same log output from Jenkins reads:

[INFO] 80 implicit excludes (use -debug for more details).
[INFO] 19 explicit excludes (use -debug for more details).
[INFO] 627 resources included (use -debug for more details)

The last successful build on Jenkins reads:

[INFO] 81 implicit excludes (use -debug for more details).
[INFO] 19 explicit excludes (use -debug for more details).
[INFO] 136 resources included (use -debug for more details)

Since this build I added two files so that matches with the 138 
resources in the vanilla build.


So for some reason the latest builds have a lot more files in the 
working directory.


Is there a way to see the working directory that Jenkins is using and 
the rat.txt report? There is something that should not be there.


Is this something for INFRA to fix?

Alex

Re: Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

2019-06-20 Thread Heinrich Bohne 

A quick looks shows that the BigFractionTest does have test cases for very 
large numbers. However the add, subtract, divide and multiply tests and a few 
others just use values that would work with Fraction. Possibly these can be 
moved to a shared common tests location too.


That's what I was thinking too – the draft was by no means intended to be 
complete, I just created it to give a general idea of how I would go about 
implementing this. I'll work some more on it before I create an actual pull 
request.


On 6/20/19 10:40 AM, Alex Herbert wrote:



On 20 Jun 2019, at 00:54, Heinrich Bohne  wrote:

An awful lot of code is duplicated between FractionTest and
BigFractionTest. Often, the test cases in the two classes only differ in
the types they use (e.g. Fraction vs. BigFraction), but the actual
values the tests use are the same.

I think this could be mitigated by adding a new class that stores the
values for these common test cases, and the classes FractionTest and
BigFractionTest retrieve the values from this class and only implement
the test patterns.

I created a draft here:
https://github.com/Schamschi/commons-numbers/commit/53906afd991cd190f1a05beb0952a40ae6c6ea3f

Any opinions on this?

1. BigFraction should work the same way as Fraction when the numbers are the 
same

So collecting the common tests together makes sense. The change in the PR looks 
good.

2. BigFraction should work with numbers that cannot be handled by Fraction

A quick looks shows that the BigFractionTest does have test cases for very 
large numbers. However the add, subtract, divide and multiply tests and a few 
others just use values that would work with Fraction. Possibly these can be 
moved to a shared common tests location too.

Then variants added using BigInteger arguments just to make sure the Big part 
of BigFraction is working.


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [numbers-fraction] Code duplication between FractionTest and BigFractionTest

2019-06-20 Thread Alex Herbert 



> On 20 Jun 2019, at 00:54, Heinrich Bohne  wrote:
> 
> An awful lot of code is duplicated between FractionTest and
> BigFractionTest. Often, the test cases in the two classes only differ in
> the types they use (e.g. Fraction vs. BigFraction), but the actual
> values the tests use are the same.
> 
> I think this could be mitigated by adding a new class that stores the
> values for these common test cases, and the classes FractionTest and
> BigFractionTest retrieve the values from this class and only implement
> the test patterns.
> 
> I created a draft here:
> https://github.com/Schamschi/commons-numbers/commit/53906afd991cd190f1a05beb0952a40ae6c6ea3f
> 
> Any opinions on this?

1. BigFraction should work the same way as Fraction when the numbers are the 
same

So collecting the common tests together makes sense. The change in the PR looks 
good.

2. BigFraction should work with numbers that cannot be handled by Fraction

A quick looks shows that the BigFractionTest does have test cases for very 
large numbers. However the add, subtract, divide and multiply tests and a few 
others just use values that would work with Fraction. Possibly these can be 
moved to a shared common tests location too.

Then variants added using BigInteger arguments just to make sure the Big part 
of BigFraction is working.

> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org