Re: [Math][Numbers] Regression (due to a change in "BigFraction" class?)
On Sun, 26 Jun 2022 at 21:27, Gilles Sadowski wrote: > > > > > > Strangely I am not receiving emails from GH actions (or jenkins) to > inform > > me that the build fails after a commit. There may be a setting for the GH > > actions that is missing to enable e-mail to the committer after a build > > failure. > > I also did not see the failure until trying a local build of [Math]. > Isn't it related to the fact that such test failures entail that the build > is tagged as "unstable" rather than "failed"? > For GH actions I think we can add this to the .asf.yaml [1,2]: notifications: jobs: dev@commons.apache.org I am not sure if we should try this with dev@ or use another e-mail list. For Jenkins the post build editable e-mail notification section had 'Disable Extended Email Publisher' selected. I have unchecked this box (as per the RNG config); we will wait to see if it now sends emails on a build error. Note that statistics and math also have this setting unchecked. Geometry has the setting checked (perhaps it should be updated). However this may not be the setting to fix this since it was not checked in the math config and math had a recent build failure after it was triggered by a change in numbers. The email is targeted at the developer who created the commit. So the math build failure should have been sent to me since I have the most recent commit on master. But I received no email. The math build is logged as a failed build but the log output shows that maven still completes remaining modules and uploads the SNAPSHOT artifacts. Also note that the Jenkins build for numbers continues to deploy all modules after a module has failed tests (see [3] for the failed build after the offending commit). So there is something in the Jenkins setup that is ignoring test failures and continuing with the build to deploy artifacts from all the modules. Alex [1] https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-GitHubActionsbuildstatusemails [2] https://cwiki.apache.org/confluence/display/INFRA/Git+-+.asf.yaml+features#Git.asf.yamlfeatures-Notificationsettingsforrepositories [3] https://ci-builds.apache.org/job/Commons/job/commons-numbers/150/
Re: [numbers][gsoc] GSoC 2022 - NUMBERS-186 Proposal
On Sun, 26 Jun 2022 at 20:52, Sumanth Rajkumar wrote: > Hi, > I have raised PR #113 after rebasing to the master branch with Alex's > checkstyle changes > > As per feedback, I have made the following changes > a) Added javadoc comments > b) Ensured test coverage > c) Renamed accessors on the interface > Thanks for the changes. Note that a new PR is not required. You can simply force push changes to the previous PR. It is covering the same subject. I've not yet fully read the PR. However the level of abstraction on some of the simple functions seems excessive. Many of the scalar operations using applyScalarFunction are one liners that have been abstracted to multiple layers of function references. Simple operations such as add, subtract, conjugate, negate, arg (defined as Math.atan2) may be better left alone. They can be duplicated into the complex functions class if the API is for public consumption but performance may be impacted by the abstraction. The code is definitely made less readable. Also note that you have some double empty lines which should be a single empty line and then some functions ending with } and no empty line after. These can be simply fixed using a regular expression to search for them. I note that some javadoc is missing for private methods. I have not set checkstyle to enforce this and the default scope is public. It should at least be protected, but my preference would be package. I will see if the rest of the project is OK for this and then update the rule. > > > > Gilles Sadowski wrote: > > In "DComplex", I propose that the accessors be named "real()" and > > "imag()" (or just > > "re()" and "im()"). ["DComplex" is not a very satisfying name either...] > > For the interface name, shall I change it to Complex64 from DComplex? > In c the 'complex' keyword is a suffix: double complex c1; float complex c2; long double complex c3; In c++ the type is generic (and read as a suffix): complex c1; complex c2; Either of these would be my preference over DComplex or Complex64. > > Are we sure that all this code needs to be part of the public API? > > If not, I'd suggest limiting accessibility to "package-private". > > Are you referring to the static methods in ComplexFunctions and > ComplexBiFunctions classes? > I think they would need to be public for developers to be able to compose > multiple operations... > The static helper functions have been extracted to support all the ISO c99 operations on the list structure of complex numbers. A list will ideally implement a generic foreach operation. So to apply a single function only requires making the static functions public. The alternative is to make the list expose all the ISO c99 operations in its public API. To create a composite function that eventually writes back to the list can be implemented by writing intermediate values to a result which is then passed to the next operation. This can be satisfied by using the Complex class. This already exposes all the ISO c99 functions. So perhaps it is not required to make all the helper functions public for the purpose of composing multiple operations. But it would be helpful for all the single operations. > > Thanks, > Sumanth > > PS: Noticed master branch unit test failures in numbers-fraction module > This has been fixed. Sorry for the mistake. Alex
Re: [Math][Numbers] Regression (due to a change in "BigFraction" class?)
Hello. Le dim. 26 juin 2022 à 22:17, Alex Herbert a écrit : > > On Sun, 26 Jun 2022 at 21:12, Gilles Sadowski wrote: > > > Hello. > > > > Jenkins (as well as local build of [Math]) is failing: > > https://ci-builds.apache.org/job/Commons/job/commons-math/336/ > > > > Two regressions appeared in unit tests untouched for ages: > > org.apache.commons.math4.legacy.analysis.polynomials.PolynomialsUtilsTest > > > > org.apache.commons.math4.legacy.ode.nonstiff.AdamsNordsieckTransformerTest > > > > The impacted classes > > org.apache.commons.math4.legacy.analysis.polynomials.PolynomialsUtils > > org.apache.commons.math4.legacy.ode.nonstiff > > both depend on class "BigFraction" from [Numbers] that has been modified > > in commit 1497df18dfb77f454450d71733c31a47560c6845. > > There, parentheses have been removed in logical tests. > > Could this seemingly innocuous change be causing this issue? > > > > Yes. It is a rounding error I introduced when erasing the wrong set of > parentheses. I have corrected the error. Sorry for the mistake. Once in a (long) while. ;-) It's great to see that the test suites are working! > > Strangely I am not receiving emails from GH actions (or jenkins) to inform > me that the build fails after a commit. There may be a setting for the GH > actions that is missing to enable e-mail to the committer after a build > failure. I also did not see the failure until trying a local build of [Math]. Isn't it related to the fact that such test failures entail that the build is tagged as "unstable" rather than "failed"? Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math][Numbers] Regression (due to a change in "BigFraction" class?)
On Sun, 26 Jun 2022 at 21:12, Gilles Sadowski wrote: > Hello. > > Jenkins (as well as local build of [Math]) is failing: > https://ci-builds.apache.org/job/Commons/job/commons-math/336/ > > Two regressions appeared in unit tests untouched for ages: > org.apache.commons.math4.legacy.analysis.polynomials.PolynomialsUtilsTest > > org.apache.commons.math4.legacy.ode.nonstiff.AdamsNordsieckTransformerTest > > The impacted classes > org.apache.commons.math4.legacy.analysis.polynomials.PolynomialsUtils > org.apache.commons.math4.legacy.ode.nonstiff > both depend on class "BigFraction" from [Numbers] that has been modified > in commit 1497df18dfb77f454450d71733c31a47560c6845. > There, parentheses have been removed in logical tests. > Could this seemingly innocuous change be causing this issue? > Yes. It is a rounding error I introduced when erasing the wrong set of parentheses. I have corrected the error. Sorry for the mistake. Strangely I am not receiving emails from GH actions (or jenkins) to inform me that the build fails after a commit. There may be a setting for the GH actions that is missing to enable e-mail to the committer after a build failure. Alex
[Math][Numbers] Regression (due to a change in "BigFraction" class?)
Hello. Jenkins (as well as local build of [Math]) is failing: https://ci-builds.apache.org/job/Commons/job/commons-math/336/ Two regressions appeared in unit tests untouched for ages: org.apache.commons.math4.legacy.analysis.polynomials.PolynomialsUtilsTest org.apache.commons.math4.legacy.ode.nonstiff.AdamsNordsieckTransformerTest The impacted classes org.apache.commons.math4.legacy.analysis.polynomials.PolynomialsUtils org.apache.commons.math4.legacy.ode.nonstiff both depend on class "BigFraction" from [Numbers] that has been modified in commit 1497df18dfb77f454450d71733c31a47560c6845. There, parentheses have been removed in logical tests. Could this seemingly innocuous change be causing this issue? If so, there is a probably unwanted side-effect (either in [Numbers] or in [Math]). Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [numbers][gsoc] GSoC 2022 - NUMBERS-186 Proposal
Hi, I have raised PR #113 after rebasing to the master branch with Alex's checkstyle changes As per feedback, I have made the following changes a) Added javadoc comments b) Ensured test coverage c) Renamed accessors on the interface > Gilles Sadowski wrote: > In "DComplex", I propose that the accessors be named "real()" and > "imag()" (or just > "re()" and "im()"). ["DComplex" is not a very satisfying name either...] For the interface name, shall I change it to Complex64 from DComplex? > Are we sure that all this code needs to be part of the public API? > If not, I'd suggest limiting accessibility to "package-private". Are you referring to the static methods in ComplexFunctions and ComplexBiFunctions classes? I think they would need to be public for developers to be able to compose multiple operations... Thanks, Sumanth PS: Noticed master branch unit test failures in numbers-fraction module On Fri, 24 Jun 2022 at 19:43, Gilles Sadowski wrote: > Hello. > > Le ven. 24 juin 2022 à 16:59, Sumanth Rajkumar > a écrit : > > > > Hi Alex, Gilles, and Matt, > > > > I have raised a PR to the complex-gsoc-22 branch and it has been linked > to > > the NUMBERS-188 jira. > > One tenet of a project such as "Commons" is that everything must be > documented.[1] > For the Javadoc comments, please apply the same style as in other source > files. > > Formatting should also be taken care of (to help review, and future > maintenance).[2] > > Are we sure that all this code needs to be part of the public API? If > not, I'd suggest > limiting accessibility to "package-private". > > In "DComplex", I propose that the accessors be named "real()" and > "imag()" (or just > "re()" and "im()"). ["DComplex" is not a very satisfying name either...] > > Thanks, > Gilles > > [1] I'm a bit surprised that the build succeeds despite the missing > comments. > [2] E.g. one argument per line improves readability (IMHO). > > > > > [...] > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[CANCELLED] [VOTE] Release Apache Commons Configuration 2.8 based on RC2
Hello, Apologies for the late response. The second half of this week turned out to be extraordinarily busy and I haven't had any time for commons. Thank you for the detailed review, Gary. I am cancelling this vote and will be making those changes for RC3. It may be a few days more before I can get to it. Should I also change the version to "2.8.0" instead of "2.8" while I'm at it? Regards, Matt J On Fri, Jun 24, 2022 at 7:38 AM Gary Gregory wrote: > > Where is the documentation for the new property-based toggles? > > It should be at least be documented here: > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/userguide/howto_basicfeatures.html#Variable_Interpolation > > Shouldn't the migration page also mention have a new section for this > version on how to get the features back with the sys prop toggles on > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/userguide/upgradeto2_0.html > ? > > Gary > > On Tue, Jun 21, 2022 at 11:47 PM Matt Juntunen > wrote: > > > > We have fixed quite a few bugs and added some significant enhancements > > since Apache Commons Configuration 2.7 was released, so I would like > > to release Apache Commons Configuration 2.8. > > > > Apache Commons Configuration 2.8 RC2 is available for review here: > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2 > > (svn revision 55251) > > > > The Git tag commons-configuration-2.8-RC2 commit for this RC is > > f540433112b9a93c26c43277c3ec7a3d40565115 which you can browse here: > > > > https://gitbox.apache.org/repos/asf?p=commons-configuration.git;a=commit;h=f540433112b9a93c26c43277c3ec7a3d40565115 > > You may checkout this tag using: > > git clone https://gitbox.apache.org/repos/asf/commons-configuration.git > > --branch commons-configuration-2.8-RC2 commons-configuration-2.8-RC2 > > > > Maven artifacts are here: > > > > https://repository.apache.org/content/repositories/orgapachecommons-1590/org/apache/commons/commons-configuration2/2.8/ > > > > These are the artifacts and their hashes: > > > > #Release SHA-512s > > #Tue Jun 21 23:27:23 EDT 2022 > > commons-configuration2-2.8-bin.tar.gz=b3f4628ecf3fc52feaf68ca13d0518d0ff5de8bea690a3fa625b91f2ffee9ef0fe1c575743d71bd035ba5d1c0be47a668ec1b28fb1953998f6723cecb8b59a38 > > commons-configuration2-2.8-bin.zip=86dc5ee9d7581b6c0b2f2807fb4f2179eec0dc4dfdb1246ffd9054a64e4511b534a4be015946403f0d0519362029cef2d4d89c684d38eaa4bd1e6af8d8b8b3a9 > > commons-configuration2-2.8-javadoc.jar=91dc9721ebea0345175d02b2d8e4bf08a255034549527edbecd382771540d85ca2423f22a4bc260d42ac33e9c3bd6b36a5fb7713b4919b58a0c06d9661285b0d > > commons-configuration2-2.8-sources.jar=85e4f25fc9a0682bd3376de2741b48bfb6b77e98795a107c818c0bb51578cde8dd60a5e38177a6ce2a73bc4a1b9f925720321f7320fef0173c6f26c0a303bb55 > > commons-configuration2-2.8-src.tar.gz=924be9a8c0fd5f5a03d9ccd14a0bf79b83323f424fc4580084e807a5f7f242d40146cbdcd34d8d3a0098aeebe3040f77089230176ef737d649666152f2bda6ea > > commons-configuration2-2.8-src.zip=e6695471c21e0c885b3ad5b0e0ff65a69a65cbc82a7c96d0406342f81b2efb8185b7008dfd7d49603ca96ea44761bb681aacfd997bbbae742ad922d58173305a > > commons-configuration2-2.8-test-sources.jar=d203e063ec6b7ea16688c9015f10cf41bb3c592e990e214f6f808a20f19efe5973b3d30f4b939d571a8f4c1c2094d52c77733b59d0e7cdf412d27133fac7c7d9 > > commons-configuration2-2.8-tests.jar=6878c163de212e0617650ecbcd68887db1fc0c29f596ca773598b4ef7314e7062f4671208b8360d6ec2ca8f8408c75763912bcc545903e440fd77a6086af5c49 > > > > > > > > I have tested this with ***'mvn clean install site'*** using: > > *** > > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) > > Maven home: /home/matt/tools/maven/apache-maven-3.8.4 > > Java version: 1.8.0_322, vendor: Temurin, runtime: > > /home/matt/lang/java/jdk8u322-b06/jre > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "linux", version: "5.17.12-300.fc36.x86_64", arch: "amd64", > > family: "unix" > > > > Apache Maven 3.8.4 (9b656c72d54e5bacbed989b64718c159fe39b537) > > Maven home: /home/matt/tools/maven/apache-maven-3.8.4 > > Java version: 11.0.14.1, vendor: Eclipse Adoptium, runtime: > > /home/matt/lang/java/jdk-11.0.14.1+1 > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "linux", version: "5.17.12-300.fc36.x86_64", arch: "amd64", > > family: "unix" > > *** > > > > Details of changes since 2.7 are in the release notes: > > > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/RELEASE-NOTES.txt > > > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/changes-report.html > > > > Site: > > > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/site/index.html > > (note some *relative* links are broken and the 2.8 directories are > > not yet created - these will be OK once the site is deployed.) > > > > JApiCmp Report (compared to 2.7): > > > > https://dist.apache.org/repos/dist/dev/commons/configuration/2.8-RC2/s
Re: [CRYPTO] Updated docker build
I've merged the docker build into the default branch. It may not be perfect, but it does work well enough! On Wed, 22 Jun 2022 at 17:14, sebb wrote: > > On Wed, 22 Jun 2022 at 15:59, Alex Remily wrote: > > > > I went back and reviewed docker setup at your link: > > > > https://github.com/apache/commons-crypto/tree/79374289bdd227b5b668039c9336cd10d9e3bf7c/src/docker > > > > Nice work. > > Props to you for getting the initial build working. > I just tweaked it. > > > I agree that it's more flexible and provides the same > > capability. The instructions were straightforward and the end result was a > > full build. One can also experiment via the command line, which is nice. > > A couple of comments. The comments on lines 16-21 should be removed, as > > you've provided updated instructions in the readme. > > Done. > > > I recall that during > > the last release process I recommended using 18.04 as the base image and > > was overruled because of backwards compatibility concerns with the native > > binaries. I don't know that I share those concerns, but that was the > > rationale for using the older base. > > I see. > Hopefully not an issue anymore? > > > Otherwise, it seems ready to commit and close out 120 and 132. > > > > Alex > > > > On Tue, Jun 21, 2022 at 5:52 PM sebb wrote: > > > > > On Tue, 21 Jun 2022 at 22:32, Alex Remily wrote: > > > > > > > > > > previous > > > > submission.> > > > > > > > > Don't know that it's an "improvement", but a different approach. I > > > > think > > > > if we provide a dockerfile that builds every supported arch (minus the > > > Mac) > > > > developers could easily modify it by removing parts they don't want as > > > > opposed to adding dependencies and builds for the parts that they do. > > > > > > That is the case with my version. > > > The builds are in separate script files that can be easily edited. > > > And if a build fails due to a source issue, it can just be repeated > > > after changing the source. > > > No need to rebuild the image. > > > Also no need to export the generated output as it is created on the host. > > > > > > > Also, I think this approach makes it easier for the next release manager > > > > because it declares all the necessary dependencies and performs the > > > builds > > > > in the proper order. > > > > > > AFAICT there is no ordering issue with my version apart from linux32 > > > which needs an extra install. > > > > > > > The last release was something of a challenge because > > > > a lot of corporate knowledge had been lost when the original developers > > > > left. > > > > > > Indeed. > > > > > > There is some documentation in the src/docker/README file, but it > > > could be expanded. > > > > > > > > > you > > > > must have used a different checkout when you reported the failures.> > > > > > > > > I got sidetracked. Apologies. I need to do that and provide feedback. > > > I > > > > don't see why we can't have both, as long as we document them. > > > > > > I see no reason to have both. > > > > > > > > > > be > > > > updated.> > > > > > > > > As of this PR, it's in the POM but not in the dockerfile. > > > > > > Sorry, you are right. > > > I thought I saw '32-bit build' but it was actually '32-bit Mac build'. > > > Oops. > > > We have already decided to drop that. > > > > > > > I see that you did a PR review. I'll try to look at it tonight and > > > > respond. > > > > > > > > Thanks. > > > > > > > > On Tue, Jun 21, 2022 at 4:23 PM sebb wrote: > > > > > > > > > On Tue, 21 Jun 2022 at 20:00, Alex Remily > > > wrote: > > > > > > > > > > > > I went ahead and submitted a PR related to this discussion. The > > > > > dockerfile > > > > > > does a full build, minus the Mac, and should simplify the release > > > > > process. > > > > > > > > > > Not sure how it improves on the Docker build I derived from your > > > > > previous submission. > > > > > > > > > > Did you try the sebb-docker branch again after my last reply? > > > > > I think you must have used a different checkout when you reported the > > > > > failures. > > > > > > > > > > > Developers can easily modify as needed for their own purposes. I > > > > > recommend > > > > > > removing the 32-bit Mac build profile from the POM, but have not > > > done so > > > > > in > > > > > > this PR. > > > > > > > > > > If it is removed from the POM then the Docker build will also need to > > > > > be updated. > > > > > > > > > > Whilst it is unlikely that the 32 bit builds will be needed, at > > > > > present they seem to work OK, > > > > > so they might as well be kept. > > > > > > > > > > > Alex > > > > > > > > > > > > https://github.com/apache/commons-crypto/pull/166 > > > > > > > > > > > > On Mon, Jun 20, 2022 at 10:24 AM sebb wrote: > > > > > > > > > > > > > On Mon, 20 Jun 2022 at 14:35, Alex Remily > > > > > wrote: > > > > > > > > > > > > > > > > Sebb, > > > > > > > > > > > > > > > > I cloned your repo and ran the dockerfile. Feedback: > > > > > > > > > > > > > > > > The Maven
