[jira] [Commented] (CRYPTO-139) adding suuport for AARCH64 architecture in common crypto
[ https://issues.apache.org/jira/browse/CRYPTO-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815988#comment-16815988 ] ossdev commented on CRYPTO-139: --- Issue is fixed by PR [https://github.com/apache/commons-crypto/pull/93] [https://github.com/apache/commons-crypto/pull/92] test report is attached for the reference > adding suuport for AARCH64 architecture in common crypto > > > Key: CRYPTO-139 > URL: https://issues.apache.org/jira/browse/CRYPTO-139 > Project: Commons Crypto > Issue Type: New Feature >Reporter: puresoftware >Priority: Critical > Attachments: CRYPTO-139-commons-crypto.patch > > > AARCH 64 architecture support is missing in the exiting common-crypto code. > Now we did some modification in the code level and add the support for > AARCH64. Now the common-crypto project can be used in aarch64 platform and > also compatible with openssl 1.1.x. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-lang] coveralls commented on issue #417: (doc) Fixing couple of dangling javadocs, converted to comments.
coveralls commented on issue #417: (doc) Fixing couple of dangling javadocs, converted to comments. URL: https://github.com/apache/commons-lang/pull/417#issuecomment-482429169 [](https://coveralls.io/builds/22762632) Coverage decreased (-0.007%) to 95.384% when pulling **82cfd26b56c5dd9481eecfe73cea8f2ccf01a5e6 on ethanwood17:fix-javadocs** into **24ebbb069b59c7729010ce7c7a7c59b28a4620ef on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-lang] ethanwood17 opened a new pull request #417: (doc) Fixing couple of dangling javadocs, converted to comments.
ethanwood17 opened a new pull request #417: (doc) Fixing couple of dangling javadocs, converted to comments. URL: https://github.com/apache/commons-lang/pull/417 Fixing couple of dangling javadocs, converted to comments. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (GEOMETRY-50) Overflow in Vector norm and distance
[ https://issues.apache.org/jira/browse/GEOMETRY-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815894#comment-16815894 ] Matt Juntunen commented on GEOMETRY-50: --- Sounds good to me. PR? > Overflow in Vector norm and distance > > > Key: GEOMETRY-50 > URL: https://issues.apache.org/jira/browse/GEOMETRY-50 > Project: Apache Commons Geometry > Issue Type: Bug >Reporter: Baljit Singh >Priority: Major > > In Euclidean Vector classes (Vector2D, Vector3D), norm() and distance() rely > on Math.sqrt(), which can overflow if the components of the vectors are > large. Instead, they should rely on SafeNorm. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEOMETRY-51) EpsilonDoublePrecisionContext allows negative & NaN epsilon
[
https://issues.apache.org/jira/browse/GEOMETRY-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815892#comment-16815892
]
Matt Juntunen commented on GEOMETRY-51:
---
We should probably just check for this on construction and throw an
{{IllegalArgumentException}}. Feel free to submit a PR on Github.
> EpsilonDoublePrecisionContext allows negative & NaN epsilon
> ---
>
> Key: GEOMETRY-51
> URL: https://issues.apache.org/jira/browse/GEOMETRY-51
> Project: Apache Commons Geometry
> Issue Type: Bug
>Reporter: Baljit Singh
>Priority: Major
>
> EpsilonDoublePrecisionContext does not validate the epsilon to be positive (0
> or greater). The comparison is based on Precision.compareTo(double, double,
> double), which itself calls Precision.equals(double, double, double), which
> then compares using Math.abs(y - x) <= eps. If epsilon is negative or NaN,
> the comparison is invalid.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (VFS-686) Upgrade Jackrabbit dependency to the latest 2.x
[ https://issues.apache.org/jira/browse/VFS-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815886#comment-16815886 ] Gary Gregory commented on VFS-686: -- The link from GihHub to GitBox seems broken; see my email on the dev ML. I want to wait to merge this until it is fixed... > Upgrade Jackrabbit dependency to the latest 2.x > --- > > Key: VFS-686 > URL: https://issues.apache.org/jira/browse/VFS-686 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Woonsan Ko >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The current dependency, Jackrabbit 1.6.5, still depends on HttpClient 3.x, > while Jackrabbit 2.x depends on HttpClient 4.x. > So, WebDAV file system provider should use the latest stable version of > Jackrabbit 2.x. > As of VFS-360, it is possible to let the WebDAV file system use > HttpComponents 4.x. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-vfs] woonsan commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x
woonsan commented on issue #52: VFS-686: webdav4 provider based on the latest Jackrabbit 2.x URL: https://github.com/apache/commons-vfs/pull/52#issuecomment-482395737 Now it's really ready to review. It now depends on the latest JR release: 2.19.2. Thanks! This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (VFS-686) Upgrade Jackrabbit dependency to the latest 2.x
[ https://issues.apache.org/jira/browse/VFS-686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815876#comment-16815876 ] Woonsan Ko commented on VFS-686: The pull request ( https://github.com/apache/commons-vfs/pull/52 ) is now ready to review. No more JR snapshot dependency; now using the latest release, 2.19.2. Thanks! > Upgrade Jackrabbit dependency to the latest 2.x > --- > > Key: VFS-686 > URL: https://issues.apache.org/jira/browse/VFS-686 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Woonsan Ko >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The current dependency, Jackrabbit 1.6.5, still depends on HttpClient 3.x, > while Jackrabbit 2.x depends on HttpClient 4.x. > So, WebDAV file system provider should use the latest stable version of > Jackrabbit 2.x. > As of VFS-360, it is possible to let the WebDAV file system use > HttpComponents 4.x. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (VFS-686) Upgrade Jackrabbit dependency to the latest 2.x
[ https://issues.apache.org/jira/browse/VFS-686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Woonsan Ko updated VFS-686: --- Labels: pull-request-available (was: ) > Upgrade Jackrabbit dependency to the latest 2.x > --- > > Key: VFS-686 > URL: https://issues.apache.org/jira/browse/VFS-686 > Project: Commons VFS > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Woonsan Ko >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > > The current dependency, Jackrabbit 1.6.5, still depends on HttpClient 3.x, > while Jackrabbit 2.x depends on HttpClient 4.x. > So, WebDAV file system provider should use the latest stable version of > Jackrabbit 2.x. > As of VFS-360, it is possible to let the WebDAV file system use > HttpComponents 4.x. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-rng] aherbert merged pull request #34: RNG utilities command line application
aherbert merged pull request #34: RNG utilities command line application URL: https://github.com/apache/commons-rng/pull/34 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-rng] coveralls edited a comment on issue #34: RNG utilities command line application
coveralls edited a comment on issue #34: RNG utilities command line application URL: https://github.com/apache/commons-rng/pull/34#issuecomment-479544065 [](https://coveralls.io/builds/22754847) Coverage decreased (-0.01%) to 98.473% when pulling **6a383817c3ffca3c5538dbfe4fb5206d578cbea3 on aherbert:rng-utils** into **c258e5d182184cba600e1f9248fde5223e30d55a on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-rng] aherbert commented on issue #34: RNG utilities command line application
aherbert commented on issue #34: RNG utilities command line application URL: https://github.com/apache/commons-rng/pull/34#issuecomment-482274155 A further update to the examples-stress application adds: - `output` command to write output from an RNG to file - `bridge` command to test passing the integer data from Java to c - `endian` command to show the native platform endianness This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Closed] (CONFIGURATION-743) Update optional library snakeyaml from 1.23 to 1.24.
[ https://issues.apache.org/jira/browse/CONFIGURATION-743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed CONFIGURATION-743. -- Resolution: Fixed Fix Version/s: 2.5 In git master. > Update optional library snakeyaml from 1.23 to 1.24. > > > Key: CONFIGURATION-743 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-743 > Project: Commons Configuration > Issue Type: Improvement >Reporter: Gary Gregory >Priority: Major > Fix For: 2.5 > > > Update optional library snakeyaml from 1.23 to 1.24. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CONFIGURATION-743) Update optional library snakeyaml from 1.23 to 1.24.
Gary Gregory created CONFIGURATION-743: -- Summary: Update optional library snakeyaml from 1.23 to 1.24. Key: CONFIGURATION-743 URL: https://issues.apache.org/jira/browse/CONFIGURATION-743 Project: Commons Configuration Issue Type: Improvement Reporter: Gary Gregory Update optional library snakeyaml from 1.23 to 1.24. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (DBCP-543) Update Apache Commons Pool from 2.6.1 to 2.6.2.
[ https://issues.apache.org/jira/browse/DBCP-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory closed DBCP-543. - Resolution: Fixed Fix Version/s: 2.6.1 > Update Apache Commons Pool from 2.6.1 to 2.6.2. > --- > > Key: DBCP-543 > URL: https://issues.apache.org/jira/browse/DBCP-543 > Project: Commons DBCP > Issue Type: Improvement >Reporter: Gary Gregory >Priority: Major > Fix For: 2.6.1 > > > Update Apache Commons Pool from 2.6.1 to 2.6.2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (DBCP-543) Update Apache Commons Pool from 2.6.1 to 2.6.2.
Gary Gregory created DBCP-543: - Summary: Update Apache Commons Pool from 2.6.1 to 2.6.2. Key: DBCP-543 URL: https://issues.apache.org/jira/browse/DBCP-543 Project: Commons DBCP Issue Type: Improvement Reporter: Gary Gregory Update Apache Commons Pool from 2.6.1 to 2.6.2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (POOL-365) Update ASM from 7.0 to 7.1
[ https://issues.apache.org/jira/browse/POOL-365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved POOL-365. --- Resolution: Fixed Fix Version/s: 2.7.0 In git master. > Update ASM from 7.0 to 7.1 > -- > > Key: POOL-365 > URL: https://issues.apache.org/jira/browse/POOL-365 > Project: Commons Pool > Issue Type: New Feature >Reporter: Gary Gregory >Priority: Major > Fix For: 2.7.0 > > > Update ASM from 7.0 to 7.1. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEOMETRY-51) EpsilonDoublePrecisionContext allows negative & NaN epsilon
[ https://issues.apache.org/jira/browse/GEOMETRY-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Baljit Singh updated GEOMETRY-51: - Description: EpsilonDoublePrecisionContext does not validate the epsilon to be positive (0 or greater). The comparison is based on Precision.compareTo(double, double, double), which itself calls Precision.equals(double, double, double), which then compares using Math.abs(y - x) <= eps. If epsilon is negative or NaN, the comparison is invalid. (was: EpsilonDoublePrecisionContext does not validate the epsilon to be positive (0 or greater). The comparison is based on Precision.compareTo(double, double, double), which itself calls Precision.equals(double, double, double), which then compares using Math.abs(y - x) <= eps. If epsilon is negative, the comparison in invalid.) > EpsilonDoublePrecisionContext allows negative & NaN epsilon > --- > > Key: GEOMETRY-51 > URL: https://issues.apache.org/jira/browse/GEOMETRY-51 > Project: Apache Commons Geometry > Issue Type: Bug >Reporter: Baljit Singh >Priority: Major > > EpsilonDoublePrecisionContext does not validate the epsilon to be positive (0 > or greater). The comparison is based on Precision.compareTo(double, double, > double), which itself calls Precision.equals(double, double, double), which > then compares using Math.abs(y - x) <= eps. If epsilon is negative or NaN, > the comparison is invalid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEOMETRY-51) EpsilonDoublePrecisionContext allows negative & NaN epsilon
[ https://issues.apache.org/jira/browse/GEOMETRY-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Baljit Singh updated GEOMETRY-51: - Summary: EpsilonDoublePrecisionContext allows negative & NaN epsilon (was: EpsilonDoublePrecisionContext allows negative epsilon) > EpsilonDoublePrecisionContext allows negative & NaN epsilon > --- > > Key: GEOMETRY-51 > URL: https://issues.apache.org/jira/browse/GEOMETRY-51 > Project: Apache Commons Geometry > Issue Type: Bug >Reporter: Baljit Singh >Priority: Major > > EpsilonDoublePrecisionContext does not validate the epsilon to be positive (0 > or greater). The comparison is based on Precision.compareTo(double, double, > double), which itself calls Precision.equals(double, double, double), which > then compares using Math.abs(y - x) <= eps. If epsilon is negative, the > comparison in invalid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (STATISTICS-7) Stream-based Java statistical processing
[ https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815553#comment-16815553 ] Eric Barnhill commented on STATISTICS-7: Welcome aboard [~Udit Arora] . Fork the commons-statistics repository and start making contributions. You submit the contributions with a pull request. I will review the pull request and interact with you until it is satisfactory. Then, probably, Gilles will review my review :) . Even if we can't get you a GSoc slot this year, if you start contributing you will be in a great position for one next year. Because the main thing we want to know is, are these applicants going to stick around, contribute, become part of the project. > Stream-based Java statistical processing > > > Key: STATISTICS-7 > URL: https://issues.apache.org/jira/browse/STATISTICS-7 > Project: Apache Commons Statistics > Issue Type: New Feature >Reporter: Eric Barnhill >Priority: Major > Labels: GSoC2019, gsoc2019, statistics, streams > > The new component aims to be a library of commons statistics functions > synchronized with the latest developments in the Java language, in particular > Java's functional programming syntax. > The library will make commonly used statistical functions available to an end > user through a simple grammar comparable to commons-math-statistics or > scikit-learn, while under the hood will implement Java's mapping, streaming, > and other producer and consumer functions to ensure the statistical methods > run optimally in new Java implementations. > As functional programming grows increasingly central to big data applications > we believe these libraries will play an important function in the data > engineering ecosystem. In particular, data engineering is widely done with > Java, then passed to other languages for data-scientific analyses; however, > the common availability of functionally implemented statistical mapping and > reductions in Java could prove very useful at the interface of data science > and engineering, by enabling teams to more easily perform reductions on the > engineering side before handing off to the analysis side. > Developers working on the project will have the opportunity to demonstrate > Java programming, functional programming, algorithm design, and data science > skills and receive authorship on a commons project that is likely to be > widely used. > The ideal contributor will also be able to help with important architectural > decision making. The old source of these libraries, commons-math, grew too > large, hierarchically complex and interdependent for the commons mission. The > developers on this project need to make architectural choices that will > enable the statiscal code to be lightweight and reusable, with a minimum of > outside dependencies while avoiding redundancy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEOMETRY-51) EpsilonDoublePrecisionContext allows negative epsilon
Baljit Singh created GEOMETRY-51: Summary: EpsilonDoublePrecisionContext allows negative epsilon Key: GEOMETRY-51 URL: https://issues.apache.org/jira/browse/GEOMETRY-51 Project: Apache Commons Geometry Issue Type: Bug Reporter: Baljit Singh EpsilonDoublePrecisionContext does not validate the epsilon to be positive (0 or greater). The comparison is based on Precision.compareTo(double, double, double), which itself calls Precision.equals(double, double, double), which then compares using Math.abs(y - x) <= eps. If epsilon is negative, the comparison in invalid. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (POOL-364) Update from Java 7 to Java 8.
[ https://issues.apache.org/jira/browse/POOL-364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory resolved POOL-364. --- Resolution: Fixed Fix Version/s: 2.7.0 In git master. > Update from Java 7 to Java 8. > - > > Key: POOL-364 > URL: https://issues.apache.org/jira/browse/POOL-364 > Project: Commons Pool > Issue Type: New Feature >Reporter: Gary Gregory >Priority: Major > Fix For: 2.7.0 > > > Update from Java 7 to Java 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (POOL-365) Update ASM from 7.0 to 7.1
Gary Gregory created POOL-365: - Summary: Update ASM from 7.0 to 7.1 Key: POOL-365 URL: https://issues.apache.org/jira/browse/POOL-365 Project: Commons Pool Issue Type: New Feature Reporter: Gary Gregory Update ASM from 7.0 to 7.1. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (POOL-364) Update from Java 7 to Java 8.
Gary Gregory created POOL-364: - Summary: Update from Java 7 to Java 8. Key: POOL-364 URL: https://issues.apache.org/jira/browse/POOL-364 Project: Commons Pool Issue Type: New Feature Reporter: Gary Gregory Update from Java 7 to Java 8. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (VFS-699) Add setting for FTP encoding autodetection #58
Gary Gregory created VFS-699: Summary: Add setting for FTP encoding autodetection #58 Key: VFS-699 URL: https://issues.apache.org/jira/browse/VFS-699 Project: Commons VFS Issue Type: New Feature Reporter: Gary Gregory Add setting for FTP encoding autodetection #58. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (LANG-1448) Commons-Lang3; StringUtils JavaDoc page wrong for containsOnly and containsNone
[
https://issues.apache.org/jira/browse/LANG-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Tompkins updated LANG-1448:
---
Assignee: Rob Tompkins
> Commons-Lang3; StringUtils JavaDoc page wrong for containsOnly and
> containsNone
> ---
>
> Key: LANG-1448
> URL: https://issues.apache.org/jira/browse/LANG-1448
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 3.8.1
>Reporter: David W. Burhans
>Assignee: Rob Tompkins
>Priority: Minor
>
> TLDR: 'xxx' is not java and can never compile.
>
> The descriptions of the
> containsOnly([CharSequence|https://docs.oracle.com/javase/7/docs/api/java/lang/CharSequence.html?is-external=true]
> cs, char... valid) and
> containsNone([CharSequence|https://docs.oracle.com/javase/7/docs/api/java/lang/CharSequence.html?is-external=true]
> cs, char... valid) methods contain incorrect examples.
>
> One such bad example:
> StringUtils.containsOnly("abab", 'abc') = true
>
> This is not Java code and can never compile.
>
> The description of the
> containsAny([CharSequence|https://docs.oracle.com/javase/7/docs/api/java/lang/CharSequence.html?is-external=true]
> cs, char... valid) method does contain correct examples.
>
> One such correct example:
> StringUtils.containsAny("zzabyycdxx",['z','a']) = true
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (LANG-1448) Commons-Lang3; StringUtils JavaDoc page wrong for containsOnly and containsNone
David W. Burhans created LANG-1448:
--
Summary: Commons-Lang3; StringUtils JavaDoc page wrong for
containsOnly and containsNone
Key: LANG-1448
URL: https://issues.apache.org/jira/browse/LANG-1448
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 3.8.1
Reporter: David W. Burhans
TLDR: 'xxx' is not java and can never compile.
The descriptions of the
containsOnly([CharSequence|https://docs.oracle.com/javase/7/docs/api/java/lang/CharSequence.html?is-external=true]
cs, char... valid) and
containsNone([CharSequence|https://docs.oracle.com/javase/7/docs/api/java/lang/CharSequence.html?is-external=true]
cs, char... valid) methods contain incorrect examples.
One such bad example:
StringUtils.containsOnly("abab", 'abc') = true
This is not Java code and can never compile.
The description of the
containsAny([CharSequence|https://docs.oracle.com/javase/7/docs/api/java/lang/CharSequence.html?is-external=true]
cs, char... valid) method does contain correct examples.
One such correct example:
StringUtils.containsAny("zzabyycdxx",['z','a']) = true
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (STATISTICS-7) Stream-based Java statistical processing
[ https://issues.apache.org/jira/browse/STATISTICS-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815446#comment-16815446 ] Udit Arora commented on STATISTICS-7: - Sir Now since I have to wait.. what could I do towards this project? Anything that I should explore or learn..? > Stream-based Java statistical processing > > > Key: STATISTICS-7 > URL: https://issues.apache.org/jira/browse/STATISTICS-7 > Project: Apache Commons Statistics > Issue Type: New Feature >Reporter: Eric Barnhill >Priority: Major > Labels: GSoC2019, gsoc2019, statistics, streams > > The new component aims to be a library of commons statistics functions > synchronized with the latest developments in the Java language, in particular > Java's functional programming syntax. > The library will make commonly used statistical functions available to an end > user through a simple grammar comparable to commons-math-statistics or > scikit-learn, while under the hood will implement Java's mapping, streaming, > and other producer and consumer functions to ensure the statistical methods > run optimally in new Java implementations. > As functional programming grows increasingly central to big data applications > we believe these libraries will play an important function in the data > engineering ecosystem. In particular, data engineering is widely done with > Java, then passed to other languages for data-scientific analyses; however, > the common availability of functionally implemented statistical mapping and > reductions in Java could prove very useful at the interface of data science > and engineering, by enabling teams to more easily perform reductions on the > engineering side before handing off to the analysis side. > Developers working on the project will have the opportunity to demonstrate > Java programming, functional programming, algorithm design, and data science > skills and receive authorship on a commons project that is likely to be > widely used. > The ideal contributor will also be able to help with important architectural > decision making. The old source of these libraries, commons-math, grew too > large, hierarchically complex and interdependent for the commons mission. The > developers on this project need to make architectural choices that will > enable the statiscal code to be lightweight and reusable, with a minimum of > outside dependencies while avoiding redundancy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (RNG-90) Improve nextInt(int) and nextLong(long) for powers of 2
Alex D Herbert created RNG-90:
-
Summary: Improve nextInt(int) and nextLong(long) for powers of 2
Key: RNG-90
URL: https://issues.apache.org/jira/browse/RNG-90
Project: Commons RNG
Issue Type: Improvement
Components: core
Affects Versions: 1.3
Reporter: Alex D Herbert
Assignee: Alex D Herbert
The code for nextInt(int) checks the range number n is a power of two and if so
it computes a fast solution:
{code:java}
return (int) ((n * (long) (nextInt() >>> 1)) >> 31);
{code}
This scales a 31 bit positive number by a power of 2 (i.e. n) then discards the
least significant bits. An alternative result can be achieved using a mask to
discard the most significant bits:
{code:java}
return nextInt() & (n-1)
{code}
This works if n is a power of 2 as (n-1) will be all the bits set below it.
Note: This method is employed by ThreadLocalRandom.
It also makes the method applicable to nextLong(long) since you no longer
require the long multiplication arithmetic.
The mask version is applicable to any generator with a long period in the lower
order bits. The current version for any generator with a short period in the
lower order bits. The non-masking method is employed by {{java.util.Random}}
which is a weak generator.
The methods are currently in {{BaseProvider}}. I suggest dividing the methods
to use protected methods to compute the result:
{code:java}
@Override
public int nextInt(int n) {
checkStrictlyPositive(n);
final int nm1 = n - 1;
if ((n & nm1) == 0) {
// Range is a power of 2
return nextIntPowerOfTwo(n, nm1);
}
return nextIntNonPowerOfTwo(n, nm1);
}
/**
* Generates an {@code int} value between 0 (inclusive) and the
* specified value (exclusive).
*
* @param n Bound on the random number to be returned. This is a power of 2.
* @param nm1 The bound value minus 1.
* @return a random {@code int} value between 0 (inclusive) and {@code n}
* (exclusive).
*/
protected int nextIntPowerOfTwo(int n, int nm1) {
return nextInt() & nm1;
}
/**
* Generates an {@code int} value between 0 (inclusive) and the specified value
* (exclusive).
*
* @param n Bound on the random number to be returned. This is not a power of 2.
* @param nm1 The bound value minus 1.
* @return a random {@code int} value between 0 (inclusive) and {@code n}
(exclusive).
*/
protected int nextIntNonPowerOfTwo(int n, int nm1) {
int bits;
int val;
do {
bits = nextInt() >>> 1;
val = bits % n;
} while (bits - val + nm1 < 0);
return val;
}
@Override
public long nextLong(long n) {
checkStrictlyPositive(n);
final long nm1 = n - 1;
if ((n & nm1) == 0) {
// Range is a power of 2
return nextLongPowerOfTwo(n, nm1);
}
return nextLongNonPowerOfTwo(n, nm1);
}
/**
* Generates an {@code long} value between 0 (inclusive) and the
* specified value (exclusive).
*
* @param n Bound on the random number to be returned. This is a power of 2.
* @param nm1 The bound value minus 1.
* @return a random {@code long} value between 0 (inclusive) and {@code n}
* (exclusive).
*/
protected long nextLongPowerOfTwo(long n, long nm1) {
return nextLong() & nm1;
}
/**
* Generates an {@code long} value between 0 (inclusive) and the specified value
* (exclusive).
*
* @param n Bound on the random number to be returned. This is not a power of 2.
* @param nm1 The bound value minus 1.
* @return a random {@code long} value between 0 (inclusive) and {@code n}
(exclusive).
*/
protected long nextLongNonPowerOfTwo(long n, long nm1) {
long bits;
long val;
do {
bits = nextLong() >>> 1;
val = bits % n;
} while (bits - val + nm1 < 0);
return val;
}
{code}
This will update all providers to use the new method. Then the JDK
implementation can be changed to override the default:
{code:java}
@Override
protected int nextIntPowerOfTwo(int n, int nm1) {
return (int) ((n * (long) (nextInt() >>> 1)) >> 31);
}
@Override
protected long nextLongPowerOfTwo(long n, long nm1) {
return nextLongNonPowerOfTwo(n, nm1);
}
{code}
I do not know how the use of protected methods will affect performance. An
alternative is to inline the entire computation for the new masking method:
{code:java}
public int nextInt(int n) {
checkStrictlyPositive(n);
final int nm1 = n - 1;
if ((n & nm1) == 0) {
// Range is a power of 2
return nextInt() & nm1;
}
int bits;
int val;
do {
bits = nextInt() >>> 1;
val = bits % n;
} while (bits - val + nm1 < 0);
return val;
}
{code}
Then rewrite the entire method in the JDK generator. This will be less flexible
if other generators are added than have short periods in the lower order bits.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-io] garydgregory commented on issue #40: IO-279: Added ignoreNew parameter on instantiating Tailer.
garydgregory commented on issue #40: IO-279: Added ignoreNew parameter on instantiating Tailer. URL: https://github.com/apache/commons-io/pull/40#issuecomment-482089524 Hi @Misiu, Thanks for the ping. I am -1 to this PR because: - It breaks binary compatibility. You can tell since this build is broken. See the red "All checks have failed" note on this page and the associated Travis builds. - It does not contain a unit test to test the new feature. Gary This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (IO-279) Tailer erroneously considers file as new
[
https://issues.apache.org/jira/browse/IO-279?focusedWorklogId=226080=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-226080
]
ASF GitHub Bot logged work on IO-279:
-
Author: ASF GitHub Bot
Created on: 11/Apr/19 12:14
Start Date: 11/Apr/19 12:14
Worklog Time Spent: 10m
Work Description: garydgregory commented on issue #40: IO-279: Added
ignoreNew parameter on instantiating Tailer.
URL: https://github.com/apache/commons-io/pull/40#issuecomment-482089524
Hi @Misiu,
Thanks for the ping.
I am -1 to this PR because:
- It breaks binary compatibility. You can tell since this build is broken.
See the red "All checks have failed" note on this page and the associated
Travis builds.
- It does not contain a unit test to test the new feature.
Gary
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 226080)
Time Spent: 20m (was: 10m)
> Tailer erroneously considers file as new
>
>
> Key: IO-279
> URL: https://issues.apache.org/jira/browse/IO-279
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.0.1, 2.4
>Reporter: Sergio Bossa
>Priority: Major
> Attachments: IO-279.patch, disable_resetting.patch, fix-tailer.patch,
> modify-test-fixed.patch, modify-test.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Tailer sometimes erroneously considers the tailed file as new, forcing a
> repositioning at the start of the file: I'm still unable to reproduce this in
> a test case, because it only happens to me with huge log files during Apache
> Tomcat startup.
> This is the piece of code causing the problem:
> {code}
> // See if the file needs to be read again
> if (length > position) {
> // The file has more content than it did last time
> last = System.currentTimeMillis();
> position = readLines(reader);
> } else if (FileUtils.isFileNewer(file, last)) {
> /* This can happen if the file is truncated or overwritten
> * with the exact same length of information. In cases like
> * this, the file position needs to be reset
> */
> position = 0;
> reader.seek(position); // cannot be null here
> // Now we can read new lines
> last = System.currentTimeMillis();
> position = readLines(reader);
> }
> {code}
> What probably happens is that the new file content is about to be written on
> disk, the date is already updated but content is still not flushed, so actual
> length is untouched and there you go.
> In other words, I think there should be some better method to verify the
> condition above, rather than relying only on dates: keeping and comparing the
> hash code of the latest line may be a solution, but may hurt performances ...
> other ideas?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (POOL-267) Use of AbandonListener instead of PrintWriter when a pool object is detected in an abandon state
[ https://issues.apache.org/jira/browse/POOL-267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated POOL-267: -- Fix Version/s: (was: 2.6.2) 2.7.0 > Use of AbandonListener instead of PrintWriter when a pool object is detected > in an abandon state > > > Key: POOL-267 > URL: https://issues.apache.org/jira/browse/POOL-267 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Anthony Communier >Priority: Major > Fix For: 2.7.0 > > Attachments: AbandonedListenerPatch.diff > > > I would be great to have a more flexible mecanism for abandon detection. > Having just a PrintWriter is too restrictive. With an AbandonListener it > would be possible to make more things like using log API or enabling > supervision of application. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (POOL-321) ObjectPool.addObject limiting us to add an object with parameter
[ https://issues.apache.org/jira/browse/POOL-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated POOL-321: -- Fix Version/s: (was: 2.6.2) 2.7.0 > ObjectPool.addObject limiting us to add an object with parameter > > > Key: POOL-321 > URL: https://issues.apache.org/jira/browse/POOL-321 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.4 >Reporter: Ugur Bayram >Priority: Major > Fix For: 2.7.0 > > > In current implementation we are not able to add an object with parameter to > the pool. addObject does not take any parameter > Consider of a user pool where the content of each user might differ. In such > cases, current implementation have limitation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (POOL-272) GenericKeyedObjectPool should have a per-key version of numTestsPerEvictionRun
[ https://issues.apache.org/jira/browse/POOL-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated POOL-272: -- Fix Version/s: (was: 2.6.2) 2.7.0 > GenericKeyedObjectPool should have a per-key version of numTestsPerEvictionRun > -- > > Key: POOL-272 > URL: https://issues.apache.org/jira/browse/POOL-272 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Michael Berman >Priority: Major > Fix For: 2.7.0 > > > It would be cool if there were a per-key version of numTestsPerEvictionRun. I > have a use case where I'm primarily configuring my pool size (min/maxidle and > maxtotal) per key, but don't want to cap the number of keys or total number > of objects in the pool. In this case, it seems like the number of tests i > would want per eviction run is fixed with respect to my per-key pool size, > but that I would want it scale with the number of keys. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (POOL-353) Return false if current connection count is less then MinIdle in DefaultEvictionPolicy
[ https://issues.apache.org/jira/browse/POOL-353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated POOL-353: -- Fix Version/s: (was: 2.6.2) 2.7.0 > Return false if current connection count is less then MinIdle in > DefaultEvictionPolicy > -- > > Key: POOL-353 > URL: https://issues.apache.org/jira/browse/POOL-353 > Project: Commons Pool > Issue Type: Improvement >Affects Versions: 2.6.0 >Reporter: jefferyyuan >Assignee: Mark Struberg >Priority: Minor > Fix For: 3.0, 2.7.0 > > > At > [https://github.com/apache/commons-pool/blob/master/src/main/java/org/apache/commons/pool2/impl/BaseGenericObjectPool.java#L1140] > It first evicts idle connections, then re-creates idle instances to > ensureMinIdle. > DefaultEvictionPolicy will close idle connection even when there is <= > MinIdle connections. > https://github.com/apache/commons-pool/blob/master/src/main/java/org/apache/commons/pool2/impl/DefaultEvictionPolicy.java > > In case minIdle is set to large, it would causes problems like frequent full > GC. > * the connection related objects are promoted and stored in old gen, then > evict will close them and make it gc-able, and ensureMinIdle will create new > connections which will be eventually promoted to old gen and gc-able again. > * Old gen will grow quickly and need full gc. > We can solve the problem if we always keep minIdle connections in the > DefaultEvictionPolicy. > Or at least add doc to DefaultEvictionPolicy and may provide another > EvictionPolicy which returns false if current connection count is less then > MinIdle and refer it in DefaultEvictionPolicy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (IO-279) Tailer erroneously considers file as new
[
https://issues.apache.org/jira/browse/IO-279?focusedWorklogId=226075=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-226075
]
ASF GitHub Bot logged work on IO-279:
-
Author: ASF GitHub Bot
Created on: 11/Apr/19 11:56
Start Date: 11/Apr/19 11:56
Worklog Time Spent: 10m
Work Description: Misiu commented on issue #40: IO-279: Added ignoreNew
parameter on instantiating Tailer.
URL: https://github.com/apache/commons-io/pull/40#issuecomment-482084210
@garydgregory could You take a look at this PR?
We need this for openHAB -
https://github.com/openhab/openhab2-addons/issues/5442
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
---
Worklog Id: (was: 226075)
Time Spent: 10m
Remaining Estimate: 0h
> Tailer erroneously considers file as new
>
>
> Key: IO-279
> URL: https://issues.apache.org/jira/browse/IO-279
> Project: Commons IO
> Issue Type: Bug
>Affects Versions: 2.0.1, 2.4
>Reporter: Sergio Bossa
>Priority: Major
> Attachments: IO-279.patch, disable_resetting.patch, fix-tailer.patch,
> modify-test-fixed.patch, modify-test.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Tailer sometimes erroneously considers the tailed file as new, forcing a
> repositioning at the start of the file: I'm still unable to reproduce this in
> a test case, because it only happens to me with huge log files during Apache
> Tomcat startup.
> This is the piece of code causing the problem:
> {code}
> // See if the file needs to be read again
> if (length > position) {
> // The file has more content than it did last time
> last = System.currentTimeMillis();
> position = readLines(reader);
> } else if (FileUtils.isFileNewer(file, last)) {
> /* This can happen if the file is truncated or overwritten
> * with the exact same length of information. In cases like
> * this, the file position needs to be reset
> */
> position = 0;
> reader.seek(position); // cannot be null here
> // Now we can read new lines
> last = System.currentTimeMillis();
> position = readLines(reader);
> }
> {code}
> What probably happens is that the new file content is about to be written on
> disk, the date is already updated but content is still not flushed, so actual
> length is untouched and there you go.
> In other words, I think there should be some better method to verify the
> condition above, rather than relying only on dates: keeping and comparing the
> hash code of the latest line may be a solution, but may hurt performances ...
> other ideas?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] [commons-io] Misiu commented on issue #40: IO-279: Added ignoreNew parameter on instantiating Tailer.
Misiu commented on issue #40: IO-279: Added ignoreNew parameter on instantiating Tailer. URL: https://github.com/apache/commons-io/pull/40#issuecomment-482084210 @garydgregory could You take a look at this PR? We need this for openHAB - https://github.com/openhab/openhab2-addons/issues/5442 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (RNG-67) Instructions for how to build and run the examples-stress code
[
https://issues.apache.org/jira/browse/RNG-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gilles updated RNG-67:
--
Description: As discussed in RNG-57 there are a few steps needed in order
to be able to run the stress tests DieHarder and TestU01. I made some notes as
I was performing stress tests of the new core code for {{nextBoolean}}. I can
put all the changes into a PR for review. (was: As discussed in
[RNG-57|http://example.com] there are a few steps needed in order to be able to
run the stress tests DieHarder and TestU01. I made some notes as I was
performing stress tests of the new core code for {{nextBoolean}}. I can put all
the changes into a PR for review.)
> Instructions for how to build and run the examples-stress code
> --
>
> Key: RNG-67
> URL: https://issues.apache.org/jira/browse/RNG-67
> Project: Commons RNG
> Issue Type: Improvement
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Trivial
> Labels: documentation
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> As discussed in RNG-57 there are a few steps needed in order to be able to
> run the stress tests DieHarder and TestU01. I made some notes as I was
> performing stress tests of the new core code for {{nextBoolean}}. I can put
> all the changes into a PR for review.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (RNG-67) Instructions for how to build and run the examples-stress code
[
https://issues.apache.org/jira/browse/RNG-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex D Herbert resolved RNG-67.
---
Resolution: Implemented
In master.
> Instructions for how to build and run the examples-stress code
> --
>
> Key: RNG-67
> URL: https://issues.apache.org/jira/browse/RNG-67
> Project: Commons RNG
> Issue Type: Improvement
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Priority: Trivial
> Labels: documentation
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> As discussed in [RNG-57|http://example.com] there are a few steps needed in
> order to be able to run the stress tests DieHarder and TestU01. I made some
> notes as I was performing stress tests of the new core code for
> {{nextBoolean}}. I can put all the changes into a PR for review.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (RNG-68) AhrensDieterMarsagliaTsangGammaSampler constructor can be optimised for the theta parameter
[
https://issues.apache.org/jira/browse/RNG-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alex D Herbert resolved RNG-68.
---
Resolution: Implemented
Assignee: Alex D Herbert
In master.
> AhrensDieterMarsagliaTsangGammaSampler constructor can be optimised for the
> theta parameter
> ---
>
> Key: RNG-68
> URL: https://issues.apache.org/jira/browse/RNG-68
> Project: Commons RNG
> Issue Type: Improvement
> Components: sampling
>Affects Versions: 1.2
>Reporter: Alex D Herbert
>Assignee: Alex D Herbert
>Priority: Trivial
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The AhrensDieterExponentialSampler has two algorithms based on the {{theta}}
> parameter. The constructor precomputes factors for both algorithms even
> though only one algorithm will even be called.
> I suggest optimising the constructor using:
> {code:java}
> public AhrensDieterMarsagliaTsangGammaSampler(UniformRandomProvider rng,
> double alpha,
> double theta) {
> super(null);
> this.rng = rng;
> this.alpha = alpha;
> this.theta = theta;
> gaussian = new ZigguratNormalizedGaussianSampler(rng);
> if (theta < 1) {
> oneOverTheta = 1 / theta;
> bGSOptim = 1 + theta / Math.E;
> // Unused
> dOptim = cOptim = 0;
> } else {
> dOptim = theta - ONE_THIRD;
> cOptim = ONE_THIRD / Math.sqrt(dOptim);
> // Unused
> oneOverTheta = bGSOptim = 0;
> }
> }
> {code}
> An alternative is to split the two algorithms into two classes as was done
> for the {{PoissonSampler}} for small and large mean.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
