Re: [numbers-fraction] Documentation of fractions' reduction to lowest terms
Agreed, but it's not clear to me that it must be part of the public API. Yes, I admit that the public API doesn't really have anything to do with this, I realize that now. If my last email suggested otherwise, this was unintentional. On 7/1/19 11:52 PM, Gilles Sadowski wrote: Hello. Le lun. 1 juil. 2019 à 20:23, Heinrich Bohne a écrit : Is there a case where *not* knowing whether the fraction is reduced or not is detrimental? Hm, maybe you're right and specifying this (as well as where the sign is stored) in the public API is not that important, as long as the combination of returned numerator and denominator is valid. The only benefit would have been that the user would have the certainty that the returned values are already reduced to lowest terms, so that, in case this matters to the user, they don't need to reduce the values themselves. But whether this would outweigh the reduced flexibility of the API is something that probably cannot be answered without the ability to predict the future. However, what *is* crucial is specifying these things in the documentation of the private fields that hold the numerator and denominator, because a lot of the class' implementation relies on this. Sure. The code doc should indicate all current assumptions. By not leaking them into the public API, we keep the flexibility until usage requires to go one way or another. In fact, I noticed that BigFraction.hashCode() was broken before the resolution of NUMBERS-119 and NUMBERS-125, because, while BigFraction.equals(Object) reduced the numerators and denominators before comparing them, hashCode() didn't. Specifying the reduction to lowest terms of the fields numerator and denominator is even more important in Fraction than in BigFraction, because the magnitude of the values stored in these fields has an impact on whether arithmetic operations overflow or don't. Agreed, but it's not clear to me that it must be part of the public API. Gilles On 7/1/19 7:03 PM, Gilles Sadowski wrote: Hello. Le lun. 1 juil. 2019 à 12:35, Heinrich Bohne a écrit : Couldn't it entail a loss of opportunity to allow "non-reduced" fractions for efficiency reason? Yes, it would, but I can't envision a scenario where this would be detrimental. Of course, I may be missing something. Is there a case where *not* knowing whether the fraction is reduced or not is detrimental? But I don't follow; if it's an implementation detail, it should not appear anywhere in the doc, and users should not rely on it. What I meant is that it would be an implementation detail how the numerator and denominator are stored. What the methods getNumerator() and getDenominator() return should, of course, be specified appropriately (for example, something like "returns the numerator of this fraction's representation in lowest terms"). It just occurred to me that the question of where something should be documented can also be applied to the sign being held by the numerator rather than the denominator in case of negative fractions (which, if I'm not mistaken, is currently only specified in Fraction.getReducedFraction(int, int), a method that is targeted for deletion in https://issues.apache.org/jira/browse/NUMBERS-125 ). Good catch. It's a similar issue: Is knowing where the sign is stored useful to users or can it be considered an implementation detail (leaving more freedom to change it)? Wouldn't a method "isNegative()" be a better alternative? Regards, Gilles On 7/1/19 9:32 AM, Gilles Sadowski wrote: Hi. Le lun. 1 juil. 2019 à 03:52, Heinrich Bohne a écrit : I've recently been wondering about the following: With the resolution of NUMBERS-119 (https://issues.apache.org/jira/browse/NUMBERS-119), all constructors in Fraction and BigFraction reduce the created fraction to lowest terms (in the constructor Fraction(double, double, int, int), this is not obvious, but because the convergents of a simple continued fraction are automatically reduced to lowest terms when calculated with the recursive formula used in the constructor, the fraction returned thereof is also reduced to lowest terms). This rises the following question: Would it not be better if this reduction to lowest terms were made part of the contract of the two fields storing the numerator and denominator (i.e. included in their documentation), and, as a consequence, of the corresponding public accessor methods? Couldn't it entail a loss of opportunity to allow "non-reduced" fractions for efficiency reason? Then the fact that the fraction is reduced to lowest terms when created from a constructor or a public factory method would become an implementation detail irrelevant to the caller of the method/constructor, which could also prevent confusion, seeing as the numerator-denominator factory methods are the only ones that explicitly state that the fraction is reduced to lowest terms, even though this is true for all other factory methods as well. The doc should be fixed. But I
Re: [VOTE][RESULT] Release Apache Commons Daemon 1.2.0 RC2
The following votes were cast: Binding: +1: ggregory, markt, chtompki, stain Non-binding: +1: Jonathan Gallimore No other votes were cast. The vote therefore passes. Thanks to everyone who contributed to this release. Mark On 28/06/2019 15:20, Mark Thomas wrote: > It has been ~18 months since the last Commons Daemon release. After the > recent flurry of activity and a couple of failed RCs, it is time for > another release vote. > > Notable changes since 1.1.0 include: > - Improved JRE/JDK detection to support increased range of both JVM > versions and vendors. > - Procrun. Minimum target platform for Windows binaries is now Windows 7 > - Procrun. Change the default service from LocalSystem to > 'NT Authority\LocalService' > > The full set of changes is in the changelog > > 1.2.0 RC2 can be obtained from (r34680): > https://dist.apache.org/repos/dist/dev/commons/daemon/ > > The git tag is: > Tag: COMMONS_DAEMON_1_2_0_RC2 > URL: > https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=d88fd9100c1110fa51b7c7a08e3e7efd0e58227b > Hash: d88fd9100c1110fa51b7c7a08e3e7efd0e58227b > > The Maven Staging repo is: > https://repository.apache.org/content/repositories/orgapachecommons-1443/ > > The Windows binaries have been signed by the Symantec code signing service. > > Files signed with my preferred key: > http://people.apache.org/~markt/ > KEYS file is standard Apache Commons keys file: > http://www.apache.org/dist/commons/KEYS > > > [ ] Approved - go ahead and release Commons Daemon 1.2.0 RC2 as 1.2.0 > [ ] Broken - do not release because... > > - > 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: [VOTE] Release Apache Commons Text 1.7 based on RC1
My +1 Gary On Sun, Jun 30, 2019 at 10:28 AM Gary Gregory wrote: > We have fixed quite a few bugs and added some significant enhancements > since Apache Commons Text 1.6 was released, so I would like to release > Apache Commons Text 1.7. > > Apache Commons Text 1.7 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/text/1.7-RC1 (svn > revision 34703) > > The Git tag commons-text-1.7-RC1 commit for this RC is > 3866d2626dc3767b003c7cfe163a388b10c80957 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-text.git;a=commit;h=3866d2626dc3767b003c7cfe163a388b10c80957 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-text.git > --branch commons-text-1.7-RC1 commons-text-1.7-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1445/org/apache/commons/commons-text/1.7/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Sun Jun 30 10:15:20 EDT 2019 > > commons-text-1.7-bin.tar.gz=b900c07380f986c916e8fba6bff561ddf5bd1362d8b7b4b4487a780cb78ba86fc3cf0b30fc6b07053fca26a893ada44134fc2d0ab31bee6394e44f411ad3cdb4 > > commons-text-1.7-bin.tar.gz.asc=0b5d581f3c085ae428ef2c149c74127d9a1070f5ea2cdfe8394446cc6b2481ea712d07b3a65fb455bfbb991027138dc633b3845a083041b5b8f8d295080a3ab0 > > commons-text-1.7-bin.zip=d97c7021c568b349a4ae09f5fcfae3a6ce592aec83b46f7c9c9777c945e3555a25e93ef39544eb4430ee00206aca2979e35542709d23461f0229c2df80744234 > > commons-text-1.7-bin.zip.asc=a861e9786b00fec6c39ea6705e388c3b08225a8f5fc399c2f68d09b6d61b60fd16337731d71013e8eccb178b7d6c4c53bfdec5363139bf9bd42d7605b8b21c15 > > commons-text-1.7-javadoc.jar=138588633e95974fadca17340ec771e1bea8a614e53ec37aaa9b86fc4a09ee3bfc2645f207ff2fa9c4c53c664ee767d14a6a683145d0165ff94f5e1d4b8d7a14 > > commons-text-1.7-javadoc.jar.asc=7fc209412ced402547eade377a3e184572a503b11cdccde3c043023601f351f26235b56fd94ad00158e25c5e1a8d0055e7e8e88a5cb0d0448cddd2f0da054a73 > > commons-text-1.7-sources.jar=380158e7aa99be61608dd53b7929e48cc4d4f4e898221033205d36b22f6d59046f67fceaa1df832ca3f6760515980a5df4b9c450ced43e4aa9ee26fab22baaa7 > > commons-text-1.7-sources.jar.asc=1db512a3af2ad5c04617dcf896e611bee7a029ec51b9892bea02504fc283212b4d6d3c44af703d31a3802e5bf4f5fb537d455d50b070aa4e4b0ffe4902c381d5 > > commons-text-1.7-src.tar.gz=5660e4566e55b42e3b6ca22cd50affa232f5477e9ac30bd244eea7cdedc7f588d633e54aeb52bdec77506a8cbab22124b8c2fd6a94901140df75a75751775106 > > commons-text-1.7-src.tar.gz.asc=fa3486f6f0ed1521875a4a4e41028e10680149440fa1c9ea9960cc8cb3cca5ce3ceaad41336ac8bf62b100c187a7b9ed4608d84230f57a33e66ecc1fa9464a64 > > commons-text-1.7-src.zip=e168f84b109a2d174e6c51ce3a94606e00a2ac1373a88486e9dca735133e3a1f3e906b580e59f1aa38d9dd2f31774dba9f5d1a0b402db3fd87d9aa36438d713b > > commons-text-1.7-src.zip.asc=81a06410fbb81055b8580b4b7a9d635b8f5ccc851419aa23346e87f67578d09b8cc16637713bb4595998086651b7256400af3b134db5bbbea8b6255b4afe8438 > > commons-text-1.7-test-sources.jar=d2ead377bfc1f57efb4f885764b47e956b702063147c550dbc71789681654612aec69d0d585f5afac52a3b650e4c72189f68f6eef3b3e06427dc53ff0f58ff20 > > commons-text-1.7-test-sources.jar.asc=1e9e481115338f1213ddacdaaebfbbc611c7cfe9816b0f432ea143fee2777e8a19b5bc987e1438a97b9b9a7afc1fe01188be7b055494c47bede93c1e366ee37a > > commons-text-1.7-tests.jar=b6109fee5d299cd0d0985938b65703b7b1941995d00eeb169d98de18c1eabbaff7feeb258bab819e5a6a4dc06a9647235b900b2bd2457296810e2fabf64b > > commons-text-1.7-tests.jar.asc=2f6297a03538e6b128e505aab34cce75790e9256c6545e964ee3918eac88dfb69d2fddaa845242022a55354b9a6911e207a190f8b81b7e6e6d19eeb986096511 > > commons-text-1.7.jar.asc=566460a04edb42c34a7d5bda1b255804a61a134a08ae881af6a1b3476ca178da1bc27f2900776785a4a2af8fc7cec74935791e354e1b91885e356e3873172aa0 > > commons-text-1.7.pom.asc=d481dd4360ca514b9279b5e38780f65b33555cc07c927f761e5ca1df1d6e013ffb0390245d6ac5046cef77be0102465a133f9c4663eb14f0316f987033bd0074 > > (no need for .asc hashes!) > > I have tested this with 'mvn -V -Duser.name=%my_apache_id% > -Dcommons.release-plugin.version=%commons.release-plugin.version% > -Ddoclint=none -Prelease -Pjacoco -Ptest-deploy clean package site deploy' > 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" > > After the above, I ran 'mvn -V test' with: > > 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: 11.0.3, vendor: Oracle Corporation, runtime: C:\Program > Files\Java\jdk-11.0.3 > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows 10", version: "10.0", arch: "amd64", family: "windows" > >
Re: [VOTE] Release Apache Commons Daemon 1.2.0 RC2
My vote: +1 (binding) Verified: +1 sha512 sha256 +1 asc / KEYS +1 src zip vs tar.gz +1 bin zip vs tar.gz vs jar +1 src vs git (missing in src: README.md CONTRIBUTING.md; whitespace differences in commons-daemon-1.2.0-native-src) +1 mvn repo vs dist +1 mvn apache-rat:check +1 No unexpected binaries in src (bmp, rtf, ico) +1 LICENSE NOTICE +0 GPL code in src/native/unix/support/config.* (permitted w/ autoconf exception) +1 mvn clean install -1 commons-daemon-1.2.0-native-src/unix/INSTALL.txt outdated +1 ./configure ; make (tested just ./jsvc --help ) Tested with Ubuntu 18.04 TLS $ mvn -v Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 2018-10-24T19:41:47+01:00) Maven home: /home/stain/software/maven Java version: 11.0.3, vendor: Oracle Corporation, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_GB, platform encoding: UTF-8 OS name: "linux", version: "4.15.0-52-generic", arch: "amd64", family: "unix" I did not test building or running the Windows part. commons-daemon-1.2.0-native-src/unix is outdated as it claims you only need to run "sh support/buildconf.sh" if building from SVN. We are using git, and I still had to run it when building from dist/sources On Fri, 28 Jun 2019 15:20:56 +0100, Mark Thomas wrote: > It has been ~18 months since the last Commons Daemon release. After the > recent flurry of activity and a couple of failed RCs, it is time for > another release vote. > > Notable changes since 1.1.0 include: > - Improved JRE/JDK detection to support increased range of both JVM > versions and vendors. > - Procrun. Minimum target platform for Windows binaries is now Windows 7 > - Procrun. Change the default service from LocalSystem to > 'NT Authority\LocalService' > > The full set of changes is in the changelog > > 1.2.0 RC2 can be obtained from (r34680): > https://dist.apache.org/repos/dist/dev/commons/daemon/ > > The git tag is: > Tag: COMMONS_DAEMON_1_2_0_RC2 > URL: > https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=d88fd9100c1110fa51b7c7a08e3e7efd0e58227b > Hash: d88fd9100c1110fa51b7c7a08e3e7efd0e58227b > > The Maven Staging repo is: > https://repository.apache.org/content/repositories/orgapachecommons-1443/ > > The Windows binaries have been signed by the Symantec code signing service. > > Files signed with my preferred key: > http://people.apache.org/~markt/ > KEYS file is standard Apache Commons keys file: > http://www.apache.org/dist/commons/KEYS > > > [ ] Approved - go ahead and release Commons Daemon 1.2.0 RC2 as 1.2.0 > [ ] Broken - do not release because... > > - > 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: [VOTE] Release Apache Commons Daemon 1.2.0 RC2
+1, thanks for the release! Jon On Fri, Jun 28, 2019 at 3:21 PM Mark Thomas wrote: > It has been ~18 months since the last Commons Daemon release. After the > recent flurry of activity and a couple of failed RCs, it is time for > another release vote. > > Notable changes since 1.1.0 include: > - Improved JRE/JDK detection to support increased range of both JVM > versions and vendors. > - Procrun. Minimum target platform for Windows binaries is now Windows 7 > - Procrun. Change the default service from LocalSystem to > 'NT Authority\LocalService' > > The full set of changes is in the changelog > > 1.2.0 RC2 can be obtained from (r34680): > https://dist.apache.org/repos/dist/dev/commons/daemon/ > > The git tag is: > Tag: COMMONS_DAEMON_1_2_0_RC2 > URL: > > https://gitbox.apache.org/repos/asf?p=commons-daemon.git;a=commit;h=d88fd9100c1110fa51b7c7a08e3e7efd0e58227b > Hash: d88fd9100c1110fa51b7c7a08e3e7efd0e58227b > > The Maven Staging repo is: > https://repository.apache.org/content/repositories/orgapachecommons-1443/ > > The Windows binaries have been signed by the Symantec code signing service. > > Files signed with my preferred key: > http://people.apache.org/~markt/ > KEYS file is standard Apache Commons keys file: > http://www.apache.org/dist/commons/KEYS > > > [ ] Approved - go ahead and release Commons Daemon 1.2.0 RC2 as 1.2.0 > [ ] Broken - do not release because... > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [configuration] review for PR 30
Le 02/07/2019 à 01:59, Gary Gregory a écrit : > What would you call the method? I don't know, setPropertyDirectInternal? It's private anyway, the name isn't important. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
