[GitHub] [commons-daemon] wzssyqa opened a new pull request #10: apsupport.m4: improve mips detect
wzssyqa opened a new pull request #10: apsupport.m4: improve mips detect
URL: https://github.com/apache/commons-daemon/pull/10
For mips, we add some new CPU types: mipsisa64r6{,el}, mipsisa32r6{,el}.
To add support of them and don't make the list too long,
we detect mips*el and then mips*.
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
With regards,
Apache Git Services
[jira] [Commented] (GEOMETRY-32) BSPTree Updates
[
https://issues.apache.org/jira/browse/GEOMETRY-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855285#comment-16855285
]
Matt Juntunen commented on GEOMETRY-32:
---
Update:
Still working on this. I'm currently almost done with the Euclidean 2D classes.
I've created the new types {{LineSegment}}, {{LineSegmentPath}},
{{LineSegmentConnector}} (and subclasses), {{SubLine}}, and
{{RegionBSPTree2D}}. I'm currently working on finishing up the geometric
property calculations for {{RegionBSPTree2D}} and handling several edge cases.
I still have yet to do the Euclidean 3D classes as well as Spherical 1D and 2D
before I can remove the old BSP tree classes. If someone wants to follow the
pattern I've done for Euclidean 1D and 2D and apply it to the spherical
packages, that would be a big help.
> BSPTree Updates
> ---
>
> Key: GEOMETRY-32
> URL: https://issues.apache.org/jira/browse/GEOMETRY-32
> Project: Apache Commons Geometry
> Issue Type: Improvement
> Components: core
>Reporter: Matt Juntunen
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The following updates should be made to the BSPTree class:
> - add an {{isLeaf()}} method to replace all of the {{node.getCut() == null}}
> expressions
> - add unit tests
> _Edit [2019-02-17]:_
> Additional goals:
> - Refactor the API to split the idea of a general BSPTree and a BSPTree used
> for defining in/out regions. This could result in a BSPTree interface and a
> RegionBSPTree interface. The goal here is to allow end-users to create their
> own extensions of these classes and specialize them for their own
> applications (for example, to implement spatial sorting or other algorithms).
> This will be one of the only planned extension points in the library.
> - Make the API easier to use and extend and reduce the necessity of casting
> (especially unchecked casting) as much as possible.
> - Add the idea of convex subhyperplanes to allow for more efficient tree
> construction.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (NUMBERS-104) Speed up trial division
[
https://issues.apache.org/jira/browse/NUMBERS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855187#comment-16855187
]
Heinrich Bohne edited comment on NUMBERS-104 at 6/4/19 2:06 AM:
OK, done. The last {{if (n != 1)}} condition is still not fully covered, but
this is because {{n != 1}} will only evaluate to false here if, all other
conditions the method's contract imposes being fulfilled, the method is called
with an unnecessarily high value for the parameter {{maxFactor}}, or, more
specifically, if the parameter {{maxFactor}} is greater than or equal to the
parameter {{n}}, which is an indication of a design flaw of the method itself
rather than the unit tests, and this design flaw is outside the scope of this
ticket.
was (Author: schamschi):
OK, done. The last {{if (n != 1)}} condition is still not fully covered, but
this is because {{n != 1}} will only evaluate to false here if, all other
conditions the method's contract imposes being fulfilled, the method is called
with an unnecessarily high value for the parameter {{maxFactor}}, or, more
specifically, if the parameters {{maxFactor}} and {{n}} are identical, which is
an indication of a design flaw of the method itself rather than the unit tests,
and this design flaw is outside the scope of this ticket.
> Speed up trial division
> ---
>
> Key: NUMBERS-104
> URL: https://issues.apache.org/jira/browse/NUMBERS-104
> Project: Commons Numbers
> Issue Type: Improvement
> Components: primes
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, the method {{SmallPrimes.boundedTrialDivision(int, int,
> List)}} skips multiples of 2 and 3, thereby reducing the amount of
> integers to be tried to 1/3 of all integers. This can be improved at the cost
> of extra memory by extending the set of prime factors to be skipped in the
> trial division, for example, to 2, 3, 5, 7, and 11.
> However, instead of code duplication, which is the way the code currently
> achieves this, a way to implement this could be:
> * First, precompute and store all integers between 0 (inclusive) and
> 2⋅3⋅5⋅7⋅11=2310 (exclusive) that are not divisible by any of those 5 prime
> numbers (480 numbers in total, according to my experiments).
> * Then, when performing the trial division, one only needs to try out numbers
> of the form 2310⋅k + c, where k is a non-negative integer and c is one of the
> 480 numbers described in the previous step.
> That way, the amount of integers to be tried will be 480/2310 ≈ 20.78%,
> instead of 1/3 ≈ 33.33%, which is a speedup of about 60.42% compared to the
> current algorithm. Of course, with more prime factors eliminated, less
> numbers will have to be tried, but it seems that the returns are quickly
> diminishing compared to the required memory. For example, when also
> eliminating the prime factors 13, 17 and 19, the memory required increases to
> 1658880 integers, whereas the percentage of integers to be tried only drops
> to about 17.10%.
> Since the class {{SmallPrimes}} already stores an array containing the first
> 512 prime numbers, a 480-element {{int}} array seems like a reasonable size
> and a small price to pay for a 60.42% speedup.
> I'm just not entirely sure whether this should go here or on the developer
> mailing list. Since this is actually not a new idea, but just an enhancement
> of an already existing idea, I'm putting it here, but on the other hand, it
> requires some re-writing and some new code, so maybe I'm wrong.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (NUMBERS-112) Port "BrentSolver" from "Commons Math"
Gilles created NUMBERS-112: -- Summary: Port "BrentSolver" from "Commons Math" Key: NUMBERS-112 URL: https://issues.apache.org/jira/browse/NUMBERS-112 Project: Commons Numbers Issue Type: Task Reporter: Gilles Assignee: Gilles Fix For: 1.0 Efficient algorithm for finding the root of a function (it is used within "Commons Statistics"). See proposal on the ["dev" ML|https://markmail.org/message/44w75iq5vyfiwmle]. The relatively deep hierarchy of the "Commons Math" design will not be ported. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (NUMBERS-104) Speed up trial division
[
https://issues.apache.org/jira/browse/NUMBERS-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855187#comment-16855187
]
Heinrich Bohne commented on NUMBERS-104:
OK, done. The last {{if (n != 1)}} condition is still not fully covered, but
this is because {{n != 1}} will only evaluate to false here if, all other
conditions the method's contract imposes being fulfilled, the method is called
with an unnecessarily high value for the parameter {{maxFactor}}, or, more
specifically, if the parameters {{maxFactor}} and {{n}} are identical, which is
an indication of a design flaw of the method itself rather than the unit tests,
and this design flaw is outside the scope of this ticket.
> Speed up trial division
> ---
>
> Key: NUMBERS-104
> URL: https://issues.apache.org/jira/browse/NUMBERS-104
> Project: Commons Numbers
> Issue Type: Improvement
> Components: primes
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, the method {{SmallPrimes.boundedTrialDivision(int, int,
> List)}} skips multiples of 2 and 3, thereby reducing the amount of
> integers to be tried to 1/3 of all integers. This can be improved at the cost
> of extra memory by extending the set of prime factors to be skipped in the
> trial division, for example, to 2, 3, 5, 7, and 11.
> However, instead of code duplication, which is the way the code currently
> achieves this, a way to implement this could be:
> * First, precompute and store all integers between 0 (inclusive) and
> 2⋅3⋅5⋅7⋅11=2310 (exclusive) that are not divisible by any of those 5 prime
> numbers (480 numbers in total, according to my experiments).
> * Then, when performing the trial division, one only needs to try out numbers
> of the form 2310⋅k + c, where k is a non-negative integer and c is one of the
> 480 numbers described in the previous step.
> That way, the amount of integers to be tried will be 480/2310 ≈ 20.78%,
> instead of 1/3 ≈ 33.33%, which is a speedup of about 60.42% compared to the
> current algorithm. Of course, with more prime factors eliminated, less
> numbers will have to be tried, but it seems that the returns are quickly
> diminishing compared to the required memory. For example, when also
> eliminating the prime factors 13, 17 and 19, the memory required increases to
> 1658880 integers, whereas the percentage of integers to be tried only drops
> to about 17.10%.
> Since the class {{SmallPrimes}} already stores an array containing the first
> 512 prime numbers, a 480-element {{int}} array seems like a reasonable size
> and a small price to pay for a 60.42% speedup.
> I'm just not entirely sure whether this should go here or on the developer
> mailing list. Since this is actually not a new idea, but just an enhancement
> of an already existing idea, I'm putting it here, but on the other hand, it
> requires some re-writing and some new code, so maybe I'm wrong.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (NUMBERS-104) Speed up trial division
[
https://issues.apache.org/jira/browse/NUMBERS-104?focusedWorklogId=253478=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-253478
]
ASF GitHub Bot logged work on NUMBERS-104:
--
Author: ASF GitHub Bot
Created on: 04/Jun/19 00:58
Start Date: 04/Jun/19 00:58
Worklog Time Spent: 10m
Work Description: coveralls commented on issue #46: NUMBERS-104: Speed up
trial division
URL: https://github.com/apache/commons-numbers/pull/46#issuecomment-497873456
[](https://coveralls.io/builds/23771969)
Coverage increased (+0.2%) to 93.642% when pulling
**7b15fad6c3eeece124f635b7a5c2fd72443f2017 on Schamschi:NUMBERS-104** into
**daac9ac15f6161b32fa4c1374c2d6b563c90af87 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: 253478)
Time Spent: 0.5h (was: 20m)
> Speed up trial division
> ---
>
> Key: NUMBERS-104
> URL: https://issues.apache.org/jira/browse/NUMBERS-104
> Project: Commons Numbers
> Issue Type: Improvement
> Components: primes
>Reporter: Heinrich Bohne
>Priority: Minor
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Currently, the method {{SmallPrimes.boundedTrialDivision(int, int,
> List)}} skips multiples of 2 and 3, thereby reducing the amount of
> integers to be tried to 1/3 of all integers. This can be improved at the cost
> of extra memory by extending the set of prime factors to be skipped in the
> trial division, for example, to 2, 3, 5, 7, and 11.
> However, instead of code duplication, which is the way the code currently
> achieves this, a way to implement this could be:
> * First, precompute and store all integers between 0 (inclusive) and
> 2⋅3⋅5⋅7⋅11=2310 (exclusive) that are not divisible by any of those 5 prime
> numbers (480 numbers in total, according to my experiments).
> * Then, when performing the trial division, one only needs to try out numbers
> of the form 2310⋅k + c, where k is a non-negative integer and c is one of the
> 480 numbers described in the previous step.
> That way, the amount of integers to be tried will be 480/2310 ≈ 20.78%,
> instead of 1/3 ≈ 33.33%, which is a speedup of about 60.42% compared to the
> current algorithm. Of course, with more prime factors eliminated, less
> numbers will have to be tried, but it seems that the returns are quickly
> diminishing compared to the required memory. For example, when also
> eliminating the prime factors 13, 17 and 19, the memory required increases to
> 1658880 integers, whereas the percentage of integers to be tried only drops
> to about 17.10%.
> Since the class {{SmallPrimes}} already stores an array containing the first
> 512 prime numbers, a 480-element {{int}} array seems like a reasonable size
> and a small price to pay for a 60.42% speedup.
> I'm just not entirely sure whether this should go here or on the developer
> mailing list. Since this is actually not a new idea, but just an enhancement
> of an already existing idea, I'm putting it here, but on the other hand, it
> requires some re-writing and some new code, so maybe I'm wrong.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-numbers] coveralls edited a comment on issue #46: NUMBERS-104: Speed up trial division
coveralls edited a comment on issue #46: NUMBERS-104: Speed up trial division URL: https://github.com/apache/commons-numbers/pull/46#issuecomment-497873456 [](https://coveralls.io/builds/23771969) Coverage increased (+0.2%) to 93.642% when pulling **7b15fad6c3eeece124f635b7a5c2fd72443f2017 on Schamschi:NUMBERS-104** into **daac9ac15f6161b32fa4c1374c2d6b563c90af87 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 With regards, Apache Git Services
[jira] [Commented] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[
https://issues.apache.org/jira/browse/IMAGING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855177#comment-16855177
]
Gilles commented on IMAGING-228:
{quote}For maintainability - for now.
{quote}
I just wanted to point out that the Math method takes 2 {{double}} as arguments.
IMO, it is easier to keep track of the specific needs with private methods
like "cube" and "square". But I won't dispute more how you want to manage the
improvement of that codebase.
{quote}commons-math had some sort of optimized math methods
{quote}
Yes. Some of the methods in {{FastMath}} were faster than their counterpart in
the JDK, but some were slower. There is an old JIRA about this. Also, several
Java releases have happened since then, and I'd be surprised if the JVM hadn't
caught up (this could be checked with JMH). The main advantage of {{FastMath}}
was the improved accuracy (but, again, this advantage may have dwindled in more
recent JVMs). Unless there is some follow-up on the findings reported in the
JIRA issue, I wouldn't recommend coding against {{FastMath}} (it's the reason
it is not part on the new math-related components).
> Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
> ---
>
> Key: IMAGING-228
> URL: https://issues.apache.org/jira/browse/IMAGING-228
> Project: Commons Imaging
> Issue Type: Improvement
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.0-alpha2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a private method in PhotometricInterpreterLogLuv, that calculates the
> cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3).
> Will add unit tests and some javadocs around photometric interpreters,
> logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[
https://issues.apache.org/jira/browse/IMAGING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855122#comment-16855122
]
Bruno P. Kinoshita edited comment on IMAGING-228 at 6/3/19 10:44 PM:
-
Hi [~erans]
Glad I created a PR and this issue instead of committing directly, some review
& feedback is always appreciated.
>Why would you do that?
For maintainability - for now.
>Just saw the commit on GitHub: The original code is how I would have done it.
>;) Intuitively, I'd bet that the call to {{Math.pow}} is slower...
Agree, even if a few ms or ns, this is probably some performance users would
appreciate, as parsing images is not always the fastest operation. But at the
moment the old code base needs some polishing, and IMO it could do with
simplification list this, even at cost of performance.
This `#cube` method, for example, is not the only one in Imaging. There's
another one in
[ColorConversion|[https://github.com/apache/commons-imaging/blob/eb98398bd111cdc35b2c9a5fc8022a28d7c99035/src/main/java/org/apache/commons/imaging/color/ColorConversions.java#L536].]
ColorConversion has also a `#square` method. And even though it has a `#cube`
method, there is a `Math(var_Y, 3)` there too.
We could create some sort of utility class to accommodate these methods. But I
would prefer doing this later, in the whole project, and considering whether
this should be maintained here or if there are libraries out there that could
help us (e.g. I remember commons-math had some sort of optimized math methods,
that could outperform the ones from JDK?).
What do you think?
was (Author: kinow):
Hi [~erans]
Glad I created a PR and this issue instead of committing directly, some review
& feedback is always appreciated.
>Why would you do that?
For maintainability - for now.
>Just saw the commit on GitHub: The original code is how I would have done it.
>;) Intuitively, I'd bet that the call to {{Math.pow}} is slower...
Agree, even if a few ms or ns, this is probably some performance users would
appreciate, as parsing images is not always the fastest operation. But at the
moment the old code base needs some polishing, and IMO it could do with
simplification list this, even at cost of performance.
This `#cube` method, for example, is not the only one in Imaging. There's
another one in
[ColorConversion|[https://github.com/apache/commons-imaging/blob/eb98398bd111cdc35b2c9a5fc8022a28d7c99035/src/main/java/org/apache/commons/imaging/color/ColorConversions.java#L536].]
ColorConversion has also a `#square` method.
We would either have to maintain both, or start creating some sort of utility
class to accommodate these methods. And I would prefer doing this later, in the
whole project, and considering whether this should be maintained here or if
there are libraries out there that could help us (e.g. I remember commons-math
had some sort of optimized math methods, that could outperform the ones from
JDK?).
So my plan is to use Math methods for now, then revisit performance later in
another ticket, and try to do it right across the whole project. What do you
think?
> Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
> ---
>
> Key: IMAGING-228
> URL: https://issues.apache.org/jira/browse/IMAGING-228
> Project: Commons Imaging
> Issue Type: Improvement
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.0-alpha2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a private method in PhotometricInterpreterLogLuv, that calculates the
> cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3).
> Will add unit tests and some javadocs around photometric interpreters,
> logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[
https://issues.apache.org/jira/browse/IMAGING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855122#comment-16855122
]
Bruno P. Kinoshita edited comment on IMAGING-228 at 6/3/19 10:42 PM:
-
Hi [~erans]
Glad I created a PR and this issue instead of committing directly, some review
& feedback is always appreciated.
>Why would you do that?
For maintainability - for now.
>Just saw the commit on GitHub: The original code is how I would have done it.
>;) Intuitively, I'd bet that the call to {{Math.pow}} is slower...
Agree, even if a few ms or ns, this is probably some performance users would
appreciate, as parsing images is not always the fastest operation. But at the
moment the old code base needs some polishing, and IMO it could do with
simplification list this, even at cost of performance.
This `#cube` method, for example, is not the only one in Imaging. There's
another one in
[ColorConversion|[https://github.com/apache/commons-imaging/blob/eb98398bd111cdc35b2c9a5fc8022a28d7c99035/src/main/java/org/apache/commons/imaging/color/ColorConversions.java#L536].]
ColorConversion has also a `#square` method.
But if you look at ColorConversion, even though it has a `#cube` method, it
also uses Math.pow(N, 3).
We would either have to maintain both, or start creating some sort of utility
class to accommodate these methods. And I would prefer doing this later, in the
whole project, and considering whether this should be maintained here or if
there are libraries out there that could help us (e.g. I remember commons-math
had some sort of optimized math methods, that could outperform the ones from
JDK?).
So my plan is to use Math methods for now, then revisit performance later in
another ticket, and try to do it right across the whole project. What do you
think?
was (Author: kinow):
Hi [~erans]
Glad I created a PR and this issue instead of committing directly, some review
& feedback is always appreciated.
>Why would you do that?
For maintainability - for now.
>Just saw the commit on GitHub: The original code is how I would have done it.
>;) Intuitively, I'd bet that the call to {{Math.pow}} is slower...
Agree, even if a few ms or ns, this is probably some performance users would
appreciate, as parsing images is not always the fastest operation. But at the
moment the old code base needs some polishing, and IMO it could do with
simplification list this, even at cost of performance.
This `#cube` method, for example, is not the only one in Imaging. There's
another one in
[ColorConversion|[https://github.com/apache/commons-imaging/blob/eb98398bd111cdc35b2c9a5fc8022a28d7c99035/src/main/java/org/apache/commons/imaging/color/ColorConversions.java#L536].]
ColorConversion has also a `#square` method.
But if you look at ColorConversion, even though it has a `#cube` method, it
also uses Math.pow(N, 3). And even though it has `#cube` it also uses Math.sqrt.
We would either have to maintain both, or start creating some sort of utility
class to accommodate these methods. And I would prefer doing this later, in the
whole project, and considering whether this should be maintained here or if
there are libraries out there that could help us (e.g. I remember commons-math
had some sort of optimized math methods, that could outperform the ones from
JDK?).
So my plan is to use Math methods for now, then revisit performance later in
another ticket, and try to do it right across the whole project. What do you
think?
> Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
> ---
>
> Key: IMAGING-228
> URL: https://issues.apache.org/jira/browse/IMAGING-228
> Project: Commons Imaging
> Issue Type: Improvement
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.0-alpha2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a private method in PhotometricInterpreterLogLuv, that calculates the
> cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3).
> Will add unit tests and some javadocs around photometric interpreters,
> logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[
https://issues.apache.org/jira/browse/IMAGING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855122#comment-16855122
]
Bruno P. Kinoshita commented on IMAGING-228:
Hi [~erans]
Glad I created a PR and this issue instead of committing directly, some review
& feedback is always appreciated.
>Why would you do that?
For maintainability - for now.
>Just saw the commit on GitHub: The original code is how I would have done it.
>;) Intuitively, I'd bet that the call to {{Math.pow}} is slower...
Agree, even if a few ms or ns, this is probably some performance users would
appreciate, as parsing images is not always the fastest operation. But at the
moment the old code base needs some polishing, and IMO it could do with
simplification list this, even at cost of performance.
This `#cube` method, for example, is not the only one in Imaging. There's
another one in
[ColorConversion|[https://github.com/apache/commons-imaging/blob/eb98398bd111cdc35b2c9a5fc8022a28d7c99035/src/main/java/org/apache/commons/imaging/color/ColorConversions.java#L536].]
ColorConversion has also a `#square` method.
But if you look at ColorConversion, even though it has a `#cube` method, it
also uses Math.pow(N, 3). And even though it has `#cube` it also uses Math.sqrt.
We would either have to maintain both, or start creating some sort of utility
class to accommodate these methods. And I would prefer doing this later, in the
whole project, and considering whether this should be maintained here or if
there are libraries out there that could help us (e.g. I remember commons-math
had some sort of optimized math methods, that could outperform the ones from
JDK?).
So my plan is to use Math methods for now, then revisit performance later in
another ticket, and try to do it right across the whole project. What do you
think?
> Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
> ---
>
> Key: IMAGING-228
> URL: https://issues.apache.org/jira/browse/IMAGING-228
> Project: Commons Imaging
> Issue Type: Improvement
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.0-alpha2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a private method in PhotometricInterpreterLogLuv, that calculates the
> cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3).
> Will add unit tests and some javadocs around photometric interpreters,
> logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-75) Improve the speed of the RandomSource create method.
[ https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855087#comment-16855087 ] Alex D Herbert commented on RNG-75: --- Here is the data comparing the construction through the factory with construction using the *new* keyword. *With a pre-build seed*: |RNG|createNativeSeed|new + NativeSeed|Relative|Seed size|Seed type| |SPLIT_MIX_64|10.555|2.725|3.874|1|long| |XO_RO_SHI_RO_64_SS|11.410|2.772|4.116|2|int| |XO_RO_SHI_RO_64_S|11.430|2.778|4.114|2|int| |XO_SHI_RO_128_SS|12.175|3.759|3.239|4|int| |XO_RO_SHI_RO_128_SS|12.216|3.939|3.101|2|long| |XO_RO_SHI_RO_128_PLUS|12.347|4.069|3.034|2|long| |XO_SHI_RO_128_PLUS|12.147|4.796|2.533|4|int| |XO_SHI_RO_256_PLUS|13.326|5.815|2.292|4|long| |XO_SHI_RO_256_SS|13.363|5.946|2.247|4|long| |KISS|23.082|9.233|2.500|4|int| |XO_SHI_RO_512_PLUS|18.215|10.172|1.791|8|long| |XO_SHI_RO_512_SS|18.595|10.731|1.733|8|long| |JDK|24.610|12.654|1.945|1|long| |WELL_512_A|26.347|13.353|1.973|16|int| |WELL_1024_A|34.587|20.974|1.649|32|int| |XOR_SHIFT_1024_S_PHI|36.171|21.823|1.657|16|long| |XOR_SHIFT_1024_S|36.644|21.901|1.673|16|long| |WELL_19937_A|335.859|310.806|1.081|624|int| |WELL_19937_C|332.835|313.929|1.060|624|int| |MWC_256|322.355|325.020|0.992|257|int| |WELL_44497_A|638.771|618.200|1.033|1391|int| |WELL_44497_B|645.603|629.002|1.026|1391|int| |ISAAC|1835.391|1838.906|0.998|256|int| |MT_64|5179.458|5160.515|1.004|312|long| |MT|8644.216|8729.320|0.990|624|int| |TWO_CMRES|149571.119|100527.616|1.488|1|int| The TWO_CMRES data is an anomaly. The time to build the RNG is very large. The time for the constructor invocation should not matter. This should be investigated as using *new* here is the biggest benefit in the table. However the units are ns so this is a difference of .5 milliseconds in practice. For the rest of the generators the cost of the factory method is progressively swamped by the rest of the work to make the generator as the seed gets larger. Using the *new* keyword is only relatively noticeable for very small seeds when the RNG has no extra work in the constructor. In practice this will not be noticed since it would require creating thousands of short lifetime generators with simple pre-built seeds. *With seed built using the SeedFactory*. I only include those with small seeds as I do not have data for seeds larger than 128: |RNG|createNullSeed|new + SeedFactory|Relative|Seed size|Seed type| |SPLIT_MIX_64|85.635|58.978|1.452|1|long| |XO_RO_SHI_RO_64_SS|81.631|64.035|1.275|2|int| |XO_RO_SHI_RO_64_S|85.723|64.042|1.339|2|int| |JDK|95.676|68.908|1.388|1|long| |XO_SHI_RO_128_SS|104.708|82.973|1.262|4|int| |XO_SHI_RO_128_PLUS|103.972|84.010|1.238|4|int| |XO_RO_SHI_RO_128_SS|117.396|85.957|1.366|2|long| |XO_RO_SHI_RO_128_PLUS|110.042|86.088|1.278|2|long| |KISS|112.247|88.447|1.269|4|int| |XO_SHI_RO_256_PLUS|150.657|109.504|1.376|4|long| |XO_SHI_RO_256_SS|141.544|115.450|1.226|4|long| |WELL_512_A|254.421|179.110|1.420|16|int| |XO_SHI_RO_512_PLUS|217.515|186.256|1.168|8|long| |XO_SHI_RO_512_SS|217.241|186.816|1.163|8|long| |XOR_SHIFT_1024_S_PHI|372.309|330.121|1.128|16|long| |XOR_SHIFT_1024_S|368.234|330.200|1.115|16|long| |WELL_1024_A|596.979|352.489|1.694|32|int| |TWO_CMRES|149183.341|100574.526|1.483|1|int| WELL_1024_A is an outlier. The rest of the generators all are built in comparable time to using the *new* keyword. Comparison of the tables show that generating the seed takes the majority of time for construction of a generator. For the normal use case of a long-lived generator then construction cost is not a factor on run-time. If a use case is for a generator that is very short lived (<100 deviates) and then discarded where speed is a priority then the recommendation is to create using the *new* keyword a small state generator and build the state using a fast thread-safe method to create a seed. A separate Jira ticket will discuss options for adding such a method to the SeedFactory. The fastest generator to create is the SplitMix. There is a Jira ticket to add a primitive constructor to this generator RNG-76 which shows that auto-boxing is a significant part of construction. The other generators with small state have array seeds or constructors with primitive arguments so auto-boxing is not a factor. Alternatively ThreadLocalRandom from JDK 1.7 would fit this use case ideally as it is designed for this purpose. It does not implement UniformRandomProvider so would have to be wrapped to be used with anything requiring that interface. > Improve the speed of the RandomSource create method. > > > Key: RNG-75 > URL: https://issues.apache.org/jira/browse/RNG-75 > Project: Commons RNG > Issue Type: Improvement > Components: simple >Affects Versions: 1.3 >Reporter: Alex D Herbert >
[jira] [Commented] (CSV-240) Links for JavaDoc broken on web site
[ https://issues.apache.org/jira/browse/CSV-240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16855046#comment-16855046 ] Gary Gregory commented on CSV-240: -- This will be fixed in the upcoming release; for a preview please see https://dist.apache.org/repos/dist/dev/commons/csv/1.7-RC1/site/index.html > Links for JavaDoc broken on web site > > > Key: CSV-240 > URL: https://issues.apache.org/jira/browse/CSV-240 > Project: Commons CSV > Issue Type: Bug > Components: Documentation >Affects Versions: 1.6 >Reporter: Basil >Priority: Minor > > The sidebar on the left of this page: > [https://commons.apache.org/proper/commons-csv/] > …has items for `Javadoc 1.6`, `Javadoc 1.5`, and so on. The main body of the > page has the same. All of these links for the numbered versions of `Javadoc` > are broken, resulting in a `Not Found` error page. > For example, one such broken link: > [https://commons.apache.org/proper/commons-csv/archives/1.6/apidocs/index.html] > The only Javadoc link that works is `Javadoc Trunk`, but that is for the > forthcoming release, not the current release. > https://commons.apache.org/proper/commons-csv/apidocs/index.html > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-rng] coveralls edited a comment on issue #46: Update ProviderBuilder factory methods
coveralls edited a comment on issue #46: Update ProviderBuilder factory methods URL: https://github.com/apache/commons-rng/pull/46#issuecomment-498219127 [](https://coveralls.io/builds/23764252) Coverage increased (+0.06%) to 98.811% when pulling **45d73f54086c15d391938ae171d31b4c371194cc on aherbert:improvement-RNG-75** into **0bda14cc5fc04155f8d1d2c4eeb8d1e1dd6160a3 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 With regards, Apache Git Services
[GitHub] [commons-lang] XenoAmess opened a new pull request #429: ArrayUtils: merge 8 isSameLength, isEmpty, isNotEmpty into one function each.
XenoAmess opened a new pull request #429: ArrayUtils: merge 8 isSameLength,isEmpty,isNotEmpty into one function each. URL: https://github.com/apache/commons-lang/pull/429 There are 8 isSameLength,8 isEmpty,8 isNotEmpty in ArrayUtils, but only one getLength function. That is somehow weird, and breaks compatibility. And also, if we make such change, we can apply isSameLength upon different kind of arrays. Otherwise, we shall make functions like getLength be 8 functions to keep compatibility in my opinion. 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 With regards, Apache Git Services
[jira] [Updated] (BCEL-317) Pluggable cache for ConstantUtf8
[
https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-317:
-
Description:
Follow-up of BCEL-186. This enhancement is to provide an option to cache
ConstantUtf8 instances that have the same value.
Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass
instances
We use BCEL library to inspect Java class. Thank you for the great library.
When our tool checks classes in ~200 jar files, it creates more than 2 million
BCEL ConstantUtf8 instances. I suspect many of them share the same values such
as "java.lang.String".
Without cache, my tool created 2,6 million ConstantUtf8 instances (before
failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files.
!2644k_constantutf8_without_getCachedInstance.png!
With the cache, my tool created just 0.6 million ConstantUtf8 instances. It
didn't throw the OutOfMemoryError.
!621k_constantutf8_with_getCachedInstance.png!
Old commit that made ConstantUtf8.getInstance
[https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383=1481382=1481383]
The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186
[http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541=1652540=1652541]
h1. How our project uses BCEL
- Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around
200 JAR files as its input class path in
ClassDumper.createClassRepository([source code
URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83])
{code:java}
private static Repository createClassRepository(List paths) {
ClassPath classPath = new LinkageCheckClassPath(paths);
return new ClassPathRepository(classPath); # This is BCEL API
}{code}
- reads JavaClasses one by one in ClassDumper.listClassesInJar ([source code
URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360])
through the ClassPathRepository.
{code:java}
private ImmutableSet listClassesInJar(Path jar) throws IOException
{
ImmutableSet.Builder javaClasses = ImmutableSet.builder();
for (String className : listClassNamesInJar(jar)) {
try {
JavaClass javaClass = classRepository.loadClass(className); # This is
BCEL API. ConstantUtf8 is not cached.
javaClasses.add(javaClass);
...(omit)
return javaClasses.build();
}{code}
Stacktrace from the ClassDumper.listClassesInJar to BCEL's
ConstantUtf8.getInstance would look like this:
{code:java}
ConstantUtf8.getInstance
Constant.readConstant
ConstantPool.
ClassParser.readConstantPool
ClassParser.parse
ClassPathRepository.loadClass
ClassPathRepository.loadClass
ClassDumper.listClassesInJar {code}
- Use the JavaClass instances to check if any symbol references (entries in
constant pool [Java Virtual Machine Specification 4.4. The Constant
Pool|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4]:
CONSTANT_Class, CONSTANT_Fieldref, CONSTANT_Methodref, and
CONSTANT_InterfaceMethodref) has invalid referent in the class path.
was:
Follow-up of BCEL-186. This enhancement is to provide an option to cache
ConstantUtf8 instances that have the same value.
Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass
instances
We use BCEL library to inspect Java class. Thank you for the great library.
When our tool checks classes in ~200 jar files, it creates more than 2 million
BCEL ConstantUtf8 instances. I suspect many of them share the same values such
as "java.lang.String".
Without cache, my tool created 2,6 million ConstantUtf8 instances (before
failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files.
!2644k_constantutf8_without_getCachedInstance.png!
With the cache, my tool created just 0.6 million ConstantUtf8 instances. It
didn't throw the OutOfMemoryError.
!621k_constantutf8_with_getCachedInstance.png!
Old commit that made ConstantUtf8.getInstance
[https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383=1481382=1481383]
The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186
[http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541=1652540=1652541]
h1. How our project uses BCEL
- Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around
200 JAR files as its input class path in
[jira] [Closed] (LANG-1461) Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
[
https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory closed LANG-1461.
--
Resolution: Fixed
In git master.
> Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
>
>
> Key: LANG-1461
> URL: https://issues.apache.org/jira/browse/LANG-1461
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.10
>
>
> Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
> * {{StringUtills#getBytes(String, Charset)}}
> * {{StringUtills#getBytes(String, String)}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-rng] coveralls edited a comment on issue #46: Update ProviderBuilder factory methods
coveralls edited a comment on issue #46: Update ProviderBuilder factory methods URL: https://github.com/apache/commons-rng/pull/46#issuecomment-498219127 [](https://coveralls.io/builds/23761654) Coverage increased (+0.06%) to 98.811% when pulling **a9d507c0335adc8d7cb3549cbc551214eb414334 on aherbert:improvement-RNG-75** into **0bda14cc5fc04155f8d1d2c4eeb8d1e1dd6160a3 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 With regards, Apache Git Services
[jira] [Updated] (LANG-1461) Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
[
https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LANG-1461:
---
Description:
Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
* {{StringUtills#getBytes(String, Charset)}}
* {{StringUtills#getBytes(String, String)}}
was:
Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
* {{StringUtills#getBytes(String, Charset)}}
* {{StringUtills#getBytes(String, String)}}
Also adds the following used by the above:
* {{CharSetUtils.defaultCharset(Charset)}}
* {{CharSetUtils.defaultCharset(String)}}
> Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
>
>
> Key: LANG-1461
> URL: https://issues.apache.org/jira/browse/LANG-1461
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.10
>
>
> Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
> * {{StringUtills#getBytes(String, Charset)}}
> * {{StringUtills#getBytes(String, String)}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BCEL-317) Pluggable cache for ConstantUtf8
[
https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854715#comment-16854715
]
Tomo Suzuki commented on BCEL-317:
--
Hi [~ggregory],
I've enriched the "How our project uses BCEL" section in this ticket. I hope it
answers your question but I'm happy to answer more detail.
I also created another PR to reflect your feedback: PR
[27|https://github.com/apache/commons-bcel/pull/27]: Constant to switch
ConstantUtf8.getInstance or getCachedInstance.
> Pluggable cache for ConstantUtf8
>
>
> Key: BCEL-317
> URL: https://issues.apache.org/jira/browse/BCEL-317
> Project: Commons BCEL
> Issue Type: Improvement
> Components: Main
>Affects Versions: 6.3.1
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: 2644k_constantutf8_without_getCachedInstance.png,
> 621k_constantutf8_with_getCachedInstance.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Follow-up of BCEL-186. This enhancement is to provide an option to cache
> ConstantUtf8 instances that have the same value.
>
> Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass
> instances
>
> We use BCEL library to inspect Java class. Thank you for the great library.
>
> When our tool checks classes in ~200 jar files, it creates more than 2
> million BCEL ConstantUtf8 instances. I suspect many of them share the same
> values such as "java.lang.String".
>
> Without cache, my tool created 2,6 million ConstantUtf8 instances (before
> failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files.
> !2644k_constantutf8_without_getCachedInstance.png!
>
> With the cache, my tool created just 0.6 million ConstantUtf8 instances. It
> didn't throw the OutOfMemoryError.
> !621k_constantutf8_with_getCachedInstance.png!
>
> Old commit that made ConstantUtf8.getInstance
> [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383=1481382=1481383]
> The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186
> [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541=1652540=1652541]
>
> h1. How our project uses BCEL
> - Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around
> 200 JAR files as its input class path in
> ClassDumper.createClassRepository([source code
> URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83])
> {code:java}
> private static Repository createClassRepository(List paths) {
> ClassPath classPath = new LinkageCheckClassPath(paths);
> return new ClassPathRepository(classPath); # This is BCEL API
> }
> {code}
> - reads JavaClasses one by one in ClassDumper.listClassesInJar ([source code
> URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360])
> through the ClassPathRepository.
> {code:java}
> private ImmutableSet listClassesInJar(Path jar) throws
> IOException {
> ImmutableSet.Builder javaClasses = ImmutableSet.builder();
> for (String className : listClassNamesInJar(jar)) {
> try {
> JavaClass javaClass = classRepository.loadClass(className); # This is
> BCEL API. ConstantUtf8 is not cached.
> javaClasses.add(javaClass);
> ...(omit)
> return javaClasses.build();
> }
> {code}
> - Use the JavaClass instances to check if any symbol references (entries in
> constant pool [Java Virtual Machine Specification 4.4. The Constant
> Pool|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4]:
> CONSTANT_Class, CONSTANT_Fieldref, CONSTANT_Methodref, and
> CONSTANT_InterfaceMethodref) has invalid referent in the class path.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (BCEL-317) Pluggable cache for ConstantUtf8
[
https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-317:
-
Description:
Follow-up of BCEL-186. This enhancement is to provide an option to cache
ConstantUtf8 instances that have the same value.
Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass
instances
We use BCEL library to inspect Java class. Thank you for the great library.
When our tool checks classes in ~200 jar files, it creates more than 2 million
BCEL ConstantUtf8 instances. I suspect many of them share the same values such
as "java.lang.String".
Without cache, my tool created 2,6 million ConstantUtf8 instances (before
failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files.
!2644k_constantutf8_without_getCachedInstance.png!
With the cache, my tool created just 0.6 million ConstantUtf8 instances. It
didn't throw the OutOfMemoryError.
!621k_constantutf8_with_getCachedInstance.png!
Old commit that made ConstantUtf8.getInstance
[https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383=1481382=1481383]
The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186
[http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541=1652540=1652541]
h1. How our project uses BCEL
- Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around
200 JAR files as its input class path in
ClassDumper.createClassRepository([source code
URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83])
{code:java}
private static Repository createClassRepository(List paths) {
ClassPath classPath = new LinkageCheckClassPath(paths);
return new ClassPathRepository(classPath); # This is BCEL API
}
{code}
- reads JavaClasses one by one in ClassDumper.listClassesInJar ([source code
URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360])
through the ClassPathRepository.
{code:java}
private ImmutableSet listClassesInJar(Path jar) throws IOException
{
ImmutableSet.Builder javaClasses = ImmutableSet.builder();
for (String className : listClassNamesInJar(jar)) {
try {
JavaClass javaClass = classRepository.loadClass(className); # This is
BCEL API. ConstantUtf8 is not cached.
javaClasses.add(javaClass);
...(omit)
return javaClasses.build();
}
{code}
- Use the JavaClass instances to check if any symbol references (entries in
constant pool [Java Virtual Machine Specification 4.4. The Constant
Pool|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4]:
CONSTANT_Class, CONSTANT_Fieldref, CONSTANT_Methodref, and
CONSTANT_InterfaceMethodref) has invalid referent in the class path.
was:
Follow-up of BCEL-186. This enhancement is to provide an option to cache
ConstantUtf8 instances that have the same value.
Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass
instances
We use BCEL library to inspect Java class. Thank you for the great library.
When our tool checks classes in ~200 jar files, it creates more than 2 million
BCEL ConstantUtf8 instances. I suspect many of them share the same values such
as "java.lang.String".
Without cache, my tool created 2,6 million ConstantUtf8 instances (before
failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files.
!2644k_constantutf8_without_getCachedInstance.png!
With the cache, my tool created just 0.6 million ConstantUtf8 instances. It
didn't throw the OutOfMemoryError.
!621k_constantutf8_with_getCachedInstance.png!
Old commit that made ConstantUtf8.getInstance
[https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383=1481382=1481383]
The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186
[http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541=1652540=1652541]
h1. How our project uses BCEL
- Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around
200 JAR files as its input class path in
ClassDumper.createClassRepository([source code
URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83])
{code:java}
private static Repository createClassRepository(List paths) {
ClassPath
[jira] [Updated] (BCEL-317) Pluggable cache for ConstantUtf8
[
https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomo Suzuki updated BCEL-317:
-
Description:
Follow-up of BCEL-186. This enhancement is to provide an option to cache
ConstantUtf8 instances that have the same value.
Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass
instances
We use BCEL library to inspect Java class. Thank you for the great library.
When our tool checks classes in ~200 jar files, it creates more than 2 million
BCEL ConstantUtf8 instances. I suspect many of them share the same values such
as "java.lang.String".
Without cache, my tool created 2,6 million ConstantUtf8 instances (before
failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files.
!2644k_constantutf8_without_getCachedInstance.png!
With the cache, my tool created just 0.6 million ConstantUtf8 instances. It
didn't throw the OutOfMemoryError.
!621k_constantutf8_with_getCachedInstance.png!
Old commit that made ConstantUtf8.getInstance
[https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383=1481382=1481383]
The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186
[http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541=1652540=1652541]
h1. How our project uses BCEL
- Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around
200 JAR files as its input class path in
ClassDumper.createClassRepository([source code
URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83])
{code:java}
private static Repository createClassRepository(List paths) {
ClassPath classPath = new LinkageCheckClassPath(paths);
return new ClassPathRepository(classPath);
}
{code}
- reads JavaClasses one by one in ClassDumper.listClassesInJar ([source code
URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360])
through the ClassPathRepository.
{code:java}
private ImmutableSet listClassesInJar(Path jar) throws IOException
{
ImmutableSet.Builder javaClasses = ImmutableSet.builder();
for (String className : listClassNamesInJar(jar)) {
try {
JavaClass javaClass = classRepository.loadClass(className);
javaClasses.add(javaClass);
...(omit)
return javaClasses.build();
}
{code}
- Use the JavaClass instances to check if any symbol references (entries in
constant pool [Java Virtual Machine Specification 4.4. The Constant
Pool|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4]:
CONSTANT_Class, CONSTANT_Fieldref, CONSTANT_Methodref, and
CONSTANT_InterfaceMethodref) has invalid referent in the class path.
was:
Follow-up of BCEL-186. This enhancement is to provide an option to cache
ConstantUtf8 instances that have the same value.
Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass
instances
We use BCEL library to inspect Java class. Thank you for the great library.
When our tool checks classes in ~200 jar files, it creates more than 2 million
BCEL ConstantUtf8 instances. I suspect many of them share the same values such
as "java.lang.String".
Without cache, my tool created 2,6 million ConstantUtf8 instances (before
failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files.
!2644k_constantutf8_without_getCachedInstance.png!
With the cache, my tool created just 0.6 million ConstantUtf8 instances. It
didn't throw the OutOfMemoryError.
!621k_constantutf8_with_getCachedInstance.png!
Old commit that made ConstantUtf8.getInstance
[https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383=1481382=1481383]
The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186
[http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541=1652540=1652541]
h1. How our project uses BCEL
- Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200
JAR files as its input class path in ClassDumper.createClassRepository([source
code
URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83])
- reads JavaClass one by one in ClassDumper.listClassesInJar ([source code
[jira] [Updated] (LANG-1461) Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
[
https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LANG-1461:
---
Description:
Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
* {{StringUtills#getBytes(String, Charset)}}
* {{StringUtills#getBytes(String, String)}}
Also adds the following used by the above:
* {{CharSetUtils.defaultCharset(Charset)}}
* {{CharSetUtils.defaultCharset(String)}}
was:
Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
* {{StringUtills#getBytes(String, Charset)}}
* {{StringUtills#getBytes(String, String)}}
> Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
>
>
> Key: LANG-1461
> URL: https://issues.apache.org/jira/browse/LANG-1461
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.10
>
>
> Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
> * {{StringUtills#getBytes(String, Charset)}}
> * {{StringUtills#getBytes(String, String)}}
> Also adds the following used by the above:
> * {{CharSetUtils.defaultCharset(Charset)}}
> * {{CharSetUtils.defaultCharset(String)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (BCEL-317) Pluggable cache for ConstantUtf8
[ https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-317: - Description: Follow-up of BCEL-186. This enhancement is to provide an option to cache ConstantUtf8 instances that have the same value. Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass instances We use BCEL library to inspect Java class. Thank you for the great library. When our tool checks classes in ~200 jar files, it creates more than 2 million BCEL ConstantUtf8 instances. I suspect many of them share the same values such as "java.lang.String". Without cache, my tool created 2,6 million ConstantUtf8 instances (before failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. !2644k_constantutf8_without_getCachedInstance.png! With the cache, my tool created just 0.6 million ConstantUtf8 instances. It didn't throw the OutOfMemoryError. !621k_constantutf8_with_getCachedInstance.png! Old commit that made ConstantUtf8.getInstance [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383=1481382=1481383] The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541=1652540=1652541] h1. How our project uses BCEL - Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 JAR files as its input class path in ClassDumper.createClassRepository([source code URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) - reads JavaClass one by one in ClassDumper.listClassesInJar ([source code URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360]) through the ClassPathRepository. was: Follow-up of BCEL-186. This enhancement is to provide an option to cache ConstantUtf8 instances that have the same value. Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass instances We use BCEL library to inspect Java class. Thank you for the great library. When our tool checks classes in ~200 jar files, it creates more than 2 million BCEL ConstantUtf8 instances. I suspect many of them share the same values such as "java.lang.String". Without cache, my tool created 2,6 million ConstantUtf8 instances (before failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. !2644k_constantutf8_without_getCachedInstance.png! With the cache, my tool created just 0.6 million ConstantUtf8 instances. It didn't throw the OutOfMemoryError. !621k_constantutf8_with_getCachedInstance.png! Old commit that made ConstantUtf8.getInstance [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383=1481382=1481383] The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541=1652540=1652541] h1. How our project uses BCEL Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 JAR files as its input class path ([ClassDumper.createClassRepository|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) and reads JavaClass one by one ([ClassDumper.listClassesInJar|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360]) through the ClassPathRepository. > Pluggable cache for ConstantUtf8 > > > Key: BCEL-317 > URL: https://issues.apache.org/jira/browse/BCEL-317 > Project: Commons BCEL > Issue Type: Improvement > Components: Main >Affects Versions: 6.3.1 >Reporter: Tomo Suzuki >Priority: Minor > Attachments: 2644k_constantutf8_without_getCachedInstance.png, > 621k_constantutf8_with_getCachedInstance.png > > Time Spent: 20m > Remaining Estimate: 0h > > Follow-up of BCEL-186. This enhancement is to provide an option to cache > ConstantUtf8 instances that have the same value. > > Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass > instances > > We use
[jira] [Updated] (LANG-1461) Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
[
https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LANG-1461:
---
Summary: Add null-safe StringUtils APIs to wrap
String#getBytes([Charset|String]) (was: Add null-safe StringUtils APIs to wrap
getBytes(String, [Charset|String]))
> Add null-safe StringUtils APIs to wrap String#getBytes([Charset|String])
>
>
> Key: LANG-1461
> URL: https://issues.apache.org/jira/browse/LANG-1461
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.10
>
>
> Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
> * {{StringUtills#getBytes(String, Charset)}}
> * {{StringUtills#getBytes(String, String)}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (LANG-1461) Add null-safe StringUtils APIs to wrap getBytes(String, [Charset|String])
[
https://issues.apache.org/jira/browse/LANG-1461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory updated LANG-1461:
---
Summary: Add null-safe StringUtils APIs to wrap getBytes(String,
[Charset|String]) (was: Add null-safe versions to wrap getBytes(String,
[Charset|String]))
> Add null-safe StringUtils APIs to wrap getBytes(String, [Charset|String])
> -
>
> Key: LANG-1461
> URL: https://issues.apache.org/jira/browse/LANG-1461
> Project: Commons Lang
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
> Fix For: 3.10
>
>
> Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
> * {{StringUtills#getBytes(String, Charset)}}
> * {{StringUtills#getBytes(String, String)}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CODEC-253) Upgrade to Java 8
[ https://issues.apache.org/jira/browse/CODEC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854678#comment-16854678 ] Michael Osipov commented on CODEC-253: -- [~ggregory], pretty professional by opening another ticket for this issue and commit right away w/o concluding the discussion here. You can also get Zulu 7 for free and test your stuff. You pretty gained nothing by changing the byte code version. > Upgrade to Java 8 > - > > Key: CODEC-253 > URL: https://issues.apache.org/jira/browse/CODEC-253 > Project: Commons Codec > Issue Type: Improvement >Reporter: Rob Tompkins >Assignee: Rob Tompkins >Priority: Major > Fix For: 1.13 > > > Upgrade to java 8 as the target of of the build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (LANG-1461) Add null-safe versions to wrap getBytes(String, [Charset|String])
Gary Gregory created LANG-1461:
--
Summary: Add null-safe versions to wrap getBytes(String,
[Charset|String])
Key: LANG-1461
URL: https://issues.apache.org/jira/browse/LANG-1461
Project: Commons Lang
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
Fix For: 3.10
Add null-safe versions to wrap {{getBytes(String, [Charset|String])}}:
* {{StringUtills#getBytes(String, Charset)}}
* {{StringUtills#getBytes(String, String)}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BCEL-317) Pluggable cache for ConstantUtf8
[ https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854631#comment-16854631 ] Gary Gregory commented on BCEL-317: --- May you please show how you use the BCEL API? That will help me see if I can provide a minimal change set for you to test... > Pluggable cache for ConstantUtf8 > > > Key: BCEL-317 > URL: https://issues.apache.org/jira/browse/BCEL-317 > Project: Commons BCEL > Issue Type: Improvement > Components: Main >Affects Versions: 6.3.1 >Reporter: Tomo Suzuki >Priority: Minor > Attachments: 2644k_constantutf8_without_getCachedInstance.png, > 621k_constantutf8_with_getCachedInstance.png > > Time Spent: 20m > Remaining Estimate: 0h > > Follow-up of BCEL-186. This enhancement is to provide an option to cache > ConstantUtf8 instances that have the same value. > > Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass > instances > > We use BCEL library to inspect Java class. Thank you for the great library. > > When our tool checks classes in ~200 jar files, it creates more than 2 > million BCEL ConstantUtf8 instances. I suspect many of them share the same > values such as "java.lang.String". > > Without cache, my tool created 2,6 million ConstantUtf8 instances (before > failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. > !2644k_constantutf8_without_getCachedInstance.png! > > With the cache, my tool created just 0.6 million ConstantUtf8 instances. It > didn't throw the OutOfMemoryError. > !621k_constantutf8_with_getCachedInstance.png! > > Old commit that made ConstantUtf8.getInstance > [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383=1481382=1481383] > The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 > [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541=1652540=1652541] > > h1. How our project uses BCEL > Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 > JAR files as its input class path > ([ClassDumper.createClassRepository|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) > and reads JavaClass one by one > ([ClassDumper.listClassesInJar|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360]) > through the ClassPathRepository. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RNG-75) Improve the speed of the RandomSource create method.
[
https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854589#comment-16854589
]
Gilles commented on RNG-75:
---
bq. performance of the {{SeedFactory}}
Performance is a non-goal for this class.
Primary goal was to provide the largest possible seed space.
To achieve it, the whole seed should be generated from the RNG with longest
period.
For "intermediate" requirement, a single long is generated from that longest
period RNG in order to seed a fast RNG, and the rest of the seed array is
produced by that RNG. IIRC we discussed of {{SeedFactory}} providing new
{{create...Fast}} methods to that end.
For "special" ("odd" ;)) requirement (throw-away RNG (?)), where even a single
long from a slow RNG is unbearable (?), I would not assume that {{SeedFactory}}
should be used (e.g. the user can instantiate and keep a reference to a fast
RNG that would serve as his own seed factory).
> Improve the speed of the RandomSource create method.
>
>
> Key: RNG-75
> URL: https://issues.apache.org/jira/browse/RNG-75
> Project: Commons RNG
> Issue Type: Improvement
> Components: simple
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Minor
> Fix For: 1.3
>
> Attachments: large.jpg, long.jpg, small.jpg
>
>
> Update the {{o.a.c.rng.simple.internal}} package to improve the construction
> speed of random generators.
> Areas identified by the construction benchmark
> [RNG-72|https://issues.apache.org/jira/projects/RNG/issues/RNG-72] include:
> * Update the {{RandomSourceInternal}} to know the desired size for the native
> seed
> * Update the {{SeedFactory}} for faster {{byte[]}} conversions
> * Remove the use of reflection for fast seeding generators
> It is intended that all changes made are non-destructive to the quality of
> any generated seed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BCEL-317) Pluggable cache for ConstantUtf8
[ https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854577#comment-16854577 ] Tomo Suzuki commented on BCEL-317: -- My ClassDumper is irrelevant to the one in the examples. They happen to have the same name. > Pluggable cache for ConstantUtf8 > > > Key: BCEL-317 > URL: https://issues.apache.org/jira/browse/BCEL-317 > Project: Commons BCEL > Issue Type: Improvement > Components: Main >Affects Versions: 6.3.1 >Reporter: Tomo Suzuki >Priority: Minor > Attachments: 2644k_constantutf8_without_getCachedInstance.png, > 621k_constantutf8_with_getCachedInstance.png > > Time Spent: 20m > Remaining Estimate: 0h > > Follow-up of BCEL-186. This enhancement is to provide an option to cache > ConstantUtf8 instances that have the same value. > > Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass > instances > > We use BCEL library to inspect Java class. Thank you for the great library. > > When our tool checks classes in ~200 jar files, it creates more than 2 > million BCEL ConstantUtf8 instances. I suspect many of them share the same > values such as "java.lang.String". > > Without cache, my tool created 2,6 million ConstantUtf8 instances (before > failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files. > !2644k_constantutf8_without_getCachedInstance.png! > > With the cache, my tool created just 0.6 million ConstantUtf8 instances. It > didn't throw the OutOfMemoryError. > !621k_constantutf8_with_getCachedInstance.png! > > Old commit that made ConstantUtf8.getInstance > [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383=1481382=1481383] > The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186 > [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541=1652540=1652541] > > h1. How our project uses BCEL > Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200 > JAR files as its input class path > ([ClassDumper.createClassRepository|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83]) > and reads JavaClass one by one > ([ClassDumper.listClassesInJar|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360]) > through the ClassPathRepository. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (JEXL-302) JexlScript.getVariables returns strange values for array access
[
https://issues.apache.org/jira/browse/JEXL-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854569#comment-16854569
]
Dmitri Blinov commented on JEXL-302:
I have got your point, but for the sake of argument, as of now - {{a.b}} is not
equivalent to {{a["b"]}}. First because of ant-ish variables. One can only
address anti-sh variable as {{a.b}}, not as {{a["b"]}}. And second - because we
can have {{propertyGet()/propertySet()}} and {{arrayGet()/arraySet()}} to be
overloaded separately.
I understand that what {{a.b}} is resolved into (whether this a variable
{{a.b}} or only {{a}} is a variable, and {{b}} is property name) is decided
during runtime, so this can not be defined from syntax representation tree - a
tough task for {{JexlScript.getVariables()}}.
Still, the example of issue
{code:java}
a[b]['c']{code}
does not follow the pattern in question. From your explanation, and from what I
get from the {{JexlScript.getVariables(),}} the code {{a[b]['c']}} is
equivalent to {{a[b.c]}}, which in fact should be equivalent to {{a[b["c"]]}}.
Something is wrong here...
> JexlScript.getVariables returns strange values for array access
> ---
>
> Key: JEXL-302
> URL: https://issues.apache.org/jira/browse/JEXL-302
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> I can not understand the logic behind the current implementation of
> {{JexlScript.getVariables()}} method. From the documentation we know that the
> result should be the set of script variables. For the code
> {code:java}
> a[b][c]{code}
> it gives three variables {{a}}, {{b}}, {{c}}. So far so good. But for the code
> {code:java}
> a[b]['c']{code}
> it returns {{a}} and {{b c}}, where second variable has two fragments {{b}}
> and {{c}}. The documentation states that variables with multiple fragments
> are ant-ish variables, but I don't have any of ant-ish variables in the
> example, and {{'c'}} is not a variable, but a constant. I expect to get {{a}}
> and {{b}} as a result.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-75) Improve the speed of the RandomSource create method.
[
https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854542#comment-16854542
]
Alex D Herbert commented on RNG-75:
---
I have created a PR that rearranges the internals of the ProviderBuilder. The
goal was to allow:
* Construction of array seeds of the correct length
* Customisation of seed creation on a per generator basis, e.g. to prevent
creation of seeds containing only zero bytes
The code change does the following:
* Moves the creation methods for creating a seed and a new generator into
RandomSourceInternal
* Adds a new interface for seed conversions to specify output array size
* Adds a property to each RandomSourceInternal containing the size of the seed
* Uses a custom enum supporting all the seed types to perform conversions
* Caches the constructor (it is always the same) to avoid repeat lookups using
reflection
Note: The new code still creates a maximum array length of 128 when using a
null seed. This is to minimise the work done in the SeedFactory to create
arrays using a single synchronized RNG. This could be changed by has been left
to have the same support as the old code.
To support sized conversions a new interface has been added where the output
array size is specified. This is only applicable when the input seed is either
an int or long and is converted to an array using a SplitMix generator. So to
avoid supporting this interface for all seed converters a new internal enum was
created that performs seed conversions. This uses the seed converters directly
and uses the array size when appropriate.
I have JMH construction timing data for all the generators. For reference here
are the methods:
* Create using the native constructor with the {{new}} keyword
* Create using a cached {{Constructor}} with newInstance
* Create using a cached {{Class}}, lookup the {{Constructor}} and
use newInstance
* Create using {{RandomSource}} with the native seed
* Create using {{RandomSource}} with a {{null}} seed
* Create using {{RandomSource}} with a truncated native seed forcing self
seeding
* Create using {{RandomSource}} with a {{byte[]}} of the appropriate length
To avoid a large table I've computed the relative time between the old code
and the new. I've split the generators into groups with:
* Long seeding routines
* Large array seeds (above the supported max length of 128)
* Small seeds (below length 128)
Here are some charts of the relative construction time:
*Long seeding routines*
!long.jpg!
In this case the changes have not made the construction faster. I do not
understand the slower time for TWO_CMRES. Construction with the same seed using
the *new* keyword is the same. But the new factory methods are slower. The seed
is a single integer so this timing difference is strange. This generator is
very slow to self-seed so I would expect no difference for the construction
since instantiation time is minimal compared to the self-seeding time.
The other generators are the same speed. The slower time for createLongSeed for
the Mersenne Twisters is explained by the fact that the old method computed a
seed of length 128. The MT requires a seed of 624 and MT_64 a seed of 312. So
the new method which creates the correct seed length is doing more work.
*Large array seeds*
!large.jpg!
For the generators with big seeds most methods are the same speed. The MWC
result for *createNullSeed* is an outlier. It requires repeating on a different
machine to verify.
For the other generators they are slower on *createLongSeed* since the new
method is array size aware and creates a full length seed rather than the old
method creating length 128.
*Small seeds*
!small.jpg!
For *createLongSeed* construction is faster as the correct seed length is
created rather than a seed of length 128.
For other cases the construction is faster as the method now caches the
constructor that is used to create the generator. This adds a noticeable
improvement when the seed is pre-built.
Note that *createNullSeed* is not much faster for JDK or SplitMix as they have
a single long seed. The time is mainly consumed by the SeedFactory creating the
seed.
A table comparing the speed of construction a single seed created by a
synchronised method is shown below for a single thread or 4 threads running in
JMH.
|Method|1 Thread|4 Threads|
|AtomicInt_getAndIncrement|4.88|66.20|
|AtomicLong_getAndIncrement|4.85|62.57|
|SeedFactory_createInt|54.75|791.25|
|SeedFactory_createLong|63.92|842.57|
|SyncSplitMix_nextInt|6.66|78.77|
|SyncSplitMix_nextLong|6.63|75.18|
|System_currentTimeMillis|570.87|2,217.24|
|System_identityHashCode|36.43|41.42|
|System_nanoTime|575.76|2,224.95|
|ThreadLocalRandom_nextInt|1.44|1.65|
|ThreadLocalRandom_nextLong|1.63|1.66|
|volatileInt_increment|4.94|145.98|
|volatileLong_increment|4.87|154.59|
|Well44497b_nextInt|18.95|572.74|
[jira] [Commented] (CODEC-95) Base64: optionally allow strict parsing of base64 strings
[
https://issues.apache.org/jira/browse/CODEC-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854540#comment-16854540
]
Melloware commented on CODEC-95:
I think this is now fixed by https://issues.apache.org/jira/browse/CODEC-134
which no longer allows invalid Base64?
> Base64: optionally allow strict parsing of base64 strings
> -
>
> Key: CODEC-95
> URL: https://issues.apache.org/jira/browse/CODEC-95
> Project: Commons Codec
> Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Adam Rabung
>Priority: Minor
> Fix For: 1.x
>
> Attachments: strictMode.zip
>
>
> Currently, Codec skips base64 characters that are outside of the encode
> table. I realize this is perfectly to spec, but I wonder if other users
> might appreciate a "strict" mode that throws an exception when one of these
> illegal characters are encountered. For example, I would love an exception
> to be thrown here:
> new Base64().decode("!@#$ iHaveIllegalCharsAtBeginningAndEnd %^&"));
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (BCEL-317) Pluggable cache for ConstantUtf8
[
https://issues.apache.org/jira/browse/BCEL-317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854538#comment-16854538
]
Gary Gregory commented on BCEL-317:
---
Hi [~suztomo],
I do not see such methods in {{src/examples/ClassDumper.java}}. Do you have a
customized version of the example?
Gary
> Pluggable cache for ConstantUtf8
>
>
> Key: BCEL-317
> URL: https://issues.apache.org/jira/browse/BCEL-317
> Project: Commons BCEL
> Issue Type: Improvement
> Components: Main
>Affects Versions: 6.3.1
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: 2644k_constantutf8_without_getCachedInstance.png,
> 621k_constantutf8_with_getCachedInstance.png
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Follow-up of BCEL-186. This enhancement is to provide an option to cache
> ConstantUtf8 instances that have the same value.
>
> Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass
> instances
>
> We use BCEL library to inspect Java class. Thank you for the great library.
>
> When our tool checks classes in ~200 jar files, it creates more than 2
> million BCEL ConstantUtf8 instances. I suspect many of them share the same
> values such as "java.lang.String".
>
> Without cache, my tool created 2,6 million ConstantUtf8 instances (before
> failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files.
> !2644k_constantutf8_without_getCachedInstance.png!
>
> With the cache, my tool created just 0.6 million ConstantUtf8 instances. It
> didn't throw the OutOfMemoryError.
> !621k_constantutf8_with_getCachedInstance.png!
>
> Old commit that made ConstantUtf8.getInstance
> [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383=1481382=1481383]
> The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186
> [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541=1652540=1652541]
>
> h1. How our project uses BCEL
> Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around 200
> JAR files as its input class path
> ([ClassDumper.createClassRepository|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83])
> and reads JavaClass one by one
> ([ClassDumper.listClassesInJar|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360])
> through the ClassPathRepository.
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[
https://issues.apache.org/jira/browse/IMAGING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854516#comment-16854516
]
Gilles commented on IMAGING-228:
Just saw the commit on GitHub: The original code is how I would have done it. ;)
Intuitively, I'd bet that the call to {{Math.pow}} is slower...
> Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
> ---
>
> Key: IMAGING-228
> URL: https://issues.apache.org/jira/browse/IMAGING-228
> Project: Commons Imaging
> Issue Type: Improvement
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Fix For: 1.0-alpha2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have a private method in PhotometricInterpreterLogLuv, that calculates the
> cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3).
> Will add unit tests and some javadocs around photometric interpreters,
> logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
[ https://issues.apache.org/jira/browse/IMAGING-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854512#comment-16854512 ] Gilles commented on IMAGING-228: bq. N * N * N \[...\] can be replaced by Math.pow(N, 3). Why would you do that? > Remove private method PhotometricInterpreterLogLuv#cube by Math.pow > --- > > Key: IMAGING-228 > URL: https://issues.apache.org/jira/browse/IMAGING-228 > Project: Commons Imaging > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > We have a private method in PhotometricInterpreterLogLuv, that calculates the > cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3). > Will add unit tests and some javadocs around photometric interpreters, > logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (BCEL-319) DumpClass.main(String[]) leaks FileImageInputStream
Gary Gregory created BCEL-319:
-
Summary: DumpClass.main(String[]) leaks FileImageInputStream
Key: BCEL-319
URL: https://issues.apache.org/jira/browse/BCEL-319
Project: Commons BCEL
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
The method {{DumpClass.main(String[])}} leaks {{FileImageInputStream}}
instances by never closing them.
This only matters if invoked via an API call instead of from an OS shell.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Deleted] (BCEL-319) DumpClass.main(String[]) leaks FileImageInputStream
[
https://issues.apache.org/jira/browse/BCEL-319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory deleted BCEL-319:
--
> DumpClass.main(String[]) leaks FileImageInputStream
> ---
>
> Key: BCEL-319
> URL: https://issues.apache.org/jira/browse/BCEL-319
> Project: Commons BCEL
> Issue Type: New Feature
>Reporter: Gary Gregory
>Assignee: Gary Gregory
>Priority: Major
>
> The method {{DumpClass.main(String[])}} leaks {{FileImageInputStream}}
> instances by never closing them.
> This only matters if invoked via an API call instead of from an OS shell.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RNG-75) Improve the speed of the RandomSource create method.
[
https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex D Herbert updated RNG-75:
--
Attachment: small.jpg
large.jpg
> Improve the speed of the RandomSource create method.
>
>
> Key: RNG-75
> URL: https://issues.apache.org/jira/browse/RNG-75
> Project: Commons RNG
> Issue Type: Improvement
> Components: simple
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Minor
> Fix For: 1.3
>
> Attachments: large.jpg, long.jpg, small.jpg
>
>
> Update the {{o.a.c.rng.simple.internal}} package to improve the construction
> speed of random generators.
> Areas identified by the construction benchmark
> [RNG-72|https://issues.apache.org/jira/projects/RNG/issues/RNG-72] include:
> * Update the {{RandomSourceInternal}} to know the desired size for the native
> seed
> * Update the {{SeedFactory}} for faster {{byte[]}} conversions
> * Remove the use of reflection for fast seeding generators
> It is intended that all changes made are non-destructive to the quality of
> any generated seed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RNG-75) Improve the speed of the RandomSource create method.
[
https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex D Herbert updated RNG-75:
--
Attachment: (was: small.jpg)
> Improve the speed of the RandomSource create method.
>
>
> Key: RNG-75
> URL: https://issues.apache.org/jira/browse/RNG-75
> Project: Commons RNG
> Issue Type: Improvement
> Components: simple
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Minor
> Fix For: 1.3
>
> Attachments: long.jpg
>
>
> Update the {{o.a.c.rng.simple.internal}} package to improve the construction
> speed of random generators.
> Areas identified by the construction benchmark
> [RNG-72|https://issues.apache.org/jira/projects/RNG/issues/RNG-72] include:
> * Update the {{RandomSourceInternal}} to know the desired size for the native
> seed
> * Update the {{SeedFactory}} for faster {{byte[]}} conversions
> * Remove the use of reflection for fast seeding generators
> It is intended that all changes made are non-destructive to the quality of
> any generated seed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RNG-75) Improve the speed of the RandomSource create method.
[
https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex D Herbert updated RNG-75:
--
Attachment: (was: large.jpg)
> Improve the speed of the RandomSource create method.
>
>
> Key: RNG-75
> URL: https://issues.apache.org/jira/browse/RNG-75
> Project: Commons RNG
> Issue Type: Improvement
> Components: simple
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Minor
> Fix For: 1.3
>
> Attachments: long.jpg
>
>
> Update the {{o.a.c.rng.simple.internal}} package to improve the construction
> speed of random generators.
> Areas identified by the construction benchmark
> [RNG-72|https://issues.apache.org/jira/projects/RNG/issues/RNG-72] include:
> * Update the {{RandomSourceInternal}} to know the desired size for the native
> seed
> * Update the {{SeedFactory}} for faster {{byte[]}} conversions
> * Remove the use of reflection for fast seeding generators
> It is intended that all changes made are non-destructive to the quality of
> any generated seed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (BCEL-318) Add org.apache.bcel.classfile.ConstantUtf8.clearCache().
Gary Gregory created BCEL-318:
-
Summary: Add org.apache.bcel.classfile.ConstantUtf8.clearCache().
Key: BCEL-318
URL: https://issues.apache.org/jira/browse/BCEL-318
Project: Commons BCEL
Issue Type: New Feature
Reporter: Gary Gregory
Assignee: Gary Gregory
Add {{org.apache.bcel.classfile.ConstantUtf8.clearCache()}}.
There was previously no way to clear the cache.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (RNG-75) Improve the speed of the RandomSource create method.
[
https://issues.apache.org/jira/browse/RNG-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex D Herbert updated RNG-75:
--
Attachment: small.jpg
long.jpg
large.jpg
> Improve the speed of the RandomSource create method.
>
>
> Key: RNG-75
> URL: https://issues.apache.org/jira/browse/RNG-75
> Project: Commons RNG
> Issue Type: Improvement
> Components: simple
>Affects Versions: 1.3
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Minor
> Fix For: 1.3
>
> Attachments: large.jpg, long.jpg, small.jpg
>
>
> Update the {{o.a.c.rng.simple.internal}} package to improve the construction
> speed of random generators.
> Areas identified by the construction benchmark
> [RNG-72|https://issues.apache.org/jira/projects/RNG/issues/RNG-72] include:
> * Update the {{RandomSourceInternal}} to know the desired size for the native
> seed
> * Update the {{SeedFactory}} for faster {{byte[]}} conversions
> * Remove the use of reflection for fast seeding generators
> It is intended that all changes made are non-destructive to the quality of
> any generated seed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CODEC-253) Upgrade to Java 8
[ https://issues.apache.org/jira/browse/CODEC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved CODEC-253. Resolution: Fixed > Upgrade to Java 8 > - > > Key: CODEC-253 > URL: https://issues.apache.org/jira/browse/CODEC-253 > Project: Commons Codec > Issue Type: Improvement >Reporter: Rob Tompkins >Assignee: Rob Tompkins >Priority: Major > Fix For: 1.13 > > > Upgrade to java 8 as the target of of the build. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-253) Upgrade to Java 8
[
https://issues.apache.org/jira/browse/CODEC-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854488#comment-16854488
]
Gary Gregory commented on CODEC-253:
[~melloware]: Yes, IMO, we can close this; YMMV.
[~michael-o]: The comment
https://issues.apache.org/jira/browse/CODEC-253?focusedCommentId=16761022=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16761022:
{quote}Java 7 still receives updates, many commercial vendors will provide
updates too.
{quote}
is to me a reason _against_ staying on Java 7. We cannot get these updates,
only companies that pay for Java 7 commercial support (from Oracle) get them.
So we have to way to know if newer "private" versions of Java 7 work or break
for us. Granted this is an unlikely case, but I do see why, as a FOSS
organization we should support Java 7 when support is only offered to paid
customers.
> Upgrade to Java 8
> -
>
> Key: CODEC-253
> URL: https://issues.apache.org/jira/browse/CODEC-253
> Project: Commons Codec
> Issue Type: Improvement
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
>Priority: Major
> Fix For: 1.13
>
>
> Upgrade to java 8 as the target of of the build.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-rng] coveralls commented on issue #46: Update ProviderBuilder factory methods
coveralls commented on issue #46: Update ProviderBuilder factory methods URL: https://github.com/apache/commons-rng/pull/46#issuecomment-498219127 [](https://coveralls.io/builds/23755787) Coverage increased (+0.07%) to 98.821% when pulling **730b217ab8ccb86032d46d9eba4bb087c2fd3f6e on aherbert:improvement-RNG-75** into **0bda14cc5fc04155f8d1d2c4eeb8d1e1dd6160a3 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 With regards, Apache Git Services
[GitHub] [commons-rng] coveralls commented on issue #46: Update ProviderBuilder factory methods
coveralls commented on issue #46: Update ProviderBuilder factory methods URL: https://github.com/apache/commons-rng/pull/46#issuecomment-498219122 [](https://coveralls.io/builds/23755787) Coverage increased (+0.07%) to 98.821% when pulling **730b217ab8ccb86032d46d9eba4bb087c2fd3f6e on aherbert:improvement-RNG-75** into **0bda14cc5fc04155f8d1d2c4eeb8d1e1dd6160a3 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 With regards, Apache Git Services
[GitHub] [commons-rng] aherbert opened a new pull request #46: Update ProviderBuilder factory methods
aherbert opened a new pull request #46: Update ProviderBuilder factory methods URL: https://github.com/apache/commons-rng/pull/46 This rearranges the internals of the ProviderBuilder. This achieves the following goals: - Allow each RandomSource to know it's own array seed length - Allow each RandomSource to be able to override the default seed creation path The second point is to support generators with specific seeding requirements, e.g. do not allow all zero bytes. 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 With regards, Apache Git Services
[GitHub] [commons-imaging] kinow commented on issue #44: [IMAGING-228] Drop cube method and add unit tests for PhotometricInterpretationLogLuv
kinow commented on issue #44: [IMAGING-228] Drop cube method and add unit tests for PhotometricInterpretationLogLuv URL: https://github.com/apache/commons-imaging/pull/44#issuecomment-498194530 `oraclejdk8` is failing, but looks to be related to https://travis-ci.community/t/the-travis-ci-build-could-not-be-completed-due-to-an-error/1345 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 With regards, Apache Git Services
[jira] [Commented] (IMAGING-221) updateExifMetadataLossless restructures meta data (and problems with Maker Notes)
[ https://issues.apache.org/jira/browse/IMAGING-221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16854429#comment-16854429 ] Bruno P. Kinoshita commented on IMAGING-221: >The input to producing the file "mine-gps.jpg" is, perhaps, the file >"mine-original.jpg" which does not contain description and UserComment fields? Hi [~joakimk]! Unfortunately I don't have the workspace anymore (preparing laptop for overseas trip). But I don't remember having issues with the GPS coordinates. It all seemed to have worked fine for me. I may have added some comment with confusing wording, or attached the wrong file. > updateExifMetadataLossless restructures meta data (and problems with Maker > Notes) > - > > Key: IMAGING-221 > URL: https://issues.apache.org/jira/browse/IMAGING-221 > Project: Commons Imaging > Issue Type: Bug >Reporter: Joakim Knudsen >Assignee: Bruno P. Kinoshita >Priority: Major > Fix For: 1.0-alpha2 > > Attachments: mine-gps.JPG, mine-metadata.JPG, mine-original.JPG, > mine.JPG, mine.JPG.html, original.JPG, original.html, tagsmissing.png, > test.JPG, test.html > > > ExifRewriter's *updateExifMetadataLossless* method causes the meta data of > the JPEG to be completely reordered after writing. This, in itself, might not > be a big concern, but it's a bit unexpected when the method is named > "lossless". More worryingly, I also find problems are introduced wrt. the > Maker Notes tag (odd offset). > I've produced an example of the problem in the attached JPEG file, using > ExifTool to validate/analyze the images before and after. The image is taken > by a Sony Xperia Z5 phone, and the "original.JPG" validates OK. After > modifying the contents of the UserComments tag (value: "Test") the modified > image produces a warning: > Verifying the attached photo using ExifTool gives the following output: > $ ./exiftool\(-k\).exe -validate -warning -a ../test.JPG > -- press RETURN -- > > Validate : 1 Warning (all minor) > Warning : [minor] Possibly incorrect maker notes > offsets (fix by -628?) > > Using ExifTool's -htmldump option, it is easy to see how the meta data has > been affected. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMAGING-228) Remove private method PhotometricInterpreterLogLuv#cube by Math.pow
Bruno P. Kinoshita created IMAGING-228: -- Summary: Remove private method PhotometricInterpreterLogLuv#cube by Math.pow Key: IMAGING-228 URL: https://issues.apache.org/jira/browse/IMAGING-228 Project: Commons Imaging Issue Type: Improvement Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Fix For: 1.0-alpha2 We have a private method in PhotometricInterpreterLogLuv, that calculates the cube of a number N doing N * N * N. That can be replaced by Math.pow(N, 3). Will add unit tests and some javadocs around photometric interpreters, logluv, cei, lab, color spaces, ceixyz-ceilab, etc, as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-imaging] kinow opened a new pull request #44: Drop cube function add tests
kinow opened a new pull request #44: Drop cube function add tests URL: https://github.com/apache/commons-imaging/pull/44 Noticed that the `PhotometricInterpretaterLogLuv` had no coverage, so decided to write some simple unit tests. Then found a `cube` method that can be replaced by `Math.pow(N, 3)`, and also that there is no javadocs about what is XYZ, why LAB, what is CIE, or even what is Photometric Interpretation. 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 With regards, Apache Git Services
[GitHub] [commons-imaging] kinow commented on issue #44: Drop cube function add tests
kinow commented on issue #44: Drop cube function add tests URL: https://github.com/apache/commons-imaging/pull/44#issuecomment-498155651 Just need to finish the unit tests to promote to PR. Draft for now. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
