[GitHub] [commons-geometry] darkma773r commented on pull request #194: GEOMETRY-142: PointMap and PointSet
darkma773r commented on pull request #194: URL: https://github.com/apache/commons-geometry/pull/194#issuecomment-1068662469 Addressed comments and made changes based on recommendations on the dev mailing list. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-geometry] darkma773r commented on a change in pull request #194: GEOMETRY-142: PointMap and PointSet
darkma773r commented on a change in pull request #194:
URL: https://github.com/apache/commons-geometry/pull/194#discussion_r827563187
##
File path:
commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/PointMap3DImpl.java
##
@@ -0,0 +1,174 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.geometry.euclidean;
+
+import java.util.List;
+
+import org.apache.commons.geometry.core.collection.PointMap;
+import org.apache.commons.geometry.core.internal.AbstractBucketPointMap;
+import org.apache.commons.geometry.euclidean.threed.Vector3D;
+import org.apache.commons.numbers.core.Precision;
+
+/** Internal {@link PointMap3D} implementation.
+ * @param Map value type
+ */
+final class PointMap3DImpl
+extends AbstractBucketPointMap
+implements PointMap {
+
+/** Number of children per node. */
+private static final int NODE_CHILD_COUNT = 8;
+
+/** Max entries per node. This value was determined empirically was chosen
to
Review comment:
Fixed.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-geometry] darkma773r commented on a change in pull request #194: GEOMETRY-142: PointMap and PointSet
darkma773r commented on a change in pull request #194:
URL: https://github.com/apache/commons-geometry/pull/194#discussion_r827563111
##
File path:
commons-geometry-euclidean/src/main/java/org/apache/commons/geometry/euclidean/PointMap3DImpl.java
##
@@ -0,0 +1,174 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.geometry.euclidean;
+
+import java.util.List;
+
+import org.apache.commons.geometry.core.collection.PointMap;
+import org.apache.commons.geometry.core.internal.AbstractBucketPointMap;
+import org.apache.commons.geometry.euclidean.threed.Vector3D;
+import org.apache.commons.numbers.core.Precision;
+
+/** Internal {@link PointMap3D} implementation.
+ * @param Map value type
+ */
+final class PointMap3DImpl
+extends AbstractBucketPointMap
+implements PointMap {
+
+/** Number of children per node. */
+private static final int NODE_CHILD_COUNT = 8;
+
+/** Max entries per node. This value was determined empirically was chosen
to
+ * provide a balance between having a small number of entries in each node
when
+ * searching and having a large number of samples to provide a good split
point
+ * during insertion.
Review comment:
Good idea. Done.
--
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.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [commons-geometry] darkma773r commented on a change in pull request #194: GEOMETRY-142: PointMap and PointSet
darkma773r commented on a change in pull request #194:
URL: https://github.com/apache/commons-geometry/pull/194#discussion_r827562722
##
File path:
commons-geometry-examples/examples-jmh/src/main/java/org/apache/commons/geometry/examples/jmh/euclidean/pointmap/RebuildingKDTree.java
##
@@ -0,0 +1,259 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.geometry.examples.jmh.euclidean.pointmap;
+
+import java.util.ArrayList;
+import java.util.Comparator;
+import java.util.List;
+
+import org.apache.commons.geometry.euclidean.threed.Vector3D;
+import org.apache.commons.numbers.core.Precision.DoubleEquivalence;
+
+/** {@link KDTree} subclass that rebuilds the tree periodically in an
+ * attempt to restrict the overall height of the tree.
+ * @param Value type
+ */
+public class RebuildingKDTree extends KDTree {
+
+/** Default rebuild maximum. */
+private static final int DEFAULT_REBUILD_MAX = 16;
+
+/** Maximum size of the tree before it is rebuilt. */
+private int rebuildMax = DEFAULT_REBUILD_MAX;
+
+/** Minimum size of the tree before it is rebuilt. */
+private int rebuildMin;
+
+/** Construct a new instance.
+ * @param precision precision context
+ */
+public RebuildingKDTree(final DoubleEquivalence precision) {
+super(precision);
+}
+
+/** {@inheritDoc} */
+@Override
+public V put(final Vector3D key, final V value) {
+final V result = super.put(key, value);
+
+if (size() >= rebuildMax) {
+rebuild();
+}
+
+return result;
+}
+
+/** {@inheritDoc} */
+@Override
+public V remove(final Object key) {
+final V result = super.remove(key);
+
+if (size() <= rebuildMin) {
+rebuild();
+}
+
+return result;
+}
+
+/**
+ * Rebuild the tree, attempting to reduce the tree depth.
+ */
+public void rebuild() {
+int n = size();
+if (n > 0) {
+// construct an array list containing all of the tree nodes
+final List> nodes = collectNodes();
+
+// rebuild recursively and set the new root
+final KDTreeNode newRoot = rebuildRecursive(nodes, 0, n, 0);
+
+setRoot(newRoot);
+}
+
+rebuildMax = Math.max(DEFAULT_REBUILD_MAX, 2 * n);
+rebuildMin = n / 2;
+}
+
+/** Get a list containing all nodes in the tree. The node connections are
all cleared.
+ * @return list containing all nodes in the tree
+ */
+protected List> collectNodes() {
+final List> nodes = new ArrayList<>(size());
+collectNodesRecursive(getRoot(), nodes);
+
+return nodes;
+}
+
+/** Add nodes in the subtree rooted at {@code curr} to {@code nodes}. The
node connection
+ * references are all cleared.
+ * @param curr subtree root node
+ * @param nodes node list
+ */
+protected void collectNodesRecursive(final KDTreeNode curr, final
List> nodes) {
+if (curr != null) {
+collectNodesRecursive(curr.getLeft(), nodes);
+nodes.add(curr);
+collectNodesRecursive(curr.getRight(), nodes);
+
+curr.setParent(null);
+curr.setLeft(null);
+curr.setRight(null);
+}
+}
+
+/** Recursively rebuild the tree using the specified node sublist.
+ * @param nodes node list
+ * @param startIdx sub list start index (inclusive)
+ * @param endIdx sub list end index (exclusive)
+ * @param depth node depth
+ * @return the root of the subtree containing the nodes between {@code
startIdx} and {@code endIdx}
+ */
+protected KDTreeNode rebuildRecursive(final List> nodes,
final int startIdx, final int endIdx,
+final int depth) {
+final CutDimension cutDimension = getCutDimensionForDepth(depth);
+
+final KDTreeNode node;
+if ((endIdx - startIdx) < 2) {
+// only a single node here
+node = nodes.get(startIdx);
+} else {
+final int splitIdx = partition(nodes, startIdx, endIdx,
cutDimension);
+
+node = nodes.get(splitIdx);
+
+if
[jira] [Commented] (NUMBERS-52) Incomplete beta function I(x, a, b) is inaccurate for large values of a and/or b
[
https://issues.apache.org/jira/browse/NUMBERS-52?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507275#comment-17507275
]
Alex Herbert commented on NUMBERS-52:
-
The regularised Beta functions were updated in [NUMBERS-181] with an
improvement in accuracy. This requires re-evaluation to determine if it is now
sufficient.
> Incomplete beta function I(x, a, b) is inaccurate for large values of a
> and/or b
>
>
> Key: NUMBERS-52
> URL: https://issues.apache.org/jira/browse/NUMBERS-52
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Sebastien Brisard
>Priority: Major
> Labels: gsoc2019, special-functions
>
> This was first reported in MATH-718. The result of the current implementation
> of the incomplete beta function I(x, a, b) is inaccurate when a and/or b are
> large-ish.
> I've skimmed through [slatec|http://www.netlib.org/slatec/fnlib/betai.f],
> GSL,
> [Boost|http://www.boost.org/doc/libs/1_38_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/sf_beta/ibeta_function.html]
> as well as NR. At first sight, neither uses the same method to compute this
> function. I think [TOMS-708|http://www.netlib.org/toms/708] is probably the
> best option.
> _Issue moved from MATH project on January 27, 2018 (concerned implementation
> was moved to module {{commons-numbers-gamma}} of "Commons Numbers")._
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (NUMBERS-181) Update the RegularizedBeta function using the Boost implementation
[ https://issues.apache.org/jira/browse/NUMBERS-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Herbert resolved NUMBERS-181. -- Resolution: Implemented > Update the RegularizedBeta function using the Boost implementation > -- > > Key: NUMBERS-181 > URL: https://issues.apache.org/jira/browse/NUMBERS-181 > Project: Commons Numbers > Issue Type: Improvement > Components: gamma >Affects Versions: 1.1 >Reporter: Alex Herbert >Priority: Major > Fix For: 1.1 > > > The gamma functions were updated to use the Boost C++ implementation in > NUMBERS-174. This was done for the methods where accuracy was improved over > the existing implementation. > Investigate porting the Boost C++ implementation of the beta function. This > may improve accuracy over the existing implementation. > The implementation may solve the accuracy of the RegularizedBeta when a and b > are largeish (NUMBERS-52) and will solve the computation of the complement of > the RegularizedBeta function (NUMBERS-169). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (RNG-170) nextBytes(byte[], int, int) to be consistent with JDK range checks for index out of bounds empty bytes
[
https://issues.apache.org/jira/browse/RNG-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert resolved RNG-170.
--
Resolution: Fixed
Fixed in commit:
c3c802117da90523ecc0dd1507d895ac9c3f5f54
Range checks now applied as per JDK 9 Objects.checkFromIndexSize.
> nextBytes(byte[], int, int) to be consistent with JDK range checks for index
> out of bounds empty bytes
> --
>
> Key: RNG-170
> URL: https://issues.apache.org/jira/browse/RNG-170
> Project: Commons RNG
> Issue Type: Bug
> Components: core
>Affects Versions: 1.4
>Reporter: Alex Herbert
>Priority: Trivial
> Fix For: 1.5
>
>
> The implementation of nextBytes is inconsistent:
> {code:java}
> UniformRandomProvider rng = RandomSource.KISS.create();
> byte[] empty = {};
> // OK
> rng.nextBytes(empty);
> // Throws IndexOutOfBoundsException
> rng.nextBytes(empty, 0, empty.length);
> {code}
> This also throws:
> {code:java}
> byte[] bytes = new byte[10];
> // Throws IndexOutOfBoundsException
> rng.nextBytes(bytes, 0, -1);
> {code}
> The second exception is index out of bounds. This could be:
> - illegal argument exception (negative length)
> - index out of bounds
> - ignore
> The case for ignoring negative length is this loop:
>
> {code:java}
> for (int j = 0; j < len; j++) {
> bytes[start + j]++;
> } {code}
> Will not throw for a negative length irrespective of the start index.
>
> The nextBytes(byte[], int, int) method is not in the JDK generators so there
> is no precedent for what to do for a negative length here. However
> System.arraycopy uses the start+length arguments. This test:
> {code:java}
> @ParameterizedTest
> @CsvSource({
> // OK
> "10, 0, 10",
> "10, 5, 5",
> "10, 9, 1",
> "0, 0, 0",
> // Bad
> "10, 0, 11",
> "10, 10, 1",
> "10, 10, 2147483647",
> "10, 0, -1",
> "10, 5, -1",
> })
> void testNextBytesIndices(int size, int start, int len) {
> final SplitMix64 rng = new SplitMix64(123);
> final byte[] bytes = new byte[size];
> // Be consistent with System.arraycopy
> try {
> System.arraycopy(bytes, start, bytes, start, len);
> } catch (Exception ex) {
> // nextBytes should throw the same exception
> Assertions.assertThrows(ex.getClass(), () ->
> rng.nextBytes(bytes, start, len));
> return;
> }
> // OK
> rng.nextBytes(bytes, start, len);
> }
> {code}
> Shows the exception raised should be ArrayIndexOutOfBoundsException
> (currently it is IndexOutOfBoundsException). It also shows that
> System.arraycopy will allows zero length for an empty array with start=0.
> I suggest updating the method nextBytes(byte[], start, len) to throw
> consistent exceptions matching System.arraycopy. This is a minimal change to
> switch to ArrayIndexOutOfBoundException and to ignore zero length byte[] when
> start=len=0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (RNG-170) nextBytes(byte[], int, int) to be consistent with JDK range checks for index out of bounds empty bytes
[
https://issues.apache.org/jira/browse/RNG-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17507260#comment-17507260
]
Alex Herbert commented on RNG-170:
--
Java 9 introduced:
{code:java}
Objects.checkFromIndexSize(int fromIndex, int size, int length);
{code}
See [Objects.checkFromIndexSize JDK 11
javadoc|https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Objects.html#checkFromIndexSize(int,int,int)]
The behaviour of this method is the same as System.arraycopy but throws
IndexOutOfBoundException, not ArrayIndexOutOfBoundException.
It will allow:
{noformat}
size start len
00 0
10 100{noformat}
The latter is an edge case that also previously threw for nextBytes. So this is
two behaviour changes introduced by updating to be consistent with the JDK
range checks, both when the length is 0.
> nextBytes(byte[], int, int) to be consistent with JDK range checks for index
> out of bounds empty bytes
> --
>
> Key: RNG-170
> URL: https://issues.apache.org/jira/browse/RNG-170
> Project: Commons RNG
> Issue Type: Bug
> Components: core
>Affects Versions: 1.4
>Reporter: Alex Herbert
>Priority: Trivial
> Fix For: 1.5
>
>
> The implementation of nextBytes is inconsistent:
> {code:java}
> UniformRandomProvider rng = RandomSource.KISS.create();
> byte[] empty = {};
> // OK
> rng.nextBytes(empty);
> // Throws IndexOutOfBoundsException
> rng.nextBytes(empty, 0, empty.length);
> {code}
> This also throws:
> {code:java}
> byte[] bytes = new byte[10];
> // Throws IndexOutOfBoundsException
> rng.nextBytes(bytes, 0, -1);
> {code}
> The second exception is index out of bounds. This could be:
> - illegal argument exception (negative length)
> - index out of bounds
> - ignore
> The case for ignoring negative length is this loop:
>
> {code:java}
> for (int j = 0; j < len; j++) {
> bytes[start + j]++;
> } {code}
> Will not throw for a negative length irrespective of the start index.
>
> The nextBytes(byte[], int, int) method is not in the JDK generators so there
> is no precedent for what to do for a negative length here. However
> System.arraycopy uses the start+length arguments. This test:
> {code:java}
> @ParameterizedTest
> @CsvSource({
> // OK
> "10, 0, 10",
> "10, 5, 5",
> "10, 9, 1",
> "0, 0, 0",
> // Bad
> "10, 0, 11",
> "10, 10, 1",
> "10, 10, 2147483647",
> "10, 0, -1",
> "10, 5, -1",
> })
> void testNextBytesIndices(int size, int start, int len) {
> final SplitMix64 rng = new SplitMix64(123);
> final byte[] bytes = new byte[size];
> // Be consistent with System.arraycopy
> try {
> System.arraycopy(bytes, start, bytes, start, len);
> } catch (Exception ex) {
> // nextBytes should throw the same exception
> Assertions.assertThrows(ex.getClass(), () ->
> rng.nextBytes(bytes, start, len));
> return;
> }
> // OK
> rng.nextBytes(bytes, start, len);
> }
> {code}
> Shows the exception raised should be ArrayIndexOutOfBoundsException
> (currently it is IndexOutOfBoundsException). It also shows that
> System.arraycopy will allows zero length for an empty array with start=0.
> I suggest updating the method nextBytes(byte[], start, len) to throw
> consistent exceptions matching System.arraycopy. This is a minimal change to
> switch to ArrayIndexOutOfBoundException and to ignore zero length byte[] when
> start=len=0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (RNG-170) nextBytes(byte[], int, int) to be consistent with JDK range checks for index out of bounds empty bytes
[
https://issues.apache.org/jira/browse/RNG-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex Herbert updated RNG-170:
-
Summary: nextBytes(byte[], int, int) to be consistent with JDK range checks
for index out of bounds empty bytes (was: nextBytes(byte[], int, int) throws
index out of bounds for empty bytes)
> nextBytes(byte[], int, int) to be consistent with JDK range checks for index
> out of bounds empty bytes
> --
>
> Key: RNG-170
> URL: https://issues.apache.org/jira/browse/RNG-170
> Project: Commons RNG
> Issue Type: Bug
> Components: core
>Affects Versions: 1.4
>Reporter: Alex Herbert
>Priority: Trivial
> Fix For: 1.5
>
>
> The implementation of nextBytes is inconsistent:
> {code:java}
> UniformRandomProvider rng = RandomSource.KISS.create();
> byte[] empty = {};
> // OK
> rng.nextBytes(empty);
> // Throws IndexOutOfBoundsException
> rng.nextBytes(empty, 0, empty.length);
> {code}
> This also throws:
> {code:java}
> byte[] bytes = new byte[10];
> // Throws IndexOutOfBoundsException
> rng.nextBytes(bytes, 0, -1);
> {code}
> The second exception is index out of bounds. This could be:
> - illegal argument exception (negative length)
> - index out of bounds
> - ignore
> The case for ignoring negative length is this loop:
>
> {code:java}
> for (int j = 0; j < len; j++) {
> bytes[start + j]++;
> } {code}
> Will not throw for a negative length irrespective of the start index.
>
> The nextBytes(byte[], int, int) method is not in the JDK generators so there
> is no precedent for what to do for a negative length here. However
> System.arraycopy uses the start+length arguments. This test:
> {code:java}
> @ParameterizedTest
> @CsvSource({
> // OK
> "10, 0, 10",
> "10, 5, 5",
> "10, 9, 1",
> "0, 0, 0",
> // Bad
> "10, 0, 11",
> "10, 10, 1",
> "10, 10, 2147483647",
> "10, 0, -1",
> "10, 5, -1",
> })
> void testNextBytesIndices(int size, int start, int len) {
> final SplitMix64 rng = new SplitMix64(123);
> final byte[] bytes = new byte[size];
> // Be consistent with System.arraycopy
> try {
> System.arraycopy(bytes, start, bytes, start, len);
> } catch (Exception ex) {
> // nextBytes should throw the same exception
> Assertions.assertThrows(ex.getClass(), () ->
> rng.nextBytes(bytes, start, len));
> return;
> }
> // OK
> rng.nextBytes(bytes, start, len);
> }
> {code}
> Shows the exception raised should be ArrayIndexOutOfBoundsException
> (currently it is IndexOutOfBoundsException). It also shows that
> System.arraycopy will allows zero length for an empty array with start=0.
> I suggest updating the method nextBytes(byte[], start, len) to throw
> consistent exceptions matching System.arraycopy. This is a minimal change to
> switch to ArrayIndexOutOfBoundException and to ignore zero length byte[] when
> start=len=0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (RNG-170) nextBytes(byte[], int, int) throws index out of bounds for empty bytes
Alex Herbert created RNG-170:
Summary: nextBytes(byte[], int, int) throws index out of bounds
for empty bytes
Key: RNG-170
URL: https://issues.apache.org/jira/browse/RNG-170
Project: Commons RNG
Issue Type: Bug
Components: core
Affects Versions: 1.4
Reporter: Alex Herbert
Fix For: 1.5
The implementation of nextBytes is inconsistent:
{code:java}
UniformRandomProvider rng = RandomSource.KISS.create();
byte[] empty = {};
// OK
rng.nextBytes(empty);
// Throws IndexOutOfBoundsException
rng.nextBytes(empty, 0, empty.length);
{code}
This also throws:
{code:java}
byte[] bytes = new byte[10];
// Throws IndexOutOfBoundsException
rng.nextBytes(bytes, 0, -1);
{code}
The second exception is index out of bounds. This could be:
- illegal argument exception (negative length)
- index out of bounds
- ignore
The case for ignoring negative length is this loop:
{code:java}
for (int j = 0; j < len; j++) {
bytes[start + j]++;
} {code}
Will not throw for a negative length irrespective of the start index.
The nextBytes(byte[], int, int) method is not in the JDK generators so there is
no precedent for what to do for a negative length here. However
System.arraycopy uses the start+length arguments. This test:
{code:java}
@ParameterizedTest
@CsvSource({
// OK
"10, 0, 10",
"10, 5, 5",
"10, 9, 1",
"0, 0, 0",
// Bad
"10, 0, 11",
"10, 10, 1",
"10, 10, 2147483647",
"10, 0, -1",
"10, 5, -1",
})
void testNextBytesIndices(int size, int start, int len) {
final SplitMix64 rng = new SplitMix64(123);
final byte[] bytes = new byte[size];
// Be consistent with System.arraycopy
try {
System.arraycopy(bytes, start, bytes, start, len);
} catch (Exception ex) {
// nextBytes should throw the same exception
Assertions.assertThrows(ex.getClass(), () ->
rng.nextBytes(bytes, start, len));
return;
}
// OK
rng.nextBytes(bytes, start, len);
}
{code}
Shows the exception raised should be ArrayIndexOutOfBoundsException (currently
it is IndexOutOfBoundsException). It also shows that System.arraycopy will
allows zero length for an empty array with start=0.
I suggest updating the method nextBytes(byte[], start, len) to throw consistent
exceptions matching System.arraycopy. This is a minimal change to switch to
ArrayIndexOutOfBoundException and to ignore zero length byte[] when start=len=0.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[GitHub] [commons-bcel] markro49 opened a new pull request #117: Verifier
markro49 opened a new pull request #117: URL: https://github.com/apache/commons-bcel/pull/117 This fixes a number of BCEL issues related to running the Verifier on a bad or malformed .class file and having it die with an exception rather than report a verification failure. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Work logged] (COMPRESS-612) Support atime/ctime and higher time precision for TAR
[ https://issues.apache.org/jira/browse/COMPRESS-612?focusedWorklogId=741727=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-741727 ] ASF GitHub Bot logged work on COMPRESS-612: --- Author: ASF GitHub Bot Created on: 15/Mar/22 16:23 Start Date: 15/Mar/22 16:23 Worklog Time Spent: 10m Work Description: andrebrait commented on pull request #254: URL: https://github.com/apache/commons-compress/pull/254#issuecomment-1068187687 @PeterAlfredLee Thanks, I checked it and I found the reason. It's because I removed this: ```java /** Convert millis to seconds */ public static final int MILLIS_PER_SECOND = 1000; ``` I put it back. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 741727) Time Spent: 40m (was: 0.5h) > Support atime/ctime and higher time precision for TAR > - > > Key: COMPRESS-612 > URL: https://issues.apache.org/jira/browse/COMPRESS-612 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.21 >Reporter: Andre Brait >Priority: Major > Labels: tar > Time Spent: 40m > Remaining Estimate: 0h > > This is a proposal for some code I have already worked on. > h3. Context > I'm coding a tool that requires extracting/compressing files. I noticed the > following shortcomings: > - -File size is limited to 8GB. This limitation was lifted as of > POSIX.1-2001 and it also does not exist on GNU and old GNU formats. Bigger > files are fully supported by some TAR archiving tools such as GNU TAR. > Reference: > [https://lists.gnu.org/archive/html/help-tar/2015-04/msg1.html]- > -- I think I was actually wrong here in that current implementation should > support files >8GB if using BIGNUMBER_POSIX. > - Only modification date is available as a time type. > - Maximum granularity is seconds, even though the PAX header contains 100ns > intervals > - Other time-related PAX headers are considered extra headers (ctime and > atime) > My proposal is as follows: > - Migrate time fields from java.util.Date to java.nio.file.attribute.FileTime > - Keep backwards compatibility through getter/setter methods and add new > ones for FileTime > - Parse times in with a maximal granularity of 100ns intervals from PAX > headers > - Read/write ctime and atime and add corresponding fields > - Write times to PAX headers using a maximum granularity of 100ns intervals > when in BIGNUMBER_POSIX mode. > - -Add a new mode BIGNUMBER_POSIX_2001 for writing big numbers, allowing for > the bigger size, mtime, ctime and atime to be written- > - -Lift the 8GB limit when using BIGNUMBER_POSIX_2001- > I already have some code for that in > https://github.com/andrebrait/commons-compress/tree/COMPRESS-612 > Since compatibility with Android now requires API level 26 and that includes > FileTime, I think we can do that here as well. > This will bring tar in line with Zip in this regard. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[GitHub] [commons-compress] andrebrait commented on pull request #254: COMPRESS-612: improve TAR support for file times
andrebrait commented on pull request #254: URL: https://github.com/apache/commons-compress/pull/254#issuecomment-1068187687 @PeterAlfredLee Thanks, I checked it and I found the reason. It's because I removed this: ```java /** Convert millis to seconds */ public static final int MILLIS_PER_SECOND = 1000; ``` I put it back. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (VFS-817) DeadLock on SftpFileObject
[ https://issues.apache.org/jira/browse/VFS-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17506868#comment-17506868 ] Mykhailo edited comment on VFS-817 at 3/15/22, 1:25 PM: Not sure what should i do, please provide more detailed instructions, Attached core files contains deadlock information and all threads dump with call stacks 1LKDEADLOCK Deadlock detected !!! NULL - NULL 2LKDEADLOCKTHR Thread "pool-flow.seda.scc-route-thread-7,SA=PATHW_sftp,TR=7:f89c076e-88f3-45ba-8e7a-65ade0985e50" (0x31CA1700) 3LKDEADLOCKWTR is waiting for: 4LKDEADLOCKMON sys_mon_t:0x01002DE42530 infl_mon_t: 0x01002DE42580: 4LKDEADLOCKOBJ org/apache/commons/vfs2/provider/sftp/SftpFileObject@0xEF515468 3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread "pool-flow.seda.scc-route-thread-1,SA=PATHW_sftp,TR=8:83e21c98-1a45-45f3-9766-893868cac245" (0x31B3DA00) 3LKDEADLOCKWTR which is waiting for: 4LKDEADLOCKMON sys_mon_t:0x01002A397F18 infl_mon_t: 0x01002A397F68: 4LKDEADLOCKOBJ org/apache/commons/vfs2/provider/sftp/SftpFileSystem@0xB28E18A0 3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread "pool-flow.seda.scc-route-thread-7,SA=PATHW_sftp,TR=7:f89c076e-88f3-45ba-8e7a-65ade0985e50" (0x31CA1700) Java callstack for "pool-flow.seda.scc-route-thread-7,SA=PATHW_sftp,TR=7:f89c076e-88f3-45ba-8e7a-65ade0985e50" : 4XESTACKTRACE at org/apache/commons/vfs2/provider/sftp/SftpFileObject.doDetach(SftpFileObject.java:140) 5XESTACKTRACE (entered lock: org/apache/commons/vfs2/provider/sftp/SftpFileObject@0xEF515468, entry count: 1) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractFileObject.detach(AbstractFileObject.java:484) 5XESTACKTRACE (entered lock: org/apache/commons/vfs2/provider/sftp/SftpFileSystem@0xB28E18A0, entry count: 2) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractFileObject.refresh(AbstractFileObject.java:1790) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractFileSystem.resolveFile(AbstractFileSystem.java:344) 5XESTACKTRACE (entered lock: org/apache/commons/vfs2/provider/sftp/SftpFileSystem@0xB28E18A0, entry count: 1) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractFileSystem.resolveFile(AbstractFileSystem.java:307) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:75) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:55) 4XESTACKTRACE at org/apache/commons/vfs2/impl/DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:788) 4XESTACKTRACE at org/apache/commons/vfs2/impl/DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:835) 4XESTACKTRACE at com/scc/smx/components/file/vfs/FileProxyFactory.createVFSFileObjectFileProxy(FileProxyFactory.java:190) Java callstack for "pool-flow.seda.scc-route-thread-1,SA=PATHW_sftp,TR=8:83e21c98-1a45-45f3-9766-893868cac245": 4XESTACKTRACE at org/apache/commons/vfs2/provider/sftp/SftpFileSystem.putChannel(SftpFileSystem.java:350) 4XESTACKTRACE at org/apache/commons/vfs2/provider/sftp/SftpFileObject.statSelf(SftpFileObject.java:527) 5XESTACKTRACE (entered lock: org/apache/commons/vfs2/provider/sftp/SftpFileObject@0xEF515468, entry count: 2) 4XESTACKTRACE at org/apache/commons/vfs2/provider/sftp/SftpFileObject.getPermissions(SftpFileObject.java:457) 5XESTACKTRACE (entered lock: org/apache/commons/vfs2/provider/sftp/SftpFileObject@0xEF515468, entry count: 1) 4XESTACKTRACE at org/apache/commons/vfs2/provider/sftp/SftpFileObject.doIsWriteable(SftpFileObject.java:262) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractFileObject.isWriteable(AbstractFileObject.java:1625) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractFileObject.moveTo(AbstractFileObject.java:1677) 4XESTACKTRACE at com/scc/smx/components/file/vfs/VFSFileObjectFileProxy.moveTo(VFSFileObjectFileProxy.java:298) as for me problem may be caused by added 11 synchronized`s on methods to work with 'private SftpATTRS attrs' in SftpFileObject.java, but i`m not sure was (Author: JIRAUSER286567): Not sure what should i do, please provide some more detailed instructions, Attached cores files contains deadlock information and all threads dump with call stacks 1LKDEADLOCK Deadlock detected !!! NULL - NULL 2LKDEADLOCKTHR Thread
[GitHub] [commons-collections] garydgregory closed pull request #290: Bump checkstyle from 9.3 to 10.0
garydgregory closed pull request #290: URL: https://github.com/apache/commons-collections/pull/290 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-collections] dependabot[bot] commented on pull request #290: Bump checkstyle from 9.3 to 10.0
dependabot[bot] commented on pull request #290: URL: https://github.com/apache/commons-collections/pull/290#issuecomment-1067950239 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-collections] garydgregory commented on pull request #290: Bump checkstyle from 9.3 to 10.0
garydgregory commented on pull request #290: URL: https://github.com/apache/commons-collections/pull/290#issuecomment-1067950202 Closing: Requires Java 11. -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-scxml] garydgregory commented on pull request #35: Bump jackson-databind from 2.9.3 to 2.13.2
garydgregory commented on pull request #35: URL: https://github.com/apache/commons-scxml/pull/35#issuecomment-1067947675 @dependabot rebase -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-scxml] garydgregory commented on pull request #41: Bump jaxb-impl from 2.3.6 to 3.0.2
garydgregory commented on pull request #41: URL: https://github.com/apache/commons-scxml/pull/41#issuecomment-1067947300 @dependabot rebase -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-scxml] garydgregory merged pull request #40: Bump junit-jupiter-engine from 5.4.2 to 5.8.2
garydgregory merged pull request #40: URL: https://github.com/apache/commons-scxml/pull/40 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-scxml] garydgregory merged pull request #39: Bump jackson-core from 2.9.3 to 2.13.2
garydgregory merged pull request #39: URL: https://github.com/apache/commons-scxml/pull/39 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-scxml] garydgregory merged pull request #42: Bump Saxon-HE from 9.6.0-1 to 11.2
garydgregory merged pull request #42: URL: https://github.com/apache/commons-scxml/pull/42 -- 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. To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (RNG-169) Update byte[] array conversion use optimum memory allocation
Alex Herbert created RNG-169: Summary: Update byte[] array conversion use optimum memory allocation Key: RNG-169 URL: https://issues.apache.org/jira/browse/RNG-169 Project: Commons RNG Issue Type: Improvement Components: simple Affects Versions: 1.4 Reporter: Alex Herbert Fix For: 1.5 The seed conversion routines in ByteArray2LongArray and ByteArray2IntArray can be optimised for memory usage. The converters can be updated to implement Seed2ArrayConverter. This allows the length of the output seed to be constructed to the correct length. This will avoid converting part of the byte[] seed that is not used. In addition the input seed is expanded if it is not modulus 8 or 4 respectively using Arrays.copyOf. This will zero fill the end of the seed. The array can then be converted by the NumberFactory without an exception. These routines should be updated to use the same method as NumberFactory to fill in a long[] and then add any trailing bytes to the final long. This avoids any array copy when using arbitrary seed lengths, e.g. SecureRandom.getSeed(13). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (VFS-817) DeadLock on SftpFileObject
[ https://issues.apache.org/jira/browse/VFS-817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17506868#comment-17506868 ] Mykhailo commented on VFS-817: -- Not sure what should i do, please provide some more detailed instructions, Attached cores files contains deadlock information and all threads dump with call stacks 1LKDEADLOCK Deadlock detected !!! NULL - NULL 2LKDEADLOCKTHR Thread "pool-flow.seda.scc-route-thread-7,SA=PATHW_sftp,TR=7:f89c076e-88f3-45ba-8e7a-65ade0985e50" (0x31CA1700) 3LKDEADLOCKWTR is waiting for: 4LKDEADLOCKMON sys_mon_t:0x01002DE42530 infl_mon_t: 0x01002DE42580: 4LKDEADLOCKOBJ org/apache/commons/vfs2/provider/sftp/SftpFileObject@0xEF515468 3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread "pool-flow.seda.scc-route-thread-1,SA=PATHW_sftp,TR=8:83e21c98-1a45-45f3-9766-893868cac245" (0x31B3DA00) 3LKDEADLOCKWTR which is waiting for: 4LKDEADLOCKMON sys_mon_t:0x01002A397F18 infl_mon_t: 0x01002A397F68: 4LKDEADLOCKOBJ org/apache/commons/vfs2/provider/sftp/SftpFileSystem@0xB28E18A0 3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread "pool-flow.seda.scc-route-thread-7,SA=PATHW_sftp,TR=7:f89c076e-88f3-45ba-8e7a-65ade0985e50" (0x31CA1700) Java callstack for "pool-flow.seda.scc-route-thread-7,SA=PATHW_sftp,TR=7:f89c076e-88f3-45ba-8e7a-65ade0985e50" : 4XESTACKTRACE at org/apache/commons/vfs2/provider/sftp/SftpFileObject.doDetach(SftpFileObject.java:140) 5XESTACKTRACE (entered lock: org/apache/commons/vfs2/provider/sftp/SftpFileObject@0xEF515468, entry count: 1) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractFileObject.detach(AbstractFileObject.java:484) 5XESTACKTRACE (entered lock: org/apache/commons/vfs2/provider/sftp/SftpFileSystem@0xB28E18A0, entry count: 2) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractFileObject.refresh(AbstractFileObject.java:1790) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractFileSystem.resolveFile(AbstractFileSystem.java:344) 5XESTACKTRACE (entered lock: org/apache/commons/vfs2/provider/sftp/SftpFileSystem@0xB28E18A0, entry count: 1) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractFileSystem.resolveFile(AbstractFileSystem.java:307) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:75) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractOriginatingFileProvider.findFile(AbstractOriginatingFileProvider.java:55) 4XESTACKTRACE at org/apache/commons/vfs2/impl/DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:788) 4XESTACKTRACE at org/apache/commons/vfs2/impl/DefaultFileSystemManager.resolveFile(DefaultFileSystemManager.java:835) 4XESTACKTRACE at com/scc/smx/components/file/vfs/FileProxyFactory.createVFSFileObjectFileProxy(FileProxyFactory.java:190) Java callstack for "pool-flow.seda.scc-route-thread-1,SA=PATHW_sftp,TR=8:83e21c98-1a45-45f3-9766-893868cac245": 4XESTACKTRACE at org/apache/commons/vfs2/provider/sftp/SftpFileSystem.putChannel(SftpFileSystem.java:350) 4XESTACKTRACE at org/apache/commons/vfs2/provider/sftp/SftpFileObject.statSelf(SftpFileObject.java:527) 5XESTACKTRACE (entered lock: org/apache/commons/vfs2/provider/sftp/SftpFileObject@0xEF515468, entry count: 2) 4XESTACKTRACE at org/apache/commons/vfs2/provider/sftp/SftpFileObject.getPermissions(SftpFileObject.java:457) 5XESTACKTRACE (entered lock: org/apache/commons/vfs2/provider/sftp/SftpFileObject@0xEF515468, entry count: 1) 4XESTACKTRACE at org/apache/commons/vfs2/provider/sftp/SftpFileObject.doIsWriteable(SftpFileObject.java:262) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractFileObject.isWriteable(AbstractFileObject.java:1625) 4XESTACKTRACE at org/apache/commons/vfs2/provider/AbstractFileObject.moveTo(AbstractFileObject.java:1677) 4XESTACKTRACE at com/scc/smx/components/file/vfs/VFSFileObjectFileProxy.moveTo(VFSFileObjectFileProxy.java:298) as for me problem may be caused by added 11 synchronized`s on methods to work with 'private SftpATTRS attrs' in SftpFileObject.java, but i`m not sure > DeadLock on SftpFileObject > -- > > Key: VFS-817 > URL: https://issues.apache.org/jira/browse/VFS-817 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.9.0 >Reporter: Mykhailo >Priority: Major > Attachments: cores.zip > > >
