[jira] [Commented] (MATH-1416) Depend on "Commons Numbers"
[
https://issues.apache.org/jira/browse/MATH-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16403824#comment-16403824
]
Gilles commented on MATH-1416:
--
I forgot to include "Closes #82" in the log message. Sorry.
> Depend on "Commons Numbers"
> ---
>
> Key: MATH-1416
> URL: https://issues.apache.org/jira/browse/MATH-1416
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Major
> Labels: dependency, deprecated
> Fix For: 4.0
>
>
> The following codes with an equivalent in ["Commons
> Numbers"|http://commons.apache.org/proper/commons-numbers] must be deleted
> before the next major release (4.0):
> * Package {{o.a.c.math4.fraction}}
> * Package {{o.a.c.math4.complex}}
> * Package {{o.a.c.math4.primes}}
> Codes that depend on these functionalities must be updated with corresponding
> calls to "Commons Numbers" classes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1416) Depend on "Commons Numbers"
[
https://issues.apache.org/jira/browse/MATH-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16403814#comment-16403814
]
Gilles commented on MATH-1416:
--
Thanks. Merged in commit b048757035a1196a825113ca6e676bd439e4d46f ("master").
> Depend on "Commons Numbers"
> ---
>
> Key: MATH-1416
> URL: https://issues.apache.org/jira/browse/MATH-1416
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Major
> Labels: dependency, deprecated
> Fix For: 4.0
>
>
> The following codes with an equivalent in ["Commons
> Numbers"|http://commons.apache.org/proper/commons-numbers] must be deleted
> before the next major release (4.0):
> * Package {{o.a.c.math4.fraction}}
> * Package {{o.a.c.math4.complex}}
> * Package {{o.a.c.math4.primes}}
> Codes that depend on these functionalities must be updated with corresponding
> calls to "Commons Numbers" classes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (NUMBERS-56) Wrong dimension check?
[
https://issues.apache.org/jira/browse/NUMBERS-56?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated NUMBERS-56:
--
Description:
In {{ComplexUtils}}, at line 989:
{code:java}
public static double[][][][] complex2Interleaved(Complex[][][][] c, int
interleavedDim) {
if (interleavedDim > 2 || interleavedDim < 0) {
throw new IndexOutOfRangeException(interleavedDim);
}
// ...
}
{code}
at line 1261:
{code:java}
public static Complex[][][] interleaved2Complex(double[][][] i, int
interleavedDim) {
if (interleavedDim > 2 || interleavedDim < 0) {
throw new IndexOutOfRangeException(interleavedDim);
}
// ...
}
{code}
Shouldn't the upper bound be 3?
was:
In {{ComplexUtils}} (line 989):
{code:java}
public static double[][][][] complex2Interleaved(Complex[][][][] c, int
interleavedDim) {
if (interleavedDim > 2 || interleavedDim < 0) {
throw new IndexOutOfRangeException(interleavedDim);
}
// ...
}
{code}
Shouldn't the upper bound be 3?
> Wrong dimension check?
> --
>
> Key: NUMBERS-56
> URL: https://issues.apache.org/jira/browse/NUMBERS-56
> Project: Commons Numbers
> Issue Type: Bug
> Components: complex
>Reporter: Gilles
>Priority: Trivial
> Fix For: 1.0
>
>
> In {{ComplexUtils}}, at line 989:
> {code:java}
> public static double[][][][] complex2Interleaved(Complex[][][][] c, int
> interleavedDim) {
> if (interleavedDim > 2 || interleavedDim < 0) {
> throw new IndexOutOfRangeException(interleavedDim);
> }
> // ...
> }
> {code}
> at line 1261:
> {code:java}
> public static Complex[][][] interleaved2Complex(double[][][] i, int
> interleavedDim) {
> if (interleavedDim > 2 || interleavedDim < 0) {
> throw new IndexOutOfRangeException(interleavedDim);
> }
> // ...
> }
> {code}
> Shouldn't the upper bound be 3?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-986) DurationFormatUtils.formatDuration accepts formats with year/month but cannot use them
[ https://issues.apache.org/jira/browse/LANG-986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16403783#comment-16403783 ] Daniel Dowd commented on LANG-986: -- Is this improvement something that can be worked on? If so I would like to take it on. > DurationFormatUtils.formatDuration accepts formats with year/month but cannot > use them > -- > > Key: LANG-986 > URL: https://issues.apache.org/jira/browse/LANG-986 > Project: Commons Lang > Issue Type: Improvement > Components: lang.time.* >Reporter: Sebb >Priority: Major > Fix For: Discussion > > > The method DurationFormatUtils.formatDuration does not validate that the > format is applicable. The method does not calculate months and years, so > these values will be 0 if the format contains y or M. > Perhaps the method should throw IAE if one of the unused format chars is used? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1359) add getStopTime to StopWatch
[
https://issues.apache.org/jira/browse/LANG-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16403734#comment-16403734
]
Keegan Witt commented on LANG-1359:
---
I'm not looking to get the elapsed time. I'm looking to get the ending time.
So if I were manually coding a stopwatch,
{code:java}
long start = new Date().getTime();
// stuff that happens between start and stop
long stop = new Date().getTime();
long elapsed = stop - start;
{code}
In my case, I'd be looking for the {{stop}} long.
> add getStopTime to StopWatch
>
>
> Key: LANG-1359
> URL: https://issues.apache.org/jira/browse/LANG-1359
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.time.*
>Reporter: Keegan Witt
>Priority: Minor
>
> Someone I know recently had a use case where they needed to retrieve the
> stopTime for a timer. I know this could be inferred from
> {code:java}
> stopWatch.getStartTime() + stopWatch.getTime();
> {code}
> but it might be nice to just add a getter.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CONFIGURATION-690) ExprLookup will never return variables using getVariables()
[ https://issues.apache.org/jira/browse/CONFIGURATION-690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-690. Resolution: Fixed Fix Version/s: 2.3 This is indeed strange. A fix has been applied in SVN revision 1827107, so that the method now returns a copy of the variables of this lookup object. > ExprLookup will never return variables using getVariables() > --- > > Key: CONFIGURATION-690 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-690 > Project: Commons Configuration > Issue Type: Bug > Components: Interpolation >Affects Versions: 2.2 >Reporter: Steven Paligo >Priority: Major > Fix For: 2.3 > > > ExprLookup's getVariables() method always returns null -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CONFIGURATION-689) NullPointerException in ExprLookup when not using variables
[ https://issues.apache.org/jira/browse/CONFIGURATION-689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16403723#comment-16403723 ] Oliver Heger commented on CONFIGURATION-689: This is true; however, the NPE is not propagated to the outside, but caught and logged. The lookup operation returns the same variable that has been passed in. The default constructor could be modified to set an empty Variables object, but without further modifications this would change the behavior of the class: A lookup on an undefined variable would then return *null* rather than the variable name. Do you have a concrete use case in which this internal NPE causes a problem? > NullPointerException in ExprLookup when not using variables > --- > > Key: CONFIGURATION-689 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-689 > Project: Commons Configuration > Issue Type: Bug > Components: Interpolation >Affects Versions: 2.2 >Reporter: Steven Paligo >Priority: Major > > When an ExprLookup instance is created with the default constructor, the > "variables" object is null. During a lookup, initializeContext(JexlContext) > iterates over "variables" which triggers a NullPointerException. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (COMPRESS-446) Resource Leak in ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)
Christoph Ludwig created COMPRESS-446:
-
Summary: Resource Leak in
ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)
Key: COMPRESS-446
URL: https://issues.apache.org/jira/browse/COMPRESS-446
Project: Commons Compress
Issue Type: Bug
Components: Archivers
Affects Versions: 1.16.1
Environment: The application was running inside a Docker container,
the JVM had about 1.7 GByte heap space.
Reporter: Christoph Ludwig
Before it does anything else,
{{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} loops over all
futures returned by the creator`s executor service and calls {{Future#get()}}.
This will block until the future's computation is completed, respectively -
i.e., until all entries have been written to the thread-local scatter streams.
However, if the computation of a future fails, then {{Future#get()}} can also
throw an exception. This exception escapes
{{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} before the
executor service is shut down. The latter means that also the thread-local
variables in the executor service's threads and all objects referenced by them
continue to exist and cannot be reclaimed by the GC.
I encountered this situation when - while processing an archive with 130,000
documents - the JVM threw an {{OutOfMemoryError}}. The application was not able
to recover from this OOM error because most of the heap was occupied by objects
reachable from the executor service's threads.
Of course, the OOM is mostly the fault of my own code; I will be able to work
around the "leaked" executor service because I supply it in the first place and
can therefore shut it down if I detect an error situation.
The effect would be the same, though, if, say, {{Future#get()}} throws an
{{InterruptedException}}. Therefore,
{{ParallelScatterZipCreator#writeTo(ZipArchiveOutputStream)}} should either
shut down and release all resources if it cannot complete its task due to an
Exception thrown by a future or it should offer a reasonable recovery strategy.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (MATH-1416) Depend on "Commons Numbers"
[
https://issues.apache.org/jira/browse/MATH-1416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16403695#comment-16403695
]
Matt Juntunen commented on MATH-1416:
-
I've created a pull request to replace all calls to the o.a.c.numbers.Complex
constructor with the new static factory methods. The build fails without this
since the constructor is now private.
[https://github.com/apache/commons-math/pull/82]
> Depend on "Commons Numbers"
> ---
>
> Key: MATH-1416
> URL: https://issues.apache.org/jira/browse/MATH-1416
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
>Priority: Major
> Labels: dependency, deprecated
> Fix For: 4.0
>
>
> The following codes with an equivalent in ["Commons
> Numbers"|http://commons.apache.org/proper/commons-numbers] must be deleted
> before the next major release (4.0):
> * Package {{o.a.c.math4.fraction}}
> * Package {{o.a.c.math4.complex}}
> * Package {{o.a.c.math4.primes}}
> Codes that depend on these functionalities must be updated with corresponding
> calls to "Commons Numbers" classes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (LANG-1387) Add Span classes to handle checks for overlaps, containment, equality, etc.
[ https://issues.apache.org/jira/browse/LANG-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16403371#comment-16403371 ] Claude Warren commented on LANG-1387: - The jenkins build report indicates that much of this contribution is not in the proper format (curly brackets on the wrong line and that sort of thing). Is there an eclipse format XML file that one might use to correct such problems? > Add Span classes to handle checks for overlaps, containment, equality, etc. > --- > > Key: LANG-1387 > URL: https://issues.apache.org/jira/browse/LANG-1387 > Project: Commons Lang > Issue Type: Improvement > Components: lang.*, lang.math.* >Affects Versions: 3.7 >Reporter: Claude Warren >Priority: Minor > > This is a contribution of a span class as discussed on the mailing list. > The classes are int and long based and can: > # determine if points are within the span. > # determine if one span contains another span > # determine if two spans overlap > # do not have to have 0 (zero) as the index origin. > # determine the length of the span > # determine the last position in the span. > # determine the first position in the span. > Changes to Number Utils required to detect underflow and overflow > calculations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (LANG-1359) add getStopTime to StopWatch
[
https://issues.apache.org/jira/browse/LANG-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16403336#comment-16403336
]
Daniel Dowd commented on LANG-1359:
---
[~keegan]
I think this feature is already implemented in StopWatch. In the documentation
of the getTime function it states the following.
/**
*
* Get the time on the stopwatch.
*
*
*
* This is either the time between the start and the moment this method is
called, or the amount of time between
* start and stop.
*
*
* @return the time in milliseconds
*/
> add getStopTime to StopWatch
>
>
> Key: LANG-1359
> URL: https://issues.apache.org/jira/browse/LANG-1359
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.time.*
>Reporter: Keegan Witt
>Priority: Minor
>
> Someone I know recently had a use case where they needed to retrieve the
> stopTime for a timer. I know this could be inferred from
> {code:java}
> stopWatch.getStartTime() + stopWatch.getTime();
> {code}
> but it might be nice to just add a getter.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
