Re: Math: Yearly patch for commons-math3
Hi, David, if you want to be sure, that commons-math3 is being maintained, then I suggest that you take a look at the Git repository log. That should be sufficient: https://gitbox.apache.org/repos/asf?p=commons-math.git;a=log Jochen On Tue, Dec 6, 2022 at 3:57 PM Darrell Merryweather wrote: > > Hi > > As part of our FOSS compliance, we need to ensure that 3rd party libraries > are well maintained, to ensure, from a security perspective, we will have no > future issues. We are currently using commons-math3 in some of our > developments, and we were hoping someone might be able to include a yearly > patch of math3, even if its only updating the copyright headers, so that we > can ensure an updated version is maintained. > > Also, when is math4 being released? > > Thanks > > Darrell Merryweather -- Philosophy is useless, theology is worse. (Industrial Disease, Dire Straits) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Lang] "CalendarUtilsTest" fails, or not...
Interesting, the GH builds are green: https://github.com/apache/commons-lang/actions But the environment is different from yours: Maven home: /usr/share/apache-maven-3.8.6 Java version: 11.0.17, vendor: Eclipse Adoptium, runtime: /usr/lib/jvm/temurin-11-jdk-amd64 Default locale: en, platform encoding: UTF-8 OS name: "linux", version: "5.15.0-1023-azure", arch: "amd64", family: "unix" Gary On Tue, Dec 6, 2022, 19:18 Gilles Sadowski wrote: > Hello. > > Running > $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 mvn test > [... skipped ...] > [ERROR] Failures: > [ERROR] CalendarUtilsTest.testGetDayOfMonth:32 expected: <7> but was: <6> > [ERROR] CalendarUtilsTest.testGetDayOfYear:37 expected: <341> but was: > <340> > [INFO] > [ERROR] Tests run: 7330, Failures: 2, Errors: 0, Skipped: 7 > [...] > > > Running > $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 mvn > -Dtest=CalendarUtilsTest test > [... skipped ...] > [INFO] Running org.apache.commons.lang3.time.CalendarUtilsTest > [INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 0.089 s - in org.apache.commons.lang3.time.CalendarUtilsTest > [INFO] > [INFO] Results: > [INFO] > [INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0 > [...] > > Environment: > $ mvn -v > Apache Maven 3.6.3 > Maven home: /usr/share/maven > Java version: 11.0.16, vendor: Debian, runtime: > /usr/lib/jvm/java-11-openjdk-amd64 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "5.10.0-17-amd64", arch: "amd64", family: "unix" > > Regards, > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[Lang] "CalendarUtilsTest" fails, or not...
Hello. Running $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 mvn test [... skipped ...] [ERROR] Failures: [ERROR] CalendarUtilsTest.testGetDayOfMonth:32 expected: <7> but was: <6> [ERROR] CalendarUtilsTest.testGetDayOfYear:37 expected: <341> but was: <340> [INFO] [ERROR] Tests run: 7330, Failures: 2, Errors: 0, Skipped: 7 [...] Running $ JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64 mvn -Dtest=CalendarUtilsTest test [... skipped ...] [INFO] Running org.apache.commons.lang3.time.CalendarUtilsTest [INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.089 s - in org.apache.commons.lang3.time.CalendarUtilsTest [INFO] [INFO] Results: [INFO] [INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0 [...] Environment: $ mvn -v Apache Maven 3.6.3 Maven home: /usr/share/maven Java version: 11.0.16, vendor: Debian, runtime: /usr/lib/jvm/java-11-openjdk-amd64 Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "5.10.0-17-amd64", arch: "amd64", family: "unix" Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] Main site is outdated
Le mer. 7 déc. 2022 à 00:31, sebb a écrit : > > On Tue, 6 Dec 2022 at 22:28, Gilles Sadowski wrote: > > > > Hello. > > > > Homepage > >https://commons.apache.org/ > > contains inconsistent information: Some "(maven-central) badges" display > > a version number but the link points to another (usually older) one. See > > e.g. > > * RNG > > * Geometry > > * Imaging > > * Numbers > > * Compress > > * Pool > > * JCS > > * Math > > * Configuration > > * Text > > * Net > > * ... > > That's because the version data has not been updated in the relevant > status file. > RMs should ensure that the file is updated upon release. > > The badges are generated dynamically from Maven Central metadata, so > are whatever the image.shields.io website thinks is the latest. > > IMO these invisible dynamic queries go against the Privacy FAQ: > > https://privacy.apache.org/faq/committers.html > > I think it would be better to have a regular batch job to ensure the > status file is up to date and not rely on a 3rd party. > Sorry, I'm fairly lost here; I don't know what "image.shields.io" is. Nor when/how we started having those links/badges generated. I seem to remember that the RM had to update this file: https://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/component_releases.properties and the appropriate file in https://svn.apache.org/repos/asf/commons/cms-site/trunk/doap/ But then? Is there a script to run so that the site is updated? Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] Main site is outdated
On Tue, 6 Dec 2022 at 23:31, sebb wrote: > > On Tue, 6 Dec 2022 at 22:28, Gilles Sadowski wrote: > > > > Hello. > > > > Homepage > >https://commons.apache.org/ > > contains inconsistent information: Some "(maven-central) badges" display > > a version number but the link points to another (usually older) one. See > > e.g. > > * RNG > > * Geometry > > * Imaging > > * Numbers > > * Compress > > * Pool > > * JCS > > * Math > > * Configuration > > * Text > > * Net > > * ... > > That's because the version data has not been updated in the relevant > status file. > RMs should ensure that the file is updated upon release. Can you point to the relevant status file please? After a release I update: doap file in: https://svn.apache.org/repos/asf/commons/cms-site/trunk/doap component_releases.properties in: https://svn.apache.org/repos/asf/commons/cms-site/trunk/conf/ Is there another one I should update? Alex - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] Main site is outdated
On Tue, 6 Dec 2022 at 22:28, Gilles Sadowski wrote: > > Hello. > > Homepage >https://commons.apache.org/ > contains inconsistent information: Some "(maven-central) badges" display > a version number but the link points to another (usually older) one. See e.g. > * RNG > * Geometry > * Imaging > * Numbers > * Compress > * Pool > * JCS > * Math > * Configuration > * Text > * Net > * ... That's because the version data has not been updated in the relevant status file. RMs should ensure that the file is updated upon release. The badges are generated dynamically from Maven Central metadata, so are whatever the image.shields.io website thinks is the latest. IMO these invisible dynamic queries go against the Privacy FAQ: https://privacy.apache.org/faq/committers.html I think it would be better to have a regular batch job to ensure the status file is up to date and not rely on a 3rd party. > Regards, > Gilles > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng][lang] Shuffling arrays
I would rather keep the ArrayUtils.shuffle() methods not deprecated, and mention RNG in the Javadoc for more advanced usages. Adding a 100KB dependency just to shuffle an array isn't optimal. Emmanuel Bourg Le 06/12/2022 à 21:40, Gary Gregory a écrit : I am ok with both LANG and TEXT deprecating to RNG. Gary On Tue, Dec 6, 2022, 13:21 Alex Herbert wrote: On Tue, 6 Dec 2022 at 17:22, Gary Gregory wrote: I agree this should be in rng. Does rng duplicate all of the lang APIs such that we can deprecate the lang methods? In short, yes. (cd src/main && git grep -c Random) - ArrayUtils - RandomStringUtils - RandomUtils The proposed ArraySampler with shuffle methods for all array types would deprecate ArrayUtils.shuffle. You would have to provide a UniformRandomProvider in place of a java.util.Random. RandomStringUtils is not explicitly deprecated. However the class javadoc states that Commons Text's RandomStringGenerator and, generically, Commons RNG are more suitable for random generation. RandomUtils is already deprecated. It mentions RNG in the header but the functionality is for static thread-safe calls for random numbers. The RandomUtils class is partly deprecated by changing calls from RandomUtils.xxx to ThreadLocalRandom.current().xxx. The class uses ThreadLocalRandom under the hood, but does not act as a pass-through for all methods. It looks like these could be updated to directly use ThreadLocalRandom's implementation: nextLong(long upper) Note: This method in RandomUtils does not check upper > 0 which is a bug. However the bounds for some methods are different, some have extra conditions and some are missing from ThreadLocalRandom. method : lang : ThreadLocalRandom nextBytes(int) : present : NA nextDouble() : [0, MAX_VALUE) : [0, 1) nextDouble(lower, upper) : [lower, upper) | upper > lower >= 0 : upper > lower nextFloat() : [0, MAX_VALUE) : [0, 1) nextFloat(lower, upper) : [lower, upper) | upper > lower >= 0 : NA nextInt() : [0, MAX_VALUE) : [MIN_VALUE, MAX_VALUE] nextInt(upper) : NA : [0, upper) nextInt(lower, upper) : [lower, upper) | upper > lower >= 0 : [lower, upper) | upper > lower nextLong() : [0, MAX_VALUE) : [MIN_VALUE, MAX_VALUE] nextLong(upper) : [0, upper) [no check upper > 0] : [0, upper) nextLong(lower upper) : [lower, upper) | upper > lower >= 0 : [lower, upper) | upper > lower All these methods are in the UniformRandomProvider interface from [rng], including the nextFloat with ranges but with the exception of nextBytes(int count). The generators provide nextBytes(byte[]) and you must supply the array. In this case it may be helpful to document each method with an equivalent from ThreadLocalRandom that provides a thread-safe static call to generate the same output (with the exception that lower bounds can be negative in ThreadLocalRandom). Alex - 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
[ANNOUNCE] Apache Commons BCEL 6.7.0
The Apache Commons BCEL team is pleased to announce the release of Apache Commons BCEL 6.7.0! The Byte Code Engineering Library (BCEL) is intended to give users a convenient way to analyze, create, and manipulate compiled .class files. Classes are represented by objects containing all the symbolic information of the given class: methods, fields, and byte code instructions. This is a maintenance and bug-fix release. Historical list of changes: https://commons.apache.org/proper/commons-bcelchanges-report.html For complete information on Apache Commons BCEL, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Apache Commons BCEL website: https://commons.apache.org/proper/commons-bcel Download it from https://commons.apache.org/proper/commons-bcel/download_bcel.cgi Have fun! Gary Gregory -Apache Commons BCEL team Feedback Open source works best when you give feedback: https://commons.apache.org/bcel Please direct all bug reports to JIRA: https://issues.apache.org/jira/browse/BCEL Or subscribe to the commons-user mailing list The Apache Commons Team - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-math4 release date
Hello. Le mar. 6 déc. 2022 à 14:47, Darrell Merryweather a écrit : > > Hi > > Is there an estimated release date for the commons-math version 4.0 release? All dependencies for this new major version have now been released. So, a release could be done at any time now provided all issues targeted at 4.0 are resolved. Did you know that many functionalities originally in "Commons Math" (up to version 3.6.1) have been ported to new components: * RNG * Numbers * Geometry * Statistics ? I'd be interested to know which functionality you depend on. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[All] Main site is outdated
Hello. Homepage https://commons.apache.org/ contains inconsistent information: Some "(maven-central) badges" display a version number but the link points to another (usually older) one. See e.g. * RNG * Geometry * Imaging * Numbers * Compress * Pool * JCS * Math * Configuration * Text * Net * ... Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng][lang] Shuffling arrays
I am ok with both LANG and TEXT deprecating to RNG. Gary On Tue, Dec 6, 2022, 13:21 Alex Herbert wrote: > On Tue, 6 Dec 2022 at 17:22, Gary Gregory wrote: > > > > I agree this should be in rng. > > > > Does rng duplicate all of the lang APIs such that we can deprecate the > lang > > methods? > > In short, yes. > > (cd src/main && git grep -c Random) > - ArrayUtils > - RandomStringUtils > - RandomUtils > > The proposed ArraySampler with shuffle methods for all array types > would deprecate ArrayUtils.shuffle. You would have to provide a > UniformRandomProvider in place of a java.util.Random. > > RandomStringUtils is not explicitly deprecated. However the class > javadoc states that Commons Text's RandomStringGenerator and, > generically, Commons RNG are more suitable for random generation. > > RandomUtils is already deprecated. It mentions RNG in the header but > the functionality is for static thread-safe calls for random numbers. > The RandomUtils class is partly deprecated by changing calls from > RandomUtils.xxx to ThreadLocalRandom.current().xxx. The class uses > ThreadLocalRandom under the hood, but does not act as a pass-through > for all methods. It looks like these could be updated to directly use > ThreadLocalRandom's implementation: > > nextLong(long upper) > > Note: This method in RandomUtils does not check upper > 0 which is a bug. > > However the bounds for some methods are different, some have extra > conditions and some are missing from ThreadLocalRandom. > > method : lang : ThreadLocalRandom > nextBytes(int) : present : NA > nextDouble() : [0, MAX_VALUE) : [0, 1) > nextDouble(lower, upper) : [lower, upper) | upper > lower >= 0 : upper > > lower > nextFloat() : [0, MAX_VALUE) : [0, 1) > nextFloat(lower, upper) : [lower, upper) | upper > lower >= 0 : NA > nextInt() : [0, MAX_VALUE) : [MIN_VALUE, MAX_VALUE] > nextInt(upper) : NA : [0, upper) > nextInt(lower, upper) : [lower, upper) | upper > lower >= 0 : [lower, > upper) | upper > lower > nextLong() : [0, MAX_VALUE) : [MIN_VALUE, MAX_VALUE] > nextLong(upper) : [0, upper) [no check upper > 0] : [0, upper) > nextLong(lower upper) : [lower, upper) | upper > lower >= 0 : [lower, > upper) | upper > lower > > All these methods are in the UniformRandomProvider interface from > [rng], including the nextFloat with ranges but with the exception of > nextBytes(int count). The generators provide nextBytes(byte[]) and you > must supply the array. > > In this case it may be helpful to document each method with an > equivalent from ThreadLocalRandom that provides a thread-safe static > call to generate the same output (with the exception that lower bounds > can be negative in ThreadLocalRandom). > > Alex > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [rng][lang] Shuffling arrays
On Tue, 6 Dec 2022 at 17:22, Gary Gregory wrote: > > I agree this should be in rng. > > Does rng duplicate all of the lang APIs such that we can deprecate the lang > methods? In short, yes. (cd src/main && git grep -c Random) - ArrayUtils - RandomStringUtils - RandomUtils The proposed ArraySampler with shuffle methods for all array types would deprecate ArrayUtils.shuffle. You would have to provide a UniformRandomProvider in place of a java.util.Random. RandomStringUtils is not explicitly deprecated. However the class javadoc states that Commons Text's RandomStringGenerator and, generically, Commons RNG are more suitable for random generation. RandomUtils is already deprecated. It mentions RNG in the header but the functionality is for static thread-safe calls for random numbers. The RandomUtils class is partly deprecated by changing calls from RandomUtils.xxx to ThreadLocalRandom.current().xxx. The class uses ThreadLocalRandom under the hood, but does not act as a pass-through for all methods. It looks like these could be updated to directly use ThreadLocalRandom's implementation: nextLong(long upper) Note: This method in RandomUtils does not check upper > 0 which is a bug. However the bounds for some methods are different, some have extra conditions and some are missing from ThreadLocalRandom. method : lang : ThreadLocalRandom nextBytes(int) : present : NA nextDouble() : [0, MAX_VALUE) : [0, 1) nextDouble(lower, upper) : [lower, upper) | upper > lower >= 0 : upper > lower nextFloat() : [0, MAX_VALUE) : [0, 1) nextFloat(lower, upper) : [lower, upper) | upper > lower >= 0 : NA nextInt() : [0, MAX_VALUE) : [MIN_VALUE, MAX_VALUE] nextInt(upper) : NA : [0, upper) nextInt(lower, upper) : [lower, upper) | upper > lower >= 0 : [lower, upper) | upper > lower nextLong() : [0, MAX_VALUE) : [MIN_VALUE, MAX_VALUE] nextLong(upper) : [0, upper) [no check upper > 0] : [0, upper) nextLong(lower upper) : [lower, upper) | upper > lower >= 0 : [lower, upper) | upper > lower All these methods are in the UniformRandomProvider interface from [rng], including the nextFloat with ranges but with the exception of nextBytes(int count). The generators provide nextBytes(byte[]) and you must supply the array. In this case it may be helpful to document each method with an equivalent from ThreadLocalRandom that provides a thread-safe static call to generate the same output (with the exception that lower bounds can be negative in ThreadLocalRandom). Alex - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Math: Yearly patch for commons-math3
> On Dec 6, 2022, at 12:26 PM, Gary Gregory wrote: > > "even if its only updating the copyright headers" > > You must be joking, you know we are volunteers here. I can't imagine you'd > be willing to pay for this from a commercial vendor or consultant which > makes the request show a lack of respect for our time and resources. We are volunteers that are treated poorly by our employers! -Rob > > Gary > >> On Tue, Dec 6, 2022, 09:58 Darrell Merryweather < >> darrellmerryweat...@gmail.com> wrote: >> >> Hi >> >> As part of our FOSS compliance, we need to ensure that 3rd party libraries >> are well maintained, to ensure, from a security perspective, we will have >> no future issues. We are currently using commons-math3 in some of our >> developments, and we were hoping someone might be able to include a yearly >> patch of math3, even if its only updating the copyright headers, so that we >> can ensure an updated version is maintained. >> >> Also, when is math4 being released? >> >> Thanks >> >> Darrell Merryweather >> - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Math: Yearly patch for commons-math3
"even if its only updating the copyright headers" You must be joking, you know we are volunteers here. I can't imagine you'd be willing to pay for this from a commercial vendor or consultant which makes the request show a lack of respect for our time and resources. Gary On Tue, Dec 6, 2022, 09:58 Darrell Merryweather < darrellmerryweat...@gmail.com> wrote: > Hi > > As part of our FOSS compliance, we need to ensure that 3rd party libraries > are well maintained, to ensure, from a security perspective, we will have > no future issues. We are currently using commons-math3 in some of our > developments, and we were hoping someone might be able to include a yearly > patch of math3, even if its only updating the copyright headers, so that we > can ensure an updated version is maintained. > > Also, when is math4 being released? > > Thanks > > Darrell Merryweather >
Re: [rng][lang] Shuffling arrays
I agree this should be in rng.
Does rng duplicate all of the lang APIs such that we can deprecate the lang
methods?
Gary
On Tue, Dec 6, 2022, 09:36 Alex Herbert wrote:
> Currently the [rng] sampler package can only shuffle primitive int[]
> arrays:
>
> o.a.c.rng.sampling.PermutationSampler:
>
> public static void shuffle(UniformRandomProvider rng, int[] list)
> public static void shuffle(UniformRandomProvider rng,
>int[] list,
>int start,
>boolean towardHead)
>
> I would like to be able to shuffle other arrays such as double[].
> There is actually this functionality in [Lang] o.a.c.lang3.ArrayUtils.
> However it uses java.util.Random for the random source, and does not
> support a sub-range, e.g.
>
> public static void shuffle(final byte[] array)
> public static void shuffle(final byte[] array, final Random random)
>
> I suggest an API that requires UniformRandomProvider and can handle
> sub-ranges as:
>
> public static void shuffle(UniformRandomProvider rng, int[] data);
> public static void shuffle(UniformRandomProvider rng, int[] data, int
> from, int to);
> Or (similar to java.util.Arrays.copyOfRange):
> public static void shuffleOfRange(UniformRandomProvider rng, int[]
> data, int from, int to);
>
> This can be repeated for all 8 primitive types and generic type T.
>
> I suggest putting this in the sampling package but under what class?
> Note that all public class names in the sampling package currently end
> in Sampler. I would suggest ArraySampler.
>
> Note there is currently a ListSampler which has generic methods to
> return List samples from a list, and shuffle lists. So adding
> ArraySampler with only shuffling would be missing equivalent sample
> methods. Consistency would require adding 8 variations of sample and a
> generic one:
>
> public static double[] sample(UniformRandomProvider rng,
> double[] array,
> int k) {
> public static T[] sample(UniformRandomProvider rng,
> T[] array,
> int k)
>
> I have no use case for this but can add it for completeness.
>
> Alex
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Math: Yearly patch for commons-math3
Hi As part of our FOSS compliance, we need to ensure that 3rd party libraries are well maintained, to ensure, from a security perspective, we will have no future issues. We are currently using commons-math3 in some of our developments, and we were hoping someone might be able to include a yearly patch of math3, even if its only updating the copyright headers, so that we can ensure an updated version is maintained. Also, when is math4 being released? Thanks Darrell Merryweather
Re: [rng][lang] Shuffling arrays
On Tue, 6 Dec 2022 at 14:38, Bruno Kinoshita wrote: > > Hi Alex, > > I also don't have a use case for this right now. What about creating a JIRA > issue to wait to see if someone has the need for this feature? Maybe users > will confirm they need it, or provide other suggestions? > > -Bruno I do have a use case for shuffling primitive arrays. But not for sampling from primitive arrays. So I can create a jira issues for: 1. Add an ArraySampler with shuffle methods (to implement) 2. Add sampling methods to the ArraySampler (TBD) Alex - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [rng][lang] Shuffling arrays
Hi Alex,
I also don't have a use case for this right now. What about creating a JIRA
issue to wait to see if someone has the need for this feature? Maybe users
will confirm they need it, or provide other suggestions?
-Bruno
On Tue, 6 Dec 2022 at 15:36, Alex Herbert wrote:
> Currently the [rng] sampler package can only shuffle primitive int[]
> arrays:
>
> o.a.c.rng.sampling.PermutationSampler:
>
> public static void shuffle(UniformRandomProvider rng, int[] list)
> public static void shuffle(UniformRandomProvider rng,
>int[] list,
>int start,
>boolean towardHead)
>
> I would like to be able to shuffle other arrays such as double[].
> There is actually this functionality in [Lang] o.a.c.lang3.ArrayUtils.
> However it uses java.util.Random for the random source, and does not
> support a sub-range, e.g.
>
> public static void shuffle(final byte[] array)
> public static void shuffle(final byte[] array, final Random random)
>
> I suggest an API that requires UniformRandomProvider and can handle
> sub-ranges as:
>
> public static void shuffle(UniformRandomProvider rng, int[] data);
> public static void shuffle(UniformRandomProvider rng, int[] data, int
> from, int to);
> Or (similar to java.util.Arrays.copyOfRange):
> public static void shuffleOfRange(UniformRandomProvider rng, int[]
> data, int from, int to);
>
> This can be repeated for all 8 primitive types and generic type T.
>
> I suggest putting this in the sampling package but under what class?
> Note that all public class names in the sampling package currently end
> in Sampler. I would suggest ArraySampler.
>
> Note there is currently a ListSampler which has generic methods to
> return List samples from a list, and shuffle lists. So adding
> ArraySampler with only shuffling would be missing equivalent sample
> methods. Consistency would require adding 8 variations of sample and a
> generic one:
>
> public static double[] sample(UniformRandomProvider rng,
> double[] array,
> int k) {
> public static T[] sample(UniformRandomProvider rng,
> T[] array,
> int k)
>
> I have no use case for this but can add it for completeness.
>
> Alex
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
[rng][lang] Shuffling arrays
Currently the [rng] sampler package can only shuffle primitive int[] arrays:
o.a.c.rng.sampling.PermutationSampler:
public static void shuffle(UniformRandomProvider rng, int[] list)
public static void shuffle(UniformRandomProvider rng,
int[] list,
int start,
boolean towardHead)
I would like to be able to shuffle other arrays such as double[].
There is actually this functionality in [Lang] o.a.c.lang3.ArrayUtils.
However it uses java.util.Random for the random source, and does not
support a sub-range, e.g.
public static void shuffle(final byte[] array)
public static void shuffle(final byte[] array, final Random random)
I suggest an API that requires UniformRandomProvider and can handle
sub-ranges as:
public static void shuffle(UniformRandomProvider rng, int[] data);
public static void shuffle(UniformRandomProvider rng, int[] data, int
from, int to);
Or (similar to java.util.Arrays.copyOfRange):
public static void shuffleOfRange(UniformRandomProvider rng, int[]
data, int from, int to);
This can be repeated for all 8 primitive types and generic type T.
I suggest putting this in the sampling package but under what class?
Note that all public class names in the sampling package currently end
in Sampler. I would suggest ArraySampler.
Note there is currently a ListSampler which has generic methods to
return List samples from a list, and shuffle lists. So adding
ArraySampler with only shuffling would be missing equivalent sample
methods. Consistency would require adding 8 variations of sample and a
generic one:
public static double[] sample(UniformRandomProvider rng,
double[] array,
int k) {
public static T[] sample(UniformRandomProvider rng,
T[] array,
int k)
I have no use case for this but can add it for completeness.
Alex
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
commons-math4 release date
Hi Is there an estimated release date for the commons-math version 4.0 release? Thanks Darrell
Re: [VOTE] Release Apache Commons Statistics 1.0 based on RC1
Le mar. 6 déc. 2022 à 13:06, Alex Herbert a écrit : > > FYI > > On Mon, 5 Dec 2022 at 00:46, Alex Herbert wrote: > > > I am wondering why the module page on the site I uploaded does not > > render correctly. > > I have deployed the 1.0 release to the live site. The module page > renders correctly: > > https://commons.apache.org/proper/commons-statistics/commons-statistics-distribution/index.html Isn't it another argument for the release procedure to be relieved from the part about the broken (expectedly or not) web site? > > So the issue with staging the RC site to home.apache.org does not > apply when staged to the commons.apache.org. > You could perhaps (FTR) file a JIRA issue to INFRA. Regards, Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Apache Commons Statistics 1.0 based on RC1
FYI On Mon, 5 Dec 2022 at 00:46, Alex Herbert wrote: > I am wondering why the module page on the site I uploaded does not > render correctly. I have deployed the 1.0 release to the live site. The module page renders correctly: https://commons.apache.org/proper/commons-statistics/commons-statistics-distribution/index.html So the issue with staging the RC site to home.apache.org does not apply when staged to the commons.apache.org. Alex - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VOTE][RESULT] Release Apache Commons BCEL 6.7.0 based on RC1
This vote passes with the following binding +1 votes: - Bruno Kinoshita - Alex Herbert - Gary Gregory Gary On Tue, Dec 6, 2022 at 6:10 AM Gary Gregory wrote: > > My +1 > > Gary > > On Mon, Nov 28, 2022 at 12:13 PM Gary Gregory wrote: > > > > We have fixed a few bugs and added some enhancements since Apache > > Commons BCEL 6.6.1 was released, so I would like to release Apache > > Commons BCEL 6.7.0. > > > > Apache Commons BCEL 6.7.0 RC1 is available for review here: > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.7.0-RC1 (svn > > revision 58280) > > > > The Git tag commons-bcel-6.7.0-RC1 commit for this RC is > > 6fc2135e6b1dca14716287e72bf813cb209bdbbd which you can browse here: > > > > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=6fc2135e6b1dca14716287e72bf813cb209bdbbd > > You may checkout this tag using: > > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git > > --branch commons-bcel-6.7.0-RC1 commons-bcel-6.7.0-RC1 > > > > Maven artifacts are here: > > > > https://repository.apache.org/content/repositories/orgapachecommons-1608/org/apache/bcel/bcel/6.7.0/ > > > > These are the artifacts and their hashes: > > > > #Release SHA-512s > > #Mon Nov 28 12:01:26 EST 2022 > > Apache\ Commons\ > > BCEL-6.7.0.spdx.rdf.xml=e49b149ae8d6f1eb74da8cc82a6aed64530344f12034f6cbe26d36471929332c91df72ef4f4152c9555043494c148d174e16dd3c3eb0aff733d7da902a4d7688 > > bcel-6.7.0-bin.tar.gz=ad5286b1ff628007f7ff3f4fd5af6d859e93a86cf9a127c04e2e3ca2ebac5eb7dc65d7e1a431a588f303d37264c80334dee5ecfc7957f6b4892688f2a72859d6 > > bcel-6.7.0-bin.zip=65313338cf5911f06630d3083195e7e5fff358e6b39fda86f617bb5002ac49b9e9a4aae5f5bad610b402434aadd9db9ed61c492db9a40766044bd4615d1b4927 > > bcel-6.7.0-bom.json=3b34ce1343cfb84cd91cf8b3b6e099025e022cf2275db68ba0b4ed7ed8cbe5836ed755d2c2d47cba2379cf2620222a9925b34ed14d2279c649a4f6d9e305af9f > > bcel-6.7.0-bom.xml=a696e74e7b555b5a366e98b87c6801518756907a02731efb569d3536ed536c4f3b42a7d252e7f7992355d1b334ea58356b4f415d883dba35fa0767e026359bd5 > > bcel-6.7.0-javadoc.jar=c09f52ac63443a235508a8898949c226772c514e175851ec0cc6b182740069e463a89153b0bbbc7be67405e962e83db5738d2ca97881f3d92bfff196310ce5e5 > > bcel-6.7.0-sources.jar=cbb3d2feb83f2e78626822dc64235c02d619d5e13442b52e115748d5618af0f78868f4e29d16e577cb1c78653fab92ee9d8de1dd89777e03eb0f4941805cca0a > > bcel-6.7.0-src.tar.gz=71f0e227dbc558296f535507b3640ce4c91dddf12ef06502b5fca95b35510b02d09ca649f121427b4b47deb96c2edfe0de70999261cffbcbe170a835730096a0 > > bcel-6.7.0-src.zip=bb1d9763bbeaf5af228ed850727d4d8ca15963e6e68b0581d7b93111daceba64a5ca5036a7acce3d15073d77d511ecf32a6cc45bd40567ae5d46ba43b79c30c6 > > bcel-6.7.0-test-sources.jar=ca894df73511b4b06c2a9c876fec7f43cdbb13554b23be5af0b6e429a68e4f8e84faf1236c313166a4dbb62dba8768a47006c4a3e0cb5a5885b003eace07434c > > bcel-6.7.0-tests.jar=1ff0c0cd4191f7f21400bd9d2d2f1b98c11fd43bcfb0bcd9b4e9879cf781618877d04a568ae7b851920313a46f8b2902767e0f6a9dbfc3ff5128a650a4d69c75 > > > > I have tested this with 'mvn -V -Duser.name=$my_apache_id -Prelease > > -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using: > > > > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) > > Maven home: /usr/local/Cellar/maven/3.8.6/libexec > > Java version: 1.8.0_352, vendor: Homebrew, runtime: > > /usr/local/Cellar/openjdk@8/1.8.0+352/libexec/openjdk.jdk/Contents/Home/jre > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "mac os x", version: "13.0.1", arch: "x86_64", family: "mac" > > Darwin 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:54 > > PDT 2022; root:xnu-8792.41.9~2/RELEASE_X86_64 x86_64 > > > > Details of changes since 6.6.1 are in the release notes: > > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.7.0-RC1/RELEASE-NOTES.txt > > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.7.0-RC1/site/changes-report.html > > > > Site: > > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.7.0-RC1/site/index.html > > (note some *relative* links are broken and the 6.7.0 directories > > are not yet created - these will be OK once the site is deployed.) > > > > JApiCmp Report (compared to 6.6.1): > > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.7.0-RC1/site/japicmp.html > > > > RAT Report: > > > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.7.0-RC1/site/rat-report.html > > > > KEYS: > > https://downloads.apache.org/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
Re: [VOTE] Release Apache Commons BCEL 6.7.0 based on RC1
My +1 Gary On Mon, Nov 28, 2022 at 12:13 PM Gary Gregory wrote: > > We have fixed a few bugs and added some enhancements since Apache > Commons BCEL 6.6.1 was released, so I would like to release Apache > Commons BCEL 6.7.0. > > Apache Commons BCEL 6.7.0 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/bcel/6.7.0-RC1 (svn > revision 58280) > > The Git tag commons-bcel-6.7.0-RC1 commit for this RC is > 6fc2135e6b1dca14716287e72bf813cb209bdbbd which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-bcel.git;a=commit;h=6fc2135e6b1dca14716287e72bf813cb209bdbbd > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-bcel.git > --branch commons-bcel-6.7.0-RC1 commons-bcel-6.7.0-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1608/org/apache/bcel/bcel/6.7.0/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Mon Nov 28 12:01:26 EST 2022 > Apache\ Commons\ > BCEL-6.7.0.spdx.rdf.xml=e49b149ae8d6f1eb74da8cc82a6aed64530344f12034f6cbe26d36471929332c91df72ef4f4152c9555043494c148d174e16dd3c3eb0aff733d7da902a4d7688 > bcel-6.7.0-bin.tar.gz=ad5286b1ff628007f7ff3f4fd5af6d859e93a86cf9a127c04e2e3ca2ebac5eb7dc65d7e1a431a588f303d37264c80334dee5ecfc7957f6b4892688f2a72859d6 > bcel-6.7.0-bin.zip=65313338cf5911f06630d3083195e7e5fff358e6b39fda86f617bb5002ac49b9e9a4aae5f5bad610b402434aadd9db9ed61c492db9a40766044bd4615d1b4927 > bcel-6.7.0-bom.json=3b34ce1343cfb84cd91cf8b3b6e099025e022cf2275db68ba0b4ed7ed8cbe5836ed755d2c2d47cba2379cf2620222a9925b34ed14d2279c649a4f6d9e305af9f > bcel-6.7.0-bom.xml=a696e74e7b555b5a366e98b87c6801518756907a02731efb569d3536ed536c4f3b42a7d252e7f7992355d1b334ea58356b4f415d883dba35fa0767e026359bd5 > bcel-6.7.0-javadoc.jar=c09f52ac63443a235508a8898949c226772c514e175851ec0cc6b182740069e463a89153b0bbbc7be67405e962e83db5738d2ca97881f3d92bfff196310ce5e5 > bcel-6.7.0-sources.jar=cbb3d2feb83f2e78626822dc64235c02d619d5e13442b52e115748d5618af0f78868f4e29d16e577cb1c78653fab92ee9d8de1dd89777e03eb0f4941805cca0a > bcel-6.7.0-src.tar.gz=71f0e227dbc558296f535507b3640ce4c91dddf12ef06502b5fca95b35510b02d09ca649f121427b4b47deb96c2edfe0de70999261cffbcbe170a835730096a0 > bcel-6.7.0-src.zip=bb1d9763bbeaf5af228ed850727d4d8ca15963e6e68b0581d7b93111daceba64a5ca5036a7acce3d15073d77d511ecf32a6cc45bd40567ae5d46ba43b79c30c6 > bcel-6.7.0-test-sources.jar=ca894df73511b4b06c2a9c876fec7f43cdbb13554b23be5af0b6e429a68e4f8e84faf1236c313166a4dbb62dba8768a47006c4a3e0cb5a5885b003eace07434c > bcel-6.7.0-tests.jar=1ff0c0cd4191f7f21400bd9d2d2f1b98c11fd43bcfb0bcd9b4e9879cf781618877d04a568ae7b851920313a46f8b2902767e0f6a9dbfc3ff5128a650a4d69c75 > > I have tested this with 'mvn -V -Duser.name=$my_apache_id -Prelease > -Ptest-deploy -P jacoco -P japicmp clean package site deploy' using: > > Apache Maven 3.8.6 (84538c9988a25aec085021c365c560670ad80f63) > Maven home: /usr/local/Cellar/maven/3.8.6/libexec > Java version: 1.8.0_352, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@8/1.8.0+352/libexec/openjdk.jdk/Contents/Home/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "13.0.1", arch: "x86_64", family: "mac" > Darwin 22.1.0 Darwin Kernel Version 22.1.0: Sun Oct 9 20:14:54 > PDT 2022; root:xnu-8792.41.9~2/RELEASE_X86_64 x86_64 > > Details of changes since 6.6.1 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.7.0-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.7.0-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.7.0-RC1/site/index.html > (note some *relative* links are broken and the 6.7.0 directories > are not yet created - these will be OK once the site is deployed.) > > JApiCmp Report (compared to 6.6.1): > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.7.0-RC1/site/japicmp.html > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/bcel/6.7.0-RC1/site/rat-report.html > > KEYS: > https://downloads.apache.org/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-bcel.git > --branch commons-bcel-6.7.0-RC1 commons-bcel-6.7.0-RC1 > cd commons-bcel-6.7.0-RC1 > > 2) Check Apache licenses > > This
