[jira] [Commented] (MATH-1534) GaussianCurveFitter.ParameterGuesser uses supicious halfHeight calculations
[
https://issues.apache.org/jira/browse/MATH-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116451#comment-17116451
]
Christoph Läubrich commented on MATH-1534:
--
I'll try to provide a patch, a SimpleRegression could be enough here I just has
used this for a first simple try to play around a little bit with different
techniques. It was really fast anyways as I only compute around 1000 fits but
I'll try to recheck with SimpleRegression. I also used Polynomial because I
don't find any dedicated "Line" in common-math but maybe there is already a
class for this purpose?
Maybe it would also be an option to have multiple "guesser" classes?
> GaussianCurveFitter.ParameterGuesser uses supicious halfHeight calculations
> ---
>
> Key: MATH-1534
> URL: https://issues.apache.org/jira/browse/MATH-1534
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 4.0, 3.6.1
>Reporter: Christoph Läubrich
>Priority: Minor
>
> I'm currently looking into some curve-fitting and have examined the
> basicGuess(WeightedObservedPoint[])
> in GaussianCurveFitter.ParameterGuesser, and there is one thing I don't
> really understand.
> in [Line
> 301|https://github.com/apache/commons-math/blob/master/src/main/java/org/apache/commons/math4/fitting/GaussianCurveFitter.java#L301
> ] the "halfY" is computed by n (what is the maximal y value of the
> observation) + half the sum of n+m (where m is the x value of the maximum)
> applying this to some of my datapoints that fit relatively good as a Gaussian
> later, it seems that this condition never works (assuming that max X != 0),
> and the default in the catch clause is used instead. It seems that the
> optimizer is quite well in fitting the data anyways.
> [~erans] also suggested on the mailinglist that:
> {quote}it seems that the current code could be made more robust by
> shifting the abscissa of the maximum height to 0 before performing
> the rest of the computation{quote}
> For my own "guessing" I used the following strategy, I'm not sure if the
> current code does something similar:
> # Use p[0] and p[max] to form a line, then use PolynomialCurveFitter to fit
> the line to all points on the left
> # Use the fitted line to calculate Xleft at Ymax
> # do the same for the rigtht portion
> # Assume fwhm = rightX-leftX
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (MATH-1534) GaussianCurveFitter.ParameterGuesser uses supicious halfHeight calculations
[
https://issues.apache.org/jira/browse/MATH-1534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116308#comment-17116308
]
Gilles Sadowski commented on MATH-1534:
---
bq. [...] my own "guessing" [...]
Would you provide a PR/patch (with unit tests) so that we can compare?
bq. [...] use PolynomialCurveFitter [...]
At first sight, that seems "heavy-weight" since the fitter calls a non-linear
least-squares optimizer. The idea of the "guesser" is that it should be fast.
Then again, I don't think we ever made any benchmark...
> GaussianCurveFitter.ParameterGuesser uses supicious halfHeight calculations
> ---
>
> Key: MATH-1534
> URL: https://issues.apache.org/jira/browse/MATH-1534
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 4.0, 3.6.1
>Reporter: Christoph Läubrich
>Priority: Minor
>
> I'm currently looking into some curve-fitting and have examined the
> basicGuess(WeightedObservedPoint[])
> in GaussianCurveFitter.ParameterGuesser, and there is one thing I don't
> really understand.
> in [Line
> 301|https://github.com/apache/commons-math/blob/master/src/main/java/org/apache/commons/math4/fitting/GaussianCurveFitter.java#L301
> ] the "halfY" is computed by n (what is the maximal y value of the
> observation) + half the sum of n+m (where m is the x value of the maximum)
> applying this to some of my datapoints that fit relatively good as a Gaussian
> later, it seems that this condition never works (assuming that max X != 0),
> and the default in the catch clause is used instead. It seems that the
> optimizer is quite well in fitting the data anyways.
> [~erans] also suggested on the mailinglist that:
> {quote}it seems that the current code could be made more robust by
> shifting the abscissa of the maximum height to 0 before performing
> the rest of the computation{quote}
> For my own "guessing" I used the following strategy, I'm not sure if the
> current code does something similar:
> # Use p[0] and p[max] to form a line, then use PolynomialCurveFitter to fit
> the line to all points on the left
> # Use the fitted line to calculate Xleft at Ymax
> # do the same for the rigtht portion
> # Assume fwhm = rightX-leftX
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-761) org.apache.commons.collections.IteratorUtils.toList() will return empty list when size of iterator is 1
[ https://issues.apache.org/jira/browse/COLLECTIONS-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116254#comment-17116254 ] Gary D. Gregory commented on COLLECTIONS-761: - You need to write your test with JUnit and assert what you think is the correct behavior. If the test fails then we can see if there is a failure in the main code or if the test expectations are valid. Version 3.2.2 is old, please use git master and provide a PR there. > org.apache.commons.collections.IteratorUtils.toList() will return empty list > when size of iterator is 1 > --- > > Key: COLLECTIONS-761 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-761 > Project: Commons Collections > Issue Type: Bug >Affects Versions: 3.2.2 >Reporter: Chen Lingqi >Priority: Minor > > org.apache.commons.collections.IteratorUtils.toList() will return empty list > when size of iterator is 1. In this case, iterator size is 1, return value of > iterator.hasNext() is false, therefore, it will return empty list by default. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-761) org.apache.commons.collections.IteratorUtils.toList() will return empty list when size of iterator is 1
[
https://issues.apache.org/jira/browse/COLLECTIONS-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116184#comment-17116184
]
Prabhakar Kumar Shah edited comment on COLLECTIONS-761 at 5/25/20, 6:55 PM:
is this test code correct?
{code:java}
//
public static void main(String[] args) {
Set strings = new HashSet<>();
strings.add("this is testtstring");
Iterator iterator = strings.iterator();
List out = IteratorUtils.toList(iterator);
Iterator stringIterator = out.iterator();
while(stringIterator.hasNext()){
System.out.println(stringIterator.next());
} }
{code}
it seems to be working
was (Author: pixelrism):
is this test code correct?
{code:java}
// public static void main(String[] args) {
Set strings = new HashSet<>();
strings.add("this is testtstring");
Iterator iterator = strings.iterator();
List out = IteratorUtils.toList(iterator);
Iterator stringIterator = out.iterator();
while(stringIterator.hasNext()){
System.out.println(stringIterator.next());
} }
{code}
it seems to be working
> org.apache.commons.collections.IteratorUtils.toList() will return empty list
> when size of iterator is 1
> ---
>
> Key: COLLECTIONS-761
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-761
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Chen Lingqi
>Priority: Minor
>
> org.apache.commons.collections.IteratorUtils.toList() will return empty list
> when size of iterator is 1. In this case, iterator size is 1, return value of
> iterator.hasNext() is false, therefore, it will return empty list by default.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (COLLECTIONS-761) org.apache.commons.collections.IteratorUtils.toList() will return empty list when size of iterator is 1
[
https://issues.apache.org/jira/browse/COLLECTIONS-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116184#comment-17116184
]
Prabhakar Kumar Shah edited comment on COLLECTIONS-761 at 5/25/20, 6:55 PM:
is this test code correct?
{code:java}
// public static void main(String[] args) {
Set strings = new HashSet<>();
strings.add("this is testtstring");
Iterator iterator = strings.iterator();
List out = IteratorUtils.toList(iterator);
Iterator stringIterator = out.iterator();
while(stringIterator.hasNext()){
System.out.println(stringIterator.next());
} }
{code}
it seems to be working
was (Author: pixelrism):
is this test code correct?
{code:java}
// public static void main(String[] args) { Set strings = new
HashSet<>(); strings.add("this is testtstring"); Iterator iterator =
strings.iterator(); List out = IteratorUtils.toList(iterator);
Iterator stringIterator = out.iterator();
while(stringIterator.hasNext()){ System.out.println(stringIterator.next()); } }
{code}
it seems to be working
> org.apache.commons.collections.IteratorUtils.toList() will return empty list
> when size of iterator is 1
> ---
>
> Key: COLLECTIONS-761
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-761
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Chen Lingqi
>Priority: Minor
>
> org.apache.commons.collections.IteratorUtils.toList() will return empty list
> when size of iterator is 1. In this case, iterator size is 1, return value of
> iterator.hasNext() is false, therefore, it will return empty list by default.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (COLLECTIONS-761) org.apache.commons.collections.IteratorUtils.toList() will return empty list when size of iterator is 1
[
https://issues.apache.org/jira/browse/COLLECTIONS-761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116184#comment-17116184
]
Prabhakar Kumar Shah commented on COLLECTIONS-761:
--
is this test code correct?
{code:java}
// public static void main(String[] args) { Set strings = new
HashSet<>(); strings.add("this is testtstring"); Iterator iterator =
strings.iterator(); List out = IteratorUtils.toList(iterator);
Iterator stringIterator = out.iterator();
while(stringIterator.hasNext()){ System.out.println(stringIterator.next()); } }
{code}
it seems to be working
> org.apache.commons.collections.IteratorUtils.toList() will return empty list
> when size of iterator is 1
> ---
>
> Key: COLLECTIONS-761
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-761
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 3.2.2
>Reporter: Chen Lingqi
>Priority: Minor
>
> org.apache.commons.collections.IteratorUtils.toList() will return empty list
> when size of iterator is 1. In this case, iterator size is 1, return value of
> iterator.hasNext() is false, therefore, it will return empty list by default.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (MATH-1534) GaussianCurveFitter.ParameterGuesser uses supicious halfHeight calculations
Christoph Läubrich created MATH-1534:
Summary: GaussianCurveFitter.ParameterGuesser uses supicious
halfHeight calculations
Key: MATH-1534
URL: https://issues.apache.org/jira/browse/MATH-1534
Project: Commons Math
Issue Type: Bug
Affects Versions: 3.6.1, 4.0
Reporter: Christoph Läubrich
I'm currently looking into some curve-fitting and have examined the
basicGuess(WeightedObservedPoint[])
in GaussianCurveFitter.ParameterGuesser, and there is one thing I don't really
understand.
in [Line
301|https://github.com/apache/commons-math/blob/master/src/main/java/org/apache/commons/math4/fitting/GaussianCurveFitter.java#L301
] the "halfY" is computed by n (what is the maximal y value of the
observation) + half the sum of n+m (where m is the x value of the maximum)
applying this to some of my datapoints that fit relatively good as a Gaussian
later, it seems that this condition never works (assuming that max X != 0), and
the default in the catch clause is used instead. It seems that the optimizer is
quite well in fitting the data anyways.
[~erans] also suggested on the mailinglist that:
{quote}it seems that the current code could be made more robust by
shifting the abscissa of the maximum height to 0 before performing
the rest of the computation{quote}
For my own "guessing" I used the following strategy, I'm not sure if the
current code does something similar:
# Use p[0] and p[max] to form a line, then use PolynomialCurveFitter to fit
the line to all points on the left
# Use the fitted line to calculate Xleft at Ymax
# do the same for the rigtht portion
# Assume fwhm = rightX-leftX
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-95) CSG Examples
[ https://issues.apache.org/jira/browse/GEOMETRY-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116131#comment-17116131 ] Gilles Sadowski commented on GEOMETRY-95: - bq. [...] object B, project it onto a plane orthogonal to your look direction, and then subtract the projection of object A onto that same plane [...] Yes, that was what I had in mind. bq. would not be able to provide visible point coordinates That would be a necessary feature in many cases. For example, I seem to recall that you mentioned the like of facet objects that would also carry additional (user-provided) information. If this information is "color", it is needed in order to draw scene as would be seen from the specified viewpoint. > CSG Examples > > > Key: GEOMETRY-95 > URL: https://issues.apache.org/jira/browse/GEOMETRY-95 > Project: Apache Commons Geometry > Issue Type: New Feature >Reporter: Matt Juntunen >Priority: Major > Labels: beta1 > > Adding Constructive Solid Geometry examples and userguide entries to help new > users to the library use these features. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEOMETRY-95) CSG Examples
[
https://issues.apache.org/jira/browse/GEOMETRY-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116105#comment-17116105
]
Matt Juntunen commented on GEOMETRY-95:
---
I'm just trying to get a sense of what you have in mind for visibility
determination since there are many ways to do that. One way (which is one that
we've done at my day job), is to take a number of rays from certain vantage
points and cast them against the objects in the scene. If the ray intersection
with object {{A}} is closer than the ray intersection for object {{B}}, then
object {{B}} is occluded by {{A}} at that point. This is effective and quick
but it does not give a completely full picture of the situation since only a
finite number of rays can be cast. It is possible that the object visibility is
not what is expected at one of the points that was not tested. However, this
approach can also given you valuable information about the visible point, such
as the point coordinates and normal.
Another option is to take the objects being tested, project them onto a 2D
plane (see GEOMETRY-67), and compute the difference of the regions. In this
case, you would take object {{B}}, project it onto a plane orthogonal to your
look direction, and then subtract the projection of object {{A}} onto that same
plane. If the resulting 2D region is not empty, then some portion of {{B}} is
not occluded by {{A}}. This provides a completely full picture of the
visibility (using an orthographic projection) but would not be able to provide
visible point coordinates or surface normals.
Which of the above approaches is best depends on a number of factors, such how
much accuracy is required, how complex the models in question are, whether
surface normals are needed, whether or not the models must be transformed
before comparison, etc. That's why I was asking for more details on your
particular use case.
> CSG Examples
>
>
> Key: GEOMETRY-95
> URL: https://issues.apache.org/jira/browse/GEOMETRY-95
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: beta1
>
> Adding Constructive Solid Geometry examples and userguide entries to help new
> users to the library use these features.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (LANG-1545) CharSequenceUtils.regionMatches is wrong dealing with Georgian.
[ https://issues.apache.org/jira/browse/LANG-1545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory resolved LANG-1545. --- Fix Version/s: 3.10.1 Resolution: Fixed Please review and close, especially the test I edited. > CharSequenceUtils.regionMatches is wrong dealing with Georgian. > > > Key: LANG-1545 > URL: https://issues.apache.org/jira/browse/LANG-1545 > Project: Commons Lang > Issue Type: Bug >Reporter: JIN XU >Priority: Major > Fix For: 3.10.1 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/529] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEOMETRY-50) Overflow in Vector norm and distance
[
https://issues.apache.org/jira/browse/GEOMETRY-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116085#comment-17116085
]
Matt Juntunen commented on GEOMETRY-50:
---
Revisiting this...
I took another look at the performance numbers here, checking JDK 8 and JDK 11.
Using {{SafeNorm}} is ~20 times faster on JDK 8 (vs {{Math.hypot}}) and ~2
times faster on JDK 11 for 2D norm calculation. For 3D it is ~10 slower than
the current unchecked implementation (raw floating point operations) on both
JDKs. So, it's something of a mixed bag in terms of performance.
I also noticed an interesting thing in the Vector2D unit tests while making
this change. The test
[testOrthogonal_fullCircle|https://github.com/apache/commons-geometry/blob/master/commons-geometry-euclidean/src/test/java/org/apache/commons/geometry/euclidean/twod/Vector2DTest.java#L469]
began failing on the dot product comparison on line 479 after the switch to
{{SafeNorm}}. This test creates vectors of length pi pointing in directions all
around the circle, computes the orthogonal vectors from each, and then checks
that the orthogonal vector has unit length and a dot product of zero with the
original vector. The original test epsilon for the dot product comparison was
{{Math.ulp(1d) = 2.220446049250313E-16}}. After the switch from {{Math.hypot}}
to {{SafeNorm}}, one of the produced dot products changed from
{{-5.8839292547567834E-18}} to {{-2.2617374526731045E-16}}, causing the test to
fail. Changing the test epsilon to {{Math.ulp(Math.PI) =
4.440892098500626E-16}} (the length of the input vector) makes the test pass.
Is this result to be expected here? I would hope that {{Math.hypot}} and
{{SafeNorm}} would have returned the same numbers.
> Overflow in Vector norm and distance
>
>
> Key: GEOMETRY-50
> URL: https://issues.apache.org/jira/browse/GEOMETRY-50
> Project: Apache Commons Geometry
> Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Major
> Labels: beta1
>
> In Euclidean Vector classes (Vector2D, Vector3D), norm() and distance() rely
> on Math.sqrt(), which can overflow if the components of the vectors are
> large. Instead, they should rely on SafeNorm.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-95) CSG Examples
[
https://issues.apache.org/jira/browse/GEOMETRY-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116035#comment-17116035
]
Gilles Sadowski commented on GEOMETRY-95:
-
{quote}1. Create a Ray from some eye location and look direction.
2. Cast it against 2 or more created regions.
3. See which one intersects first.
{quote}
Do you mean
# create a "look direction" from the "vantage" point to a "facet" of the
farther region,
# cast it onto the closer region, and get "infinity" if there is no
intersection?
Does the developer need to do it for every "facet" of the farther region?
> CSG Examples
>
>
> Key: GEOMETRY-95
> URL: https://issues.apache.org/jira/browse/GEOMETRY-95
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: beta1
>
> Adding Constructive Solid Geometry examples and userguide entries to help new
> users to the library use these features.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (STATISTICS-24) Documentation mistake maybe
[
https://issues.apache.org/jira/browse/STATISTICS-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116069#comment-17116069
]
Gilles Sadowski commented on STATISTICS-24:
---
bq. Is that a documentation mistake?
Yes; thanks for the report.
It should be fixed in commit 0d5a2a29593b912df307fba5083b5105dac32edf ("master"
branch).
I've updated the web site (please check).
> Documentation mistake maybe
> ---
>
> Key: STATISTICS-24
> URL: https://issues.apache.org/jira/browse/STATISTICS-24
> Project: Apache Commons Statistics
> Issue Type: Bug
>Reporter: Wu Tao
>Priority: Trivial
>
> Hi all!
> When I followed the Developers Guide at
> [http://commons.apache.org/proper/commons-statistics/developers.html], the
> doc told me to get the code from
> [http://gitbox.apache.org/repos/asf/commons-rng.git.|http://gitbox.apache.org/repos/asf/commons-rng.git,]
> I'm wondering why I can only get the rng instead of the statistics module.
> Is that a documentation mistake?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-vfs] garydgregory commented on pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
garydgregory commented on pull request #91: URL: https://github.com/apache/commons-vfs/pull/91#issuecomment-633572312 @PeterAlfredLee, What problem are you trying to solve here? As it stands, this PR breaks binary compatibility, so would be a -1 for 2.x. We should only break BC in a new major version. 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 #529: [LANG-1545] CharSequenceUtils.regionMatches is wrong dealing with Georgian.
XenoAmess edited a comment on pull request #529: URL: https://github.com/apache/commons-lang/pull/529#issuecomment-633563513 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-1545) CharSequenceUtils.regionMatches is wrong dealing with Georgian.
[ https://issues.apache.org/jira/browse/LANG-1545?focusedWorklogId=437161=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-437161 ] ASF GitHub Bot logged work on LANG-1545: Author: ASF GitHub Bot Created on: 25/May/20 13:07 Start Date: 25/May/20 13:07 Worklog Time Spent: 10m Work Description: XenoAmess commented on pull request #529: URL: https://github.com/apache/commons-lang/pull/529#issuecomment-633563513 > On that page, the U+01D3 is "Latin Capital Letter U with caron" on this GitHub page it looks like "Greek theta symbol". Which one are you testing? @garydgregory originally I found it with something uncorrect about [Greek Capital Letter Theta] and [Greek Theta Symbol] . And then I started a fully test of every pair of unicode chars and found the bug also appears when [Latin Small Letter dotless I] and [Latin Capital Letter I with dot above]. 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: 437161) Time Spent: 1h (was: 50m) > CharSequenceUtils.regionMatches is wrong dealing with Georgian. > > > Key: LANG-1545 > URL: https://issues.apache.org/jira/browse/LANG-1545 > Project: Commons Lang > Issue Type: Bug >Reporter: JIN XU >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/529] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Work logged] (LANG-1545) CharSequenceUtils.regionMatches is wrong dealing with Georgian.
[ https://issues.apache.org/jira/browse/LANG-1545?focusedWorklogId=437162=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-437162 ] ASF GitHub Bot logged work on LANG-1545: Author: ASF GitHub Bot Created on: 25/May/20 13:07 Start Date: 25/May/20 13:07 Worklog Time Spent: 10m Work Description: XenoAmess edited a comment on pull request #529: URL: https://github.com/apache/commons-lang/pull/529#issuecomment-633563513 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: 437162) Time Spent: 1h 10m (was: 1h) > CharSequenceUtils.regionMatches is wrong dealing with Georgian. > > > Key: LANG-1545 > URL: https://issues.apache.org/jira/browse/LANG-1545 > Project: Commons Lang > Issue Type: Bug >Reporter: JIN XU >Priority: Major > Time Spent: 1h 10m > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/529] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] XenoAmess commented on pull request #529: [LANG-1545] CharSequenceUtils.regionMatches is wrong dealing with Georgian.
XenoAmess commented on pull request #529: URL: https://github.com/apache/commons-lang/pull/529#issuecomment-633563513 > On that page, the U+01D3 is "Latin Capital Letter U with caron" on this GitHub page it looks like "Greek theta symbol". Which one are you testing? @garydgregory originally I found it with something uncorrect about [Greek Capital Letter Theta] and [Greek Theta Symbol] . And then I started a fully test of every pair of unicode chars and found the bug also appears when [Latin Small Letter dotless I] and [Latin Capital Letter I with dot above]. 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] (GEOMETRY-97) Use Centroid instead of Barycenter
[
https://issues.apache.org/jira/browse/GEOMETRY-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116012#comment-17116012
]
Matt Juntunen commented on GEOMETRY-97:
---
This is ready here:
https://github.com/darkma773r/commons-geometry/tree/geometry-97-working
Just waiting for feedback on GEOMETRY-94 before merging.
> Use Centroid instead of Barycenter
> --
>
> Key: GEOMETRY-97
> URL: https://issues.apache.org/jira/browse/GEOMETRY-97
> Project: Apache Commons Geometry
> Issue Type: Improvement
>Reporter: Matt Juntunen
>Priority: Minor
> Labels: beta1
>
> In geometry, the terms "centroid" and "barycenter" are synonyms referring to
> the center of mass of a geometric object. The code currently uses
> "barycenter" when referring to the center of mass (ex:
> {{region.getBarycenter()}}). However, "centroid" seems to be used more
> frequently. For example, one is far more likely to find relevant results when
> searching Google for "polygon centroid" than "polygon barycenter". Also,
> "barycenter" has an alternate meaning in astrophysics, where it refers to the
> center of mass of two or more orbiting objects. It seems to me like
> "centroid" is a better, more geometry-focused term to use in the code.
> See [centroid.|https://en.wikipedia.org/wiki/Centroid].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEOMETRY-95) CSG Examples
[
https://issues.apache.org/jira/browse/GEOMETRY-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17116009#comment-17116009
]
Matt Juntunen commented on GEOMETRY-95:
---
bq. compute the set of visible elements from some vantage point.
Can you explain more about your intended use case here? I'm wondering if the
linecast functionality is sufficient here. A simple case using linecasting
would be
1. Create a {{Ray}} from some eye location and look direction.
2. Cast it against 2 or more created regions.
3. See which one intersects first.
Are you picturing anything more than that?
> CSG Examples
>
>
> Key: GEOMETRY-95
> URL: https://issues.apache.org/jira/browse/GEOMETRY-95
> Project: Apache Commons Geometry
> Issue Type: New Feature
>Reporter: Matt Juntunen
>Priority: Major
> Labels: beta1
>
> Adding Constructive Solid Geometry examples and userguide entries to help new
> users to the library use these features.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (STATISTICS-24) Documentation mistake maybe
Wu Tao created STATISTICS-24: Summary: Documentation mistake maybe Key: STATISTICS-24 URL: https://issues.apache.org/jira/browse/STATISTICS-24 Project: Apache Commons Statistics Issue Type: Bug Reporter: Wu Tao Hi all! When I followed the Developers Guide at [http://commons.apache.org/proper/commons-statistics/developers.html], the doc told me to get the code from [http://gitbox.apache.org/repos/asf/commons-rng.git.|http://gitbox.apache.org/repos/asf/commons-rng.git,] I'm wondering why I can only get the rng instead of the statistics module. Is that a documentation mistake? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] coveralls edited a comment on pull request #529: [LANG-1545] CharSequenceUtils.regionMatches is wrong dealing with Georgian.
coveralls edited a comment on pull request #529: URL: https://github.com/apache/commons-lang/pull/529#issuecomment-621222482 [](https://coveralls.io/builds/31012644) Coverage increased (+0.01%) to 95.105% when pulling **f83d19802a7d70a539fab111f59d7e55ef1f5210 on XenoAmess:fix_bug_in_StringUtils_about_Georgian** into **f6923510352fc3fbfad68bc6c5ac5258a34671b7 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] (LANG-1545) CharSequenceUtils.regionMatches is wrong dealing with Georgian.
[ https://issues.apache.org/jira/browse/LANG-1545?focusedWorklogId=437156=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-437156 ] ASF GitHub Bot logged work on LANG-1545: Author: ASF GitHub Bot Created on: 25/May/20 12:27 Start Date: 25/May/20 12:27 Worklog Time Spent: 10m Work Description: coveralls edited a comment on pull request #529: URL: https://github.com/apache/commons-lang/pull/529#issuecomment-621222482 [](https://coveralls.io/builds/31012644) Coverage increased (+0.01%) to 95.105% when pulling **f83d19802a7d70a539fab111f59d7e55ef1f5210 on XenoAmess:fix_bug_in_StringUtils_about_Georgian** into **f6923510352fc3fbfad68bc6c5ac5258a34671b7 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: 437156) Time Spent: 50m (was: 40m) > CharSequenceUtils.regionMatches is wrong dealing with Georgian. > > > Key: LANG-1545 > URL: https://issues.apache.org/jira/browse/LANG-1545 > Project: Commons Lang > Issue Type: Bug >Reporter: JIN XU >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/529] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-csv] garydgregory edited a comment on pull request #73: Refactor csv format
garydgregory edited a comment on pull request #73: URL: https://github.com/apache/commons-csv/pull/73#issuecomment-633544633 I'm not sure if replacing usage of a type-safe constructor with a type-unsafe `Map` (values are `Object`) is a good thing. For future maintainers, it will be easy (IMO) to mess up the cast-typing and the key strings. What do others think? 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] (COMPRESS-512) "AsiExtraField is not a concrete class" with graalvm native-image
[
https://issues.apache.org/jira/browse/COMPRESS-512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17115981#comment-17115981
]
Jean-Baptiste commented on COMPRESS-512:
Thx for the replies, I will try to investigate a bit more by myself.
> "AsiExtraField is not a concrete class" with graalvm native-image
> -
>
> Key: COMPRESS-512
> URL: https://issues.apache.org/jira/browse/COMPRESS-512
> Project: Commons Compress
> Issue Type: Bug
> Components: Archivers
>Affects Versions: 1.20
>Reporter: Jean-Baptiste
>Priority: Trivial
>
> Hi, I am trying to unzip a file using apache commons compress. It is working
> with in a "classical jvm" like OpenJDK 11 or even Graalvm 11 but when I
> convert it in native-image it fails to run with its exception:
> {code:java}
> picocli.CommandLine$ExecutionException: Error while calling command (void
> fr.gouv.vitam.troubleshoot.TroubleShooter.logForAll(fr.gouv.vitam.troubleshoot.pojo.Component[],java.nio.file.Path)
> throws java.io.IOException): java.lang.ExceptionInInitializerError
> at picocli.CommandLine.executeUserObject(CommandLine.java:1816)
> at picocli.CommandLine.access$900(CommandLine.java:145)
> at
> picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2150)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2144)
> at picocli.CommandLine$RunLast.handle(CommandLine.java:2108)
> at
> picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:1975)
> at picocli.CommandLine.execute(CommandLine.java:1904)
> at
> fr.gouv.vitam.troubleshoot.TroubleShooter.main(TroubleShooter.java:165)
> Caused by: java.lang.ExceptionInInitializerError
> at
> com.oracle.svm.core.hub.ClassInitializationInfo.initialize(ClassInitializationInfo.java:290)
> at java.lang.Class.ensureInitialized(DynamicHub.java:496)
> at
> org.apache.commons.compress.archivers.zip.ZipArchiveEntry.setCentralDirectoryExtra(ZipArchiveEntry.java:700)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.readCentralDirectoryEntry(ZipFile.java:805)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:714)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:371)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:318)
> at
> org.apache.commons.compress.archivers.zip.ZipFile.(ZipFile.java:274)
> at
> fr.gouv.vitam.troubleshoot.subcommands.ZipTroubleshootReader.extract(ZipTroubleshootReader.java:44)
> at
> fr.gouv.vitam.troubleshoot.subcommands.LogForAll.execute(LogForAll.java:28)
> at
> fr.gouv.vitam.troubleshoot.TroubleService.logForAll(TroubleService.java:41)
> at
> fr.gouv.vitam.troubleshoot.TroubleShooter.logForAll(TroubleShooter.java:119)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at picocli.CommandLine.executeUserObject(CommandLine.java:1802)
> ... 7 more
> Caused by: java.lang.RuntimeException: class
> org.apache.commons.compress.archivers.zip.AsiExtraField is not a concrete
> class
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.register(ExtraFieldUtils.java:73)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.(ExtraFieldUtils.java:43)
> at
> com.oracle.svm.core.hub.ClassInitializationInfo.invokeClassInitializer(ClassInitializationInfo.java:350)
> at
> com.oracle.svm.core.hub.ClassInitializationInfo.initialize(ClassInitializationInfo.java:270)
> ... 20 more
> {code}
> The interesting part is that one I think:
> {code:java}
> org.apache.commons.compress.archivers.zip.AsiExtraField is not a concrete
> class at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.register(ExtraFieldUtils.java:73)
> at
> org.apache.commons.compress.archivers.zip.ExtraFieldUtils.(ExtraFieldUtils.java:43)
> {code}
> In order to build it in native image I am using the following configuration:
> {code:java}
>
> org.graalvm.nativeimage
> native-image-maven-plugin
> ${native-image-maven-plugin.version}
>
>
>
> ${NOT-compile-to-binary}
> troubleshooter
>
> fr.gouv.vitam.troubleshoot.TroubleShooter
>
> -H:ReflectionConfigurationFiles=classes/META-INF/native-image/picocli-generated/fr.grouv.vitam/troubloushouter/reflect-config.json
> -H:+ReportUnsupportedElementsAtRuntime
>
>
> native-image
>
> package
>
>
>
> {code}
>
> Do you have an idea ?
--
This message was sent by Atlassian Jira
[GitHub] [commons-csv] garydgregory commented on pull request #73: Refactor csv format
garydgregory commented on pull request #73: URL: https://github.com/apache/commons-csv/pull/73#issuecomment-633544633 I'm not sure if replacing usage of a type-safe constructor with a type-unsafe `Map` (values are `Object`) is a good thing. What do others think? For future maintainers, it will be easy (IMO) to mess up the cast-typing and the key strings. 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] PeterAlfredLee opened a new pull request #91: VFS-676 : change dependency from java.util.zip to Commons Compress
PeterAlfredLee opened a new pull request #91: URL: https://github.com/apache/commons-vfs/pull/91 This PR is to change the currently using zip dependency from `java.util.zip` to `Commons Compress`. Including these changes : 1. The `JarFIleObject` no longer extends from `ZipFileObject`, and the `JarFileSystem` no longer extends from `ZipFileSystem`. The `jar` module in `Commons Compress` could not achieve fit what we need in vfs, cause it did not implement some methods like `getCertificates` that are need in vfs. So I have decoupled `JarFIleObject/JarFileSystem` from `ZipFileObject/ZipFileSystem`, and moved the methods needed from `ZipFileObject/ZipFileSystem` to `JarFIleObject/JarFileSystem`. This change makes `jar` and `zip` two separate modules. 2. The `ZipFile` in `Commons Compress` open zip archivers using `Files.newByteChannel`, while the `ZipFile` in 'java.util.zip' is using a native method. This means the zip archivers can be safely deleted after reading by `ZipFIle` - and some tests are failing now and I have ignored them, say `testCannotDeleteWhileStreaming` and `testCannotDeleteWhileStreaming2`. 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] danygold closed pull request #114: Remove C-style array declaration
danygold closed pull request #114: URL: https://github.com/apache/commons-io/pull/114 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] danygold commented on pull request #114: Remove C-style array declaration
danygold commented on pull request #114: URL: https://github.com/apache/commons-io/pull/114#issuecomment-633526642 In #115 is fixed this "bug" and also others. Close this pull request because it's now redundant 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-jexl] XenoAmess commented on pull request #21: Fix travis-ci scripts. Move to java 8 according to [JEXL-249].
XenoAmess commented on pull request #21: URL: https://github.com/apache/commons-jexl/pull/21#issuecomment-633504269 @henrib Done. Review it when you have time. 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-jexl] XenoAmess commented on pull request #21: fix travis-ci script
XenoAmess commented on pull request #21: URL: https://github.com/apache/commons-jexl/pull/21#issuecomment-633487531 > Let's move to java8! JEXL-249 has been reopened. OK. then I will start doing 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. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [commons-jexl] henrib commented on pull request #21: fix travis-ci script
henrib commented on pull request #21: URL: https://github.com/apache/commons-jexl/pull/21#issuecomment-633483292 Let's move to java8! JEXL-249 has been reopened. 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] (COMPRESS-531) Tar decompression fails with NullPointerException
Maksim Zuev created COMPRESS-531:
Summary: Tar decompression fails with NullPointerException
Key: COMPRESS-531
URL: https://issues.apache.org/jira/browse/COMPRESS-531
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.20
Reporter: Maksim Zuev
This Kotlin code fails with exception(NPE.tar is in the attachment)
Exception in thread "main" java.lang.NullPointerException
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.applyPaxHeadersToCurrentEntry(TarArchiveInputStream.java:757)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.paxHeaders(TarArchiveInputStream.java:562)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:404)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:799)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt:20)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt)
{code:java}
import org.apache.commons.compress.archivers.ArchiveStreamFactory
import java.io.File
fun main() {
val tar = File("NPE.tar")
ArchiveStreamFactory().createArchiveInputStream("tar",
tar.inputStream()).use { ais ->
ais.nextEntry
ais.readAllBytes()
}
}
{code}
IOException expected
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (COMPRESS-530) Tar decompression fails with NegativeArraySizeException
Maksim Zuev created COMPRESS-530:
Summary: Tar decompression fails with NegativeArraySizeException
Key: COMPRESS-530
URL: https://issues.apache.org/jira/browse/COMPRESS-530
Project: Commons Compress
Issue Type: Bug
Reporter: Maksim Zuev
Attachments: NegativeArraySizeException.tar
This Kotlin code fails with exception(NegativeArraySizeException.tar is in the
attachment)
Exception in thread "main" java.lang.NegativeArraySizeException: -5332783
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.parsePaxHeaders(TarArchiveInputStream.java:703)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.paxHeaders(TarArchiveInputStream.java:555)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:404)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:799)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt:31)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt)
{code:java}
import org.apache.commons.compress.archivers.ArchiveStreamFactory
import java.io.File
fun main() {
val tar = File("NegativeArraySizeException.tar")
ArchiveStreamFactory().createArchiveInputStream("tar",
tar.inputStream()).use { ais ->
ais.nextEntry
ais.readAllBytes()
}
}
{code}
IOException expected
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (COMPRESS-529) Tar decompression fails with runtime exceptions
[
https://issues.apache.org/jira/browse/COMPRESS-529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zuev updated COMPRESS-529:
-
Description:
This Kotlin code fails with exception(NumberFormatException.tar is in the
attachment)
Exception in thread "main" java.lang.NumberFormatException: For input string:
"143266�921.098285006"
at
java.base/jdk.internal.math.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2054)
at
java.base/jdk.internal.math.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
at java.base/java.lang.Double.parseDouble(Double.java:543)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.processPaxHeader(TarArchiveEntry.java:1161)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.updateEntryFromPaxHeaders(TarArchiveEntry.java:1093)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.applyPaxHeadersToCurrentEntry(TarArchiveInputStream.java:757)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.paxHeaders(TarArchiveInputStream.java:562)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:404)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:799)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt:69)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt)
{code:java}
import org.apache.commons.compress.archivers.ArchiveStreamFactory
import java.io.File
fun main() {
val tar = File("NumberFormatException.tar")
ArchiveStreamFactory().createArchiveInputStream("tar",
tar.inputStream()).use { ais ->
ais.nextEntry
ais.readAllBytes()
}
}
{code}
This Kotlin code fails with exception(LongName.tar is in the attachment)
Exception in thread "main" java.lang.RuntimeException: file name 'asidhuasih a
sdjn osdn
sdvs ndv
asdjbhasdb asb iasbfi basdigf basduio
asdkhasjdhasd
asdjkhasnjddjasjdas
/?' is too long ( > 100 bytes)
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.handleLongName(TarArchiveOutputStream.java:683)
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.putArchiveEntry(TarArchiveOutputStream.java:358)
at ru.example.kotlinfuzzer.tests.MainKt.test(main.kt:20)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt:8)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt)
{code:java}
import org.apache.commons.compress.archivers.ArchiveStreamFactory
import org.apache.commons.compress.archivers.tar.TarArchiveEntry
import java.io.File
fun main() {
test(File("LongName.tar"))
}
fun test(tar: File) {
val (decompressed, name) =
ArchiveStreamFactory().createArchiveInputStream("tar", tar.inputStream()).use {
ais ->
val entry = ais.nextEntry
ais.readAllBytes() to entry.name
}
File.createTempFile("apache_", ".tar").also {
ArchiveStreamFactory().createArchiveOutputStream("tar",
it.outputStream()).use { aos ->
val entry = TarArchiveEntry(name)
entry.size = decompressed.size.toLong()
aos.putArchiveEntry(entry)
try {
aos.write(decompressed)
} finally {
aos.closeArchiveEntry()
}
}
}
}
{code}
IOException expected
was:
This Kotlin code fails with exception(NumberFormatException.tar is in the
attachment)
Exception in thread "main" java.lang.NumberFormatException: For input string:
"143266�921.098285006"
at
java.base/jdk.internal.math.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2054)
at
java.base/jdk.internal.math.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
at java.base/java.lang.Double.parseDouble(Double.java:543)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.processPaxHeader(TarArchiveEntry.java:1161)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.updateEntryFromPaxHeaders(TarArchiveEntry.java:1093)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.applyPaxHeadersToCurrentEntry(TarArchiveInputStream.java:757)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.paxHeaders(TarArchiveInputStream.java:562)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:404)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:799)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt:69)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt)
{code:java}
import org.apache.commons.compress.archivers.ArchiveStreamFactory
import java.io.File
fun main() {
val tar = File("NumberFormatException.tar")
ArchiveStreamFactory().createArchiveInputStream("tar",
tar.inputStream()).use { ais ->
ais.nextEntry
ais.readAllBytes()
}
}
{code}
This Kotlin code fails with exception(LongName.tar is in
[jira] [Created] (COMPRESS-529) Tar decompression fails with runtime exceptions
Maksim Zuev created COMPRESS-529:
Summary: Tar decompression fails with runtime exceptions
Key: COMPRESS-529
URL: https://issues.apache.org/jira/browse/COMPRESS-529
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.20
Reporter: Maksim Zuev
Attachments: LongName.tar, NumberFormatException.tar
This Kotlin code fails with exception(NumberFormatException.tar is in the
attachment)
Exception in thread "main" java.lang.NumberFormatException: For input string:
"143266�921.098285006"
at
java.base/jdk.internal.math.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2054)
at
java.base/jdk.internal.math.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
at java.base/java.lang.Double.parseDouble(Double.java:543)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.processPaxHeader(TarArchiveEntry.java:1161)
at
org.apache.commons.compress.archivers.tar.TarArchiveEntry.updateEntryFromPaxHeaders(TarArchiveEntry.java:1093)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.applyPaxHeadersToCurrentEntry(TarArchiveInputStream.java:757)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.paxHeaders(TarArchiveInputStream.java:562)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextTarEntry(TarArchiveInputStream.java:404)
at
org.apache.commons.compress.archivers.tar.TarArchiveInputStream.getNextEntry(TarArchiveInputStream.java:799)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt:69)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt)
{code:java}
import org.apache.commons.compress.archivers.ArchiveStreamFactory
import java.io.File
fun main() {
val tar = File("NumberFormatException.tar")
ArchiveStreamFactory().createArchiveInputStream("tar",
tar.inputStream()).use { ais ->
ais.nextEntry
ais.readAllBytes()
}
}
{code}
This Kotlin code fails with exception(LongName.tar is in the attachment)
Exception in thread "main" java.lang.RuntimeException: file name 'asidhuasih a
sdjn osdn
sdvs ndv
asdjbhasdb asb iasbfi basdigf basduio
asdkhasjdhasd
asdjkhasnjddjasjdas
/?' is too long ( > 100 bytes)
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.handleLongName(TarArchiveOutputStream.java:683)
at
org.apache.commons.compress.archivers.tar.TarArchiveOutputStream.putArchiveEntry(TarArchiveOutputStream.java:358)
at ru.example.kotlinfuzzer.tests.MainKt.test(main.kt:20)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt:8)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt)
{code:java}
import org.apache.commons.compress.archivers.ArchiveStreamFactory
import org.apache.commons.compress.archivers.tar.TarArchiveEntry
import java.io.File
fun main() {
test(File("LongName.tar"))
}
fun test(tar: File) {
val (decompressed, name) =
ArchiveStreamFactory().createArchiveInputStream("tar", tar.inputStream()).use {
ais ->
val entry = ais.nextEntry
ais.readAllBytes() to entry.name
}
File.createTempFile("apache_", ".tar").also {
ArchiveStreamFactory().createArchiveOutputStream("tar",
it.outputStream()).use { aos ->
val entry = TarArchiveEntry(name)
entry.size = decompressed.size.toLong()
aos.putArchiveEntry(entry)
try {
aos.write(decompressed)
} finally {
aos.closeArchiveEntry()
}
}
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (COMPRESS-528) Tar decompression - Inconsistent entry size
Maksim Zuev created COMPRESS-528:
Summary: Tar decompression - Inconsistent entry size
Key: COMPRESS-528
URL: https://issues.apache.org/jira/browse/COMPRESS-528
Project: Commons Compress
Issue Type: Bug
Affects Versions: 1.20
Reporter: Maksim Zuev
Attachments: InconsistentSize.tar
Expected that
{{[getSize|https://commons.apache.org/proper/commons-compress/javadocs/api-1.20/org/apache/commons/compress/archivers/tar/TarArchiveEntry.html#getSize--]()
}}returns the size of byte array read from ArchiveInputStream
To reproduce run this Kotlin code(InconsistentSize.tar is in the attachment).
It fails with exception
Exception in thread "main" java.lang.IllegalStateException: 19 expected but 0
found
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt:82)
at ru.example.kotlinfuzzer.tests.MainKt.main(main.kt)
{code:java}
import org.apache.commons.compress.archivers.ArchiveStreamFactory
import java.io.File
fun main() {
val tar = File("InconsistentSize.tar")
ArchiveStreamFactory().createArchiveInputStream("tar",
tar.inputStream()).use { ais ->
val expected = ais.nextEntry.size
val actual = ais.readAllBytes().size.toLong()
check(expected == actual) { "$expected expected but $actual found" }
}
}
{code}
{{}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[GitHub] [commons-csv] coveralls commented on pull request #73: Refactor csv format
coveralls commented on pull request #73: URL: https://github.com/apache/commons-csv/pull/73#issuecomment-633436839 [](https://coveralls.io/builds/31007798) Coverage increased (+0.1%) to 98.618% when pulling **5efded10c452dc84031caf587cc90527e868b141 on dota17:refactorCSVFormat** into **852e11e4fbaae07d272102f453ea9cfd1684d99d 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] dota17 opened a new pull request #73: Refactor csv format
dota17 opened a new pull request #73: URL: https://github.com/apache/commons-csv/pull/73 refactor CSVFormat withXXX methods using a new constructor 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] kyohei-nakamura commented on a change in pull request #40: Add Evictor threads test code.
kyohei-nakamura commented on a change in pull request #40:
URL: https://github.com/apache/commons-dbcp/pull/40#discussion_r429753652
##
File path: src/test/java/org/apache/commons/dbcp2/TestBasicDataSource.java
##
@@ -916,6 +917,34 @@ public void testCreateConnectionFactory() throws Exception
{
conn.close();
ds.close();
}
+
+@Test
+public void testEvict() throws Exception {
+ds.setInitialSize(10);
+ds.setMaxIdle(10);
+ds.setMaxTotal(10);
+ds.setMinIdle(5);
+ds.setNumTestsPerEvictionRun(3);
+ds.setMinEvictableIdleTimeMillis(100);
+ds.setTimeBetweenEvictionRunsMillis(1000);
+ds.setPoolPreparedStatements(true);
+
+Connection conn = ds.getConnection();
+conn.close();
+
+ThreadMXBean threadBean = ManagementFactory.getThreadMXBean();
+while
(Arrays.stream(threadBean.getThreadInfo(threadBean.getAllThreadIds()))
+.anyMatch(t ->
t.getThreadName().equals("commons-pool-evictor-thread"))) {
+if (ds.getNumIdle() <= ds.getMinIdle()) {
+break;
+}
+Thread.sleep(1000);
Review comment:
Thanks for your comment.
The Evictor thread runs with a delay of the value of
timeBetweenEvictionRunsMillis.
I think that the sleep time of the main thread should refer to that value.
I have fixed 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
[jira] [Work logged] (LANG-1546) change to
[ https://issues.apache.org/jira/browse/LANG-1546?focusedWorklogId=437051=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-437051 ] ASF GitHub Bot logged work on LANG-1546: Author: ASF GitHub Bot Created on: 25/May/20 06:21 Start Date: 25/May/20 06:21 Worklog Time Spent: 10m Work Description: XenoAmess edited a comment on pull request #428: URL: https://github.com/apache/commons-lang/pull/428#issuecomment-633216222 @kinow @michael-o @garydgregory , anything we can do to get this moving? 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: 437051) Remaining Estimate: 0h Time Spent: 10m > change to > -- > > Key: LANG-1546 > URL: https://issues.apache.org/jira/browse/LANG-1546 > Project: Commons Lang > Issue Type: Bug >Reporter: JIN XU >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > [https://github.com/apache/commons-lang/pull/428] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-lang] XenoAmess edited a comment on pull request #428: [LANG-1546] change to
XenoAmess edited a comment on pull request #428: URL: https://github.com/apache/commons-lang/pull/428#issuecomment-633216222 @kinow @michael-o @garydgregory , anything we can do to get this moving? 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] XenoAmess edited a comment on pull request #115: fix code smells
XenoAmess edited a comment on pull request #115: URL: https://github.com/apache/commons-io/pull/115#issuecomment-633359016 > > Also, in function NullPrintStreamTest.process(final NullPrintStream nos), > > We use function void PrintStream.write(byte buf[]), which is @SInCE 14 > > Should we really use a java 14 function in a java 8 project? > > And is it neccessary? > > I just started a release candidate for 2.7 so this will have to wait until another RC if something goes wrong or more likely the next release. OK, none of them is bugfix nor other important things so you can review/merge it anytime you want sooner or later. > The API you refer to is defined in Java 8 as `java.io.FilterOutputStream.write(byte[])`. I will find some time to test if j2se8 can run jdk14's compile output NullPrintStreamTest classfile. update: OK it can work on jdk8. no change needed. 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
