[jira] [Commented] (COMPRESS-388) Improve concurrent reads from ZipFile
[ https://issues.apache.org/jira/browse/COMPRESS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980284#comment-15980284 ] ASF GitHub Bot commented on COMPRESS-388: - Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/21 [](https://coveralls.io/builds/11199449) Coverage decreased (-0.02%) to 84.214% when pulling **3c8672db0a68dcd6b59c36abc3ec676b5af02f0a on kvr000:feature/COMPRESS-388-concurrent-reads-performance-fix** into **13a039029ca7d7fca9862cfb792f7148c555f05f on apache:master**. > Improve concurrent reads from ZipFile > - > > Key: COMPRESS-388 > URL: https://issues.apache.org/jira/browse/COMPRESS-388 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.13 > Environment: Any >Reporter: Zbynek Vyskovsky > Labels: patch, performance > Fix For: 1.14 > > Original Estimate: 2h > Remaining Estimate: 2h > > Concurrent reads on the ZipFile archive is terribly slow on multiprocessor > systems. On my 4 CPU laptop it shows 26 reads/s vs 2 reads/s on 100MB samples > for example. > The cause is the use of synchronized blocks to access the underlying file > channel. This may be required for generic SeekableByteChannel but most > commonly there is FileChannel implementation which supports lock-free reading > from any position (i.e. using pread/pwrite system calls or their equivalent). > With the fix the performance is about 10 times faster (on 4 CPU system, with > more processor the difference should grow significantly). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COMPRESS-388) Improve concurrent reads from ZipFile
[ https://issues.apache.org/jira/browse/COMPRESS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980285#comment-15980285 ] ASF GitHub Bot commented on COMPRESS-388: - Github user coveralls commented on the issue: https://github.com/apache/commons-compress/pull/21 [](https://coveralls.io/builds/11199449) Coverage decreased (-0.02%) to 84.214% when pulling **3c8672db0a68dcd6b59c36abc3ec676b5af02f0a on kvr000:feature/COMPRESS-388-concurrent-reads-performance-fix** into **13a039029ca7d7fca9862cfb792f7148c555f05f on apache:master**. > Improve concurrent reads from ZipFile > - > > Key: COMPRESS-388 > URL: https://issues.apache.org/jira/browse/COMPRESS-388 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.13 > Environment: Any >Reporter: Zbynek Vyskovsky > Labels: patch, performance > Fix For: 1.14 > > Original Estimate: 2h > Remaining Estimate: 2h > > Concurrent reads on the ZipFile archive is terribly slow on multiprocessor > systems. On my 4 CPU laptop it shows 26 reads/s vs 2 reads/s on 100MB samples > for example. > The cause is the use of synchronized blocks to access the underlying file > channel. This may be required for generic SeekableByteChannel but most > commonly there is FileChannel implementation which supports lock-free reading > from any position (i.e. using pread/pwrite system calls or their equivalent). > With the fix the performance is about 10 times faster (on 4 CPU system, with > more processor the difference should grow significantly). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COMPRESS-388) Improve concurrent reads from ZipFile
[ https://issues.apache.org/jira/browse/COMPRESS-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980283#comment-15980283 ] ASF GitHub Bot commented on COMPRESS-388: - GitHub user kvr000 opened a pull request: https://github.com/apache/commons-compress/pull/21 COMPRESS-388: Fix concurrent reads performance Ticket: https://issues.apache.org/jira/browse/COMPRESS-388 Concurrent reads on the ZipFile archive is terribly slow on multiprocessor systems. On my 4 CPU laptop it shows 26 reads/s vs 2 reads/s on 100MB samples for example. The cause is the use of synchronized blocks to access the underlying file channel. This may be required for generic SeekableByteChannel but most commonly there is FileChannel implementation which supports lock-free reading from any position (i.e. using pread/pwrite system calls or their equivalent). With the fix the performance is about 10 times faster (on 4 CPU system, with more processor the difference should grow significantly). You can merge this pull request into a Git repository by running: $ git pull https://github.com/kvr000/commons-compress feature/COMPRESS-388-concurrent-reads-performance-fix Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-compress/pull/21.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #21 commit 3c8672db0a68dcd6b59c36abc3ec676b5af02f0a Author: Zbynek Vyskovsky Date: 2017-04-23T06:45:46Z COMPRESS-388: Fix concurrent reads performance > Improve concurrent reads from ZipFile > - > > Key: COMPRESS-388 > URL: https://issues.apache.org/jira/browse/COMPRESS-388 > Project: Commons Compress > Issue Type: Improvement > Components: Archivers >Affects Versions: 1.13 > Environment: Any >Reporter: Zbynek Vyskovsky > Labels: patch, performance > Fix For: 1.14 > > Original Estimate: 2h > Remaining Estimate: 2h > > Concurrent reads on the ZipFile archive is terribly slow on multiprocessor > systems. On my 4 CPU laptop it shows 26 reads/s vs 2 reads/s on 100MB samples > for example. > The cause is the use of synchronized blocks to access the underlying file > channel. This may be required for generic SeekableByteChannel but most > commonly there is FileChannel implementation which supports lock-free reading > from any position (i.e. using pread/pwrite system calls or their equivalent). > With the fix the performance is about 10 times faster (on 4 CPU system, with > more processor the difference should grow significantly). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (COMPRESS-388) Improve concurrent reads from ZipFile
Zbynek Vyskovsky created COMPRESS-388: - Summary: Improve concurrent reads from ZipFile Key: COMPRESS-388 URL: https://issues.apache.org/jira/browse/COMPRESS-388 Project: Commons Compress Issue Type: Improvement Components: Archivers Affects Versions: 1.13 Environment: Any Reporter: Zbynek Vyskovsky Fix For: 1.14 Concurrent reads on the ZipFile archive is terribly slow on multiprocessor systems. On my 4 CPU laptop it shows 26 reads/s vs 2 reads/s on 100MB samples for example. The cause is the use of synchronized blocks to access the underlying file channel. This may be required for generic SeekableByteChannel but most commonly there is FileChannel implementation which supports lock-free reading from any position (i.e. using pread/pwrite system calls or their equivalent). With the fix the performance is about 10 times faster (on 4 CPU system, with more processor the difference should grow significantly). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COMPRESS-384) Tar File EOF not being detected
[ https://issues.apache.org/jira/browse/COMPRESS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980215#comment-15980215 ] Charles Honton commented on COMPRESS-384: - I'm not sure your scenario should be supported. Using a file as the intermediate storage is fraught with complications like those you are experiencing. Have you tried using a pipe between process 1 and process 2? > Tar File EOF not being detected > --- > > Key: COMPRESS-384 > URL: https://issues.apache.org/jira/browse/COMPRESS-384 > Project: Commons Compress > Issue Type: Bug > Components: Build >Affects Versions: 1.13 > Environment: Windows 10, JDK 1.8 >Reporter: Jason Shattu > Attachments: file.tar > > > I've created both a zip and tar file, with the same contents using the latest > version of 7zip. When I read both archives using code of the form: > ArchiveStreamFactory().createArchiveInputStream(format, inputStream); > I notice that both formats correctly list their contents, however the Tar > Input doesn't return a "null" entry when it hits the EOF from > archiveStream.getNextEntry() > this makes it hard to distinguish between a genuine EOF or a file which is > still being written to. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NUMBERS-25) Check list for first release
[
https://issues.apache.org/jira/browse/NUMBERS-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980211#comment-15980211
]
Gilles commented on NUMBERS-25:
---
bq. Do we need both Jenkins and Travis?
Unless I'm mistaken, Jenkins creates snapshots; the latest successfully built
artefact can then be used as a dependency in another component (namely the
development version of "Commons Math").
bq. good contributions for that "help-wanted" category.
+1
> Check list for first release
>
>
> Key: NUMBERS-25
> URL: https://issues.apache.org/jira/browse/NUMBERS-25
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Gilles
> Labels: release, tasks
> Fix For: 1.0
>
>
> List of tasks to complete before considering a first release.
> * (x) Review public API
> * Ensure clean project reports
> ** (x) JIRA
> ** (x) Surefire
> ** (x) RAT
> ** (x) Jacoco
> ** (x) FindBugs
> ** (x) Checkstyle
> ** (x) PMD
> ** (x) CPD
> * Ensure that "Commons Math" ("master" branch) compiles and pass all unit
> tests when
> ** (x) dependencies to "Commons Numbers" modules are added and
> ** (x) all classes that have an equivalent in "Commons Numbers" are deleted.
> * (x) User guide
> * (x) Jenkins
> * (x) Web site
> * (/) [GitHub|https://github.com/apache/commons-numbers]
> * (/) [Travis|https://travis-ci.org/apache/commons-numbers]
> * (x) Coveralls
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (NUMBERS-24) Create logo for Apache Commons Numbers
[ https://issues.apache.org/jira/browse/NUMBERS-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita updated NUMBERS-24: -- Attachment: commons-number-site-2017-04-23-fullpage.png > Create logo for Apache Commons Numbers > -- > > Key: NUMBERS-24 > URL: https://issues.apache.org/jira/browse/NUMBERS-24 > Project: Commons Numbers > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0 > > Attachments: commons-number-site-2017-04-23-fullpage.png > > > The project currently has no logo. There is a Commons Math logo in the > project site resources folder, that needs to be replaced by a new original > logo. > See https://www.apache.org/foundation/marks/pmcs for trademark notes too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980208#comment-15980208
]
Bruno P. Kinoshita commented on MATH-1414:
--
>It might be better for traceability to leave it open until the whole package
>is deleted.
Works for me :-)
>But if it's clear enough right now that follow-up happens in "Commons
>Numbers", no problem.
Yup, I'm still watching this issue, but will focus the work on NUMBERS-22 now.
Thanks Gilles
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
> Fix For: 4.0
>
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-25) Check list for first release
[
https://issues.apache.org/jira/browse/NUMBERS-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980207#comment-15980207
]
Bruno P. Kinoshita commented on NUMBERS-25:
---
Do we need both Jenkins and Travis? I thought some projects were being built
using just Jenkins, or just Travis.
Coveralls and User guide look like good contributions for that "help-wanted"
category. We can even break it down into sub tasks if necessary I think.
> Check list for first release
>
>
> Key: NUMBERS-25
> URL: https://issues.apache.org/jira/browse/NUMBERS-25
> Project: Commons Numbers
> Issue Type: Task
>Reporter: Gilles
> Labels: release, tasks
> Fix For: 1.0
>
>
> List of tasks to complete before considering a first release.
> * (x) Review public API
> * Ensure clean project reports
> ** (x) JIRA
> ** (x) Surefire
> ** (x) RAT
> ** (x) Jacoco
> ** (x) FindBugs
> ** (x) Checkstyle
> ** (x) PMD
> ** (x) CPD
> * Ensure that "Commons Math" ("master" branch) compiles and pass all unit
> tests when
> ** (x) dependencies to "Commons Numbers" modules are added and
> ** (x) all classes that have an equivalent in "Commons Numbers" are deleted.
> * (x) User guide
> * (x) Jenkins
> * (x) Web site
> * (/) [GitHub|https://github.com/apache/commons-numbers]
> * (/) [Travis|https://travis-ci.org/apache/commons-numbers]
> * (x) Coveralls
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980206#comment-15980206
]
Gilles commented on MATH-1414:
--
Maybe it be better for traceability to leave it open until the whole package is
deleted.
But if it's clear enough right now that follow-up happens in "Commons Numbers",
no problem.
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
> Fix For: 4.0
>
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980206#comment-15980206
]
Gilles edited comment on MATH-1414 at 4/23/17 1:26 AM:
---
It might be better for traceability to leave it open until the whole package is
deleted.
But if it's clear enough right now that follow-up happens in "Commons Numbers",
no problem.
was (Author: erans):
Maybe it be better for traceability to leave it open until the whole package is
deleted.
But if it's clear enough right now that follow-up happens in "Commons Numbers",
no problem.
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
> Fix For: 4.0
>
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1413) Add generics to Frequency
[
https://issues.apache.org/jira/browse/MATH-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980205#comment-15980205
]
Bruno P. Kinoshita commented on MATH-1413:
--
Any objections for this? Otherwise I will review the code once more, and
prepare to merge in the next days.
> Add generics to Frequency
> -
>
> Key: MATH-1413
> URL: https://issues.apache.org/jira/browse/MATH-1413
> Project: Commons Math
> Issue Type: Bug
>Reporter: Bruno P. Kinoshita
>Assignee: Bruno P. Kinoshita
>Priority: Minor
> Labels: generics
> Fix For: 4.0
>
>
> The Frequency class has no generic types, but creates an internal TreeMap,
> with keys with the type `Comparator`. Then whenever you add or get values
> from the TreeMap, it will throw CCE if you pass a key value with a different
> type from the others stored in the map.
> {code}
> Frequency f = new Frequency();
> // Okay
> f.addValue("Ola");
> // Key 12, type Integer, does not match String type. CCE, wrapped in a Math
> exception
> f.addValue(12);
> {code}
> And even a simpler example without Math classes to help outlining the issue.
> {code}
> TreeMap map = new TreeMap<>();
> int key = 1;
> map.put(key, "One");
> // Okay
> map.get(100);
> // TreeMap will try to call 1.1#compareTo against each Key it contains, which
> can result
> // in a CCE here.
> map.get(1.1);
> {code}
> It is not clear how we could compare the key type to the given v value.
> Checking if the map is not empty, and then checking the type of the first key
> doesn't sound very elegant (and not sure if it would be a valid solution).
> A better solution could be to add generics to the class, breaking the current
> contract (i.e. not allowing three types, boxing to longs, etc), but on the
> bright side, it won't use CCE as a normal workflow, nor need suppress
> warnings annotations any more.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-22) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/NUMBERS-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980204#comment-15980204
]
Bruno P. Kinoshita commented on NUMBERS-22:
---
Adding same comment I sent to MATH-1414 as I believe it may be helpful here in
NUMBERS too (also linked the ticket in JIRA).
{quote}
Trying to make sure I understand the issue in the code.
Using -2.44242319E-315 as input, here's the result in Python with NumPy.
{noformat}
>>> import numpy as np
>>> complex0 = -2.44242319e-315
>>> complex1 = np.reciprocal(complex0)
>>> complex1
-inf
>>> np.imag(complex1)
array(0.0)
{noformat}
Here's the output with GNU Octave:
{noformat}
>> complex0 = -2.44242319E-315
complex0 = -2.4424e-315
>> complex1 = 1./complex0
complex1 = -Inf
>> imag(complex1)
ans = 0
{noformat}
And in our case, as [~gjahanagirova] pointed, we get the following with the
latest code from git/master:
{noformat}
Complex complex0 = new Complex((-2.44242319E-315));
Complex complex1 = complex0.reciprocal();
System.out.println(complex1.getReal());
System.out.println(complex1.getImaginary());
# Output will be:
# -Infinity
# NaN
{noformat}
For the reciprocal value, for the three libraries the real value is -Infinity.
NumPy and Octave seem to agree that the imaginary part of the reciprocal is
0.0. But [math] says it is NaN.
>the value of complex1.getImaginary() will be NaN, instead of complex1 being
>equal to INF.
Are we sure the imaginary part of the reciprocal value must be INF, instead of
0.0 as in the other libraries?
{quote}
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: NUMBERS-22
> URL: https://issues.apache.org/jira/browse/NUMBERS-22
> Project: Commons Numbers
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
>
> I have been redirected here from the issue repository of Apache Commons Math,
> as the Complex class will likely be deprecated in favour of its equivalent in
> "Commons Numbers".
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> The suggested solutions after the discussion are either checking the equality
> to ZERO with some tolerance or to detect if one of the real or imaginary
> parts is going to be infinite or NaN and then return the proper result.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-24) Create logo for Apache Commons Numbers
[ https://issues.apache.org/jira/browse/NUMBERS-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980203#comment-15980203 ] Bruno P. Kinoshita commented on NUMBERS-24: --- I like it [~erans]! And you updated the header too. I have removed the math.gif logo and added your change to changes.xml eed94bfe84a71698fbc9b3a9e7808cd3f5f899d5 Attached updated screenshot. Site builds OK, everything looking good. Closing ticket. Cheers Bruno > Create logo for Apache Commons Numbers > -- > > Key: NUMBERS-24 > URL: https://issues.apache.org/jira/browse/NUMBERS-24 > Project: Commons Numbers > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0 > > > The project currently has no logo. There is a Commons Math logo in the > project site resources folder, that needs to be replaced by a new original > logo. > See https://www.apache.org/foundation/marks/pmcs for trademark notes too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (NUMBERS-24) Create logo for Apache Commons Numbers
[ https://issues.apache.org/jira/browse/NUMBERS-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved NUMBERS-24. --- Resolution: Fixed > Create logo for Apache Commons Numbers > -- > > Key: NUMBERS-24 > URL: https://issues.apache.org/jira/browse/NUMBERS-24 > Project: Commons Numbers > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0 > > > The project currently has no logo. There is a Commons Math logo in the > project site resources folder, that needs to be replaced by a new original > logo. > See https://www.apache.org/foundation/marks/pmcs for trademark notes too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980201#comment-15980201
]
Bruno P. Kinoshita commented on MATH-1414:
--
Should we mark this issue as Won't Fix then [~erans]?
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
> Fix For: 4.0
>
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1284) Vector is-not-a Point
[
https://issues.apache.org/jira/browse/MATH-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980159#comment-15980159
]
Raymond DeCampo commented on MATH-1284:
---
I agree with the issue as reported; from a mathematical POV a vector is not a
point.
>From a CS POV I am having trouble seeing the value that having the interface
>{{Vector}} extending the interface {{Point}} brings. In fact, by having
>{{Vector}} extend {{Point}}, one ends up with a method in your {{Vector}}
>implementation where one is ostensibly calculating the "distance from a vector
>to a point". This isn't really satisfying to me from a mathematical or CS
>perspective. The implementations of the {{Point}} {{distance()}} method in
>{{Vector}} implementations all immediately cast the {{Point}} to a {{Vector}}
>implementation.
I will prepare a branch with a proposal for resolving this issue.
> Vector is-not-a Point
> -
>
> Key: MATH-1284
> URL: https://issues.apache.org/jira/browse/MATH-1284
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.5
>Reporter: Roman Werpachowski
>Priority: Minor
> Fix For: 4.0
>
>
> The class hierarchy for geometry claims that Vector is-a Point:
> https://commons.apache.org/proper/commons-math/apidocs/org/apache/commons/math3/geometry/Point.html
> This is mathematically incorrect, see e.g.
> http://math.stackexchange.com/a/645827
> Just because they share the same numerical representation, Point and Vector
> shouldn't be crammed into a common class hierarchy.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #263: Use String#contains where possible
Github user PascalSchumacher commented on the issue: https://github.com/apache/commons-lang/pull/263 Thanks! --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang pull request #263: Use String#contains where possible
Github user asfgit closed the pull request at: https://github.com/apache/commons-lang/pull/263 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #263: Use String#contains where possible
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/263 [](https://coveralls.io/builds/11196975) Coverage remained the same at 94.655% when pulling **8fff6277fd22866753be3d2b3d717a32fba428a3 on mureinik:contains** into **8cafd87c83f4197f7e8d14de8cba453c844266c0 on apache:master**. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang pull request #263: Use String#contains where possible
GitHub user mureinik opened a pull request: https://github.com/apache/commons-lang/pull/263 Use String#contains where possible Since the project defines a JDK 7 source compatibility, it's safe to use JDK 5's features. This patch replaces usages of `String#indexOf` with `String#contains` where possible to make the code easier to read and maintain. You can merge this pull request into a Git repository by running: $ git pull https://github.com/mureinik/commons-lang contains Alternatively you can review and apply these changes as the patch at: https://github.com/apache/commons-lang/pull/263.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #263 commit 8fff6277fd22866753be3d2b3d717a32fba428a3 Author: Allon Mureinik Date: 2017-04-22T19:59:38Z Use String#contains where possible Since the project defines a JDK 7 source compatibility, it's safe to use JDK 5's features. This patch replaces usages of String#indexOf with String#contains where possible to make the code easier to read and maintain. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (COMPRESS-384) Tar File EOF not being detected
[ https://issues.apache.org/jira/browse/COMPRESS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980046#comment-15980046 ] Stefan Bodewig commented on COMPRESS-384: - Yes, I'm afraid what you are doing won't work for general formats. For tar it should signal EOF after it has read two consecutive 512 byte blocks of zeros after an entry has been finished, but not all tar archivers create these blocks. Looking at you archive I see a lot of trailing zeros, so there maybe something strange going on here, I'll look into it. > Tar File EOF not being detected > --- > > Key: COMPRESS-384 > URL: https://issues.apache.org/jira/browse/COMPRESS-384 > Project: Commons Compress > Issue Type: Bug > Components: Build >Affects Versions: 1.13 > Environment: Windows 10, JDK 1.8 >Reporter: Jason Shattu > Attachments: file.tar > > > I've created both a zip and tar file, with the same contents using the latest > version of 7zip. When I read both archives using code of the form: > ArchiveStreamFactory().createArchiveInputStream(format, inputStream); > I notice that both formats correctly list their contents, however the Tar > Input doesn't return a "null" entry when it hits the EOF from > archiveStream.getNextEntry() > this makes it hard to distinguish between a genuine EOF or a file which is > still being written to. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (COMPRESS-384) Tar File EOF not being detected
[ https://issues.apache.org/jira/browse/COMPRESS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Shattu updated COMPRESS-384: -- ok, I thought you said earlier that an EOF tar file was marked by a number of Zeros. But I accept your more general point that most of the Archives Formats don't know when the Archive ends other than when their is no more data. Yes, my FilterInputStream is feeding the TarArchiveInputStream. With the Zip Format, getNextEntry() returns a null whereas for Tar it just blocks, using my FilterInputStream. I presume this is because the ZIP has already detected the end of the archive through its specific end of archive marker. All your questions are sensible, and i'm not explaining in that well, because I’m not at the code and I’m doing it from memory. The scenario I'm trying to cater for is as follows:- Process 1 -> Slowly creates a Large Archive on the File System. Process 2 -> Reads this Large Archive from the same File System. If Process 2 is Faster than Process 1 it will hit an EOF and assume their are no more entries in the file. However, I need it to block until Process 1 is finished. Hence to support this behaviour I need to implement blocking with FilterInputStream. This works better with Zip coz it knows when the archive has finished and can cleanup the blocking reading process. Doesn't look we can be so clean with the Tar Archive though. Thanks, Jason > Tar File EOF not being detected > --- > > Key: COMPRESS-384 > URL: https://issues.apache.org/jira/browse/COMPRESS-384 > Project: Commons Compress > Issue Type: Bug > Components: Build >Affects Versions: 1.13 > Environment: Windows 10, JDK 1.8 >Reporter: Jason Shattu > Attachments: file.tar > > > I've created both a zip and tar file, with the same contents using the latest > version of 7zip. When I read both archives using code of the form: > ArchiveStreamFactory().createArchiveInputStream(format, inputStream); > I notice that both formats correctly list their contents, however the Tar > Input doesn't return a "null" entry when it hits the EOF from > archiveStream.getNextEntry() > this makes it hard to distinguish between a genuine EOF or a file which is > still being written to. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (MATH-1415) Update "Commons" main site
Gilles created MATH-1415: Summary: Update "Commons" main site Key: MATH-1415 URL: https://issues.apache.org/jira/browse/MATH-1415 Project: Commons Math Issue Type: Task Reporter: Gilles Priority: Minor "Commons Numbers" should appear on the "Commons" web page. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Moved] (NUMBERS-26) Update "Commons" main site
[ https://issues.apache.org/jira/browse/NUMBERS-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles moved MATH-1415 to NUMBERS-26: - Workflow: jira (was: classic default workflow) Key: NUMBERS-26 (was: MATH-1415) Project: Commons Numbers (was: Commons Math) > Update "Commons" main site > -- > > Key: NUMBERS-26 > URL: https://issues.apache.org/jira/browse/NUMBERS-26 > Project: Commons Numbers > Issue Type: Task >Reporter: Gilles >Priority: Minor > Labels: web-site > > "Commons Numbers" should appear on the "Commons" web page. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1354) Easy conversion from BigDecimal to BigFraction
[
https://issues.apache.org/jira/browse/MATH-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-1354:
-
Labels: commons-numbers (was: )
Fix Version/s: (was: 4.X)
4.0
Issue to be moved to NUMBERS.
> Easy conversion from BigDecimal to BigFraction
> --
>
> Key: MATH-1354
> URL: https://issues.apache.org/jira/browse/MATH-1354
> Project: Commons Math
> Issue Type: Wish
>Reporter: Dobes Vandermeer
> Labels: commons-numbers
> Fix For: 4.0
>
>
> Users of BigFraction might also be working with BigDecimal. Here's a simple
> way to convert BigDecimal to BigFraction:
> {code}
> public static BigFraction bigDecimalToBigFraction(BigDecimal bd) {
> int scale = bd.scale();
> // If scale >= 0 then the value is bd.unscaledValue() / 10^scale
> if(scale >= 0)
> return new BigFraction(bd.unscaledValue(),
> BigInteger.TEN.pow(scale));
> // If scale < 0 then the value is bd.unscaledValue() * 10^-scale
> return new
> BigFraction(bd.unscaledValue().multiply(BigInteger.TEN.pow(-scale)));
> }
> {code}
> It might be nice to have this incorporated into the BigFraction class as a
> constructor.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (MATH-1239) Add a fast sequential random sampler method
[ https://issues.apache.org/jira/browse/MATH-1239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles resolved MATH-1239. -- Resolution: Won't Do Fix Version/s: (was: 4.X) ["Commons RNG"|http://commons.apache.org/proper/commons-rng] would be a better home for this kind of features. > Add a fast sequential random sampler method > --- > > Key: MATH-1239 > URL: https://issues.apache.org/jira/browse/MATH-1239 > Project: Commons Math > Issue Type: Sub-task >Reporter: Thomas Neidhart > > Many applications need a fast way to randomly select n samples from a > population without replacement. > So far the best way seems to be the method proposed by Vitter in the > following paper: > http://www.mathcs.emory.edu/~cheung/papers/StreamDB/RandomSampling/1984-Vitter-Faster-random-sampling.pdf > A comparison with other methods can be found here (same author): > https://hal.archives-ouvertes.fr/inria-00075929/document -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1332) For 4.0, deprecate method name getArgument() and replace with arg()
[ https://issues.apache.org/jira/browse/MATH-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-1332: - Docs Text: Issue must be moved to NUMBERS. Labels: commons-numbers (was: ) Fix Version/s: (was: 4.X) 4.0 > For 4.0, deprecate method name getArgument() and replace with arg() > --- > > Key: MATH-1332 > URL: https://issues.apache.org/jira/browse/MATH-1332 > Project: Commons Math > Issue Type: Improvement >Reporter: Eric Barnhill >Priority: Trivial > Labels: commons-numbers > Fix For: 4.0 > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Currently magnitude of complex is returned by calling abs while phase angle > is returned by calling getArgument(). I propose deprecating getArgument and > using arg() because: > -- it's not really an accessor method since the argument is computed > -- arg() is shorter, more elegant and similar to abs() with which its usage > will sometimes be paired -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-1414:
-
Fix Version/s: (was: 4.X)
4.0
Issue has been moved to NUMBERS-22.
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
> Fix For: 4.0
>
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1353) "EmpiricalDistribution" has various shortcomings
[ https://issues.apache.org/jira/browse/MATH-1353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-1353: - Fix Version/s: (was: 4.X) 4.0 > "EmpiricalDistribution" has various shortcomings > > > Key: MATH-1353 > URL: https://issues.apache.org/jira/browse/MATH-1353 > Project: Commons Math > Issue Type: Improvement >Reporter: Gilles >Priority: Minor > Labels: refactoring > Fix For: 4.0 > > > * Class uses file IO (CM should not be concerned with data persistence) > * Class uses the "java.net" API (ditto) > I'd think that the core functionality could be provided without supporting > data loading (from a file or a URL). > Data input would be via any of > * Collection > * Iterable > * Stream (Java 8) > A redesign goal should be to make the class immutable. > E.g. data source must be set in the constructor (rather than via a "load" > method); there would thus be a one-to-one correspondence between data source > and distribution instance. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-667) Representations of the complex numbers
[
https://issues.apache.org/jira/browse/MATH-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated MATH-667:
Labels: commons-numbers features (was: features)
Fix Version/s: (was: 4.X)
4.0
Issue must be moved to NUMBERS.
> Representations of the complex numbers
> --
>
> Key: MATH-667
> URL: https://issues.apache.org/jira/browse/MATH-667
> Project: Commons Math
> Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
> Labels: commons-numbers, features
> Fix For: 4.0
>
>
> Several issues have been raised about the current behaviour of the "Complex"
> class, located in package "o.a.c.m.complex" (e.g. MATH-657, MATH-620).
> The ensuing discussion revealed various, sometimes incompatible, requirements
> with focus on efficiency or consistency or backwards compatibility or
> comparison with other math packages (Octave) or faithfulness to standards
> (C99x).
> It is thus proposed to create several classes, each with a clearly defined
> purpose.
> The consensus seems to be that the first task is to implement a new
> "BasicComplex" class where the computational formulae (for computing real and
> imaginary part of a complex) will be applied directly without worrying about
> limiting cases (NaNs and infinities). Doing so will automatically produce a
> behaviour similar to the Java {{double}} primitive. It is also assumed that
> it will be the most efficient implementation for "normal" use (i.e. not
> involving limiting cases).
> This task would consist in copying most of the code in the existing "Complex"
> class over to "BasicComplex". And similarly with "ComplexTest". Then, in
> "BasicComplex", one would remove all variables that refer to NaNs and
> infinities together with checks and special assignments, and adapt the unit
> tests along the way.
> A new "ExtendedComplex" class would inherit from "BasicComplex". This class
> would aim at representing the compactified space of the complex numbers (one
> point-at-infinity).
> A new "C99Complex" class would inherit from "BasicComplex". This class would
> aim at implementing the C99x standard.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1331) Addition of accesor methods for abs() and getArgument() of Complex-valued arrays
[ https://issues.apache.org/jira/browse/MATH-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilles updated MATH-1331: - Affects Version/s: (was: 4.0) Labels: commons-numbers math (was: math) Fix Version/s: (was: 4.X) 4.0 Issue must be moved to NUMBERS. > Addition of accesor methods for abs() and getArgument() of Complex-valued > arrays > > > Key: MATH-1331 > URL: https://issues.apache.org/jira/browse/MATH-1331 > Project: Commons Math > Issue Type: Improvement >Reporter: Eric Barnhill >Priority: Minor > Labels: commons-numbers, math > Fix For: 4.0 > > Original Estimate: 20m > Remaining Estimate: 20m > > Propose to add array-based accessor methods for the abs() and getArgument() > functions of Complex objects and add them to ComplexUtils. These would be: > Complex[] abs(Complex[] c) > also in 2 and 3D, and > Complex[] getArgument(Complex[] c) > Following the documentation and other conventions currently found in > ComplexUtils. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COMPRESS-384) Tar File EOF not being detected
[ https://issues.apache.org/jira/browse/COMPRESS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15980001#comment-15980001 ] Stefan Bodewig commented on COMPRESS-384: - You are correct, tar and zip deal with EOF differently as zip has an internal structure that signals the end of the readable content while tar simply has to read until it hits EOF. Many archivers won't know when the archive is finished until they hit EOF, cpio or ar are in the same boat. 7zip on the other hand has a structure that allows it to know the archive is finished as well. What zip and 7zip share is some kind of table of contents stored internally while tar and others really are just a stream of consecutive entries without any relation to each other and they only know they are done when there is no next entry. I think I had it backwards at first, sorry. So your FilterInputStream is the one TarArchiveInputStream is reading from, right? Then you use getNextEntry to read entries from the tar stream wrapping your blocking stream. What exactly happens that you didn't expect? I'm sorry if I sound stupid, but it still isn't clear to me. > Tar File EOF not being detected > --- > > Key: COMPRESS-384 > URL: https://issues.apache.org/jira/browse/COMPRESS-384 > Project: Commons Compress > Issue Type: Bug > Components: Build >Affects Versions: 1.13 > Environment: Windows 10, JDK 1.8 >Reporter: Jason Shattu > Attachments: file.tar > > > I've created both a zip and tar file, with the same contents using the latest > version of 7zip. When I read both archives using code of the form: > ArchiveStreamFactory().createArchiveInputStream(format, inputStream); > I notice that both formats correctly list their contents, however the Tar > Input doesn't return a "null" entry when it hits the EOF from > archiveStream.getNextEntry() > this makes it hard to distinguish between a genuine EOF or a file which is > still being written to. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (COMPRESS-384) Tar File EOF not being detected
[ https://issues.apache.org/jira/browse/COMPRESS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Shattu updated COMPRESS-384: -- Well to be precise the FilterInputStream, reads the underlying input, if it is -1 then it sleeps the thread for a small period and then tries again. If it has some data it returns back to requesting the Input Stream. It repeats this indefinitely. Although I can configure it to timeout. If i sleep the thread then naturally the compression is blocked at the same time. This is all to do with having flexibility to deal with very slow realtime archive producers. Admittedly this is an advanced use case,but given the nature of streams I think it should support this. It looks like the TAR format isn't dealing with EOF in quite the same way as ZIP. Jason On 22 Apr 2017 15:55, "Stefan Bodewig (JIRA)" wrote: [ https://issues.apache.org/jira/browse/COMPRESS-384?page= com.atlassian.jira.plugin.system.issuetabpanels:comment- tabpanel&focusedCommentId=15979965#comment-15979965 ] Stefan Bodewig commented on COMPRESS-384: - Maybe I'm starting to understand. So your FilterInputStream blocks on read if the underlying stream doesn't provide any data right now. What are you expecting the underlying stream to do, i.e. when are you blocking and when do you assume the stream has been exhausted and return -1 from read in the implementation of your own? latest version of 7zip. When I read both archives using code of the form: Input doesn't return a "null" entry when it hits the EOF from archiveStream.getNextEntry() is still being written to. -- This message was sent by Atlassian JIRA (v6.3.15#6346) > Tar File EOF not being detected > --- > > Key: COMPRESS-384 > URL: https://issues.apache.org/jira/browse/COMPRESS-384 > Project: Commons Compress > Issue Type: Bug > Components: Build >Affects Versions: 1.13 > Environment: Windows 10, JDK 1.8 >Reporter: Jason Shattu > Attachments: file.tar > > > I've created both a zip and tar file, with the same contents using the latest > version of 7zip. When I read both archives using code of the form: > ArchiveStreamFactory().createArchiveInputStream(format, inputStream); > I notice that both formats correctly list their contents, however the Tar > Input doesn't return a "null" entry when it hits the EOF from > archiveStream.getNextEntry() > this makes it hard to distinguish between a genuine EOF or a file which is > still being written to. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COMPRESS-384) Tar File EOF not being detected
[ https://issues.apache.org/jira/browse/COMPRESS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979965#comment-15979965 ] Stefan Bodewig commented on COMPRESS-384: - Maybe I'm starting to understand. So your FilterInputStream blocks on read if the underlying stream doesn't provide any data right now. What are you expecting the underlying stream to do, i.e. when are you blocking and when do you assume the stream has been exhausted and return -1 from read in the implementation of your own? > Tar File EOF not being detected > --- > > Key: COMPRESS-384 > URL: https://issues.apache.org/jira/browse/COMPRESS-384 > Project: Commons Compress > Issue Type: Bug > Components: Build >Affects Versions: 1.13 > Environment: Windows 10, JDK 1.8 >Reporter: Jason Shattu > Attachments: file.tar > > > I've created both a zip and tar file, with the same contents using the latest > version of 7zip. When I read both archives using code of the form: > ArchiveStreamFactory().createArchiveInputStream(format, inputStream); > I notice that both formats correctly list their contents, however the Tar > Input doesn't return a "null" entry when it hits the EOF from > archiveStream.getNextEntry() > this makes it hard to distinguish between a genuine EOF or a file which is > still being written to. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (COMPRESS-384) Tar File EOF not being detected
[ https://issues.apache.org/jira/browse/COMPRESS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Shattu updated COMPRESS-384: -- Yep, i'm doing something slightly novel, but I would expect to still be supported by the library. so given something like ArchiveInputStream archiveStream = new ArchiveStreamFactory().createArchiveInputStream(format, stream); The stream I pass into the factory is not just a straightforward FileInputStream, but a FileInputStream that is wrapped using a FilterInputStream, which deliberately blocks if there is no more data. The reason I do this, is that I might have a separate slow running process generating the tar file and the processing reading the tar file doesn't know when it had ended. Perhaps there is a better way to do this so please advise. In any case, this approach works nicely with Zip Archives but not with Tar file. Does that make sense? Thanks, Jason > Tar File EOF not being detected > --- > > Key: COMPRESS-384 > URL: https://issues.apache.org/jira/browse/COMPRESS-384 > Project: Commons Compress > Issue Type: Bug > Components: Build >Affects Versions: 1.13 > Environment: Windows 10, JDK 1.8 >Reporter: Jason Shattu > Attachments: file.tar > > > I've created both a zip and tar file, with the same contents using the latest > version of 7zip. When I read both archives using code of the form: > ArchiveStreamFactory().createArchiveInputStream(format, inputStream); > I notice that both formats correctly list their contents, however the Tar > Input doesn't return a "null" entry when it hits the EOF from > archiveStream.getNextEntry() > this makes it hard to distinguish between a genuine EOF or a file which is > still being written to. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1332) For 4.0, deprecate method name getArgument() and replace with arg()
[ https://issues.apache.org/jira/browse/MATH-1332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1332: --- Fix Version/s: (was: 4.0) 4.X > For 4.0, deprecate method name getArgument() and replace with arg() > --- > > Key: MATH-1332 > URL: https://issues.apache.org/jira/browse/MATH-1332 > Project: Commons Math > Issue Type: Improvement >Reporter: Eric Barnhill >Priority: Trivial > Fix For: 4.X > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > Currently magnitude of complex is returned by calling abs while phase angle > is returned by calling getArgument(). I propose deprecating getArgument and > using arg() because: > -- it's not really an accessor method since the argument is computed > -- arg() is shorter, more elegant and similar to abs() with which its usage > will sometimes be paired -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1372) Add argmin/argmax static functions to MathArrays utility class
[ https://issues.apache.org/jira/browse/MATH-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1372: --- Fix Version/s: 4.0 > Add argmin/argmax static functions to MathArrays utility class > -- > > Key: MATH-1372 > URL: https://issues.apache.org/jira/browse/MATH-1372 > Project: Commons Math > Issue Type: Wish >Reporter: Artem Barger >Assignee: Artem Barger >Priority: Trivial > Fix For: 4.0 > > Attachments: MATH-1372.patch > > > Following conversation in the ML thread. > Working lately w/ CM, I've found myself using a lot functions which helps to > identify the index of the min/max elements in given array of doubles. > In ML it was pointed out that similar functionality already exists in > RealVector, however due to MATH-765 it's planned to be removed (deprecated), > moreover to use it one has to create an instance of RealVector, where for > simple cases it might be redundant. > Hence I'd like to propose to add these static methods to the MathArrays > utility class. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1347) Wrong equation in Javadoc of Percentile.EstimationType, LEGACY, variable estimation
[ https://issues.apache.org/jira/browse/MATH-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1347: --- Fix Version/s: 4.0 > Wrong equation in Javadoc of Percentile.EstimationType, LEGACY, variable > estimation > --- > > Key: MATH-1347 > URL: https://issues.apache.org/jira/browse/MATH-1347 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.6 > Environment: Windows 7 >Reporter: Richard Brunauer >Priority: Trivial > Labels: documentation > Fix For: 4.0 > > Original Estimate: 1h > Remaining Estimate: 1h > > The Javadoc entry for Enum Percentile.EstimationType LAGACY uses a wrong > equation for variable estimate. > Explaination in version 3.0, 3.6 source code and 3.6 semantics do an > interpolation between two values. The quation for variable estimation has > only a ceiling function. This does not match. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1386) EPSILON value in org.apache.commons.math.util.MathUtils seems like half of what it should be
[ https://issues.apache.org/jira/browse/MATH-1386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1386: --- Fix Version/s: 4.X > EPSILON value in org.apache.commons.math.util.MathUtils seems like half of > what it should be > - > > Key: MATH-1386 > URL: https://issues.apache.org/jira/browse/MATH-1386 > Project: Commons Math > Issue Type: Wish > Environment: win 7 >Reporter: Brian S. McCormick >Priority: Trivial > Fix For: 4.X > > Original Estimate: 1h > Remaining Estimate: 1h > > I've always used 1.1920929E-7 for dealing with float epsilon values. When > dealing with double I've always used 2.220446049250313E-16 for epsilon. > You have it defined in org.apache.commons.math.util.MathUtils as > 1.1102230246251565E-16 which is half what I think it should be. > I come up with these numbers using the following: > float fEps = Float.intBitsToFloat(Float.floatToIntBits(1f) + 1) - 1; > double dEps = Double.longBitsToDouble(Double.doubleToLongBits(1) + 1) - 1; > Am I correct? I don't really know. I do know that float epsilon in every > legacy C/C++ compiler etc I have ever used is defined as about 1e-7 and this > is the value using the formula for fEps above. When I started doing comps > using doubles instead of floats I started using the formula for dEps above > which looks to me like the equivalent for double numbers. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1382) MultivariateNormalDistribution.density() unnecessarily copies means array in loop
[ https://issues.apache.org/jira/browse/MATH-1382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1382: --- Fix Version/s: 4.0 > MultivariateNormalDistribution.density() unnecessarily copies means array in > loop > - > > Key: MATH-1382 > URL: https://issues.apache.org/jira/browse/MATH-1382 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.6.1 >Reporter: Stefan Bunk >Priority: Trivial > Labels: easyfix > Fix For: 4.0 > > > In the class MultivariateNormalDistribution, the public method density() > calls the private method getExponentTerm(), which first centers the given > instance by the mean. > However, it is using the method getMeans(), which creates a copy of means > array each time, just for reading the i-th index. > See > https://github.com/apache/commons-math/blob/3.6.1-release/src/main/java/org/apache/commons/math3/distribution/MultivariateNormalDistribution.java#L238 > A solution should use the private variable `means` directly. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1298) Aggregation should be supported for DescriptiveStatistics
[ https://issues.apache.org/jira/browse/MATH-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1298: --- Fix Version/s: 4.X > Aggregation should be supported for DescriptiveStatistics > - > > Key: MATH-1298 > URL: https://issues.apache.org/jira/browse/MATH-1298 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 3.5 >Reporter: Phil Steitz >Priority: Minor > Fix For: 4.X > > > DescriptiveStatistics should support aggregation as SummaryStatistics do. An > API similar to AggregateSummaryStatistics should be exposed for > DescriptiveStatistics. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-621:
--
Fix Version/s: (was: 4.0)
4.X
> BOBYQA is missing in optimization
> -
>
> Key: MATH-621
> URL: https://issues.apache.org/jira/browse/MATH-621
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Dr. Dietmar Wolz
> Fix For: 4.X
>
> Attachments: bobyqa_convert.pl, BOBYQA.math.patch,
> bobyqaoptimizer0.4.zip, BOBYQAOptimizer0.4.zip, BOBYQAOptimizer.java.patch,
> BOBYQA.v02.math.patch, bobyqav0.3.zip, bobyqa.zip
>
>
> During experiments with space flight trajectory optimizations I recently
> observed, that the direct optimization algorithm BOBYQA
> http://plato.asu.edu/ftp/other_software/bobyqa.zip
> from Mike Powell is significantly better than the simple Powell algorithm
> already in commons.math. It uses significantly lower function calls and is
> more reliable for high dimensional problems. You can replace CMA-ES in many
> more application cases by BOBYQA than by the simple Powell optimizer.
> I would like to contribute a Java port of the algorithm.
> I maintained the structure of the original FORTRAN code, so the
> code is fast but not very nice.
> License status: Michael Powell has sent the agreement via snail mail
> - it hasn't arrived yet.
> Progress: The attached patch relative to the trunk contains both the
> optimizer and the related unit tests - which are all green now.
> Performance:
> Performance difference (number of function evaluations)
> PowellOptimizer / BOBYQA for different test functions (taken from
> the unit test of BOBYQA, dimension=13 for most of the
> tests.
> Rosen = 9350 / 1283
> MinusElli = 118 / 59
> Elli = 223 / 58
> ElliRotated = 8626 / 1379
> Cigar = 353 / 60
> TwoAxes = 223 / 66
> CigTab = 362 / 60
> Sphere = 223 / 58
> Tablet = 223 / 58
> DiffPow = 421 / 928
> SsDiffPow = 614 / 219
> Ackley = 757 / 97
> Rastrigin = 340 / 64
> The number for DiffPow should be discussed with Michael Powell,
> I will send him the details.
> h3. Open Problems
> * Checkstyle violations[1] because of the original Fortran source:
> ** Original method comments were copied: Javadoc standard documentation
> should be added, but the original documentation should stay (as a reference
> to what the original intended behaviour was) untouched until we are sure that
> the code behaves as expected.
> ** Multiple variable declarations per line.
> ** "goto" conversions:
> *** "goto"s not convertible in loops were translated into a finite automaton
> (switch statement)
> *** "no default in switch"
> *** "fall through from previous case in switch"
> * Unexplored code paths: "throw" statements have been introduced in the code.
> Each should be triggered by at least one unit test. They are currently
> commented out in provision of the 3.0 release (cf. MATH-712) but should be
> re-enabled afterwards.
> [1] Once the violations are solved, the following lines should be removed
> from the source file:
> * {{// CHECKSTYLE: stop all}}
> * {{//CHECKSTYLE: resume all}}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1414) Method reciprocal() in Complex for complex numbers with parts very close to 0.0
[
https://issues.apache.org/jira/browse/MATH-1414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1414:
---
Fix Version/s: 4.X
> Method reciprocal() in Complex for complex numbers with parts very close to
> 0.0
> ---
>
> Key: MATH-1414
> URL: https://issues.apache.org/jira/browse/MATH-1414
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Gunel Jahangirova
>Priority: Minor
> Fix For: 4.X
>
>
> In class Complex method reciprocal() returns INF only if the real and
> imaginary parts are exactly equal to 0.0. In the cases when real and
> imaginary parts are double numbers very close to 0.0, it does not hold. For
> example, if we run this code
> {code}
> Complex complex0 = new Complex((-2.44242319E-315));
> Complex complex1 = complex0.reciprocal();
> {code}
> the value of complex1.getReal() will be -Infinity and the value of
> complex1.getImaginary() will be NaN, instead of complex1 being equal to INF.
> I think the code in the method
> {code}
> if (real == 0.0 && imaginary == 0.0) {
> return INF;
> }
> {code}
> should be replaced by the equality check with some tolerance (0.01 in this
> case):
> {code}
> if (equals(this, ZERO, 0.01)) {
> return INF;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1385) java.lang.OutOfMemoryError: GC overhead limit exceeded
[ https://issues.apache.org/jira/browse/MATH-1385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1385: --- Fix Version/s: 4.0 > java.lang.OutOfMemoryError: GC overhead limit exceeded > -- > > Key: MATH-1385 > URL: https://issues.apache.org/jira/browse/MATH-1385 > Project: Commons Math > Issue Type: Bug > Environment: Windows 10, jdk 8, Netbeans 8.1 >Reporter: Pasquale Calorigero > Fix For: 4.0 > > > I'm writing code for shorttime fourier transform , but jvm return this error > Exception in thread "main" java.lang.OutOfMemoryError: GC overhead limit > exceeded > at > org.apache.commons.math3.transform.TransformUtils.createComplexArray(TransformUtils.java:138) > at > org.apache.commons.math3.transform.FastFourierTransformer.transform(FastFourierTransformer.java:376) > Seems that your code everytime that compute fft , causes the execution of gc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-765) Refactoring the vector and matrix classes
[
https://issues.apache.org/jira/browse/MATH-765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-765:
--
Fix Version/s: (was: 4.0)
4.X
> Refactoring the vector and matrix classes
> -
>
> Key: MATH-765
> URL: https://issues.apache.org/jira/browse/MATH-765
> Project: Commons Math
> Issue Type: Improvement
>Affects Versions: 3.3
>Reporter: Sébastien Brisard
> Labels: api-change, linear
> Fix For: 4.X
>
>
> {panel:title=Warning|borderStyle=solid}
> This is not a bug report, but rather a summary of all discussions which have
> taken place on the mailing list regarding the refactoring of the vector and
> matrix classes. Indeed, it has been argued many times that the {{RealVector}}
> and {{RealMatrix}} interfaces are really cluttered, and could benefit from
> other approaches (like functional programming).
> The description of this ticket will be updated as the discussion progresses
> on the mailing-list, and new JIRA tickets will be created to carry out the
> "real" work. {color:red}In order to keep this ticket tidy, contributors
> should refrain from commenting on this website. Instead, messages should be
> posted on the dev mailing-list{color}.
> {panel}
> h1. The current API (version 3.0)
> In this section, the current interfaces for vectors and matrices are
> compared. Vectors and matrices are two mathematical objects which are very
> close in nature. Their implementations should therefore be as similar as
> possible. The methods will be sorted as follows
> * methods reflecting the mathematical structure of vector space: addition,
> multiplication by a scalar, matrix-vector product, ...
> * methods reflecting the mathematical structure of euclidean space
> * ...
> h2. Methods reflecting the mathematical structure of vector space
> h3. List of the methods
> || {{RealVector}}|| {{RealMatrix}}
>|| Comments ||
> | {{RealVector add(RealVector v)}} | {{RealMatrix add(RealMatrix
> m)}} | |
> | {{RealVector subtract(RealVector v)}} | {{RealMatrix
> subtract(RealMatrix m)}} | |
> | {{int getDimension()}} | {{int getRowDimension()}},\\
> {{int getColumnDimension()}} | |
> | {{RealVector mapMultiply(double d)}} | {{scalarMultiply(double d)}}
>| (1) |
> | {{RealVector mapMultiplyToSelf(double d)}} |
>| |
> | {{RealVector outerProduct(RealVector v)}} |
>| |
> || {{double getTrace()}}
>| |
> || {{multiply(RealMatrix m)}}
>| |
> || {{double[] operate(double[])}}
>| (2) |
> || {{RealVector
> operate(RealVector)}}| |
> || {{RealMatrix power(int p)}}
>| |
> || {{double[]
> preMultiply(double[])}}| (2) |
> || {{RealMatrix
> preMultiply(RealMatrix)}}| |
> || {{RealVector
> preMultiply(RealVector)}}| |
> || {{RealMatrix transpose()}}
>| |
> h3. Comments on the above methods
> h4. Comment (1)
> {{RealVector RealVector.mapMultiply(double)}} and {{RealMatrix
> RealMatrix.scalarMultiply(double)}} perform essentially the same task.
> Readibility of the classes would be improved if they add the same name. This
> is very important since these methods reflect the fact that the space of
> vectors as well as the space of matrices are two vector spaces.
> h4. Comment (2)
> Prior to the release of version 3.0, all methods taking as argument, or
> returning, {{double[]}} as a representation of vectors were removed. The
> rationale for this is that calling {{new ArrayRealVector(double[], false)}}
> is very easy, and comes at virtually no cost (see MATH-653 and MATH-660). It
> might be worth considering the same simplification for the {{RealMatrix}}
> interface.
> h2. Methods reflecting the mathematical structure of euclidean space
> h3. List of the methods
> || {{RealVector}}
[jira] [Updated] (MATH-1391) Simplex method intermediate solutions
[
https://issues.apache.org/jira/browse/MATH-1391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1391:
---
Fix Version/s: 4.0
> Simplex method intermediate solutions
> -
>
> Key: MATH-1391
> URL: https://issues.apache.org/jira/browse/MATH-1391
> Project: Commons Math
> Issue Type: Improvement
>Reporter: Konstantin Bryazgin
> Fix For: 4.0
>
>
> I suggest allowing access to intermediate solutions of simplex algorithm (not
> final vertexes at polyhedron). It can be useful for progress illustrating or
> early interrupting of process.
> It can be like this:
> {code}
> SimplexSolver simplexSolver = new SimplexSolver();
> // ... prepare constraintSet and goalFunction
> simplexSolver.setSimplexSolverInterceptor(new SimplexSolverInterceptor() {
> public boolean intercept(PointValuePair pointValuePair) {
> // pointValuePair is intermediate solution
> // return if the optimization must be stopped here
> return false;
> }
> });
> PointValuePair pair = simplexSolver.optimize(goalFunction, constraintSet,
> GoalType.MINIMIZE);
> {code}
> I needed it, so I've done it. Commit is here:
> https://github.com/kosbr/commons-math/commit/20f6c3d7428b7e5d5c695af7c4f51df979245297
>
> Here is the description of what I've done in my blog.
> https://kosbr.github.io/2016/11/07/simplex-interceptor.html
> I'm able to do the same enhancement to the commons-math library respecting
> rules like commit name.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-1404) Test failure which occur with LC_ALL=en_US.UTF8, but not with LC_ALL=de_DE.UTF-8
[ https://issues.apache.org/jira/browse/MATH-1404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1404: --- Fix Version/s: 4.0 > Test failure which occur with LC_ALL=en_US.UTF8, but not with > LC_ALL=de_DE.UTF-8 > > > Key: MATH-1404 > URL: https://issues.apache.org/jira/browse/MATH-1404 > Project: Commons Math > Issue Type: Bug >Reporter: Karl Richter > Fix For: 4.0 > > > Specifying `LC_ALL=en_US.UTF-8` causes test failures like > `RandomUtilsDataGeneratorJDKSecureRandomTest>RandomUtilsDataGeneratorAbstractTest.testNextLongNegativeRange:99->RandomUtilsDataGeneratorAbstractTest.checkNextLongUniform:130 > Chisquare test failed p-value = 0.0082266579945659 chisquare statistic = > 25.3040006.` which don't seem to occur with `LC_ALL=de_DE.UTF-8`, see > https://travis-ci.org/krichter722/commons-math/jobs/205896548 for details -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (COMPRESS-382) OutOfMemoryError from CompressorStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979944#comment-15979944
]
Luis Filipe Nassif edited comment on COMPRESS-382 at 4/22/17 2:16 PM:
--
Good work Tim! I think the wrapping IOException is a good workaround. Making
CompressorMemoryLimitException a RuntimeException is worse, making it extend an
IOException, like tukanni MemoryLimitException, makes less sense to me.
Maybe throwing a normal IOException with the original exception as cause is
sufficient? The cause can be checked in CompressorStreamFactory so no need to
create a new type of IOException?
was (Author: lfcnassif):
Good work Tim! I think the wrapping IOException is a good workaround. Making
CompressorMemoryLimitException a RuntimeException is worse, making it extend an
IOException, like tukanni MemoryLimitException, makes less sense to me.
Maybe throwing a normal IOException with the original exception as cause is
sufficient? The cause can be checked in CompressorStreamFactory so no need to
create a new IOException?
> OutOfMemoryError from CompressorStreamFactory
> -
>
> Key: COMPRESS-382
> URL: https://issues.apache.org/jira/browse/COMPRESS-382
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.10, 1.11, 1.12
> Environment: Windows7, jre1.8.0_101 x64
>Reporter: Luis Filipe Nassif
> Attachments: data.mui
>
>
> While using Tika-1.14 to detect file types, the attached 1KB file triggered
> an OOME with 1GB heap. Tika calls
> CompressorStreamFactory.createCompressorInputStream(in) to detect if the file
> is a compressor stream, but CompressorStreamFactory erroneously detects it as
> a LZMACompressorInputStream and when the LZMACompressorInputStream is
> instanciated the OOME is thrown. This error does not happen with
> commons-compress versions prior to 1.10, when auto detecting LZMA streams was
> added. OOME stacktrace below:
> {code}
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at org.tukaani.xz.lz.LZDecoder.(Unknown Source) ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at
> org.apache.commons.compress.compressors.lzma.LZMACompressorInputStream.(LZMACompressorInputStream.java:48)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.commons.compress.compressors.CompressorStreamFactory.createCompressorInputStream(CompressorStreamFactory.java:251)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detectCompressorFormat(ZipContainerDetector.java:109)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detect(ZipContainerDetector.java:95)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.detect.CompositeDetector.detect(CompositeDetector.java:77)
> ~[tika-core-1.14.jar:1.14]
> at
> dpf.sp.gpinf.indexer.process.task.SignatureTask.process(SignatureTask.java:50)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processMonitorTimeout(AbstractTask.java:203)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:152)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at dpf.sp.gpinf.indexer.process.Worker.process(Worker.java:174)
> ~[iped.jar:?]
> ... 1 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-932) Contributions to filter package
[ https://issues.apache.org/jira/browse/MATH-932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-932: -- Fix Version/s: (was: 4.0) 4.X > Contributions to filter package > --- > > Key: MATH-932 > URL: https://issues.apache.org/jira/browse/MATH-932 > Project: Commons Math > Issue Type: Improvement >Reporter: Jens Kübler > Fix For: 4.X > > Attachments: extendedKalmanSupport.txt > > > - Extended Kalman Filter with user supplied transition functions > - Unscented Kalman Filter > - Rauch Tung Striebel Kalman Smoother > - Ability to supply combinations of nonlinear and linear kalman filter > setups, i.e. nonlinear unscented system transition with a linear > measurment update -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1233) Uncommon wilcoxon signed-rank p-values
[ https://issues.apache.org/jira/browse/MATH-1233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1233: --- Fix Version/s: 4.0 > Uncommon wilcoxon signed-rank p-values > -- > > Key: MATH-1233 > URL: https://issues.apache.org/jira/browse/MATH-1233 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.5 >Reporter: Icaro Cavalcante Dourado > Fix For: 4.0 > > Attachments: MATH-1233-test.patch > > > This implementation in WilcoxonSignedRankTest looks weird. For equal vectors, > the correct pValue should be 1, because it is the probability of the vectors > to come from same population. > On the opposite, this implementation returns ~0 for equal vectors. So we need > to analyze the returned pValue > significanceLevel to reject H0 hypothesis, > while in R and many others tools we perform the opposite: pValue <= > significanceLevel gives us an argument to reject null hypothesis. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1381) BinomialTest P-value > 1
[ https://issues.apache.org/jira/browse/MATH-1381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1381: --- Fix Version/s: 4.0 > BinomialTest P-value > 1 > > > Key: MATH-1381 > URL: https://issues.apache.org/jira/browse/MATH-1381 > Project: Commons Math > Issue Type: Bug >Reporter: Wang Qiang > Fix For: 4.0 > > > When I use the Binomial Test, I got p-value > 1 for two sided check. > Example: > (new BinomialTest()).binomialTest(200, 200, 0.9950429, > AlternativeHypothesis.TWO_SIDED) == 1.3701357550780435 > In my case, if the expected p-value is 1 (calculated by package in other > language, scipy in this case), the p-value returned could be > 1 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1171) clustering implementations have unnecessary overhead
[ https://issues.apache.org/jira/browse/MATH-1171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-1171: --- Fix Version/s: 4.0 > clustering implementations have unnecessary overhead > > > Key: MATH-1171 > URL: https://issues.apache.org/jira/browse/MATH-1171 > Project: Commons Math > Issue Type: Bug >Reporter: Mark > Fix For: 4.0 > > Attachments: image_clustering_example.png > > > I want to apply clustering algorithms like KMeansPlusPlusClusterer to > pictures. And creating a point instance for each pixel is not a good idea. > Therefore the interface should not be based on Collections, but on some > interface that provides sort of "get(index)" accessors to data that is > potentially stored in a pixel array etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-901) FastMath.sin is slow
[ https://issues.apache.org/jira/browse/MATH-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-901: -- Fix Version/s: (was: 4.0) 4.X > FastMath.sin is slow > > > Key: MATH-901 > URL: https://issues.apache.org/jira/browse/MATH-901 > Project: Commons Math > Issue Type: Sub-task >Affects Versions: 3.0 > Environment: Mac OS 10.8.2, Java 7 >Reporter: Konstantin Berlin > Fix For: 4.X > > Attachments: SineTest.java > > > The FastMath.sin (maybe other functions too) are not nearly as fast as some > other libraries that can be found on the internet. > The *much* faster code can be found here > http://www.oliford.co.uk/phys/code/AlgorithmRepository/src/jafama/. > Max Absolute Error Apache vs JDK: 1.1102230246251565E-16 > Max Absolute Error Alternative vs JDK: 5.551115123125783E-16 > JDK Time: 0.698 > Apache Time: 0.491 > Alternative Time: 0.18 > I will add my test code as soon as I figure out how. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MATH-1323) Clarify usage of "LeastSquaresProblem" wrappers
[
https://issues.apache.org/jira/browse/MATH-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated MATH-1323:
---
Fix Version/s: (was: 4.0)
4.X
> Clarify usage of "LeastSquaresProblem" wrappers
> ---
>
> Key: MATH-1323
> URL: https://issues.apache.org/jira/browse/MATH-1323
> Project: Commons Math
> Issue Type: Task
>Reporter: Gilles
> Labels: API, documentation
> Fix For: 4.X
>
>
> In {{o.a.c.m.fitting.leastsquares.LeastSquareFactory}}, there is a method
> "countEvaluations" that could have been the intended way to enforce a limited
> number of evaluations/iterations in the new design of the least-squares
> optimizers.
> However, currently, the counters are inherited from
> {{o.a.c.m.optim.OptimizationProblem}}.
> It should be clarified which code is supposed to be deprecated. The issue is
> certainly related to the still pending refactoring of the {{o.a.c.m.optim}}
> package.
> Related discussion on the ML:
> http://markmail.org/message/2suzbyqv2hvzsemu
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-172) implementation of implicit Runge-Kutta method for stiff differential equations
[ https://issues.apache.org/jira/browse/MATH-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-172: -- Fix Version/s: (was: 4.0) 4.X > implementation of implicit Runge-Kutta method for stiff differential equations > -- > > Key: MATH-172 > URL: https://issues.apache.org/jira/browse/MATH-172 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 1.2 >Reporter: James Housden >Assignee: Luc Maisonobe > Fix For: 4.X > > Attachments: bdf-2009-07-07.patch, BDFIntegrator.java, > BDFNordsieckTransformer.java > > > In version 1.2 several explicit Runge-Kutta methods have been implemented > which work fine for non-stiff problems. However these methods are not > suitable for stiff equations. The implementation of an implicit Runge-Kutta > method such as Radau5 would extend the functionality of the ode package to > cover the solution of stiff ordinary differential equations. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COMPRESS-382) OutOfMemoryError from CompressorStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979945#comment-15979945
]
ASF GitHub Bot commented on COMPRESS-382:
-
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/20#discussion_r112810573
--- Diff:
src/test/java/org/apache/commons/compress/compressors/DetectCompressorTestCase.java
---
@@ -167,6 +171,26 @@ private String detect(String testFileName) throws
IOException, CompressorExcepti
}
@Test
+public void testMemoryLimit() throws Exception {
+testMemoryLimit("COMPRESS-382");
+testMemoryLimit("COMPRESS-386");
+}
+
+private void testMemoryLimit(String fileName) throws IOException,
CompressorException {
+CompressorStreamFactory fac = new CompressorStreamFactory(true,
+100);
+try (InputStream is = new BufferedInputStream(
+new FileInputStream(getFile(fileName {
+InputStream compressorInputStream =
fac.createCompressorInputStream(is);
+fail("Should have thrown CompressorMemoryLimitException");
--- End diff --
+1 and make it two tests :-)
> OutOfMemoryError from CompressorStreamFactory
> -
>
> Key: COMPRESS-382
> URL: https://issues.apache.org/jira/browse/COMPRESS-382
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.10, 1.11, 1.12
> Environment: Windows7, jre1.8.0_101 x64
>Reporter: Luis Filipe Nassif
> Attachments: data.mui
>
>
> While using Tika-1.14 to detect file types, the attached 1KB file triggered
> an OOME with 1GB heap. Tika calls
> CompressorStreamFactory.createCompressorInputStream(in) to detect if the file
> is a compressor stream, but CompressorStreamFactory erroneously detects it as
> a LZMACompressorInputStream and when the LZMACompressorInputStream is
> instanciated the OOME is thrown. This error does not happen with
> commons-compress versions prior to 1.10, when auto detecting LZMA streams was
> added. OOME stacktrace below:
> {code}
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at org.tukaani.xz.lz.LZDecoder.(Unknown Source) ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at
> org.apache.commons.compress.compressors.lzma.LZMACompressorInputStream.(LZMACompressorInputStream.java:48)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.commons.compress.compressors.CompressorStreamFactory.createCompressorInputStream(CompressorStreamFactory.java:251)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detectCompressorFormat(ZipContainerDetector.java:109)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detect(ZipContainerDetector.java:95)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.detect.CompositeDetector.detect(CompositeDetector.java:77)
> ~[tika-core-1.14.jar:1.14]
> at
> dpf.sp.gpinf.indexer.process.task.SignatureTask.process(SignatureTask.java:50)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processMonitorTimeout(AbstractTask.java:203)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:152)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at dpf.sp.gpinf.indexer.process.Worker.process(Worker.java:174)
> ~[iped.jar:?]
> ... 1 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (MATH-463) Monte Carlo engine with 1D path
[ https://issues.apache.org/jira/browse/MATH-463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Tompkins updated MATH-463: -- Fix Version/s: (was: 4.0) 4.X > Monte Carlo engine with 1D path > --- > > Key: MATH-463 > URL: https://issues.apache.org/jira/browse/MATH-463 > Project: Commons Math > Issue Type: New Feature >Reporter: Pavel Ryzhov > Fix For: 4.X > > Attachments: mc1.patch > > > Quite simple Monte-Carlo engine: > 1. Generates N samples (paths) of Ito process with given drift and > diffusion. It uses simple Euler discretization on equally spaced time scale. > 2. For each path evaluate some path function and provide this value to > SummaryStatistics. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (COMPRESS-382) OutOfMemoryError from CompressorStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979944#comment-15979944
]
Luis Filipe Nassif commented on COMPRESS-382:
-
Good work Tim! I think the wrapping IOException is a good workaround. Making
CompressorMemoryLimitException a RuntimeException is worse, making it extend an
IOException, like tukanni MemoryLimitException, makes less sense to me.
Maybe throwing a normal IOException with the original exception as cause is
sufficient? The cause can be checked in CompressorStreamFactory so no need to
create a new IOException?
> OutOfMemoryError from CompressorStreamFactory
> -
>
> Key: COMPRESS-382
> URL: https://issues.apache.org/jira/browse/COMPRESS-382
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.10, 1.11, 1.12
> Environment: Windows7, jre1.8.0_101 x64
>Reporter: Luis Filipe Nassif
> Attachments: data.mui
>
>
> While using Tika-1.14 to detect file types, the attached 1KB file triggered
> an OOME with 1GB heap. Tika calls
> CompressorStreamFactory.createCompressorInputStream(in) to detect if the file
> is a compressor stream, but CompressorStreamFactory erroneously detects it as
> a LZMACompressorInputStream and when the LZMACompressorInputStream is
> instanciated the OOME is thrown. This error does not happen with
> commons-compress versions prior to 1.10, when auto detecting LZMA streams was
> added. OOME stacktrace below:
> {code}
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at org.tukaani.xz.lz.LZDecoder.(Unknown Source) ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at
> org.apache.commons.compress.compressors.lzma.LZMACompressorInputStream.(LZMACompressorInputStream.java:48)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.commons.compress.compressors.CompressorStreamFactory.createCompressorInputStream(CompressorStreamFactory.java:251)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detectCompressorFormat(ZipContainerDetector.java:109)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detect(ZipContainerDetector.java:95)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.detect.CompositeDetector.detect(CompositeDetector.java:77)
> ~[tika-core-1.14.jar:1.14]
> at
> dpf.sp.gpinf.indexer.process.task.SignatureTask.process(SignatureTask.java:50)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processMonitorTimeout(AbstractTask.java:203)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:152)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at dpf.sp.gpinf.indexer.process.Worker.process(Worker.java:174)
> ~[iped.jar:?]
> ... 1 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-384) Tar File EOF not being detected
[
https://issues.apache.org/jira/browse/COMPRESS-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979943#comment-15979943
]
Stefan Bodewig commented on COMPRESS-384:
-
Sorry for the delay, Jason.
I'm not sure I understand what you are doing. If I use
{{org.apache.commons.compress.archivers.Lister}} I see the expected behaviour
({{getNextEntry}} returns {{null}}) but we don't really try to read the entries
themselves.
Hmm after applying
{code}
diff --git a/src/main/java/org/apache/commons/compress/archivers/Lister.java
b/src/main/java/org/apache/commons/compress/archivers/Lister.java
index 7df9591..232b2ed 100644
--- a/src/main/java/org/apache/commons/compress/archivers/Lister.java
+++ b/src/main/java/org/apache/commons/compress/archivers/Lister.java
@@ -22,6 +22,7 @@
import java.io.File;
import java.io.InputStream;
import java.nio.file.Files;
+import org.apache.commons.compress.utils.IOUtils;
/**
* Simple command line application that lists the contents of an archive.
@@ -49,7 +50,12 @@ public static void main(final String[] args) throws
Exception {
System.out.println("Created " + ais.toString());
ArchiveEntry ae;
while ((ae = ais.getNextEntry()) != null) {
-System.out.println(ae.getName());
+System.out.print(ae.getName());
+if (ae.isDirectory()) {
+System.out.println(" is a directory");
+} else {
+System.out.println(" has size " +
IOUtils.toByteArray(ais).length);
+}
}
}
}
{code}
I seem to get reasonable sizes. Can you show a few lines of code where we can
see what you are trying to do and where things go wrong?
> Tar File EOF not being detected
> ---
>
> Key: COMPRESS-384
> URL: https://issues.apache.org/jira/browse/COMPRESS-384
> Project: Commons Compress
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.13
> Environment: Windows 10, JDK 1.8
>Reporter: Jason Shattu
> Attachments: file.tar
>
>
> I've created both a zip and tar file, with the same contents using the latest
> version of 7zip. When I read both archives using code of the form:
> ArchiveStreamFactory().createArchiveInputStream(format, inputStream);
> I notice that both formats correctly list their contents, however the Tar
> Input doesn't return a "null" entry when it hits the EOF from
> archiveStream.getNextEntry()
> this makes it hard to distinguish between a genuine EOF or a file which is
> still being written to.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-387) Allow spaces in path for unit tests in Windows
[
https://issues.apache.org/jira/browse/COMPRESS-387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979940#comment-15979940
]
Stefan Bodewig commented on COMPRESS-387:
-
Thanks Uwe
bq. Nevertheless, I'd prefer to get an InputStream directly, as the test suite
would fail, if the resources are in a JAR file for some reason (IDE,...).
I agree in general but in our case the resource is a directory and we want to
walk its children which is a lot less cumbersome if you can rely on the File
API.
> Allow spaces in path for unit tests in Windows
> --
>
> Key: COMPRESS-387
> URL: https://issues.apache.org/jira/browse/COMPRESS-387
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Trivial
> Fix For: 1.14
>
>
> I'm getting build failures on Windows, probably because I'm working in a
> directory that has a space in the name (on purpose!).
> If we modify the much better:
> {noformat}
> private static final File ARCDIR = new
> File(CLASSLOADER.getResource("archives").getFile());
> {noformat}
> with this hideousness in LongPathTest, LongSymLinkTest and ArchiveReadTest
> {noformat}
> static {
> try {
> ARCDIR = new
> File(CLASSLOADER.getResource("archives").toURI().getPath());
> } catch (URISyntaxException e) {
> throw new RuntimeException(e);
> }
> }
> {noformat}
> tests all pass.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-382) OutOfMemoryError from CompressorStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979939#comment-15979939
]
ASF GitHub Bot commented on COMPRESS-382:
-
Github user kinow commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/20#discussion_r112810239
--- Diff:
src/test/java/org/apache/commons/compress/compressors/DetectCompressorTestCase.java
---
@@ -167,6 +171,26 @@ private String detect(String testFileName) throws
IOException, CompressorExcepti
}
@Test
+public void testMemoryLimit() throws Exception {
+testMemoryLimit("COMPRESS-382");
+testMemoryLimit("COMPRESS-386");
+}
+
+private void testMemoryLimit(String fileName) throws IOException,
CompressorException {
+CompressorStreamFactory fac = new CompressorStreamFactory(true,
+100);
+try (InputStream is = new BufferedInputStream(
+new FileInputStream(getFile(fileName {
+InputStream compressorInputStream =
fac.createCompressorInputStream(is);
+fail("Should have thrown CompressorMemoryLimitException");
--- End diff --
Maybe instead we could let the CompressorMemoryLimitException happen, and
declare in the @Test annotation the expected exception.
> OutOfMemoryError from CompressorStreamFactory
> -
>
> Key: COMPRESS-382
> URL: https://issues.apache.org/jira/browse/COMPRESS-382
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.10, 1.11, 1.12
> Environment: Windows7, jre1.8.0_101 x64
>Reporter: Luis Filipe Nassif
> Attachments: data.mui
>
>
> While using Tika-1.14 to detect file types, the attached 1KB file triggered
> an OOME with 1GB heap. Tika calls
> CompressorStreamFactory.createCompressorInputStream(in) to detect if the file
> is a compressor stream, but CompressorStreamFactory erroneously detects it as
> a LZMACompressorInputStream and when the LZMACompressorInputStream is
> instanciated the OOME is thrown. This error does not happen with
> commons-compress versions prior to 1.10, when auto detecting LZMA streams was
> added. OOME stacktrace below:
> {code}
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at org.tukaani.xz.lz.LZDecoder.(Unknown Source) ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at
> org.apache.commons.compress.compressors.lzma.LZMACompressorInputStream.(LZMACompressorInputStream.java:48)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.commons.compress.compressors.CompressorStreamFactory.createCompressorInputStream(CompressorStreamFactory.java:251)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detectCompressorFormat(ZipContainerDetector.java:109)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detect(ZipContainerDetector.java:95)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.detect.CompositeDetector.detect(CompositeDetector.java:77)
> ~[tika-core-1.14.jar:1.14]
> at
> dpf.sp.gpinf.indexer.process.task.SignatureTask.process(SignatureTask.java:50)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processMonitorTimeout(AbstractTask.java:203)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:152)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at dpf.sp.gpinf.indexer.process.Worker.process(Worker.java:174)
> ~[iped.jar:?]
> ... 1 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TEXT-45) WordUtils delimiters should be strings, not char varargs
[
https://issues.apache.org/jira/browse/TEXT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979938#comment-15979938
]
Rob Tompkins commented on TEXT-45:
--
I'm going to include in this issue, the adding back of {{WordUtils}}.
> WordUtils delimiters should be strings, not char varargs
>
>
> Key: TEXT-45
> URL: https://issues.apache.org/jira/browse/TEXT-45
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Andrew Pennebaker
>Priority: Minor
> Labels: api,, interface,ease,of,use,, robustness,
> Fix For: 1.1
>
>
> Strings behave like char varargs of arbitrary length, but are much easier to
> use.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (TEXT-45) WordUtils delimiters should be strings, not char varargs
[
https://issues.apache.org/jira/browse/TEXT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979936#comment-15979936
]
Rob Tompkins edited comment on TEXT-45 at 4/22/17 1:51 PM:
---
Seems like we should accommodate such changes on methods {{capitalize}},
{{capatalizeFully}}, {{uncapitalize}}, and {{initials}}. After adding
{{WordUtils}} back.
was (Author: chtompki):
Seems like we should accommodate such changes on methods {{capitalize}},
{{capatalizeFully}}, {{uncapitalize}}, and {{initials}}.
> WordUtils delimiters should be strings, not char varargs
>
>
> Key: TEXT-45
> URL: https://issues.apache.org/jira/browse/TEXT-45
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Andrew Pennebaker
>Priority: Minor
> Labels: api,, interface,ease,of,use,, robustness,
> Fix For: 1.1
>
>
> Strings behave like char varargs of arbitrary length, but are much easier to
> use.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TEXT-45) WordUtils delimiters should be strings, not char varargs
[
https://issues.apache.org/jira/browse/TEXT-45?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979936#comment-15979936
]
Rob Tompkins commented on TEXT-45:
--
Seems like we should accommodate such changes on methods {{capitalize}},
{{capatalizeFully}}, {{uncapitalize}}, and {{initials}}.
> WordUtils delimiters should be strings, not char varargs
>
>
> Key: TEXT-45
> URL: https://issues.apache.org/jira/browse/TEXT-45
> Project: Commons Text
> Issue Type: Improvement
>Reporter: Andrew Pennebaker
>Priority: Minor
> Labels: api,, interface,ease,of,use,, robustness,
> Fix For: 1.1
>
>
> Strings behave like char varargs of arbitrary length, but are much easier to
> use.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NUMBERS-24) Create logo for Apache Commons Numbers
[ https://issues.apache.org/jira/browse/NUMBERS-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979935#comment-15979935 ] Gilles commented on NUMBERS-24: --- commit c7c9ccfbb2c0c49a1f92057a8203761515cbe4f4 > Create logo for Apache Commons Numbers > -- > > Key: NUMBERS-24 > URL: https://issues.apache.org/jira/browse/NUMBERS-24 > Project: Commons Numbers > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0 > > > The project currently has no logo. There is a Commons Math logo in the > project site resources folder, that needs to be replaced by a new original > logo. > See https://www.apache.org/foundation/marks/pmcs for trademark notes too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (NUMBERS-25) Check list for first release
Gilles created NUMBERS-25:
-
Summary: Check list for first release
Key: NUMBERS-25
URL: https://issues.apache.org/jira/browse/NUMBERS-25
Project: Commons Numbers
Issue Type: Task
Reporter: Gilles
Fix For: 1.0
List of tasks to complete before considering a first release.
* (x) Review public API
* Ensure clean project reports
** (x) JIRA
** (x) Surefire
** (x) RAT
** (x) Jacoco
** (x) FindBugs
** (x) Checkstyle
** (x) PMD
** (x) CPD
* Ensure that "Commons Math" ("master" branch) compiles and pass all unit tests
when
** (x) dependencies to "Commons Numbers" modules are added and
** (x) all classes that have an equivalent in "Commons Numbers" are deleted.
* (x) User guide
* (x) Jenkins
* (x) Web site
* (/) [GitHub|https://github.com/apache/commons-numbers]
* (/) [Travis|https://travis-ci.org/apache/commons-numbers]
* (x) Coveralls
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (COMPRESS-382) OutOfMemoryError from CompressorStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979934#comment-15979934
]
Stefan Bodewig commented on COMPRESS-382:
-
Many thanks Tim, I like your suggestions and would merge it as is. I can live
with not covering all other formats, but would modify
{{XZCompressorInputStream}} the same way you did to
{{LZMACompressorInputStream}} (and can certainly do that myself).
bq. The one part that I don't like is the IOException that wraps a memory limit
exception in ZCompressorInputStream.
I understand that, but we can't add {{CompressorException}} to the
constructor's signature either (too bad it is a checked exception). Maybe store
the original exception inside the {{IOExceptionWrappingMemoryLimitException}}
as cause and rethrow the cause from within the factory? Wouldn't be much better
either, I'm afraid.
> OutOfMemoryError from CompressorStreamFactory
> -
>
> Key: COMPRESS-382
> URL: https://issues.apache.org/jira/browse/COMPRESS-382
> Project: Commons Compress
> Issue Type: Bug
> Components: Compressors
>Affects Versions: 1.10, 1.11, 1.12
> Environment: Windows7, jre1.8.0_101 x64
>Reporter: Luis Filipe Nassif
> Attachments: data.mui
>
>
> While using Tika-1.14 to detect file types, the attached 1KB file triggered
> an OOME with 1GB heap. Tika calls
> CompressorStreamFactory.createCompressorInputStream(in) to detect if the file
> is a compressor stream, but CompressorStreamFactory erroneously detects it as
> a LZMACompressorInputStream and when the LZMACompressorInputStream is
> instanciated the OOME is thrown. This error does not happen with
> commons-compress versions prior to 1.10, when auto detecting LZMA streams was
> added. OOME stacktrace below:
> {code}
> Caused by: java.lang.OutOfMemoryError: Java heap space
> at org.tukaani.xz.lz.LZDecoder.(Unknown Source) ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.initialize(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at org.tukaani.xz.LZMAInputStream.(Unknown Source)
> ~[xz-1.5.jar:1.5]
> at
> org.apache.commons.compress.compressors.lzma.LZMACompressorInputStream.(LZMACompressorInputStream.java:48)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.commons.compress.compressors.CompressorStreamFactory.createCompressorInputStream(CompressorStreamFactory.java:251)
> ~[commons-compress-1.10.jar:1.10]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detectCompressorFormat(ZipContainerDetector.java:109)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.parser.pkg.ZipContainerDetector.detect(ZipContainerDetector.java:95)
> ~[tika-parsers-1.14.jar:1.14]
> at
> org.apache.tika.detect.CompositeDetector.detect(CompositeDetector.java:77)
> ~[tika-core-1.14.jar:1.14]
> at
> dpf.sp.gpinf.indexer.process.task.SignatureTask.process(SignatureTask.java:50)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processMonitorTimeout(AbstractTask.java:203)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:152)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.sendToNextTask(AbstractTask.java:190)
> ~[iped.jar:?]
> at
> dpf.sp.gpinf.indexer.process.task.AbstractTask.processAndSendToNextTask(AbstractTask.java:160)
> ~[iped.jar:?]
> at dpf.sp.gpinf.indexer.process.Worker.process(Worker.java:174)
> ~[iped.jar:?]
> ... 1 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-656) YAML Configuration
[
https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979924#comment-15979924
]
The Alchemist commented on CONFIGURATION-656:
-
A new version of the patch is available at
https://issues.apache.org/jira/secure/attachment/12864054/commons-configuration2-yaml.and.json.support.diff.
I made an superclass that is used by both the JSON and YAML {{Configuration}}
classes.
> YAML Configuration
> --
>
> Key: CONFIGURATION-656
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-656
> Project: Commons Configuration
> Issue Type: New Feature
> Components: Format
>Reporter: Gary Gregory
>
> Like the missing JSON Configuration, we really should also support YAML.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CONFIGURATION-656) YAML Configuration
[ https://issues.apache.org/jira/browse/CONFIGURATION-656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] The Alchemist updated CONFIGURATION-656: Attachment: (was: commons-configuration2-yaml.support.patch) > YAML Configuration > -- > > Key: CONFIGURATION-656 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-656 > Project: Commons Configuration > Issue Type: New Feature > Components: Format >Reporter: Gary Gregory > > Like the missing JSON Configuration, we really should also support YAML. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (TEXT-41) WordUtils.abbreviate support
[ https://issues.apache.org/jira/browse/TEXT-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated TEXT-41: -- Summary: WordUtils.abbreviate support (was: WordUtils.abbreviate support in 3.0) > WordUtils.abbreviate support > > > Key: TEXT-41 > URL: https://issues.apache.org/jira/browse/TEXT-41 > Project: Commons Text > Issue Type: New Feature >Reporter: Mirek Hankus > Fix For: 1.1 > > Attachments: LANG-766.patch > > > Commons Lang 2.x has method WordUtils.abbreviate(java.lang.String str, int > lower, int upper, java.lang.String appendToEnd), which > # operates on words not Strings as StringUtils.abbreviate > # it allows to specify what shoud be appended to string > (StringUtils.abbreviate always appends "...") > In 3.0 there is no such method, but it was very usefull. please add support > for WordUtils.abbreviate -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (LANG-933) Request to support custom DateFormatSymbols in FastDateFormat
[ https://issues.apache.org/jira/browse/LANG-933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed LANG-933. -- Resolution: Won't Fix Fix Version/s: (was: Patch Needed) As discussed on the mailing list, we won't add new features related to java.util.Date. See https://mail-archives.apache.org/mod_mbox/commons-dev/201704.mbox/%3Cac296ba2-c9ef-2d6f-271e-d4699690581d%40gmx.net%3E for details. > Request to support custom DateFormatSymbols in FastDateFormat > - > > Key: LANG-933 > URL: https://issues.apache.org/jira/browse/LANG-933 > Project: Commons Lang > Issue Type: Wish > Components: lang.time.* >Affects Versions: 3.1 >Reporter: Egidijus Vaisnora >Priority: Minor > > FastDateFormat do not have possibility to accept custom DateFormatSymbols -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (LANG-1136) Add a method in EnumUtils to 'translate' an enum value
[ https://issues.apache.org/jira/browse/LANG-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed LANG-1136. --- Resolution: Won't Fix Fix Version/s: (was: Discussion) I agree with Benedikt, this sounds a bit to specific for commons-lang. > Add a method in EnumUtils to 'translate' an enum value > -- > > Key: LANG-1136 > URL: https://issues.apache.org/jira/browse/LANG-1136 > Project: Commons Lang > Issue Type: Wish > Components: lang.* >Reporter: Cimballi >Priority: Minor > > Add a method in EnumUtils to 'translate' an enum value. > Example : > Enum1 > Enum2 > Object.enum2 > Enum1 getEnum(Enum1.class, Object.enum2); > If enum2 is null, returns 2, else returns the Enum1 with the same name as > Object.enum2, throws exception if no such Enum1. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (LANG-661) Add methods to get startDateOfXXX and endDateOfXXX for week, month and year
[ https://issues.apache.org/jira/browse/LANG-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed LANG-661. -- Resolution: Won't Fix As discussed on the mailing list, we won't add new features related to java.util.Date. See https://mail-archives.apache.org/mod_mbox/commons-dev/201704.mbox/%3Cac296ba2-c9ef-2d6f-271e-d4699690581d%40gmx.net%3E for details. > Add methods to get startDateOfXXX and endDateOfXXX for week, month and year > --- > > Key: LANG-661 > URL: https://issues.apache.org/jira/browse/LANG-661 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* > Environment: OS: Win XP SP3 > JDK:1.6u22 >Reporter: Maheshkumar Periyasamy >Priority: Minor > Attachments: DataUtilsTest.java, DateUtils.java > > > We can have methods to get startDateOfXXX and endDateOfXXX for week, month > and year. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (LANG-661) Add methods to get startDateOfXXX and endDateOfXXX for week, month and year
[ https://issues.apache.org/jira/browse/LANG-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated LANG-661: --- Fix Version/s: (was: 4.0) > Add methods to get startDateOfXXX and endDateOfXXX for week, month and year > --- > > Key: LANG-661 > URL: https://issues.apache.org/jira/browse/LANG-661 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* > Environment: OS: Win XP SP3 > JDK:1.6u22 >Reporter: Maheshkumar Periyasamy >Priority: Minor > Attachments: DataUtilsTest.java, DateUtils.java > > > We can have methods to get startDateOfXXX and endDateOfXXX for week, month > and year. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (LANG-556) Add methods for constructing dates to DateUtils
[ https://issues.apache.org/jira/browse/LANG-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed LANG-556. -- Resolution: Won't Fix As discussed on the mailing list, we won't add new features related to java.util.Date. See https://mail-archives.apache.org/mod_mbox/commons-dev/201704.mbox/%3Cac296ba2-c9ef-2d6f-271e-d4699690581d%40gmx.net%3E for details. > Add methods for constructing dates to DateUtils > --- > > Key: LANG-556 > URL: https://issues.apache.org/jira/browse/LANG-556 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Ben Arnold >Priority: Minor > > It is often really useful to be able to get a date in one line of code, > particularly in unit tests. It is also handy to be able to obtain the current > time in a specified timezone. > It would be great to have methods like these on DateUtils: > Date now(TimeZone) > Date nowUtc() > Date createDate(int year, int month, int day) // local time > Date createDate(int year, int month, int day, int hour, minute, int second) > // local time > Date createDateUtc(int year, int month, int day) > Date createDateUtc(int year, int month, int day, int hour, minute, int second) > Date createDate(TimeZone timeZone, int year, int month, int day) > Date createDate(TimeZone timeZone, int year, int month, int day, int hour, > minute, int second) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (LANG-556) Add methods for constructing dates to DateUtils
[ https://issues.apache.org/jira/browse/LANG-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated LANG-556: --- Fix Version/s: (was: 4.0) > Add methods for constructing dates to DateUtils > --- > > Key: LANG-556 > URL: https://issues.apache.org/jira/browse/LANG-556 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Reporter: Ben Arnold >Priority: Minor > > It is often really useful to be able to get a date in one line of code, > particularly in unit tests. It is also handy to be able to obtain the current > time in a specified timezone. > It would be great to have methods like these on DateUtils: > Date now(TimeZone) > Date nowUtc() > Date createDate(int year, int month, int day) // local time > Date createDate(int year, int month, int day, int hour, minute, int second) > // local time > Date createDateUtc(int year, int month, int day) > Date createDateUtc(int year, int month, int day, int hour, minute, int second) > Date createDate(TimeZone timeZone, int year, int month, int day) > Date createDate(TimeZone timeZone, int year, int month, int day, int hour, > minute, int second) -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (LANG-350) New RandomDateUtils class in the lang.time package
[ https://issues.apache.org/jira/browse/LANG-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed LANG-350. -- Resolution: Won't Fix As discussed on the mailing list, we won't add new features related to java.util.Date. See https://mail-archives.apache.org/mod_mbox/commons-dev/201704.mbox/%3Cac296ba2-c9ef-2d6f-271e-d4699690581d%40gmx.net%3E for details. > New RandomDateUtils class in the lang.time package > -- > > Key: LANG-350 > URL: https://issues.apache.org/jira/browse/LANG-350 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Affects Versions: 2.3 >Reporter: Nathan Silberman >Priority: Minor > Attachments: RandomDateUtils.java, RandomDateUtilsTest.java > > > A new RandomDateUtils class that would provide methods for returning random > datetimes and random simple dates. Its functionality would include but not > limited to the following: > /* > * Random datetime after Janurary 1st, 1970 > */ > public static Date randomDate(); > /* > * A Random datetime after the given date > */ > public static Date randomDateAfter( Date date ); > /* > * A Random datetime before the given date > */ > public static Date randomDateBefore( Date date ); > /* > * Random datetime after this instant > */ > public static Date randomFutureDate(); > /* > * Random datetime before this instant > */ > public static Date randomPastDate(); > /* > * Random date (zeroed out time) after Janurary 1st, 1970 > */ > public static Date randomSimpleDate(); > /* > * A Random date (zeroed out time) after the given date > */ > public static Date randomSimpleDateAfter( Date date ); > /* > * A Random date (zeroed out time) before the given date > */ > public static Date randomSimpleDateBefore( Date date ); > /* > * Random date (zeroed out time) after this instant > */ > public static Date randomSimpleFutureDate(); > /* > * Random date (zeroed out time) before this instant > */ > public static Date randomSimplePastDate(); -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (LANG-350) New RandomDateUtils class in the lang.time package
[ https://issues.apache.org/jira/browse/LANG-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated LANG-350: --- Fix Version/s: (was: 4.0) > New RandomDateUtils class in the lang.time package > -- > > Key: LANG-350 > URL: https://issues.apache.org/jira/browse/LANG-350 > Project: Commons Lang > Issue Type: New Feature > Components: lang.time.* >Affects Versions: 2.3 >Reporter: Nathan Silberman >Priority: Minor > Attachments: RandomDateUtils.java, RandomDateUtilsTest.java > > > A new RandomDateUtils class that would provide methods for returning random > datetimes and random simple dates. Its functionality would include but not > limited to the following: > /* > * Random datetime after Janurary 1st, 1970 > */ > public static Date randomDate(); > /* > * A Random datetime after the given date > */ > public static Date randomDateAfter( Date date ); > /* > * A Random datetime before the given date > */ > public static Date randomDateBefore( Date date ); > /* > * Random datetime after this instant > */ > public static Date randomFutureDate(); > /* > * Random datetime before this instant > */ > public static Date randomPastDate(); > /* > * Random date (zeroed out time) after Janurary 1st, 1970 > */ > public static Date randomSimpleDate(); > /* > * A Random date (zeroed out time) after the given date > */ > public static Date randomSimpleDateAfter( Date date ); > /* > * A Random date (zeroed out time) before the given date > */ > public static Date randomSimpleDateBefore( Date date ); > /* > * Random date (zeroed out time) after this instant > */ > public static Date randomSimpleFutureDate(); > /* > * Random date (zeroed out time) before this instant > */ > public static Date randomSimplePastDate(); -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (LANG-347) DateUtils' new addWeekdays feature
[
https://issues.apache.org/jira/browse/LANG-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher updated LANG-347:
---
Fix Version/s: (was: 4.0)
> DateUtils' new addWeekdays feature
> --
>
> Key: LANG-347
> URL: https://issues.apache.org/jira/browse/LANG-347
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.time.*
>Reporter: Vasily Ivanov
>
> New method to add signed number of weekdays (skipping weekends):
> /**
>* Adds a number of weekdays (skipping weekends) to a date returning a new
> Date object.
>* The original date object is unchanged.
>*
>* If the original Date itself is on a weekend, calculation will be started
> from the
>* next Monday morning (0:00:00.000) if an amount is positive or from the
> last Friday night
>* (23:59:59.999) otherwise.
>*
>* @param date the date, not null
>* @param amount the amount to add, may be negative
>* @return the new Date object with the amount added
>*/
> public static Date addWeekdays(Date date,
> int amount)
> {
> if (date == null) {
> throw new IllegalArgumentException("The date must not be null");
> }
> Calendar c = Calendar.getInstance();
> c.setTime(date);
> if (amount != 0) {
> if (isWeekend(c)) {
> // see comments above
> final boolean isSat = getDayOfWeek(c) == Calendar.SATURDAY;
> int numToJump = 0;
> if (amount > 0) {
> // this will jump date to the closest Monday
> numToJump = isSat ? 2 : 1;
> } else {
> // this will jump date to the closest Saturday
> numToJump = isSat ? 0 : -1;
> }
> c.add(Calendar.DAY_OF_MONTH, numToJump);
> // this will jump to the start of the day (Monday or Saturday)
> modify(c, Calendar.DAY_OF_MONTH, false);
> if (amount < 0) {
> // this will go back to the end of prev Friday
> c.add(Calendar.MILLISECOND, -1);
> }
> }
> int count = 0;
> final int absAmount = Math.abs(amount);
> final int offset = amount > 0 ? 1 : -1;
> while (count < absAmount) {
> c.add(Calendar.DAY_OF_MONTH, offset);
> if (!isWeekend(c)) {
> count++;
> }
> }
> }
> return c.getTime();
> }
> public static int getDayOfWeek(Calendar c)
> {
> return c.get(Calendar.DAY_OF_WEEK);
> }
> public static boolean isWeekend(Calendar c)
> {
> final int dayOfWeek = getDayOfWeek(c);
> return dayOfWeek == Calendar.SATURDAY || dayOfWeek == Calendar.SUNDAY;
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (LANG-347) DateUtils' new addWeekdays feature
[
https://issues.apache.org/jira/browse/LANG-347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pascal Schumacher closed LANG-347.
--
Resolution: Won't Fix
As discussed on the mailing list, we won't add new features related to
java.util.Date. See
https://mail-archives.apache.org/mod_mbox/commons-dev/201704.mbox/%3Cac296ba2-c9ef-2d6f-271e-d4699690581d%40gmx.net%3E
for details.
> DateUtils' new addWeekdays feature
> --
>
> Key: LANG-347
> URL: https://issues.apache.org/jira/browse/LANG-347
> Project: Commons Lang
> Issue Type: New Feature
> Components: lang.time.*
>Reporter: Vasily Ivanov
>
> New method to add signed number of weekdays (skipping weekends):
> /**
>* Adds a number of weekdays (skipping weekends) to a date returning a new
> Date object.
>* The original date object is unchanged.
>*
>* If the original Date itself is on a weekend, calculation will be started
> from the
>* next Monday morning (0:00:00.000) if an amount is positive or from the
> last Friday night
>* (23:59:59.999) otherwise.
>*
>* @param date the date, not null
>* @param amount the amount to add, may be negative
>* @return the new Date object with the amount added
>*/
> public static Date addWeekdays(Date date,
> int amount)
> {
> if (date == null) {
> throw new IllegalArgumentException("The date must not be null");
> }
> Calendar c = Calendar.getInstance();
> c.setTime(date);
> if (amount != 0) {
> if (isWeekend(c)) {
> // see comments above
> final boolean isSat = getDayOfWeek(c) == Calendar.SATURDAY;
> int numToJump = 0;
> if (amount > 0) {
> // this will jump date to the closest Monday
> numToJump = isSat ? 2 : 1;
> } else {
> // this will jump date to the closest Saturday
> numToJump = isSat ? 0 : -1;
> }
> c.add(Calendar.DAY_OF_MONTH, numToJump);
> // this will jump to the start of the day (Monday or Saturday)
> modify(c, Calendar.DAY_OF_MONTH, false);
> if (amount < 0) {
> // this will go back to the end of prev Friday
> c.add(Calendar.MILLISECOND, -1);
> }
> }
> int count = 0;
> final int absAmount = Math.abs(amount);
> final int offset = amount > 0 ? 1 : -1;
> while (count < absAmount) {
> c.add(Calendar.DAY_OF_MONTH, offset);
> if (!isWeekend(c)) {
> count++;
> }
> }
> }
> return c.getTime();
> }
> public static int getDayOfWeek(Calendar c)
> {
> return c.get(Calendar.DAY_OF_WEEK);
> }
> public static boolean isWeekend(Calendar c)
> {
> final int dayOfWeek = getDayOfWeek(c);
> return dayOfWeek == Calendar.SATURDAY || dayOfWeek == Calendar.SUNDAY;
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (LANG-65) [lang] Expose DateIterator or add DateUtils.iterator(startDate, endDate)
[ https://issues.apache.org/jira/browse/LANG-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed LANG-65. - Resolution: Won't Fix > [lang] Expose DateIterator or add DateUtils.iterator(startDate, endDate) > > > Key: LANG-65 > URL: https://issues.apache.org/jira/browse/LANG-65 > Project: Commons Lang > Issue Type: Improvement > Components: lang.time.* > Environment: Operating System: other > Platform: Other >Reporter: Ben Munat > > The DateUtils.iterator methods only work with the preset date ranges indicated > by constants in the class. It would be very useful to be able to iterate > through > each day between a user-specified start date and an end date. > This could be as simple as making the static DateIterator inner class of > DateUtils public (it's package protected now). Or, if that's not appealing for > some reason, another iterator method could be added that takes the start date > and end date and returns a DateIterator instance as Iterator. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Reopened] (LANG-65) [lang] Expose DateIterator or add DateUtils.iterator(startDate, endDate)
[ https://issues.apache.org/jira/browse/LANG-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher reopened LANG-65: --- > [lang] Expose DateIterator or add DateUtils.iterator(startDate, endDate) > > > Key: LANG-65 > URL: https://issues.apache.org/jira/browse/LANG-65 > Project: Commons Lang > Issue Type: Improvement > Components: lang.time.* > Environment: Operating System: other > Platform: Other >Reporter: Ben Munat > > The DateUtils.iterator methods only work with the preset date ranges indicated > by constants in the class. It would be very useful to be able to iterate > through > each day between a user-specified start date and an end date. > This could be as simple as making the static DateIterator inner class of > DateUtils public (it's package protected now). Or, if that's not appealing for > some reason, another iterator method could be added that takes the start date > and end date and returns a DateIterator instance as Iterator. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (LANG-65) [lang] Expose DateIterator or add DateUtils.iterator(startDate, endDate)
[ https://issues.apache.org/jira/browse/LANG-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher closed LANG-65. - Resolution: Fixed As discussed on the mailing list, we won't add new features related to java.util.Date. See [https://mail-archives.apache.org/mod_mbox/commons-dev/201704.mbox/%3Cac296ba2-c9ef-2d6f-271e-d4699690581d%40gmx.net%3E] for details. > [lang] Expose DateIterator or add DateUtils.iterator(startDate, endDate) > > > Key: LANG-65 > URL: https://issues.apache.org/jira/browse/LANG-65 > Project: Commons Lang > Issue Type: Improvement > Components: lang.time.* > Environment: Operating System: other > Platform: Other >Reporter: Ben Munat > > The DateUtils.iterator methods only work with the preset date ranges indicated > by constants in the class. It would be very useful to be able to iterate > through > each day between a user-specified start date and an end date. > This could be as simple as making the static DateIterator inner class of > DateUtils public (it's package protected now). Or, if that's not appealing for > some reason, another iterator method could be added that takes the start date > and end date and returns a DateIterator instance as Iterator. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (LANG-65) [lang] Expose DateIterator or add DateUtils.iterator(startDate, endDate)
[ https://issues.apache.org/jira/browse/LANG-65?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pascal Schumacher updated LANG-65: -- Fix Version/s: (was: 4.0) > [lang] Expose DateIterator or add DateUtils.iterator(startDate, endDate) > > > Key: LANG-65 > URL: https://issues.apache.org/jira/browse/LANG-65 > Project: Commons Lang > Issue Type: Improvement > Components: lang.time.* > Environment: Operating System: other > Platform: Other >Reporter: Ben Munat > > The DateUtils.iterator methods only work with the preset date ranges indicated > by constants in the class. It would be very useful to be able to iterate > through > each day between a user-specified start date and an end date. > This could be as simple as making the static DateIterator inner class of > DateUtils public (it's package protected now). Or, if that's not appealing for > some reason, another iterator method could be added that takes the start date > and end date and returns a DateIterator instance as Iterator. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NUMBERS-24) Create logo for Apache Commons Numbers
[ https://issues.apache.org/jira/browse/NUMBERS-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979876#comment-15979876 ] Gilles commented on NUMBERS-24: --- I can do that. > Create logo for Apache Commons Numbers > -- > > Key: NUMBERS-24 > URL: https://issues.apache.org/jira/browse/NUMBERS-24 > Project: Commons Numbers > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0 > > > The project currently has no logo. There is a Commons Math logo in the > project site resources folder, that needs to be replaced by a new original > logo. > See https://www.apache.org/foundation/marks/pmcs for trademark notes too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NUMBERS-24) Create logo for Apache Commons Numbers
[ https://issues.apache.org/jira/browse/NUMBERS-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979863#comment-15979863 ] Bruno P. Kinoshita commented on NUMBERS-24: --- I think so, +1. Quick and simple, and we can change it later. This way we can focus on the rest of the content for the web site, and Java code too, of course :-) are you going to update the logo? > Create logo for Apache Commons Numbers > -- > > Key: NUMBERS-24 > URL: https://issues.apache.org/jira/browse/NUMBERS-24 > Project: Commons Numbers > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0 > > > The project currently has no logo. There is a Commons Math logo in the > project site resources folder, that needs to be replaced by a new original > logo. > See https://www.apache.org/foundation/marks/pmcs for trademark notes too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (NUMBERS-24) Create logo for Apache Commons Numbers
[ https://issues.apache.org/jira/browse/NUMBERS-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15979850#comment-15979850 ] Gilles commented on NUMBERS-24: --- Would a logo based (same feather and "commons" string) on the one from [RNG|http://commons.apache.org/proper/commons-rng/] be OK? > Create logo for Apache Commons Numbers > -- > > Key: NUMBERS-24 > URL: https://issues.apache.org/jira/browse/NUMBERS-24 > Project: Commons Numbers > Issue Type: Improvement >Reporter: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0 > > > The project currently has no logo. There is a Commons Math logo in the > project site resources folder, that needs to be replaced by a new original > logo. > See https://www.apache.org/foundation/marks/pmcs for trademark notes too. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (COMPRESS-385) Add detect() to CompressorStreamFactory
[
https://issues.apache.org/jira/browse/COMPRESS-385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved COMPRESS-385.
-
Resolution: Fixed
true, thanks
> Add detect() to CompressorStreamFactory
> ---
>
> Key: COMPRESS-385
> URL: https://issues.apache.org/jira/browse/COMPRESS-385
> Project: Commons Compress
> Issue Type: Improvement
>Reporter: Tim Allison
>Priority: Minor
> Fix For: 1.14
>
>
> On TIKA-1631, several users have requested that we try to avoid an OOM when a
> corrupted Z file is "detected" by CompressorStreamFactory.
> In Tika, for detection, we're creating the stream via CompressorStreamFactory
> and then "detecting" based on what stream was created. Given that there can
> be some overhead in creating the stream and that there can be an OOM for a
> corrupt Z file, it would be great to add a {{detect(InputStream is)}} option
> in CompressorStreamFactory.
> PR on way.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
