Re: [VOTE] Release Apache Commons RNG 1.3 based on RC1

2019-11-05 Thread Gilles Sadowski 
Hi.

Le mar. 5 nov. 2019 à 17:36, Alex Herbert  a écrit :
>
> We have fixed quite a few bugs and added some significant enhancements
> since Apache Commons RNG 1.2 was released, so I would like to release
> Apache Commons RNG 1.3.
>
> Apache Commons RNG 1.3 RC1 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/
>https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/
>
> Tag name:
>RNG_1_3_RC1 (signature can be checked from git using 'git tag -v
> RNG_1_3_RC1')
>
> Tag URL:
> https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=43f290e68c31e5bea6cde97c7e999c2e1f2562b2
>
> Commit ID the tag points at:
>43f290e68c31e5bea6cde97c7e999c2e1f2562b2
>
> Maven artifacts are here:
> https://repository.apache.org/content/repositories/orgapachecommons-1476/org/apache/commons/
>
> These are the artifacts and their SHA 512 hashes:
> 310c0582b80c60fb159846f9615c7952b3c405265955392d77b16d7cfac9e8c5f2c680686e526b412ab8b4356ef9ecd07977764c31db8e02bef40e37b47ac27a
> commons-rng-1.0-bin.tar.gz
> e0247ea82aff57cc86ac904ae482c193b7edd5253d26f87fc590b50a738d5fa5c4a6b3b24cd6a48c459e18156ade2588d8c9d12c9a04d15570780240d29ef406
> commons-rng-1.0-bin.zip
> f33b922a9d8bc6098bd0e9a98859b17e1cdda21922f136b568868b21af274fdf3d78456a5c73c26c665205a22493836d59b1d33822c4a5c58e82ba64eadcb5e1
> commons-rng-1.0-src.tar.gz
> ef4fe63ebbd76e8d95b5f054fed76a40a85f5dd99ca2406a31fb95b593ed3d96b29389bf82424e18895192751689d7590404c8b1d90b28878271c79cad3be18b
> commons-rng-1.0-src.zip
>
> [...]
>
> Please review the release candidate and vote.
> This vote will close no sooner that 72 hours from now.
>
[X] +1 Release these artifacts
>[ ] +0 OK, but...
>[ ] -0 OK, but really should fix...
>[ ] -1 I oppose this release because...
>

Thanks,
Gilles

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[IO] Travis build fails due to missing package documentation

2019-11-05 Thread Rob Spoor 
See https://travis-ci.org/apache/commons-io/jobs/607784753. The reason 
is commit 14d6f4c6dbb429ebb915b530ea61fe911d36b20b, which added 
interface IOConsumer in package org.apache.commons.io.function, but 
forgot to add a package-info.java or package.html.


In case you're interested, you can possibly use something I wrote a 
while ago: https://github.com/robtimus/io-functions. This contains an 
almost identical IOConsumer plus a lot more copies of the interfaces in 
java.util.function.


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [IO] Don't deprecate IOUtils#closeQuietly()

2019-11-05 Thread David Mollitor 
Here is a discussion about this topic @ Guava.

https://github.com/google/guava/issues/1118

On Tue, Nov 5, 2019 at 1:14 PM Pascal Schumacher 
wrote:

> +1, for removing the deprecatio
>
> Am 05.11.2019 um 16:10 schrieb Gary Gregory:
> > Hi All:
> >
> > I propose that we do NOT deprecate IOUtils#closeQuietly(). There are
> > use-cases for this method outside of try-with-resources blocks.
> >
> > For example, I have some wrapper objects that contain Closeable objects.
> > When the wrapper is closed, I do and want to add calls to
> > IOUtils#closeQuietly() to avoid null checks in call sites.
> >
> > Gary
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [IO] Don't deprecate IOUtils#closeQuietly()

2019-11-05 Thread Pascal Schumacher 

+1, for removing the deprecatio

Am 05.11.2019 um 16:10 schrieb Gary Gregory:

Hi All:

I propose that we do NOT deprecate IOUtils#closeQuietly(). There are
use-cases for this method outside of try-with-resources blocks.

For example, I have some wrapper objects that contain Closeable objects.
When the wrapper is closed, I do and want to add calls to
IOUtils#closeQuietly() to avoid null checks in call sites.

Gary




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [IO] Don't deprecate IOUtils#closeQuietly()

2019-11-05 Thread Claude Warren 
+1 I have similar use cases.

On Tue, Nov 5, 2019 at 3:12 PM Gary Gregory  wrote:

> In this vein, I'd also like to add a null-safe close(Closeable) method.
>
> Gary
>
> On Tue, Nov 5, 2019 at 10:10 AM Gary Gregory 
> wrote:
>
> > Hi All:
> >
> > I propose that we do NOT deprecate IOUtils#closeQuietly(). There are
> > use-cases for this method outside of try-with-resources blocks.
> >
> > For example, I have some wrapper objects that contain Closeable objects.
> > When the wrapper is closed, I do and want to add calls to
> > IOUtils#closeQuietly() to avoid null checks in call sites.
> >
> > Gary
> >
>


-- 
I like: Like Like - The likeliest place on the web

LinkedIn: http://www.linkedin.com/in/claudewarren

Re: [Numbers] Arrays of "Complex" objects and RAM

2019-11-05 Thread Alex Herbert 

On 05/11/2019 00:09, Eric Barnhill wrote:

That's interesting. The JTransforms library performs Fourier transforms
that can take complex input, output, or both. They do this with interleaved
double[] arrays, which I suppose is much more space efficient, and the
status of a number as real or imaginary is implicit by its location being
odd or even.


The packing of multi-dimensional structures into a single array is 
common in image processing. It has computational efficiency when 
operating on the entire set of numbers.


It is used a lot in image processing to pack 2D data as a single array. 
In this case even random access to the (x,y) index as:


2D: [x][y]
1D: [y * maxx + x]

is comparable in speed as the later avoids the second array dereference.

A single array has advantages for a copy operation as it requires a 
single .clone() method call. The disadvantage is that the ultimate size 
of the multi-dimension array is limited by the size of an array.


In the case of complex numbers the use of alternating indices to store 
real and imaginary allows the array to be easily resized and extended. 
Operations that process all positions only need to cache in memory a 
sub-section of the array.


[re1, im1, re2, im2, re3, im3]

The alternative is to store real and imaginary in a large block in 
either 1 array or 2 arrays:


[re1, re2, re3, im1, im2, im3]

[re1, re2, re3]
[im1, im2, im3]

This has advantages for operations that require either the real or the 
imaginary components on their own. It is a bit more work to extend the 
data as it requires two copies of the existing data and packing of the 
new values as the appropriate position.


For small sizes the use of 2 arrays this would be less efficient memory 
wise. It would require some type of pointer to hold the pair. However it 
could store double the amount of complex numbers.


The MultidimensionalCounter functionality you mention is for example known
in Matlab as ind2sub() and sub2ind() . It allows for 1d vectorizing of
certain functions which can improve performance. Some people swear by it. I
always found it an additional mental exercise that I didn't want to occupy
myself with unless I absolutely had to. So, maybe it makes sense to
"advertise" this approach like you say, but some users may just want the 3D
arrays for more rapid prototyping-ish applications.

I wonder if there isn't some streaming solution for this -- the numbers are
stored as an interleaved 1D array, but are streamed through a Complex
constructor before any needed operations are performed.


My initial thought is not as double values. A DoubleStream processes 
single values. To collect the real and imaginary components would 
require that the stream can be processed two at a time.


This structure would work:

class ComplexArray {
// Must be even in length. Packed as (real, imaginary)
    double[] data;
int size;

    Stream stream() {
    return IntStream.range(0, size / 2)
    .mapToObj(i -> Complex.ofCartesian(data[i*2], 
data[i*2+1]));
    }

void add(Complex c) {
checkCapacity(2);
data[size++] = c.getReal();
data[size++] = c.getImaginary();
}

void combine(ComplexArray c) {
checkCapacity(c.size);
System.arraycopy(c.data, 0, data, size, c.size);
size += c.size;
}

private void checkCapacity(int length) {
final int minCapacity = size + length;
final int oldCapacity = data.length;
if (minCapacity > oldCapacity) {
int newCapacity = ((oldCapacity * 3) >>> 1) + 1;
if (newCapacity < minCapacity) {
newCapacity = minCapacity;
}
data = Arrays.copyOf(data, newCapacity);
}
}
}



And I guess that leads to my last question -- suppose someone wants to call
a trig function on a series of Complex numbers. Now let's imagine the
primitives have been stored in some maximally efficient way. It seems like,
to use any of the functionality in Complex, these numbers would have to be
unpacked, cast as Complex, operated on, then cast back to how they are
being stored. I wonder if that would prove to be more efficient in the end.


Probably not more efficient to create all the Complex instances. Ideally 
you would operate on the primitive data directly.


Looking at what Complex is capable of doing it seems that there are a 
lot of operations that would have to be duplicated to allow operations 
to work on primitives. However you can create the API and implement it 
lazily using the above object, e.g.


public static ComplexArray apply(ComplexArray array, UnaryOperator 
mapper) {
return array.stream()
.map(mapper)
.collect(ComplexArray::new, ComplexArray::add, 
ComplexArray::combine);
}

public static ComplexArray log(ComplexArray array) {
return apply(Complex::log);
}

This does create a new Complex object for each operation function 
applied to the data.


The

Survey about the Relevance of Open Source Research

2019-11-05 Thread Edna Dias Canedo 
Dear all,

I'm conducting a Survey about the Relevance of Open Source Research as part
of my Bachelor’s dissertation in Computer Science at the University Of
Brasília (Brazil) and I kindly ask you to participate in it.

The study aims at identifying, through a systematic literature mapping,
works on the Software Engineering literature that are focused on the Open
Source model, and latter conduct the present Survey with developers and
researchers that are related to the Open Source Community. This is done in
an attempt to gather a set of works that is able to give an overview of the
variety of available results in the literature and investigate its
perceived relevance to the Open Source community.

https://forms.gle/kTYJjg1Brk2kgpsf8
-- 
Professor PhD Edna Dias Canedo
Homepage: https://cic.unb.br/~ednacanedo/
Department of Computer Science
University of Brasília (UnB), Campus Darcy Ribeiro, Brasília-DF, Brazil

[VOTE] Release Apache Commons RNG 1.3 based on RC1

2019-11-05 Thread Alex Herbert 
We have fixed quite a few bugs and added some significant enhancements 
since Apache Commons RNG 1.2 was released, so I would like to release 
Apache Commons RNG 1.3.


Apache Commons RNG 1.3 RC1 is available for review here:
  https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/
  https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/

Tag name:
  RNG_1_3_RC1 (signature can be checked from git using 'git tag -v 
RNG_1_3_RC1')


Tag URL:
https://gitbox.apache.org/repos/asf?p=commons-rng.git;a=commit;h=43f290e68c31e5bea6cde97c7e999c2e1f2562b2

Commit ID the tag points at:
  43f290e68c31e5bea6cde97c7e999c2e1f2562b2

Maven artifacts are here:
https://repository.apache.org/content/repositories/orgapachecommons-1476/org/apache/commons/

These are the artifacts and their SHA 512 hashes:
310c0582b80c60fb159846f9615c7952b3c405265955392d77b16d7cfac9e8c5f2c680686e526b412ab8b4356ef9ecd07977764c31db8e02bef40e37b47ac27a 
commons-rng-1.0-bin.tar.gz
e0247ea82aff57cc86ac904ae482c193b7edd5253d26f87fc590b50a738d5fa5c4a6b3b24cd6a48c459e18156ade2588d8c9d12c9a04d15570780240d29ef406 
commons-rng-1.0-bin.zip
f33b922a9d8bc6098bd0e9a98859b17e1cdda21922f136b568868b21af274fdf3d78456a5c73c26c665205a22493836d59b1d33822c4a5c58e82ba64eadcb5e1 
commons-rng-1.0-src.tar.gz
ef4fe63ebbd76e8d95b5f054fed76a40a85f5dd99ca2406a31fb95b593ed3d96b29389bf82424e18895192751689d7590404c8b1d90b28878271c79cad3be18b 
commons-rng-1.0-src.zip


The source code contains examples that are not part of the public API. 
These examples contain Java 9 modules and are enabled using a profile 
(see below).


An error when building the Java 9 modules site/javadoc under JDK 11 is a 
known issue as the javadoc command errors when documenting Java 9 
modules that include code from the unamed module.


Note: Testing randomness using statistical thresholds results in 
failures at a given probability. The 'maven-surefire-plugin' is 
configured to re-run tests that fail, and pass the build if they succeed 
within the allotted number of reruns (the test will be marked as 'flaky' 
in the report).


I have tested this with:

'mvn clean install site' using:

***
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T19:41:47+01:00)

Maven home: /usr/local/apache-maven-3.6.0
Java version: 1.8.0_222, vendor: Private Build, runtime: 
/usr/lib/jvm/java-8-openjdk-amd64/jre

Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
"unix"

***

***
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T19:41:47+01:00)

Maven home: /usr/local/apache-maven-3.6.0
Java version: 11.0.5, vendor: AdoptOpenJDK, runtime: 
/usr/lib/jvm/jdk-11.0.5+10

Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
"unix"

***

Java 9 modules in the examples modules.

'mvn -Pcommons-rng-examples clean install site' using:

***
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T19:41:47+01:00)

Maven home: /usr/local/apache-maven-3.6.0
Java version: 9, vendor: Oracle Corporation, runtime: /usr/lib/jvm/jdk-9
Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
"unix"

***

'mvn -Pcommons-rng-examples clean install' using:

***
Apache Maven 3.6.0 (97c98ec64a1fdfee7767ce5ffb20918da4f719f3; 
2018-10-24T19:41:47+01:00)

Maven home: /usr/local/apache-maven-3.6.0
Java version: 11.0.5, vendor: AdoptOpenJDK, runtime: 
/usr/lib/jvm/jdk-11.0.5+10

Default locale: en_GB, platform encoding: UTF-8
OS name: "linux", version: "4.4.0-166-generic", arch: "amd64", family: 
"unix"

***

Details of changes since 1.2 are in the release notes:
https://dist.apache.org/repos/dist/dev/commons/rng/1.3-RC1/RELEASE-NOTES.txt
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/changes-report.html

Site:
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/index.html
    (note some *relative* links are broken and the 1.3 directories are 
not yet created - these will be OK once the site is deployed.)


CLIRR Report (compared to 1.2):
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-client-api/clirr-report.html
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-core/clirr-report.html
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-simple/clirr-report.html
https://home.apache.org/~aherbert/commons-rng-1.3-RC1-site/commons-rng-sampling/clirr-report.html

RAT Report:
https://home.apache.org/~aherbert/commons-rng-1.3-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 that 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,

Alex Herbert,
Release Manager (using key

Re: [IO] Don't deprecate IOUtils#closeQuietly()

2019-11-05 Thread Gary Gregory 
In this vein, I'd also like to add a null-safe close(Closeable) method.

Gary

On Tue, Nov 5, 2019 at 10:10 AM Gary Gregory  wrote:

> Hi All:
>
> I propose that we do NOT deprecate IOUtils#closeQuietly(). There are
> use-cases for this method outside of try-with-resources blocks.
>
> For example, I have some wrapper objects that contain Closeable objects.
> When the wrapper is closed, I do and want to add calls to
> IOUtils#closeQuietly() to avoid null checks in call sites.
>
> Gary
>

[IO] Don't deprecate IOUtils#closeQuietly()

2019-11-05 Thread Gary Gregory 
Hi All:

I propose that we do NOT deprecate IOUtils#closeQuietly(). There are
use-cases for this method outside of try-with-resources blocks.

For example, I have some wrapper objects that contain Closeable objects.
When the wrapper is closed, I do and want to add calls to
IOUtils#closeQuietly() to avoid null checks in call sites.

Gary

Re: [commons-rng] branch master updated: Jira report to contain 'Implemented' resolution.

2019-11-05 Thread Alex Herbert 



On 05/11/2019 14:33, Gilles Sadowski wrote:

Hi Alex.

Le mar. 5 nov. 2019 à 13:54,  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


The following commit(s) were added to refs/heads/master by this push:
  new 76b6fee  Jira report to contain 'Implemented' resolution.
76b6fee is described below

commit 76b6feea6ae7739a8eb89ad5877f6336679e4028
Author: aherbert 
AuthorDate: Tue Nov 5 12:53:42 2019 +

 Jira report to contain 'Implemented' resolution.
---
  pom.xml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/pom.xml b/pom.xml
index 8b2b1bb..22e31f0 100644
--- a/pom.xml
+++ b/pom.xml
@@ -296,7 +296,7 @@
Fix 
Version,Key,Component,Summary,Type,Resolution,Status

Fix Version DESC,Type,Key DESC
-  Fixed
+  Fixed,Implemented

Thanks for spotting this.
However, some issues have been tagged as "Done".


I was checking the site for the RC and found a lot of Jira tickets were 
missing or without a fix version. So I've included the Implemented ones 
and updated some of the very old tickets to have a fix version of 1.0.


Looking at all the tickets with Done as the resolution it seemed that 
they were tasks [1]. However I've just spotted these that added new code 
to the API:


RNG-69 - GeometricSampler [2]

RNG-39 - UnitSphereRandomSampler [3]

At the moment I think it better to change these to Implemented and 
rebuild the website for RC1 rather than rerolling again. I was just 
about to send out the VOTE e-mail. If I update Jira then I wont have to 
redeploy the Nexus artifacts.



[1] 
https://issues.apache.org/jira/browse/RNG-64?jql=project%20%3D%20RNG%20%20and%20resolution%20%3D%20Done%20


[2] https://issues.apache.org/jira/browse/RNG-69

[3] https://issues.apache.org/jira/browse/RNG-39



Regards,
Gilles


Resolved,Closed

Bug,New Feature,Task,Improvement,Wish,Test


-
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: [commons-rng] branch master updated: Jira report to contain 'Implemented' resolution.

2019-11-05 Thread Gilles Sadowski 
Hi Alex.

Le mar. 5 nov. 2019 à 13:54,  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
>
>
> The following commit(s) were added to refs/heads/master by this push:
>  new 76b6fee  Jira report to contain 'Implemented' resolution.
> 76b6fee is described below
>
> commit 76b6feea6ae7739a8eb89ad5877f6336679e4028
> Author: aherbert 
> AuthorDate: Tue Nov 5 12:53:42 2019 +
>
> Jira report to contain 'Implemented' resolution.
> ---
>  pom.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/pom.xml b/pom.xml
> index 8b2b1bb..22e31f0 100644
> --- a/pom.xml
> +++ b/pom.xml
> @@ -296,7 +296,7 @@
>Fix 
> Version,Key,Component,Summary,Type,Resolution,Status
>
>Fix Version DESC,Type,Key DESC
> -  Fixed
> +  Fixed,Implemented

Thanks for spotting this.
However, some issues have been tagged as "Done".

Regards,
Gilles

>Resolved,Closed
>
>Bug,New Feature,Task,Improvement,Wish,Test
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Fwd: [commons-rng] annotated tag RNG_1_3_RC2 created (now a670c77)

2019-11-05 Thread Gary Gregory 
There is no need to burn a RC number unless a vote has been called.

Gary

-- Forwarded message -
From: 
Date: Tue, Nov 5, 2019, 05:52
Subject: [commons-rng] annotated tag RNG_1_3_RC2 created (now a670c77)
To: comm...@commons.apache.org 


This is an automated email from the ASF dual-hosted git repository.

aherbert pushed a change to annotated tag RNG_1_3_RC2
in repository https://gitbox.apache.org/repos/asf/commons-rng.git.


  at a670c77  (tag)
 tagging e934ddea986fe7551c72fdb42bea52c605c987ac (commit)
 replaces RNG_1_3_RC1
  by aherbert
  on Tue Nov 5 10:50:20 2019 +

- Log -
RC2.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAABAgAGBQJdwVPsAAoJECGTn/DKKmVn968P/RKGtWraq5ErRSJ652YHArMZ
h9ZtQ3k4068UEzExeBkeqle6HM1Oyv1urioy8o4ySsg52pLrgY9Xg0ZnlTU/yNDy
d1P2oqq9sn0CkBmgQabZU4ILv8IUgsslYC5iKzjyh+MbXlBFemaSUu3G2ONNr8hw
Dt3f1IpF48N5IlTKSyHOVBPHCHpjvsNd1zDufGVamZkQOOVbyn+WqbhN4bOzz6QJ
OJMPinocLycHYxiICaXnHZliHWYbZ2FwDAIuhcB5CjexgEOvH06Lk82kv2iQ/Vlk
WtOK74R7be9Iga32rSAlqhHmWNdj34J+qHESgb6rs02JklpsKvRege883VvtIgu3
8ljBnqaRxRK/WGaRMPWWYWoHBNdKVXdOc1v21Icte87H3xmDxe4mTHHXbOHhCZ0l
YUFaFNmqy3sx06vZy2iEe+Y8UrZrdFZyIeZn28UqYikpOG5FmX3foqncoaPHkGg2
BjvvrQNzwutqBCL7W0/UNBlJtb1Zg7eoT4G6W8pZ4QWAzy+SVSOdyb6DJkRYRib+
aIdWGhhp+Tb5L83K2V9FZ9JZJ7dQSb4MX+w9kzOiyqQw7ANWIYZNsFqdCFDvYOul
e2uzKzlaRnVLaWe0qwwBooAbdrSDbmLLPSkVH+hY8oP16FALr9V6wcMVh/k7SXzT
KR+ud5yWOeggeaLXF5HM
=3DSO
-END PGP SIGNATURE-
---

No new revisions were added by this update.

Re: [commons-rng] annotated tag RNG_1_3_RC2 created (now a670c77)

2019-11-05 Thread Gilles Sadowski 
Hi.

What happened to RC1?

Regards,
Gilles

Le mar. 5 nov. 2019 à 11:52,  a écrit :
>
> This is an automated email from the ASF dual-hosted git repository.
>
> aherbert pushed a change to annotated tag RNG_1_3_RC2
> in repository https://gitbox.apache.org/repos/asf/commons-rng.git.
>
>
>   at a670c77  (tag)
>  tagging e934ddea986fe7551c72fdb42bea52c605c987ac (commit)
>  replaces RNG_1_3_RC1
>   by aherbert
>   on Tue Nov 5 10:50:20 2019 +
>
> - Log -
> RC2.
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQIcBAABAgAGBQJdwVPsAAoJECGTn/DKKmVn968P/RKGtWraq5ErRSJ652YHArMZ
> h9ZtQ3k4068UEzExeBkeqle6HM1Oyv1urioy8o4ySsg52pLrgY9Xg0ZnlTU/yNDy
> d1P2oqq9sn0CkBmgQabZU4ILv8IUgsslYC5iKzjyh+MbXlBFemaSUu3G2ONNr8hw
> Dt3f1IpF48N5IlTKSyHOVBPHCHpjvsNd1zDufGVamZkQOOVbyn+WqbhN4bOzz6QJ
> OJMPinocLycHYxiICaXnHZliHWYbZ2FwDAIuhcB5CjexgEOvH06Lk82kv2iQ/Vlk
> WtOK74R7be9Iga32rSAlqhHmWNdj34J+qHESgb6rs02JklpsKvRege883VvtIgu3
> 8ljBnqaRxRK/WGaRMPWWYWoHBNdKVXdOc1v21Icte87H3xmDxe4mTHHXbOHhCZ0l
> YUFaFNmqy3sx06vZy2iEe+Y8UrZrdFZyIeZn28UqYikpOG5FmX3foqncoaPHkGg2
> BjvvrQNzwutqBCL7W0/UNBlJtb1Zg7eoT4G6W8pZ4QWAzy+SVSOdyb6DJkRYRib+
> aIdWGhhp+Tb5L83K2V9FZ9JZJ7dQSb4MX+w9kzOiyqQw7ANWIYZNsFqdCFDvYOul
> e2uzKzlaRnVLaWe0qwwBooAbdrSDbmLLPSkVH+hY8oP16FALr9V6wcMVh/k7SXzT
> KR+ud5yWOeggeaLXF5HM
> =3DSO
> -END PGP SIGNATURE-
> ---
>
> No new revisions were added by this update.
>

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org