[GitHub] [commons-text] kinow closed pull request #237: Bump mockito-inline from 3.11.0 to 3.11.1
kinow closed pull request #237: URL: https://github.com/apache/commons-text/pull/237 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] dependabot[bot] commented on pull request #237: Bump mockito-inline from 3.11.0 to 3.11.1
dependabot[bot] commented on pull request #237: URL: https://github.com/apache/commons-text/pull/237#issuecomment-861196248 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-imaging] dependabot[bot] commented on pull request #153: Bump commons-io from 2.9.0 to 2.10.0
dependabot[bot] commented on pull request #153: URL: https://github.com/apache/commons-imaging/pull/153#issuecomment-861192826 OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting `@dependabot ignore this major version` or `@dependabot ignore this minor version`. You can also ignore all major, minor, or patch releases for a dependency by adding an [`ignore` condition](https://docs.github.com/en/code-security/supply-chain-security/configuration-options-for-dependency-updates#ignore) with the desired `update_types` to your config file. If you change your mind, just re-open this PR and I'll resolve any conflicts on it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-imaging] kinow closed pull request #153: Bump commons-io from 2.9.0 to 2.10.0
kinow closed pull request #153: URL: https://github.com/apache/commons-imaging/pull/153 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363317#comment-17363317
]
Matt Juntunen commented on NUMBERS-163:
---
Ok, I think I see what you're doing here. We don't need the accumulator class
because {{LinearCombination}} can be the accumulator itself. A few questions on
the API:
- Are you picturing {{LinearCombination}} being mutable?
- If we go this route with {{LinearCombination}}, would it make sense to try
something similar with {{Norm}} for consistency?
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363285#comment-17363285
]
Gilles Sadowski commented on NUMBERS-163:
-
bq. Can you flesh out the API you're proposing?
In part, it's the same as in you PR, minus the {{Accumulator}} class:
{code}
LinearCombination acc = LinearCombination.of(0, 0, 0, 0)
.add(u1, v1)
.add(u2, v2)
.add(u3, v3)
.add(u4, v4);
{code}
We could also provide
{code}
LinearCombination s = LinearCombination.of(u1, v1, u2, v2);
s = s.add(LinearCombination.of(u3, v3, u4, v4));
{code}
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (RNG-145) "ContinuousUniformSampler" with both bounds excluded
[
https://issues.apache.org/jira/browse/RNG-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363222#comment-17363222
]
Alex Herbert edited comment on RNG-145 at 6/14/21, 9:23 PM:
h2. Fixing the test for an open interval
I tried the obvious solution of testing the number of doubles in the range
between low and high. This can be done using the raw long bits of the double
and obtaining the difference between the two in a robust way that accounts for
the sign. This gap must be at least 1.
This mostly works. It does not work for this case:
{code:java}
double x = Double.MIN_VALUE;
ContinuousUniformSampler.of(rng, -x, x, true).sample()
{code}
The issue is that the only value of u that will create a sample of 0.0 is 0.5:
{code:java}
double x = Double.MIN_VALUE;
// OK
Assert.assertEquals(0.0, 0.5 * -x + 0.5 * x, 0.0);
// Fails to create the sample ...
Assert.assertNotEquals(0.0, Math.nextAfter(0.5, 1) * -x + Math.nextAfter(0.5,
-1) * x, 0.0);
// ... due to rounding
Assert.assertEquals(-x, Math.nextAfter(0.5, 1) * -x, 0.0);
Assert.assertEquals(0.0, Math.nextAfter(0.5, -1) * x, 0.0);
{code}
A sample can be create for other sub-normal ranges:
{code:java}
double x = Double.MIN_VALUE;
ContinuousUniformSampler.of(rng, 0.0, x*2, true).sample()
ContinuousUniformSampler.of(rng, x, x*3, true).sample()
{code}
In this case the lower and upper bounds have the same sign. The case of 2 ULP
difference not working for sub-normal numbers is when the sign changes.
I have updated the sampler to check the ULP is 2 if the lower and upper are the
same sign, otherwise the gap must be 3 ULP. This works and can create samples
that are not at the bounds.
was (Author: alexherbert):
h2. Fixing the test for an open interval
I tried the obvious solution of testing the number of doubles in the range
between low and high. This can be done using the raw long bits of the double
and obtaining the difference between the two in a robust way that accounts for
the sign. This gap must be at least 1.
This mostly works. It does not work for this case:
{code:java}
double x = Double.MIN_VALUE;
ContinuousUniformSampler.of(rng, -x, x, true).sample()
{code}
The issue is that the only value of u that will create a sample of 0.0 is 0.5:
{code:java}
double x = Double.MIN_VALUE;
// OK
Assert.assertEquals(0.0, 0.5 * -x + 0.5 * x, 0.0);
// Fails to create the sample ...
Assert.assertNotEquals(0.0, Math.nextAfter(0.5, 1) * -x + Math.nextAfter(0.5,
-1) * x, 0.0);
// ... due to rounding
Assert.assertEquals(-x, Math.nextAfter(0.5, 1) * -x, 0.0);
Assert.assertEquals(0.0, Math.nextAfter(0.5, -1) * x, 0.0);
{code}
A sample can be create for other sub-normal ranges:
{code:java}
double x = Double.MIN_VALUE;
ContinuousUniformSampler.of(rng, 0.0, x*2, true).sample()
ContinuousUniformSampler.of(rng, x, x*3, true).sample()
{code}
In this case the lower and upper bounds have the same sign. The case of 2 ULP
difference not working for sub-normal numbers is when the sign changes.
I have updated the sampler to check the ULP is 2 if the lower and upper are the
same sign, otherwise the gap must be 3 ULP. This works are can create samples
that are not at the bounds.
> "ContinuousUniformSampler" with both bounds excluded
>
>
> Key: RNG-145
> URL: https://issues.apache.org/jira/browse/RNG-145
> Project: Commons RNG
> Issue Type: New Feature
> Components: sampling
>Reporter: Gilles Sadowski
>Priority: Major
> Fix For: 1.4
>
>
> In class {{RandomUtils}}, Commons Math provides
> {code}
> public double nextUniform(double lo, double hi) { /* ... */ }
> {code}
> where both bounds are excluded.
> Should the feature be added to {{ContinuousUniformSampler}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (RNG-145) "ContinuousUniformSampler" with both bounds excluded
[
https://issues.apache.org/jira/browse/RNG-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363222#comment-17363222
]
Alex Herbert commented on RNG-145:
--
h2. Fixing the test for an open interval
I tried the obvious solution of testing the number of doubles in the range
between low and high. This can be done using the raw long bits of the double
and obtaining the difference between the two in a robust way that accounts for
the sign. This gap must be at least 1.
This mostly works. It does not work for this case:
{code:java}
double x = Double.MIN_VALUE;
ContinuousUniformSampler.of(rng, -x, x, true).sample()
{code}
The issue is that the only value of u that will create a sample of 0.0 is 0.5:
{code:java}
double x = Double.MIN_VALUE;
// OK
Assert.assertEquals(0.0, 0.5 * -x + 0.5 * x, 0.0);
// Fails to create the sample ...
Assert.assertNotEquals(0.0, Math.nextAfter(0.5, 1) * -x + Math.nextAfter(0.5,
-1) * x, 0.0);
// ... due to rounding
Assert.assertEquals(-x, Math.nextAfter(0.5, 1) * -x, 0.0);
Assert.assertEquals(0.0, Math.nextAfter(0.5, -1) * x, 0.0);
{code}
A sample can be create for other sub-normal ranges:
{code:java}
double x = Double.MIN_VALUE;
ContinuousUniformSampler.of(rng, 0.0, x*2, true).sample()
ContinuousUniformSampler.of(rng, x, x*3, true).sample()
{code}
In this case the lower and upper bounds have the same sign. The case of 2 ULP
difference not working for sub-normal numbers is when the sign changes.
I have updated the sampler to check the ULP is 2 if the lower and upper are the
same sign, otherwise the gap must be 3 ULP. This works are can create samples
that are not at the bounds.
> "ContinuousUniformSampler" with both bounds excluded
>
>
> Key: RNG-145
> URL: https://issues.apache.org/jira/browse/RNG-145
> Project: Commons RNG
> Issue Type: New Feature
> Components: sampling
>Reporter: Gilles Sadowski
>Priority: Major
> Fix For: 1.4
>
>
> In class {{RandomUtils}}, Commons Math provides
> {code}
> public double nextUniform(double lo, double hi) { /* ... */ }
> {code}
> where both bounds are excluded.
> Should the feature be added to {{ContinuousUniformSampler}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (MATH-1610) Remove "nextUniform(double,double)" from "RandomUtils"
[ https://issues.apache.org/jira/browse/MATH-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Sadowski resolved MATH-1610. --- Resolution: Done > Remove "nextUniform(double,double)" from "RandomUtils" > -- > > Key: MATH-1610 > URL: https://issues.apache.org/jira/browse/MATH-1610 > Project: Commons Math > Issue Type: Sub-task >Reporter: Gilles Sadowski >Priority: Major > Labels: api, remove > > Functionality moved to "Commons RNG" (cf. RNG-145). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MATH-1611) Remove "nextUniform(long,long)" from "RandomUtils"
Gilles Sadowski created MATH-1611: - Summary: Remove "nextUniform(long,long)" from "RandomUtils" Key: MATH-1611 URL: https://issues.apache.org/jira/browse/MATH-1611 Project: Commons Math Issue Type: Sub-task Reporter: Gilles Sadowski Functionality to be moved to "Commons RNG" (cf. RNG-140). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (MATH-1610) Remove "nextUniform(double,double)" from "RandomUtils"
Gilles Sadowski created MATH-1610: - Summary: Remove "nextUniform(double,double)" from "RandomUtils" Key: MATH-1610 URL: https://issues.apache.org/jira/browse/MATH-1610 Project: Commons Math Issue Type: Sub-task Reporter: Gilles Sadowski Functionality moved to "Commons RNG" (cf. RNG-145). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] coveralls commented on pull request #770: Removed use of restricted identifier
coveralls commented on pull request #770: URL: https://github.com/apache/commons-lang/pull/770#issuecomment-860954287 [](https://coveralls.io/builds/40572785) Coverage remained the same at 94.976% when pulling **3add9ab3795f07808ca7ab680673caf5fe23ed60 on fykidwai:master** into **197d50434748bfb2db935266cfe740fc01a607ee on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] fykidwai opened a new pull request #770: Removed use of restricted identifier
fykidwai opened a new pull request #770: URL: https://github.com/apache/commons-lang/pull/770 Modified variable name from 'var' to 'key' to avoid confusion in future with java 11+ versions -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-341) Add number to byte array methods
[
https://issues.apache.org/jira/browse/LANG-341?focusedWorklogId=610863=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610863
]
ASF GitHub Bot logged work on LANG-341:
---
Author: ASF GitHub Bot
Created on: 14/Jun/21 19:21
Start Date: 14/Jun/21 19:21
Worklog Time Spent: 10m
Work Description: yurelle commented on pull request #219:
URL: https://github.com/apache/commons-lang/pull/219#issuecomment-860932390
I never thought about using boolean; that's a good idea. Thanks.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 610863)
Time Spent: 1h 50m (was: 1h 40m)
> Add number to byte array methods
>
>
> Key: LANG-341
> URL: https://issues.apache.org/jira/browse/LANG-341
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Lilianne E. Blaze
>Priority: Major
> Fix For: Discussion
>
> Attachments: 341-v1-src.patch, 341-v1-test.patch, LANG-341-2.patch,
> LANG-341.patch
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Hello,
> I need a set of methods to convert Long to or from a byte[] array, as if
> writing / reading from Data(Input/Output)Stream(
> ByteArray(Input/Output)Stream ).
> First, doing it with Streams seems a bit wasteful, second, it seems a
> pretty general use. Would it be possible to add something like that to,
> for example,
> org.apache.commons.lang.math.NumberUtils?
> Example code:
> {code:java}
> static public long toLong(byte[] b)
> {
> return toLong(b, 0);
> }
>
> static public long toLong(byte[] b, int offset)
> {
> return (((long)b[offset] << 56) +
> ((long)(b[offset + 1] & 255) << 48) +
> ((long)(b[offset + 2] & 255) << 40) +
> ((long)(b[offset + 3] & 255) << 32) +
> ((long)(b[offset + 4] & 255) << 24) +
> ((b[offset + 5] & 255) << 16) +
> ((b[offset + 6] & 255) << 8) +
> ((b[offset + 7] & 255) << 0));
> }
>
> static public byte[] longToByteArray(long l)
> {
> byte b[] = new byte[8];
> longToByteArray(l, b, 0);
> return b;
> }
>
> static public void longToByteArray(long l, byte b[], int offset)
> {
> b[offset] = (byte)(l >>> 56);
> b[offset + 1] = (byte)(l >>> 48);
> b[offset + 2] = (byte)(l >>> 40);
> b[offset + 3] = (byte)(l >>> 32);
> b[offset + 4] = (byte)(l >>> 24);
> b[offset + 5] = (byte)(l >>> 16);
> b[offset + 6] = (byte)(l >>> 8);
> b[offset + 7] = (byte)(l >>> 0);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] yurelle commented on pull request #219: LANG-341: Add number to byte array methods to org.apache.commons.lang3.Conversion
yurelle commented on pull request #219: URL: https://github.com/apache/commons-lang/pull/219#issuecomment-860932390 I never thought about using boolean; that's a good idea. Thanks. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (TEXT-208) refine RandomStringGenerator to not check if random==null each time.also add a function for getting secured RandomStringGenerator conveniently.
[ https://issues.apache.org/jira/browse/TEXT-208?focusedWorklogId=610843=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610843 ] ASF GitHub Bot logged work on TEXT-208: --- Author: ASF GitHub Bot Created on: 14/Jun/21 18:55 Start Date: 14/Jun/21 18:55 Worklog Time Spent: 10m Work Description: coveralls commented on pull request #238: URL: https://github.com/apache/commons-text/pull/238#issuecomment-860916464 [](https://coveralls.io/builds/40570644) Coverage increased (+0.02%) to 97.982% when pulling **996ff64bf9fbcaab2abbb6202ae8901c72bafb71 on xenoamess-fork:add_secure_text_random_provider** into **0065576125d2e25055ee33b8681a903f48cab55a on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 610843) Remaining Estimate: 0h Time Spent: 10m > refine RandomStringGenerator to not check if random==null each time.also add > a function for getting secured RandomStringGenerator conveniently. > --- > > Key: TEXT-208 > URL: https://issues.apache.org/jira/browse/TEXT-208 > Project: Commons Text > Issue Type: Improvement >Reporter: Jin Xu >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > https://github.com/apache/commons-text/pull/238 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-text] coveralls commented on pull request #238: [TEXT-208]refine RandomStringGenerator to not check if random==null each time.also add a function for getting secured RandomStringGene
coveralls commented on pull request #238: URL: https://github.com/apache/commons-text/pull/238#issuecomment-860916464 [](https://coveralls.io/builds/40570644) Coverage increased (+0.02%) to 97.982% when pulling **996ff64bf9fbcaab2abbb6202ae8901c72bafb71 on xenoamess-fork:add_secure_text_random_provider** into **0065576125d2e25055ee33b8681a903f48cab55a on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-csv] coveralls edited a comment on pull request #130: Minor Improvement:
coveralls edited a comment on pull request #130: URL: https://github.com/apache/commons-csv/pull/130#issuecomment-766590441 [](https://coveralls.io/builds/40569758) Coverage remained the same at 98.463% when pulling **6d4a36a1ce229a59ae5dec8353e2db04b6dddc4f on arturobernalg:feature/minor_improvement** into **00fcb06bb5be4709a7c07fc834c2a1d1eb84e17e on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-daemon] arturobernalg opened a new pull request #31: MInor Changes:
arturobernalg opened a new pull request #31: URL: https://github.com/apache/commons-daemon/pull/31 * Simplify expressions * Use java array style * Replace Explicit with <> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] XenoAmess edited a comment on pull request #239: Remove use of restricted identifier
XenoAmess edited a comment on pull request #239: URL: https://github.com/apache/commons-text/pull/239#issuecomment-860886113 lgtm. `var` have some other meanings in 11+ so change it is a good point. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] XenoAmess commented on pull request #239: Remove use of restricted identifier
XenoAmess commented on pull request #239: URL: https://github.com/apache/commons-text/pull/239#issuecomment-860886113 lgtm. var have some other meanings in 11+ so change it is a good point. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (TEXT-208) refine RandomStringGenerator to not check if random==null each time.also add a function for getting secured RandomStringGenerator conveniently.
Jin Xu created TEXT-208: --- Summary: refine RandomStringGenerator to not check if random==null each time.also add a function for getting secured RandomStringGenerator conveniently. Key: TEXT-208 URL: https://issues.apache.org/jira/browse/TEXT-208 Project: Commons Text Issue Type: Improvement Reporter: Jin Xu https://github.com/apache/commons-text/pull/238 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-text] fykidwai opened a new pull request #239: Remove use of restricted identifier
fykidwai opened a new pull request #239: URL: https://github.com/apache/commons-text/pull/239 Modified variable name from 'var' to 'key' to avoid confusion in future -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] XenoAmess opened a new pull request #238: refine RandomStringGenerator to not check if random==null each time.
XenoAmess opened a new pull request #238: URL: https://github.com/apache/commons-text/pull/238 also add a function for getting secured RandomStringGenerator conveniently. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (RNG-145) "ContinuousUniformSampler" with both bounds excluded
[
https://issues.apache.org/jira/browse/RNG-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363112#comment-17363112
]
Alex Herbert commented on RNG-145:
--
The change to the sampler was valid but the test used {{>=}} and {{<=}} to test
the bound. When updated to use {{<}} and {{>}} it fails due to floating point
inaccuracy. Eliminating the sampler, the following test fails:
{code:java}
@Test
public void testOpenInterval() {
final double low = 3.18;
final double high = 5.23;
final double u = 0x1.0p-53d;
final double value = u * high + (1 - u) * low;
Assert.assertTrue("Value not in range: " + value, value > low && value <
high);
}
{code}
The range between 5.23 - 3.18 = 2.05. The precision of a double is not enough
to express a value that is the fraction 2^-53 of the range between the two
values. The result is rounded to 3.18.
A correct implementation will require creating the value and then repeating if
the bounds are reached. I've updated the code to use this method (commit
2cfea0baac98f65ce2145b91575847a2d106028e):
{code:java}
@Override
public double sample() {
final double x = super.sample();
// Due to rounding using a variate u in the open interval (0,1) with the
original
// algorithm may generate a value at the bound. Thus the bound is
explicitly tested
// and the sample repeated if necessary.
if (x == getHi() || x == getLo()) {
return sample();
}
return x;
}
{code}
There is an unsolved issue in that there must actually be a value in between
the bounds. This will create a stack overflow:
{code:java}
ContinuousUniformSampler.of(rng, 3.25, 3.25, true).sample();
{code}
The factory constructor must verify that the lower and upper bound have a
double value in between them. I will add a fix for this when I have considered
how to solve the problem.
> "ContinuousUniformSampler" with both bounds excluded
>
>
> Key: RNG-145
> URL: https://issues.apache.org/jira/browse/RNG-145
> Project: Commons RNG
> Issue Type: New Feature
> Components: sampling
>Reporter: Gilles Sadowski
>Priority: Major
> Fix For: 1.4
>
>
> In class {{RandomUtils}}, Commons Math provides
> {code}
> public double nextUniform(double lo, double hi) { /* ... */ }
> {code}
> where both bounds are excluded.
> Should the feature be added to {{ContinuousUniformSampler}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] XenoAmess edited a comment on pull request #459: (doc): Document public RandomStringUtils exploit
XenoAmess edited a comment on pull request #459: URL: https://github.com/apache/commons-lang/pull/459#issuecomment-860857383 Why not change to use `java.security.SecureRandom` here? Is there be any reason for not using it instead? What about adding a configuration boolean param about it? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] XenoAmess edited a comment on pull request #459: (doc): Document public RandomStringUtils exploit
XenoAmess edited a comment on pull request #459: URL: https://github.com/apache/commons-lang/pull/459#issuecomment-860857383 Why not change to use `java.security.SecureRandom` here? Is there be any reason for not using it instead? What about adding a configuration about it? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] XenoAmess commented on pull request #459: (doc): Document public RandomStringUtils exploit
XenoAmess commented on pull request #459: URL: https://github.com/apache/commons-lang/pull/459#issuecomment-860857383 Why not change to use java.security.SecureRandom here? Is there be any reason for not using it instead? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (LANG-1572) implement TODO in CharSequenceUtils.indexOf : remake it.
[ https://issues.apache.org/jira/browse/LANG-1572?focusedWorklogId=610763=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610763 ] ASF GitHub Bot logged work on LANG-1572: Author: ASF GitHub Bot Created on: 14/Jun/21 16:40 Start Date: 14/Jun/21 16:40 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #560: URL: https://github.com/apache/commons-lang/pull/560#issuecomment-650483751 [](https://coveralls.io/builds/40565919) Coverage decreased (-0.007%) to 94.969% when pulling **77452dd913879a8c09d14342b1c9a05a17db39ef on xenoamess-fork:remake_indexOf** into **197d50434748bfb2db935266cfe740fc01a607ee on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 610763) Time Spent: 4h 20m (was: 4h 10m) > implement TODO in CharSequenceUtils.indexOf : remake it. > > > Key: LANG-1572 > URL: https://issues.apache.org/jira/browse/LANG-1572 > Project: Commons Lang > Issue Type: Sub-task >Reporter: Jin Xu >Priority: Major > Time Spent: 4h 20m > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/560] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] coveralls edited a comment on pull request #560: [LANG-1572] green implementation CharSequenceUtils.indexOf
coveralls edited a comment on pull request #560: URL: https://github.com/apache/commons-lang/pull/560#issuecomment-650483751 [](https://coveralls.io/builds/40565919) Coverage decreased (-0.007%) to 94.969% when pulling **77452dd913879a8c09d14342b1c9a05a17db39ef on xenoamess-fork:remake_indexOf** into **197d50434748bfb2db935266cfe740fc01a607ee on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-724) FileUtils.deleteDirectory javadoc is inaccurate for nonexistent directory
[
https://issues.apache.org/jira/browse/IO-724?focusedWorklogId=610759=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610759
]
ASF GitHub Bot logged work on IO-724:
-
Author: ASF GitHub Bot
Created on: 14/Jun/21 16:27
Start Date: 14/Jun/21 16:27
Worklog Time Spent: 10m
Work Description: coveralls commented on pull request #245:
URL: https://github.com/apache/commons-io/pull/245#issuecomment-860819880
[](https://coveralls.io/builds/40565329)
Coverage remained the same at 89.25% when pulling
**4cdb88caaa0b05517ba84d0b2686c73719717ca0 on liran2000:IO-724-javadoc** into
**ff0237315321bf9e01d0df3aaf1b4e6a4d3b1618 on apache:master**.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 610759)
Time Spent: 50m (was: 40m)
> FileUtils.deleteDirectory javadoc is inaccurate for nonexistent directory
> -
>
> Key: IO-724
> URL: https://issues.apache.org/jira/browse/IO-724
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Henry Tung
>Priority: Minor
> Time Spent: 50m
> Remaining Estimate: 0h
>
> FileUtils.deleteDirectory javadoc claims:
> {code:java}
> @throws IllegalArgumentException if {@code directory} does not exist or is
> not a directory{code}
> but the first two lines of the code are:
> {code:java}
> Objects.requireNonNull(directory, "directory");
> if (!directory.exists()) {
> return;
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] coveralls commented on pull request #245: IO-724 deleteDirectory exception javadoc inaccurate update
coveralls commented on pull request #245: URL: https://github.com/apache/commons-io/pull/245#issuecomment-860819880 [](https://coveralls.io/builds/40565329) Coverage remained the same at 89.25% when pulling **4cdb88caaa0b05517ba84d0b2686c73719717ca0 on liran2000:IO-724-javadoc** into **ff0237315321bf9e01d0df3aaf1b4e6a4d3b1618 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?focusedWorklogId=610754=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610754
]
ASF GitHub Bot logged work on NUMBERS-163:
--
Author: ASF GitHub Bot
Created on: 14/Jun/21 16:10
Start Date: 14/Jun/21 16:10
Worklog Time Spent: 10m
Work Description: coveralls edited a comment on pull request #95:
URL: https://github.com/apache/commons-numbers/pull/95#issuecomment-860599924
[](https://coveralls.io/builds/40564790)
Coverage increased (+0.003%) to 99.665% when pulling
**30e8afb29eb11039e5780112c3de91421e8d4632 on darkma773r:numbers-163** into
**19899e7124dcd182fb3ebe31f17405c15be6cd19 on apache:master**.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 610754)
Time Spent: 0.5h (was: 20m)
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-numbers] coveralls edited a comment on pull request #95: NUMBERS-163: Accumulator classes
coveralls edited a comment on pull request #95: URL: https://github.com/apache/commons-numbers/pull/95#issuecomment-860599924 [](https://coveralls.io/builds/40564790) Coverage increased (+0.003%) to 99.665% when pulling **30e8afb29eb11039e5780112c3de91421e8d4632 on darkma773r:numbers-163** into **19899e7124dcd182fb3ebe31f17405c15be6cd19 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (RNG-145) "ContinuousUniformSampler" with both bounds excluded
[
https://issues.apache.org/jira/browse/RNG-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363044#comment-17363044
]
Alex Herbert commented on RNG-145:
--
Pushed a change in commit 81b07fadbfba6d6afe7bb74ec3e8a5a43a40c343 that adds
support for the open interval.
> "ContinuousUniformSampler" with both bounds excluded
>
>
> Key: RNG-145
> URL: https://issues.apache.org/jira/browse/RNG-145
> Project: Commons RNG
> Issue Type: New Feature
> Components: sampling
>Reporter: Gilles Sadowski
>Priority: Major
> Fix For: 1.4
>
>
> In class {{RandomUtils}}, Commons Math provides
> {code}
> public double nextUniform(double lo, double hi) { /* ... */ }
> {code}
> where both bounds are excluded.
> Should the feature be added to {{ContinuousUniformSampler}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (IO-724) FileUtils.deleteDirectory javadoc is inaccurate for nonexistent directory
[
https://issues.apache.org/jira/browse/IO-724?focusedWorklogId=610724=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610724
]
ASF GitHub Bot logged work on IO-724:
-
Author: ASF GitHub Bot
Created on: 14/Jun/21 15:29
Start Date: 14/Jun/21 15:29
Worklog Time Spent: 10m
Work Description: liran2000 edited a comment on pull request #245:
URL: https://github.com/apache/commons-io/pull/245#issuecomment-860778084
> Thinng about this will be better when after we apply JSR305
>
> If my memory be correct, there be a branch adding these annotations to
suggest Nullable or NotNull.
>
The most important here is to remove the "IllegalArgumentException" if
directory does not exist from the javadoc, which does not match the
implementation condition: if (!directory.exists()) { return;}
Regarding Nullable/NotNull, got it, removed this addition for now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 610724)
Time Spent: 40m (was: 0.5h)
> FileUtils.deleteDirectory javadoc is inaccurate for nonexistent directory
> -
>
> Key: IO-724
> URL: https://issues.apache.org/jira/browse/IO-724
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Henry Tung
>Priority: Minor
> Time Spent: 40m
> Remaining Estimate: 0h
>
> FileUtils.deleteDirectory javadoc claims:
> {code:java}
> @throws IllegalArgumentException if {@code directory} does not exist or is
> not a directory{code}
> but the first two lines of the code are:
> {code:java}
> Objects.requireNonNull(directory, "directory");
> if (!directory.exists()) {
> return;
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (IO-724) FileUtils.deleteDirectory javadoc is inaccurate for nonexistent directory
[
https://issues.apache.org/jira/browse/IO-724?focusedWorklogId=610723=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610723
]
ASF GitHub Bot logged work on IO-724:
-
Author: ASF GitHub Bot
Created on: 14/Jun/21 15:29
Start Date: 14/Jun/21 15:29
Worklog Time Spent: 10m
Work Description: liran2000 commented on pull request #245:
URL: https://github.com/apache/commons-io/pull/245#issuecomment-860778084
> Thinng about this will be better when after we apply JSR305
>
> If my memory be correct, there be a branch adding these annotations to
suggest Nullable or NotNull.
>
The most important here is to remove the "IllegalArgumentException" if
directory does not exist or from the javadoc, which does not match the
implementation condition: if (!directory.exists()) { return;}
Regarding Nullable/NotNull, got it, removed this addition for now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 610723)
Time Spent: 0.5h (was: 20m)
> FileUtils.deleteDirectory javadoc is inaccurate for nonexistent directory
> -
>
> Key: IO-724
> URL: https://issues.apache.org/jira/browse/IO-724
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Henry Tung
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> FileUtils.deleteDirectory javadoc claims:
> {code:java}
> @throws IllegalArgumentException if {@code directory} does not exist or is
> not a directory{code}
> but the first two lines of the code are:
> {code:java}
> Objects.requireNonNull(directory, "directory");
> if (!directory.exists()) {
> return;
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] liran2000 edited a comment on pull request #245: IO-724 deleteDirectory exception javadoc inaccurate update
liran2000 edited a comment on pull request #245:
URL: https://github.com/apache/commons-io/pull/245#issuecomment-860778084
> Thinng about this will be better when after we apply JSR305
>
> If my memory be correct, there be a branch adding these annotations to
suggest Nullable or NotNull.
>
The most important here is to remove the "IllegalArgumentException" if
directory does not exist from the javadoc, which does not match the
implementation condition: if (!directory.exists()) { return;}
Regarding Nullable/NotNull, got it, removed this addition for now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-io] liran2000 commented on pull request #245: IO-724 deleteDirectory exception javadoc inaccurate update
liran2000 commented on pull request #245:
URL: https://github.com/apache/commons-io/pull/245#issuecomment-860778084
> Thinng about this will be better when after we apply JSR305
>
> If my memory be correct, there be a branch adding these annotations to
suggest Nullable or NotNull.
>
The most important here is to remove the "IllegalArgumentException" if
directory does not exist or from the javadoc, which does not match the
implementation condition: if (!directory.exists()) { return;}
Regarding Nullable/NotNull, got it, removed this addition for now.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (RNG-140) nextLong(long lo, long hi)
[
https://issues.apache.org/jira/browse/RNG-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363024#comment-17363024
]
Gilles Sadowski commented on RNG-140:
-
bq. return an instance of the class from the factory constructor and not
interfaces?
I guess so because we don't know which interface the caller may need (as in the
case recently discussed).
> nextLong(long lo, long hi)
> --
>
> Key: RNG-140
> URL: https://issues.apache.org/jira/browse/RNG-140
> Project: Commons RNG
> Issue Type: Wish
> Components: sampling
>Reporter: Gilles Sadowski
>Priority: Minor
> Labels: api
>
> Replacement for functionality defined in
> [{{RandomUtils}}|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/random/RandomUtils.java;h=60060e71d5bbe1d00878a1f54f8bb1ff88b65f11;hb=HEAD#l293].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363020#comment-17363020
]
Matt Juntunen commented on NUMBERS-163:
---
bq. ... we should perhaps encapsulate the (extended precision) "implementation
details" in a SumVector3D class
+1. That's the plan :-)
bq. To add it to another instance; thus providing the accumulation
functionality (without an additional name).
Perhaps I'm not seeing the full picture here. Can you flesh out the API you're
proposing?
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (RNG-140) nextLong(long lo, long hi)
[
https://issues.apache.org/jira/browse/RNG-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363018#comment-17363018
]
Alex Herbert commented on RNG-140:
--
I can put the LongSampler and the implementation of UniformLongSampler into a
PR for review. It will be a lot of copy code as the tests will need expanding
to include the framework to test any LongSampler implementation.
Going forward shall we return an instance of the class from the factory
constructor and not interfaces? So any future change of interfaces that are
implemented will not be breaking compatibility.
> nextLong(long lo, long hi)
> --
>
> Key: RNG-140
> URL: https://issues.apache.org/jira/browse/RNG-140
> Project: Commons RNG
> Issue Type: Wish
> Components: sampling
>Reporter: Gilles Sadowski
>Priority: Minor
> Labels: api
>
> Replacement for functionality defined in
> [{{RandomUtils}}|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/random/RandomUtils.java;h=60060e71d5bbe1d00878a1f54f8bb1ff88b65f11;hb=HEAD#l293].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-341) Add number to byte array methods
[
https://issues.apache.org/jira/browse/LANG-341?focusedWorklogId=610715=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610715
]
ASF GitHub Bot logged work on LANG-341:
---
Author: ASF GitHub Bot
Created on: 14/Jun/21 14:52
Start Date: 14/Jun/21 14:52
Worklog Time Spent: 10m
Work Description: XenoAmess edited a comment on pull request #219:
URL: https://github.com/apache/commons-lang/pull/219#issuecomment-860747593
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 610715)
Time Spent: 1h 40m (was: 1.5h)
> Add number to byte array methods
>
>
> Key: LANG-341
> URL: https://issues.apache.org/jira/browse/LANG-341
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Lilianne E. Blaze
>Priority: Major
> Fix For: Discussion
>
> Attachments: 341-v1-src.patch, 341-v1-test.patch, LANG-341-2.patch,
> LANG-341.patch
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Hello,
> I need a set of methods to convert Long to or from a byte[] array, as if
> writing / reading from Data(Input/Output)Stream(
> ByteArray(Input/Output)Stream ).
> First, doing it with Streams seems a bit wasteful, second, it seems a
> pretty general use. Would it be possible to add something like that to,
> for example,
> org.apache.commons.lang.math.NumberUtils?
> Example code:
> {code:java}
> static public long toLong(byte[] b)
> {
> return toLong(b, 0);
> }
>
> static public long toLong(byte[] b, int offset)
> {
> return (((long)b[offset] << 56) +
> ((long)(b[offset + 1] & 255) << 48) +
> ((long)(b[offset + 2] & 255) << 40) +
> ((long)(b[offset + 3] & 255) << 32) +
> ((long)(b[offset + 4] & 255) << 24) +
> ((b[offset + 5] & 255) << 16) +
> ((b[offset + 6] & 255) << 8) +
> ((b[offset + 7] & 255) << 0));
> }
>
> static public byte[] longToByteArray(long l)
> {
> byte b[] = new byte[8];
> longToByteArray(l, b, 0);
> return b;
> }
>
> static public void longToByteArray(long l, byte b[], int offset)
> {
> b[offset] = (byte)(l >>> 56);
> b[offset + 1] = (byte)(l >>> 48);
> b[offset + 2] = (byte)(l >>> 40);
> b[offset + 3] = (byte)(l >>> 32);
> b[offset + 4] = (byte)(l >>> 24);
> b[offset + 5] = (byte)(l >>> 16);
> b[offset + 6] = (byte)(l >>> 8);
> b[offset + 7] = (byte)(l >>> 0);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-341) Add number to byte array methods
[
https://issues.apache.org/jira/browse/LANG-341?focusedWorklogId=610710=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610710
]
ASF GitHub Bot logged work on LANG-341:
---
Author: ASF GitHub Bot
Created on: 14/Jun/21 14:51
Start Date: 14/Jun/21 14:51
Worklog Time Spent: 10m
Work Description: XenoAmess commented on pull request #219:
URL: https://github.com/apache/commons-lang/pull/219#issuecomment-860747593
@yurelle
```
throw new IllegalArgumentException("Input data is longer than size of
'double' primitive ("+SIZE+" bytes)");
```
tips:
next time when you wanna bake some codes from a template for all primitive
types, suggest use `boolean`, as boolean is the less troublesome one in them...
if cannot use `boolean` then can use `double`
do never use `int` or `long` as template...that will cause the
`longer->doubler` thing.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 610710)
Time Spent: 1h 20m (was: 1h 10m)
> Add number to byte array methods
>
>
> Key: LANG-341
> URL: https://issues.apache.org/jira/browse/LANG-341
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Lilianne E. Blaze
>Priority: Major
> Fix For: Discussion
>
> Attachments: 341-v1-src.patch, 341-v1-test.patch, LANG-341-2.patch,
> LANG-341.patch
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Hello,
> I need a set of methods to convert Long to or from a byte[] array, as if
> writing / reading from Data(Input/Output)Stream(
> ByteArray(Input/Output)Stream ).
> First, doing it with Streams seems a bit wasteful, second, it seems a
> pretty general use. Would it be possible to add something like that to,
> for example,
> org.apache.commons.lang.math.NumberUtils?
> Example code:
> {code:java}
> static public long toLong(byte[] b)
> {
> return toLong(b, 0);
> }
>
> static public long toLong(byte[] b, int offset)
> {
> return (((long)b[offset] << 56) +
> ((long)(b[offset + 1] & 255) << 48) +
> ((long)(b[offset + 2] & 255) << 40) +
> ((long)(b[offset + 3] & 255) << 32) +
> ((long)(b[offset + 4] & 255) << 24) +
> ((b[offset + 5] & 255) << 16) +
> ((b[offset + 6] & 255) << 8) +
> ((b[offset + 7] & 255) << 0));
> }
>
> static public byte[] longToByteArray(long l)
> {
> byte b[] = new byte[8];
> longToByteArray(l, b, 0);
> return b;
> }
>
> static public void longToByteArray(long l, byte b[], int offset)
> {
> b[offset] = (byte)(l >>> 56);
> b[offset + 1] = (byte)(l >>> 48);
> b[offset + 2] = (byte)(l >>> 40);
> b[offset + 3] = (byte)(l >>> 32);
> b[offset + 4] = (byte)(l >>> 24);
> b[offset + 5] = (byte)(l >>> 16);
> b[offset + 6] = (byte)(l >>> 8);
> b[offset + 7] = (byte)(l >>> 0);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (LANG-341) Add number to byte array methods
[
https://issues.apache.org/jira/browse/LANG-341?focusedWorklogId=610711=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610711
]
ASF GitHub Bot logged work on LANG-341:
---
Author: ASF GitHub Bot
Created on: 14/Jun/21 14:51
Start Date: 14/Jun/21 14:51
Worklog Time Spent: 10m
Work Description: XenoAmess edited a comment on pull request #219:
URL: https://github.com/apache/commons-lang/pull/219#issuecomment-860747593
@yurelle
```
throw new IllegalArgumentException("Input data is longer than size of
'double' primitive ("+SIZE+" bytes)");
```
tips:
next time when you wanna bake some codes from a template for all primitive
types, suggest use `boolean`, as boolean is the less troublesome one in them...
if cannot use `boolean` then can use `double`
do never use `int` or `long` as template...that will cause the
`longer->doubleer` thing.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 610711)
Time Spent: 1.5h (was: 1h 20m)
> Add number to byte array methods
>
>
> Key: LANG-341
> URL: https://issues.apache.org/jira/browse/LANG-341
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.*
>Reporter: Lilianne E. Blaze
>Priority: Major
> Fix For: Discussion
>
> Attachments: 341-v1-src.patch, 341-v1-test.patch, LANG-341-2.patch,
> LANG-341.patch
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Hello,
> I need a set of methods to convert Long to or from a byte[] array, as if
> writing / reading from Data(Input/Output)Stream(
> ByteArray(Input/Output)Stream ).
> First, doing it with Streams seems a bit wasteful, second, it seems a
> pretty general use. Would it be possible to add something like that to,
> for example,
> org.apache.commons.lang.math.NumberUtils?
> Example code:
> {code:java}
> static public long toLong(byte[] b)
> {
> return toLong(b, 0);
> }
>
> static public long toLong(byte[] b, int offset)
> {
> return (((long)b[offset] << 56) +
> ((long)(b[offset + 1] & 255) << 48) +
> ((long)(b[offset + 2] & 255) << 40) +
> ((long)(b[offset + 3] & 255) << 32) +
> ((long)(b[offset + 4] & 255) << 24) +
> ((b[offset + 5] & 255) << 16) +
> ((b[offset + 6] & 255) << 8) +
> ((b[offset + 7] & 255) << 0));
> }
>
> static public byte[] longToByteArray(long l)
> {
> byte b[] = new byte[8];
> longToByteArray(l, b, 0);
> return b;
> }
>
> static public void longToByteArray(long l, byte b[], int offset)
> {
> b[offset] = (byte)(l >>> 56);
> b[offset + 1] = (byte)(l >>> 48);
> b[offset + 2] = (byte)(l >>> 40);
> b[offset + 3] = (byte)(l >>> 32);
> b[offset + 4] = (byte)(l >>> 24);
> b[offset + 5] = (byte)(l >>> 16);
> b[offset + 6] = (byte)(l >>> 8);
> b[offset + 7] = (byte)(l >>> 0);
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-lang] XenoAmess edited a comment on pull request #219: LANG-341: Add number to byte array methods to org.apache.commons.lang3.Conversion
XenoAmess edited a comment on pull request #219: URL: https://github.com/apache/commons-lang/pull/219#issuecomment-860747593 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-lang] XenoAmess edited a comment on pull request #219: LANG-341: Add number to byte array methods to org.apache.commons.lang3.Conversion
XenoAmess edited a comment on pull request #219:
URL: https://github.com/apache/commons-lang/pull/219#issuecomment-860747593
@yurelle
```
throw new IllegalArgumentException("Input data is longer than size of
'double' primitive ("+SIZE+" bytes)");
```
tips:
next time when you wanna bake some codes from a template for all primitive
types, suggest use `boolean`, as boolean is the less troublesome one in them...
if cannot use `boolean` then can use `double`
do never use `int` or `long` as template...that will cause the
`longer->doubleer` thing.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-lang] XenoAmess commented on pull request #219: LANG-341: Add number to byte array methods to org.apache.commons.lang3.Conversion
XenoAmess commented on pull request #219:
URL: https://github.com/apache/commons-lang/pull/219#issuecomment-860747593
@yurelle
```
throw new IllegalArgumentException("Input data is longer than size of
'double' primitive ("+SIZE+" bytes)");
```
tips:
next time when you wanna bake some codes from a template for all primitive
types, suggest use `boolean`, as boolean is the less troublesome one in them...
if cannot use `boolean` then can use `double`
do never use `int` or `long` as template...that will cause the
`longer->doubler` thing.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[jira] [Commented] (RNG-140) nextLong(long lo, long hi)
[
https://issues.apache.org/jira/browse/RNG-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363000#comment-17363000
]
Gilles Sadowski commented on RNG-140:
-
bq. I suggest [...] {{LongSampler}}
I'd have favoured {{DiscreteLongSampler}} (as alphabetical hint of functional
similarity) but you are probably right since it a low-level class required to
handle a different type. [The more so if the {{DiscreteSampler}} and
{{ContinuousSampler}} are going to disappear.]
bq. methods names are not as nice as the current {{sample}}.
{code}
interface ...
implements DoubleSupplier{
@Override
double getAsDouble();
default double sample() {
return getAsDouble();
}
}
{code}
> nextLong(long lo, long hi)
> --
>
> Key: RNG-140
> URL: https://issues.apache.org/jira/browse/RNG-140
> Project: Commons RNG
> Issue Type: Wish
> Components: sampling
>Reporter: Gilles Sadowski
>Priority: Minor
> Labels: api
>
> Replacement for functionality defined in
> [{{RandomUtils}}|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/random/RandomUtils.java;h=60060e71d5bbe1d00878a1f54f8bb1ff88b65f11;hb=HEAD#l293].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (IO-724) FileUtils.deleteDirectory javadoc is inaccurate for nonexistent directory
[
https://issues.apache.org/jira/browse/IO-724?focusedWorklogId=610699=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610699
]
ASF GitHub Bot logged work on IO-724:
-
Author: ASF GitHub Bot
Created on: 14/Jun/21 14:26
Start Date: 14/Jun/21 14:26
Worklog Time Spent: 10m
Work Description: XenoAmess commented on pull request #245:
URL: https://github.com/apache/commons-io/pull/245#issuecomment-860728365
Thinng about this will be better when after we apply JSR305
If my memory be correct, there be a branch adding these annotations to
suggest Nullable or NotNull.
How's it going @garydgregory ?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 610699)
Time Spent: 20m (was: 10m)
> FileUtils.deleteDirectory javadoc is inaccurate for nonexistent directory
> -
>
> Key: IO-724
> URL: https://issues.apache.org/jira/browse/IO-724
> Project: Commons IO
> Issue Type: Bug
> Components: Utilities
>Affects Versions: 2.8.0
>Reporter: Henry Tung
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> FileUtils.deleteDirectory javadoc claims:
> {code:java}
> @throws IllegalArgumentException if {@code directory} does not exist or is
> not a directory{code}
> but the first two lines of the code are:
> {code:java}
> Objects.requireNonNull(directory, "directory");
> if (!directory.exists()) {
> return;
> }{code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-io] XenoAmess commented on pull request #245: IO-724 deleteDirectory exception javadoc inaccurate update
XenoAmess commented on pull request #245: URL: https://github.com/apache/commons-io/pull/245#issuecomment-860728365 Thinng about this will be better when after we apply JSR305 If my memory be correct, there be a branch adding these annotations to suggest Nullable or NotNull. How's it going @garydgregory ? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362985#comment-17362985
]
Gilles Sadowski commented on NUMBERS-163:
-
I would have suggested the {{Accumulator}} inner class myself, on the a priori
that the alternative was less efficient. I recall having suggested inner
classes where [~mattjuntunen] didn't want them. ;)
But now it seems that such a class could just be redundant.
{quote}You can have different implementations of LinearCombination.
{quote}
Yes (I seem to recall I raised that point somewhere else).
By maintaining the "static" API, we prevent the flexibility (IIUC).
{quote}What would one do with an instance of LinearCombination besides get the
double value from it? In that case, why even have an instance at all?
{quote}
To add it to another instance; thus providing the accumulation functionality
(without an additional name).
Note: An accumulator class may still be needed in the context of a
[collector|https://docs.oracle.com/javase/8/docs/api/java/util/stream/Collector.html]
but it could perhaps be private (?).
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (POOL-396) Exceptions in validation can cause an object's lifecycle to be stuck in EVICTION state
[
https://issues.apache.org/jira/browse/POOL-396?focusedWorklogId=610694=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610694
]
ASF GitHub Bot logged work on POOL-396:
---
Author: ASF GitHub Bot
Created on: 14/Jun/21 14:08
Start Date: 14/Jun/21 14:08
Worklog Time Spent: 10m
Work Description: coveralls commented on pull request #85:
URL: https://github.com/apache/commons-pool/pull/85#issuecomment-860714291
[](https://coveralls.io/builds/40561036)
Coverage increased (+0.03%) to 84.03% when pulling
**df6e1233b6f848754108f423e30cbbefb481a258 on jeremyk-91:POOL-396-validation**
into **e405182e6eaabc7422dfd6f65511b7883443b1e9 on apache:master**.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 610694)
Time Spent: 20m (was: 10m)
> Exceptions in validation can cause an object's lifecycle to be stuck in
> EVICTION state
> --
>
> Key: POOL-396
> URL: https://issues.apache.org/jira/browse/POOL-396
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.4.2, 2.9.0
>Reporter: Jeremy Kong
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, if validation of an object throws an exception when testing an
> idle object during eviction, an exception will be thrown from the evict()
> method. This causes the object to be left in the EVICTION state, but still be
> present in the idleObjects queue.
> Future runs of the eviction thread will run into an infinite loop, because
> they pick up the afflicted object from the queue, fail to set its state to
> EVICTION, don't count it as a test, and repeat ad infinitum. This infinite
> loop means that no further evictions will take place; it also causes
> increases in garbage collection owing to allocation of the EvictionIterator
> on each loop iteration.
> This test added to TestGenericObjectPool (plus a small change allowing
> exceptions to be thrown from the validateObject method of SimpleFactory)
> reproduces the issue.
> {code:java}
> @Test
> @Timeout(value = 6, unit = TimeUnit.MILLISECONDS)
> public void testExceptionInValidationDuringEviction() throws Exception {
> genericObjectPool.setMaxIdle(1);
> genericObjectPool.setMaxTotal(2);
> genericObjectPool.setNumTestsPerEvictionRun(1);
> genericObjectPool.setMinEvictableIdleTime(Duration.ofMillis(0));
> genericObjectPool.setTestWhileIdle(true);
> String active = genericObjectPool.borrowObject();
> genericObjectPool.returnObject(active);
> simpleFactory.setThrowExceptionOnValidate(true);
> try {
> genericObjectPool.evict();
> } catch (Exception e) {
> // OK that a given run fails. But the object should still be evicted.
> }
> genericObjectPool.evict(); // currently fails: causes an infinite loop!
> assertEquals(0, genericObjectPool.getNumActive());
> assertEquals(0, genericObjectPool.getNumIdle());
> }
> {code}
> It seems that protection against exceptions thrown by validation code exist
> elsewhere (e.g. in borrowObject()); similarly, protections against exceptions
> thrown by user eviction policy code exist in evict(). So it looks like the
> testWhileIdle() portion of evict() needs to similarly be protected.
> Thanks!
> Jeremy
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-pool] coveralls commented on pull request #85: POOL-396: Handle validation exceptions during eviction.
coveralls commented on pull request #85: URL: https://github.com/apache/commons-pool/pull/85#issuecomment-860714291 [](https://coveralls.io/builds/40561036) Coverage increased (+0.03%) to 84.03% when pulling **df6e1233b6f848754108f423e30cbbefb481a258 on jeremyk-91:POOL-396-validation** into **e405182e6eaabc7422dfd6f65511b7883443b1e9 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (RNG-145) "ContinuousUniformSampler" with both bounds excluded
[
https://issues.apache.org/jira/browse/RNG-145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362980#comment-17362980
]
Alex Herbert commented on RNG-145:
--
I am OK with this. I think this is valid:
{code:java}
public static SharedStateContinuousSampler of(UniformRandomProvider rng,
double lo,
double hi,
boolean excludeBounds) {
{code}
Currently the underlying nextDouble() method typically returns in the interval
[0, 1). So the current ContinuousUniformSampler will return in the interval
[lower, upper). The sampler is robust to a swap of the arguments so you can get
the alternative (lower, upper] by swapping the arguments to the constructor.
The sample is generated using:
{code:java}
final double u = rng.nextDouble();
return u * hi + (1 - u) * lo;
{code}
So if the nextDouble() does return either 0 or 1 you get one of the bounds.
The current method in Commons Math trusts the implementation of nextDouble does
not return 1 and only checks for 0.
To ensure we generate in the open interval (lower, upper) I think requires not
using (trusting) nextDouble() and instead using nextLong() and eliminating 0
from the call to (nextLong() >>> 11). From the 2^53 -1 numbers that are left
you can create a double in (0, 1).
> "ContinuousUniformSampler" with both bounds excluded
>
>
> Key: RNG-145
> URL: https://issues.apache.org/jira/browse/RNG-145
> Project: Commons RNG
> Issue Type: New Feature
> Components: sampling
>Reporter: Gilles Sadowski
>Priority: Major
> Fix For: 1.4
>
>
> In class {{RandomUtils}}, Commons Math provides
> {code}
> public double nextUniform(double lo, double hi) { /* ... */ }
> {code}
> where both bounds are excluded.
> Should the feature be added to {{ContinuousUniformSampler}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (RNG-140) nextLong(long lo, long hi)
[
https://issues.apache.org/jira/browse/RNG-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362965#comment-17362965
]
Alex Herbert commented on RNG-140:
--
It could. But for the {{int}} case we have a sampler in the sampling package
that does the equivalent algorithm:
{code:java}
DiscreteSampler sampler = DiscreteUniformSampler.of(rng, lower, upper);
{code}
Pending an eventual update to Java 8 it would make more sense to have a sampler
interface that returns a long so we can move to support double, int or long
streams with the sampler as a supplier. Perhaps DiscreteLongSampler or just
LongSampler?
* ContinuousSampler (double)
* DiscreteSampler (int)
* DiscreteLongSampler (long)
* LongSampler (long)
Since the interfaces are functional interfaces (1 method) it would be cleaner
(in Java 8) to have the samplers just implement:
* DoubleSupplier.getAsDouble
* IntSupplier.getAsInt
* LongSupplier.getAsLong
The methods names are not as nice as the current {{sample}}. And we would have
to add the SharedStateSampler support to this:
* SharedStateDoubleSupplier
* SharedStateIntSupplier
* SharedStateLongSupplier
So maybe:
* LongSampler
* SharedStateLongSampler
Then add an additional method to the current DiscreteUniformSampler with long
instead of int arguments:
{code:java}
int lower = ...
int upper = ...
SharedStateDiscreteSampler sampler1 = DiscreteUniformSampler.of(rng, lower,
upper);
SharedStateLongSampler sampler2 = DiscreteUniformSampler.of(rng, (long) lower,
(long) upper);
{code}
Note that the factory method returns the interface type. It was mentioned that
a fluent API would return an instance of the class. If this is to be used in
the future (RNG 2.0) then the factory method should be in its own class. A
future API would be to replace ContinuousSampler and DiscreteSampler and with
the more specific DoubleSampler and IntSampler:
{code:java}
DoubleSampler s1 = UniformDoubleSampler.of(rng, 3.12, 4.23);
IntSampler s2 = UniformIntSampler.of(rng, 32, 45);
LongSampler s3 = UniformLongSampler.of(rng, 132L, 145L);
{code}
This cannot be done currently as factory methods are tied to returning
instances of the interface SharedState(Continuous|Discrete)Sampler. So those
interfaces must continue until a major release.
For now I suggest adding:
* LongSampler (interface)
* SharedStateLongSampler (interface)
* UniformLongSampler (sampler that implements the algorithm)
> nextLong(long lo, long hi)
> --
>
> Key: RNG-140
> URL: https://issues.apache.org/jira/browse/RNG-140
> Project: Commons RNG
> Issue Type: Wish
> Components: sampling
>Reporter: Gilles Sadowski
>Priority: Minor
> Labels: api
>
> Replacement for functionality defined in
> [{{RandomUtils}}|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/random/RandomUtils.java;h=60060e71d5bbe1d00878a1f54f8bb1ff88b65f11;hb=HEAD#l293].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (POOL-396) Exceptions in validation can cause an object's lifecycle to be stuck in EVICTION state
[
https://issues.apache.org/jira/browse/POOL-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362952#comment-17362952
]
Jeremy Kong commented on POOL-396:
--
I have proposed a fix in
[https://github.com/apache/commons-pool/pull/85|https://github.com/apache/commons-pool/pull/85].
> Exceptions in validation can cause an object's lifecycle to be stuck in
> EVICTION state
> --
>
> Key: POOL-396
> URL: https://issues.apache.org/jira/browse/POOL-396
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.4.2, 2.9.0
>Reporter: Jeremy Kong
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, if validation of an object throws an exception when testing an
> idle object during eviction, an exception will be thrown from the evict()
> method. This causes the object to be left in the EVICTION state, but still be
> present in the idleObjects queue.
> Future runs of the eviction thread will run into an infinite loop, because
> they pick up the afflicted object from the queue, fail to set its state to
> EVICTION, don't count it as a test, and repeat ad infinitum. This infinite
> loop means that no further evictions will take place; it also causes
> increases in garbage collection owing to allocation of the EvictionIterator
> on each loop iteration.
> This test added to TestGenericObjectPool (plus a small change allowing
> exceptions to be thrown from the validateObject method of SimpleFactory)
> reproduces the issue.
> {code:java}
> @Test
> @Timeout(value = 6, unit = TimeUnit.MILLISECONDS)
> public void testExceptionInValidationDuringEviction() throws Exception {
> genericObjectPool.setMaxIdle(1);
> genericObjectPool.setMaxTotal(2);
> genericObjectPool.setNumTestsPerEvictionRun(1);
> genericObjectPool.setMinEvictableIdleTime(Duration.ofMillis(0));
> genericObjectPool.setTestWhileIdle(true);
> String active = genericObjectPool.borrowObject();
> genericObjectPool.returnObject(active);
> simpleFactory.setThrowExceptionOnValidate(true);
> try {
> genericObjectPool.evict();
> } catch (Exception e) {
> // OK that a given run fails. But the object should still be evicted.
> }
> genericObjectPool.evict(); // currently fails: causes an infinite loop!
> assertEquals(0, genericObjectPool.getNumActive());
> assertEquals(0, genericObjectPool.getNumIdle());
> }
> {code}
> It seems that protection against exceptions thrown by validation code exist
> elsewhere (e.g. in borrowObject()); similarly, protections against exceptions
> thrown by user eviction policy code exist in evict(). So it looks like the
> testWhileIdle() portion of evict() needs to similarly be protected.
> Thanks!
> Jeremy
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (RNG-145) "ContinuousUniformSampler" with both bounds excluded
Gilles Sadowski created RNG-145:
---
Summary: "ContinuousUniformSampler" with both bounds excluded
Key: RNG-145
URL: https://issues.apache.org/jira/browse/RNG-145
Project: Commons RNG
Issue Type: New Feature
Components: sampling
Reporter: Gilles Sadowski
Fix For: 1.4
In class {{RandomUtils}}, Commons Math provides
{code}
public double nextUniform(double lo, double hi) { /* ... */ }
{code}
where both bounds are excluded.
Should the feature be added to {{ContinuousUniformSampler}}?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (POOL-396) Exceptions in validation can cause an object's lifecycle to be stuck in EVICTION state
[
https://issues.apache.org/jira/browse/POOL-396?focusedWorklogId=610663=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610663
]
ASF GitHub Bot logged work on POOL-396:
---
Author: ASF GitHub Bot
Created on: 14/Jun/21 13:17
Start Date: 14/Jun/21 13:17
Worklog Time Spent: 10m
Work Description: jeremyk-91 opened a new pull request #85:
URL: https://github.com/apache/commons-pool/pull/85
This addresses https://issues.apache.org/jira/browse/POOL-396.
I think the CLA isn't needed under clause 5, but happy to sign it if needed.
Thanks!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 610663)
Remaining Estimate: 0h
Time Spent: 10m
> Exceptions in validation can cause an object's lifecycle to be stuck in
> EVICTION state
> --
>
> Key: POOL-396
> URL: https://issues.apache.org/jira/browse/POOL-396
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.4.2, 2.9.0
>Reporter: Jeremy Kong
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, if validation of an object throws an exception when testing an
> idle object during eviction, an exception will be thrown from the evict()
> method. This causes the object to be left in the EVICTION state, but still be
> present in the idleObjects queue.
> Future runs of the eviction thread will run into an infinite loop, because
> they pick up the afflicted object from the queue, fail to set its state to
> EVICTION, don't count it as a test, and repeat ad infinitum. This infinite
> loop means that no further evictions will take place; it also causes
> increases in garbage collection owing to allocation of the EvictionIterator
> on each loop iteration.
> This test added to TestGenericObjectPool (plus a small change allowing
> exceptions to be thrown from the validateObject method of SimpleFactory)
> reproduces the issue.
> {code:java}
> @Test
> @Timeout(value = 6, unit = TimeUnit.MILLISECONDS)
> public void testExceptionInValidationDuringEviction() throws Exception {
> genericObjectPool.setMaxIdle(1);
> genericObjectPool.setMaxTotal(2);
> genericObjectPool.setNumTestsPerEvictionRun(1);
> genericObjectPool.setMinEvictableIdleTime(Duration.ofMillis(0));
> genericObjectPool.setTestWhileIdle(true);
> String active = genericObjectPool.borrowObject();
> genericObjectPool.returnObject(active);
> simpleFactory.setThrowExceptionOnValidate(true);
> try {
> genericObjectPool.evict();
> } catch (Exception e) {
> // OK that a given run fails. But the object should still be evicted.
> }
> genericObjectPool.evict(); // currently fails: causes an infinite loop!
> assertEquals(0, genericObjectPool.getNumActive());
> assertEquals(0, genericObjectPool.getNumIdle());
> }
> {code}
> It seems that protection against exceptions thrown by validation code exist
> elsewhere (e.g. in borrowObject()); similarly, protections against exceptions
> thrown by user eviction policy code exist in evict(). So it looks like the
> testWhileIdle() portion of evict() needs to similarly be protected.
> Thanks!
> Jeremy
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-pool] jeremyk-91 opened a new pull request #85: POOL-396: Handle validation exceptions during eviction.
jeremyk-91 opened a new pull request #85: URL: https://github.com/apache/commons-pool/pull/85 This addresses https://issues.apache.org/jira/browse/POOL-396. I think the CLA isn't needed under clause 5, but happy to sign it if needed. Thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (RNG-140) nextLong(long lo, long hi)
[
https://issues.apache.org/jira/browse/RNG-140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362947#comment-17362947
]
Gilles Sadowski commented on RNG-140:
-
Could the method be added to the {{UniformRandomProvider}} interface and
implemented in {{BaseProvider}}?
Code (from Commons Math):
{code:java}
public long nextLong(final long lower,
final long upper) {
if (lower >= upper) {
throw new
NumberIsTooLargeException(LocalizedFormats.LOWER_BOUND_NOT_BELOW_UPPER_BOUND,
lower, upper, false);
}
final long max = (upper - lower) + 1;
if (max <= 0) {
// Range is too wide to fit in a positive long (larger than
2^63);
// as it covers more than half the long range, we use directly a
// simple rejection method.
while (true) {
final long r = rng.nextLong();
if (r >= lower && r <= upper) {
return r;
}
}
} else if (max < Integer.MAX_VALUE){
// We can shift the range and generate directly a positive int.
return lower + rng.nextInt((int) max);
} else {
// We can shift the range and generate directly a positive long.
return lower + rng.nextLong(max);
}
}
{code}
> nextLong(long lo, long hi)
> --
>
> Key: RNG-140
> URL: https://issues.apache.org/jira/browse/RNG-140
> Project: Commons RNG
> Issue Type: Wish
> Components: sampling
>Reporter: Gilles Sadowski
>Priority: Minor
> Labels: api
>
> Replacement for functionality defined in
> [{{RandomUtils}}|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/random/RandomUtils.java;h=60060e71d5bbe1d00878a1f54f8bb1ff88b65f11;hb=HEAD#l293].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MATH-1609) "RandomUtils" unit tests are not run
Gilles Sadowski created MATH-1609: - Summary: "RandomUtils" unit tests are not run Key: MATH-1609 URL: https://issues.apache.org/jira/browse/MATH-1609 Project: Commons Math Issue Type: Task Reporter: Gilles Sadowski Fix For: 4.0 Unit tests are defined in an [_abstract_ class|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/test/java/org/apache/commons/math4/legacy/random/RandomUtilsDataGeneratorAbstractTest.java;h=1edb37196568cc803ab564281a43473b6b785213;hb=HEAD] that is not extended by any test class. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MATH-1608) Remove "nextHexString" from "RandomUtils"
[ https://issues.apache.org/jira/browse/MATH-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Sadowski resolved MATH-1608. --- Fix Version/s: (was: 4.0) Resolution: Done > Remove "nextHexString" from "RandomUtils" > - > > Key: MATH-1608 > URL: https://issues.apache.org/jira/browse/MATH-1608 > Project: Commons Math > Issue Type: Task >Reporter: Gilles Sadowski >Priority: Major > Labels: api, remove > > Method > [nextHexString|https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/random/RandomUtils.java;h=60060e71d5bbe1d00878a1f54f8bb1ff88b65f11;hb=HEAD#l211] > * is based on the outdated SHA-1 > * is not used within CM > * is probably superseded by [Codec] utilities (and out-of-scope in CM) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (POOL-396) Exceptions in validation can cause an object's lifecycle to be stuck in EVICTION state
Jeremy Kong created POOL-396:
Summary: Exceptions in validation can cause an object's lifecycle
to be stuck in EVICTION state
Key: POOL-396
URL: https://issues.apache.org/jira/browse/POOL-396
Project: Commons Pool
Issue Type: Bug
Affects Versions: 2.9.0, 2.4.2
Reporter: Jeremy Kong
Currently, if validation of an object throws an exception when testing an idle
object during eviction, an exception will be thrown from the evict() method.
This causes the object to be left in the EVICTION state, but still be present
in the idleObjects queue.
Future runs of the eviction thread will run into an infinite loop, because they
pick up the afflicted object from the queue, fail to set its state to EVICTION,
don't count it as a test, and repeat ad infinitum. This infinite loop means
that no further evictions will take place; it also causes increases in garbage
collection owing to allocation of the EvictionIterator on each loop iteration.
This test added to TestGenericObjectPool (plus a small change allowing
exceptions to be thrown from the validateObject method of SimpleFactory)
reproduces the issue.
{code:java}
@Test
@Timeout(value = 6, unit = TimeUnit.MILLISECONDS)
public void testExceptionInValidationDuringEviction() throws Exception {
genericObjectPool.setMaxIdle(1);
genericObjectPool.setMaxTotal(2);
genericObjectPool.setNumTestsPerEvictionRun(1);
genericObjectPool.setMinEvictableIdleTime(Duration.ofMillis(0));
genericObjectPool.setTestWhileIdle(true);
String active = genericObjectPool.borrowObject();
genericObjectPool.returnObject(active);
simpleFactory.setThrowExceptionOnValidate(true);
try {
genericObjectPool.evict();
} catch (Exception e) {
// OK that a given run fails. But the object should still be evicted.
}
genericObjectPool.evict(); // currently fails: causes an infinite loop!
assertEquals(0, genericObjectPool.getNumActive());
assertEquals(0, genericObjectPool.getNumIdle());
}
{code}
It seems that protection against exceptions thrown by validation code exist
elsewhere (e.g. in borrowObject()); similarly, protections against exceptions
thrown by user eviction policy code exist in evict(). So it looks like the
testWhileIdle() portion of evict() needs to similarly be protected.
Thanks!
Jeremy
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (MATH-1375) BOBYQAOptimizer Seems to Sometimes Enter Endless Loop
[
https://issues.apache.org/jira/browse/MATH-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles Sadowski updated MATH-1375:
--
Fix Version/s: (was: 4.0)
4.X
> BOBYQAOptimizer Seems to Sometimes Enter Endless Loop
> -
>
> Key: MATH-1375
> URL: https://issues.apache.org/jira/browse/MATH-1375
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: Java 8 JDK, OpenJDK, Ubuntu
>Reporter: Thomas Weise
>Priority: Minor
> Fix For: 4.X
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> I am using BOBYQAOptimizer to solve some numerical problems related to
> nonlinear function fitting. BOBYQAOptimizer is provided with close-to-optimal
> solutions which it is supposed to refine. In some cases, BOBYQAOptimizer
> seems to enter an endless loop, or at least an extremely long loop. The
> problem is almost impossible to reproduce as it occurs maybe once every 1000
> runs.
> From what I can see with the debugger, the source of the problem is probably
> method trsbox which is called by bobyqb. In trsbox, some values of a vector
> (sorry, forgot which one) grow extremely large (>=1e250). Either way, I
> noticed that both mentioned methods feature a for(;; ) loop.
> Now that algorithm looks quite mathematical to me and seemingly has been
> translated from FORTRAN or something. I think fixing and finding mathematical
> issues might be complicated (see also the caveats reported in the release
> notes) and overall, the algorithm is working.
> How about you also count the iterations of the for(;; ) loops in bobyqb and
> trsbox and throw an exception if they exceed some limit? In the easiest case,
> instead of for(;; ) you can do something like
> {code}
> for(int maxRemainingSteps=100; (--maxRemainingSteps)>=0;) {
> ...
> }
>throw new MaxCountExceededException(100);
> // or TooManyEvaluationsException(100);
> // or MathIllegalStateException(LocalizedFormats.SIMPLE_MESSAGE, "Huh?");
> {code}
> Since the original for loops are always left via "return", that would already
> do the trick. Or you could use an Incrementor object for this purpose. Either
> way, I think with the very simple fix above, you would prevent endless loops,
> add only a tiny bit of very easy-to-understand code, and would not break the
> algorithm contract, since such exceptions could be thrown sometimes even
> without the fix.
> In summary: BOBYQAOptimizer needs some work. Fixing the issue I observed
> properly (i.e., by fixing the special cases causing it) is probably very
> complex and is probably not feasible. Preventing it, however, seems to be
> rather easy, as I have shown above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MATH-1375) BOBYQAOptimizer Seems to Sometimes Enter Endless Loop
[
https://issues.apache.org/jira/browse/MATH-1375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362926#comment-17362926
]
Gilles Sadowski commented on MATH-1375:
---
bq. And such a loop must be impossible in any productive environment.
I agree.
The implementation is buggy and should not have made it into CM (due to its
coding style).
bq. limit the iteration numbers of these loops [...]
Patch welcome.
> BOBYQAOptimizer Seems to Sometimes Enter Endless Loop
> -
>
> Key: MATH-1375
> URL: https://issues.apache.org/jira/browse/MATH-1375
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
> Environment: Java 8 JDK, OpenJDK, Ubuntu
>Reporter: Thomas Weise
>Priority: Minor
> Fix For: 4.0
>
> Original Estimate: 4h
> Remaining Estimate: 4h
>
> I am using BOBYQAOptimizer to solve some numerical problems related to
> nonlinear function fitting. BOBYQAOptimizer is provided with close-to-optimal
> solutions which it is supposed to refine. In some cases, BOBYQAOptimizer
> seems to enter an endless loop, or at least an extremely long loop. The
> problem is almost impossible to reproduce as it occurs maybe once every 1000
> runs.
> From what I can see with the debugger, the source of the problem is probably
> method trsbox which is called by bobyqb. In trsbox, some values of a vector
> (sorry, forgot which one) grow extremely large (>=1e250). Either way, I
> noticed that both mentioned methods feature a for(;; ) loop.
> Now that algorithm looks quite mathematical to me and seemingly has been
> translated from FORTRAN or something. I think fixing and finding mathematical
> issues might be complicated (see also the caveats reported in the release
> notes) and overall, the algorithm is working.
> How about you also count the iterations of the for(;; ) loops in bobyqb and
> trsbox and throw an exception if they exceed some limit? In the easiest case,
> instead of for(;; ) you can do something like
> {code}
> for(int maxRemainingSteps=100; (--maxRemainingSteps)>=0;) {
> ...
> }
>throw new MaxCountExceededException(100);
> // or TooManyEvaluationsException(100);
> // or MathIllegalStateException(LocalizedFormats.SIMPLE_MESSAGE, "Huh?");
> {code}
> Since the original for loops are always left via "return", that would already
> do the trick. Or you could use an Incrementor object for this purpose. Either
> way, I think with the very simple fix above, you would prevent endless loops,
> add only a tiny bit of very easy-to-understand code, and would not break the
> algorithm contract, since such exceptions could be thrown sometimes even
> without the fix.
> In summary: BOBYQAOptimizer needs some work. Fixing the issue I observed
> properly (i.e., by fixing the special cases causing it) is probably very
> complex and is probably not feasible. Preventing it, however, seems to be
> rather easy, as I have shown above.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (VFS-806) org.apache.commons.vfs2.FileContent.getLastModifiedTime() is losing milliseconds (always ends in 000)
[ https://issues.apache.org/jira/browse/VFS-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362920#comment-17362920 ] Gary Kuntsevich commented on VFS-806: - Tried version 2.8.0 - got the same result: lastmodifiedtime = 2021/06/14 08:13:01.*000* > org.apache.commons.vfs2.FileContent.getLastModifiedTime() is losing > milliseconds (always ends in 000) > - > > Key: VFS-806 > URL: https://issues.apache.org/jira/browse/VFS-806 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.7.0 > Environment: Linux: Ubuntu 16.04.5 LTS >Reporter: Gary Kuntsevich >Priority: Major > > org.apache.commons.vfs2.FileContent.getLastModifiedTime() is losing > milliseconds (always ends in 000) when running on Linux: Ubuntu 16.04.5 LTS -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (MATH-1315) MultiKMeansPlusPlusClusterer buggy for alternative evaluators
[ https://issues.apache.org/jira/browse/MATH-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles Sadowski resolved MATH-1315. --- Fix Version/s: (was: 4.0) Resolution: Cannot Reproduce Code has changed, rendering the patch unnecessary (hopefully). > MultiKMeansPlusPlusClusterer buggy for alternative evaluators > - > > Key: MATH-1315 > URL: https://issues.apache.org/jira/browse/MATH-1315 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Thorsten Schäfer >Priority: Major > Attachments: MATH-1315.patch > > > I just looked into the source code for the MultiKMeansPlusPlusClusterer and > realized that it would return null in case of an alternative evaluator that > favors bigger values instead of smaller ones: > The basic idea of the clustering method is that we perform n clusterings and > choose the best result. The decision what's the best result is performed by > the evaluator, which by default assumes smaller values are better. > According to the documentation, we can also provide a different evaluator, > which for instance would decide that bigger values are better, but given we > initialize the best value with Double.POSITIVE_INFINITY in method > MultiKMeansPlusPlusClusterer.cluster(Collection), we would never find a > "better" result and thus always return null. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (COMPRESS-514) SevenZFile fails with encoded header over 2GiB
[
https://issues.apache.org/jira/browse/COMPRESS-514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362915#comment-17362915
]
A Kelday commented on COMPRESS-514:
---
Hi,
I see there's a new github comment about rebasing the current (very old) PR.
I'll hopefully have some time to look at this again soon, but I no longer have
the "test case" 7zip to work with. It contained 3rd party data which cannot be
retained or shared, plus it was over 1TB.
I'll attempt to create a smaller test case 7zip which reproduces the original
problem, but it could take some time since it probably requires at least 20
million central directory paths.
> SevenZFile fails with encoded header over 2GiB
> --
>
> Key: COMPRESS-514
> URL: https://issues.apache.org/jira/browse/COMPRESS-514
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: A Kelday
>Priority: Minor
> Attachments: HeaderChannelBuffer.java
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> When reading what some may call a large encrypted 7zip file (1.2TB with 22
> million files), the read fails at the header stage with the trace below. Is
> this within the spec? I've written some code to handle it, because I did
> actually need to extract the file in java. If that's of any use I can provide
> it (it's a naive wrapper that just pages in a buffer at a time).
>
> {code:java}
> Exception in thread "main" java.io.IOException: Cannot handle
> unpackSize241696
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.assertFitsIntoInt(SevenZFile.java:1523)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.readEncodedHeader(SevenZFile.java:622)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.initializeArchive(SevenZFile.java:532)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.readHeaders(SevenZFile.java:468)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:337)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:129)
> at
> org.apache.commons.compress.archivers.sevenz.SevenZFile.(SevenZFile.java:116)
> {code}
> 7zip itself can also open it (and display/extract etc.), here are the stats:
>
>
> {code:java}
> Size: 2 489 903 580 875
> Packed Size: 1 349 110 308 832
> Folders: 40 005
> Files: 22 073 957
> CRC: E26F6A96
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362908#comment-17362908
]
Alex Herbert commented on NUMBERS-163:
--
{quote}There is (surprisingly perhaps) no performance loss (on the contrary,
for the simple cases).
{quote}
Thanks for testing. I have no other issues with the builder type API and that
is more flexible. Maintaining the static methods when performance is no
different is not necessary.
{quote}As far as making LinearCombination itself implement DoubleSupplier, I do
not see the utility.
{quote}
You can have different implementations of LinearCombination. dot2s is a 2-fold
precision algorithm. The generic extension is the dotK family for k-fold
precision. There is also the unlimited precision method (within the bounds of
the range of a double).
But this would also work for the accumulator class you are describing. The
accumulator can have sub-class implementations.
The algorithm should be specified in the constructor:
{code:java}
double x1 = LinearCombination.of(LinearCombination.DOT_2S)
.add(1e300, 1)
.add(1e100, 1)
.add(1, 1)
.add(-1e300, 1)
.add(-1e100, 1)
.getAsDouble();
assert x1 == 1;
{code}
I think this fails for the dot2s algorithm. But it would work for DOT_3
algorithm.
This would allow code to switch the accuracy by just putting in a different
enum specified algorithm.
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362906#comment-17362906
]
Gilles Sadowski commented on NUMBERS-163:
-
{quote}[here|https://github.com/apache/commons-geometry/blob/master/commons-geometry-spherical/src/main/java/org/apache/commons/geometry/spherical/twod/RegionBSPTree2S.java#L173]
[...] replace [...] {{Vector3D}} accumulator [...] with extended precision
[...]
{quote}
As this is (conceptually) a ({{Vector3D}}) addition (to be carried by 3
{{Summation}} instances), we should perhaps encapsulate the (extended
precision) "implementation details" in a {{SumVector3D}} class (name TBD):
{code:java}
public class SumVector3D {
private Summation x = Summation.zero();
private Summation y = Summation.zero();
private Summation z = Summation.zero();
public SumVector3D() {}
public void add(Vector3D v) {
x = Summation.add(v.getX());
// ...
}
public Vector3D get() {
return Vector3D.of(x.getAsDouble(), y.getAsDouble(), z.getAsDouble());
}
}
{code}
(Unrelated) nit: Variable
[{{centroidVector}}|https://github.com/apache/commons-geometry/blob/master/commons-geometry-spherical/src/main/java/org/apache/commons/geometry/spherical/twod/RegionBSPTree2S.java#L175]
should be declared inside the loop and "final".
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TEXT-207) Include DoubleFormats utility from commons-geometry
[
https://issues.apache.org/jira/browse/TEXT-207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362903#comment-17362903
]
Matt Juntunen commented on TEXT-207:
Thanks, [~kinow]! I'll be working on this here:
https://github.com/darkma773r/commons-text/tree/double-formats
> Include DoubleFormats utility from commons-geometry
> ---
>
> Key: TEXT-207
> URL: https://issues.apache.org/jira/browse/TEXT-207
> Project: Commons Text
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
>
> commons-geometry currently contains a
> [DoubleFormats|https://github.com/apache/commons-geometry/blob/master/commons-geometry-io-core/src/main/java/org/apache/commons/geometry/io/core/utils/DoubleFormats.java]
> utility class in the {{commons-geometry-io-core}} module that produces
> standardized string representations of doubles for use in text-based data
> formats. It has the following features:
> - It is completely thread-safe.
> - It produces string in scientific, engineering, plain, or mixed (plain or
> scientific depending on value) formats.
> - Performance is comparable to {{DecimalFormat}} and {{BigDecimal}}.
> As mentioned on the dev mailing list, I believe that this class has broader
> applicability than just geometric data formats and would be a good fit for
> commons-text.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-77) Move utilities from "Commons Geometry"
[
https://issues.apache.org/jira/browse/NUMBERS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362902#comment-17362902
]
Matt Juntunen commented on NUMBERS-77:
--
Created TEXT-207 for moving {{DoubleFormats}} to commons-text.
> Move utilities from "Commons Geometry"
> --
>
> Key: NUMBERS-77
> URL: https://issues.apache.org/jira/browse/NUMBERS-77
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Gilles Sadowski
>Priority: Major
> Fix For: 1.1
>
> Attachments: NUMBERS-77.diff
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> "Commons Geometry" defines utilities that would be a better fit in this
> component.
> Duplication of general-purpose codes should be avoided, in order to benefit
> from consolidated usage (bug reporting, performance enhancements, ...).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362900#comment-17362900
]
Matt Juntunen commented on NUMBERS-163:
---
I've made a PR with the changes I was picturing here:
[https://github.com/apache/commons-numbers/pull/95]. Please let me know what
you think.
bq. Isn't there a possible loss (depending on the order of accumulation)?
Yes, but the static methods have the exact same issue. The dot2s add sum2s
algorithms that we are using are designed to reduce this loss as much as
possible. The accumulator classes simply unroll the algorithms and give the
caller control over when and how the inputs are added.
As far as making {{LinearCombination}} itself implement {{DoubleSupplier}}, I
do not see the utility. What would one do with an instance of
{{LinearCombination}} besides get the {{double}} value from it? In that case,
why even have an instance at all?
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Work logged] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?focusedWorklogId=610630=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610630
]
ASF GitHub Bot logged work on NUMBERS-163:
--
Author: ASF GitHub Bot
Created on: 14/Jun/21 11:08
Start Date: 14/Jun/21 11:08
Worklog Time Spent: 10m
Work Description: coveralls commented on pull request #95:
URL: https://github.com/apache/commons-numbers/pull/95#issuecomment-860599924
[](https://coveralls.io/builds/40556505)
Coverage increased (+0.002%) to 99.665% when pulling
**0d6bb9f0689e2c8a326c2a25244e7ff0f27f283a on darkma773r:numbers-163** into
**19899e7124dcd182fb3ebe31f17405c15be6cd19 on apache:master**.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 610630)
Time Spent: 20m (was: 10m)
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-numbers] coveralls commented on pull request #95: NUMBERS-163: Accumulator classes
coveralls commented on pull request #95: URL: https://github.com/apache/commons-numbers/pull/95#issuecomment-860599924 [](https://coveralls.io/builds/40556505) Coverage increased (+0.002%) to 99.665% when pulling **0d6bb9f0689e2c8a326c2a25244e7ff0f27f283a on darkma773r:numbers-163** into **19899e7124dcd182fb3ebe31f17405c15be6cd19 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?focusedWorklogId=610629=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610629
]
ASF GitHub Bot logged work on NUMBERS-163:
--
Author: ASF GitHub Bot
Created on: 14/Jun/21 11:02
Start Date: 14/Jun/21 11:02
Worklog Time Spent: 10m
Work Description: darkma773r opened a new pull request #95:
URL: https://github.com/apache/commons-numbers/pull/95
Adding Summation.Accumulator and LinearCombination.Accumulator.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 610629)
Remaining Estimate: 0h
Time Spent: 10m
> Summation and LinearCombination Accumulators
>
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
>.add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-numbers] darkma773r opened a new pull request #95: NUMBERS-163: Accumulator classes
darkma773r opened a new pull request #95: URL: https://github.com/apache/commons-numbers/pull/95 Adding Summation.Accumulator and LinearCombination.Accumulator. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (JEXL-352) Possible memory leak regarding parser jjtree nodes in jexl 3.2
[
https://issues.apache.org/jira/browse/JEXL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Øyvind Horneland updated JEXL-352:
--
Summary: Possible memory leak regarding parser jjtree nodes in jexl 3.2
(was: Possible memory leak regarind parser jjtree nodes in jexl 3.2)
> Possible memory leak regarding parser jjtree nodes in jexl 3.2
> --
>
> Key: JEXL-352
> URL: https://issues.apache.org/jira/browse/JEXL-352
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: * JEXL 3.2
> * Java 11
> * Jetty 9.4.41.v20210516
>
>Reporter: Øyvind Horneland
>Priority: Major
> Attachments: jexl-engine-hprof.png
>
>
> Our application encountered a memory leak issue after upgrading from JEXL 3.1
> to 3.2.
> It seems that every call to JexlEngine createExpression now adds new entries
> to engine.parser.jjtree.nodes. In our case we suddenly had millions of nodes
> in this list.
> This sample seems to reproduce the issue
> {code:java}
> JexlEngine jexlEngine = new JexlBuilder().create();
> String testExpression = "dummy";
> jexlEngine.createExpression(testExpression); //
> jexlEngine.parser.jjtree.nodes.size() == 1
> jexlEngine.createExpression(testExpression); //
> jexlEngine.parser.jjtree.nodes.size() == 2
> {code}
> We currently don't cache the returned expression and JexlEngine is configured
> with defaults as shown in the sample.
> Note that calling jexlEngine.clearCache() does not free the nodes.
> Attached screenshot for the hprof of our application with ~ 1.7 million nodes
> in jjtree.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JEXL-352) Possible memory leak regarding parser jjtree nodes in JEXL 3.2
[
https://issues.apache.org/jira/browse/JEXL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Øyvind Horneland updated JEXL-352:
--
Summary: Possible memory leak regarding parser jjtree nodes in JEXL 3.2
(was: Possible memory leak regarding parser jjtree nodes in jexl 3.2)
> Possible memory leak regarding parser jjtree nodes in JEXL 3.2
> --
>
> Key: JEXL-352
> URL: https://issues.apache.org/jira/browse/JEXL-352
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: * JEXL 3.2
> * Java 11
> * Jetty 9.4.41.v20210516
>
>Reporter: Øyvind Horneland
>Priority: Major
> Attachments: jexl-engine-hprof.png
>
>
> Our application encountered a memory leak issue after upgrading from JEXL 3.1
> to 3.2.
> It seems that every call to JexlEngine createExpression now adds new entries
> to engine.parser.jjtree.nodes. In our case we suddenly had millions of nodes
> in this list.
> This sample seems to reproduce the issue
> {code:java}
> JexlEngine jexlEngine = new JexlBuilder().create();
> String testExpression = "dummy";
> jexlEngine.createExpression(testExpression); //
> jexlEngine.parser.jjtree.nodes.size() == 1
> jexlEngine.createExpression(testExpression); //
> jexlEngine.parser.jjtree.nodes.size() == 2
> {code}
> We currently don't cache the returned expression and JexlEngine is configured
> with defaults as shown in the sample.
> Note that calling jexlEngine.clearCache() does not free the nodes.
> Attached screenshot for the hprof of our application with ~ 1.7 million nodes
> in jjtree.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (JEXL-352) Possible memory leak regarind parser jjtree nodes in jexl 3.2
[
https://issues.apache.org/jira/browse/JEXL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Øyvind Horneland updated JEXL-352:
--
Environment:
* JEXL 3.2
* Java 11
* Jetty 9.4.41.v20210516
was:
JEXL 3.2
Java 11
Jetty 9.4.41.v20210516
> Possible memory leak regarind parser jjtree nodes in jexl 3.2
> -
>
> Key: JEXL-352
> URL: https://issues.apache.org/jira/browse/JEXL-352
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.2
> Environment: * JEXL 3.2
> * Java 11
> * Jetty 9.4.41.v20210516
>
>Reporter: Øyvind Horneland
>Priority: Major
> Attachments: jexl-engine-hprof.png
>
>
> Our application encountered a memory leak issue after upgrading from JEXL 3.1
> to 3.2.
> It seems that every call to JexlEngine createExpression now adds new entries
> to engine.parser.jjtree.nodes. In our case we suddenly had millions of nodes
> in this list.
> This sample seems to reproduce the issue
> {code:java}
> JexlEngine jexlEngine = new JexlBuilder().create();
> String testExpression = "dummy";
> jexlEngine.createExpression(testExpression); //
> jexlEngine.parser.jjtree.nodes.size() == 1
> jexlEngine.createExpression(testExpression); //
> jexlEngine.parser.jjtree.nodes.size() == 2
> {code}
> We currently don't cache the returned expression and JexlEngine is configured
> with defaults as shown in the sample.
> Note that calling jexlEngine.clearCache() does not free the nodes.
> Attached screenshot for the hprof of our application with ~ 1.7 million nodes
> in jjtree.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (JEXL-352) Possible memory leak regarind parser jjtree nodes in jexl 3.2
Øyvind Horneland created JEXL-352:
-
Summary: Possible memory leak regarind parser jjtree nodes in jexl
3.2
Key: JEXL-352
URL: https://issues.apache.org/jira/browse/JEXL-352
Project: Commons JEXL
Issue Type: Bug
Affects Versions: 3.2
Environment: JEXL 3.2
Java 11
Jetty 9.4.41.v20210516
Reporter: Øyvind Horneland
Attachments: jexl-engine-hprof.png
Our application encountered a memory leak issue after upgrading from JEXL 3.1
to 3.2.
It seems that every call to JexlEngine createExpression now adds new entries to
engine.parser.jjtree.nodes. In our case we suddenly had millions of nodes in
this list.
This sample seems to reproduce the issue
{code:java}
JexlEngine jexlEngine = new JexlBuilder().create();
String testExpression = "dummy";
jexlEngine.createExpression(testExpression); //
jexlEngine.parser.jjtree.nodes.size() == 1
jexlEngine.createExpression(testExpression); //
jexlEngine.parser.jjtree.nodes.size() == 2
{code}
We currently don't cache the returned expression and JexlEngine is configured
with defaults as shown in the sample.
Note that calling jexlEngine.clearCache() does not free the nodes.
Attached screenshot for the hprof of our application with ~ 1.7 million nodes
in jjtree.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-compress] garydgregory commented on pull request #160: Bump org.apache.felix.framework from 6.0.3 to 7.0.0
garydgregory commented on pull request #160: URL: https://github.com/apache/commons-compress/pull/160#issuecomment-859983980 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] dependabot[bot] opened a new pull request #204: Bump mockito-core from 3.8.0 to 3.11.1
dependabot[bot] opened a new pull request #204: URL: https://github.com/apache/commons-compress/pull/204 Bumps [mockito-core](https://github.com/mockito/mockito) from 3.8.0 to 3.11.1. Release notes Sourced from https://github.com/mockito/mockito/releases;>mockito-core's releases. v3.11.1 Changelog generated by https://github.com/shipkit/shipkit-changelog;>Shipkit Changelog Gradle Plugin 3.11.1 2021-06-11 - https://github.com/mockito/mockito/compare/v3.11.0...v3.11.1;>3 commit(s) by Charles Munger, dependabot[bot] Bump versions.bytebuddy from 1.11.1 to 1.11.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2322;>#2322)](https://github-redirect.dependabot.com/mockito/mockito/pull/2322;>mockito/mockito#2322) Check package-privacy of method params [(https://github-redirect.dependabot.com/mockito/mockito/issues/2318;>#2318)](https://github-redirect.dependabot.com/mockito/mockito/pull/2318;>mockito/mockito#2318) Bump shipkit-auto-version from 1.1.16 to 1.1.17 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2317;>#2317)](https://github-redirect.dependabot.com/mockito/mockito/pull/2317;>mockito/mockito#2317) v3.11.0 Changelog generated by https://github.com/shipkit/shipkit-changelog;>Shipkit Changelog Gradle Plugin 3.11.0 2021-06-03 - https://github.com/mockito/mockito/compare/v3.10.0...v3.11.0;>18 commit(s) by Charles Munger, Szczepan Faber, dependabot[bot] Bump versions.bytebuddy from 1.11.0 to 1.11.1 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2313;>#2313)](https://github-redirect.dependabot.com/mockito/mockito/pull/2313;>mockito/mockito#2313) Undo parent for MultipleParentsClassLoader [(https://github-redirect.dependabot.com/mockito/mockito/issues/2312;>#2312)](https://github-redirect.dependabot.com/mockito/mockito/pull/2312;>mockito/mockito#2312) Bump shipkit-auto-version from 1.1.14 to 1.1.16 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2310;>#2310)](https://github-redirect.dependabot.com/mockito/mockito/pull/2310;>mockito/mockito#2310) Bump gradle/wrapper-validation-action from 1.0.3 to 1.0.4 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2309;>#2309)](https://github-redirect.dependabot.com/mockito/mockito/pull/2309;>mockito/mockito#2309) Bump com.github.ben-manes.versions from 0.38.0 to 0.39.0 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2308;>#2308)](https://github-redirect.dependabot.com/mockito/mockito/pull/2308;>mockito/mockito#2308) Bump shipkit-auto-version from 1.1.11 to 1.1.14 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2307;>#2307)](https://github-redirect.dependabot.com/mockito/mockito/pull/2307;>mockito/mockito#2307) Use the parent classloader if the context classloader is a child of it. [(https://github-redirect.dependabot.com/mockito/mockito/issues/2306;>#2306)](https://github-redirect.dependabot.com/mockito/mockito/pull/2306;>mockito/mockito#2306) Bump kotlin-stdlib from 1.5.0 to 1.5.10 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2305;>#2305)](https://github-redirect.dependabot.com/mockito/mockito/pull/2305;>mockito/mockito#2305) The type is not public and its mock class is loaded by a different class loader with a context classloader that delegates [(https://github-redirect.dependabot.com/mockito/mockito/issues/2303;>#2303)](https://github-redirect.dependabot.com/mockito/mockito/issues/2303;>mockito/mockito#2303) Enabled automated changelog [(https://github-redirect.dependabot.com/mockito/mockito/issues/2301;>#2301)](https://github-redirect.dependabot.com/mockito/mockito/pull/2301;>mockito/mockito#2301) Bump kotlinx-coroutines-core from 1.4.3-native-mt to 1.5.0-native-mt [(https://github-redirect.dependabot.com/mockito/mockito/issues/2299;>#2299)](https://github-redirect.dependabot.com/mockito/mockito/pull/2299;>mockito/mockito#2299) Bump versions.errorprone from 2.6.0 to 2.7.1 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2298;>#2298)](https://github-redirect.dependabot.com/mockito/mockito/pull/2298;>mockito/mockito#2298) Bump junit-platform-launcher from 1.7.1 to 1.7.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2297;>#2297)](https://github-redirect.dependabot.com/mockito/mockito/pull/2297;>mockito/mockito#2297) Bump versions.junitJupiter from 5.7.1 to 5.7.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2296;>#2296)](https://github-redirect.dependabot.com/mockito/mockito/pull/2296;>mockito/mockito#2296) Renamed main dev branch [(https://github-redirect.dependabot.com/mockito/mockito/issues/2295;>#2295)](https://github-redirect.dependabot.com/mockito/mockito/pull/2295;>mockito/mockito#2295) Bump gradle/wrapper-validation-action from 1 to 1.0.3
[GitHub] [commons-geometry] darkma773r opened a new pull request #173: using commons-numbers Norm enum
darkma773r opened a new pull request #173: URL: https://github.com/apache/commons-geometry/pull/173 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] coveralls edited a comment on pull request #160: Bump org.apache.felix.framework from 6.0.3 to 7.0.0
coveralls edited a comment on pull request #160: URL: https://github.com/apache/commons-compress/pull/160#issuecomment-751601803 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-dbcp] dependabot[bot] opened a new pull request #114: Bump mockito-core from 3.11.0 to 3.11.1
dependabot[bot] opened a new pull request #114: URL: https://github.com/apache/commons-dbcp/pull/114 Bumps [mockito-core](https://github.com/mockito/mockito) from 3.11.0 to 3.11.1. Release notes Sourced from https://github.com/mockito/mockito/releases;>mockito-core's releases. v3.11.1 Changelog generated by https://github.com/shipkit/shipkit-changelog;>Shipkit Changelog Gradle Plugin 3.11.1 2021-06-11 - https://github.com/mockito/mockito/compare/v3.11.0...v3.11.1;>3 commit(s) by Charles Munger, dependabot[bot] Bump versions.bytebuddy from 1.11.1 to 1.11.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2322;>#2322)](https://github-redirect.dependabot.com/mockito/mockito/pull/2322;>mockito/mockito#2322) Check package-privacy of method params [(https://github-redirect.dependabot.com/mockito/mockito/issues/2318;>#2318)](https://github-redirect.dependabot.com/mockito/mockito/pull/2318;>mockito/mockito#2318) Bump shipkit-auto-version from 1.1.16 to 1.1.17 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2317;>#2317)](https://github-redirect.dependabot.com/mockito/mockito/pull/2317;>mockito/mockito#2317) Commits https://github.com/mockito/mockito/commit/ef34307383da5a27fff23f7310787d262fbb4cfd;>ef34307 Bump versions.bytebuddy from 1.11.1 to 1.11.2 (https://github-redirect.dependabot.com/mockito/mockito/issues/2322;>#2322) https://github.com/mockito/mockito/commit/41e445c1f7029a8635283428f1f02846ba95f241;>41e445c Check for non-public type references in methods (https://github-redirect.dependabot.com/mockito/mockito/issues/2318;>#2318) https://github.com/mockito/mockito/commit/07951e90c82d194f65821ff809247ea819264ea2;>07951e9 Bump shipkit-auto-version from 1.1.16 to 1.1.17 (https://github-redirect.dependabot.com/mockito/mockito/issues/2317;>#2317) See full diff in https://github.com/mockito/mockito/compare/v3.11.0...v3.11.1;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] coveralls commented on pull request #206: Minor change:
coveralls commented on pull request #206: URL: https://github.com/apache/commons-compress/pull/206#issuecomment-860017962 [](https://coveralls.io/builds/40531976) Coverage increased (+0.02%) to 86.833% when pulling **a62fbbe1da36b5ca9c70c701c52a347663ed86aa on arturobernalg:feature/minor_changes** into **c8e445990231114a15fbba688a0f487b7320fff2 on apache:master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-fileupload] coveralls commented on pull request #101: Bump commons-io from 2.9.0 to 2.10.0
coveralls commented on pull request #101: URL: https://github.com/apache/commons-fileupload/pull/101#issuecomment-860402813 [](https://coveralls.io/builds/40548322) Coverage remained the same at 78.117% when pulling **6ffad8c92d793fed7340c0809e6560164ebfd6dc on dependabot/maven/commons-io-commons-io-2.10.0** into **31067dd3da7011222698d56e7804b24099bafc75 on master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-text] kinow closed pull request #235: Bump checkstyle from 8.42 to 8.43
kinow closed pull request #235: URL: https://github.com/apache/commons-text/pull/235 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-csv] coveralls commented on pull request #155: Bump mockito-core from 3.7.7 to 3.11.1
coveralls commented on pull request #155: URL: https://github.com/apache/commons-csv/pull/155#issuecomment-860404300 [](https://coveralls.io/builds/40548396) Coverage remained the same at 98.463% when pulling **837e6a6010af28f8c5af9717001bc7926cfed52c on dependabot/maven/org.mockito-mockito-core-3.11.1** into **00fcb06bb5be4709a7c07fc834c2a1d1eb84e17e on master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-compress] coveralls commented on pull request #204: Bump mockito-core from 3.8.0 to 3.11.1
coveralls commented on pull request #204: URL: https://github.com/apache/commons-compress/pull/204#issuecomment-859976577 [](https://coveralls.io/builds/40529819) Coverage decreased (-0.02%) to 86.812% when pulling **600bf216ade168d58c297b8b43d378c063814dbf on dependabot/maven/org.mockito-mockito-core-3.11.1** into **83273103546d7e992cf3af243cf2baa038f8c7ed on master**. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-io] dependabot[bot] opened a new pull request #246: Bump mockito-inline from 3.11.0 to 3.11.1
dependabot[bot] opened a new pull request #246: URL: https://github.com/apache/commons-io/pull/246 Bumps [mockito-inline](https://github.com/mockito/mockito) from 3.11.0 to 3.11.1. Release notes Sourced from https://github.com/mockito/mockito/releases;>mockito-inline's releases. v3.11.1 Changelog generated by https://github.com/shipkit/shipkit-changelog;>Shipkit Changelog Gradle Plugin 3.11.1 2021-06-11 - https://github.com/mockito/mockito/compare/v3.11.0...v3.11.1;>3 commit(s) by Charles Munger, dependabot[bot] Bump versions.bytebuddy from 1.11.1 to 1.11.2 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2322;>#2322)](https://github-redirect.dependabot.com/mockito/mockito/pull/2322;>mockito/mockito#2322) Check package-privacy of method params [(https://github-redirect.dependabot.com/mockito/mockito/issues/2318;>#2318)](https://github-redirect.dependabot.com/mockito/mockito/pull/2318;>mockito/mockito#2318) Bump shipkit-auto-version from 1.1.16 to 1.1.17 [(https://github-redirect.dependabot.com/mockito/mockito/issues/2317;>#2317)](https://github-redirect.dependabot.com/mockito/mockito/pull/2317;>mockito/mockito#2317) Commits https://github.com/mockito/mockito/commit/ef34307383da5a27fff23f7310787d262fbb4cfd;>ef34307 Bump versions.bytebuddy from 1.11.1 to 1.11.2 (https://github-redirect.dependabot.com/mockito/mockito/issues/2322;>#2322) https://github.com/mockito/mockito/commit/41e445c1f7029a8635283428f1f02846ba95f241;>41e445c Check for non-public type references in methods (https://github-redirect.dependabot.com/mockito/mockito/issues/2318;>#2318) https://github.com/mockito/mockito/commit/07951e90c82d194f65821ff809247ea819264ea2;>07951e9 Bump shipkit-auto-version from 1.1.16 to 1.1.17 (https://github-redirect.dependabot.com/mockito/mockito/issues/2317;>#2317) See full diff in https://github.com/mockito/mockito/compare/v3.11.0...v3.11.1;>compare view [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-dbcp] arturobernalg opened a new pull request #113: Simplify Assertions
arturobernalg opened a new pull request #113: URL: https://github.com/apache/commons-dbcp/pull/113 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-email] dependabot[bot] commented on pull request #47: Bump commons-io from 2.8.0 to 2.9.0
dependabot[bot] commented on pull request #47: URL: https://github.com/apache/commons-email/pull/47#issuecomment-860401829 Superseded by #49. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-dbutils] dependabot[bot] commented on pull request #73: Bump mockito-core from 3.7.0 to 3.11.0
dependabot[bot] commented on pull request #73: URL: https://github.com/apache/commons-dbutils/pull/73#issuecomment-860401506 Superseded by #74. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-vfs] arturobernalg opened a new pull request #187: Simplify conditions and avoid extra checks
arturobernalg opened a new pull request #187: URL: https://github.com/apache/commons-vfs/pull/187 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-geometry] asfgit merged pull request #172: improvements to DoubleFormats performance
asfgit merged pull request #172: URL: https://github.com/apache/commons-geometry/pull/172 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (IO-711) Use Objects.requireNotNull for fail fast method/constructors
[ https://issues.apache.org/jira/browse/IO-711?focusedWorklogId=610546=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-610546 ] ASF GitHub Bot logged work on IO-711: - Author: ASF GitHub Bot Created on: 14/Jun/21 08:04 Start Date: 14/Jun/21 08:04 Worklog Time Spent: 10m Work Description: boris-unckel closed pull request #196: URL: https://github.com/apache/commons-io/pull/196 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 610546) Time Spent: 1.5h (was: 1h 20m) > Use Objects.requireNotNull for fail fast method/constructors > > > Key: IO-711 > URL: https://issues.apache.org/jira/browse/IO-711 > Project: Commons IO > Issue Type: Improvement > Components: Filters, Streams/Writers, Utilities >Affects Versions: 2.8.0 >Reporter: Boris Unckel >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > Currently some NullPointer checks are IllegalArgumentException, at other > points a lot of constructor and/or method logic happens before a null pointer > occurs. > The approach is to make these places use > Objects.requireNonNull(sampleObject,"sampleObject"); > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-text] kinow closed pull request #236: Bump mockito-inline from 3.10.0 to 3.11.0
kinow closed pull request #236: URL: https://github.com/apache/commons-text/pull/236 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
