Re: [numbers][fraction] pulling fraction-dev into master
Changed are merged; in particular the travis updates were kept; if you are working on Fraction kindly rebase. On Wed, Jun 5, 2019 at 3:40 PM Eric Barnhill wrote: > For some months I worked on the Fraction class on a fraction-dev branch, > now others are furthering it, but IIUC working off of master, plus it > sounds like my edits are out of date in other ways. > > So within the next day, I will pull fraction-dev into master. I would > request any other contributors contributing to Fraction, to merge these > changes into their own work and rebase. > > I was at the final checkstyle edits of what I was working on, so hopefully > it will not cause anyone more than minor conveniences. If it will cause you > a larger inconvenience and you would rather work together to merge it, > please post here. If you find after the fact it causes you a headache I can > roll it back, I will keep the branch around for a while. > > Eric >
Re: [math] MATH-1486 and release 3.6.2
Hello. Le jeu. 6 juin 2019 à 18:14, Stephen Colebourne a écrit : > > I've raised a GitHub PR [1] to add the Java 9 module name to [math] on > the MATH_3_X branch. Assuming that is merged, I'm willing to raise > another PR with the necessary bits to prepare the repo to release > v3.6.2. > > This approach sidesteps all issues with commons-4 and does the minimum > necessary for downstream users to use the project as a module in Java > 9 onwards. (At my day job we produce open source that depends on > commons-math, which means I can't add a module-info.java until > commons-math has a module name.) > > While I'm technically still a commons committer, I think it would be > highly innappropriate for me to try and shepherd the actual v3.6.2 > release. Is anyone willing to work with me to do the release? A v3.6.2 > release would contain just the module name change and one performance > improvement that was added to the repo in 2016, so it should be a case > of cranking the handle providing not too much has changed in the > process since 2016. I was about to merge the PR but, on my machine, the build fails. Did you try? Back then (pre-fork), I was in favour of maintaining both lines (3.X and 4.X); but the 3.X branch has not been maintained for more than 3 years, and it shows. Now (post-fork), my opinion is that the effort would be better placed in getting the new dependencies of the development version of Commons Math released, and release CM 4.0 thereafter. Regards, Gilles > thanks > Stephen > [1] https://github.com/apache/commons-math/pull/107 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[math] MATH-1486 and release 3.6.2
I've raised a GitHub PR [1] to add the Java 9 module name to [math] on the MATH_3_X branch. Assuming that is merged, I'm willing to raise another PR with the necessary bits to prepare the repo to release v3.6.2. This approach sidesteps all issues with commons-4 and does the minimum necessary for downstream users to use the project as a module in Java 9 onwards. (At my day job we produce open source that depends on commons-math, which means I can't add a module-info.java until commons-math has a module name.) While I'm technically still a commons committer, I think it would be highly innappropriate for me to try and shepherd the actual v3.6.2 release. Is anyone willing to work with me to do the release? A v3.6.2 release would contain just the module name change and one performance improvement that was added to the repo in 2016, so it should be a case of cranking the handle providing not too much has changed in the process since 2016. thanks Stephen [1] https://github.com/apache/commons-math/pull/107 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RNG] Re: [commons-rng] 04/11: RNG-75: Use SplitMix64.next()
On 06/06/2019 16:07, Gilles Sadowski wrote:
Hi.
Not sure about the changes below.
It seems to me that "nextLong()" ensures that a "long" is generated,
while "next()" could, if the RNG type is later changed, return an "int"
cast to "long" (i.e. half its bits set to zero).
Regards,
Gilles
Good spot. It was introduced when looking at a weird performance spike
in the JMH timings for seed conversion. I do not think it was the
problem and could be a bigger, different problem in the future.
I will fix this with a revert.
Le jeu. 6 juin 2019 à 10:00, a écrit :
This is an automated email from the ASF dual-hosted git repository.
aherbert pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/commons-rng.git
commit aa246979feb8c880c60c972faf7c9ffb9174f4cd
Author: Alex Herbert
AuthorDate: Fri May 31 22:35:25 2019 +0100
RNG-75: Use SplitMix64.next()
---
.../java/org/apache/commons/rng/simple/internal/Long2IntArray.java| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/commons-rng-simple/src/main/java/org/apache/commons/rng/simple/internal/Long2IntArray.java
b/commons-rng-simple/src/main/java/org/apache/commons/rng/simple/internal/Long2IntArray.java
index d98a77c..2f7660c 100644
---
a/commons-rng-simple/src/main/java/org/apache/commons/rng/simple/internal/Long2IntArray.java
+++
b/commons-rng-simple/src/main/java/org/apache/commons/rng/simple/internal/Long2IntArray.java
@@ -62,11 +62,11 @@ public class Long2IntArray implements
Seed2ArrayConverter {
int i = 0;
// Handle an odd size
if ((size & 1) == 1) {
-out[i++] = NumberFactory.extractHi(rng.nextLong());
+out[i++] = NumberFactory.extractHi(rng.next());
}
// Fill the remaining pairs
while (i < size) {
-final long v = rng.nextLong();
+final long v = rng.next();
out[i] = NumberFactory.extractHi(v);
out[i + 1] = NumberFactory.extractLo(v);
i += 2;
-
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] Re: [commons-rng] 04/11: RNG-75: Use SplitMix64.next()
On 06/06/2019 16:07, Gilles Sadowski wrote:
Hi.
Not sure about the changes below.
It seems to me that "nextLong()" ensures that a "long" is generated,
while "next()" could, if the RNG type is later changed, return an "int"
cast to "long" (i.e. half its bits set to zero).
Regards,
Gilles
Good spot. It was introduced when looking at a weird performance spike
in the JMH timings for seed conversion. I do not think it was the
problem and could be a bigger, different problem in the future.
I will fix this with a revert.
Le jeu. 6 juin 2019 à 10:00, a écrit :
This is an automated email from the ASF dual-hosted git repository.
aherbert pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/commons-rng.git
commit aa246979feb8c880c60c972faf7c9ffb9174f4cd
Author: Alex Herbert
AuthorDate: Fri May 31 22:35:25 2019 +0100
RNG-75: Use SplitMix64.next()
---
.../java/org/apache/commons/rng/simple/internal/Long2IntArray.java| 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/commons-rng-simple/src/main/java/org/apache/commons/rng/simple/internal/Long2IntArray.java
b/commons-rng-simple/src/main/java/org/apache/commons/rng/simple/internal/Long2IntArray.java
index d98a77c..2f7660c 100644
---
a/commons-rng-simple/src/main/java/org/apache/commons/rng/simple/internal/Long2IntArray.java
+++
b/commons-rng-simple/src/main/java/org/apache/commons/rng/simple/internal/Long2IntArray.java
@@ -62,11 +62,11 @@ public class Long2IntArray implements
Seed2ArrayConverter {
int i = 0;
// Handle an odd size
if ((size & 1) == 1) {
-out[i++] = NumberFactory.extractHi(rng.nextLong());
+out[i++] = NumberFactory.extractHi(rng.next());
}
// Fill the remaining pairs
while (i < size) {
-final long v = rng.nextLong();
+final long v = rng.next();
out[i] = NumberFactory.extractHi(v);
out[i + 1] = NumberFactory.extractLo(v);
i += 2;
-
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
[RNG] Re: [commons-rng] 04/11: RNG-75: Use SplitMix64.next()
Hi.
Not sure about the changes below.
It seems to me that "nextLong()" ensures that a "long" is generated,
while "next()" could, if the RNG type is later changed, return an "int"
cast to "long" (i.e. half its bits set to zero).
Regards,
Gilles
Le jeu. 6 juin 2019 à 10:00, a écrit :
>
> This is an automated email from the ASF dual-hosted git repository.
>
> aherbert pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-rng.git
>
> commit aa246979feb8c880c60c972faf7c9ffb9174f4cd
> Author: Alex Herbert
> AuthorDate: Fri May 31 22:35:25 2019 +0100
>
> RNG-75: Use SplitMix64.next()
> ---
> .../java/org/apache/commons/rng/simple/internal/Long2IntArray.java| 4
> ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
> a/commons-rng-simple/src/main/java/org/apache/commons/rng/simple/internal/Long2IntArray.java
>
> b/commons-rng-simple/src/main/java/org/apache/commons/rng/simple/internal/Long2IntArray.java
> index d98a77c..2f7660c 100644
> ---
> a/commons-rng-simple/src/main/java/org/apache/commons/rng/simple/internal/Long2IntArray.java
> +++
> b/commons-rng-simple/src/main/java/org/apache/commons/rng/simple/internal/Long2IntArray.java
> @@ -62,11 +62,11 @@ public class Long2IntArray implements
> Seed2ArrayConverter {
> int i = 0;
> // Handle an odd size
> if ((size & 1) == 1) {
> -out[i++] = NumberFactory.extractHi(rng.nextLong());
> +out[i++] = NumberFactory.extractHi(rng.next());
> }
> // Fill the remaining pairs
> while (i < size) {
> -final long v = rng.nextLong();
> +final long v = rng.next();
> out[i] = NumberFactory.extractHi(v);
> out[i + 1] = NumberFactory.extractLo(v);
> i += 2;
>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] Alpha/beta releases
On Wed, 5 Jun 2019 at 23:40, Gary Gregory wrote: > > Hi All: > > I see two lines of usage IRL from people: > > - I use whatever is "released" on Maven Central. I quote the word released > since that includes ANY artifacts, pre 1.0 like a 0.87 or -alpha, and > -betas. N.B. This by definition excludes SNAPSHOTs > - I am not allowed to use alpha, beta, or SNAPSHOT versions. > > The reality ends up being that you see some stacks that have a mix of both > of the above. > > We all know that Jar hell is created when breaking BC within the same > package name (and Maven coordinates.) Or changing Maven coordinates but not changing the package name. > We have clear rules of engagement of major, minor and maintenance releases. > > The question for me is how should we treat other kinds of releases: alphas > and betas. This is assuming that we want to keep on releasing alphas and > betas. > > Jar hell is, well, hellish. I like to avoid it. +1 > Since the very nature of alphas and betas is that changing APIs should be > allowed, even encouraged in order to get the API in the right shape before > a x.y.z release, I am warming to using alpha and beta in package names... I thought API changes were restricted to alpha releases and beta for behaviour changes? But this is a minor detail. > If you are to be so bold as to use such a thing, then reflecting that in > the import states what you are doing clearly, and avoid any jar hell. Agreed, it's clearly the user choice here since they have to change their code (and POM) to use the new package. Note: this would also require use of new Maven coordinates. > That said, it should be left to each component to decide whether or not to > opt in such naming. +1 I think it would be worth documenting step by step how the proposal works overall, to make sure that nothing has been overlooked. One can then look at whether any additional tooling is needed, or if it already exists. > Gary > > > On Wed, Jun 5, 2019 at 6:25 PM Gilles Sadowski wrote: > > > Le mer. 5 juin 2019 à 23:14, sebb a écrit : > > > > > > On Wed, 5 Jun 2019 at 17:16, Gilles Sadowski > > wrote: > > > > > > > > Le mer. 5 juin 2019 à 17:57, James Carman > > a écrit : > > > > > > > > > > I’m having a hard time understanding the comparing APIs use case. > > If I > > > > > were to want to try that, I’d create a branch and import the new > > dependency > > > > > version and see what breaks. The performance part I wouldn’t think > > I’d use > > > > > one code base either. I’m not suggesting my way is the only or best > > way, > > > > > just explaining why I’m having a hard time understanding what you’re > > > > > doing. Maybe this will be a learning opportunity for me! :) > > > > > > > > Case mainly in point is getting to the first release of new components. > > > > This is happening now for [Imaging], and will be soon (hopefully) for > > > > [Numbers], [Statistics] and [Geometry]. > > > > > > > > IIUC, the former is going to release a beta version without modifying > > > > the top-level package name. This will create the possibility of JAR > > > > hell (when 1.0 will be out). > > > > > > > > Since we don't have that much review/feedback on these new and/or > > > > refactored codes, I thought we could be on a safer ground if we first > > > > release beta version(s) that > > > > * won't be subject to JAR hell and > > > > * will be easy (i.e. just add the dependency in the POM file) to > > > >integrate for people kind enough to give it a try. > > > >[If it's not easy[1], they won't do it.] > > > > > > > > Regards, > > > > Gilles > > > > > > > > [1] Like: You "just" have to install "git", check out the source, > > install > > > > "maven", run the "package" goal, then move the "target/whatever.jar" > > > > file to where your code will look for it. > > > > > > No need to install Git; can just download the source archive and unpack > > it. > > > I think we can assume they already have Maven, otherwise why are we > > > worried about releasing to Maven? > > > > > > Note that the suggestion of using different package names will force > > > users to edit their code. > > > > So what; this is the purpose of beta-testing features that don't > > exist in previous releases or in the previous beta version. > > > > > They will then have to compile their source, probably using Maven. > > > > > > Seems to me the suggestion creates more work for end users. > > > > People will have to do something. > > When they raise an issue, it is easier for me and for them to point > > to one-line change in their dependencies (and the corresponding > > change in their code), then to start explaining that they should > > build from source. > > > > From the discussion, I'm still missing the opinion stating explicitly > > that "we don't care about JAR hell produced by a beta release". > > My suggestion is only to avoid that. Is the PMC fine releasing > > *incompatible* beta releases (and of course incompatible with the > > "stable" r
