Re: Proposal to introduce JUnit 5 in commons-numbers
(please make sure to CC me on replies) +1 on this. One thing I'd like for us to avoid a mess of different junit versions making it difficult to know which runner will be executing the class. It would be great if we did a complete conversion and not just introduced new syntax. I've actually done this before on a largish Java project from JUnit3/4 to 5. It isn't hard, just a fair amount of mechanical code changes. On Wed, 22 May 2019 at 15:30, Eric Barnhill wrote: > +1 > > On Wed, May 22, 2019 at 3:15 PM Gilles Sadowski > wrote: > > > Hi. > > > > Le mer. 22 mai 2019 à 18:43, Heinrich Bohne a > > écrit : > > > > > > Right now, commons-numbers is using JUnit 4.12, the last stable version > > > of JUnit 4. As far as I am aware, there is no explicit syntax in JUnit > > > 4.12 for testing whether an exception is thrown apart from either using > > > the deprecated class ExpectedException or adding the "expected" > > > parameter to the Test annotation. The problem with the latter approach > > > is that it is impossible to ascertain where exactly in the annotated > > > method the exception is thrown – it could be thrown somewhere > unexpected > > > and the test will still pass. Besides, when testing the same exception > > > trigger with multiple different inputs, it is impractical to create a > > > separate method for each test case, which would be necessary with both > > > aforementioned approaches. > > > > > > This has led to the creation of constructs where the expected exception > > > is swallowed, which has been deemed undesirable > > > < > > > https://issues.apache.org/jira/browse/NUMBERS-99?focusedCommentId=16843419=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16843419 > > >. > > > Because of this, I propose to add JUnit 5 as a dependency in > > > commons-numbers. JUnit 5 has several "assertThrows" methods that would > > > solve the described dilemma. > > > > +1 > > > > Gilles > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > -- Eitan Adler
[VOTE] Release Apache Commons Configuration 2.5 based on RC1
To: dev@commons.apache.org Subject: [VOTE] Release Apache Commons Configuration 2.5 based on RC1 We have fixed quite a few bugs and added some significant enhancements since Apache Commons Configuration 2.4 was released, so I would like to release Apache Commons Configuration 2.5. Apache Commons Configuration 2.5 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/configuration/2.5-RC1 (svn revision 34200) The Git tag commons-configuration-2.5-RC1 commit for this RC is dc00a04783ea951280ba0cd8318f53e19acb707f which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=dc00a04783ea951280ba0cd8318f53e19acb707f You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-configuration.git --branch commons-configuration-2.5-RC1 commons-configuration-2.5-RC1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1439/org/apache/commons/commons-configuration2/2.5/ These are the artifacts and their hashes: #Release SHA-512s #Thu May 23 21:10:52 EDT 2019 commons-configuration2-2.5-bin.tar.gz=af36d6218f2b04492b1ecdb3a45c9eca0e782f38d1278076ce066b2e31c3a92fe7a10eef4639f1047bf25ae2bdc4e61e401b7713933886a221588ff276d713c1 commons-configuration2-2.5-bin.tar.gz.asc=5b28973721604ad88dd91918d4093876bab8d711851adcbbc641d6da555badc7cca508ec779d2ecdb846ad954063b34a04345e683652caeb4624bfc76c518d1f commons-configuration2-2.5-bin.zip=1133a75ab29fa15514fd050462feb2cf6de1cd03bca0a85c109474f2671189ff05ae966a44f0ee629b91fc9c7dea15e90e4704b82f70f2e517a444c689ea34c8 commons-configuration2-2.5-bin.zip.asc=5bb8a2ebaaacb974c52da36626937f33aec24479590830c8ec68d148abf7163e04c9b3bbc4f54c1608679ac4ad4ce6b1c70e5ff5402c4a592d838828808d9a81 commons-configuration2-2.5-javadoc.jar=9f8290afe2f663ead9ddae5034c7a08f9ee792cd48821e17fced1ca287a2fb58906e782c8b3f4428ccda1089193402407002f70194d5ecba09edbebf9fab commons-configuration2-2.5-javadoc.jar.asc=2b62b54400e81f1de39cfe17ed9aafa716a46b58dbf31b49270f85bbc53df09738decd7daec9fe84ef893824a63ed2d7333aa3b0d54524b879d5f17d98d3eb15 commons-configuration2-2.5-sources.jar=05b0675c7725a97cfc892267c44503be12f086f740f83f86b59bab902bd395c9b3f57fa37969993a1cab49a8d99266f29c984f331649d3800fe56a884a0bcc39 commons-configuration2-2.5-sources.jar.asc=42158d3cffd2403a6efd80b1654d252d2a164475e57c11a2a30159bd15216c87ccfdd9ce4609ceeffbd387350a93d4d2d2044af346db93f70812af80b14644d3 commons-configuration2-2.5-src.tar.gz=b69725d694f59678b690d50dc1f17718e7bd3deaa49a4dd30c20548b7df14494d27cec6325b6dd5a4da4adba368c26743ce80de147682cf49da1d5304f6bd9b1 commons-configuration2-2.5-src.tar.gz.asc=c274f8e4e1c575d3b423315019df312530910bcf465e7b109d4fcd7b6d4b671ed34f5cf7731c8fb98378940b1ae03d595e69db4cf94095ad7293a8afda8e2956 commons-configuration2-2.5-src.zip=57e5fa659506668a41f6fde8cc76f96152d0861d19a2f7dbd72dac56864aabf704b081fe029446de5c760ff0d1605f978d5322933c2627a0db73d9d4d1208293 commons-configuration2-2.5-src.zip.asc=15040a9ca0ec7a51df16ed86378656c28c345a0360dd234d118b0d00abadc0375cf031f864b92fbf3af6c0c799661e74d1d257a4b1c5dc2b53db3d8b350fcc95 commons-configuration2-2.5-test-sources.jar=756f6437475241b26b2ce190f8388227e058cefb862e48b98ac86b1886fa299902b77163baec789ead26f398912069b881fe1a1dfe62a1892b8245be31e13f5b commons-configuration2-2.5-test-sources.jar.asc=080cc1fbc4925bdfd5679d0d2ba60c67a0f594b2b585b010f273ed7a598f817ff9224d0790d2c2981460ea8de69ba67e77c11ee17aa6965bf398b94bd92e9306 commons-configuration2-2.5-tests.jar=ae8a35a0f3c832f8d0869ab900ad13b33537b0112ef320ef9718ad9e707a3a18292d785b0c78f2ade81a0d8967edeb4c92ff6ea4a796a57b3d62c2c153529078 commons-configuration2-2.5-tests.jar.asc=2b25ba280d7c210fb2e7cdc78e971557f365eb08a6645503003833f685ca88d848afb5b56abac5d2861473f01d2d2636ae442e825506c6f059f59bef1a8ba8d6 commons-configuration2-2.5.jar.asc=ab783f4b2e248786a0c7c914f5e80046b045b859713e7b94c97b4f4a65001db9270650917f00ee4ab8ca6e32fe6411f9ee9e17126b86751febcbdc7b403b08c1 commons-configuration2-2.5.pom.asc=6836729386d91565b4e489763a0930b6cacfa697719c563210b0dd3ec9f058060d254374b6fd53ff03ecb2e78227dc4b20128b85e04bbd56d4fc1483d6140666 I have tested this with 'mvn clean install site -Pjacoco' using: Apache Maven 3.6.1 (d66c9c0b3152b2e69ee9bac180bb8fcc8e6af555; 2019-04-04T15:00:29-04:00) Maven home: C:\Java\apache-maven-3.6.1\bin\.. Java version: 1.8.0_212, vendor: Oracle Corporation, runtime: C:\Program Files\Java\jdk1.8.0_212\jre Default locale: en_US, platform encoding: Cp1252 OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" Details of changes since 2.4 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/configuration/2.5-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/configuration/2.5-RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/configuration/2.5-RC1/site/index.html (note some *relative* links are broken and the 2.5 directories are not yet created - these
Re: [commons-compress] branch master updated: Capitalized the first word of the exception messages
Nice clean up :-)
Gary
On Thu, May 23, 2019, 09:00 wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> ebourg pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-compress.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new 31195ff Capitalized the first word of the exception messages
> 31195ff is described below
>
> commit 31195ffa28f505163d0d66242c89ee467e882127
> Author: Emmanuel Bourg
> AuthorDate: Thu May 23 15:00:41 2019 +0200
>
> Capitalized the first word of the exception messages
> ---
> .../compress/archivers/ar/ArArchiveInputStream.java| 10 +-
> .../commons/compress/archivers/cpio/CpioArchiveEntry.java | 2 +-
> .../compress/archivers/cpio/CpioArchiveInputStream.java| 2 +-
> .../compress/archivers/cpio/CpioArchiveOutputStream.java | 10 +-
> .../commons/compress/archivers/dump/TapeInputStream.java | 4 ++--
> .../commons/compress/archivers/examples/Archiver.java | 2 +-
> .../commons/compress/archivers/examples/Expander.java | 8
> .../org/apache/commons/compress/archivers/sevenz/CLI.java | 2 +-
> .../commons/compress/archivers/sevenz/CoderBase.java | 2 +-
> .../commons/compress/archivers/sevenz/SevenZFile.java | 2 +-
> .../compress/archivers/tar/TarArchiveOutputStream.java | 6 +++---
> .../commons/compress/archivers/zip/AsiExtraField.java | 2 +-
> .../commons/compress/archivers/zip/ExtraFieldUtils.java| 4 ++--
> .../archivers/zip/UnsupportedZipFeatureException.java | 6 +++---
> .../archivers/zip/Zip64ExtendedInformationExtraField.java | 2 +-
> .../compress/archivers/zip/Zip64RequiredException.java | 4 ++--
> .../commons/compress/archivers/zip/ZipArchiveEntry.java| 2 +-
> .../compress/archivers/zip/ZipArchiveOutputStream.java | 8
> .../org/apache/commons/compress/archivers/zip/ZipFile.java | 6 +++---
> .../compressors/bzip2/BZip2CompressorInputStream.java | 14
> +++---
> .../compressors/bzip2/BZip2CompressorOutputStream.java | 4 ++--
> .../compressors/lz4/BlockLZ4CompressorOutputStream.java| 2 +-
> .../compressors/lz4/FramedLZ4CompressorInputStream.java| 2 +-
> .../lz77support/AbstractLZ77CompressorInputStream.java | 2 +-
> .../compress/compressors/lz77support/LZ77Compressor.java | 2 +-
> .../commons/compress/compressors/lzw/LZWInputStream.java | 2 +-
> .../snappy/FramedSnappyCompressorInputStream.java | 8
> .../java/org/apache/commons/compress/utils/ByteUtils.java | 6 +++---
> .../compress/utils/FixedLengthBlockOutputStream.java | 2 +-
> .../commons/compress/archivers/examples/ExpanderTest.java | 4 ++--
> .../commons/compress/archivers/zip/AsiExtraFieldTest.java | 2 +-
> .../compress/archivers/zip/ExtraFieldUtilsTest.java| 2 +-
> .../lz4/FramedLZ4CompressorInputStreamTest.java| 2 +-
> .../snappy/FramedSnappyCompressorInputStreamTest.java | 2 +-
> 34 files changed, 70 insertions(+), 70 deletions(-)
>
> diff --git
> a/src/main/java/org/apache/commons/compress/archivers/ar/ArArchiveInputStream.java
> b/src/main/java/org/apache/commons/compress/archivers/ar/ArArchiveInputStream.java
> index 38d13d9..5d74e87 100644
> ---
> a/src/main/java/org/apache/commons/compress/archivers/ar/ArArchiveInputStream.java
> +++
> b/src/main/java/org/apache/commons/compress/archivers/ar/ArArchiveInputStream.java
> @@ -104,11 +104,11 @@ public class ArArchiveInputStream extends
> ArchiveInputStream {
> final int read = IOUtils.readFully(input, realized);
> trackReadBytes(read);
> if (read != expected.length) {
> -throw new IOException("failed to read header. Occured at
> byte: " + getBytesRead());
> +throw new IOException("Failed to read header. Occured at
> byte: " + getBytesRead());
> }
> for (int i = 0; i < expected.length; i++) {
> if (expected[i] != realized[i]) {
> -throw new IOException("invalid header " +
> ArchiveUtils.toAsciiString(realized));
> +throw new IOException("Invalid header " +
> ArchiveUtils.toAsciiString(realized));
> }
> }
> }
> @@ -128,7 +128,7 @@ public class ArArchiveInputStream extends
> ArchiveInputStream {
> return null;
> }
> if (read < metaData.length) {
> -throw new IOException("truncated ar archive");
> +throw new IOException("Truncated ar archive");
> }
> }
>
> @@ -138,11 +138,11 @@ public class ArArchiveInputStream extends
> ArchiveInputStream {
> final int read = IOUtils.readFully(input, realized);
> trackReadBytes(read);
> if (read != expected.length) {
> -throw new
Re: [statistics] Pull request for GLSMultipleLinearRegression
Hi Elena, Thanks for this intriguing idea. As far as I ever knew IRLS requires a matrix. Can you provide me with a citation where I can read about this vector-based approach? Thanks, Eric On Thu, May 23, 2019, 06:44 Елена Картышева wrote: > Hello. > > I would like to propose a pull request implementing an option to use > variance vector instead of covariance matrix. It allows users to avoid > unnecessary memory usage and excessive computation in case of uncorrelated > but heteroscedastic errors thus making it possible to work with huge input > matrices. Using variance vector in such cases allows to reduce time > complexity from O(N^2) to just O(N) (where N is a number of observations) > and dramatically reduce memory usage. For example, in my practice arose a > need to train generalized linear model. Usage of Iteratively reweighted > least squares algorithm requires weighted regression with more than a > million observations. Current implementation would require approximately 12 > terabytes of memory while patched version needs only 8 megabytes. Since > IRLS is iterative algorithm a million-times complexity reduction is also > pretty handy. > > > -- > Sincerely yours, Elena Kartysheva. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [geometry] release
Gilles,
In regard to the roadmap, there has been steady progress but not much is
visible yet from the GitHub or JIRA point of view, unfortunately. I'm currently
working on the final items from the initial roadmap email I sent out, namely
the ones related to the BSP tree and Region API cleanup (GEOMETRY-32,
GEOMETRY-33, GEOMETRY-34, and GEOMETRY-24). It made the most sense to handle
all of these issues with a general refactoring of the core classes, which is
what I'm doing on my working branch
(https://github.com/darkma773r/commons-geometry/tree/geometry-32-working). I
currently have all of the BSP tree code done (the biggest chunk of this) along
with the 1D and most of the 2D Euclidean classes. I have yet to do Euclidean 3D
and spherical 1D and 2D. Here is a comparison of the old API vs the new API for
calculating the area of the difference of two 2D regions defined by vertex
paths:
--- Old API ---
DoublePrecisionContext precision = ...;
Vector2D[] aVertices = { ... };
Vector2D[] bVertices = { ... };
PolygonsSet a = new PolygonsSet(precision, aVertices);
PolygonsSet b = new PolygonsSet(precision, bVertices);
PolygonsSet c = (PolygonsSet) new
RegionFactory().difference(a.copySelf(), b.copySelf());
double area = c.getSize();
--- New API ---
DoublePrecisionContext precision = ...;
List aVertices = ...;
List bVertices = ...;
RegionBSPTree2D a = LineSegmentPath.fromVertices(aVertices, precision).toTree();
RegionBSPTree2D b = LineSegmentPath.fromVertices(bVertices, precision).toTree();
a.difference(b);
double area = a.getSize();
I'll keep you updated as I get closer to finishing. It is a large change so we
will undoubtedly need to discuss quite a few things. Also, if anyone has free
time and wants to help with the spherical classes on my working branch, that
would definitely help speed things along.
Regards,
Matt
From: Rob Tompkins
Sent: Thursday, May 23, 2019 12:31 PM
To: dev@commons.apache.org
Subject: Re: [geometry] release
On 5/23/2019 9:49 AM, Gilles Sadowski wrote:
> Hi.
>
> Le jeu. 23 mai 2019 à 15:37, Rob Tompkins a écrit :
>>
>>
>>> On May 23, 2019, at 7:25 AM, Gilles Sadowski wrote:
>>>
>>> Hi.
>>>
Le mer. 22 mai 2019 à 14:07, Matt Juntunen a
écrit :
Hi Sven,
Until we can roll out an actual release of numbers and geometry,
>>> Any update of the roadmap? :-)
>> Do we have a reason to not release?
> Code is in the middle of being refactored, and contains many
> to-be-deleted classes.
Gotcha...was going to offer to send it up if there was an appetite.
>
> Gilles
>
>> -Rob
>>
[...]
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [geometry] release
On 5/23/2019 9:49 AM, Gilles Sadowski wrote: Hi. Le jeu. 23 mai 2019 à 15:37, Rob Tompkins a écrit : On May 23, 2019, at 7:25 AM, Gilles Sadowski wrote: Hi. Le mer. 22 mai 2019 à 14:07, Matt Juntunen a écrit : Hi Sven, Until we can roll out an actual release of numbers and geometry, Any update of the roadmap? :-) Do we have a reason to not release? Code is in the middle of being refactored, and contains many to-be-deleted classes. Gotcha...was going to offer to send it up if there was an appetite. Gilles -Rob [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
RE: [statistics] Pull request for GLSMultipleLinearRegression
Hello, There is currently a transition from the commons-math-stat libraries to the new commons-statistics library. I am working on regression related design for my Google Summer of Code project. I am a new contributor and would love to work with more people who have used these tools extensively for more insights. The transition is mostly in the design stages. We are still figuring out essential problems like which linear math library to use (not from commons-math since its outdated) and designing a better/more flexible UI. I have not looked into GLS as in-depth yet (as much as OLS or the new LogisticRegression component), perhaps you can help contribute to the GLS component to ensure your needs are met. Our goal is also to maximize efficiencies in all areas, utilizing Java 8 features such as the Streams API where it would increase performance. Issue for regression component, please post insights here as well: https://issues.apache.org/jira/browse/STATISTICS-8 GitHub Repo: https://github.com/apache/commons-statistics Thank you for your post, Cheers, -Ben Nguyen From: Елена Картышева Sent: Thursday, May 23, 2019 8:44 AM To: dev Subject: [statistics] Pull request for GLSMultipleLinearRegression Hello. I would like to propose a pull request implementing an option to use variance vector instead of covariance matrix. It allows users to avoid unnecessary memory usage and excessive computation in case of uncorrelated but heteroscedastic errors thus making it possible to work with huge input matrices. Using variance vector in such cases allows to reduce time complexity from O(N^2) to just O(N) (where N is a number of observations) and dramatically reduce memory usage. For example, in my practice arose a need to train generalized linear model. Usage of Iteratively reweighted least squares algorithm requires weighted regression with more than a million observations. Current implementation would require approximately 12 terabytes of memory while patched version needs only 8 megabytes. Since IRLS is iterative algorithm a million-times complexity reduction is also pretty handy. -- Sincerely yours, Elena Kartysheva. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [GSoC] Thursday mentee meeting
Hello. Le mer. 22 mai 2019 à 20:51, Eric Barnhill a écrit : > > Let's have another mentee meeting Thursday morning, same time as the > previous two. I won't be in front of the keyboard at 5 PM UTC. Two potential contributors (Aleksander Ściborek and Ellen Kartysheva) posted (here, on the "dev" ML) proposals that are connected to the GSoC work discussed in these meetings. Please engage with them in order to come up with an consensus on the way(s) forward. Thanks, Gilles > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [geometry] release
Hi. Le jeu. 23 mai 2019 à 15:37, Rob Tompkins a écrit : > > > > > On May 23, 2019, at 7:25 AM, Gilles Sadowski wrote: > > > > Hi. > > > >> Le mer. 22 mai 2019 à 14:07, Matt Juntunen a > >> écrit : > >> > >> Hi Sven, > >> > >> Until we can roll out an actual release of numbers and geometry, > > > > Any update of the roadmap? :-) > > Do we have a reason to not release? Code is in the middle of being refactored, and contains many to-be-deleted classes. Gilles > > -Rob > > > > >> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[statistics] Pull request for GLSMultipleLinearRegression
Hello. I would like to propose a pull request implementing an option to use variance vector instead of covariance matrix. It allows users to avoid unnecessary memory usage and excessive computation in case of uncorrelated but heteroscedastic errors thus making it possible to work with huge input matrices. Using variance vector in such cases allows to reduce time complexity from O(N^2) to just O(N) (where N is a number of observations) and dramatically reduce memory usage. For example, in my practice arose a need to train generalized linear model. Usage of Iteratively reweighted least squares algorithm requires weighted regression with more than a million observations. Current implementation would require approximately 12 terabytes of memory while patched version needs only 8 megabytes. Since IRLS is iterative algorithm a million-times complexity reduction is also pretty handy. -- Sincerely yours, Elena Kartysheva. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [geometry] release
> On May 23, 2019, at 7:25 AM, Gilles Sadowski wrote: > > Hi. > >> Le mer. 22 mai 2019 à 14:07, Matt Juntunen a >> écrit : >> >> Hi Sven, >> >> Until we can roll out an actual release of numbers and geometry, > > Any update of the roadmap? :-) Do we have a reason to not release? -Rob > >> I think your best bet is to fork commons-geometry and all of its SNAPSHOT >> dependencies, change the groupIds and/or artifactIds in the poms to >> something custom (to avoid conflicts later on), and then release those >> directly to your artifactory server. You'll probably need to make other >> modifications to the poms in order to get this to work. This process will >> most likely be very painful. If you only use small portions of the geometry >> code, another option would be to temporarily copy some of the classes from >> commons-geometry directly into your application code. This would avoid a lot >> of messing around with release processes and would make the commons-geometry >> behavior that your application relies on directly visible. I would use this >> approach, if at all possible, until a real release can be made. >> >> Godspeed. >> >> -Matt >> >> From: Sven Rathgeber >> Sent: Wednesday, May 22, 2019 3:23 AM >> To: dev@commons.apache.org >> Subject: [geometry] release >> >> Hi, >> >> I use in one of our applications the current state >> of https://github.com/apache/commons-geometry >> (c45647f45df7d81819e47ad6bd0d342069fb305d ). >> (... which has a couple of child projects and relies on the current state of >> common-numbers -> in sum about 15 jars.) >> >> Now I have to release my application in order to bring it to our testsystem, >> but maven >> is not happy about the SNAPSHOT release of commons-geometry. >> >> I tried with a profile to release it to our artifactory server but that >> looks like a pretty hard >> way. Currently maven wants me to commit to 'https://gitbox.apache.org' :), >> which is not exactly what I want. >> >> Do you see a way how I can release my application ? > > This could be an approach: >https://maven.apache.org/plugins/maven-shade-plugin/ > > Regards, > Gilles > >> >> Cheers. >> Sven >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[statistics] Pull request for GLSMultipleLinearRegression
I would like to propose a pull request implementing an option to use variance vector instead of covariance matrix. It allows users to avoid unnecessary memory usage and excessive computation in case of uncorrelated but heteroscedastic errors thus making it possible to work with huge input matrices. Using variance vector in such cases allows to reduce time complexity from O(N^2) to just O(N) (where N is a number of observations) and dramatically reduce memory usage. For example, in my practice arose a need to train generalized linear model. Usage of Iteratively reweighted least squares algorithm requires weighted regression with more than a million observations. Current implementation would require approximately 12 terabytes of memory while patched version needs only 8 megabytes. Since IRLS is iterative algorithm a million-times complexity reduction is also pretty handy. https://github.com/apache/commons-math/pull/106
Re: [rng] binary compatibility with final modifier
On 23/05/2019 13:46, Gilles Sadowski wrote:
Hello.
Le jeu. 23 mai 2019 à 14:10, Alex Herbert a écrit :
On 23/05/2019 12:53, sebb wrote:
Are the classes supposed to be final?
Or just the existing constructor(s)?
The two package-private classes are definitely helper classes and should
be final.
The class with the clirr issue (it is actually an info) only has static
methods. So currently it is a utility class.
Changing it to have a new role with instance methods would be a design
update that could be served by introducing a new class. However this
class has taken the best name.
Any instance role for the class would require that it is typed for
generics. But a quick try seems to pass clirr.
Gilles, any opinion on a future for ListSampler as:
public class ListSampler {
// Other static stuff (already in the class)...
T sample();
}
Unless I'm missing something, this use-case is covered by
"CollectionSampler".[1]
"ListSampler" is for other use-cases (sublist, in-place shuffle).[2]
Yes. I missed that. So there is never a need for an instance of
ListSampler and it can be made final without breaking any compatibility.
Regards,
Gilles
[1]
http://commons.apache.org/proper/commons-rng/commons-rng-sampling/javadocs/api-1.2/org/apache/commons/rng/sampling/CollectionSampler.html
[2]
http://commons.apache.org/proper/commons-rng/commons-rng-sampling/javadocs/api-1.2/org/apache/commons/rng/sampling/ListSampler.html
Alex
On Thu, 23 May 2019 at 12:51, Gilles Sadowski wrote:
Hello.
Le jeu. 23 mai 2019 à 13:43, Alex Herbert a écrit :
[rng] has three classes with a private constructor that are not
currently marked as final. 1 is public and 2 are package private.
If I mark them as final then clirr:check ignores the package private
ones and produces this warning for the public one:
If it's a "Warning" and not an "Error", I don't think that it could
count as a release blocker. [Confirmation from PMC members
welcome...]
"Added final modifier to class, but class was effectively final anyway"
Given the class could not have been extended (due to a private
constructor) it seems OK to allow the final modifier.
I think so.
So can the final modifier be added? Is there a precedent here with
regard to releases?
Cf. above.
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng] binary compatibility with final modifier
Hello.
Le jeu. 23 mai 2019 à 14:10, Alex Herbert a écrit :
>
>
> On 23/05/2019 12:53, sebb wrote:
> > Are the classes supposed to be final?
> > Or just the existing constructor(s)?
>
> The two package-private classes are definitely helper classes and should
> be final.
>
> The class with the clirr issue (it is actually an info) only has static
> methods. So currently it is a utility class.
>
> Changing it to have a new role with instance methods would be a design
> update that could be served by introducing a new class. However this
> class has taken the best name.
>
> Any instance role for the class would require that it is typed for
> generics. But a quick try seems to pass clirr.
>
> Gilles, any opinion on a future for ListSampler as:
>
> public class ListSampler {
>
> // Other static stuff (already in the class)...
>
> T sample();
>
> }
Unless I'm missing something, this use-case is covered by
"CollectionSampler".[1]
"ListSampler" is for other use-cases (sublist, in-place shuffle).[2]
Regards,
Gilles
[1]
http://commons.apache.org/proper/commons-rng/commons-rng-sampling/javadocs/api-1.2/org/apache/commons/rng/sampling/CollectionSampler.html
[2]
http://commons.apache.org/proper/commons-rng/commons-rng-sampling/javadocs/api-1.2/org/apache/commons/rng/sampling/ListSampler.html
>
> Alex
>
>
> >
> > On Thu, 23 May 2019 at 12:51, Gilles Sadowski wrote:
> >> Hello.
> >>
> >> Le jeu. 23 mai 2019 à 13:43, Alex Herbert a
> >> écrit :
> >>> [rng] has three classes with a private constructor that are not
> >>> currently marked as final. 1 is public and 2 are package private.
> >>>
> >>> If I mark them as final then clirr:check ignores the package private
> >>> ones and produces this warning for the public one:
> >> If it's a "Warning" and not an "Error", I don't think that it could
> >> count as a release blocker. [Confirmation from PMC members
> >> welcome...]
> >>
> >>> "Added final modifier to class, but class was effectively final anyway"
> >>>
> >>>
> >>> Given the class could not have been extended (due to a private
> >>> constructor) it seems OK to allow the final modifier.
> >> I think so.
> >>
> >>> So can the final modifier be added? Is there a precedent here with
> >>> regard to releases?
> >> Cf. above.
> >>
> >> Gilles
> >>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng] binary compatibility with final modifier
On 23/05/2019 12:53, sebb wrote:
Are the classes supposed to be final?
Or just the existing constructor(s)?
The two package-private classes are definitely helper classes and should
be final.
The class with the clirr issue (it is actually an info) only has static
methods. So currently it is a utility class.
Changing it to have a new role with instance methods would be a design
update that could be served by introducing a new class. However this
class has taken the best name.
Any instance role for the class would require that it is typed for
generics. But a quick try seems to pass clirr.
Gilles, any opinion on a future for ListSampler as:
public class ListSampler {
// Other static stuff (already in the class)...
T sample();
}
Alex
On Thu, 23 May 2019 at 12:51, Gilles Sadowski wrote:
Hello.
Le jeu. 23 mai 2019 à 13:43, Alex Herbert a écrit :
[rng] has three classes with a private constructor that are not
currently marked as final. 1 is public and 2 are package private.
If I mark them as final then clirr:check ignores the package private
ones and produces this warning for the public one:
If it's a "Warning" and not an "Error", I don't think that it could
count as a release blocker. [Confirmation from PMC members
welcome...]
"Added final modifier to class, but class was effectively final anyway"
Given the class could not have been extended (due to a private
constructor) it seems OK to allow the final modifier.
I think so.
So can the final modifier be added? Is there a precedent here with
regard to releases?
Cf. above.
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Aw: Re: [geometry] release
Hi, > This could be an approach: > https://maven.apache.org/plugins/maven-shade-plugin/[https://maven.apache.org/plugins/maven-shade-plugin/] I started to think in a similar direction and finally got it with the assembly-plugin (jar-with-dependencies). And "mvn deploy:deploy-file ..." did the rest :) Thanks for your ideas. Sven - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng] binary compatibility with final modifier
Are the classes supposed to be final? Or just the existing constructor(s)? On Thu, 23 May 2019 at 12:51, Gilles Sadowski wrote: > > Hello. > > Le jeu. 23 mai 2019 à 13:43, Alex Herbert a écrit : > > > > [rng] has three classes with a private constructor that are not > > currently marked as final. 1 is public and 2 are package private. > > > > If I mark them as final then clirr:check ignores the package private > > ones and produces this warning for the public one: > > If it's a "Warning" and not an "Error", I don't think that it could > count as a release blocker. [Confirmation from PMC members > welcome...] > > > > > "Added final modifier to class, but class was effectively final anyway" > > > > > > Given the class could not have been extended (due to a private > > constructor) it seems OK to allow the final modifier. > > I think so. > > > > > So can the final modifier be added? Is there a precedent here with > > regard to releases? > > Cf. above. > > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng] binary compatibility with final modifier
Hello. Le jeu. 23 mai 2019 à 13:43, Alex Herbert a écrit : > > [rng] has three classes with a private constructor that are not > currently marked as final. 1 is public and 2 are package private. > > If I mark them as final then clirr:check ignores the package private > ones and produces this warning for the public one: If it's a "Warning" and not an "Error", I don't think that it could count as a release blocker. [Confirmation from PMC members welcome...] > > "Added final modifier to class, but class was effectively final anyway" > > > Given the class could not have been extended (due to a private > constructor) it seems OK to allow the final modifier. I think so. > > So can the final modifier be added? Is there a precedent here with > regard to releases? Cf. above. Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [statistics] PMD
Hi. Le jeu. 23 mai 2019 à 13:33, Alex Herbert a écrit : > > Having just fixed [rng] for PMD I had a look at why it was fine in > statistics as some of the issues are present there. > > PMD in statistics is old. It uses rules that are deprecated. > > I have updated to a similar ruleset to [rng] and fixed all the problems. > See this PR [1]. > > One rule violation is this class name: > > SaddlePointExpansion > > It is a class copied from [math]. I've set the name to use an exclusion. > However since the code has not been released we could just rename to > > SaddlePointExpansionHelper > SaddlePointExpansionUtils Sure. Also, the class is package-private. Gilles > > Alex > > > [1] https://github.com/apache/commons-statistics/pull/13 > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[rng] binary compatibility with final modifier
[rng] has three classes with a private constructor that are not currently marked as final. 1 is public and 2 are package private. If I mark them as final then clirr:check ignores the package private ones and produces this warning for the public one: "Added final modifier to class, but class was effectively final anyway" Given the class could not have been extended (due to a private constructor) it seems OK to allow the final modifier. So can the final modifier be added? Is there a precedent here with regard to releases? Alex - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[statistics] PMD
Having just fixed [rng] for PMD I had a look at why it was fine in statistics as some of the issues are present there. PMD in statistics is old. It uses rules that are deprecated. I have updated to a similar ruleset to [rng] and fixed all the problems. See this PR [1]. One rule violation is this class name: SaddlePointExpansion It is a class copied from [math]. I've set the name to use an exclusion. However since the code has not been released we could just rename to SaddlePointExpansionHelper SaddlePointExpansionUtils Alex [1] https://github.com/apache/commons-statistics/pull/13 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[beanutils2] CVE-2014-0114 Pull Request
Hey All!, First time contributor here. My company has a corporate goal to only use open source libraries with NO open Security CVE's marked as critical. BeanUtils has CVE-2014-0114 marked as critical so I opened a ticket: https://issues.apache.org/jira/browse/BEANUTILS-520 I submitted my first Apache Commons PR which addresses the issue which I was hoping I could get code reviewed and hopefully merged. I followed all guidelines and included a specific unit test to prove the issue and the fix. Pull Request: https://github.com/apache/commons-beanutils/pull/7 I really feel like this is an important fix to have security on by default and still allow the ability to opt-out and make it backwards compatible. I hope the Apache community feels the same way! Thanks, Melloware
Re: [geometry] release
Hi. Le mer. 22 mai 2019 à 14:07, Matt Juntunen a écrit : > > Hi Sven, > > Until we can roll out an actual release of numbers and geometry, Any update of the roadmap? :-) > I think your best bet is to fork commons-geometry and all of its SNAPSHOT > dependencies, change the groupIds and/or artifactIds in the poms to something > custom (to avoid conflicts later on), and then release those directly to your > artifactory server. You'll probably need to make other modifications to the > poms in order to get this to work. This process will most likely be very > painful. If you only use small portions of the geometry code, another option > would be to temporarily copy some of the classes from commons-geometry > directly into your application code. This would avoid a lot of messing around > with release processes and would make the commons-geometry behavior that your > application relies on directly visible. I would use this approach, if at all > possible, until a real release can be made. > > Godspeed. > > -Matt > > From: Sven Rathgeber > Sent: Wednesday, May 22, 2019 3:23 AM > To: dev@commons.apache.org > Subject: [geometry] release > > Hi, > > I use in one of our applications the current state > of https://github.com/apache/commons-geometry > (c45647f45df7d81819e47ad6bd0d342069fb305d ). > (... which has a couple of child projects and relies on the current state of > common-numbers -> in sum about 15 jars.) > > Now I have to release my application in order to bring it to our testsystem, > but maven > is not happy about the SNAPSHOT release of commons-geometry. > > I tried with a profile to release it to our artifactory server but that > looks like a pretty hard > way. Currently maven wants me to commit to 'https://gitbox.apache.org' :), > which is not exactly what I want. > > Do you see a way how I can release my application ? This could be an approach: https://maven.apache.org/plugins/maven-shade-plugin/ Regards, Gilles > > Cheers. > Sven > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng] default maven goal
Hi. Le jeu. 23 mai 2019 à 11:49, Alex Herbert a écrit : > > The [rng] pom does not have a default goal. Here are the default goals > in the projects I currently have checked out: > > commons-codec/pom.xml:clean verify apache-rat:check > clirr:check javadoc:javadoc > > commons-collections/pom.xml:clean verify > apache-rat:check clirr:check javadoc:javadoc > > commons-lang/pom.xml: clean verify apache-rat:check > clirr:check checkstyle:check spotbugs:check javadoc:javadoc > > commons-statistics/pom.xml:clean verify > apache-rat:check clirr:check checkstyle:check pmd:check spotbugs:check > javadoc:javadoc > > commons-text/pom.xml:clean verify apache-rat:check > clirr:check checkstyle:check spotbugs:check javadoc:javadoc > > These seem to match at least this: > > clean verify apache-rat:check clirr:check javadoc:javadoc > > Some also run: > > checkstyle:check spotbugs:check > > The only projects I have without a default goal are: > > commons-geometry > commons-math > commons-numbers > commons-rng > > I think it would be useful to run all the checks that the project is > required to pass in travis as the default goal. This can be used by a > developer as a final check before commit. > > Opinions? > > Is the defaultGoal a domain of the developer (as it is used above) or > should it be for an end user, e.g. where I have seen it used for 'mvn > install'. No idea; I always specify something to do. Before a commit, I generally run $ mvn site site:stage and have a look at the generated reports (mainly CheckStyle). Regards, Gilles > > Alex > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[rng] default maven goal
The [rng] pom does not have a default goal. Here are the default goals in the projects I currently have checked out: commons-codec/pom.xml: clean verify apache-rat:check clirr:check javadoc:javadoc commons-collections/pom.xml: clean verify apache-rat:check clirr:check javadoc:javadoc commons-lang/pom.xml: clean verify apache-rat:check clirr:check checkstyle:check spotbugs:check javadoc:javadoc commons-statistics/pom.xml: clean verify apache-rat:check clirr:check checkstyle:check pmd:check spotbugs:check javadoc:javadoc commons-text/pom.xml: clean verify apache-rat:check clirr:check checkstyle:check spotbugs:check javadoc:javadoc These seem to match at least this: clean verify apache-rat:check clirr:check javadoc:javadoc Some also run: checkstyle:check spotbugs:check The only projects I have without a default goal are: commons-geometry commons-math commons-numbers commons-rng I think it would be useful to run all the checks that the project is required to pass in travis as the default goal. This can be used by a developer as a final check before commit. Opinions? Is the defaultGoal a domain of the developer (as it is used above) or should it be for an end user, e.g. where I have seen it used for 'mvn install'. Alex
