You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Alex Herbert <al...@gmail.com> on 2019/06/10 15:17:39 UTC
Re: [rng] Releasing 1.3
On 10/06/2019 15:31, Gilles Sadowski wrote:
>>> P.S. Thinking of releasing 1.3?
>> Not yet. I think there are a few outstanding items that work together
>> for the multi-threaded focus of the new code and the new generators:
> Sure but some of them could be postponed, if just to RERO.
>
>> - RNG-98: LongJumpable (easy)
>>
>> - RNG-102: SharedStateSampler (lots of easy work)
>>
>> - RNG-106: XorShiRo generators require non-zero input seeds
>>
>> (I'm still thinking about the best way to do this. The Jira ticket
>> suggests a speed test to at least know the implications of different ideas.)
> This is only when using the "SeedFactory" (?). [Otherwise, it's the
> user's responsibility to construct an appropriate seed.]
>
> Couldn't we just check that the output of the internal generator is not
> all zero (and call it again if it is)?
Yes. The worse case scenario is a 1 in 2^64 collision rate with zero.
All other generators have larger state sizes. So this would be fine. An
alternative would be to set a single bit to non zero. This throws away 1
bit of randomness from the seed and will always work without any
recursion. But it makes the seed worse. The ideas are in the header for
this Jira ticket:
https://issues.apache.org/jira/browse/RNG-106
I'll fix this soon.
The other item I did not mention is outcome from RNG-104. This seems to
indicate that using System.identityHashCode(new Object()) is not as good
a mixer as a ThreadLocal random generator, both for speed and also
quality. I'm currently testing Well44497b ^ SplitMix in BigCrush but I
think this should replace the identity hash code method.
It also shows that using a synchronized block on each call to the
generator is slow. Seed arrays can be built 2x faster using 8 calls to
the generator per synchronisation when single threaded. When
multi-threaded it is much better. I'm still testing to find a good
estimate of the optimum block size for all scenarios.
>
>> There are also outstanding items I've partially looked at:
>>
>> - RNG-90: Improve nextInt(int) and nextLong(long) for powers of 2
>>
>> I paused testing this as I moved on to other things. The easy fix is to
>> copy the JDK SplittableRandom implementation. But it requires a
>> generator with good quality lower bits. It would have to be worked
>> around for generators that have low period lower bits. So this requires
>> digesting all the results of BigCrush to determine which generators can
>> use the new method and which should not change. Then is the decision on
>> how to do it.
> A second-order improvement IMHO.
Which is why I moved on. Note that the speed of using the new approach
is much faster for powers of 2.
>
>> - RNG-95: DiscreteUniformSampler
>>
>> I have code that computes a discrete uniform sample using multiply and
>> not the modulus algorithm used in nextInt(int). However I cannot find
>> anywhere that uses the method so currently I am the author. I cannot
>> imagine no-one has done this before
> Interesting...
>
>> but to be on the safe side it may be
>> better to put it in as an alternative DiscreteSampler, e.g.
>> FastDiscreteUniformSampler and leave the current DiscreteUniformSampler
>> to default to using nextInt(int).
> I'm wary of this naming after the "FastMath" experience.
> Perhaps safer is to puti in a feature branch, until you are sure that
> it can replace the current implementation.
I couldn't think of a name describing the method. It is related to the
discrete Weyl sequence so perhaps WeylDiscreteUniformSampler. It's a
work in progress...
>
>> Speed tests show it is faster, and can be over 2-fold faster when the
>> rejection algorithm in nextInt(int) is worse case.
>>
>> - RNG-100: GuideTableDiscreteSampler
>>
>> All done but should be rebased and put in a PR
>>
>> - RNG-99: AliasMethodDiscreteSampler
>>
>> Also done but is very hard to find a probability distribution where it
>> is better than GuideTableDiscreteSampler. It could be added as a
>> reference implementation.
> +1
>
>> - RNG-XX: Use GuideTableDiscreteSampler behind
>> DiscreteProbabilityCollectionSampler<T>
>>
>> It will be faster and remove the binarySearch method from that class.
> +1
>
>> I also thought we wait until end of GSoC and so new generators could
>> also be included.
> I'd rather not wait.
> There are many improvements and new features (thanks to you!)
> that warrant a release.
OK. I'll get on with fixing the "must haves".
>
> And I also think that releasing his GSoC work would be a nice
> achievement task for Abhishek (after he will have assisted at
> how it worked out for 1.3).
>
> Best,
> Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Gilles Sadowski <gi...@gmail.com>.
> > [...]
> > [...] is that check
> > ---CUT---
> > if (!(source.normalized instanceof SharedStateSampler<?>)) {
> > throw new UnsupportedOperationException("The underlying
> > sampler is not a SharedStateSampler");
> > }
> > ---CUT---
> > necessary?
>
> That was already in the codebase. I added it to support
> SharedStateSampler in RNG-102.
>
> The withUniformRandomProvider method is documented to:
>
> @throws UnsupportedOperationException if the underlying sampler is not
> a {@link SharedStateSampler}.
> @throws ClassCastException if the underlying {@link SharedStateSampler}
> does not return a {@link NormalizedGaussianSampler}.
>
> So currently the two cases can be distinguished. If we drop the
>
> source.normalized instanceof SharedStateSampler<?>
>
> check then the next part will throw a ClassCastException if either case
> is true.
>
> So the question is really what exception should be raised in the rare
> case that the operation cannot be performed (because the user created
> with a NormalizedGaussianSampler not from the library). The
> ClassCastException (which indicates the executing code did not check
> what it can do) could be caught and rethrown as an
> UnsupportedOperationException. Or the object could be tested with
> instanceof before the cast. This would at least be consistent and show
> the code knows what it is doing. So if a user calls:
>
> GaussianSampler.withUniformRandomProvider(rng)
>
> The only exception they have to handle is an
> UnsupportedOperationException. An alternative would be an
> IllegalStateException but that would indicate that the method would be
> possible but not at this time. I think this would be better than a
> ClassCastException.
>
> My vote is to make UnsupportedOperationException the only exception to
> be thrown. The ClassCastException to allow the cases to be separated is
> unnecessary.
I'm fine with that.
Regards,
Gilles
>
> I can change this in master. It is only in GaussianSampler and
> LogNormalSampler. There are already unit tests for the edge cases so
> these just have to be updated to expect the appropriate documented
> exception.
>
>
> > [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
On 31/07/2019 00:49, Gilles Sadowski wrote:
> Le mar. 30 juil. 2019 à 22:07, Alex Herbert <al...@gmail.com> a écrit :
>>
>>
>>> On 30 Jul 2019, at 19:28, Gilles Sadowski <gi...@gmail.com> wrote:
>>>
>>> Hi.
>>>
>>> Le mar. 30 juil. 2019 à 15:38, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> a écrit :
>>>> On 30/07/2019 10:56, Gilles Sadowski wrote:
>>>>> Hello.
>>>>>
>>>>> Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
>>>>>> On 10/06/2019 15:31, Gilles Sadowski wrote:
>>>>>>>>> P.S. Thinking of releasing 1.3?
>>>>>>>> Not yet. I think there are a few outstanding items [...]
>>>>> Anything missing?
>>>> - RNG-110: The PR for SharedSharedDiscrete/ContinuousSampler should have
>>>> a review [1]. I've left this while we finished GSoC phase 2 but it is ready.
>>>>
>>>> I added factory methods for all samplers. For existing samplers this is
>>>> just for consistency. Some however use internal delegates and the
>>>> factory method can return the delegate directly which is an advantage.
>>>>
>>>> One issue to look at is how I handled GaussianSampler and
>>>> LogNormalSampler. The samplers can only be shared state samplers if the
>>>> input NormalizedGaussianSampler is a shared state sampler. I handled
>>>> this with documentation. But this means a downstream user may be passed
>>>> a SharedStateContinuousSampler, use it as such and receive an exception
>>>> if it was created incorrectly.
>>> Could the library create it "incorrectly”?
>> No. All the NormalizedGaussianSamplers in the library are suitable to pass to the GaussianSampler and LogNormalSampler.
>>
>>>> The alternative is two factory methods which must have different names
>>>> due to type erasure:
>>>>
>>>> public static ContinuousSampler of(NormalizedGaussianSampler gaussian,
>>>> double scale, double shape);
>>>>
>>>> public static
>>>> <T extends NormalizedGaussianSampler &
>>>> SharedStateSampler<ContinuousSampler>>
>>>> SharedStateContinuousSampler
>>>> ofSharedState(T normalized,
>>>> double mean,
>>>> double standardDeviation) {
>>> Not nice, at first sight.
>>>
>>>> So the options are:
>>>>
>>>> - As current but has the pitfall of throwing exceptions if you do create
>>>> a one with something that does not share state (i.e. not a sampler in
>>>> the library).
>>> IIUC, it answers my question above.
>>> I would not consider too much that the interfaces defined in our "client API"
>>> module could be implemented by external codes.
>>> Even within "Commons", we do not use other components' API…
>> OK. User beware documentation. If using only our library it will not be an issue.
>>
>> So I take it that you are fine with the PR?
> Yes.
> I didn't look at all the details but is that check
> ---CUT---
> if (!(source.normalized instanceof SharedStateSampler<?>)) {
> throw new UnsupportedOperationException("The underlying
> sampler is not a SharedStateSampler");
> }
> ---CUT---
> necessary?
That was already in the codebase. I added it to support
SharedStateSampler in RNG-102.
The withUniformRandomProvider method is documented to:
@throws UnsupportedOperationException if the underlying sampler is not
a {@link SharedStateSampler}.
@throws ClassCastException if the underlying {@link SharedStateSampler}
does not return a {@link NormalizedGaussianSampler}.
So currently the two cases can be distinguished. If we drop the
source.normalized instanceof SharedStateSampler<?>
check then the next part will throw a ClassCastException if either case
is true.
So the question is really what exception should be raised in the rare
case that the operation cannot be performed (because the user created
with a NormalizedGaussianSampler not from the library). The
ClassCastException (which indicates the executing code did not check
what it can do) could be caught and rethrown as an
UnsupportedOperationException. Or the object could be tested with
instanceof before the cast. This would at least be consistent and show
the code knows what it is doing. So if a user calls:
GaussianSampler.withUniformRandomProvider(rng)
The only exception they have to handle is an
UnsupportedOperationException. An alternative would be an
IllegalStateException but that would indicate that the method would be
possible but not at this time. I think this would be better than a
ClassCastException.
My vote is to make UnsupportedOperationException the only exception to
be thrown. The ClassCastException to allow the cases to be separated is
unnecessary.
I can change this in master. It is only in GaussianSampler and
LogNormalSampler. There are already unit tests for the edge cases so
these just have to be updated to expect the appropriate documented
exception.
>
>> Just rereading it now and I’m not totally sold on the factory constructors using .of(…). Here’s Joshua Bloch on the matter [1]:
>>
>> —
>> Here are some common names for static factory methods:
>>
>> • valueOf—Returns an instance that has, loosely speaking, the same value as its parameters. Such static factories are effectively type-conversion methods.
>>
>> • of—A concise alternative to valueOf, popularized by EnumSet (Item 32).
>>
>> • getInstance—Returns an instance that is described by the parameters but cannot be said to have the same value. In the case of a singleton, getInstance takes no parameters and returns the sole instance.
>>
>> • newInstance—Like getInstance, except that newInstance guarantees that each instance returned is distinct from all others.
>>
>> • getType—Like getInstance, but used when the factory method is in a different class. Type indicates the type of object returned by the factory method.
>>
>> • newType—Like newInstance, but used when the factory method is in a different class. Type indicates the type of object returned by the factory method.
>> —
>>
>> The ’newType’ may be appropriate as the factory method is returning an instance of an interface not defined in the class. This is required for some implementations such as the PoissonSampler which returns either a SmallMean or LargeMeanPoissonSampler. So the Bloch naming could be ’newSampler’. But then we have over verbose code using ‘Sampler' twice:
>>
>> new PoissonSampler(rng, mean)
>>
>> PoissonSampler.of(rng, mean)
>>
>> PoissonSampler.newSampler(rng, mean)
>>
>> IMO the later is too verbose. If we state that the sampler is entirely defined by the input arguments to ‘of’ then it does satisfy "has, loosely speaking, the same value as its parameters”.
>>
>> So ‘of’ is OK. The only other words I like are ‘from’ or ‘with’:
>>
>> PoissonSampler.of(rng, mean)
>> PoissonSampler.from(rng, mean)
>> PoissonSampler.with(rng, mean)
>>
> "with" seems the most appropriate but has the disadvantage of not
> being in Bloch's list.
> I would then stick with "of" because "from" looks like the arguments
> will be transformed
> (and it also is not in the list...).
>
> Gilles
>
>> WDYT?
>>
>> [1] http://www.informit.com/articles/article.aspx?p=1216151 <http://www.informit.com/articles/article.aspx?p=1216151>
>>>> - Another factory method to explicitly create a SharedStateSampler using
>>>> a normalised Gaussian SharedStateSampler.
>>>>
>>>>
>>>> A few things that are 90% done:
>>>>
>>>> - RNG-85: MiddleSquareWeylSequence generator
>>>>
>>>> This is simple code and now the modifications have been made to the
>>>> ProviderBuilder it is possible to pass in a good quality increment for
>>>> the Weyl sequence. I have code to build the increment that can be added
>>>> to the SeedFactory. I did this months ago so will have to find it and
>>>> create the PR.
>>>>
>>>> - RNG-95: DiscreteUniformSampler
>>>>
>>>> I now have a reference for the alternative algorithm for choosing int
>>>> values from an interval. The code is done but should go after RNG-110 as
>>>> the code uses 5 internal delegates for different algorithms. This would
>>>> be optimised by the changes in RNG-110.
>>>>
>>>> - RNG-109: DiscreteProbabilityCollectionSampler to use an internal
>>>> DiscreteSampler
>>>>
>>>> I have to create a benchmark to compare the AliasMethodSampler against
>>>> the GuideTableSampler to see which is more suitable for a generic
>>>> probability distribution. This should not take long.
>>>>
>>>> - RNG-94: RotateRotateMultiplyXorMultiplyXor
>>>>
>>>> Simple code that is based on the same idea of using an output hash
>>>> function on a Weyl sequence like SplitMix. It is slightly slower but the
>>>> hash function is better and more robust to low complexity increments. So
>>>> we can add it using a seeded increment for the Weyl sequence. This would
>>>> take a day to add the two hash function variants.
>>>>
>>> Everything ready is fine to add before the next release, but equally
>>> fine to add after it (and do another release in 2 months if wanted)
>>> given the host of new features already implemented. :-)
>> I’ll put what I have together in the coming week or so.
>>
>>> Best,
>>> Gilles
>>>
>>>> Maybe for later:
>>>>
>>>> - RNG-90: Improve nextInt(int)
>>>>
>>>> This could use the same algorithm as RNG-95. I have not done the testing
>>>> yet. It also can be done for nextLong(long) which requires a 64-bit
>>>> product multiplication to be computed as a 128-bit result. I have code
>>>> for this but no performance tests.
>>>>
>>>> Not done but...
>>>>
>>>> The PCG family has extended generators: K-dimensionally equidistributed
>>>> or Cryptographic. These have a much larger period and the
>>>> equidistributed ones can be Jumpable.
>>>>
>>>>
>>>> [1] https://github.com/apache/commons-rng/pull/58
>>>>
>>>>
>>>>
>>>>> Regards,
>>>>> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Gilles Sadowski <gi...@gmail.com>.
Le mar. 30 juil. 2019 à 22:07, Alex Herbert <al...@gmail.com> a écrit :
>
>
>
> > On 30 Jul 2019, at 19:28, Gilles Sadowski <gi...@gmail.com> wrote:
> >
> > Hi.
> >
> > Le mar. 30 juil. 2019 à 15:38, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> a écrit :
> >>
> >> On 30/07/2019 10:56, Gilles Sadowski wrote:
> >>> Hello.
> >>>
> >>> Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
> >>>>
> >>>> On 10/06/2019 15:31, Gilles Sadowski wrote:
> >>>>>>> P.S. Thinking of releasing 1.3?
> >>>>>> Not yet. I think there are a few outstanding items [...]
> >>> Anything missing?
> >>
> >> - RNG-110: The PR for SharedSharedDiscrete/ContinuousSampler should have
> >> a review [1]. I've left this while we finished GSoC phase 2 but it is ready.
> >>
> >> I added factory methods for all samplers. For existing samplers this is
> >> just for consistency. Some however use internal delegates and the
> >> factory method can return the delegate directly which is an advantage.
> >>
> >> One issue to look at is how I handled GaussianSampler and
> >> LogNormalSampler. The samplers can only be shared state samplers if the
> >> input NormalizedGaussianSampler is a shared state sampler. I handled
> >> this with documentation. But this means a downstream user may be passed
> >> a SharedStateContinuousSampler, use it as such and receive an exception
> >> if it was created incorrectly.
> >
> > Could the library create it "incorrectly”?
>
> No. All the NormalizedGaussianSamplers in the library are suitable to pass to the GaussianSampler and LogNormalSampler.
>
> >
> >>
> >> The alternative is two factory methods which must have different names
> >> due to type erasure:
> >>
> >> public static ContinuousSampler of(NormalizedGaussianSampler gaussian,
> >> double scale, double shape);
> >>
> >> public static
> >> <T extends NormalizedGaussianSampler &
> >> SharedStateSampler<ContinuousSampler>>
> >> SharedStateContinuousSampler
> >> ofSharedState(T normalized,
> >> double mean,
> >> double standardDeviation) {
> >
> > Not nice, at first sight.
> >
> >> So the options are:
> >>
> >> - As current but has the pitfall of throwing exceptions if you do create
> >> a one with something that does not share state (i.e. not a sampler in
> >> the library).
> >
> > IIUC, it answers my question above.
> > I would not consider too much that the interfaces defined in our "client API"
> > module could be implemented by external codes.
> > Even within "Commons", we do not use other components' API…
>
> OK. User beware documentation. If using only our library it will not be an issue.
>
> So I take it that you are fine with the PR?
Yes.
I didn't look at all the details but is that check
---CUT---
if (!(source.normalized instanceof SharedStateSampler<?>)) {
throw new UnsupportedOperationException("The underlying
sampler is not a SharedStateSampler");
}
---CUT---
necessary?
> Just rereading it now and I’m not totally sold on the factory constructors using .of(…). Here’s Joshua Bloch on the matter [1]:
>
> —
> Here are some common names for static factory methods:
>
> • valueOf—Returns an instance that has, loosely speaking, the same value as its parameters. Such static factories are effectively type-conversion methods.
>
> • of—A concise alternative to valueOf, popularized by EnumSet (Item 32).
>
> • getInstance—Returns an instance that is described by the parameters but cannot be said to have the same value. In the case of a singleton, getInstance takes no parameters and returns the sole instance.
>
> • newInstance—Like getInstance, except that newInstance guarantees that each instance returned is distinct from all others.
>
> • getType—Like getInstance, but used when the factory method is in a different class. Type indicates the type of object returned by the factory method.
>
> • newType—Like newInstance, but used when the factory method is in a different class. Type indicates the type of object returned by the factory method.
> —
>
> The ’newType’ may be appropriate as the factory method is returning an instance of an interface not defined in the class. This is required for some implementations such as the PoissonSampler which returns either a SmallMean or LargeMeanPoissonSampler. So the Bloch naming could be ’newSampler’. But then we have over verbose code using ‘Sampler' twice:
>
> new PoissonSampler(rng, mean)
>
> PoissonSampler.of(rng, mean)
>
> PoissonSampler.newSampler(rng, mean)
>
> IMO the later is too verbose. If we state that the sampler is entirely defined by the input arguments to ‘of’ then it does satisfy "has, loosely speaking, the same value as its parameters”.
>
> So ‘of’ is OK. The only other words I like are ‘from’ or ‘with’:
>
> PoissonSampler.of(rng, mean)
> PoissonSampler.from(rng, mean)
> PoissonSampler.with(rng, mean)
>
"with" seems the most appropriate but has the disadvantage of not
being in Bloch's list.
I would then stick with "of" because "from" looks like the arguments
will be transformed
(and it also is not in the list...).
Gilles
> WDYT?
>
> [1] http://www.informit.com/articles/article.aspx?p=1216151 <http://www.informit.com/articles/article.aspx?p=1216151>
> >
> >> - Another factory method to explicitly create a SharedStateSampler using
> >> a normalised Gaussian SharedStateSampler.
> >>
> >>
> >> A few things that are 90% done:
> >>
> >> - RNG-85: MiddleSquareWeylSequence generator
> >>
> >> This is simple code and now the modifications have been made to the
> >> ProviderBuilder it is possible to pass in a good quality increment for
> >> the Weyl sequence. I have code to build the increment that can be added
> >> to the SeedFactory. I did this months ago so will have to find it and
> >> create the PR.
> >>
> >> - RNG-95: DiscreteUniformSampler
> >>
> >> I now have a reference for the alternative algorithm for choosing int
> >> values from an interval. The code is done but should go after RNG-110 as
> >> the code uses 5 internal delegates for different algorithms. This would
> >> be optimised by the changes in RNG-110.
> >>
> >> - RNG-109: DiscreteProbabilityCollectionSampler to use an internal
> >> DiscreteSampler
> >>
> >> I have to create a benchmark to compare the AliasMethodSampler against
> >> the GuideTableSampler to see which is more suitable for a generic
> >> probability distribution. This should not take long.
> >>
> >> - RNG-94: RotateRotateMultiplyXorMultiplyXor
> >>
> >> Simple code that is based on the same idea of using an output hash
> >> function on a Weyl sequence like SplitMix. It is slightly slower but the
> >> hash function is better and more robust to low complexity increments. So
> >> we can add it using a seeded increment for the Weyl sequence. This would
> >> take a day to add the two hash function variants.
> >>
> >
> > Everything ready is fine to add before the next release, but equally
> > fine to add after it (and do another release in 2 months if wanted)
> > given the host of new features already implemented. :-)
>
> I’ll put what I have together in the coming week or so.
>
> >
> > Best,
> > Gilles
> >
> >> Maybe for later:
> >>
> >> - RNG-90: Improve nextInt(int)
> >>
> >> This could use the same algorithm as RNG-95. I have not done the testing
> >> yet. It also can be done for nextLong(long) which requires a 64-bit
> >> product multiplication to be computed as a 128-bit result. I have code
> >> for this but no performance tests.
> >>
> >> Not done but...
> >>
> >> The PCG family has extended generators: K-dimensionally equidistributed
> >> or Cryptographic. These have a much larger period and the
> >> equidistributed ones can be Jumpable.
> >>
> >>
> >> [1] https://github.com/apache/commons-rng/pull/58
> >>
> >>
> >>
> >>>
> >>> Regards,
> >>> Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
> On 30 Jul 2019, at 19:28, Gilles Sadowski <gi...@gmail.com> wrote:
>
> Hi.
>
> Le mar. 30 juil. 2019 à 15:38, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> a écrit :
>>
>> On 30/07/2019 10:56, Gilles Sadowski wrote:
>>> Hello.
>>>
>>> Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
>>>>
>>>> On 10/06/2019 15:31, Gilles Sadowski wrote:
>>>>>>> P.S. Thinking of releasing 1.3?
>>>>>> Not yet. I think there are a few outstanding items [...]
>>> Anything missing?
>>
>> - RNG-110: The PR for SharedSharedDiscrete/ContinuousSampler should have
>> a review [1]. I've left this while we finished GSoC phase 2 but it is ready.
>>
>> I added factory methods for all samplers. For existing samplers this is
>> just for consistency. Some however use internal delegates and the
>> factory method can return the delegate directly which is an advantage.
>>
>> One issue to look at is how I handled GaussianSampler and
>> LogNormalSampler. The samplers can only be shared state samplers if the
>> input NormalizedGaussianSampler is a shared state sampler. I handled
>> this with documentation. But this means a downstream user may be passed
>> a SharedStateContinuousSampler, use it as such and receive an exception
>> if it was created incorrectly.
>
> Could the library create it "incorrectly”?
No. All the NormalizedGaussianSamplers in the library are suitable to pass to the GaussianSampler and LogNormalSampler.
>
>>
>> The alternative is two factory methods which must have different names
>> due to type erasure:
>>
>> public static ContinuousSampler of(NormalizedGaussianSampler gaussian,
>> double scale, double shape);
>>
>> public static
>> <T extends NormalizedGaussianSampler &
>> SharedStateSampler<ContinuousSampler>>
>> SharedStateContinuousSampler
>> ofSharedState(T normalized,
>> double mean,
>> double standardDeviation) {
>
> Not nice, at first sight.
>
>> So the options are:
>>
>> - As current but has the pitfall of throwing exceptions if you do create
>> a one with something that does not share state (i.e. not a sampler in
>> the library).
>
> IIUC, it answers my question above.
> I would not consider too much that the interfaces defined in our "client API"
> module could be implemented by external codes.
> Even within "Commons", we do not use other components' API…
OK. User beware documentation. If using only our library it will not be an issue.
So I take it that you are fine with the PR?
Just rereading it now and I’m not totally sold on the factory constructors using .of(…). Here’s Joshua Bloch on the matter [1]:
—
Here are some common names for static factory methods:
• valueOf—Returns an instance that has, loosely speaking, the same value as its parameters. Such static factories are effectively type-conversion methods.
• of—A concise alternative to valueOf, popularized by EnumSet (Item 32).
• getInstance—Returns an instance that is described by the parameters but cannot be said to have the same value. In the case of a singleton, getInstance takes no parameters and returns the sole instance.
• newInstance—Like getInstance, except that newInstance guarantees that each instance returned is distinct from all others.
• getType—Like getInstance, but used when the factory method is in a different class. Type indicates the type of object returned by the factory method.
• newType—Like newInstance, but used when the factory method is in a different class. Type indicates the type of object returned by the factory method.
—
The ’newType’ may be appropriate as the factory method is returning an instance of an interface not defined in the class. This is required for some implementations such as the PoissonSampler which returns either a SmallMean or LargeMeanPoissonSampler. So the Bloch naming could be ’newSampler’. But then we have over verbose code using ‘Sampler' twice:
new PoissonSampler(rng, mean)
PoissonSampler.of(rng, mean)
PoissonSampler.newSampler(rng, mean)
IMO the later is too verbose. If we state that the sampler is entirely defined by the input arguments to ‘of’ then it does satisfy "has, loosely speaking, the same value as its parameters”.
So ‘of’ is OK. The only other words I like are ‘from’ or ‘with’:
PoissonSampler.of(rng, mean)
PoissonSampler.from(rng, mean)
PoissonSampler.with(rng, mean)
WDYT?
[1] http://www.informit.com/articles/article.aspx?p=1216151 <http://www.informit.com/articles/article.aspx?p=1216151>
>
>> - Another factory method to explicitly create a SharedStateSampler using
>> a normalised Gaussian SharedStateSampler.
>>
>>
>> A few things that are 90% done:
>>
>> - RNG-85: MiddleSquareWeylSequence generator
>>
>> This is simple code and now the modifications have been made to the
>> ProviderBuilder it is possible to pass in a good quality increment for
>> the Weyl sequence. I have code to build the increment that can be added
>> to the SeedFactory. I did this months ago so will have to find it and
>> create the PR.
>>
>> - RNG-95: DiscreteUniformSampler
>>
>> I now have a reference for the alternative algorithm for choosing int
>> values from an interval. The code is done but should go after RNG-110 as
>> the code uses 5 internal delegates for different algorithms. This would
>> be optimised by the changes in RNG-110.
>>
>> - RNG-109: DiscreteProbabilityCollectionSampler to use an internal
>> DiscreteSampler
>>
>> I have to create a benchmark to compare the AliasMethodSampler against
>> the GuideTableSampler to see which is more suitable for a generic
>> probability distribution. This should not take long.
>>
>> - RNG-94: RotateRotateMultiplyXorMultiplyXor
>>
>> Simple code that is based on the same idea of using an output hash
>> function on a Weyl sequence like SplitMix. It is slightly slower but the
>> hash function is better and more robust to low complexity increments. So
>> we can add it using a seeded increment for the Weyl sequence. This would
>> take a day to add the two hash function variants.
>>
>
> Everything ready is fine to add before the next release, but equally
> fine to add after it (and do another release in 2 months if wanted)
> given the host of new features already implemented. :-)
I’ll put what I have together in the coming week or so.
>
> Best,
> Gilles
>
>> Maybe for later:
>>
>> - RNG-90: Improve nextInt(int)
>>
>> This could use the same algorithm as RNG-95. I have not done the testing
>> yet. It also can be done for nextLong(long) which requires a 64-bit
>> product multiplication to be computed as a 128-bit result. I have code
>> for this but no performance tests.
>>
>> Not done but...
>>
>> The PCG family has extended generators: K-dimensionally equidistributed
>> or Cryptographic. These have a much larger period and the
>> equidistributed ones can be Jumpable.
>>
>>
>> [1] https://github.com/apache/commons-rng/pull/58
>>
>>
>>
>>>
>>> Regards,
>>> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le mar. 30 juil. 2019 à 15:38, Alex Herbert <al...@gmail.com> a écrit :
>
> On 30/07/2019 10:56, Gilles Sadowski wrote:
> > Hello.
> >
> > Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
> >>
> >> On 10/06/2019 15:31, Gilles Sadowski wrote:
> >>>>> P.S. Thinking of releasing 1.3?
> >>>> Not yet. I think there are a few outstanding items [...]
> > Anything missing?
>
> - RNG-110: The PR for SharedSharedDiscrete/ContinuousSampler should have
> a review [1]. I've left this while we finished GSoC phase 2 but it is ready.
>
> I added factory methods for all samplers. For existing samplers this is
> just for consistency. Some however use internal delegates and the
> factory method can return the delegate directly which is an advantage.
>
> One issue to look at is how I handled GaussianSampler and
> LogNormalSampler. The samplers can only be shared state samplers if the
> input NormalizedGaussianSampler is a shared state sampler. I handled
> this with documentation. But this means a downstream user may be passed
> a SharedStateContinuousSampler, use it as such and receive an exception
> if it was created incorrectly.
Could the library create it "incorrectly"?
>
> The alternative is two factory methods which must have different names
> due to type erasure:
>
> public static ContinuousSampler of(NormalizedGaussianSampler gaussian,
> double scale, double shape);
>
> public static
> <T extends NormalizedGaussianSampler &
> SharedStateSampler<ContinuousSampler>>
> SharedStateContinuousSampler
> ofSharedState(T normalized,
> double mean,
> double standardDeviation) {
Not nice, at first sight.
> So the options are:
>
> - As current but has the pitfall of throwing exceptions if you do create
> a one with something that does not share state (i.e. not a sampler in
> the library).
IIUC, it answers my question above.
I would not consider too much that the interfaces defined in our "client API"
module could be implemented by external codes.
Even within "Commons", we do not use other components' API...
> - Another factory method to explicitly create a SharedStateSampler using
> a normalised Gaussian SharedStateSampler.
>
>
> A few things that are 90% done:
>
> - RNG-85: MiddleSquareWeylSequence generator
>
> This is simple code and now the modifications have been made to the
> ProviderBuilder it is possible to pass in a good quality increment for
> the Weyl sequence. I have code to build the increment that can be added
> to the SeedFactory. I did this months ago so will have to find it and
> create the PR.
>
> - RNG-95: DiscreteUniformSampler
>
> I now have a reference for the alternative algorithm for choosing int
> values from an interval. The code is done but should go after RNG-110 as
> the code uses 5 internal delegates for different algorithms. This would
> be optimised by the changes in RNG-110.
>
> - RNG-109: DiscreteProbabilityCollectionSampler to use an internal
> DiscreteSampler
>
> I have to create a benchmark to compare the AliasMethodSampler against
> the GuideTableSampler to see which is more suitable for a generic
> probability distribution. This should not take long.
>
> - RNG-94: RotateRotateMultiplyXorMultiplyXor
>
> Simple code that is based on the same idea of using an output hash
> function on a Weyl sequence like SplitMix. It is slightly slower but the
> hash function is better and more robust to low complexity increments. So
> we can add it using a seeded increment for the Weyl sequence. This would
> take a day to add the two hash function variants.
>
Everything ready is fine to add before the next release, but equally
fine to add after it (and do another release in 2 months if wanted)
given the host of new features already implemented. :-)
Best,
Gilles
> Maybe for later:
>
> - RNG-90: Improve nextInt(int)
>
> This could use the same algorithm as RNG-95. I have not done the testing
> yet. It also can be done for nextLong(long) which requires a 64-bit
> product multiplication to be computed as a 128-bit result. I have code
> for this but no performance tests.
>
> Not done but...
>
> The PCG family has extended generators: K-dimensionally equidistributed
> or Cryptographic. These have a much larger period and the
> equidistributed ones can be Jumpable.
>
>
> [1] https://github.com/apache/commons-rng/pull/58
>
>
>
> >
> > Regards,
> > Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
On 30/07/2019 10:56, Gilles Sadowski wrote:
> Hello.
>
> Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
>>
>> On 10/06/2019 15:31, Gilles Sadowski wrote:
>>>>> P.S. Thinking of releasing 1.3?
>>>> Not yet. I think there are a few outstanding items [...]
> Anything missing?
- RNG-110: The PR for SharedSharedDiscrete/ContinuousSampler should have
a review [1]. I've left this while we finished GSoC phase 2 but it is ready.
I added factory methods for all samplers. For existing samplers this is
just for consistency. Some however use internal delegates and the
factory method can return the delegate directly which is an advantage.
One issue to look at is how I handled GaussianSampler and
LogNormalSampler. The samplers can only be shared state samplers if the
input NormalizedGaussianSampler is a shared state sampler. I handled
this with documentation. But this means a downstream user may be passed
a SharedStateContinuousSampler, use it as such and receive an exception
if it was created incorrectly.
The alternative is two factory methods which must have different names
due to type erasure:
public static ContinuousSampler of(NormalizedGaussianSampler gaussian,
double scale, double shape);
public static
<T extends NormalizedGaussianSampler &
SharedStateSampler<ContinuousSampler>>
SharedStateContinuousSampler
ofSharedState(T normalized,
double mean,
double standardDeviation) {
So the options are:
- As current but has the pitfall of throwing exceptions if you do create
a one with something that does not share state (i.e. not a sampler in
the library).
- Another factory method to explicitly create a SharedStateSampler using
a normalised Gaussian SharedStateSampler.
A few things that are 90% done:
- RNG-85: MiddleSquareWeylSequence generator
This is simple code and now the modifications have been made to the
ProviderBuilder it is possible to pass in a good quality increment for
the Weyl sequence. I have code to build the increment that can be added
to the SeedFactory. I did this months ago so will have to find it and
create the PR.
- RNG-95: DiscreteUniformSampler
I now have a reference for the alternative algorithm for choosing int
values from an interval. The code is done but should go after RNG-110 as
the code uses 5 internal delegates for different algorithms. This would
be optimised by the changes in RNG-110.
- RNG-109: DiscreteProbabilityCollectionSampler to use an internal
DiscreteSampler
I have to create a benchmark to compare the AliasMethodSampler against
the GuideTableSampler to see which is more suitable for a generic
probability distribution. This should not take long.
- RNG-94: RotateRotateMultiplyXorMultiplyXor
Simple code that is based on the same idea of using an output hash
function on a Weyl sequence like SplitMix. It is slightly slower but the
hash function is better and more robust to low complexity increments. So
we can add it using a seeded increment for the Weyl sequence. This would
take a day to add the two hash function variants.
Maybe for later:
- RNG-90: Improve nextInt(int)
This could use the same algorithm as RNG-95. I have not done the testing
yet. It also can be done for nextLong(long) which requires a 64-bit
product multiplication to be computed as a 128-bit result. I have code
for this but no performance tests.
Not done but...
The PCG family has extended generators: K-dimensionally equidistributed
or Cryptographic. These have a much larger period and the
equidistributed ones can be Jumpable.
[1] https://github.com/apache/commons-rng/pull/58
>
> Regards,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
>
>
> On 10/06/2019 15:31, Gilles Sadowski wrote:
> >>> P.S. Thinking of releasing 1.3?
> >> Not yet. I think there are a few outstanding items [...]
Anything missing?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
On 10/06/2019 18:05, Gilles Sadowski wrote:
> Hi.
>
> Le lun. 10 juin 2019 à 18:33, Alex Herbert <al...@gmail.com> a écrit :
>>
>> On 10/06/2019 17:18, Gilles Sadowski wrote:
>>> Le lun. 10 juin 2019 à 17:56, Alex Herbert <al...@gmail.com> a écrit :
>>>> On 10/06/2019 16:34, Gilles Sadowski wrote:
>>>>> Hello.
>>>>>
>>>>> Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
>>>>>> On 10/06/2019 15:31, Gilles Sadowski wrote:
>>>>>>>>> P.S. Thinking of releasing 1.3?
>>>>>>>> Not yet. I think there are a few outstanding items that work together
>>>>>>>> for the multi-threaded focus of the new code and the new generators:
>>>>>>> Sure but some of them could be postponed, if just to RERO.
>>>>>>>
>>>>>>>> - RNG-98: LongJumpable (easy)
>>>>>>>>
>>>>>>>> - RNG-102: SharedStateSampler (lots of easy work)
>>>>>>>>
>>>>>>>> - RNG-106: XorShiRo generators require non-zero input seeds
>>>>>>>>
>>>>>>>> (I'm still thinking about the best way to do this. The Jira ticket
>>>>>>>> suggests a speed test to at least know the implications of different ideas.)
>>>>>>> This is only when using the "SeedFactory" (?). [Otherwise, it's the
>>>>>>> user's responsibility to construct an appropriate seed.]
>>>>>>>
>>>>>>> Couldn't we just check that the output of the internal generator is not
>>>>>>> all zero (and call it again if it is)?
>>>>>> Yes. The worse case scenario is a 1 in 2^64 collision rate with zero.
>>>>>> All other generators have larger state sizes. So this would be fine. An
>>>>>> alternative would be to set a single bit to non zero. This throws away 1
>>>>>> bit of randomness from the seed and will always work without any
>>>>>> recursion. But it makes the seed worse. The ideas are in the header for
>>>>>> this Jira ticket:
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/RNG-106
>>>>>>
>>>>>> I'll fix this soon.
>>>>>>
>>>>>> The other item I did not mention is outcome from RNG-104. This seems to
>>>>>> indicate that using System.identityHashCode(new Object()) is not as good
>>>>>> a mixer as a ThreadLocal random generator, both for speed and also
>>>>>> quality. I'm currently testing Well44497b ^ SplitMix in BigCrush but I
>>>>>> think this should replace the identity hash code method.
>>>>> Didn't you also suggest to use XOR_SHIFT_1024_PHI (given the
>>>>> large enough period, better speed score on BigCrush)?
>>>> Yes. I'm still thinking about this. My initial calculations were based
>>>> on the length of time it would take to sample all the seeds from the
>>>> generator. Below we consider the number of possible seeds required and
>>>> produced:
>>>>
>>>> The Well4497b seed size is 1391 of ints so there are (2^32)^1391
>>>> possible seeds of random bits, or 2^1423.
>>>>
>>>> The XorShift1024 period is (2^1024 -1) of longs so there are (2^64)^1024
>>>> random bits output before repeat (ideally as the period may be shorter).
>>>> So the bit output is max 2^1088 before repeat.
>>>>
>>>> Assuming the output from XorShift1024 is truly random-per-bit it cannot
>>>> output enough unique seeds to cover all those required by the Well44497b
>>>> generator.
>>>>
>>>> But currently we seed using a maximum of 128 values and leave the rest
>>>> to the self-seeding routine in the base generator. For a long array this
>>>> is (2^64)^128 = 2^192, and only 2^160 for int arrays. So the
>>>> XorShift1024 generator can output enough bits to create all the seeds
>>>> that the SeedFactory currently produces.
>>> I'd think (roughly) that's a good enough compromise for a
>>> "convenience" routine. [Stringent requirements can be met
>>> explicitly otherwise.]
>> Sorry. I've done that wrong:
>>
>> (a^b)^c = a^(b^c) not a^(b+c)
>>
>> Well44497b seed size is 1391 of ints so there are 32*1391 (44512) bits
>> in the seed, and so 2^44512 possible seeds.
>>
>> XorShift1024 period is (2^1024 -1) of longs so there are 64*2^1024
>> random bits output before repeat, or 2^6 * 2^1024 = 2^1030.
>>
>> Not enough.
>>
>> The max seed size is long[128] which is 64*128 bits in the seed, and so
>> 2^8192 possible seeds.
>>
>> Still not enough.
>>
>> So even though it would take 2^969 years to repeat the period of a
>> XorShift1024 generator if sampled 10 billion time a second [1], it
>> cannot produce every possible seed currently required.
>>
>> So this is a dilemma. Choose a generator that can theoretically output
>> all the seeds required, even though you could never use them, or choose
>> a faster generator that can still output more seeds than you could
>> possibly use.
> How about using both?
> Generate the first element of the seed array (or the single "long" seed)
> from Well44497b and the rest from XorShift1024?
I think this just splits the generation of a seed of n bits into two
seeds of x and n-x bits. So if the requirement is to generate an array
long[128] you then have long + long[127]. And the number of combinations
of long[127] is still too big for XorShift1024.
I'd be happy with XorShift1024 as it cannot realistically be repeated
and outputs better seed quality. It could be documented that using
SecureRandom to access the system pool of entropy would produce a high
quality seed but would be slow and ThreadLocalRandom can produce the
seed faster but with a short period. Perhaps it could be tied to
Abhishek's demonstration of the speed of the SecureRandom algorithms in
Java 9 on a new page in the user guide?
I'm running the benchmarks again with both generators to see what the
performance effect is of switching. I'll revisit this when I have the
results.
>
> Gilles
>
>> [1]
>> https://issues.apache.org/jira/browse/RNG-104?focusedCommentId=16857619&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16857619
>>
>>>> So a switch to using XorShift1024 would satisfy current requirements
>>>> and, given it passes BigCrush, would remove the requirement to mix the
>>>> output with a second generator. (IIUC the purpose is to improve
>>>> randomness of Well44497.)
>>> Is it really necessary to have the utmost randomness for generating
>>> seeds? [It seems that the (rare) correlations of a seed used by some
>>> RNG instance with a seed used by some other instance will be "diluted"
>>> in the different sequences generated by the two instances.]
>>>
>>> Whatever, replacing with XorShift1024 will gain on that too, and
>>> as you note, keep the SeedFactory simpler (no mix).
>>>
>>> Regards,
>>> Gilles
>>>
>>>>> [...]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le lun. 10 juin 2019 à 18:33, Alex Herbert <al...@gmail.com> a écrit :
>
>
> On 10/06/2019 17:18, Gilles Sadowski wrote:
> > Le lun. 10 juin 2019 à 17:56, Alex Herbert <al...@gmail.com> a écrit :
> >>
> >> On 10/06/2019 16:34, Gilles Sadowski wrote:
> >>> Hello.
> >>>
> >>> Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
> >>>> On 10/06/2019 15:31, Gilles Sadowski wrote:
> >>>>>>> P.S. Thinking of releasing 1.3?
> >>>>>> Not yet. I think there are a few outstanding items that work together
> >>>>>> for the multi-threaded focus of the new code and the new generators:
> >>>>> Sure but some of them could be postponed, if just to RERO.
> >>>>>
> >>>>>> - RNG-98: LongJumpable (easy)
> >>>>>>
> >>>>>> - RNG-102: SharedStateSampler (lots of easy work)
> >>>>>>
> >>>>>> - RNG-106: XorShiRo generators require non-zero input seeds
> >>>>>>
> >>>>>> (I'm still thinking about the best way to do this. The Jira ticket
> >>>>>> suggests a speed test to at least know the implications of different ideas.)
> >>>>> This is only when using the "SeedFactory" (?). [Otherwise, it's the
> >>>>> user's responsibility to construct an appropriate seed.]
> >>>>>
> >>>>> Couldn't we just check that the output of the internal generator is not
> >>>>> all zero (and call it again if it is)?
> >>>> Yes. The worse case scenario is a 1 in 2^64 collision rate with zero.
> >>>> All other generators have larger state sizes. So this would be fine. An
> >>>> alternative would be to set a single bit to non zero. This throws away 1
> >>>> bit of randomness from the seed and will always work without any
> >>>> recursion. But it makes the seed worse. The ideas are in the header for
> >>>> this Jira ticket:
> >>>>
> >>>> https://issues.apache.org/jira/browse/RNG-106
> >>>>
> >>>> I'll fix this soon.
> >>>>
> >>>> The other item I did not mention is outcome from RNG-104. This seems to
> >>>> indicate that using System.identityHashCode(new Object()) is not as good
> >>>> a mixer as a ThreadLocal random generator, both for speed and also
> >>>> quality. I'm currently testing Well44497b ^ SplitMix in BigCrush but I
> >>>> think this should replace the identity hash code method.
> >>> Didn't you also suggest to use XOR_SHIFT_1024_PHI (given the
> >>> large enough period, better speed score on BigCrush)?
> >> Yes. I'm still thinking about this. My initial calculations were based
> >> on the length of time it would take to sample all the seeds from the
> >> generator. Below we consider the number of possible seeds required and
> >> produced:
> >>
> >> The Well4497b seed size is 1391 of ints so there are (2^32)^1391
> >> possible seeds of random bits, or 2^1423.
> >>
> >> The XorShift1024 period is (2^1024 -1) of longs so there are (2^64)^1024
> >> random bits output before repeat (ideally as the period may be shorter).
> >> So the bit output is max 2^1088 before repeat.
> >>
> >> Assuming the output from XorShift1024 is truly random-per-bit it cannot
> >> output enough unique seeds to cover all those required by the Well44497b
> >> generator.
> >>
> >> But currently we seed using a maximum of 128 values and leave the rest
> >> to the self-seeding routine in the base generator. For a long array this
> >> is (2^64)^128 = 2^192, and only 2^160 for int arrays. So the
> >> XorShift1024 generator can output enough bits to create all the seeds
> >> that the SeedFactory currently produces.
> > I'd think (roughly) that's a good enough compromise for a
> > "convenience" routine. [Stringent requirements can be met
> > explicitly otherwise.]
>
> Sorry. I've done that wrong:
>
> (a^b)^c = a^(b^c) not a^(b+c)
>
> Well44497b seed size is 1391 of ints so there are 32*1391 (44512) bits
> in the seed, and so 2^44512 possible seeds.
>
> XorShift1024 period is (2^1024 -1) of longs so there are 64*2^1024
> random bits output before repeat, or 2^6 * 2^1024 = 2^1030.
>
> Not enough.
>
> The max seed size is long[128] which is 64*128 bits in the seed, and so
> 2^8192 possible seeds.
>
> Still not enough.
>
> So even though it would take 2^969 years to repeat the period of a
> XorShift1024 generator if sampled 10 billion time a second [1], it
> cannot produce every possible seed currently required.
>
> So this is a dilemma. Choose a generator that can theoretically output
> all the seeds required, even though you could never use them, or choose
> a faster generator that can still output more seeds than you could
> possibly use.
How about using both?
Generate the first element of the seed array (or the single "long" seed)
from Well44497b and the rest from XorShift1024?
Gilles
>
> [1]
> https://issues.apache.org/jira/browse/RNG-104?focusedCommentId=16857619&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16857619
>
> >
> >> So a switch to using XorShift1024 would satisfy current requirements
> >> and, given it passes BigCrush, would remove the requirement to mix the
> >> output with a second generator. (IIUC the purpose is to improve
> >> randomness of Well44497.)
> > Is it really necessary to have the utmost randomness for generating
> > seeds? [It seems that the (rare) correlations of a seed used by some
> > RNG instance with a seed used by some other instance will be "diluted"
> > in the different sequences generated by the two instances.]
> >
> > Whatever, replacing with XorShift1024 will gain on that too, and
> > as you note, keep the SeedFactory simpler (no mix).
> >
> > Regards,
> > Gilles
> >
> >>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
On 10/06/2019 17:18, Gilles Sadowski wrote:
> Le lun. 10 juin 2019 à 17:56, Alex Herbert <al...@gmail.com> a écrit :
>>
>> On 10/06/2019 16:34, Gilles Sadowski wrote:
>>> Hello.
>>>
>>> Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
>>>> On 10/06/2019 15:31, Gilles Sadowski wrote:
>>>>>>> P.S. Thinking of releasing 1.3?
>>>>>> Not yet. I think there are a few outstanding items that work together
>>>>>> for the multi-threaded focus of the new code and the new generators:
>>>>> Sure but some of them could be postponed, if just to RERO.
>>>>>
>>>>>> - RNG-98: LongJumpable (easy)
>>>>>>
>>>>>> - RNG-102: SharedStateSampler (lots of easy work)
>>>>>>
>>>>>> - RNG-106: XorShiRo generators require non-zero input seeds
>>>>>>
>>>>>> (I'm still thinking about the best way to do this. The Jira ticket
>>>>>> suggests a speed test to at least know the implications of different ideas.)
>>>>> This is only when using the "SeedFactory" (?). [Otherwise, it's the
>>>>> user's responsibility to construct an appropriate seed.]
>>>>>
>>>>> Couldn't we just check that the output of the internal generator is not
>>>>> all zero (and call it again if it is)?
>>>> Yes. The worse case scenario is a 1 in 2^64 collision rate with zero.
>>>> All other generators have larger state sizes. So this would be fine. An
>>>> alternative would be to set a single bit to non zero. This throws away 1
>>>> bit of randomness from the seed and will always work without any
>>>> recursion. But it makes the seed worse. The ideas are in the header for
>>>> this Jira ticket:
>>>>
>>>> https://issues.apache.org/jira/browse/RNG-106
>>>>
>>>> I'll fix this soon.
>>>>
>>>> The other item I did not mention is outcome from RNG-104. This seems to
>>>> indicate that using System.identityHashCode(new Object()) is not as good
>>>> a mixer as a ThreadLocal random generator, both for speed and also
>>>> quality. I'm currently testing Well44497b ^ SplitMix in BigCrush but I
>>>> think this should replace the identity hash code method.
>>> Didn't you also suggest to use XOR_SHIFT_1024_PHI (given the
>>> large enough period, better speed score on BigCrush)?
>> Yes. I'm still thinking about this. My initial calculations were based
>> on the length of time it would take to sample all the seeds from the
>> generator. Below we consider the number of possible seeds required and
>> produced:
>>
>> The Well4497b seed size is 1391 of ints so there are (2^32)^1391
>> possible seeds of random bits, or 2^1423.
>>
>> The XorShift1024 period is (2^1024 -1) of longs so there are (2^64)^1024
>> random bits output before repeat (ideally as the period may be shorter).
>> So the bit output is max 2^1088 before repeat.
>>
>> Assuming the output from XorShift1024 is truly random-per-bit it cannot
>> output enough unique seeds to cover all those required by the Well44497b
>> generator.
>>
>> But currently we seed using a maximum of 128 values and leave the rest
>> to the self-seeding routine in the base generator. For a long array this
>> is (2^64)^128 = 2^192, and only 2^160 for int arrays. So the
>> XorShift1024 generator can output enough bits to create all the seeds
>> that the SeedFactory currently produces.
> I'd think (roughly) that's a good enough compromise for a
> "convenience" routine. [Stringent requirements can be met
> explicitly otherwise.]
Sorry. I've done that wrong:
(a^b)^c = a^(b^c) not a^(b+c)
Well44497b seed size is 1391 of ints so there are 32*1391 (44512) bits
in the seed, and so 2^44512 possible seeds.
XorShift1024 period is (2^1024 -1) of longs so there are 64*2^1024
random bits output before repeat, or 2^6 * 2^1024 = 2^1030.
Not enough.
The max seed size is long[128] which is 64*128 bits in the seed, and so
2^8192 possible seeds.
Still not enough.
So even though it would take 2^969 years to repeat the period of a
XorShift1024 generator if sampled 10 billion time a second [1], it
cannot produce every possible seed currently required.
So this is a dilemma. Choose a generator that can theoretically output
all the seeds required, even though you could never use them, or choose
a faster generator that can still output more seeds than you could
possibly use.
[1]
https://issues.apache.org/jira/browse/RNG-104?focusedCommentId=16857619&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16857619
>
>> So a switch to using XorShift1024 would satisfy current requirements
>> and, given it passes BigCrush, would remove the requirement to mix the
>> output with a second generator. (IIUC the purpose is to improve
>> randomness of Well44497.)
> Is it really necessary to have the utmost randomness for generating
> seeds? [It seems that the (rare) correlations of a seed used by some
> RNG instance with a seed used by some other instance will be "diluted"
> in the different sequences generated by the two instances.]
>
> Whatever, replacing with XorShift1024 will gain on that too, and
> as you note, keep the SeedFactory simpler (no mix).
>
> Regards,
> Gilles
>
>>> [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
>
>
> On 10/06/2019 15:31, Gilles Sadowski wrote:
> >>> P.S. Thinking of releasing 1.3?
> >> Not yet. I think there are a few outstanding items that work together
> >> for the multi-threaded focus of the new code and the new generators:
> > Sure but some of them could be postponed, if just to RERO.
> >
> >> - RNG-98: LongJumpable (easy)
> >>
> >> - RNG-102: SharedStateSampler (lots of easy work)
> >>
> >> - RNG-106: XorShiRo generators require non-zero input seeds
> >>
> >> (I'm still thinking about the best way to do this. The Jira ticket
> >> suggests a speed test to at least know the implications of different ideas.)
> > This is only when using the "SeedFactory" (?). [Otherwise, it's the
> > user's responsibility to construct an appropriate seed.]
> >
> > Couldn't we just check that the output of the internal generator is not
> > all zero (and call it again if it is)?
>
> Yes. The worse case scenario is a 1 in 2^64 collision rate with zero.
> All other generators have larger state sizes. So this would be fine. An
> alternative would be to set a single bit to non zero. This throws away 1
> bit of randomness from the seed and will always work without any
> recursion. But it makes the seed worse. The ideas are in the header for
> this Jira ticket:
>
> https://issues.apache.org/jira/browse/RNG-106
>
> I'll fix this soon.
>
> The other item I did not mention is outcome from RNG-104. This seems to
> indicate that using System.identityHashCode(new Object()) is not as good
> a mixer as a ThreadLocal random generator, both for speed and also
> quality. I'm currently testing Well44497b ^ SplitMix in BigCrush but I
> think this should replace the identity hash code method.
Didn't you also suggest to use XOR_SHIFT_1024_PHI (given the
large enough period, better speed score on BigCrush)?
> It also shows that using a synchronized block on each call to the
> generator is slow. Seed arrays can be built 2x faster using 8 calls to
> the generator per synchronisation when single threaded. When
> multi-threaded it is much better. I'm still testing to find a good
> estimate of the optimum block size for all scenarios.
+1
> >
> >> There are also outstanding items I've partially looked at:
> >>
> >> - RNG-90: Improve nextInt(int) and nextLong(long) for powers of 2
> >>
> >> I paused testing this as I moved on to other things. The easy fix is to
> >> copy the JDK SplittableRandom implementation. But it requires a
> >> generator with good quality lower bits. It would have to be worked
> >> around for generators that have low period lower bits. So this requires
> >> digesting all the results of BigCrush to determine which generators can
> >> use the new method and which should not change. Then is the decision on
> >> how to do it.
> > A second-order improvement IMHO.
> Which is why I moved on. Note that the speed of using the new approach
> is much faster for powers of 2.
> >
> >> - RNG-95: DiscreteUniformSampler
> >>
> >> I have code that computes a discrete uniform sample using multiply and
> >> not the modulus algorithm used in nextInt(int). However I cannot find
> >> anywhere that uses the method so currently I am the author. I cannot
> >> imagine no-one has done this before
> > Interesting...
> >
> >> but to be on the safe side it may be
> >> better to put it in as an alternative DiscreteSampler, e.g.
> >> FastDiscreteUniformSampler and leave the current DiscreteUniformSampler
> >> to default to using nextInt(int).
> > I'm wary of this naming after the "FastMath" experience.
> > Perhaps safer is to puti in a feature branch, until you are sure that
> > it can replace the current implementation.
> I couldn't think of a name describing the method. It is related to the
> discrete Weyl sequence so perhaps WeylDiscreteUniformSampler. It's a
> work in progress...
> >
> >> Speed tests show it is faster, and can be over 2-fold faster when the
> >> rejection algorithm in nextInt(int) is worse case.
> >>
> >> - RNG-100: GuideTableDiscreteSampler
> >>
> >> All done but should be rebased and put in a PR
> >>
> >> - RNG-99: AliasMethodDiscreteSampler
> >>
> >> Also done but is very hard to find a probability distribution where it
> >> is better than GuideTableDiscreteSampler. It could be added as a
> >> reference implementation.
> > +1
> >
> >> - RNG-XX: Use GuideTableDiscreteSampler behind
> >> DiscreteProbabilityCollectionSampler<T>
> >>
> >> It will be faster and remove the binarySearch method from that class.
> > +1
> >
> >> I also thought we wait until end of GSoC and so new generators could
> >> also be included.
> > I'd rather not wait.
> > There are many improvements and new features (thanks to you!)
> > that warrant a release.
> OK. I'll get on with fixing the "must haves".
:-)
> > And I also think that releasing his GSoC work would be a nice
> > achievement task for Abhishek (after he will have assisted at
> > how it worked out for 1.3).
> >
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le ven. 30 août 2019 à 15:29, Alex Herbert <al...@gmail.com> a écrit :
>
>
> On 30/08/2019 14:22, Gilles Sadowski wrote:
> > Hi.
> >
> > Le ven. 30 août 2019 à 15:11, Abhishek Dhadwal <dh...@gmail.com> a écrit :
> >> Hello,
> >>
> >> What would be the deadline for the release ?
> > There is no deadline, but the sooner the better.
> > The many new features deserve a release.
> >
> >> If it’s not too early I could resolve RNG-111 (https://issues.apache.org/jira/browse/RNG-111) over the next few days. I couldn’t work on it before due to back to back college project evaluations and my mid term examinations (which get over by tomorrow).
> > Great.
>
> My take on this...
>
> There is nothing outstanding.
>
> It would be nice to get the JSF generator (RNG-111) put in as it is a
> compliment to the SFC generator I just added (RNG-112). Let's give
> Abhishek some time to finish this work.
+1
> All the speed tests will need to be updated for the site. I have been
> considering if we should have more 'real' benchmarks. Currently we
> benchmark a single call to each method in UniformRandomProvider using
> the pattern recommended by JMH. I've built these benchmarks to require
> post-processing to subtract the JMH overhead. So the tables for the
> user-guide can either put in the raw data or as is currently done put in
> the relative scores following post-processing to subtract the JMH baseline.
No strong preference.
But I don't think that the userguide needs to expose details such as
baseline subtraction.
>
> However it is unclear if the current benchmark represents real-world
> observable differences. A candidate for a 'real' world test for
> nextInt() is a shuffle benchmark. This can be done using an actual array
> or just by generating indices to swap.
How is this more real world than the above (i.e. generating *one* int)?
> When using an actual array it is
> more realistic but relative performance is size dependent. When the
> array gets large the method is slowed by cache misses during the actual
> swap of the data. So the shuffle benchmark results would have to be
> report for different sizes.
A perhaps better illustration would be to report the time it takes to
compute pi to a certain accuracy (cf. class "ComputePi" in module
"commons-rng-examples").
> The other method to target would be nextLong(). I cannot think of a real
> use case for this so instead we could target nextDouble(). I tried a
> benchmark using a SmallMeanPoissonSampler which calls nextDouble() n+1
> times for a mean of n. This is a good start point for an algorithm that
> puts the random numbers to use. However it may be replicating what is
> already listed for the comparison of the different normalised Gaussian
> samplers. Currently the user guide has a table comparing the 3 different
> Gaussian samplers and then another table for the Marsaglia normalised
> Gaussian sampler. (Note: There is some redundancy here.) Since all the
> Gaussian samplers use nextDouble()/nextLong() then the output of this
> table is a rough guide to the relative speed of the RNG on 64-bit output.
>
> I would suggest dropping the table showing the Marsaglia normalised
> Gaussian sampler (it is redundant given the comparison of different
> Gaussian samplers)
+1
> and adding a shuffle benchmark for different array sizes.
-0
(cf. above)
>
> More on RNG-32 below...
>
> >
> > Best,
> > Gilles
> >
> >> Regards,
> >> Abhishek
> >>
> >> Sent from Mail for Windows 10
> >>
> >> From: Gilles Sadowski
> >> Sent: 30 August 2019 17:22
> >> To: Commons Developers List
> >> Subject: Re: [rng] Releasing 1.3
> >>
> >> Hi.
> >>
> >> Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
> >>>
> >>> On 10/06/2019 15:31, Gilles Sadowski wrote:
> >>>>>> P.S. Thinking of releasing 1.3?
> >>>>> Not yet. I think there are a few outstanding items [...]
> >> Status?
> >>
> >> In particular could we resolve
> >> https://issues.apache.org/jira/projects/RNG/issues/RNG-32
> >> and all its sub-tasks following the work done through GSoC?
>
> This could be rounded up. Each tickets need some finishing details.
>
>
> RNG-16: We did test LCGs that outperform the 48-bit LCG of
> Java.util.Random. Any 64-bit LCG which returns the upper 32-bits should
> be an OK generator. The ones we tested using increments 1 (Musl) and
> 1442695040888963407 (from Knuth) perform as:
>
> ---------
> DieHarder
> ---------
> KnuthShiftLCG : 1, 0, 0, 0, 0
> MuslShiftLCG : 0, 0, 0, 0, 0
> -------
> TestU01
> -------
> MuslShiftLCG : 15, 16, 15, 14, 15
> KnuthShiftLCG : 14, 11, 16, 17, 14
>
> They are bad on BigCrush but will probably be the fastest 32-bit
> generators in the library if a user wants a very fast 32-bit generator
> for simple random stuff (e.g. generating filenames).
If doing IO afterwards, generation time will be fairly insignificant.
> A single example
> would at least be a reference point and a comparison for the PCG
> generators that use a 64-bit LCG and then permute the output. It is
> possible to create one using the abstract class for the PCG generators:
>
> public class LcgShift32 extends AbstractPcg6432 {
> public LcgShift32(long[] seed) {
> super(seed);
> }
>
> @Override
> protected int transform(long x) {
> return (int)(x >>> 32);
> }
> }
Is this faster than generating a "long" with a good 64-bit generator
and use it whole to get two "int"s?
> RNG-84: The PCG ticket should be resolved. I have not had time to work
> on the K-dimensionally distributed variants that should support the
> Jumpable interface. This can go on a new ticket when I get round to it.
Sure.
>
> RNG-17: We never got as far as testing a Lagged Fibonacci generator. The
> reference example int versions only output 24-bits so were not deemed
> suitable. There was a reference example that used 48-bit floating point
> values. However to add this would not fit in the model of the
> source32/64 packages. I think this ticket should be left open with links
> to the reference implementations and a task to test them using DieHarder
> and BigCrush from the native C implementation. If results are good then
> a double based LFG could be added to a new source64F package.
Are there any modern generators based on "double"?
Regards,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
On 30/08/2019 14:22, Gilles Sadowski wrote:
> Hi.
>
> Le ven. 30 août 2019 à 15:11, Abhishek Dhadwal <dh...@gmail.com> a écrit :
>> Hello,
>>
>> What would be the deadline for the release ?
> There is no deadline, but the sooner the better.
> The many new features deserve a release.
>
>> If it’s not too early I could resolve RNG-111 (https://issues.apache.org/jira/browse/RNG-111) over the next few days. I couldn’t work on it before due to back to back college project evaluations and my mid term examinations (which get over by tomorrow).
> Great.
My take on this...
There is nothing outstanding.
It would be nice to get the JSF generator (RNG-111) put in as it is a
compliment to the SFC generator I just added (RNG-112). Let's give
Abhishek some time to finish this work.
All the speed tests will need to be updated for the site. I have been
considering if we should have more 'real' benchmarks. Currently we
benchmark a single call to each method in UniformRandomProvider using
the pattern recommended by JMH. I've built these benchmarks to require
post-processing to subtract the JMH overhead. So the tables for the
user-guide can either put in the raw data or as is currently done put in
the relative scores following post-processing to subtract the JMH baseline.
However it is unclear if the current benchmark represents real-world
observable differences. A candidate for a 'real' world test for
nextInt() is a shuffle benchmark. This can be done using an actual array
or just by generating indices to swap. When using an actual array it is
more realistic but relative performance is size dependent. When the
array gets large the method is slowed by cache misses during the actual
swap of the data. So the shuffle benchmark results would have to be
report for different sizes.
The other method to target would be nextLong(). I cannot think of a real
use case for this so instead we could target nextDouble(). I tried a
benchmark using a SmallMeanPoissonSampler which calls nextDouble() n+1
times for a mean of n. This is a good start point for an algorithm that
puts the random numbers to use. However it may be replicating what is
already listed for the comparison of the different normalised Gaussian
samplers. Currently the user guide has a table comparing the 3 different
Gaussian samplers and then another table for the Marsaglia normalised
Gaussian sampler. (Note: There is some redundancy here.) Since all the
Gaussian samplers use nextDouble()/nextLong() then the output of this
table is a rough guide to the relative speed of the RNG on 64-bit output.
I would suggest dropping the table showing the Marsaglia normalised
Gaussian sampler (it is redundant given the comparison of different
Gaussian samplers) and adding a shuffle benchmark for different array sizes.
More on RNG-32 below...
>
> Best,
> Gilles
>
>> Regards,
>> Abhishek
>>
>> Sent from Mail for Windows 10
>>
>> From: Gilles Sadowski
>> Sent: 30 August 2019 17:22
>> To: Commons Developers List
>> Subject: Re: [rng] Releasing 1.3
>>
>> Hi.
>>
>> Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
>>>
>>> On 10/06/2019 15:31, Gilles Sadowski wrote:
>>>>>> P.S. Thinking of releasing 1.3?
>>>>> Not yet. I think there are a few outstanding items [...]
>> Status?
>>
>> In particular could we resolve
>> https://issues.apache.org/jira/projects/RNG/issues/RNG-32
>> and all its sub-tasks following the work done through GSoC?
This could be rounded up. Each tickets need some finishing details.
RNG-16: We did test LCGs that outperform the 48-bit LCG of
Java.util.Random. Any 64-bit LCG which returns the upper 32-bits should
be an OK generator. The ones we tested using increments 1 (Musl) and
1442695040888963407 (from Knuth) perform as:
---------
DieHarder
---------
KnuthShiftLCG : 1, 0, 0, 0, 0
MuslShiftLCG : 0, 0, 0, 0, 0
-------
TestU01
-------
MuslShiftLCG : 15, 16, 15, 14, 15
KnuthShiftLCG : 14, 11, 16, 17, 14
They are bad on BigCrush but will probably be the fastest 32-bit
generators in the library if a user wants a very fast 32-bit generator
for simple random stuff (e.g. generating filenames). A single example
would at least be a reference point and a comparison for the PCG
generators that use a 64-bit LCG and then permute the output. It is
possible to create one using the abstract class for the PCG generators:
public class LcgShift32 extends AbstractPcg6432 {
public LcgShift32(long[] seed) {
super(seed);
}
@Override
protected int transform(long x) {
return (int)(x >>> 32);
}
}
RNG-84: The PCG ticket should be resolved. I have not had time to work
on the K-dimensionally distributed variants that should support the
Jumpable interface. This can go on a new ticket when I get round to it.
RNG-17: We never got as far as testing a Lagged Fibonacci generator. The
reference example int versions only output 24-bits so were not deemed
suitable. There was a reference example that used 48-bit floating point
values. However to add this would not fit in the model of the
source32/64 packages. I think this ticket should be left open with links
to the reference implementations and a task to test them using DieHarder
and BigCrush from the native C implementation. If results are good then
a double based LFG could be added to a new source64F package.
>>
>> Best,
>> Gilles
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Rob Tompkins <ch...@gmail.com>.
I would cd into ./target/commons-release-plugin/scm and try the svn commit from there manually. That’s the directory where everything gets staged.
I also think your svn password gets cached generally, but that’s predicated on having checked something into svn previously. Given our recent migration to all git based projects i could see that not working the first time. You can also pass “-Duser.password=...” at the command step, but that’s ugly in my opinion and can be avoided by putting that password down in your settings.xml.
Keep me posted and I’ll try to answer quickly,
-Rob
> On Nov 4, 2019, at 2:31 PM, Alex Herbert <al...@gmail.com> wrote:
>
>
>
>> On 4 Nov 2019, at 18:38, Rob Tompkins <ch...@gmail.com> wrote:
>>
>> Also keep me posted. I’ll be near my keyboard all day. -Rob
>>
>>>> On Nov 4, 2019, at 1:21 PM, Rob Tompkins <ch...@gmail.com> wrote:
>>>
>>>
>>>
>>>> On Nov 4, 2019, at 1:16 PM, Alex Herbert <al...@gmail.com> wrote:
>>>>
>>>>
>>>>>> On 04/11/2019 17:36, Alex Herbert wrote:
>>>>>
>>>>>
>>>>>> On 04/11/2019 15:40, Alex Herbert wrote:
>>>>>>
>>>>>> On 04/11/2019 12:43, Gilles Sadowski wrote:
>>>>>>> Hello.
>>>>>>>
>>>>>>> Le lun. 4 nov. 2019 à 13:05, Alex Herbert <al...@gmail.com> a écrit :
>>>>>>>>
>>>>>>>> On 04/11/2019 00:42, Gilles Sadowski wrote:
>>>>>>>>> Hi.
>>>>>>>>>
>>>>>>>>>> [...]
>>>>>>>>>>
>>>>>>>>>> So there are at least two options:
>>>>>>>>>>
>>>>>>>>>> 1. Release using JDK 9
>>>>>>>>> +1
>>>>>>>> OK. I'll run through the release with JDK 9. I do not think we have any
>>>>>>>> NIO classes so the issue raised by Gary should not be present.
>>>>>>> Here
>>>>>>> $ JAVA_HOME=/usr/lib/jvm/java-9-openjdk-amd64 mvn
>>>>>>> -Pcommons-rng-examples clean package install site site:stage
>>>>>>> built fine (but I did not check the reports).
>>>>>>
>>>>>> Good to know.
>>>>>>
>>>>>> I've been through a dry run and the outputs look as expected.
>>>>>
>>>>> The commons-release-plugin:1.7 has failed on the final step to stage the files in Nexus.
>>>>>
>>>>> All the files appear to be present but the plugin fails when processing the parent for the multi-module project.
>>>>>
>>>>> Here is the command that is currently failing:
>>>>>
>>>>> mvn -X -e -Duser.name=aherbert -Pcommons-rng-examples -Prelease clean package site site:stage deploy -rf :commons-rng
>>>>>
>>>>> [DEBUG] -- end configuration --
>>>>> [INFO] Checking out dist from: scm:svn:https://dist.apache.org/repos/dist/dev/commons/rng
>>>>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'checkout' 'https://dist.apache.org/repos/dist/dev/commons/rng@' '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup'
>>>>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup' && 'svn' 'remove' '--targets' '/tmp/maven-scm-5448861436738372728-targets'
>>>>> [INFO] Cleaning distribution area for: commons-rng
>>>>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'commit' '--file' '/tmp/maven-scm-1469264231.commit' '--encoding' 'UTF-8' '--targets' '/tmp/maven-scm-14546727756421455038-targets'
>>>>> [INFO] ------------------------------------------------------------------------
>>>>> [INFO] BUILD FAILURE
>>>>> [INFO] ------------------------------------------------------------------------
>>>>> [INFO] Total time: 7.376 s
>>>>> [INFO] Finished at: 2019-11-04T17:19:15Z
>>>>> [INFO] ------------------------------------------------------------------------
>>>>> [ERROR] Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-rng: Failed to commit files: null [null] -> [Help 1]
>>>>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-rng: Failed to commit files: null [null]
>>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
>>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
>>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
>>>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
>>>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
>>>>> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
>>>>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
>>>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>>>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>>>>> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>>>>> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>>>>> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>>>>> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>>>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>>>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
>>>>> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
>>>>> at java.lang.reflect.Method.invoke (Method.java:564)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
>>>>> Caused by: org.apache.maven.plugin.MojoFailureException: Failed to commit files: null [null]
>>>>> at org.apache.commons.release.plugin.mojos.CommonsStagingCleanupMojo.execute (CommonsStagingCleanupMojo.java:193)
>>>>> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
>>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
>>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
>>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
>>>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
>>>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
>>>>> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
>>>>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
>>>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>>>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>>>>> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>>>>> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>>>>> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>>>>> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>>>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>>>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
>>>>> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
>>>>> at java.lang.reflect.Method.invoke (Method.java:564)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
>>>>>
>>>>> I think all the files have been staged correctly.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Can this be ignored as a bug in the commons-release-plugin:1.7 trying to clean something that is not there?
>>>>>
>>>>> Alex
>>>>>
>>>> It seems the above command stalled before creating the release artefacts. I have no:
>>>>
>>>> commons-rng-1.3-src.tar.gz
>>>> commons-rng-1.3-src.zip
>>>> commons-rng-1.3-bin.tar.gz
>>>> commons-rng-1.3-bin.zip
>>>>
>>>> In the dist-archive/target directory.
>>>>
>>>> When I run
>>>>
>>>> svn checkout https://dist.apache.org/repos/dist/dev/commons/rng
>>>>
>>>> The dev area still has version 1.2-RC2 from the last release. Would this effect anything in the release process?
>>>
>>> Maybe...I would delete that and retry.
>
> I cleaned the old RC and it got a bit further. This is where is now breaks:
>
> [INFO] Staging release: commons-rng, version: 1.3
> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'commit' '--file' '/tmp/maven-scm-92724952.commit' '--encoding' 'UTF-8' '--targets' '/tmp/maven-scm-3088677623902684789-targets'
> [ERROR] Committing dist files failed: svn: E215004: Authentication failed and interactive prompting is disabled; see the --force-interactive option
>
> Unfortunately I am now at home and not in an interactive shell. So could it be related to that? Where does svn get password from?
>
>>>
>>> -Rob
>>>
>>>>
>>>> Alex
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
> On 4 Nov 2019, at 19:31, Alex Herbert <al...@gmail.com> wrote:
>
>
>
>> On 4 Nov 2019, at 18:38, Rob Tompkins <chtompki@gmail.com <ma...@gmail.com>> wrote:
>>
>> Also keep me posted. I’ll be near my keyboard all day. -Rob
>>
>>> On Nov 4, 2019, at 1:21 PM, Rob Tompkins <chtompki@gmail.com <ma...@gmail.com>> wrote:
>>>
>>>
>>>
>>>> On Nov 4, 2019, at 1:16 PM, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>>
>>>>>> On 04/11/2019 17:36, Alex Herbert wrote:
>>>>>
>>>>>
>>>>>> On 04/11/2019 15:40, Alex Herbert wrote:
>>>>>>
>>>>>> On 04/11/2019 12:43, Gilles Sadowski wrote:
>>>>>>> Hello.
>>>>>>>
>>>>>>> Le lun. 4 nov. 2019 à 13:05, Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>> a écrit :
>>>>>>>>
>>>>>>>> On 04/11/2019 00:42, Gilles Sadowski wrote:
>>>>>>>>> Hi.
>>>>>>>>>
>>>>>>>>>> [...]
>>>>>>>>>>
>>>>>>>>>> So there are at least two options:
>>>>>>>>>>
>>>>>>>>>> 1. Release using JDK 9
>>>>>>>>> +1
>>>>>>>> OK. I'll run through the release with JDK 9. I do not think we have any
>>>>>>>> NIO classes so the issue raised by Gary should not be present.
>>>>>>> Here
>>>>>>> $ JAVA_HOME=/usr/lib/jvm/java-9-openjdk-amd64 mvn
>>>>>>> -Pcommons-rng-examples clean package install site site:stage
>>>>>>> built fine (but I did not check the reports).
>>>>>>
>>>>>> Good to know.
>>>>>>
>>>>>> I've been through a dry run and the outputs look as expected.
>>>>>
>>>>> The commons-release-plugin:1.7 has failed on the final step to stage the files in Nexus.
>>>>>
>>>>> All the files appear to be present but the plugin fails when processing the parent for the multi-module project.
>>>>>
>>>>> Here is the command that is currently failing:
>>>>>
>>>>> mvn -X -e -Duser.name=aherbert -Pcommons-rng-examples -Prelease clean package site site:stage deploy -rf :commons-rng
>>>>>
>>>>> [DEBUG] -- end configuration --
>>>>> [INFO] Checking out dist from: scm:svn:https://dist.apache.org/repos/dist/dev/commons/rng <https://dist.apache.org/repos/dist/dev/commons/rng>
>>>>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'checkout' 'https://dist.apache.org/repos/dist/dev/commons/rng@' '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup <https://dist.apache.org/repos/dist/dev/commons/rng@'%20'/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup>'
>>>>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup' && 'svn' 'remove' '--targets' '/tmp/maven-scm-5448861436738372728-targets'
>>>>> [INFO] Cleaning distribution area for: commons-rng
>>>>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'commit' '--file' '/tmp/maven-scm-1469264231.commit' '--encoding' 'UTF-8' '--targets' '/tmp/maven-scm-14546727756421455038-targets'
>>>>> [INFO] ------------------------------------------------------------------------
>>>>> [INFO] BUILD FAILURE
>>>>> [INFO] ------------------------------------------------------------------------
>>>>> [INFO] Total time: 7.376 s
>>>>> [INFO] Finished at: 2019-11-04T17:19:15Z
>>>>> [INFO] ------------------------------------------------------------------------
>>>>> [ERROR] Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-rng: Failed to commit files: null [null] -> [Help 1]
>>>>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-rng: Failed to commit files: null [null]
>>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
>>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
>>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
>>>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
>>>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
>>>>> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
>>>>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
>>>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>>>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>>>>> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>>>>> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>>>>> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>>>>> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>>>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>>>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
>>>>> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
>>>>> at java.lang.reflect.Method.invoke (Method.java:564)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
>>>>> Caused by: org.apache.maven.plugin.MojoFailureException: Failed to commit files: null [null]
>>>>> at org.apache.commons.release.plugin.mojos.CommonsStagingCleanupMojo.execute (CommonsStagingCleanupMojo.java:193)
>>>>> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
>>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
>>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
>>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
>>>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
>>>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
>>>>> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
>>>>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
>>>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>>>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>>>>> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>>>>> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>>>>> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>>>>> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>>>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>>>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
>>>>> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
>>>>> at java.lang.reflect.Method.invoke (Method.java:564)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
>>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
>>>>>
>>>>> I think all the files have been staged correctly.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Can this be ignored as a bug in the commons-release-plugin:1.7 trying to clean something that is not there?
>>>>>
>>>>> Alex
>>>>>
>>>> It seems the above command stalled before creating the release artefacts. I have no:
>>>>
>>>> commons-rng-1.3-src.tar.gz
>>>> commons-rng-1.3-src.zip
>>>> commons-rng-1.3-bin.tar.gz
>>>> commons-rng-1.3-bin.zip
>>>>
>>>> In the dist-archive/target directory.
>>>>
>>>> When I run
>>>>
>>>> svn checkout https://dist.apache.org/repos/dist/dev/commons/rng <https://dist.apache.org/repos/dist/dev/commons/rng>
>>>>
>>>> The dev area still has version 1.2-RC2 from the last release. Would this effect anything in the release process?
>>>
>>> Maybe...I would delete that and retry.
>
> I cleaned the old RC and it got a bit further. This is where is now breaks:
>
> [INFO] Staging release: commons-rng, version: 1.3
> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'commit' '--file' '/tmp/maven-scm-92724952.commit' '--encoding' 'UTF-8' '--targets' '/tmp/maven-scm-3088677623902684789-targets'
> [ERROR] Committing dist files failed: svn: E215004: Authentication failed and interactive prompting is disabled; see the --force-interactive option
>
> Unfortunately I am now at home and not in an interactive shell. So could it be related to that? Where does svn get password from?
This is definitely a svn problem.
I recreated a file in https://dist.apache.org/repos/dist/dev/commons/rng <https://dist.apache.org/repos/dist/dev/commons/rng> and I am back to the original error that occurs when the release plugin tries to clean the dev directory.
So every time the release plugin issues a svn command that requires a commit (and password authentication) it fails.
Is there something obvious that I have not set to allow svn commands to run within the 'svn —non-interactive' mode used by the release plugin?
The only instructions in the rng release howto guide were instructions to configure id.apache.org <http://id.apache.org/> using the contents of ~/.ssh/id_rsa.pub. I have done this and can login to home.apache.org <http://home.apache.org/> using sftp. Is there somewhere else I have to configure remote ssh authentication for the release process?
Thanks,
Alex
>
>>>
>>> -Rob
>>>
>>>>
>>>> Alex
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
>> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
> On 4 Nov 2019, at 18:38, Rob Tompkins <ch...@gmail.com> wrote:
>
> Also keep me posted. I’ll be near my keyboard all day. -Rob
>
>> On Nov 4, 2019, at 1:21 PM, Rob Tompkins <ch...@gmail.com> wrote:
>>
>>
>>
>>> On Nov 4, 2019, at 1:16 PM, Alex Herbert <al...@gmail.com> wrote:
>>>
>>>
>>>>> On 04/11/2019 17:36, Alex Herbert wrote:
>>>>
>>>>
>>>>> On 04/11/2019 15:40, Alex Herbert wrote:
>>>>>
>>>>> On 04/11/2019 12:43, Gilles Sadowski wrote:
>>>>>> Hello.
>>>>>>
>>>>>> Le lun. 4 nov. 2019 à 13:05, Alex Herbert <al...@gmail.com> a écrit :
>>>>>>>
>>>>>>> On 04/11/2019 00:42, Gilles Sadowski wrote:
>>>>>>>> Hi.
>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>> So there are at least two options:
>>>>>>>>>
>>>>>>>>> 1. Release using JDK 9
>>>>>>>> +1
>>>>>>> OK. I'll run through the release with JDK 9. I do not think we have any
>>>>>>> NIO classes so the issue raised by Gary should not be present.
>>>>>> Here
>>>>>> $ JAVA_HOME=/usr/lib/jvm/java-9-openjdk-amd64 mvn
>>>>>> -Pcommons-rng-examples clean package install site site:stage
>>>>>> built fine (but I did not check the reports).
>>>>>
>>>>> Good to know.
>>>>>
>>>>> I've been through a dry run and the outputs look as expected.
>>>>
>>>> The commons-release-plugin:1.7 has failed on the final step to stage the files in Nexus.
>>>>
>>>> All the files appear to be present but the plugin fails when processing the parent for the multi-module project.
>>>>
>>>> Here is the command that is currently failing:
>>>>
>>>> mvn -X -e -Duser.name=aherbert -Pcommons-rng-examples -Prelease clean package site site:stage deploy -rf :commons-rng
>>>>
>>>> [DEBUG] -- end configuration --
>>>> [INFO] Checking out dist from: scm:svn:https://dist.apache.org/repos/dist/dev/commons/rng
>>>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'checkout' 'https://dist.apache.org/repos/dist/dev/commons/rng@' '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup'
>>>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup' && 'svn' 'remove' '--targets' '/tmp/maven-scm-5448861436738372728-targets'
>>>> [INFO] Cleaning distribution area for: commons-rng
>>>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'commit' '--file' '/tmp/maven-scm-1469264231.commit' '--encoding' 'UTF-8' '--targets' '/tmp/maven-scm-14546727756421455038-targets'
>>>> [INFO] ------------------------------------------------------------------------
>>>> [INFO] BUILD FAILURE
>>>> [INFO] ------------------------------------------------------------------------
>>>> [INFO] Total time: 7.376 s
>>>> [INFO] Finished at: 2019-11-04T17:19:15Z
>>>> [INFO] ------------------------------------------------------------------------
>>>> [ERROR] Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-rng: Failed to commit files: null [null] -> [Help 1]
>>>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-rng: Failed to commit files: null [null]
>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
>>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
>>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
>>>> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
>>>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
>>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>>>> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>>>> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>>>> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>>>> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
>>>> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
>>>> at java.lang.reflect.Method.invoke (Method.java:564)
>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
>>>> Caused by: org.apache.maven.plugin.MojoFailureException: Failed to commit files: null [null]
>>>> at org.apache.commons.release.plugin.mojos.CommonsStagingCleanupMojo.execute (CommonsStagingCleanupMojo.java:193)
>>>> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
>>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
>>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
>>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
>>>> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
>>>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
>>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>>>> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>>>> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>>>> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>>>> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
>>>> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
>>>> at java.lang.reflect.Method.invoke (Method.java:564)
>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
>>>> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
>>>>
>>>> I think all the files have been staged correctly.
>>>>
>>>> Any ideas?
>>>>
>>>> Can this be ignored as a bug in the commons-release-plugin:1.7 trying to clean something that is not there?
>>>>
>>>> Alex
>>>>
>>> It seems the above command stalled before creating the release artefacts. I have no:
>>>
>>> commons-rng-1.3-src.tar.gz
>>> commons-rng-1.3-src.zip
>>> commons-rng-1.3-bin.tar.gz
>>> commons-rng-1.3-bin.zip
>>>
>>> In the dist-archive/target directory.
>>>
>>> When I run
>>>
>>> svn checkout https://dist.apache.org/repos/dist/dev/commons/rng
>>>
>>> The dev area still has version 1.2-RC2 from the last release. Would this effect anything in the release process?
>>
>> Maybe...I would delete that and retry.
I cleaned the old RC and it got a bit further. This is where is now breaks:
[INFO] Staging release: commons-rng, version: 1.3
Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'commit' '--file' '/tmp/maven-scm-92724952.commit' '--encoding' 'UTF-8' '--targets' '/tmp/maven-scm-3088677623902684789-targets'
[ERROR] Committing dist files failed: svn: E215004: Authentication failed and interactive prompting is disabled; see the --force-interactive option
Unfortunately I am now at home and not in an interactive shell. So could it be related to that? Where does svn get password from?
>>
>> -Rob
>>
>>>
>>> Alex
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
Re: [rng] Releasing 1.3
Posted by Rob Tompkins <ch...@gmail.com>.
Also keep me posted. I’ll be near my keyboard all day. -Rob
> On Nov 4, 2019, at 1:21 PM, Rob Tompkins <ch...@gmail.com> wrote:
>
>
>
>> On Nov 4, 2019, at 1:16 PM, Alex Herbert <al...@gmail.com> wrote:
>>
>>
>>>> On 04/11/2019 17:36, Alex Herbert wrote:
>>>
>>>
>>>> On 04/11/2019 15:40, Alex Herbert wrote:
>>>>
>>>> On 04/11/2019 12:43, Gilles Sadowski wrote:
>>>>> Hello.
>>>>>
>>>>> Le lun. 4 nov. 2019 à 13:05, Alex Herbert <al...@gmail.com> a écrit :
>>>>>>
>>>>>> On 04/11/2019 00:42, Gilles Sadowski wrote:
>>>>>>> Hi.
>>>>>>>
>>>>>>>> [...]
>>>>>>>>
>>>>>>>> So there are at least two options:
>>>>>>>>
>>>>>>>> 1. Release using JDK 9
>>>>>>> +1
>>>>>> OK. I'll run through the release with JDK 9. I do not think we have any
>>>>>> NIO classes so the issue raised by Gary should not be present.
>>>>> Here
>>>>> $ JAVA_HOME=/usr/lib/jvm/java-9-openjdk-amd64 mvn
>>>>> -Pcommons-rng-examples clean package install site site:stage
>>>>> built fine (but I did not check the reports).
>>>>
>>>> Good to know.
>>>>
>>>> I've been through a dry run and the outputs look as expected.
>>>
>>> The commons-release-plugin:1.7 has failed on the final step to stage the files in Nexus.
>>>
>>> All the files appear to be present but the plugin fails when processing the parent for the multi-module project.
>>>
>>> Here is the command that is currently failing:
>>>
>>> mvn -X -e -Duser.name=aherbert -Pcommons-rng-examples -Prelease clean package site site:stage deploy -rf :commons-rng
>>>
>>> [DEBUG] -- end configuration --
>>> [INFO] Checking out dist from: scm:svn:https://dist.apache.org/repos/dist/dev/commons/rng
>>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'checkout' 'https://dist.apache.org/repos/dist/dev/commons/rng@' '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup'
>>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup' && 'svn' 'remove' '--targets' '/tmp/maven-scm-5448861436738372728-targets'
>>> [INFO] Cleaning distribution area for: commons-rng
>>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'commit' '--file' '/tmp/maven-scm-1469264231.commit' '--encoding' 'UTF-8' '--targets' '/tmp/maven-scm-14546727756421455038-targets'
>>> [INFO] ------------------------------------------------------------------------
>>> [INFO] BUILD FAILURE
>>> [INFO] ------------------------------------------------------------------------
>>> [INFO] Total time: 7.376 s
>>> [INFO] Finished at: 2019-11-04T17:19:15Z
>>> [INFO] ------------------------------------------------------------------------
>>> [ERROR] Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-rng: Failed to commit files: null [null] -> [Help 1]
>>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-rng: Failed to commit files: null [null]
>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
>>> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
>>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>>> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>>> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>>> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>>> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
>>> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke (Method.java:564)
>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
>>> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
>>> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
>>> Caused by: org.apache.maven.plugin.MojoFailureException: Failed to commit files: null [null]
>>> at org.apache.commons.release.plugin.mojos.CommonsStagingCleanupMojo.execute (CommonsStagingCleanupMojo.java:193)
>>> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
>>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
>>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
>>> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
>>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>>> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>>> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>>> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>>> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
>>> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
>>> at java.lang.reflect.Method.invoke (Method.java:564)
>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
>>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
>>> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
>>> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
>>>
>>> I think all the files have been staged correctly.
>>>
>>> Any ideas?
>>>
>>> Can this be ignored as a bug in the commons-release-plugin:1.7 trying to clean something that is not there?
>>>
>>> Alex
>>>
>> It seems the above command stalled before creating the release artefacts. I have no:
>>
>> commons-rng-1.3-src.tar.gz
>> commons-rng-1.3-src.zip
>> commons-rng-1.3-bin.tar.gz
>> commons-rng-1.3-bin.zip
>>
>> In the dist-archive/target directory.
>>
>> When I run
>>
>> svn checkout https://dist.apache.org/repos/dist/dev/commons/rng
>>
>> The dev area still has version 1.2-RC2 from the last release. Would this effect anything in the release process?
>
> Maybe...I would delete that and retry.
>
> -Rob
>
>>
>> Alex
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Rob Tompkins <ch...@gmail.com>.
> On Nov 4, 2019, at 1:16 PM, Alex Herbert <al...@gmail.com> wrote:
>
>
>> On 04/11/2019 17:36, Alex Herbert wrote:
>>
>>
>>> On 04/11/2019 15:40, Alex Herbert wrote:
>>>
>>> On 04/11/2019 12:43, Gilles Sadowski wrote:
>>>> Hello.
>>>>
>>>> Le lun. 4 nov. 2019 à 13:05, Alex Herbert <al...@gmail.com> a écrit :
>>>>>
>>>>> On 04/11/2019 00:42, Gilles Sadowski wrote:
>>>>>> Hi.
>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>> So there are at least two options:
>>>>>>>
>>>>>>> 1. Release using JDK 9
>>>>>> +1
>>>>> OK. I'll run through the release with JDK 9. I do not think we have any
>>>>> NIO classes so the issue raised by Gary should not be present.
>>>> Here
>>>> $ JAVA_HOME=/usr/lib/jvm/java-9-openjdk-amd64 mvn
>>>> -Pcommons-rng-examples clean package install site site:stage
>>>> built fine (but I did not check the reports).
>>>
>>> Good to know.
>>>
>>> I've been through a dry run and the outputs look as expected.
>>
>> The commons-release-plugin:1.7 has failed on the final step to stage the files in Nexus.
>>
>> All the files appear to be present but the plugin fails when processing the parent for the multi-module project.
>>
>> Here is the command that is currently failing:
>>
>> mvn -X -e -Duser.name=aherbert -Pcommons-rng-examples -Prelease clean package site site:stage deploy -rf :commons-rng
>>
>> [DEBUG] -- end configuration --
>> [INFO] Checking out dist from: scm:svn:https://dist.apache.org/repos/dist/dev/commons/rng
>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'checkout' 'https://dist.apache.org/repos/dist/dev/commons/rng@' '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup'
>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup' && 'svn' 'remove' '--targets' '/tmp/maven-scm-5448861436738372728-targets'
>> [INFO] Cleaning distribution area for: commons-rng
>> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'commit' '--file' '/tmp/maven-scm-1469264231.commit' '--encoding' 'UTF-8' '--targets' '/tmp/maven-scm-14546727756421455038-targets'
>> [INFO] ------------------------------------------------------------------------
>> [INFO] BUILD FAILURE
>> [INFO] ------------------------------------------------------------------------
>> [INFO] Total time: 7.376 s
>> [INFO] Finished at: 2019-11-04T17:19:15Z
>> [INFO] ------------------------------------------------------------------------
>> [ERROR] Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-rng: Failed to commit files: null [null] -> [Help 1]
>> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-rng: Failed to commit files: null [null]
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
>> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
>> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke (Method.java:564)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
>> Caused by: org.apache.maven.plugin.MojoFailureException: Failed to commit files: null [null]
>> at org.apache.commons.release.plugin.mojos.CommonsStagingCleanupMojo.execute (CommonsStagingCleanupMojo.java:193)
>> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
>> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
>> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
>> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
>> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
>> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
>> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
>> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
>> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
>> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
>> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
>> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke (Method.java:564)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
>> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
>>
>> I think all the files have been staged correctly.
>>
>> Any ideas?
>>
>> Can this be ignored as a bug in the commons-release-plugin:1.7 trying to clean something that is not there?
>>
>> Alex
>>
> It seems the above command stalled before creating the release artefacts. I have no:
>
> commons-rng-1.3-src.tar.gz
> commons-rng-1.3-src.zip
> commons-rng-1.3-bin.tar.gz
> commons-rng-1.3-bin.zip
>
> In the dist-archive/target directory.
>
> When I run
>
> svn checkout https://dist.apache.org/repos/dist/dev/commons/rng
>
> The dev area still has version 1.2-RC2 from the last release. Would this effect anything in the release process?
Maybe...I would delete that and retry.
-Rob
>
> Alex
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
On 04/11/2019 17:36, Alex Herbert wrote:
>
>
> On 04/11/2019 15:40, Alex Herbert wrote:
>>
>> On 04/11/2019 12:43, Gilles Sadowski wrote:
>>> Hello.
>>>
>>> Le lun. 4 nov. 2019 à 13:05, Alex Herbert <al...@gmail.com>
>>> a écrit :
>>>>
>>>> On 04/11/2019 00:42, Gilles Sadowski wrote:
>>>>> Hi.
>>>>>
>>>>>> [...]
>>>>>>
>>>>>> So there are at least two options:
>>>>>>
>>>>>> 1. Release using JDK 9
>>>>> +1
>>>> OK. I'll run through the release with JDK 9. I do not think we have
>>>> any
>>>> NIO classes so the issue raised by Gary should not be present.
>>> Here
>>> $ JAVA_HOME=/usr/lib/jvm/java-9-openjdk-amd64 mvn
>>> -Pcommons-rng-examples clean package install site site:stage
>>> built fine (but I did not check the reports).
>>
>> Good to know.
>>
>> I've been through a dry run and the outputs look as expected.
>
> The commons-release-plugin:1.7 has failed on the final step to stage
> the files in Nexus.
>
> All the files appear to be present but the plugin fails when
> processing the parent for the multi-module project.
>
> Here is the command that is currently failing:
>
> mvn -X -e -Duser.name=aherbert -Pcommons-rng-examples -Prelease clean
> package site site:stage deploy -rf :commons-rng
>
> [DEBUG] -- end configuration --
> [INFO] Checking out dist from: scm:svn:https://dist.apache.org/repos/dist/dev/commons/rng
> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'checkout' 'https://dist.apache.org/repos/dist/dev/commons/rng@' '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup'
> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup' && 'svn' 'remove' '--targets' '/tmp/maven-scm-5448861436738372728-targets'
> [INFO] Cleaning distribution area for: commons-rng
> Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'commit' '--file' '/tmp/maven-scm-1469264231.commit' '--encoding' 'UTF-8' '--targets' '/tmp/maven-scm-14546727756421455038-targets'
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 7.376 s
> [INFO] Finished at: 2019-11-04T17:19:15Z
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-rng: Failed to commit files: null [null] -> [Help 1]
> org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-rng: Failed to commit files: null [null]
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:564)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
> Caused by: org.apache.maven.plugin.MojoFailureException: Failed to commit files: null [null]
> at org.apache.commons.release.plugin.mojos.CommonsStagingCleanupMojo.execute (CommonsStagingCleanupMojo.java:193)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:564)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
>
> I think all the files have been staged correctly.
>
> Any ideas?
>
> Can this be ignored as a bug in the commons-release-plugin:1.7 trying
> to clean something that is not there?
>
> Alex
>
It seems the above command stalled before creating the release
artefacts. I have no:
commons-rng-1.3-src.tar.gz
commons-rng-1.3-src.zip
commons-rng-1.3-bin.tar.gz
commons-rng-1.3-bin.zip
In the dist-archive/target directory.
When I run
svn checkout https://dist.apache.org/repos/dist/dev/commons/rng
The dev area still has version 1.2-RC2 from the last release. Would this
effect anything in the release process?
Alex
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
On 04/11/2019 15:40, Alex Herbert wrote:
>
> On 04/11/2019 12:43, Gilles Sadowski wrote:
>> Hello.
>>
>> Le lun. 4 nov. 2019 à 13:05, Alex Herbert <al...@gmail.com>
>> a écrit :
>>>
>>> On 04/11/2019 00:42, Gilles Sadowski wrote:
>>>> Hi.
>>>>
>>>>> [...]
>>>>>
>>>>> So there are at least two options:
>>>>>
>>>>> 1. Release using JDK 9
>>>> +1
>>> OK. I'll run through the release with JDK 9. I do not think we have any
>>> NIO classes so the issue raised by Gary should not be present.
>> Here
>> $ JAVA_HOME=/usr/lib/jvm/java-9-openjdk-amd64 mvn
>> -Pcommons-rng-examples clean package install site site:stage
>> built fine (but I did not check the reports).
>
> Good to know.
>
> I've been through a dry run and the outputs look as expected.
The commons-release-plugin:1.7 has failed on the final step to stage the
files in Nexus.
All the files appear to be present but the plugin fails when processing
the parent for the multi-module project.
Here is the command that is currently failing:
mvn -X -e -Duser.name=aherbert -Pcommons-rng-examples -Prelease clean
package site site:stage deploy -rf :commons-rng
[DEBUG] -- end configuration --
[INFO] Checking out dist from: scm:svn:https://dist.apache.org/repos/dist/dev/commons/rng
Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'checkout' 'https://dist.apache.org/repos/dist/dev/commons/rng@' '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup'
Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup' && 'svn' 'remove' '--targets' '/tmp/maven-scm-5448861436738372728-targets'
[INFO] Cleaning distribution area for: commons-rng
Executing: /bin/sh -c cd '/scratch/commons-rng/dist-archive/target/commons-release-plugin/scm-cleanup' && 'svn' '--username' 'aherbert' '--no-auth-cache' '--non-interactive' 'commit' '--file' '/tmp/maven-scm-1469264231.commit' '--encoding' 'UTF-8' '--targets' '/tmp/maven-scm-14546727756421455038-targets'
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7.376 s
[INFO] Finished at: 2019-11-04T17:19:15Z
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-rng: Failed to commit files: null [null] -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.commons:commons-release-plugin:1.7:clean-staging (clean-staging) on project commons-rng: Failed to commit files: null [null]
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
Caused by: org.apache.maven.plugin.MojoFailureException: Failed to commit files: null [null]
at org.apache.commons.release.plugin.mojos.CommonsStagingCleanupMojo.execute (CommonsStagingCleanupMojo.java:193)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:564)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:356)
I think all the files have been staged correctly.
Any ideas?
Can this be ignored as a bug in the commons-release-plugin:1.7 trying to
clean something that is not there?
Alex
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
On 04/11/2019 12:43, Gilles Sadowski wrote:
> Hello.
>
> Le lun. 4 nov. 2019 à 13:05, Alex Herbert <al...@gmail.com> a écrit :
>>
>> On 04/11/2019 00:42, Gilles Sadowski wrote:
>>> Hi.
>>>
>>>> [...]
>>>>
>>>> So there are at least two options:
>>>>
>>>> 1. Release using JDK 9
>>> +1
>> OK. I'll run through the release with JDK 9. I do not think we have any
>> NIO classes so the issue raised by Gary should not be present.
> Here
> $ JAVA_HOME=/usr/lib/jvm/java-9-openjdk-amd64 mvn
> -Pcommons-rng-examples clean package install site site:stage
> built fine (but I did not check the reports).
Good to know.
I've been through a dry run and the outputs look as expected.
This command does not work with Java 9:
mvn -N -Pcommons-rng-examples commons-build:download-page
You have to build the download page using Java 8. Then switch to Java 9
again.
>
>> I am looking at the clirr report to check and add @since tags.
>>
>> Q. How to annotate implementation of a new interface on an existing class?
>>
>> Should all the new interface methods have @since tags?
> Isn't it good enough to have the tag in the class Javadoc?
For new classes. This is new methods added to existing classes due to
implementation of a new interface.
I've taken the safe option to put @since on all the new methods.
I also added @since to all the new enum values in RandomSource.
Alex
>
> Gilles
>
>>> [...]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Nov 3, 2019 at 5:44 PM Alex Herbert <al...@gmail.com>
wrote:
>
>
> > On 3 Nov 2019, at 20:12, Alex Herbert <al...@gmail.com> wrote:
> >
> >
> >
> >> On 3 Nov 2019, at 19:30, Gary Gregory <garydgregory@gmail.com <mailto:
> garydgregory@gmail.com>> wrote:
> >>
> >> On Sun, Nov 3, 2019 at 10:01 AM Alex Herbert <alex.d.herbert@gmail.com
> <ma...@gmail.com>>
> >> wrote:
> >>
> >>> I think everything is finalised for a release of RNG, namely:
> >>>
> >>> All bugs and issues with SonarCloud and LGTM.com <http://lgtm.com/>
> are fixed.
> >>> The user guide has been updated for all the new features.
> >>> The performance and quality results have been updated in the user
> guide.
> >>>
> >>> Any objections to me cutting a release candidate for v1.3? I hope to
> get
> >>> it done next week.
> >>>
> >>
> >> You first should make sure binary compatibility is there, Apache RAT
> check
> >> passes, and so on. That will avoid possible issues in a RC.
> >
> > rat:check and clirr:check are part of the default maven build so errors
> should not enter the codebase.
> >
> > The clirr:clirr report is full of infos for all the new API methods and
> classes.
> >
> > I'll start with a release dry run and see how everything looks.
> >
> > The only outstanding “issue” is that the full code for release has to be
> built using JDK 9.
> >
> > The extra examples maven modules contains some code using Java 9
> modules. All my attempts to get a build to work with JDK 11 have failed on
> the javadoc tool which complains about building for code using modules that
> references packages in the named module [1]. My last attempt using JDK
> 11.0.4 had the same error I found with JDK 11.0.2. I have not a found a fix
> for a multi-module Maven project that uses different java source versions
> and includes some java 9 source explicitly using modules.
> >
> > Given that JDK 11.0.5 is out I will have another look at this. A brief
> scan of the release notes for 11.0.5 does not mention anything but it is
> worth a try. I’d rather do a release using JDK 11 than JDK 9.
>
> JDK 11 works depending on the vendor and the source version!
>
> Steps
>
> 1. Optional. Update commons-rng-examples/examples-jpms/pom.xml to changes
> the source and target from 9 to 11. This is:
>
> <maven.compiler.source>11</maven.compiler.source>
> <maven.compiler.target>11</maven.compiler.target>
> <maven.compiler.release>11</maven.compiler.release>
>
> 2. Build using: mvn clean package site site:stage -P commons-rng-examples
>
>
> Tested two JDK 11 distributions:
>
> Official JDK from https://jdk.java.net/java-se-ri/11 <
> https://jdk.java.net/java-se-ri/11>
>
> java -version
> java version "11.0.5" 2019-10-15 LTS
> Java(TM) SE Runtime Environment 18.9 (build 11.0.5+10-LTS)
> Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.5+10-LTS, mixed mode)
>
> OpenAdopt JDK
> https://adoptopenjdk.net/releases.html?variant=openjdk11&jvmVariant=hotspot#x64_linux
> <
> https://adoptopenjdk.net/releases.html?variant=openjdk11&jvmVariant=hotspot#x64_linux
> >
>
> java -version
> openjdk version "11.0.5" 2019-10-15
> OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.5+10)
> OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.5+10, mixed mode)
>
>
> I tried 4 variants:
>
> Source 9, JDK 11.0.5
> Source 9, OpenAdopt JDK 11.0.5
> Source 11, JDK 11.0.5
> Source 11, OpenAdopt JDK 11.0.5
>
>
> Source 9, JDK 11.0.5
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.8.2:site (default-site) on
> project commons-rng-examples-jpms-lib: Error generating
> maven-javadoc-plugin:3.1.1:javadoc report:
> [ERROR] Exit code: 1 - javadoc: error - The code being documented uses
> modules but the packages defined in
> https://docs.oracle.com/javase/9/docs/api/ are in the unnamed module.
> [ERROR] javadoc: error - The code being documented uses modules but the
> packages defined in
> https://commons.apache.org/proper/commons-rng/commons-rng-client-api/apidocs/
> are in the unnamed module.
> [ERROR] javadoc: error - The code being documented uses modules but the
> packages defined in
> https://commons.apache.org/proper/commons-rng/commons-rng-sampling/apidocs/
> are in the unnamed module.
>
> Source 9, OpenAdopt JDK 11.0.5
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.8.2:site (default-site) on
> project commons-rng-examples-jpms-lib: Error generating
> maven-javadoc-plugin:3.1.1:javadoc report:
> [ERROR] Exit code: 1 - javadoc: error - The code being documented uses
> modules but the packages defined in
> https://docs.oracle.com/javase/9/docs/api/ are in the unnamed module.
>
>
> Source 11, JDK 11.0.5
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.8.2:site (default-site) on
> project commons-rng-examples-jpms-lib: Error generating
> maven-javadoc-plugin:3.1.1:javadoc report:
> [ERROR] Exit code: 1 - javadoc: error - The code being documented uses
> modules but the packages defined in
> https://commons.apache.org/proper/commons-rng/commons-rng-client-api/apidocs/
> are in the unnamed module.
> [ERROR] javadoc: error - The code being documented uses modules but the
> packages defined in
> https://commons.apache.org/proper/commons-rng/commons-rng-sampling/apidocs/
> are in the unnamed module.
>
>
> Source 11, OpenAdopt JDK 11.0.5
>
> OK
>
>
>
> So there are at least two options:
>
> 1. Release using JDK 9
>
I did not read all the details but I know that if you compile with JDK 9
and you use a JRE classes in the NIO Buffer hierarchy, things will break
when running on Java 8 due to some methods in the JRE being
added/moved/ICantRecallTheDetails in the hierarchy.
IOW, you are opening yourself up to a world of pain. The KISS is to compile
with your target platform, otherwise, you can get in trouble.
Gary
> 2. Update the examples project to use source 11 for the Java modules code
> and release using a non-oracle JDK 11
>
> Note that updating to use source 11 will break the Jenkins build which
> uses JDK 9 to run a full build including the -P commons-rng-examples
> profile. This could be ignored, updated to JDK 11 or dropped in favour of
> adding an appropriate JDK 11 run using Travis.
>
> Another option is to somehow get around the javadoc issue with modules and
> unnamed modules.
>
> WDYT?
>
> Alex
>
>
> >
> > Alex
> >
> >
> > [1] https://github.com/apache/commons-rng/pull/32 <
> https://github.com/apache/commons-rng/pull/32>
> >>
> >> Gary
> >>
> >>
> >>>
> >>> Alex
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <mailto:
> dev-unsubscribe@commons.apache.org>
> >>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:
> dev-help@commons.apache.org>
>
Re: [rng] Releasing 1.3
Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.
Le lun. 4 nov. 2019 à 13:05, Alex Herbert <al...@gmail.com> a écrit :
>
>
> On 04/11/2019 00:42, Gilles Sadowski wrote:
> > Hi.
> >
> >> [...]
> >>
> >> So there are at least two options:
> >>
> >> 1. Release using JDK 9
> > +1
>
> OK. I'll run through the release with JDK 9. I do not think we have any
> NIO classes so the issue raised by Gary should not be present.
Here
$ JAVA_HOME=/usr/lib/jvm/java-9-openjdk-amd64 mvn
-Pcommons-rng-examples clean package install site site:stage
built fine (but I did not check the reports).
> I am looking at the clirr report to check and add @since tags.
>
> Q. How to annotate implementation of a new interface on an existing class?
>
> Should all the new interface methods have @since tags?
Isn't it good enough to have the tag in the class Javadoc?
Gilles
> >
> > [...]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
On 04/11/2019 00:42, Gilles Sadowski wrote:
> Hi.
>
>> [...]
>>
>> So there are at least two options:
>>
>> 1. Release using JDK 9
> +1
OK. I'll run through the release with JDK 9. I do not think we have any
NIO classes so the issue raised by Gary should not be present.
I am looking at the clirr report to check and add @since tags.
Q. How to annotate implementation of a new interface on an existing class?
Should all the new interface methods have @since tags?
>
>> 2. Update the examples project to use source 11 for the Java modules code and release using a non-oracle JDK 11
>>
>> Note that updating to use source 11 will break the Jenkins build which uses JDK 9 to run a full build including the -P commons-rng-examples profile. This could be ignored, updated to JDK 11 or dropped in favour of adding an appropriate JDK 11 run using Travis.
>>
>> Another option is to somehow get around the javadoc issue with modules and unnamed modules.
> Let's not delay because of side issues. :-)
> Hopefully, this will be fixed in a future JDK version, or when we
> upgrade the target
> of all modules.
>
> Best,
> Gilles
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
> [...]
>
> So there are at least two options:
>
> 1. Release using JDK 9
+1
> 2. Update the examples project to use source 11 for the Java modules code and release using a non-oracle JDK 11
>
> Note that updating to use source 11 will break the Jenkins build which uses JDK 9 to run a full build including the -P commons-rng-examples profile. This could be ignored, updated to JDK 11 or dropped in favour of adding an appropriate JDK 11 run using Travis.
>
> Another option is to somehow get around the javadoc issue with modules and unnamed modules.
Let's not delay because of side issues. :-)
Hopefully, this will be fixed in a future JDK version, or when we
upgrade the target
of all modules.
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
> On 3 Nov 2019, at 20:12, Alex Herbert <al...@gmail.com> wrote:
>
>
>
>> On 3 Nov 2019, at 19:30, Gary Gregory <garydgregory@gmail.com <ma...@gmail.com>> wrote:
>>
>> On Sun, Nov 3, 2019 at 10:01 AM Alex Herbert <alex.d.herbert@gmail.com <ma...@gmail.com>>
>> wrote:
>>
>>> I think everything is finalised for a release of RNG, namely:
>>>
>>> All bugs and issues with SonarCloud and LGTM.com <http://lgtm.com/> are fixed.
>>> The user guide has been updated for all the new features.
>>> The performance and quality results have been updated in the user guide.
>>>
>>> Any objections to me cutting a release candidate for v1.3? I hope to get
>>> it done next week.
>>>
>>
>> You first should make sure binary compatibility is there, Apache RAT check
>> passes, and so on. That will avoid possible issues in a RC.
>
> rat:check and clirr:check are part of the default maven build so errors should not enter the codebase.
>
> The clirr:clirr report is full of infos for all the new API methods and classes.
>
> I'll start with a release dry run and see how everything looks.
>
> The only outstanding “issue” is that the full code for release has to be built using JDK 9.
>
> The extra examples maven modules contains some code using Java 9 modules. All my attempts to get a build to work with JDK 11 have failed on the javadoc tool which complains about building for code using modules that references packages in the named module [1]. My last attempt using JDK 11.0.4 had the same error I found with JDK 11.0.2. I have not a found a fix for a multi-module Maven project that uses different java source versions and includes some java 9 source explicitly using modules.
>
> Given that JDK 11.0.5 is out I will have another look at this. A brief scan of the release notes for 11.0.5 does not mention anything but it is worth a try. I’d rather do a release using JDK 11 than JDK 9.
JDK 11 works depending on the vendor and the source version!
Steps
1. Optional. Update commons-rng-examples/examples-jpms/pom.xml to changes the source and target from 9 to 11. This is:
<maven.compiler.source>11</maven.compiler.source>
<maven.compiler.target>11</maven.compiler.target>
<maven.compiler.release>11</maven.compiler.release>
2. Build using: mvn clean package site site:stage -P commons-rng-examples
Tested two JDK 11 distributions:
Official JDK from https://jdk.java.net/java-se-ri/11 <https://jdk.java.net/java-se-ri/11>
java -version
java version "11.0.5" 2019-10-15 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.5+10-LTS)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.5+10-LTS, mixed mode)
OpenAdopt JDK https://adoptopenjdk.net/releases.html?variant=openjdk11&jvmVariant=hotspot#x64_linux <https://adoptopenjdk.net/releases.html?variant=openjdk11&jvmVariant=hotspot#x64_linux>
java -version
openjdk version "11.0.5" 2019-10-15
OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.5+10)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.5+10, mixed mode)
I tried 4 variants:
Source 9, JDK 11.0.5
Source 9, OpenAdopt JDK 11.0.5
Source 11, JDK 11.0.5
Source 11, OpenAdopt JDK 11.0.5
Source 9, JDK 11.0.5
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.8.2:site (default-site) on project commons-rng-examples-jpms-lib: Error generating maven-javadoc-plugin:3.1.1:javadoc report:
[ERROR] Exit code: 1 - javadoc: error - The code being documented uses modules but the packages defined in https://docs.oracle.com/javase/9/docs/api/ are in the unnamed module.
[ERROR] javadoc: error - The code being documented uses modules but the packages defined in https://commons.apache.org/proper/commons-rng/commons-rng-client-api/apidocs/ are in the unnamed module.
[ERROR] javadoc: error - The code being documented uses modules but the packages defined in https://commons.apache.org/proper/commons-rng/commons-rng-sampling/apidocs/ are in the unnamed module.
Source 9, OpenAdopt JDK 11.0.5
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.8.2:site (default-site) on project commons-rng-examples-jpms-lib: Error generating maven-javadoc-plugin:3.1.1:javadoc report:
[ERROR] Exit code: 1 - javadoc: error - The code being documented uses modules but the packages defined in https://docs.oracle.com/javase/9/docs/api/ are in the unnamed module.
Source 11, JDK 11.0.5
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.8.2:site (default-site) on project commons-rng-examples-jpms-lib: Error generating maven-javadoc-plugin:3.1.1:javadoc report:
[ERROR] Exit code: 1 - javadoc: error - The code being documented uses modules but the packages defined in https://commons.apache.org/proper/commons-rng/commons-rng-client-api/apidocs/ are in the unnamed module.
[ERROR] javadoc: error - The code being documented uses modules but the packages defined in https://commons.apache.org/proper/commons-rng/commons-rng-sampling/apidocs/ are in the unnamed module.
Source 11, OpenAdopt JDK 11.0.5
OK
So there are at least two options:
1. Release using JDK 9
2. Update the examples project to use source 11 for the Java modules code and release using a non-oracle JDK 11
Note that updating to use source 11 will break the Jenkins build which uses JDK 9 to run a full build including the -P commons-rng-examples profile. This could be ignored, updated to JDK 11 or dropped in favour of adding an appropriate JDK 11 run using Travis.
Another option is to somehow get around the javadoc issue with modules and unnamed modules.
WDYT?
Alex
>
> Alex
>
>
> [1] https://github.com/apache/commons-rng/pull/32 <https://github.com/apache/commons-rng/pull/32>
>>
>> Gary
>>
>>
>>>
>>> Alex
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org <ma...@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
> On 3 Nov 2019, at 19:30, Gary Gregory <ga...@gmail.com> wrote:
>
> On Sun, Nov 3, 2019 at 10:01 AM Alex Herbert <al...@gmail.com>
> wrote:
>
>> I think everything is finalised for a release of RNG, namely:
>>
>> All bugs and issues with SonarCloud and LGTM.com are fixed.
>> The user guide has been updated for all the new features.
>> The performance and quality results have been updated in the user guide.
>>
>> Any objections to me cutting a release candidate for v1.3? I hope to get
>> it done next week.
>>
>
> You first should make sure binary compatibility is there, Apache RAT check
> passes, and so on. That will avoid possible issues in a RC.
rat:check and clirr:check are part of the default maven build so errors should not enter the codebase.
The clirr:clirr report is full of infos for all the new API methods and classes.
I'll start with a release dry run and see how everything looks.
The only outstanding “issue” is that the full code for release has to be built using JDK 9.
The extra examples maven modules contains some code using Java 9 modules. All my attempts to get a build to work with JDK 11 have failed on the javadoc tool which complains about building for code using modules that references packages in the named module [1]. My last attempt using JDK 11.0.4 had the same error I found with JDK 11.0.2. I have not a found a fix for a multi-module Maven project that uses different java source versions and includes some java 9 source explicitly using modules.
Given that JDK 11.0.5 is out I will have another look at this. A brief scan of the release notes for 11.0.5 does not mention anything but it is worth a try. I’d rather do a release using JDK 11 than JDK 9.
Alex
[1] https://github.com/apache/commons-rng/pull/32 <https://github.com/apache/commons-rng/pull/32>
>
> Gary
>
>
>>
>> Alex
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
Re: [rng] Releasing 1.3
Posted by Gary Gregory <ga...@gmail.com>.
On Sun, Nov 3, 2019 at 10:01 AM Alex Herbert <al...@gmail.com>
wrote:
> I think everything is finalised for a release of RNG, namely:
>
> All bugs and issues with SonarCloud and LGTM.com are fixed.
> The user guide has been updated for all the new features.
> The performance and quality results have been updated in the user guide.
>
> Any objections to me cutting a release candidate for v1.3? I hope to get
> it done next week.
>
You first should make sure binary compatibility is there, Apache RAT check
passes, and so on. That will avoid possible issues in a RC.
Gary
>
> Alex
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
[rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
I think everything is finalised for a release of RNG, namely:
All bugs and issues with SonarCloud and LGTM.com are fixed.
The user guide has been updated for all the new features.
The performance and quality results have been updated in the user guide.
Any objections to me cutting a release candidate for v1.3? I hope to get it done next week.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Abhishek Dhadwal <dh...@gmail.com>.
Thank you sir. I apologise for any inconvenience caused.
Regards,
Abhishek
On Tue, Sep 17, 2019 at 1:38 AM Alex Herbert <al...@gmail.com>
wrote:
>
> > On 16 Sep 2019, at 17:47, Abhishek Dhadwal <dh...@gmail.com>
> wrote:
> >
> > Hi Alex,
> >
> > I apologise for the delay in the release. My luck has provided me with
> back
> > to back bouts of food poisoning and viral infections, so, systems are
> down
> > at the moment.
> > Before I got infected, I researched around and found the following
> > resources which I intend to use as my references :
> >
> > The original article by Bob Jenkins :
> >
> > https://burtleburtle.net/bob/rand/smallprng.html
> >
> > ME O'Neil's discussion about the generator, its characteristics and test
> > results :
> >
> >
> http://www.pcg-random.org/posts/bob-jenkins-small-prng-passes-practrand.html
> >
> > ME O’Neil’s original implementation :
> >
> > https://gist.github.com/imneme/85cff47d4bad8de6bdeb671f9c76c814
> >
> > Testing output generation(reference) from ME O’Neil’s implementation of
> JSF:
> >
> >
> https://github.com/bashtage/randomgen/blob/1598d5b7fafedadc2aa07201951300bf2fe16d37/randomgen/src/jsf/jsf-test-data-gen.cpp
> >
> >
> > I may take a couple of days to completely recuperate, and two to four
> days
> > more to complete the implementation.
> >
> > In case there is a deadline for completion, let me know, I may attempt
> > working at it earlier than intended, or concede responsibility to another
> > member of the Commons Development society.
>
> OK. I don’t want to add extra work to your schedule especially if you are
> ill.
>
> The generator is very small so I just pushed a version to master. I meant
> to push via a PR but didn’t create a topic branch. The code passes the
> default maven goal.
>
> I will move on with testing this with the stress tests and then update the
> user guide for the next release with updated performance tests.
>
> Alex
>
> >
> >
> > Thanking you,
> >
> > Yours faithfully,
> >
> > Abhishek Dhadwal
> >
> >
> >
> > On Mon, Sep 16, 2019 at 10:03 PM Alex Herbert <al...@gmail.com>
> > wrote:
> >
> >> On 30/08/2019 14:11, Abhishek Dhadwal wrote:
> >>> Hello,
> >>>
> >>> What would be the deadline for the release ?
> >>> If it’s not too early I could resolve RNG-111 (
> >> https://issues.apache.org/jira/browse/RNG-111) over the next few days.
> I
> >> couldn’t work on it before due to back to back college project
> evaluations
> >> and my mid term examinations (which get over by tomorrow).
> >>
> >> Hi Abhishek,
> >>
> >> Any progress on RNG-111? There is nothing else outstanding for the 1.3
> >> release.
> >>
> >> Thanks,
> >>
> >> Alex
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >> For additional commands, e-mail: dev-help@commons.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
> On 16 Sep 2019, at 17:47, Abhishek Dhadwal <dh...@gmail.com> wrote:
>
> Hi Alex,
>
> I apologise for the delay in the release. My luck has provided me with back
> to back bouts of food poisoning and viral infections, so, systems are down
> at the moment.
> Before I got infected, I researched around and found the following
> resources which I intend to use as my references :
>
> The original article by Bob Jenkins :
>
> https://burtleburtle.net/bob/rand/smallprng.html
>
> ME O'Neil's discussion about the generator, its characteristics and test
> results :
>
> http://www.pcg-random.org/posts/bob-jenkins-small-prng-passes-practrand.html
>
> ME O’Neil’s original implementation :
>
> https://gist.github.com/imneme/85cff47d4bad8de6bdeb671f9c76c814
>
> Testing output generation(reference) from ME O’Neil’s implementation of JSF:
>
> https://github.com/bashtage/randomgen/blob/1598d5b7fafedadc2aa07201951300bf2fe16d37/randomgen/src/jsf/jsf-test-data-gen.cpp
>
>
> I may take a couple of days to completely recuperate, and two to four days
> more to complete the implementation.
>
> In case there is a deadline for completion, let me know, I may attempt
> working at it earlier than intended, or concede responsibility to another
> member of the Commons Development society.
OK. I don’t want to add extra work to your schedule especially if you are ill.
The generator is very small so I just pushed a version to master. I meant to push via a PR but didn’t create a topic branch. The code passes the default maven goal.
I will move on with testing this with the stress tests and then update the user guide for the next release with updated performance tests.
Alex
>
>
> Thanking you,
>
> Yours faithfully,
>
> Abhishek Dhadwal
>
>
>
> On Mon, Sep 16, 2019 at 10:03 PM Alex Herbert <al...@gmail.com>
> wrote:
>
>> On 30/08/2019 14:11, Abhishek Dhadwal wrote:
>>> Hello,
>>>
>>> What would be the deadline for the release ?
>>> If it’s not too early I could resolve RNG-111 (
>> https://issues.apache.org/jira/browse/RNG-111) over the next few days. I
>> couldn’t work on it before due to back to back college project evaluations
>> and my mid term examinations (which get over by tomorrow).
>>
>> Hi Abhishek,
>>
>> Any progress on RNG-111? There is nothing else outstanding for the 1.3
>> release.
>>
>> Thanks,
>>
>> Alex
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Abhishek Dhadwal <dh...@gmail.com>.
Hi Alex,
I apologise for the delay in the release. My luck has provided me with back
to back bouts of food poisoning and viral infections, so, systems are down
at the moment.
Before I got infected, I researched around and found the following
resources which I intend to use as my references :
The original article by Bob Jenkins :
https://burtleburtle.net/bob/rand/smallprng.html
ME O'Neil's discussion about the generator, its characteristics and test
results :
http://www.pcg-random.org/posts/bob-jenkins-small-prng-passes-practrand.html
ME O’Neil’s original implementation :
https://gist.github.com/imneme/85cff47d4bad8de6bdeb671f9c76c814
Testing output generation(reference) from ME O’Neil’s implementation of JSF:
https://github.com/bashtage/randomgen/blob/1598d5b7fafedadc2aa07201951300bf2fe16d37/randomgen/src/jsf/jsf-test-data-gen.cpp
I may take a couple of days to completely recuperate, and two to four days
more to complete the implementation.
In case there is a deadline for completion, let me know, I may attempt
working at it earlier than intended, or concede responsibility to another
member of the Commons Development society.
Thanking you,
Yours faithfully,
Abhishek Dhadwal
On Mon, Sep 16, 2019 at 10:03 PM Alex Herbert <al...@gmail.com>
wrote:
> On 30/08/2019 14:11, Abhishek Dhadwal wrote:
> > Hello,
> >
> > What would be the deadline for the release ?
> > If it’s not too early I could resolve RNG-111 (
> https://issues.apache.org/jira/browse/RNG-111) over the next few days. I
> couldn’t work on it before due to back to back college project evaluations
> and my mid term examinations (which get over by tomorrow).
>
> Hi Abhishek,
>
> Any progress on RNG-111? There is nothing else outstanding for the 1.3
> release.
>
> Thanks,
>
> Alex
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [rng] Releasing 1.3
Posted by Alex Herbert <al...@gmail.com>.
On 30/08/2019 14:11, Abhishek Dhadwal wrote:
> Hello,
>
> What would be the deadline for the release ?
> If it’s not too early I could resolve RNG-111 (https://issues.apache.org/jira/browse/RNG-111) over the next few days. I couldn’t work on it before due to back to back college project evaluations and my mid term examinations (which get over by tomorrow).
Hi Abhishek,
Any progress on RNG-111? There is nothing else outstanding for the 1.3
release.
Thanks,
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le ven. 30 août 2019 à 15:11, Abhishek Dhadwal <dh...@gmail.com> a écrit :
>
> Hello,
>
> What would be the deadline for the release ?
There is no deadline, but the sooner the better.
The many new features deserve a release.
> If it’s not too early I could resolve RNG-111 (https://issues.apache.org/jira/browse/RNG-111) over the next few days. I couldn’t work on it before due to back to back college project evaluations and my mid term examinations (which get over by tomorrow).
Great.
Best,
Gilles
>
> Regards,
> Abhishek
>
> Sent from Mail for Windows 10
>
> From: Gilles Sadowski
> Sent: 30 August 2019 17:22
> To: Commons Developers List
> Subject: Re: [rng] Releasing 1.3
>
> Hi.
>
> Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
> >
> >
> > On 10/06/2019 15:31, Gilles Sadowski wrote:
> > >>> P.S. Thinking of releasing 1.3?
> > >> Not yet. I think there are a few outstanding items [...]
>
> Status?
>
> In particular could we resolve
> https://issues.apache.org/jira/projects/RNG/issues/RNG-32
> and all its sub-tasks following the work done through GSoC?
>
> Best,
> Gilles
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
RE: [rng] Releasing 1.3
Posted by Abhishek Dhadwal <dh...@gmail.com>.
Hello,
What would be the deadline for the release ?
If it’s not too early I could resolve RNG-111 (https://issues.apache.org/jira/browse/RNG-111) over the next few days. I couldn’t work on it before due to back to back college project evaluations and my mid term examinations (which get over by tomorrow).
Regards,
Abhishek
Sent from Mail for Windows 10
From: Gilles Sadowski
Sent: 30 August 2019 17:22
To: Commons Developers List
Subject: Re: [rng] Releasing 1.3
Hi.
Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
>
>
> On 10/06/2019 15:31, Gilles Sadowski wrote:
> >>> P.S. Thinking of releasing 1.3?
> >> Not yet. I think there are a few outstanding items [...]
Status?
In particular could we resolve
https://issues.apache.org/jira/projects/RNG/issues/RNG-32
and all its sub-tasks following the work done through GSoC?
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [rng] Releasing 1.3
Posted by Gilles Sadowski <gi...@gmail.com>.
Hi.
Le lun. 10 juin 2019 à 17:17, Alex Herbert <al...@gmail.com> a écrit :
>
>
> On 10/06/2019 15:31, Gilles Sadowski wrote:
> >>> P.S. Thinking of releasing 1.3?
> >> Not yet. I think there are a few outstanding items [...]
Status?
In particular could we resolve
https://issues.apache.org/jira/projects/RNG/issues/RNG-32
and all its sub-tasks following the work done through GSoC?
Best,
Gilles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org