Impact of COVID-19 on Open Source Development Activities
Dear all, This is a reminder to take The Impact of COVID-19 on Open Source Development Activities Survey that was sent to you a few days ago: https://docs.google.com/forms/d/e/1FAIpQLSedJ1LT8AgLCoQMuyIcIxuoUsLHy6mzGf5-TEsWj64Y-FCDrQ/viewform?usp=sf_link If you already have taken the survey, you do not need to take the survey again. Normally, we would not send you a reminder if you had already completed a survey, but because this survey is truly anonymous, we aren't able to track who has or has not completed the survey. In case you missed the earlier announcement, the survey is intended to investigate how quarantine due COVID-19 is affecting, or has affected, the activities in the open source software projects. Best wishes. -- PhD Edna Dias Canedo Associate Professor Homepage: https://cic.unb.br/~ednacanedo/ Department of Computer Science University of Brasília (UnB), Campus Darcy Ribeiro, Brasília-DF, Brazil -- PhD Edna Dias Canedo Associate Professor Homepage: https://cic.unb.br/~ednacanedo/ Department of Computer Science University of Brasília (UnB), Campus Darcy Ribeiro, Brasília-DF, Brazil
[Statistics] ContinuousDistribution probability and ConstantContinuousDistribution
The ContinuousDistribution interface has the method:
/**
* For a random variable {@code X} whose values are distributed according
* to this distribution, this method returns {@code P(X = x)}.
* In other words, this method represents the probability mass function
* (PMF) for the distribution.
*
* @param x Point at which the PMF is evaluated.
* @return the value of the probability mass function at point {@code x}.
*/
default double probability(double x) {
return 0;
}
This is not overridden by any distribution. The javadoc is a direct copy
from the DiscreteDistribution interface where the PMF has relevance. All
the continuous distributions provide implementations for the related
density method:
/**
* Returns the probability density function (PDF) of this distribution
* evaluated at the specified point {@code x}.
* In general, the PDF is the derivative of the {@link
#cumulativeProbability(double) CDF}.
* If the derivative does not exist at {@code x}, then an appropriate
* replacement should be returned, e.g. {@code Double.POSITIVE_INFINITY},
* {@code Double.NaN}, or the limit inferior or limit superior of the
* difference quotient.
*
* @param x Point at which the PDF is evaluated.
* @return the value of the probability density function at {@code x}.
*/
double density(double x);
It appears odd that the ContinuousDistribution has a probability(x) method
which returns 0 for all implementations, i.e. why have this method? It
could be implemented for the ConstantContinuousDistribution. At least in
this case for a constant value it should return 1 when x is the value of
the distribution.
I have had no luck finding another library that implements this
distribution (e.g. R, matlab, python) and I do not know a use case other
than to implement a Dirac delta function [1]. In this case it is useful to
have the density return 1 such that multiplication by the density is a
linear functional that maps every function to its value at zero:
f(x) * delta(x) = f(0) for x=0, zero otherwise
In other libraries for continuous functions they implement only the
probability density function (PDF) and the cumulative distribution function
(CDF) for both continuous and discrete distributions. There is no
additional probability function.
Thus the method has no use in the current library. Here are two options:
1. Remove the method
2. Implement the method in the ConstantContinuousDistribution to return 1
when the value equals the constant value. It currently does this for the
density function but probability(x) will return zero for all values so it a
bug. This behaviour was ported from Commons Math 3. I find no continuous
distributions that override the probability method there either.
Alex
[1] https://en.wikipedia.org/wiki/Dirac_delta_function
Re: [Statistics] ContinuousDistribution probability and ConstantContinuousDistribution
Hello.
Le dim. 1 août 2021 à 16:45, Alex Herbert a écrit :
>
> The ContinuousDistribution interface has the method:
>
> /**
> * For a random variable {@code X} whose values are distributed according
> * to this distribution, this method returns {@code P(X = x)}.
> * In other words, this method represents the probability mass function
> * (PMF) for the distribution.
> *
> * @param x Point at which the PMF is evaluated.
> * @return the value of the probability mass function at point {@code x}.
> */
> default double probability(double x) {
> return 0;
> }
>
> This is not overridden by any distribution. The javadoc is a direct copy
> from the DiscreteDistribution interface where the PMF has relevance. All
> the continuous distributions provide implementations for the related
> density method:
>
> /**
> * Returns the probability density function (PDF) of this distribution
> * evaluated at the specified point {@code x}.
> * In general, the PDF is the derivative of the {@link
> #cumulativeProbability(double) CDF}.
> * If the derivative does not exist at {@code x}, then an appropriate
> * replacement should be returned, e.g. {@code Double.POSITIVE_INFINITY},
> * {@code Double.NaN}, or the limit inferior or limit superior of the
> * difference quotient.
> *
> * @param x Point at which the PDF is evaluated.
> * @return the value of the probability density function at {@code x}.
> */
> double density(double x);
>
> It appears odd that the ContinuousDistribution has a probability(x) method
> which returns 0 for all implementations, i.e. why have this method? It
> could be implemented for the ConstantContinuousDistribution. At least in
> this case for a constant value it should return 1 when x is the value of
> the distribution.
>
> I have had no luck finding another library that implements this
> distribution (e.g. R, matlab, python) and I do not know a use case other
> than to implement a Dirac delta function [1]. In this case it is useful to
> have the density return 1 such that multiplication by the density is a
> linear functional that maps every function to its value at zero:
>
> f(x) * delta(x) = f(0) for x=0, zero otherwise
Do you think that the API defined in the
"commons-statistics-distribution"
module is suitable for implementing this concept:
https://en.wikipedia.org/wiki/Distribution_(mathematics)
?
> In other libraries for continuous functions they implement only the
> probability density function (PDF) and the cumulative distribution function
> (CDF) for both continuous and discrete distributions. There is no
> additional probability function.
>
> Thus the method has no use in the current library. Here are two options:
>
> 1. Remove the method
+1
Thanks,
Gilles
> 2. Implement the method in the ConstantContinuousDistribution to return 1
> when the value equals the constant value. It currently does this for the
> density function but probability(x) will return zero for all values so it a
> bug. This behaviour was ported from Commons Math 3. I find no continuous
> distributions that override the probability method there either.
>
> Alex
>
> [1] https://en.wikipedia.org/wiki/Dirac_delta_function
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [geometry] 1.0 release (take 2)
Hi. Le dim. 1 août 2021 à 02:57, Matt Juntunen a écrit : > > Hello, > > I've addressed a few issues since I last proposed the commons-geometry > 1.0 release, namely > - reducing the code smells in SonarCloud from 100+ to 8 (mostly by > clearing false positives) and > - removing use of checked exceptions in the IO modules (GEOMETRY-138). Thanks! :-) > I've also run fuzz testing locally on the IO modules and am pursuing > integrating the project into OSS-Fuzz. So, how are we feeling about a > 1.0 release? We should wait for some positive feedback from the code being exercised by that new tool. [I've no idea of how long is long enough.] Then, as a matter of preference, I'd still suggest that "Commons RNG" be released first (if the latter's next release is pending). Best, Gilles > As before, the following modules would be included: > - commons-geometry-core > - commons-geometry-euclidean > - commons-geometry-spherical > - commons-geometry-io-core > - commons-geometry-io-euclidean > > Regards, > Matt J - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [geometry] 1.0 release (take 2)
On Sun, 1 Aug 2021 at 16:25, Gilles Sadowski wrote: > Hi. > > Le dim. 1 août 2021 à 02:57, Matt Juntunen a > écrit : > > > > Hello, > > > > I've addressed a few issues since I last proposed the commons-geometry > > 1.0 release, namely > > - reducing the code smells in SonarCloud from 100+ to 8 (mostly by > > clearing false positives) and > > - removing use of checked exceptions in the IO modules (GEOMETRY-138). > > Thanks! :-) > > > I've also run fuzz testing locally on the IO modules and am pursuing > > integrating the project into OSS-Fuzz. So, how are we feeling about a > > 1.0 release? > > We should wait for some positive feedback from the code being > exercised by that new tool. [I've no idea of how long is long enough.] > > Then, as a matter of preference, I'd still suggest that "Commons RNG" > be released first (if the latter's next release is pending). > I think that RNG can be released as there is nothing pending to add. I've updated the user guide with the latest performance tests and new API additions. I have not yet checked the new API to make sure all is OK with the new method signatures and class names. Alex
Re: [Statistics] ContinuousDistribution probability and ConstantContinuousDistribution
On Sun, 1 Aug 2021 at 15:57, Gilles Sadowski wrote: > > > Do you think that the API defined in the > "commons-statistics-distribution" > module is suitable for implementing this concept: > https://en.wikipedia.org/wiki/Distribution_(mathematics) > ? > That is a different definition of distribution and involves using distributions to define differentials of integrable functions. I am not familiar with this usage. It may have been applicable in the scope of CM but I think that statistics should be limited in scope to just probability distributions. Wikipedia lists a disambiguation page for distribution [1] so perhaps we should be clear that statistics.distribution is applicable to probability distributions [2]. The package javadoc currently states: Implementations of common discrete and continuous distributions. This can be updated to: Implementations of common discrete and continuous probability distributions. [1] https://en.wikipedia.org/wiki/Distribution#In_mathematics [2] https://en.wikipedia.org/wiki/Probability_distribution > > > In other libraries for continuous functions they implement only the > > probability density function (PDF) and the cumulative distribution > function > > (CDF) for both continuous and discrete distributions. There is no > > additional probability function. > > > > Thus the method has no use in the current library. Here are two options: > > > > 1. Remove the method > > +1 > > Thanks, > Gilles > > > 2. Implement the method in the ConstantContinuousDistribution to return 1 > > when the value equals the constant value. It currently does this for the > > density function but probability(x) will return zero for all values so > it a > > bug. This behaviour was ported from Commons Math 3. I find no continuous > > distributions that override the probability method there either. > > > > Alex > > > > [1] https://en.wikipedia.org/wiki/Dirac_delta_function > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Statistics] ContinuousDistribution probability and ConstantContinuousDistribution
Hi. Le dim. 1 août 2021 à 18:52, Alex Herbert a écrit : > > On Sun, 1 Aug 2021 at 15:57, Gilles Sadowski wrote: > > > > > > > Do you think that the API defined in the > > "commons-statistics-distribution" > > module is suitable for implementing this concept: > > https://en.wikipedia.org/wiki/Distribution_(mathematics) > > ? > > > > That is a different definition of distribution Sure. I thought that you were mentioning it as a possible scope extension. > and involves using > distributions to define differentials of integrable functions. I am not > familiar with this usage. It may have been applicable in the scope of CM > but I think that statistics should be limited in scope to just probability > distributions. Wikipedia lists a disambiguation page for distribution [1] > so perhaps we should be clear that statistics.distribution is applicable to > probability distributions [2]. > > The package javadoc currently states: > > Implementations of common discrete and continuous distributions. > > This can be updated to: > > Implementations of common discrete and continuous probability distributions. +1 Gilles > > [1] https://en.wikipedia.org/wiki/Distribution#In_mathematics > [2] https://en.wikipedia.org/wiki/Probability_distribution > > > > > > > In other libraries for continuous functions they implement only the > > > probability density function (PDF) and the cumulative distribution > > function > > > (CDF) for both continuous and discrete distributions. There is no > > > additional probability function. > > > > > > Thus the method has no use in the current library. Here are two options: > > > > > > 1. Remove the method > > > > +1 > > > > Thanks, > > Gilles > > > > > 2. Implement the method in the ConstantContinuousDistribution to return 1 > > > when the value equals the constant value. It currently does this for the > > > density function but probability(x) will return zero for all values so > > it a > > > bug. This behaviour was ported from Commons Math 3. I find no continuous > > > distributions that override the probability method there either. > > > > > > Alex > > > > > > [1] https://en.wikipedia.org/wiki/Dirac_delta_function > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[Statistics] Precomputation of values used in probabilities
Some of the distributions precompute values to be used in the probability
computations, others do not.
IMO if you are using a distribution it is likely that you will call one of
the probability functions many times. Which one is unknown. Options are:
1. Precompute all values that can be precomputed for each probability
computation. Some values will not be necessary depending on the use case.
2. Precompute nothing. This will repeat computations for each call to the
relevant method. In the case of inverse CDF computations solved by search
of the CDF this can be expensive.
3. Dynamically compute the values on the first call.
Option 3 is possible without synchronization using a pattern:
double value = Double.NaN;
double getValue() {
double v = value;
if (Double.isNaN(v)) {
value = v = computeValue();
}
return v;
}
This adds a lot of complexity to the classes.
I would opt for option 1 in order to optimise the distribution in use and
take the performance hit in the constructor. In the assumed use case of
multiple invocations of a probability method then the precomputation of
values for all probability methods will likely still be an optimisation for
the single method of interest invoked multiple times.
In the use case of creating a distribution to create a sampler, the
generation of random deviates will likely take far longer than any
performance hit for unnecessary precomputations.
Alex
Re: [Statistics] ContinuousDistribution probability and ConstantContinuousDistribution
On Sun, 1 Aug 2021 at 18:20, Gilles Sadowski wrote: > Hi. > > Le dim. 1 août 2021 à 18:52, Alex Herbert a > écrit : > > > > On Sun, 1 Aug 2021 at 15:57, Gilles Sadowski > wrote: > > > > > > > > > > > Do you think that the API defined in the > > > "commons-statistics-distribution" > > > module is suitable for implementing this concept: > > > https://en.wikipedia.org/wiki/Distribution_(mathematics) > > > ? > > > > > > > That is a different definition of distribution > > Sure. I thought that you were mentioning it as a possible scope > extension. > Ah I understand since I mentioned the Dirac function. I did not mean to extend the scope to the aforementioned area of maths. That was my only use case for the ConstantContinuousDistribution. It appears to be a strange addition to the library. No other libraries I looked at have it. A bit of digging in the commit history of CM found that this distribution was added to fix MATH-984 [1] so the EmpericalDistribution can represent each bin using a distribution that can perform sampling of the bin. If a bin has a single value then the ConstantContinuousDistribution applies. Since this does not apply to the code in Commons statistics then I would suggest dropping it from the library. [1] https://issues.apache.org/jira/browse/MATH-984
Re: [Statistics] ContinuousDistribution probability and ConstantContinuousDistribution
On Sun, 1 Aug 2021 at 15:57, Gilles Sadowski wrote: > > > > > 1. Remove the method > > +1 If we remove: ContinuousDistribution.probability(double) There is the option to rename ContinuousDistribution.density(double) ContinuousDistribution.logDensity(double) To probability and logProbability. This would then match the names in the DiscreteDistribution interface. Functions in Matlab use the term pdf for both discrete and continuous distributions. Functions in R use the prefix 'p' for probability. So some libraries do use the same term for both types of distribution. The javadoc can be used to distinguish the PMF [1] (discrete distributions) and PDF [2] (continuous distributions). I am not convinced by this rename. The use of density does make it clear that it is the probability density function and applies as the derivative of the CDF. Integrating the PDF must be used to obtain a probability. Wikipedia does state that the term probability function may be used in the literature for other functions leading to confusion. I would just reorder the method's occurrence in the interface to the top, matching the occurrence in the DiscreteDistribution interface. [1] https://en.wikipedia.org/wiki/Probability_mass_function [2] https://en.wikipedia.org/wiki/Probability_density_function
Re: [Statistics] Precomputation of values used in probabilities
Le dim. 1 août 2021 à 19:24, Alex Herbert a écrit :
>
> Some of the distributions precompute values to be used in the probability
> computations, others do not.
>
> IMO if you are using a distribution it is likely that you will call one of
> the probability functions many times. Which one is unknown. Options are:
>
> 1. Precompute all values that can be precomputed for each probability
> computation. Some values will not be necessary depending on the use case.
> 2. Precompute nothing. This will repeat computations for each call to the
> relevant method. In the case of inverse CDF computations solved by search
> of the CDF this can be expensive.
> 3. Dynamically compute the values on the first call.
>
> Option 3 is possible without synchronization using a pattern:
>
> double value = Double.NaN;
>
> double getValue() {
> double v = value;
> if (Double.isNaN(v)) {
> value = v = computeValue();
> }
> return v;
> }
>
> This adds a lot of complexity to the classes.
>
> I would opt for option 1 in order to optimise the distribution in use and
> take the performance hit in the constructor.
+1
Simpler and more robust code (through immutability).
Gilles
> In the assumed use case of
> multiple invocations of a probability method then the precomputation of
> values for all probability methods will likely still be an optimisation for
> the single method of interest invoked multiple times.
>
> In the use case of creating a distribution to create a sampler, the
> generation of random deviates will likely take far longer than any
> performance hit for unnecessary precomputations.
>
> Alex
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Statistics] ContinuousDistribution probability and ConstantContinuousDistribution
Le dim. 1 août 2021 à 19:57, Alex Herbert a écrit : > > On Sun, 1 Aug 2021 at 15:57, Gilles Sadowski wrote: > > > > > > > > > 1. Remove the method > > > > +1 > > > If we remove: > > ContinuousDistribution.probability(double) > > There is the option to rename > > ContinuousDistribution.density(double) > ContinuousDistribution.logDensity(double) > > To probability and logProbability. This would then match the names in the > DiscreteDistribution interface. Functions in Matlab use the term pdf for > both discrete and continuous distributions. Functions in R use the prefix > 'p' for probability. So some libraries do use the same term for both types > of distribution. > > The javadoc can be used to distinguish the PMF [1] (discrete distributions) > and PDF [2] (continuous distributions). > > I am not convinced by this rename. The use of density does make it clear > that it is the probability density function and applies as the derivative > of the CDF. Integrating the PDF must be used to obtain a probability. I also think that "density" is the more correct and non-ambiguous term. Regards, Gilles > Wikipedia does state that the term probability function may be used in the > literature for other functions leading to confusion. > > I would just reorder the method's occurrence in the interface to the top, > matching the occurrence in the DiscreteDistribution interface. > > [1] https://en.wikipedia.org/wiki/Probability_mass_function > [2] https://en.wikipedia.org/wiki/Probability_density_function - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Statistics] ContinuousDistribution probability and ConstantContinuousDistribution
On Sun, 1 Aug 2021 at 18:40, Alex Herbert wrote: > > A bit of digging in the commit history of CM found that this distribution > was added to fix MATH-984 [1] so the EmpericalDistribution can represent > each bin using a distribution that can perform sampling of the bin. If a > bin has a single value then the ConstantContinuousDistribution applies. > > Since this does not apply to the code in Commons statistics then I would > suggest dropping it from the library. > > [1] https://issues.apache.org/jira/browse/MATH-984 > Opinion on dropping ConstantContinuousDistribution since the use case from Commons Math does not apply? > >
Re: [VOTE] Release Apache Commons DBCP 2.9.0 based on RC1
[x] +1 Release these artifacts Build OK from tag with Maven home: /opt/apache-maven-3.6.3 Java version: 11.0.11, vendor: Ubuntu, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.4.0-80-generic", arch: "amd64", family: "unix" Site reports look good. Thanks! Bruno On Sunday, 1 August 2021, 3:19:42 am NZST, Gary Gregory wrote: We have fixed a few bugs and added some enhancements since Apache Commons DBCP 2.8.0 was released, so I would like to release Apache Commons DBCP 2.9.0. Apache Commons DBCP 2.9.0 RC1 is available for review here: https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1 (svn revision 49104) The Git tag commons-dbcp-2.9.0-RC1 commit for this RC is 2abdb498d0aa7b65d668fc5661795bc83844d8fa which you can browse here: https://gitbox.apache.org/repos/asf?p=commons-dbcp.git;a=commit;h=2abdb498d0aa7b65d668fc5661795bc83844d8fa You may checkout this tag using: git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git --branch commons-dbcp-2.9.0-RC1 commons-dbcp-2.9.0-RC1 Maven artifacts are here: https://repository.apache.org/content/repositories/orgapachecommons-1559/org/apache/commons/commons-dbcp2/2.9.0/ These are the artifacts and their hashes: #Release SHA-512s #Sat Jul 31 11:10:11 EDT 2021 commons-dbcp2-2.9.0-bin.tar.gz=3d910565aefae7db7e659078dca9b5b82dc16522be88783a9362b2f26b39bf6e9a8f1bddcdf37b6d5839abff03a8b0934643a08a0d5685da8d20ccfd8a9d4164 commons-dbcp2-2.9.0-bin.zip=cdd212b8740b6a5a4ae34f03cf8a205be7a56c62c7a12b6fa8f8c48a05ecd813ecf566fcf6b5d4b03d7e6c81d2ac77f00f8ad4f222bbb7a45e677a566f681f25 commons-dbcp2-2.9.0-javadoc.jar=f8ddb21b3f5e43988befe868e777c00f7a5295b1954fa377d91575a2edbf394d0d1d87563615b34915f4128d00264d402a28aa26c08011e328b2f5b94d20df50 commons-dbcp2-2.9.0-sources.jar=54f65de7f5223081588c84a124843a0e4937fc81696599e27bf736122aaa589b71f707121704cd6ef2fd17316363b3db22a76bae63de5f0df184dffe7b95 commons-dbcp2-2.9.0-src.tar.gz=8f3d47030b71606af4113f09d80f681dc7882d9636cea453a650705582d1a9043397024042e42811eff0a69025965e60d11c578296062f4f05e7a49066344d9a commons-dbcp2-2.9.0-src.zip=b0354f0e9c7d154095ffa1a2a736c606c8fc168146ffbab27614c9e297dd8e5b7d5719f92899dd51b23b63b7fa2c97786d2fae7f48d6b8ff357e742ef8ad097f commons-dbcp2-2.9.0-test-sources.jar=c17bfd92f1dd7f9f6e074a69fed15827ad4e7d98210bf0d430e91e3842fd2a09c99c1ffb30d51b4c4745cd24925d52313c1215fadeb5bf414b094ccd256d6ae5 commons-dbcp2-2.9.0-tests.jar=a4484612e3f11c7b73b96aa6668bccd8dfa9d7dc3cb5a22821709b658ce3568dfff239cb1c168bc513bc88062389e137d95fd5ce206a8d2479aa1b3195255bfe I have tested this with mvn -V -Duser.name=$my_apache_id -Dcommons.release-plugin.version=$commons_release_plugin_version -Prelease -Ptest-deploy -P jacoco -P japicmp clean package site deploy using: Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d) Maven home: /usr/local/Cellar/maven/3.8.1/libexec Java version: 1.8.0_292, vendor: AdoptOpenJDK, runtime: /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre Default locale: en_US, platform encoding: UTF-8 OS name: "mac os x", version: "10.16", arch: "x86_64", family: "mac" Darwin gdg-mac-mini.local 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64 Details of changes since 2.8.0 are in the release notes: https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/RELEASE-NOTES.txt https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/changes-report.html Site: https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/index.html (note some *relative* links are broken and the 2.9.0 directories are not yet created - these will be OK once the site is deployed.) JApiCmp Report (compared to 2.8.0): https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/japicmp.html Note that the above report contains text in red but nothing is broken, just moved, and binary compatibility is maintained. RAT Report: https://dist.apache.org/repos/dist/dev/commons/dbcp/2.9.0-RC1/site/rat-report.html KEYS: https://www.apache.org/dist/commons/KEYS Please review the release candidate and vote. This vote will close no sooner than 72 hours from now. [ ] +1 Release these artifacts [ ] +0 OK, but... [ ] -0 OK, but really should fix... [ ] -1 I oppose this release because... Thank you, Gary Gregory, Release Manager (using key 86fdc7e2a11262cb) For following is intended as a helper and refresher for reviewers. Validating a release candidate == These guidelines are NOT complete. Requirements: Git, Java, Maven. You can validate a release from a release candidate (RC) tag as follows. 1) Clone and checkout the RC tag git clone https://gitbox.apache.org/repos/asf/commons-dbcp.git --branch commons-dbcp-2.9.0-RC1 commons-dbcp-2.9.0-RC1 cd commons-dbcp-2.9.0-RC1 2) Check Apache licenses This step is not
Re: [Statistics] ContinuousDistribution probability and ConstantContinuousDistribution
Le dim. 1 août 2021 à 20:13, Alex Herbert a écrit : > > On Sun, 1 Aug 2021 at 18:40, Alex Herbert wrote: > > > > > A bit of digging in the commit history of CM found that this distribution > > was added to fix MATH-984 [1] so the EmpericalDistribution can represent > > each bin using a distribution that can perform sampling of the bin. If a > > bin has a single value then the ConstantContinuousDistribution applies. > > > > Since this does not apply to the code in Commons statistics then I would > > suggest dropping it from the library. > > > > [1] https://issues.apache.org/jira/browse/MATH-984 > > > > Opinion on dropping ConstantContinuousDistribution The class is used in Commons Math.[1] > since the use case from > Commons Math does not apply? Do you mean that this ad-hoc class should be moved back to CM (as a private inner class of "EmpiricalDistribution")? Regards, Gilles https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/distribution/EmpiricalDistribution.java;h=3fd8bbf4cc0a929811835e5c23590c55a0f2a534;hb=HEAD#l370 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Statistics] ContinuousDistribution probability and ConstantContinuousDistribution
On Sun, 1 Aug 2021 at 22:28, Gilles Sadowski wrote: > Le dim. 1 août 2021 à 20:13, Alex Herbert a > écrit : > > > > On Sun, 1 Aug 2021 at 18:40, Alex Herbert > wrote: > > > > > > > > A bit of digging in the commit history of CM found that this > distribution > > > was added to fix MATH-984 [1] so the EmpericalDistribution can > represent > > > each bin using a distribution that can perform sampling of the bin. If > a > > > bin has a single value then the ConstantContinuousDistribution applies. > > > > > > Since this does not apply to the code in Commons statistics then I > would > > > suggest dropping it from the library. > > > > > > [1] https://issues.apache.org/jira/browse/MATH-984 > > > > > > > Opinion on dropping ConstantContinuousDistribution > > The class is used in Commons Math.[1] > Yes, my remiss. Of course it would be given MATH-984 is the use case for it. > > since the use case from > > Commons Math does not apply? > > Do you mean that this ad-hoc class should be moved back to CM (as a > private inner class of "EmpiricalDistribution")? > That would be cleaner. The distribution is only used to allow the EmpiricalDistribution to function without knowing details of the bin, i.e. all bins have a kernel that is a distribution. I do not know a use case for this distribution and no other library I searched has an implementation. So removing it from the public API makes more sense. Regards, > Gilles > > > https://gitbox.apache.org/repos/asf?p=commons-math.git;a=blob;f=commons-math-legacy/src/main/java/org/apache/commons/math4/legacy/distribution/EmpiricalDistribution.java;h=3fd8bbf4cc0a929811835e5c23590c55a0f2a534;hb=HEAD#l370 > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [NET] Issues with FTPSClientTest and JKS files
On Thu, 29 Jul 2021 at 14:22, sebb wrote: > > On Thu, 29 Jul 2021 at 13:43, Gary Gregory wrote: > > > > On Tue, Jul 27, 2021 at 7:38 PM sebb wrote: > > > > > > On Tue, 27 Jul 2021 at 16:05, sebb wrote: > > > > > > > > Something strange is going on with the FTPSClientTest. > > > > > > > > One my macOS system, the original jks file works with all my Java > > > > installations: > > > > Java 8 (Oracle and AdoptOpenJDK) > > > > Java 11 (Oracle and AdoptOpenJDK) > > > > Java 15 (Oracle) > > > > Java 16 (AdoptOpenJDK) > > > > > > > > With the jre8.jks, only Java8 works; the others all fail with: > > > > java.io.EOFException: SSL peer shut down incorrectly > > > > > > > > With jre16.jks and java 16, I get > > > > java.io.EOFException: SSL peer shut down incorrectly > > > > > > > > However, when GitHub builds using the original JKS file, only Java 8 > > > > works. > > > > Java 11, 16 and 17 all hang when running FTPSClientTest > > > > > > Lots of debugging later, and it looks like the MINA server does not > > > always see the USER command, so that test is timing out. > > > However it does work sometimes (in all the JDK versions), so it does > > > not seem to be an issue with the JKS file (currently using the > > > original one). > > > > > > The code works OK on Jenkins (currently using JDK 16). > > > > > > Why is only GitHub failing? > > > > Could there be a subtle difference in OS and JRE version? > > It's not just the OS, because Java 8 works on GitHub with the same OS. > > Obviously something is different, otherwise we would not see a > consistent difference in behaviour. > > Question is: how to proceed? > > It seems to be associated with MINA embedded FTP server: is there an > alternative that could be used for the test? I've found a work-round: add a short sleep (200 ms) before the USER command. I added it because I noticed that the the MINA ftpserver did not appear to receive the USER command. So perhaps the previous commands sometimes need a bit of time to catch up? I'm just guessing. > BTW, we still need to document how the original JKS file was created. This is still the case. > The new ones don't work reliably. I have deleted them. > > Gary > > > > > > > > > Any ideas? > > > > > > > > Sebb. > > > > > > - > > > 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
Re: [Statistics] ContinuousDistribution probability and ConstantContinuousDistribution
> > > > [...] > > > > > > Opinion on dropping ConstantContinuousDistribution > > > > [...] > > > > Do you mean that this ad-hoc class should be moved back to CM (as a > > private inner class of "EmpiricalDistribution")? > > > > That would be cleaner. The distribution is only used to allow the > EmpiricalDistribution to function without knowing details of the bin, i.e. > all bins have a kernel that is a distribution. Done in commit 3df6d879e701b442fabf709c8143e6ca8f8f9547. Gilles > [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [geometry] 1.0 release (take 2)
> We should wait for some positive feedback from the code being > exercised by that new tool. [I've no idea of how long is long enough.] If I'm reading this link [1] correctly, it sounds like a few days should be sufficient. (The fuzzers were merged in today.) > Then, as a matter of preference, I'd still suggest that "Commons RNG" > be released first (if the latter's next release is pending). Ok. Any thoughts on a timeline for that? Regards, Matt J [1] https://google.github.io/oss-fuzz/faq/#what-if-my-fuzzer-does-not-find-anything On Sun, Aug 1, 2021 at 12:36 PM Alex Herbert wrote: > > On Sun, 1 Aug 2021 at 16:25, Gilles Sadowski wrote: > > > Hi. > > > > Le dim. 1 août 2021 à 02:57, Matt Juntunen a > > écrit : > > > > > > Hello, > > > > > > I've addressed a few issues since I last proposed the commons-geometry > > > 1.0 release, namely > > > - reducing the code smells in SonarCloud from 100+ to 8 (mostly by > > > clearing false positives) and > > > - removing use of checked exceptions in the IO modules (GEOMETRY-138). > > > > Thanks! :-) > > > > > I've also run fuzz testing locally on the IO modules and am pursuing > > > integrating the project into OSS-Fuzz. So, how are we feeling about a > > > 1.0 release? > > > > We should wait for some positive feedback from the code being > > exercised by that new tool. [I've no idea of how long is long enough.] > > > > Then, as a matter of preference, I'd still suggest that "Commons RNG" > > be released first (if the latter's next release is pending). > > > > I think that RNG can be released as there is nothing pending to add. I've > updated the user guide with the latest performance tests and new API > additions. I have not yet checked the new API to make sure all is OK with > the new method signatures and class names. > > Alex - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [commons-net] branch master updated: Javadoc 17 does not like empty paras
FYI, "" is not an "empty para", it's an open tag on an element, while
"" is an empty element. What Javadoc wants is for tags to be balanced,
IOW close when was previously opened.
Gary
On Sun, Aug 1, 2021, 19:28 wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> sebb pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-net.git
>
>
> The following commit(s) were added to refs/heads/master by this push:
> new 719771a Javadoc 17 does not like empty paras
> 719771a is described below
>
> commit 719771affb6a01756e21c620b26b886859c119ae
> Author: Sebb
> AuthorDate: Mon Aug 2 00:27:57 2021 +0100
>
> Javadoc 17 does not like empty paras
> ---
> .../java/org/apache/commons/net/SocketClient.java | 50
> +++---
> 1 file changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/src/main/java/org/apache/commons/net/SocketClient.java
> b/src/main/java/org/apache/commons/net/SocketClient.java
> index eddf9ab..f8149c1 100644
> --- a/src/main/java/org/apache/commons/net/SocketClient.java
> +++ b/src/main/java/org/apache/commons/net/SocketClient.java
> @@ -225,7 +225,7 @@ public abstract class SocketClient
> * and originating from the current host at a system assigned port.
> * Before returning, {@link #_connectAction_ _connectAction_() }
> * is called to perform connection initialization actions.
> - *
> + *
> * @param host The remote host.
> * @throws SocketException If the socket timeout could not be set.
> * @throws IOException If the socket could not be opened. In most
> @@ -244,7 +244,7 @@ public abstract class SocketClient
> * originating from the current host at a system assigned port.
> * Before returning, {@link #_connectAction_ _connectAction_() }
> * is called to perform connection initialization actions.
> - *
> + *
> * @param host The remote host.
> * @param port The port to connect to on the remote host.
> * @throws SocketException If the socket timeout could not be set.
> @@ -265,7 +265,7 @@ public abstract class SocketClient
> * originating from the specified local address and port.
> * Before returning, {@link #_connectAction_ _connectAction_() }
> * is called to perform connection initialization actions.
> - *
> + *
> * @param host The remote host.
> * @param port The port to connect to on the remote host.
> * @param localAddr The local address to use.
> @@ -289,7 +289,7 @@ public abstract class SocketClient
> * port and originating from the current host at a system assigned
> port.
> * Before returning, {@link #_connectAction_ _connectAction_() }
> * is called to perform connection initialization actions.
> - *
> + *
> * @param hostname The name of the remote host.
> * @throws SocketException If the socket timeout could not be set.
> * @throws IOException If the socket could not be opened. In most
> @@ -307,7 +307,7 @@ public abstract class SocketClient
> * originating from the current host at a system assigned port.
> * Before returning, {@link #_connectAction_ _connectAction_() }
> * is called to perform connection initialization actions.
> - *
> + *
> * @param hostname The name of the remote host.
> * @param port The port to connect to on the remote host.
> * @throws SocketException If the socket timeout could not be set.
> @@ -328,7 +328,7 @@ public abstract class SocketClient
> * originating from the specified local address and port.
> * Before returning, {@link #_connectAction_ _connectAction_() }
> * is called to perform connection initialization actions.
> - *
> + *
> * @param hostname The name of the remote host.
> * @param port The port to connect to on the remote host.
> * @param localAddr The local address to use.
> @@ -360,7 +360,7 @@ public abstract class SocketClient
> * {@link #connect connect() }
> * again. _isConnected_ is set to false, _socket_ is set to null,
> * _input_ is set to null, and _output_ is set to null.
> - *
> + *
> * @throws IOException If there is an error closing the socket.
> */
> public void disconnect() throws IOException
> @@ -449,7 +449,7 @@ public abstract class SocketClient
> /**
> * Returns the current value of the default port (stored in
> * {@link #_defaultPort_ _defaultPort_ }).
> - *
> + *
> * @return The current value of the default port.
> */
> public int getDefaultPort()
> @@ -460,7 +460,7 @@ public abstract class SocketClient
> /**
> * Returns the default timeout in milliseconds that is used when
> * opening a socket.
> - *
> + *
> * @return The default timeout in milliseconds that is used when
> * opening a socket.
> */
> @@ -
Re: [commons-compress] branch master updated: COMPRESS-583: update the changelog of COMPRESS-404
Ah, I forgot about the RELEASE-NOTES. Thanks for your help. cheers, Lee On Sat, Jul 31, 2021 at 7:52 PM Gary Gregory wrote: > Doing the site is good too. I will try to look... > > On Sat, Jul 31, 2021, 07:51 Gary Gregory wrote: > > > I was just talking about the readme html file from the svn repo. > > > > Gary > > > > On Fri, Jul 30, 2021, 22:20 PeterLee wrote: > > > >> > You might want to regenerate the release notes that are served on the > >> > download site. > >> > >> Yes. I do want to update the website, but I have no idea how to do this. > >> Can anyone give me a hand? > >> > >> cheers, > >> Lee > >> > >> On Sat, Jul 31, 2021 at 10:02 AM Gary Gregory > >> wrote: > >> > >> > You might want to regenerate the release notes that are served on the > >> > download site. > >> > > >> > Gary > >> > > >> > On Fri, Jul 30, 2021, 21:44 wrote: > >> > > >> > > This is an automated email from the ASF dual-hosted git repository. > >> > > > >> > > peterlee 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 7bc8679 COMPRESS-583: update the changelog of COMPRESS-404 > >> > > 7bc8679 is described below > >> > > > >> > > commit 7bc86793d2533ef314550efe2b79df752abdc8d4 > >> > > Author: PeterAlfredLee > >> > > AuthorDate: Sat Jul 31 09:38:52 2021 +0800 > >> > > > >> > > COMPRESS-583: update the changelog of COMPRESS-404 > >> > > --- > >> > > src/changes/changes.xml | 4 > >> > > 1 file changed, 4 insertions(+) > >> > > > >> > > diff --git a/src/changes/changes.xml b/src/changes/changes.xml > >> > > index 24b28c5..ee52465 100644 > >> > > --- a/src/changes/changes.xml > >> > > +++ b/src/changes/changes.xml > >> > > @@ -149,6 +149,10 @@ you relied on the recovery attempt."> > >> > > Update the class of variable file in TarArchiveEntry from > >> > > java.io.File to java.nio.file.Path. Corresponding > >> constructors > >> > > and methods are also modified/added. > >> > > + > >> > > +NOTE: The UserID and GroupID will also be read if they are > >> > > +available. The previous default value UserID:GroupdID of > was > >> > 0:0. > >> > > +This may cause a reproducibility problem. > >> > > Github Pull Request #97. > >> > > > >> > > >> > > due-to="Robin Schimpf"> > >> > > > >> > > >> > > >
