[jira] [Updated] (NUMBERS-93) PlaneAngle normalize() Upper Bound is Exclusive
[
https://issues.apache.org/jira/browse/NUMBERS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Juntunen updated NUMBERS-93:
-
Description:
The {{PlaneAngle#normalize()}} documentation states that it normalizes an angle
to be between -0.5 turns and +0.5 turns inclusive of the given center angle.
However, the upper bound is actually exclusive. The documentation should be
updated to reflect this and unit tests added.
Pull request: https://github.com/apache/commons-numbers/pull/29
was:The {{PlaneAngle#normalize()}} documentation states that it normalizes an
angle to be between -0.5 turns and +0.5 turns inclusive of the given center
angle. However, the upper bound is actually exclusive. The documentation should
be updated to reflect this and unit tests added.
> PlaneAngle normalize() Upper Bound is Exclusive
> ---
>
> Key: NUMBERS-93
> URL: https://issues.apache.org/jira/browse/NUMBERS-93
> Project: Commons Numbers
> Issue Type: Bug
>Reporter: Matt Juntunen
>Priority: Major
>
> The {{PlaneAngle#normalize()}} documentation states that it normalizes an
> angle to be between -0.5 turns and +0.5 turns inclusive of the given center
> angle. However, the upper bound is actually exclusive. The documentation
> should be updated to reflect this and unit tests added.
> Pull request: https://github.com/apache/commons-numbers/pull/29
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (NUMBERS-93) PlaneAngle normalize() Upper Bound is Exclusive
Matt Juntunen created NUMBERS-93:
Summary: PlaneAngle normalize() Upper Bound is Exclusive
Key: NUMBERS-93
URL: https://issues.apache.org/jira/browse/NUMBERS-93
Project: Commons Numbers
Issue Type: Bug
Reporter: Matt Juntunen
The {{PlaneAngle#normalize()}} documentation states that it normalizes an angle
to be between -0.5 turns and +0.5 turns inclusive of the given center angle.
However, the upper bound is actually exclusive. The documentation should be
updated to reflect this and unit tests added.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEOMETRY-11) Replace tolerance with GeometryContext
[
https://issues.apache.org/jira/browse/GEOMETRY-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747633#comment-16747633
]
Matt Juntunen commented on GEOMETRY-11:
---
This is ready to go once the PR from NUMBERS-90 is merged.
> Replace tolerance with GeometryContext
> --
>
> Key: GEOMETRY-11
> URL: https://issues.apache.org/jira/browse/GEOMETRY-11
> Project: Apache Commons Geometry
> Issue Type: Wish
>Reporter: Matt Juntunen
>Priority: Major
> Fix For: 1.0
>
>
> All of the partitioning-related concrete classes (ex: Plane, PolygonsSet,
> PolyhedronsSet, etc) use a double value named tolerance in order to address
> issues with floating point accuracy. For example, when determining if a point
> lies in a plane, the point does not need to lie exactly on the plane but just
> be within +- tolerance distance from it. Code testing values against each
> other using this tolerance is repeated throughout the code base (ex: x >= y -
> tolerance). We should abstract the concept of the tolerance into a
> GeometryContext class and provide methods for testing values against each
> other using the tolerance. This will reduce the chance of bugs and will also
> allow for more sophisticated handling of floating point accuracy later on.
> The GeometryContext class would be similar to the MathContext class used by
> BigDecimal but would contain the logic for making comparisons in addition to
> the configuration for the comparisons.
> {code:java}
> public class GeometryContext {
>public GeometryContext(tolerance){...}
>public double getTolerance(){ ... }
>// return -1, 0, +1
>public int compare(double a, double b) { ... }
> }{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-705) Compatibility with Oracle Java 11
[ https://issues.apache.org/jira/browse/COLLECTIONS-705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747584#comment-16747584 ] Shrinidhi Jahagirdar commented on COLLECTIONS-705: -- Hi, Just checking on this thread, if there are active plans to support Java 11. We haven't found any issues so far with our tests, but we would like to understand if there are problems reported, will they be actively resolved. Thanks a lot! Shrinidhi Jahagirdar > Compatibility with Oracle Java 11 > - > > Key: COLLECTIONS-705 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-705 > Project: Commons Collections > Issue Type: Improvement >Reporter: Vikram Sherigar >Priority: Major > > Is compatibility with Java 11 (or Java 9) planned for a future release? If > not, pls plan accordingly as all the earlier versions of Java have already > become obsolete. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-709) MultiSet.Entry::getCount() isn't 0 after removing the last element
[
https://issues.apache.org/jira/browse/COLLECTIONS-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747504#comment-16747504
]
Robert Wertman commented on COLLECTIONS-709:
Just realized the commit message says COMMONS-706 instead of COMMONS-709. Not
sure how important that is to fix.
> MultiSet.Entry::getCount() isn't 0 after removing the last element
> --
>
> Key: COLLECTIONS-709
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-709
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.1, 4.2
>Reporter: Robert Wertman
>Priority: Minor
> Fix For: 4.3
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Removing the final element(s) in a MultiSet doesn't set the count on a
> MultiSet.Entry to zero.
> {code:java}
> protected int getCountAfterRemoval(MultiSet multiset) {
> MultiSet.Entry entry = multiset.entrySet().iterator().next();
> entry.getCount(); // = 2
> multiset.remove(entry.getElement());
> entry.getCount(); // = 1
> multiset.remove(entry.getElement());
> return entry.getCount(); // Still = 1, should be 0
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (COLLECTIONS-709) MultiSet.Entry::getCount() isn't 0 after removing the last element
[
https://issues.apache.org/jira/browse/COLLECTIONS-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Wertman closed COLLECTIONS-709.
--
> MultiSet.Entry::getCount() isn't 0 after removing the last element
> --
>
> Key: COLLECTIONS-709
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-709
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.1, 4.2
>Reporter: Robert Wertman
>Priority: Minor
> Fix For: 4.3
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Removing the final element(s) in a MultiSet doesn't set the count on a
> MultiSet.Entry to zero.
> {code:java}
> protected int getCountAfterRemoval(MultiSet multiset) {
> MultiSet.Entry entry = multiset.entrySet().iterator().next();
> entry.getCount(); // = 2
> multiset.remove(entry.getElement());
> entry.getCount(); // = 1
> multiset.remove(entry.getElement());
> return entry.getCount(); // Still = 1, should be 0
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work logged] (COLLECTIONS-709) MultiSet.Entry::getCount() isn't 0 after removing the last element
[
https://issues.apache.org/jira/browse/COLLECTIONS-709?focusedWorklogId=187521&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-187521
]
ASF GitHub Bot logged work on COLLECTIONS-709:
--
Author: ASF GitHub Bot
Created on: 20/Jan/19 15:15
Start Date: 20/Jan/19 15:15
Worklog Time Spent: 10m
Work Description: CasualSuperman commented on pull request #66:
COLLECTIONS-709 Set Entry count to 0 after remove
URL: https://github.com/apache/commons-collections/pull/66
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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: 187521)
Time Spent: 0.5h (was: 20m)
> MultiSet.Entry::getCount() isn't 0 after removing the last element
> --
>
> Key: COLLECTIONS-709
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-709
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.1, 4.2
>Reporter: Robert Wertman
>Priority: Minor
> Fix For: 4.3
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Removing the final element(s) in a MultiSet doesn't set the count on a
> MultiSet.Entry to zero.
> {code:java}
> protected int getCountAfterRemoval(MultiSet multiset) {
> MultiSet.Entry entry = multiset.entrySet().iterator().next();
> entry.getCount(); // = 2
> multiset.remove(entry.getElement());
> entry.getCount(); // = 1
> multiset.remove(entry.getElement());
> return entry.getCount(); // Still = 1, should be 0
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (COLLECTIONS-709) MultiSet.Entry::getCount() isn't 0 after removing the last element
[
https://issues.apache.org/jira/browse/COLLECTIONS-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gary Gregory resolved COLLECTIONS-709.
--
Resolution: Fixed
Fix Version/s: 4.3
In git master now. Please verify and close this ticket and the PR.
> MultiSet.Entry::getCount() isn't 0 after removing the last element
> --
>
> Key: COLLECTIONS-709
> URL: https://issues.apache.org/jira/browse/COLLECTIONS-709
> Project: Commons Collections
> Issue Type: Bug
>Affects Versions: 4.1, 4.2
>Reporter: Robert Wertman
>Priority: Minor
> Fix For: 4.3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Removing the final element(s) in a MultiSet doesn't set the count on a
> MultiSet.Entry to zero.
> {code:java}
> protected int getCountAfterRemoval(MultiSet multiset) {
> MultiSet.Entry entry = multiset.entrySet().iterator().next();
> entry.getCount(); // = 2
> multiset.remove(entry.getElement());
> entry.getCount(); // = 1
> multiset.remove(entry.getElement());
> return entry.getCount(); // Still = 1, should be 0
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CSV-235) WRONG Implementation for RFC4180
[ https://issues.apache.org/jira/browse/CSV-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747473#comment-16747473 ] Gary Gregory commented on CSV-235: -- Hi [~exia] We welcome patches on GitHub with unit tests :) Gary > WRONG Implementation for RFC4180 > -- > > Key: CSV-235 > URL: https://issues.apache.org/jira/browse/CSV-235 > Project: Commons CSV > Issue Type: Bug > Components: Parser >Affects Versions: 1.6 >Reporter: Edward Xia >Priority: Major > > [https://tools.ietf.org/html/rfc4180#section-2] >7. If double-quotes are used to enclose fields, then a double-quote >appearing inside a field must be escaped by preceding it with >another double quote. For example: >"aaa","b""bb","ccc" > Apparently, base on a previous issue: > https://issues.apache.org/jira/browse/CSV-208, it turns out common-csv *does > not even support quote and escape to be the same character*. > RFC 4180 defines that quote and escape are both DQUOTE, however in common-csv > implementation, the default escape character is not DQUOTE, and it does not > work if changed to DQUOTE. > This means common csv is not rfc4180 compliant. > Also, I'm puzzled by the fact that someone marked CSV-208 as fixed when > nothing is fixed. Instead, it changed the behavior without documenting that > the POSTGRESQL_CSV format does not even work out of the box with the default > csv format that postgresql produces. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (POOL-359) NullPointerException closing multiple GenericObjectPools
[
https://issues.apache.org/jira/browse/POOL-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16747463#comment-16747463
]
Gary Gregory commented on POOL-359:
---
I am not ready to release new versions just yet, I have other pressing matters
to tend to unfortunately. Maybe another RM will step in before I can...
> NullPointerException closing multiple GenericObjectPools
>
>
> Key: POOL-359
> URL: https://issues.apache.org/jira/browse/POOL-359
> Project: Commons Pool
> Issue Type: Bug
>Affects Versions: 2.6.0
>Reporter: Michael Wintermeyer
>Priority: Major
> Fix For: 2.6.1
>
>
> {code:java}
> java.lang.NullPointerException
> at org.apache.commons.pool2.impl.EvictionTimer.cancel(EvictionTimer.java:97)
> at
> org.apache.commons.pool2.impl.BaseGenericObjectPool.startEvictor(BaseGenericObjectPool.java:753)
> at
> org.apache.commons.pool2.impl.GenericObjectPool.close(GenericObjectPool.java:694)
> {code}
> Possible when multiple pools in the same process each call #close.
> GenericObjectPool#close checks #isClosed before proceeding, but that call
> checks a non-static instance variable. It calls into EvictionTimer#cancel
> which sets the _static_ variable EvictionCache.executor to null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
