Re: [Math] Clarification of development model with Git

[luc]

Le 2016-04-21 02:39, Gilles a écrit :

On Wed, 20 Apr 2016 18:14:33 +0100, sebb wrote:
On 20 April 2016 at 02:55, Gilles <gil...@harfang.homelinux.org> 
wrote:

Hello.

Let's assume the following:
* Some feature branch has been pushed to the Apache repository.
* That branch fixes an issue reported in JIRA.


Has the JIRA been updated with the details of the code push?


Whenever code was available, I indicated it with a comment on the
corresponding JIRA page; and all comments generate a post to this
list.


* Nobody has raised an objection after some time[1] has passed.

Can we conclude that the code in that branch has been (lazily)
accepted and can be merged into "develop"?[2]


If you are not sure, why not send an email round asking about the
specific commits?


Done.

But the question is: How long should one wait for review (in C-T⁻R
policy)?


I think you can safely consider that the recent development
can be integrated as you want.


best regards,
Luc



A similar situation is: When I post a message on the ML, asking
whether there are objections to some proposed work, how long should
I wait before implementing the suggested solution?
Example:
  http://markmail.org/thread/ywdfvyq6hmbaje6u


Regards,
Gilles


[1] What would be reasonable value for the time span?
[2] So that other issues that depend on that code can be worked
on.




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


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

Re: [VOTE] Release Configuration 2.0 based on RC1

[Luc Maisonobe]

Le 20/03/2016 22:42, Oliver Heger a écrit :
> Hi all,
> 
> after a series of alpha and beta releases, I think we are now ready to
> release the final 2.0 version of [configuration]. So this is the
> corresponding release vote.
> 
> Configuration 2.0 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/configuration
> (revision 12797)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1143
> 
> Details of changes since 1.10 and the previous beta version are in the
> release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/configuration/RELEASE-NOTES.txt
> 
> https://home.apache.org/~oheger/configuration-2.0-rc1/changes-report.html
> 
> Here is the tag:
> 
> http://svn.apache.org/repos/asf/commons/proper/configuration/tags/CONFIGURATION_2_0_RC1
> (revision 1735904)
> 
> Site:
>https://home.apache.org/~oheger/configuration-2.0-rc1/
> (note some links in the menu are not yet working)
> 
> KEYS:
>   http://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> This vote will close no sooner than 72 hours from now, i.e. after 2200
> GMT 23-Mar 2016
> 
>   [X] +1 Release these artifacts

Luc

>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thanks!
> Oliver
> 
> 
> 
> -
> 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: [math] Fwd: Please add your release data for 'commons'

[Luc Maisonobe]

Le 21/03/2016 13:54, Evan Ward a écrit :
> Hi,
> 
> Can a Math PMC member add our release data to the database? I don't have
> the necessary permissions.

Now that we have 3 PMC, I have updated the database.
You can continue with the process.

best regards,
Luc

> 
> Thanks,
> Evan
> 
> 
>  Forwarded Message 
> Subject:  Please add your release data for 'commons'
> Date: Mon, 21 Mar 2016 12:48:51 +
> From: Apache Reporter Service <no-re...@reporter.apache.org>
> Reply-To: d...@community.apache.org
> To:   evanward <evanw...@apache.org>
> 
> 
> 
> Hi,
> This is an automated email from reporter.apache.org.
> I see that you just pushed something to our release repository for the 
> 'commons' project
> in the following commit:
> 
> r12800 at 2016-03-21 12:48:37 + (Mon, 21 Mar 2016)
> Publish commons-math 3.6.1 Release
> 
> If you are a PMC member of this project, we ask that you log on to:
> https://reporter.apache.org/addrelease.html?commons
> and add your release data (version and date) to the database.
> 
> If you are not a PMC member, please have a PMC member add this information.
> 
> While this is not a requirement, we ask that you still add this data to the
> reporter database, so that people using the Apache Reporter Service will be
> able to see the latest release data for this project.
> 
> With regards,
> The Apache Reporter Service.
> 
> 
> 
> 
> 


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

Re: [VOTE][RRESULT][RC1] Release Commons Math 3.6.1

[Luc Maisonobe]

Le 21/03/2016 16:42, Gilles a écrit :
> On Mon, 21 Mar 2016 10:29:48 -0400, Evan Ward wrote:
>> On 03/21/2016 09:18 AM, Luc Maisonobe wrote:
>>> Le 21/03/2016 13:44, Evan Ward a écrit :
>>>> The vote passes with three votes in favor and none against.
>>> Well, in fact I am not sure it passes yet ...
>>>
>>> As far as I know, there are only 2 PMC members who voted: Oliver and
>>> myself.
>>
>> Oh, I didn't realize there had to be 3 PMC members voting. I had already
>> released the maven artifacts by the time I receive your message. I'll
>> wait to publish the site until we have a vote from a third PMC member.
>> Hopefully it is a +1 so I don't have to figure out how to un-release
>> something. I'll update the release.howto.txt document to include a note
>> that a vote must have 3 PMC +1's to pass.
> 
> I'll vote
> 
> +1

Thanks a lot.

best regards,
Luc

> 
> although I do not have the time to make all the "legal" steps.
> It's a leap of faith because I trust that you (and Luc) take extreme care
> in what you do.
> 
> This kind of trust is sorely missing in other circumstances.
> 
> Also, concretely, I think that the requirements could be relaxed for a
> bug-fix release.
> 
> Regards,
> Gilles
> 
>> Best Regards,
>> Evan
>>
>>>
>>> Could a third PMC member look at it?
>>>
>>> best regards,
>>> Luc
>>>
>>>> Thanks for taking time to review.
>>>>
>>>> Best Regards,
>>>> Evan
>>>>
>>>> On 03/19/2016 11:06 PM, Matt Sicker wrote:
>>>>> If you add the -Xdoclint:none command line argument, that will
>>>>> ignore the
>>>>> javadoc errors. I love how the JDK itself doesn't compile without that
>>>>> option.
>>>>>
>>>>> On 19 March 2016 at 15:38, Oliver Heger <oliver.he...@oliver-heger.de>
>>>>> wrote:
>>>>>
>>>>>> Build worked fine with Java 1.6 on Windows 10. Artifacts and site
>>>>>> look
>>>>>> good. I could not build the site with Java 8 because of Javadoc
>>>>>> errors,
>>>>>> but this is not blocking.
>>>>>>
>>>>>> So +1
>>>>>>
>>>>>> Oliver
>>>>>>
>>>>>> Am 17.03.2016 um 20:06 schrieb Evan Ward:
>>>>>>> This is a [VOTE] for releasing Apache Commons Math 3.6.1 from
>>>>>>> release
>>>>>>> candidate 1.
>>>>>>>
>>>>>>> Tag name:
>>>>>>>   MATH_3_6_1_RC1 (signature can be checked from git using 'git
>>>>>>> tag -v')
>>>>>>>
>>>>>>> Tag URL:
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=tag;h=e40b144832c0e138b185c92326588a087e00909c
>>>>>>
>>>>>>> Commit ID the tag points at:
>>>>>>>   16abfe5de688cc52fb0396e0609cb33044b15653
>>>>>>>
>>>>>>> Site:
>>>>>>>   http://home.apache.org/~evanward/commons-math-3.6.1-RC1-site
>>>>>>>
>>>>>>> Distribution files:
>>>>>>>   https://dist.apache.org/repos/dist/dev/commons/math/
>>>>>>>
>>>>>>> Distribution files hashes (SHA1):
>>>>>>>   4d4bb6741f9b5d095bcab24f5232a871ba579df0
>>>>>> commons-math3-3.6.1-bin.tar.gz
>>>>>>>   e088b160c19af7ca2596d91430b8a71aaa5ea5da 
>>>>>>> commons-math3-3.6.1-bin.zip
>>>>>>>   77ffe792e4bf0d4bcd7b4e2a8ce3b07df40a92b9
>>>>>> commons-math3-3.6.1-src.tar.gz
>>>>>>>   cadad1cbb7757b2616a96b20d357e3a6acb1b4c9 
>>>>>>> commons-math3-3.6.1-src.zip
>>>>>>>
>>>>>>> KEYS file to check signatures:
>>>>>>>   http://www.apache.org/dist/commons/KEYS
>>>>>>>
>>>>>>> Maven artifacts:
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> https://repository.apache.org/content/repositories/orgapachecommons-1142/org/apache/commons/commons-math3/3.6.1/
>>>>>>
>>>>>>> [ ] +1 Release it.
>>>>>>> [ ] +0 Go ahead; I don't care.
>>>>>>> [ ] -0 There are a few minor glitches: ...
>>>>>>> [ ] -1 No, do not release it because ...
>>>>>>>
>>>>>>> This vote will close in 72 hours, at 2016-03-20T12:00:00Z (this
>>>>>>> is UTC
>>>>>>> time).
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Evan
>>>>>>>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


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

Re: [VOTE][RRESULT][RC1] Release Commons Math 3.6.1

[Luc Maisonobe]

Le 21/03/2016 13:44, Evan Ward a écrit :
> The vote passes with three votes in favor and none against.

Well, in fact I am not sure it passes yet ...

As far as I know, there are only 2 PMC members who voted: Oliver and myself.

Could a third PMC member look at it?

best regards,
Luc

> 
> Thanks for taking time to review.
> 
> Best Regards,
> Evan
> 
> On 03/19/2016 11:06 PM, Matt Sicker wrote:
>> If you add the -Xdoclint:none command line argument, that will ignore the
>> javadoc errors. I love how the JDK itself doesn't compile without that
>> option.
>>
>> On 19 March 2016 at 15:38, Oliver Heger <oliver.he...@oliver-heger.de>
>> wrote:
>>
>>> Build worked fine with Java 1.6 on Windows 10. Artifacts and site look
>>> good. I could not build the site with Java 8 because of Javadoc errors,
>>> but this is not blocking.
>>>
>>> So +1
>>>
>>> Oliver
>>>
>>> Am 17.03.2016 um 20:06 schrieb Evan Ward:
>>>> This is a [VOTE] for releasing Apache Commons Math 3.6.1 from release
>>>> candidate 1.
>>>>
>>>> Tag name:
>>>>   MATH_3_6_1_RC1 (signature can be checked from git using 'git tag -v')
>>>>
>>>> Tag URL:
>>>>
>>>>
>>> https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=tag;h=e40b144832c0e138b185c92326588a087e00909c
>>>> Commit ID the tag points at:
>>>>   16abfe5de688cc52fb0396e0609cb33044b15653
>>>>
>>>> Site:
>>>>   http://home.apache.org/~evanward/commons-math-3.6.1-RC1-site
>>>>
>>>> Distribution files:
>>>>   https://dist.apache.org/repos/dist/dev/commons/math/
>>>>
>>>> Distribution files hashes (SHA1):
>>>>   4d4bb6741f9b5d095bcab24f5232a871ba579df0
>>> commons-math3-3.6.1-bin.tar.gz
>>>>   e088b160c19af7ca2596d91430b8a71aaa5ea5da  commons-math3-3.6.1-bin.zip
>>>>   77ffe792e4bf0d4bcd7b4e2a8ce3b07df40a92b9
>>> commons-math3-3.6.1-src.tar.gz
>>>>   cadad1cbb7757b2616a96b20d357e3a6acb1b4c9  commons-math3-3.6.1-src.zip
>>>>
>>>> KEYS file to check signatures:
>>>>   http://www.apache.org/dist/commons/KEYS
>>>>
>>>> Maven artifacts:
>>>>
>>>>
>>> https://repository.apache.org/content/repositories/orgapachecommons-1142/org/apache/commons/commons-math3/3.6.1/
>>>> [ ] +1 Release it.
>>>> [ ] +0 Go ahead; I don't care.
>>>> [ ] -0 There are a few minor glitches: ...
>>>> [ ] -1 No, do not release it because ...
>>>>
>>>> This vote will close in 72 hours, at 2016-03-20T12:00:00Z (this is UTC
>>>> time).
>>>>
>>>> Best Regards,
>>>> Evan
>>>>
>>> -
>>> 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: [VOTE] Accept Chimera as new Apache Commons Component

[Luc Maisonobe]

+1 for new component.

Luc

Le 21/03/2016 09:57, Bernd Eckenfels a écrit :
> +1 Accept Chimera as new Apache Commons Component
> 
> 
> Gruss
> Bernd
> 
> Von: Benedikt Ritter
> Gesendet: Montag, 21. März 2016 09:45
> An: Commons Developers List
> Cc: Hadoop Common
> Betreff: [VOTE] Accept Chimera as new Apache Commons Component
> 
> Hi all,
> 
> after long discussions I think we have gathered enough information to
> decide whether we want to accept the Chimera project as a new Apache
> Commons component.
> 
> Proposed name: Apache Commons Crypto
> Proposal text:
> https://github.com/intel-hadoop/chimera/blob/master/PROPOSAL.html
> Initial Code Base:  https://github.com/intel-hadoop/chimera/
> Initial Committers (Names in alphabetical order):
> - Aaron T. Myers (a...@apache.org, Apache Hadoop PMC, one of the original
> Crypto dev team in Apache Hadoop)
> - Andrew Wang (w...@apache.org, Apache Hadoop PMC, one of the original
> Crypto dev team in Apache Hadoop)
> - Chris Nauroth (cnaur...@apache.org, Apache Hadoop PMC and active
> reviewer)
> - Colin P. McCabe (cmcc...@apache.org, Apache Hadoop PMC, one of the
> original Crypto dev team in Apache Hadoop)
> - Dapeng Sun (s...@apache.org, Apache Sentry Committer, Chimera contributor)
> - Dian Fu (dia...@apache.org, Apache Sqoop Committer, Chimera contributor)
> - Dong Chen (do...@apache.org, Apache Hive Committer,interested on Chimera)
> - Ferdinand Xu (x...@apache.org, Apache Hive Committer, Chimera contributor)
> - Haifeng Chen (haifengc...@apache.org, Chimera lead and code contributor)
> - Marcelo Vanzin (Apache Spark Committer, Chimera contributor)
> - Uma Maheswara Rao G (umamah...@apache.org, Apache Hadoop PMC, One of the
> original Crypto dev/review team in Apache Hadoop)
> - Yi Liu (y...@apache.org, Apache Hadoop PMC, One of the original Crypto
> dev/review team in Apache Hadoop)
> 
> Please review the proposal and vote.
> This vote will close no sooner than 72 hours from now, i.e. after 0900
> GMT 24-Mar 2016
> 
>   [ ] +1 Accept Chimera as new Apache Commons Component
>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this because...
> 
> Thank you!
> Benedikt
> 
> 


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

Re: [math] Fix for MATH-1342

[luc]

Le 2016-03-16 20:13, Evan Ward a écrit :

Hi,


Hi Evan,



First, I'm trying to use the new branching strategy so I would
appreciate your patience if I'm not doing correctly.

I've commited a fix for MATH-1342 in commit 7a8dc00. This is a problem
with event detection in all ODE integrators. So if the list approves I
would like to merge this into the develop branch.


I have reviewed your fix and agrees with it (you know how this part of
the code is important to me!).

However, you have put the fix on a branch related to master, not to
MATH_3_X.



I would also like to create a bug fix release on the math3 branch for
this bug.


+1 from me, but the fix should be ported to MATH_3_X in this case.
As it would be a relase fixing only 3 bugs (counting MATH-1316 and
MATH-1317 fixed two months ago just after 3.6 release, it should
probably be numbered 3.6.1.


I have a commit that I've ported to that branch that I can
push up, if that is the right way to do it. I can also volunteer to do
the release, but I've never done a release before so someone may have 
to

help me through it.


I have performed the last releases. The main document is the one in
the [math] project itself, in file doc/release/release.howto.txt. I
think it has been updated for the last two releases, so it should be
fairly accurate by now.

Prior to the release, you should upload a GPG key in the general file
holding all release managers keys for commons, see step 10 of the
procedure, that in fact should rather be step 0.

best regards,
Luc



Best Regards,
Evan


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


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

Re: [VOTE][RC1] Release Commons Math 3.6.1

[Luc Maisonobe]

Le 17/03/2016 20:06, Evan Ward a écrit :
> This is a [VOTE] for releasing Apache Commons Math 3.6.1 from release
> candidate 1.
> 
> Tag name:
>   MATH_3_6_1_RC1 (signature can be checked from git using 'git tag -v')
> 
> Tag URL:
>  
> https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=tag;h=e40b144832c0e138b185c92326588a087e00909c
> 
> Commit ID the tag points at:
>   16abfe5de688cc52fb0396e0609cb33044b15653
> 
> Site:
>   http://home.apache.org/~evanward/commons-math-3.6.1-RC1-site
> 
> Distribution files:
>   https://dist.apache.org/repos/dist/dev/commons/math/
> 
> Distribution files hashes (SHA1):
>   4d4bb6741f9b5d095bcab24f5232a871ba579df0  commons-math3-3.6.1-bin.tar.gz
>   e088b160c19af7ca2596d91430b8a71aaa5ea5da  commons-math3-3.6.1-bin.zip
>   77ffe792e4bf0d4bcd7b4e2a8ce3b07df40a92b9  commons-math3-3.6.1-src.tar.gz
>   cadad1cbb7757b2616a96b20d357e3a6acb1b4c9  commons-math3-3.6.1-src.zip
> 
> KEYS file to check signatures:
>   http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
>  
> https://repository.apache.org/content/repositories/orgapachecommons-1142/org/apache/commons/commons-math3/3.6.1/
> 
> [X] +1 Release it.

+1.

For some reason, the schell scripts I use to check some boring stuff
(diffs between zip/tar.gz/tag) didn't work. I did it manually, and
everything was fine.

best regards,
Luc

> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few minor glitches: ...
> [ ] -1 No, do not release it because ...
> 
> This vote will close in 72 hours, at 2016-03-20T12:00:00Z (this is UTC
> time).
> 
> Best Regards,
> Evan
> 


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

Re: [report] Report from the Apache Commons Project

[luc]

Le 2016-03-15 20:04, Gary Gregory a écrit :

I will file this ASAP. If you feel something should be added, do let me
know.

## Description: Report from the Apache Commons Project  [Gary D. 
Gregory]


The Apache Commons project focuses on all aspects of reusable Java
components.

The Apache Commons components are widely used in many projects, both 
within

Apache and without. Any ASF committer can commit to Apache Commons.

The last report was on December 16 2015.

No issues require board attention at this time.

## Activity:

We had three (3) releases this period (see below).

We are considering adding a new Commons component called Commons Crypto
currently called Chimera (https://github.com/intel-hadoop/chimera). It 
is

an
optimized cryptographic library. It provides Java API for both cipher 
level

and
Java stream level to help developers implement high performance AES
encryption/decryption with the minimum code and effort.

## Health report:

 Overall project health is decent to good with 3 releases this period.

 We do not have too much action on the mailing lists but we do see 
JIRAs

and
 GitHub PRs come regularly in to Commons IO and Commons Lang. These are
 usually addressed in a timely fashion.

## PMC changes:

 - No new PMC members added in the last 3 months
 - Last PMC addition was Bernd Eckenfels on Sat Nov 21 2015


One PMC member did leave.



## Committer base changes:

 - No new committers added in the last 3 months
 - Last committer addition was Loic Guibert at Wed Oct 14 2015

## Releases:

 - JEXL-3.0 was released on Sat Dec 26 2015
 - MATH-3.6 was released on Mon Jan 04 2016
 - WEAVER-1.2 was released on Mon Feb 01 2016


## JIRA activity:

 - 172 JIRA tickets created in the last 3 months
 - 110 JIRA tickets closed/resolved in the last 3 months


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

Re: [Math] Configure the CI tools... How?

[Luc Maisonobe]

Le 04/03/2016 15:29, Gilles a écrit :
> On Thu, 25 Feb 2016 17:24:18 + (UTC), Gilles (JIRA) wrote:
>> Gilles created MATH-1328:
>> 
>>
>>  Summary: Configure the CI tools
>>  Key: MATH-1328
>>  URL: https://issues.apache.org/jira/browse/MATH-1328
>>  Project: Commons Math
>>   Issue Type: Sub-task
>> Reporter: Gilles
>> Priority: Critical
>>
>>
>> * Watch the "develop" branch
>> * Signal changes to "master" in a more prominent way, e.g. with an
>> appropriately strong email "subject" (?)
> 
> I guess that there is a document that explains how to achieve this; but
> where
> is it?

This is most probably an infra task. I don't think the project has any
grasp on it.

best regards,
Luc

> 
> Thanks,
> 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: [Math] New branch for development (Was: [commons-math] Git Push Summary)

[Luc Maisonobe]

Le 25/02/2016 17:47, Gilles a écrit :
> Hi.
> 
> On Thu, 25 Feb 2016 16:09:27 + (UTC), er...@apache.org wrote:
>> Repository: commons-math
>> Updated Branches:
>>   refs/heads/develop [created] 050dfa6f0
> 
> I've created the branch "develop" as per
>   https://issues.apache.org/jira/browse/MATH-1326
> 
> Please check out that branch and stop updating "master":
>   $ git checkout develop
> 
> A summary of the new work flow is in the following tiny-howto:
>   doc/development/development.howto.txt
> 
> Thanks,
> Gilles
> 
> P.S. Git experts, please check that I did not make any mistake...

I have checked the branches, everything looks find to me.

best regards,
Luc

> 
> 
> -
> 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: [math] Initial TLP PMC membership and chair

[luc]

Le 2016-02-04 23:30, Phil Steitz a écrit :

We have the following volunteers for the new TLP, which we have
decided to call "Apache Math"

Bill Barker
Otmar Ertl
Gary Gregory
Luc Maisonobe
Thomas Neidhart
Gilles Sadowski
Phil Steitz

We need to name an initial chair for the PMC.  I will volunteer for
this if you all would like me to.  I would also happily let someone
else take the first turn.   Any other volunteers / nominations?


+1 for Phil!

Luc



Phil


-
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: [math] [POLL] new TLP name

[Luc Maisonobe]

Le 01/02/2016 18:06, Phil Steitz a écrit :
> Please select your top choice among the following suggested names
> for the new [math]-based TLP.  All are welcome and encouraged to
> respond.  This POLL will be open for 72 hours, at which time two
> tallies will be presented:  one among those who have volunteered for
> the new PMC and a second among all respondents.  Hopefully, one name
> will emerge as consensus winner.  If not, I will kick off another
> runoff poll among the top choices.   Please respond with your top
> choice for the name.
> 
> AjaMa
> Epsilon
> Erdos
> Euclid
> Euler
> Gauss
> JAML
> Math
> MathBlocks
> MathComponents (or Math Components)
> Mathelactica
> MathModules
> Megginson
> modMath
> Nash
> Newton
> Pythagoras

First choice:  Apache Epsilon
Second choice: Apache Math

Luc

> 
> 
> 
> 
> 
> -
> 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: [Math] JDK "Random" and "BitsStreamGenerator"

[Luc Maisonobe]

Hi Gilles,

Le 26/01/2016 20:07, Gilles a écrit :
> Hello Luc.
> 
> On Tue, 26 Jan 2016 09:47:20 +0100, Luc Maisonobe wrote:
>> Le 26/01/2016 01:13, Gilles a écrit :
>>> Hi.
>>
>> Hi Gilles,
>>
>>>
>>> In CM, a base class "BitsStreamGenerator" contains methods for
>>> generating various primitive types from a bit source (to be
>>> implemented by subclasses by overriding the "next(int bits)"
>>> method).
>>> For example, to get a random "long" value, the following code
>>> is called:
>>> ---CUT---
>>> public long nextLong() {
>>> final long high  = ((long) next(32)) << 32;
>>> final long  low  = (next(32)) & 0xL;
>>> return high | low;
>>> }
>>> ---CUT---
>>>
>>> If the bit source were provided by the JDK's "Random" class,
>>> is it assumed that the "long" value generated by the above
>>> code will always be equal to the "long" value generated by
>>> the call to JDK's "Random" class?
>>
>> No. There is nothing said anywhere in the javadoc that would imply
>> one implementation of nextLong is the same as another implementation.
>> The only thing that user can exapect is that when they choose one
>> implementation, it is consistent, i.e. it is "random enough" and
>> "not biased". Two different implementations can fulfill these
>> requirements without producing the same sequence.
> 
> I note that your statement contradicts Phil's[1]:
>   "[..] you [...] changed the internal implementation of all
>of the Bitstream generators."
>   "[must] verify that the same sequences are generated by the
>3_X code and the refactored code [...]"
> 
> Minor point: I think that there is a possible ambiguity with
> "JDKRandomGenerator" when the doc indicates
>   "[an] adapter that delegates the random number generation to
>the standard [Random] class".
> 
> In fact, there are two possible cases:
>  (a) delegating all methods to "Random", or
>  (b) only use the source of randomness ("next(int bits)") from
>  "Random" and create the "long" with the algo provided in CM.
> 
> CM implicitly assumes case (a).

This is because JDKRandomGenerator is an adaptor, i.e. it changes
an API to match another API, but trying not to change implementations.

The other generators we have are independent generators.

> A user could infer it from the HTML doc of "JDKRandomGenerator",
> as it does not inherit from "BitsStreamGenerator".
> But in "RandomGeneratorFactory", it's more confusing.
> [By the way, those two are duplicate implementations of the same
> functionality.]
> 
> In the new "rng" package, I'll actually provide case (b) which
> is more consistent with how the other "sources of randomness"
> are used by "BitsStreamGenerator" to provide all the "nextXxx"
> methods.
> 
>>> In other words, how "standard" are the default implementations
>>> of the methods defined in "BitsStreamGenerator"?
>>
>> I don't think there are any standard to abide by.
> 
> OK, but how do we detect a suboptimal/buggy algorithm?

We don't. We don't have the skills for it. We are not random
generator experts with years of research behind us. We try to
do our best but sometime fails and I'm pretty sure we have a
bunch of undetected suboptimal/buggy algorithms.

> 
>>> And what are the compatibility requirements with respect to
>>> reproducibility of the sequences (between releases of the
>>> library)?
>>
>> It's a grey zone, IMHO. It is nice to preserve reproducibility
>> as changing it changes the reference test cases with fixed seeds.
> 
> AFAIK, having one seed pass the tests does not imply that the RNG
> is good.

You misunderstood what I meant.

The test cases I wrote about are the test cases for other classes
that do use random generator for different purposes. In many cases,
it is even simply to have a lot of different test points (a few
thousands), in order to explore a domain. For such cases, in some
cases we even used low discrepancy Sobol sequences instead of
random sequences. So when unit cases for algorithm A (say a geometry
algorithm), uses a sequence of points and we change the implementation
of the random generator, algorithm A then has simply a different
set of test points. It's not a worse or better set, it is a different
set. So we may need to adjust the test tolerances or the like. It is
not a b

Re: [math] Name of the new TLP

[luc]

Le 2016-01-25 12:49, James Carman a écrit :

Epsilon is catchy


I like it too.  As we have a tendency to chase down accuracy, it seems
a good fit. The logo would be easy to select ...

It would do well with the existing (despite quite stagnant)
Apache Commons Nabla <http://mathworld.wolfram.com/Nabla.html>.


Luc


On Mon, Jan 25, 2016 at 6:41 AM sebb <seb...@gmail.com> wrote:


On 25 January 2016 at 09:28, luc <l...@spaceroots.org> wrote:
> Le 2016-01-25 08:52, Benedikt Ritter a écrit :
>>
>> Hi,
>>
>> I very much like the idea of taking the name of a famous mathematician.

In which case it has to be

Euclid or Pythagoras (early)
or
Paul Erdős - https://en.wikipedia.org/wiki/Erd%C5%91s_number

and everyone has heard of
John Nash (Beautiful Mind)

etc.
In the spirit of recent discussions, how about a RNG to pick the
mathematician's name for each next incarnation?

;-)

>> If it has to be some thing more descriptive: Apache Commons HttpClient
>> went
>> to Apache HttpComponents. How about Apache Math Components as TLP name?

I quite like Apache Epsilon as a non-descriptive but related name.

[ducks behind bikshed]

>>
>> Benedikt
>>
>> 2016-01-25 8:40 GMT+01:00 Ole Ersoy <ole.er...@gmail.com>:
>>
>>> Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
>>> networks, clustering, monte carlo, simplex...These need an umbrella.
>>> Some
>>> of the other Apache projects that do math may be interested in moving
>>> that
>>> piece under the Apache Math umbrella.
>>>
>>> Personally I like to see each in a separate repository dedicated to the
>>> subject, along with the corresponding documentation, etc  So:
>>> apache-math (Central repository describing the project as a whole with
>>> the
>>> documentation that cuts across modules)
>>> apache-math-linear-real
>>> apache-math-linear-field
>>> apache-math-optimization-genetic
>>> apache-math-optimization-simplex
>>> etc.
>>>
>>> And hopefully:
>>> apache-math-optimization-integer
>>> apache-math-optimization-mixed
>>> And more..
>>>
>>> Cheers,
>>> Ole
>>>
>>>
>>> On 01/24/2016 04:41 PM, Phil Steitz wrote:
>>>
>>>>
>>>> On Jan 24, 2016, at 3:17 PM, Gilles <gil...@harfang.homelinux.org>
>>>> wrote:
>>>>>
>>>>>
>>>>> Just plain and simple "Apache Math" maybe?
>>>>> Or is it taken already?
>>>>>
>>>> It's not taken; but I thought it was too broad-sounding and in fact
>>>> umbrella-ish.  There are other ASF projects that do math-relates
things.
>>>> I
>>>> think adding "components" makes it look more like a library of base
>>>> components that other math-related projects can use.
>>>>
>>>> Phil
>>>>
>>>>> Gilles
>>>>>
>>>>> On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:
>>>>>>
>>>>>>
>>>>>>> On 1/24/16 2:16 PM, James Carman wrote:
>>>>>>> I guess it depends on the scope of what the new TLP is going to do.
>>>>>>>
>>>>>> This is slightly jumping the gun, as we do have the opportunity in
>>>>>> forming the new TLP to revisit the initial goals of [math]; but I
>>>>>> suspect that initially at least we will mostly continue to be a
>>>>>> general-purpose Java math library, trying to provide IP-clean,
>>>>>> easily integrated, standard algorithm-based solutions to common math
>>>>>> programming problems.  We have grown to the point where we will
>>>>>> almost certainly break the distribution up into separate
>>>>>> "components."  No umbrella, but likely multiple release artifacts.
>>>>>> Similar in some ways to what happened with [http], which is why I
>>>>>> suggested the same approach to naming.
>>>>>>
>>>>>> Regarding picking a mathematician for the name, I don't much like
>>>>>> that idea as whoever you choose, you end up loading some math area
>>>>>> and / or cultural bias into the name.
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>>> Umbrella projects aren't that popular these days, from what I
>>>>>>> understand.
>>>>>>> Maybe an homage to a famous mathematician? Ap

Re: [math] Name of the new TLP

[luc]

Le 2016-01-25 08:52, Benedikt Ritter a écrit :

Hi,

I very much like the idea of taking the name of a famous mathematician.
If it has to be some thing more descriptive: Apache Commons HttpClient 
went

to Apache HttpComponents. How about Apache Math Components as TLP name?

Benedikt

2016-01-25 8:40 GMT+01:00 Ole Ersoy <ole.er...@gmail.com>:


Umbrella-ish is good.  Linear algebra, genetic algorithms, neural
networks, clustering, monte carlo, simplex...These need an umbrella.  
Some
of the other Apache projects that do math may be interested in moving 
that

piece under the Apache Math umbrella.

Personally I like to see each in a separate repository dedicated to 
the

subject, along with the corresponding documentation, etc  So:
apache-math (Central repository describing the project as a whole with 
the

documentation that cuts across modules)
apache-math-linear-real
apache-math-linear-field
apache-math-optimization-genetic
apache-math-optimization-simplex
etc.

And hopefully:
apache-math-optimization-integer
apache-math-optimization-mixed
And more..

Cheers,
Ole


On 01/24/2016 04:41 PM, Phil Steitz wrote:



On Jan 24, 2016, at 3:17 PM, Gilles <gil...@harfang.homelinux.org> 
wrote:


Just plain and simple "Apache Math" maybe?
Or is it taken already?


It's not taken; but I thought it was too broad-sounding and in fact
umbrella-ish.  There are other ASF projects that do math-relates 
things.  I

think adding "components" makes it look more like a library of base
components that other math-related projects can use.

Phil


Gilles

On Sun, 24 Jan 2016 14:46:17 -0700, Phil Steitz wrote:



On 1/24/16 2:16 PM, James Carman wrote:
I guess it depends on the scope of what the new TLP is going to 
do.



This is slightly jumping the gun, as we do have the opportunity in
forming the new TLP to revisit the initial goals of [math]; but I
suspect that initially at least we will mostly continue to be a
general-purpose Java math library, trying to provide IP-clean,
easily integrated, standard algorithm-based solutions to common 
math

programming problems.  We have grown to the point where we will
almost certainly break the distribution up into separate
"components."  No umbrella, but likely multiple release artifacts.
Similar in some ways to what happened with [http], which is why I
suggested the same approach to naming.

Regarding picking a mathematician for the name, I don't much like
that idea as whoever you choose, you end up loading some math area
and / or cultural bias into the name.

Phil


Umbrella projects aren't that popular these days, from what I
understand.
Maybe an homage to a famous mathematician? Apache Newton? Apache 
Euler?

Apache Euclid?

On Sun, Jan 24, 2016 at 4:08 PM Phil Steitz 
<phil.ste...@gmail.com>

wrote:

We need to agree on a name.  My own preference is for a boring,
descriptive name, but I am manifestly not a marketing guy, so 
won't

be offended if others want to be more creative.

My suggestion is

MathComponents


I would be happy with either Math Components or Math.
Also I do favor fancy acronyms that read exactly as well known
names (23 years ago, the name of my first mathematics library was
an acronym that read "Cantor"), it is probably not a good idea for
this new TLP.

In any case, the project will most probably be de facto an umbrella
project as modularizing it seems in the current mood.

best regards,
Luc



Hearkens back to HttpComponents, which has worked pretty well.

Phil




-
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




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

Re: [math] Volunteer for the new TLP PMC

[Luc Maisonobe]

Le 24/01/2016 21:54, Phil Steitz a écrit :
> Please respond to this thread if you are a Commons Committer
> interested in joining the PMC for the new TLP based on [math].

I would be honored to join the new PMC.

best regards,
Luc

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


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

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC2

[luc]

Le 2016-01-22 08:47, Romain Manni-Bucau a écrit :

+1, thanks Matt!


Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> |  Blog
<http://rmannibucau.wordpress.com> | Github 
<https://github.com/rmannibucau> |

LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber
<http://www.tomitribe.com>

2016-01-21 19:39 GMT+01:00 Matt Benson <mben...@apache.org>:


I would like to release the [weaver] component.

Apache Commons Weaver 1.2 RC2 is available for review at:
  https://dist.apache.org/repos/dist/dev/commons/weaver/ (r11994).

Maven artifacts are at:
  
https://repository.apache.org/content/repositories/orgapachecommons-1141

.

Tested with Oracle JDKs 6, 7 and 8; IBM JDKs 6 and 7.

The Subversion tag is:
  http://svn.apache.org/repos/asf/commons/proper/weaver/tags/1.2_RC2/
(r1726007).

Site (note some links may be broken; this will be fixed when the site
is deployed):
  http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/index.html

RAT Report:
  
http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/rat-report.html


Quality Reports (CLIRR/PMD/Checkstyle/Findbugs):

http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-processor/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer-api/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-privilizer-parent/commons-weaver-privilizer/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-modules-parent/commons-weaver-normalizer/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-maven-plugin/project-reports.html

http://people.apache.org/~mbenson/commons-weaver-1.2-rc2/commons-weaver-parent/commons-weaver-antlib/project-reports.html

Keys: https://dist.apache.org/repos/dist/release/commons/KEYS

Please review the release candidate and vote.
  This vote will close no sooner than 72 hours from now, i.e. after
1900UTC 24-January 2016

  [X] +1 Release these artifacts


Slight difficulty in building from sources, due to the interdependency,
but this is propermy explained in the BUILDING.txt file, so a "mvn 
install"

rather than my traditional "mvn clean compile site" was sufficient. So
this is OK to me.

best regards,
Luc


  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

  Thanks!

-
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: [Math] Revamping the "random" package or ...

[Luc Maisonobe]

Le 17/01/2016 18:45, Phil Steitz a écrit :
> On 1/17/16 9:33 AM, Luc Maisonobe wrote:
>> Le 17/01/2016 16:31, Phil Steitz a écrit :
>>> On 1/17/16 6:34 AM, Gilles wrote:
>>>> On Sun, 17 Jan 2016 10:56:38 +0100, Luc Maisonobe wrote:
>>>>> Le 16/01/2016 16:51, Gilles a écrit :
>>>>>> Hi.
>>>>>>
>>>>>> Context: nobody gave an opinion on the arguments which I put
>>>>>> forward in these posts:
>>>>>>   http://markmail.org/message/uiljlf63uucnfyy2
>>>>>>   http://markmail.org/message/ifwuijbgjytne6w2
>>>>>>
>>>>>> As a consequence, the lack of any development policy, rather
>>>>>> than being the touted advantage of the "free world" of Apache,
>>>>>> is, objectively, a quite efficient way to push in the direction
>>>>>> of the stronger voice, not necessarily backed with the stronger
>>>>>> arguments (especially when those are not "technical" but, in
>>>>>> reality, "political"!).
>>>>>> This has been the subject of another post, that also was not
>>>>>> followed by a constructive debate in order to change this
>>>>>> community's ways, so that it would not discourage proposals
>>>>>> for code evolutions towards a modern use of the Java language.
>>>>>>
>>>>>> Thus, in this context, I obviously can't know whether "silence
>>>>>> is consent" or if people will continue raising objections to my
>>>>>> experimenting with the contents of the "random" package, even
>>>>>> after not raising concern and/or not engaging in the practical
>>>>>> discussions about the proposals.
>>>>>>
>>>>>> Also, it is disrespectful to let people think that they could
>>>>>> work on some part of the library, and then voice an opinion
>>>>>> akin to the hidden policy that there exists, in CM, codes
>>>>>> that are deemed too sensitive to be ever touched again.
>>>>>>
>>>>>> My first idea was to make incremental changes in "random".
>>>>>> The first few, and little, steps unexpectedly implied a huge
>>>>>> amount of work, mainly due to the disproportionate
>>>>>> justifications that were being required.
>>>>>>
>>>>>> It is a fact that even tiny, even no-op, changes meet
>>>>>> infinitely more opposition than adding even very large chunks
>>>>>> of new code.
>>>>>>
>>>>>> Hence, I propose that all my recent changes to the "random"
>>>>>> package be reverted so that it will match the contents of the
>>>>>> 3.6 release (modulo the changes which were explicitly agreed
>>>>>> on like those in "RandomGeneratorAbstractTest").
>>>>> I did answer to at least part of your proposals, and suggested
>>>>> this experimentation is done on a branch.
>>>>> At the same time, you also proposed to adopt another branching
>>>>> policy, and this was seen positively by anyone.
>>>>>
>>>>> So I would suggest that rather than adding a parallel rng package,
>>>>> which reminds me of the difficulties we get with the two optim and
>>>>> optimization packages, you continue doing your changes directly
>>>>> in the random package as you started to do, but in a feature branch.
>>>> Sorry, but I don't agree.
>>>> I've explained that I want to propose as a *replacement* to "random".
>>>> Almost every file will be changed, and a basic requirement is to have
>>>> the RNGs, and only the RNGs, in their own package/module.
>>>>
>>>> So for example, "RandomDataGenerator" and "ValueServer", as "users"
>>>> of the RNGs, should not be in the "rng" package (but but stay in
>>>> "random" whatever else changed or delete there).
>>>>
>>>> This situation here cannot be more different than for the "optim"
>>>> package!
>>>> First, the old "optimization" _has_ been deleted in "master"; we
>>>> had to keep it in the 3.x line.
>>>> The code in "optim" has been been criticized but until now nobody
>>>> came up with a b

Re: [Math] Revamping the "random" package or ...

[Luc Maisonobe]

Le 17/01/2016 20:19, Gilles a écrit :
> Hi Luc.
> 
> [Thanks for handling the "revert" chores!]
> 
> In my local "git", I've created a branch, called "long-rng",
> initially, as the name indicates, for testing "long"-based
> RNG implementations.
> 
> As I've expanded on in other posts, I came to think that
> further changes are needed in order to obtain a cleaner
> design.  And since the minimal changes were already
> causing stir, I also figured out that this refactoring
> work should be completed[1] so that the full picture is
> available in order to compare it meaningfully with the
> current code, rather than nit-pick on every incremental
> modification.
> 
> So, what I'd thought I could do on my "long-rng" branch is
> 1. create a new "o.a.c.m.rng" package,
> 2. move all (locally) new and modified classes in "o.a.c.m.random"
>over to "o.a.c.m.rng",
> 3. "git pull" in "master" to be current on that branch,
> 4. merge the current master to "long-rng", so that package
>"o.a.c.m.random" is clean, but "o.a.c.m.rng" still contains
>all my local work!
> 
> Is that possible?

Probably, yes. I hope the revert I made today will not create
conflicts in your branch. It may create conflicts as your own
cleaning in your local workspace probably touches the same files.
In any cases, these conflicts could be resolved locally.

> 
> Of course, simpler would be to just
> 1. create a new clean branch from the current "master", and
> 2. make all the local changes of the last three weeks appear in a
>single commit.
> [Anyways, the "successful development model" blog post discussed
> in another thread recommended this for feature branches.]
> 
> Is that OK?

That would be OK too, and as you noted, everything would appear
as a single commit.

best regards,
Luc

> [I would just lose the history of the past 3 weeks (which might
> be a good thing...).]
> 
> Is there another better/simpler way?
> Please advise.
> 
> Thanks in advance,
> Gilles
> 
> [1] There is, unfortunately, not much of either collaborative or
> incremental development happening for CM: New features come in
> big commits of new files and non-compatible changes are stopped
> dead in their tracks.
> 
> On Sun, 17 Jan 2016 17:33:27 +0100, Luc Maisonobe wrote:
>> Le 17/01/2016 16:31, Phil Steitz a écrit :
>>> On 1/17/16 6:34 AM, Gilles wrote:
>>>> On Sun, 17 Jan 2016 10:56:38 +0100, Luc Maisonobe wrote:
>>>>> Le 16/01/2016 16:51, Gilles a écrit :
>>>>>> Hi.
>>>>>>
>>>>>> Context: nobody gave an opinion on the arguments which I put
>>>>>> forward in these posts:
>>>>>>   http://markmail.org/message/uiljlf63uucnfyy2
>>>>>>   http://markmail.org/message/ifwuijbgjytne6w2
>>>>>>
>>>>>> As a consequence, the lack of any development policy, rather
>>>>>> than being the touted advantage of the "free world" of Apache,
>>>>>> is, objectively, a quite efficient way to push in the direction
>>>>>> of the stronger voice, not necessarily backed with the stronger
>>>>>> arguments (especially when those are not "technical" but, in
>>>>>> reality, "political"!).
>>>>>> This has been the subject of another post, that also was not
>>>>>> followed by a constructive debate in order to change this
>>>>>> community's ways, so that it would not discourage proposals
>>>>>> for code evolutions towards a modern use of the Java language.
>>>>>>
>>>>>> Thus, in this context, I obviously can't know whether "silence
>>>>>> is consent" or if people will continue raising objections to my
>>>>>> experimenting with the contents of the "random" package, even
>>>>>> after not raising concern and/or not engaging in the practical
>>>>>> discussions about the proposals.
>>>>>>
>>>>>> Also, it is disrespectful to let people think that they could
>>>>>> work on some part of the library, and then voice an opinion
>>>>>> akin to the hidden policy that there exists, in CM, codes
>>>>>> that are deemed too sensitive to be ever touched again.
>>>>>>
>>>>>> My first idea was to make incremental changes in "random".
>>>>>> The first few, 

Re: [Math] Revamping the "random" package or ...

[Luc Maisonobe]

Le 16/01/2016 16:51, Gilles a écrit :
> Hi.
> 
> Context: nobody gave an opinion on the arguments which I put
> forward in these posts:
>   http://markmail.org/message/uiljlf63uucnfyy2
>   http://markmail.org/message/ifwuijbgjytne6w2
> 
> As a consequence, the lack of any development policy, rather
> than being the touted advantage of the "free world" of Apache,
> is, objectively, a quite efficient way to push in the direction
> of the stronger voice, not necessarily backed with the stronger
> arguments (especially when those are not "technical" but, in
> reality, "political"!).
> This has been the subject of another post, that also was not
> followed by a constructive debate in order to change this
> community's ways, so that it would not discourage proposals
> for code evolutions towards a modern use of the Java language.
> 
> Thus, in this context, I obviously can't know whether "silence
> is consent" or if people will continue raising objections to my
> experimenting with the contents of the "random" package, even
> after not raising concern and/or not engaging in the practical
> discussions about the proposals.
> 
> Also, it is disrespectful to let people think that they could
> work on some part of the library, and then voice an opinion
> akin to the hidden policy that there exists, in CM, codes
> that are deemed too sensitive to be ever touched again.
> 
> My first idea was to make incremental changes in "random".
> The first few, and little, steps unexpectedly implied a huge
> amount of work, mainly due to the disproportionate
> justifications that were being required.
> 
> It is a fact that even tiny, even no-op, changes meet
> infinitely more opposition than adding even very large chunks
> of new code.
> 
> Hence, I propose that all my recent changes to the "random"
> package be reverted so that it will match the contents of the
> 3.6 release (modulo the changes which were explicitly agreed
> on like those in "RandomGeneratorAbstractTest").

I did answer to at least part of your proposals, and suggested
this experimentation is done on a branch.
At the same time, you also proposed to adopt another branching
policy, and this was seen positively by anyone.

So I would suggest that rather than adding a parallel rng package,
which reminds me of the difficulties we get with the two optim and
optimization packages, you continue doing your changes directly
in the random package as you started to do, but in a feature branch.

> 
> Is that possible?  [Luc, as the most experienced "git" user,
> would you mind managing this, perhaps delicate, operation?]

Reverting is not difficult. Remember the trick discussed on
this list to port commits between math3 and math4? It was
basically doing a "git diff -p some-commit~1 some-commit",
then patching the commit with a sed and applying it later on.

Here is it even simpler because we don't have to patch the commit.
The trick is to do the git diff the other way round, i.e.
"git diff -p some-commit some-commit~1".

Also rather than reverting them and restarting again, in
order not to lose your work I'll cut a new feature branch
first, then revert on master only. You will be able to
continue your work on the feature branch.

On a related subject, I also read on another list that infra
now allows deleting branches again. The concerns I had with
short-lived hotfix branches are therefore not realistic
anymore, we can do as many brnahces and as short-lived as we want.

> 
> I would then pursue my refactoring in a new package named
>   org.apache.commons.math4.rng
> where all the modifications, that led to the latest outburst of
> conservatism, will take place.
> It will also allow me to further experiment and see where it
> leads, without having to argue endlessly on every compatibility
> breaking.
> 
> In effect, it's a fork of "random" (but within CM).
> Of course, this will happen in a "feature branch" which I'll
> create upstream when the renaming has been performed.
> 
> Then people can see both sets of codes "side-by-side", analyze
> them, experiment with usage, and run benchmarks of the alternative
> versions of the RNG classes.
> 
> Ultimately, if the rift between conservatists and modernists
> remains, both the "random" and the "rng" packages can coexist
> in the 4.0 release of the library.

I would really prefer not to live again the
optim/optimization/least squares nightmare.

best regards,
Luc

> 
> 
> 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: [Math] Revamping the "random" package or ...

[Luc Maisonobe]

Le 17/01/2016 16:31, Phil Steitz a écrit :
> On 1/17/16 6:34 AM, Gilles wrote:
>> On Sun, 17 Jan 2016 10:56:38 +0100, Luc Maisonobe wrote:
>>> Le 16/01/2016 16:51, Gilles a écrit :
>>>> Hi.
>>>>
>>>> Context: nobody gave an opinion on the arguments which I put
>>>> forward in these posts:
>>>>   http://markmail.org/message/uiljlf63uucnfyy2
>>>>   http://markmail.org/message/ifwuijbgjytne6w2
>>>>
>>>> As a consequence, the lack of any development policy, rather
>>>> than being the touted advantage of the "free world" of Apache,
>>>> is, objectively, a quite efficient way to push in the direction
>>>> of the stronger voice, not necessarily backed with the stronger
>>>> arguments (especially when those are not "technical" but, in
>>>> reality, "political"!).
>>>> This has been the subject of another post, that also was not
>>>> followed by a constructive debate in order to change this
>>>> community's ways, so that it would not discourage proposals
>>>> for code evolutions towards a modern use of the Java language.
>>>>
>>>> Thus, in this context, I obviously can't know whether "silence
>>>> is consent" or if people will continue raising objections to my
>>>> experimenting with the contents of the "random" package, even
>>>> after not raising concern and/or not engaging in the practical
>>>> discussions about the proposals.
>>>>
>>>> Also, it is disrespectful to let people think that they could
>>>> work on some part of the library, and then voice an opinion
>>>> akin to the hidden policy that there exists, in CM, codes
>>>> that are deemed too sensitive to be ever touched again.
>>>>
>>>> My first idea was to make incremental changes in "random".
>>>> The first few, and little, steps unexpectedly implied a huge
>>>> amount of work, mainly due to the disproportionate
>>>> justifications that were being required.
>>>>
>>>> It is a fact that even tiny, even no-op, changes meet
>>>> infinitely more opposition than adding even very large chunks
>>>> of new code.
>>>>
>>>> Hence, I propose that all my recent changes to the "random"
>>>> package be reverted so that it will match the contents of the
>>>> 3.6 release (modulo the changes which were explicitly agreed
>>>> on like those in "RandomGeneratorAbstractTest").
>>>
>>> I did answer to at least part of your proposals, and suggested
>>> this experimentation is done on a branch.
>>> At the same time, you also proposed to adopt another branching
>>> policy, and this was seen positively by anyone.
>>>
>>> So I would suggest that rather than adding a parallel rng package,
>>> which reminds me of the difficulties we get with the two optim and
>>> optimization packages, you continue doing your changes directly
>>> in the random package as you started to do, but in a feature branch.
>>
>> Sorry, but I don't agree.
>> I've explained that I want to propose as a *replacement* to "random".
>> Almost every file will be changed, and a basic requirement is to have
>> the RNGs, and only the RNGs, in their own package/module.
>>
>> So for example, "RandomDataGenerator" and "ValueServer", as "users"
>> of the RNGs, should not be in the "rng" package (but but stay in
>> "random" whatever else changed or delete there).
>>
>> This situation here cannot be more different than for the "optim"
>> package!
>> First, the old "optimization" _has_ been deleted in "master"; we
>> had to keep it in the 3.x line.
>> The code in "optim" has been been criticized but until now nobody
>> came up with a better proposal, so the only working code must
>> obviously stay.
>>
>> For "rng", I'll propose a working remplacement, and we'll be able
>> to immediately decide whether to keep "random" as is or adapt it
>> in order to remove the redundancy with the new "rng" and/or write
>> some adaptation layers from "random" to "rng".
> 
> +1 to separate the PRNG abstract class(es)? and impls into a
> separate package called "rng."  I would personally favor making that
> a subpackage of random.

OK. Then we can simply delete the cu

Re: [VOTE] Form a separate TLP based on [math]

[Luc Maisonobe]

Le 16/01/2016 16:18, Phil Steitz a écrit :
> The discussion has thus far been generally favorable.  I would like
> therefore to put the proposal to split [math] out into a separate
> TLP to a VOTE.  Assuming a favorable vote, we can discuss how to go
> about doing it.  Votes, please.  All are welcome to vote.
> 
> [X] +1 I am in favor of this action

Luc

> [ ] +0 I am OK with this
> [ ] -0 OK, but...
> [ ] -1 I oppose this action because...
> 
> This VOTE will run a little longer than usual - closing at 20 Jan
> 13:00 UTC.
> 
> Thanks!
> 
> Phil
> 
> 
> -
> 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: [math] TLP

[Luc Maisonobe]

Hi Phil,

Le 14/01/2016 01:50, Phil Steitz a écrit :
> I would like to propose that we split [math] out into a top level
> project at the ASF.  This has been proposed before, and I have
> always come down on the side of staying in Commons, but I am now
> convinced that it is a good step for us to take for the following
> reasons:
> 
> 0) We have several committers who are really only interested in
> [math], so being on the Commons PMC does not really make sense for them
> 1) The code base has swollen in size to well beyond the "small sharp
> tools" that make up the bulk of Commons
> 2) We are probably at the point where we should consider splitting
> [math] itself into separately released subcomponents (could be done
> in Commons, but starts smelling a little Jakarta-ish when Commons
> has components with subcomponents).
> 
> The downsides are
> a) [newPMC] loses Commons eyeballs / contributors who would not find
> us otherwise
> b) Migration / repackaging pain
> c) Overhead of starting and managing a PMC
> d) Other Commons components lose some eyeballs
> 
> Personally, I think the benefits outweigh the downsides at this
> point.  New better tools and ASF processes have made b) and c) a
> little less onerous.  I don't think d) is really a big problem for
> Commons, as those of us who work on other stuff here could continue
> to do so.  It is possible that a) actually works in the reverse
> direction - i.e., we are easier to find as a TLP.
> 
> What do others think about this? 

I also think it is now time for us to grow up and leave parents home.
[math] has become big, really big by now. It looks more like a
standalone autonomous project than a shared component. Since a few
years, it started to becomes a singular component, not really
similar to the others. We almost monopolize the bandwidth on the
mailing list, which can be painful for non-math developers.

I think going TLP could also allow us to do somes things differently,
perhaps experimenting on less stringent constraints about releases,
mainly related to stuff that is not stabilized. We could also accept
some ideas that were rejected up to now as not fitting in commons
scope (higher level stuff like the expression parser that was submitted
twice by different people if I remember well).

So +1 for going TLP.

best regards,
Luc

> 
> Phil
> 
> 
> -
> 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: [math][all] Archaeology pre-git

[Luc Maisonobe]

Le 11/01/2016 23:11, Phil Steitz a écrit :
> Now and then I want to go back and research how the code got to be
> the way it is.  I used to be able to just jump into the old
> svn-viewc thingy.  That is now blocked with a message that just says
> "math is in git now."  That is great; but when I go back in the git
> log, it always ends when whatever branch was created that I am
> looking at.  How can I find the full history?

It seems strange. I just did a "git checkout field-ode" and "git log"
and the list did go past the branch creation.

What I usually do for looking in large history with several branches
at once is "git log -30 --branches --oneline --decorate --graph",
of course any number of commits other than 30 can be used.

For any git command, like log, you can display its documentation
by adding a "--help" *after* the command name, as in "git log --help".

best regards,
Luc

> 
> 
> -
> 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: [Math] Feature development model

[Luc Maisonobe]

Hi Sebb,

Le 07/01/2016 04:21, sebb a écrit :
> On 7 January 2016 at 01:48, Gilles <gil...@harfang.homelinux.org> wrote:
>> On Wed, 6 Jan 2016 18:42:06 +0100, Luc Maisonobe wrote:
>>>
>>> Le 06/01/2016 15:56, Gilles a écrit :
>>>>
>>>> Hi.
>>>>
>>>> I've reread this article (which IIRC was advertised on this list some
>>>> time ago):
>>>>   http://nvie.com/posts/a-successful-git-branching-model/
>>>>
>>>> It is quite clear and I think that it would easy to get used to.
>>>
>>>
>>> Yes, it is quite a good model.
>>>
>>>> Unless there are shortcomings that would prevent its use with the CM
>>>> repository, I propose that we adopt it officially, and assume its
>>>> nomenclature in order to eventually develop scripts similar to
>>>> what is mentioned below.
>>>
>>>
>>> That would be fine with me. One should however be aware that we
>>> cannot delete branches in Apache git repository anymore (at least
>>> I think this is something that is now enforced). The reason is
>>> that history should never be lost, or rewritten. So everything
>>> that hits the repository remains there.
> 
> Infra intended this as a temporary measure whilst the implications of
> allowing deletes were worked out and a better solution found.

OK. Thanks for the clarification.

> 
> I expect the restriction will be relaxed soon.
> 
>>>
>>> Considering this, having very short lived hotfix branches may
>>> prove unpractical. I would not like on the other hand having
>>> such short lived branches fly around outside of Apache infrastructure
>>> (like github or anything), as these would defeat the purpose of
>>> preserving history.
>>>
>>> However, using more topic branches seems good to me. This is what
>>> was done for the field-doe (and the branch is still there).
>>
>>
>> Given the "git" model, it would make sense to allow deleting
>> branches whose sole purpose is to allow developers to exchange
>> work that is experimental.
> 
> Agreed, but the problem is ensuring that the appropriate parts of the
> repo are locked down.

Yes, and sometimes we can learn from errors. I also had a few
cases when I tried something, found it was bad, deleted it to
try something else, only to find a few months later that in
fact there was still a part I could have reused. But this is
a corner case. If you delete something important and not
saved elsewhere, you just blame yourself.

> 
>> Deleting a "feature" branch is not deleting history. The code
>> would become history only when this branch is merged in
>> "development".

If the branch is merged at the end, yes, history is preserved.
It can be tricky to find again as you don't have a pointer on
the tip of the branch, but the commits are there.

>> IIUC, you have preserved all the history of your commits when
>> merging your work into "master". [By the way, I think that
>> it would be better to squash one "feature" into a single
>> commit so that it is trivial to figure out whether this
>> commit introduced some problem (as is advised in the article
>> IIUC).  The detailed history of a "feature" work is not
>> necessary since even if a bug is uncovered, it is unlikely
>> that one will search for a commit to be reverted rather than
>> make a new one with the fix!  And it will avoid a flood of
>> messages to the ML which only code archaeologists would ever
>> read.]

I could have done both ways. When I proposed this a few weeks
ago, it was thought that the history was worth preserving,
moreover remembering that these commits are not in the
common ancestors of the master branch (they occurred after
MATH_3_X was forked).
Perhaps next time I will do it at once. Or better perhaps
next time we will not have to go through these hops because
we can use more straightforward git commands (git cherry-pick
and the like). Using the other classical way of squashing commits
using git rebase interactive will certainly not be allowed
by infra, as this really is a dangerous command and it opens
ways to destroy or rewrite history).

>>
>> So (from the article),
>> * the "master" branch is the one from which tags for released
>>   code are made and is of course "history",
>> * the "develop" branch is "history";
>> and those must not be deleted, obviously.
>>
>> If we want to avoid the proliferation of short-lived branches
>> that are also "history" (of hot fixes an

[ANNOUNCE] Apache Commons Math 3.6 released

[Luc Maisonobe]

The Apache Commons Team is pleased to announce the availability of
Apache Commons Math 3.6.

Apache Commons Math is a library of lightweight, self-contained
mathematics and statistics components addressing the most common
problems not available in the Java programming language or Commons Lang.

Version 3.6 is a minor release: It combines bug fixes and new features.
Changes to existing features were made in a backwards-compatible way
such as to allow drop-in replacement of the v3.x JAR file.

Most notable among the new features are: field-based version of
Ordinary Differential Equations framework, numerous improvements in
distributions, statistics and neuralnet packages, refactored
implementation of microsphere interpolation algorithm, explicit
specification of rotation convention to use (both vector operator and
frame transform conventions are now available). The minimum version of
the Java platform required to compile and use Commons Math is Java 5.
Users are encouraged to upgrade to this version as this release not
only includes bug fixes but also deprecates numerous classes and
methods that will be deleted from the next major release (4.0). Caveat:
1. The implementation of the BOBYQA optimization algorithm is in alpha
state (cf. MATH-621): Many code paths are untested, and we are looking
for volunteers to improve the code readability, robustness and
performance and to extend the unit tests suite. 2. A few methods in the
FastMath class are in fact slower that their counterpart in either Math
or StrictMath (cf. MATH-740 and MATH-901).

Users are encouraged to upgrade to this version as this release not
only includes bug fixes but also deprecates numerous classes and
methods that will be deleted from the next major release (4.0).

A full list of all changes can be found in the release notes at
http://www.apache.org/dist/commons/math/RELEASE-NOTES.txt

Source and binary distributions are available for download from the
Apache Commons download site:

http://commons.apache.org/proper/commons-math/download_math.cgi

When downloading, please verify signatures using the KEYS file available
at the above location when downloading the release.

Maven artifacts are also available in the maven central repository:

GroupId:org.apache.commons
ArtifactId: commons-math3
Version:3.6

For complete information on Apache Commons Math, including instructions
on how to submit bug reports, patches, or suggestions for improvement,
see the Apache Commons Math website:

http://commons.apache.org/proper/commons-math/

Luc Maisonobe, on behalf of the Apache Commons community



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

[math] big batch of commits coming

[Luc Maisonobe]

Hi all,

As discussed a few weeks ago, I ported the new field-based ode feature
from MATH_3_X to master. I was finally able to do that without losing
the about hundred commits history, by replaying them with some scripting.

In case this is of interest for some of you, here is how I managed to
do that.

First, I had to find the commit lists in the MATH_3_X branch that
were of interest, concentrating only on the real code change commits
(i.e. ignoring the merge commits that occurred two or three time
between the topic branch field-ode and MATH_3_X branch). This was
done by identifying a start and an end commit and listing the
intermediate ones with the following command:

git rev-list ^4685d03~1 b5276e9 --author=Luc --max-parents=1 --reverse

I put this list in a file for later looping over this.

Then I wrote a small script that extracted from one commit identifier
the commit message in one temporary file, and the diff in another
temporary file, with all math3 strings replaced with math4. The
diff was then applied, spurious .orig and .rej files eliminated, and
the commit performed with the same message as the original commit. Here
are the few commands:

  git show --pretty=format:"%s%n%n%b" --no-patch $1 \
   > $tmpdir/commit-message
  git show --pretty=format:"" $1 | sed 's,math3,math4,g' \
  > $tmpdir/commit-patch

  patch -p1 < $tmpdir/commit-patch && |
find . -name '*.orig' -exec rm {} \; \
-o -name '*.rej'  -exec rm {} \; && \
git add . && \
git commit -F $tmpdir/commit-message

It worked quite well, with only a few glitches that forced me to
interrupt the loop, remove a few commits, correct the command, and
restart the loop.

After that, I replayed a number of additional commits picked up
individually one at a time, for commits that occurred more recently
than the range before and were interspersed with other commits in
the MATH_3_X branch. So at the end, I had 101 commits.

All of this was done on a local tmp branch, so I coud roll back and
restart from scratch easily if anything went wrong. When I was certain
that this tmp branch was complete, I merged it into master.

You will see the last step in a few minutes, with a git push that will
update master with the 101 commits that are in the pipe. I'm sorry for
the noise.

At the end, we will have a master branch with the same feature as the
MATH_3_X branch, and a full history of the development of this feature.

best regards,
Luc

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

Re: [Math] Feature development model (Was: big batch of commits coming)

[Luc Maisonobe]

Le 06/01/2016 15:56, Gilles a écrit :
> Hi.
> 
> I've reread this article (which IIRC was advertised on this list some
> time ago):
>   http://nvie.com/posts/a-successful-git-branching-model/
> 
> It is quite clear and I think that it would easy to get used to.

Yes, it is quite a good model.

> Unless there are shortcomings that would prevent its use with the CM
> repository, I propose that we adopt it officially, and assume its
> nomenclature in order to eventually develop scripts similar to
> what is mentioned below.

That would be fine with me. One should however be aware that we
cannot delete branches in Apache git repository anymore (at least
I think this is something that is now enforced). The reason is
that history should never be lost, or rewritten. So everything
that hits the repository remains there.

Considering this, having very short lived hotfix branches may
prove unpractical. I would not like on the other hand having
such short lived branches fly around outside of Apache infrastructure
(like github or anything), as these would defeat the purpose of
preserving history.

However, using more topic branches seems good to me. This is what
was done for the field-doe (and the branch is still there).

best regards,
Luc

> 
> 
> Best regards,
> Gilles
> 
> On Wed, 6 Jan 2016 14:49:09 +0100, Luc Maisonobe wrote:
>> Hi all,
>>
>> As discussed a few weeks ago, I ported the new field-based ode feature
>> from MATH_3_X to master. I was finally able to do that without losing
>> the about hundred commits history, by replaying them with some scripting.
>>
>> In case this is of interest for some of you, here is how I managed to
>> do that.
>>
>> First, I had to find the commit lists in the MATH_3_X branch that
>> were of interest, concentrating only on the real code change commits
>> (i.e. ignoring the merge commits that occurred two or three time
>> between the topic branch field-ode and MATH_3_X branch). This was
>> done by identifying a start and an end commit and listing the
>> intermediate ones with the following command:
>>
>> git rev-list ^4685d03~1 b5276e9 --author=Luc --max-parents=1 --reverse
>>
>> I put this list in a file for later looping over this.
>>
>> Then I wrote a small script that extracted from one commit identifier
>> the commit message in one temporary file, and the diff in another
>> temporary file, with all math3 strings replaced with math4. The
>> diff was then applied, spurious .orig and .rej files eliminated, and
>> the commit performed with the same message as the original commit. Here
>> are the few commands:
>>
>>   git show --pretty=format:"%s%n%n%b" --no-patch $1 \
>>> $tmpdir/commit-message
>>   git show --pretty=format:"" $1 | sed 's,math3,math4,g' \
>>   > $tmpdir/commit-patch
>>
>>   patch -p1 < $tmpdir/commit-patch && |
>> find . -name '*.orig' -exec rm {} \; \
>> -o -name '*.rej'  -exec rm {} \; && \
>> git add . && \
>> git commit -F $tmpdir/commit-message
>>
>> It worked quite well, with only a few glitches that forced me to
>> interrupt the loop, remove a few commits, correct the command, and
>> restart the loop.
>>
>> After that, I replayed a number of additional commits picked up
>> individually one at a time, for commits that occurred more recently
>> than the range before and were interspersed with other commits in
>> the MATH_3_X branch. So at the end, I had 101 commits.
>>
>> All of this was done on a local tmp branch, so I coud roll back and
>> restart from scratch easily if anything went wrong. When I was certain
>> that this tmp branch was complete, I merged it into master.
>>
>> You will see the last step in a few minutes, with a git push that will
>> update master with the 101 commits that are in the pipe. I'm sorry for
>> the noise.
>>
>> At the end, we will have a master branch with the same feature as the
>> MATH_3_X branch, and a full history of the development of this feature.
>>
>> best regards,
>> Luc
> 
> 
> -
> 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: [Math] Next version(s)? (Was: [...] Putting MATH_3_X branch to post-release state.)

[Luc Maisonobe]

Le 06/01/2016 15:19, Gilles a écrit :
> Hi.

Hi Gilles,

> 
> On Tue, 05 Jan 2016 21:47:52 -, l...@apache.org wrote:
>> Putting MATH_3_X branch to post-release state.
>>
>> This change is only done in case a new release should be done.
>> This is however not really expected now and the next release should
>> rather be 4.0 than 3.7.
> 
> The latest clash about changes in the "master" branch makes this
> statement quite non obvious.

I don't think anybody wants to keep 3.X indefinitely. We did start
a 4.0 branch on master. The fact it doesn't progress fast doesn't
mean people only want to continue on 3.X.

> 
> Can we, for once, have a real release policy put in place?
> A policy that would be based on requirements transparently laid out?
> 
> That would imply that a *zero* weight would be assigned to statements
> made in order to represent an anonymous ("the users") group (that cannot
> participate in the debate, as per "Your role at the ASF is one assigned
> to you personally, [...]".)
> 
> Of course, each developer is a user (*one* user).
> Of course, each developer is entitled to his own idea of what CM is,
> should be, or should not be (and the consequence thereof on the
> project's management); but that should be clearly spelled out as one
> opinion, on a par with any other developer's opinion.

What I wrote or commit is only one people writings or work and was never
stated as an overall meta opinion. When I speak about users, I speak
about the users I know of, which are mainly my coworkers. Count it
as one opinion only if you want and associate it to me only if you
want. It is not intended to be considered as more or less important
than others opinions. Putting zero weight to it arbitrarily is not
better than putting a 10x weight on it.

> 
> A useful policy will help in avoiding that high level questions
> (such as "Backwards-compatibility or not?") constantly pollute
> development issues (such as "Refactor ").
> 
> The policy should also include a plan for releases, so that we don't
> have to wait until Luc needs one in a hurry, in order to prepare the
> next release.

We never waited until I need it. Anybody can perform release. Any
contributor can ask for a release. I happened for other commons
sub-project, and sometimes was done, sometimes not. The main
point was always: is there someone available that volunteers to
take the pain of the release. Each time I asked for a release, I
do volunteer to do it. Here again, it could have been anybody instead
of me.

We all want to Release Early Release Often, and we all fail to do it
because sincerely, it is a pain. So we end up doing release irregularly.

We are not in a corporate environment when a manager can dictate rules
that must be obeyed. This is a voluntary-based project. So even if we
were to decide some fixed rules, with high level requirement or fixed
release plans, we would never follow these plans in reality. We already
said quite a number of times: we should release more often. We never
succeeded to do it effectively.

> 
> Most importantly, we must know what are the requirements in order to
> start to manage this project in any sensible way.
> In particular, a policy should prevent to informally come back on
> previous formal decisions, with its trail of "draining" discussions.

So we should have minutes of decisions, with a signature of all
participants, and some regular meetings to monitor progress. And what
about a penalty if we don't meet deadline? Oh, and of course we should
nominate a manager, and have an independent quality management to
oversee what we do and check we really stick to the rules. We should
probably write some specification documents, and interface control
documents, and preliminary design documents, detailed design also,
and probably some test plans and development guidelines ... and we
should get paid.

Of course I go to the extreme here, and the paragraph above is
expected to be read as humorous. What I want to point out is
that in a community and collaborative development (yes, I really
mean it *is* collaborative and we succeed in it), rules are fuzzy,
and followed if they are natural enough that they are not really
rules.

> 
> Do the above points seem a common starting ground?

As long as these are fuzzy rules, yes. If they are strong policy
in a corporate-like management, no.

> 
> If so, we can begin to list the issues which the policy should aim
> at answering.
> I'd start with the following:
>  * Release early, release often (and what it means, in practice,
>for CM)

Big +1. Hey, we already want that. It is just that saying it
won't make it appear magically. Someone has to take the pain.

>  * Several development targets or a single one? [Depends on which
>are the "requirement

Re: [VOTE][RC2] Release Commons Math 3.6

[Luc Maisonobe]

Hi all,

Please remind this vote will close in less than 12 hours.
Only 2 votes have been cast by now, we need at least 3
from PMC members for this to succeed.

best regards,
Luc

Le 02/01/2016 21:15, Luc Maisonobe a écrit :
> This is a [VOTE] for releasing Apache Commons Math 3.6 from release
> candidate 2.
> 
> Tag name:
>   MATH_3_6_RC2 (signature can be checked from git using 'git tag -v')
> 
> Tag URL:
> 
> <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=95a9d35e77f70ffc9bd5143880c236a760b42005>
> 
> Commit ID the tag points at:
>   95a9d35e77f70ffc9bd5143880c236a760b42005
> 
> Site:
>   <http://home.apache.org/~luc/commons-math-3.6-RC2-site>
> 
> Distribution files:
>   https://dist.apache.org/repos/dist/dev/commons/math/
> 
> Distribution files hashes (SHA1):
>  8b0b724b91102f63c7211f8de60dec19f94c4af7  commons-math3-3.6-bin.tar.gz
>  f3f2b3974e5ecd368aa3294f8c59a7aeae4c5d90  commons-math3-3.6-bin.zip
>  213985b076b344178cd2fb07e7257cb52b65e3b9  commons-math3-3.6-src.tar.gz
>  0c66a1aaf878aa7e6c0d9bbf917b25efa463b313  commons-math3-3.6-src.zip
> 
> KEYS file to check signatures:
>   http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1138/org/apache/commons/commons-math3/3.6/
> 
> [ ] +1 Release it.
> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few minor glitches: ...
> [ ] -1 No, do not release it because ...
> 
> This vote will close in 72 hours, at 2016-01-05T20:15:00Z (this is UTC
> time).
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


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

Re: [VOTE][RC2] Release Commons Math 3.6

[Luc Maisonobe]

Le 05/01/2016 17:42, Gary Gregory a écrit :
> On Tue, Jan 5, 2016 at 7:51 AM, Gilles <gil...@harfang.homelinux.org> wrote:
> 
>> Hi Luc.
>>
>> On Tue, 5 Jan 2016 09:44:09 +0100, Luc Maisonobe wrote:
>>
>>> Hi all,
>>>
>>> Please remind this vote will close in less than 12 hours.
>>> Only 2 votes have been cast by now, we need at least 3
>>> from PMC members for this to succeed.
>>>
>>
>> [After cloning to a clean directory and "git checkout MATH_3_6_RC2".]
>> The command
>>
>> $ mvn site
>>
>> failed on my machine.
>> Here is the end of the maven output:
>> ---CUT---
>> [...]
>> [INFO] Generating "Clirr" report---
>> clirr-maven-plugin:2.6.1:clirr
>> [INFO] Comparing to version: 3.5
>> [INFO]
>> 
>> [INFO] BUILD FAILURE
>> [INFO]
>> 
>> [INFO] Total time: 01:31 min
>> [INFO] Finished at: 2016-01-05T16:35:25+01:00
>> [INFO] Final Memory: 84M/812M
>> [INFO]
>> 
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on
>> project commons-math3: Execution default-site of goal
>> org.apache.maven.plugins:maven-site-plugin:3.4:site failed: Invalid byte
>> tag in constant pool: 18 -> [Help 1]
>>
> 
> That's an issue I've seen with Java 8, should be OK with Java 7.

Yes, I confirm this happens when maven is run with Java8.

If you have multiple Java versions on your machine, you can do something
along these lines :

 LANG=C JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre mvn site

This sets up the language environment to a neutral choice and lets
maven rely on Java 7 (in this case) to avoid Java 8.

best regards,
Luc



> 
> Gary
> 
> 
>> [ERROR]
>> [ERROR] To see the full stack trace of the errors, re-run Maven with the
>> -e switch.
>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>> [ERROR]
>> [ERROR] For more information about the errors and possible solutions,
>> please read the following articles:
>> [ERROR] [Help 1]
>> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
>> ---CUT---
>>
>> $ mvn -v
>> Apache Maven 3.3.9
>> Maven home: /usr/share/maven
>> Java version: 1.8.0_72-internal, vendor: Oracle Corporation
>> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
>> Default locale: en, platform encoding: UTF-8
>> OS name: "linux", version: "4.2.0-1-amd64", arch: "amd64", family: "unix"
>>
>>
>> Regards,
>> Gilles
>>
>> best regards,
>>> Luc
>>>
>>> [...]
>>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> 
> 


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

Re: [VOTE][RC2] Release Commons Math 3.6

[Luc Maisonobe]

Le 05/01/2016 17:07, Thomas Neidhart a écrit :
> On 01/02/2016 09:15 PM, Luc Maisonobe wrote:
>> This is a [VOTE] for releasing Apache Commons Math 3.6 from release
>> candidate 2.
>>
>> Tag name:
>>   MATH_3_6_RC2 (signature can be checked from git using 'git tag -v')
>>
>> Tag URL:
>>
>> <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=95a9d35e77f70ffc9bd5143880c236a760b42005>
>>
>> Commit ID the tag points at:
>>   95a9d35e77f70ffc9bd5143880c236a760b42005
>>
>> Site:
>>   <http://home.apache.org/~luc/commons-math-3.6-RC2-site>
>>
>> Distribution files:
>>   https://dist.apache.org/repos/dist/dev/commons/math/
>>
>> Distribution files hashes (SHA1):
>>  8b0b724b91102f63c7211f8de60dec19f94c4af7  commons-math3-3.6-bin.tar.gz
>>  f3f2b3974e5ecd368aa3294f8c59a7aeae4c5d90  commons-math3-3.6-bin.zip
>>  213985b076b344178cd2fb07e7257cb52b65e3b9  commons-math3-3.6-src.tar.gz
>>  0c66a1aaf878aa7e6c0d9bbf917b25efa463b313  commons-math3-3.6-src.zip
>>
>> KEYS file to check signatures:
>>   http://www.apache.org/dist/commons/KEYS
>>
>> Maven artifacts:
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1138/org/apache/commons/commons-math3/3.6/
>>
> [X] +1 Release it.

Thanks Thomas,

best regards,
Luc

> 
> tested with
> 
> Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17
> 17:22:22+0200)
> Maven home: /home/tn/bin/apache-maven-3.1.1
> Java version: 1.7.0_91, vendor: Oracle Corporation
> Java home: /usr/lib/jvm/java-7-openjdk-i386/jre
> Default locale: en_US, platform encoding: UTF-8
> OS name: "linux", version: "3.13.0-71-generic", arch: "i386", family: "unix"
> 
> 
> Thomas
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


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

Re: [VOTE][RC2] Release Commons Math 3.6

[Luc Maisonobe]

Le 05/01/2016 19:59, Gilles a écrit :
> On Sat, 2 Jan 2016 21:15:32 +0100, Luc Maisonobe wrote:
>> This is a [VOTE] for releasing Apache Commons Math 3.6 from release
>> candidate 2.
>>
>> Tag name:
>>   MATH_3_6_RC2 (signature can be checked from git using 'git tag -v')
>>
>> Tag URL:
>>
>>
>> <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=95a9d35e77f70ffc9bd5143880c236a760b42005>
>>
>>
>> Commit ID the tag points at:
>>   95a9d35e77f70ffc9bd5143880c236a760b42005
>>
>> Site:
>>   <http://home.apache.org/~luc/commons-math-3.6-RC2-site>
>>
>> Distribution files:
>>   https://dist.apache.org/repos/dist/dev/commons/math/
>>
>> Distribution files hashes (SHA1):
>>  8b0b724b91102f63c7211f8de60dec19f94c4af7  commons-math3-3.6-bin.tar.gz
>>  f3f2b3974e5ecd368aa3294f8c59a7aeae4c5d90  commons-math3-3.6-bin.zip
>>  213985b076b344178cd2fb07e7257cb52b65e3b9  commons-math3-3.6-src.tar.gz
>>  0c66a1aaf878aa7e6c0d9bbf917b25efa463b313  commons-math3-3.6-src.zip
>>
>> KEYS file to check signatures:
>>   http://www.apache.org/dist/commons/KEYS
>>
>> Maven artifacts:
>>
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1138/org/apache/commons/commons-math3/3.6/
>>
>>
> 
>   [X] +1 Release it.

Thanks, Gilles.

best regards,
Luc

> 
> Gilles
> 
>> [ ] +0 Go ahead; I don't care.
>> [ ] -0 There are a few minor glitches: ...
>> [ ] -1 No, do not release it because ...
>>
>> This vote will close in 72 hours, at 2016-01-05T20:15:00Z (this is UTC
>> time).
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


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

Re: [VOTE][RC2] Release Commons Math 3.6

[Luc Maisonobe]

Le 05/01/2016 19:58, Gilles a écrit :
> On Tue, 5 Jan 2016 17:48:59 +0100, Luc Maisonobe wrote:
>> Le 05/01/2016 17:42, Gary Gregory a écrit :
>>> On Tue, Jan 5, 2016 at 7:51 AM, Gilles <gil...@harfang.homelinux.org>
>>> wrote:
>>>
>>>> Hi Luc.
>>>>
>>>> On Tue, 5 Jan 2016 09:44:09 +0100, Luc Maisonobe wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Please remind this vote will close in less than 12 hours.
>>>>> Only 2 votes have been cast by now, we need at least 3
>>>>> from PMC members for this to succeed.
>>>>>
>>>>
>>>> [After cloning to a clean directory and "git checkout MATH_3_6_RC2".]
>>>> The command
>>>>
>>>> $ mvn site
>>>>
>>>> failed on my machine.
>>>> Here is the end of the maven output:
>>>> ---CUT---
>>>> [...]
>>>> [INFO] Generating "Clirr" report---
>>>> clirr-maven-plugin:2.6.1:clirr
>>>> [INFO] Comparing to version: 3.5
>>>> [INFO]
>>>>
>>>> 
>>>>
>>>> [INFO] BUILD FAILURE
>>>> [INFO]
>>>>
>>>> 
>>>>
>>>> [INFO] Total time: 01:31 min
>>>> [INFO] Finished at: 2016-01-05T16:35:25+01:00
>>>> [INFO] Final Memory: 84M/812M
>>>> [INFO]
>>>>
>>>> 
>>>>
>>>> [ERROR] Failed to execute goal
>>>> org.apache.maven.plugins:maven-site-plugin:3.4:site (default-site) on
>>>> project commons-math3: Execution default-site of goal
>>>> org.apache.maven.plugins:maven-site-plugin:3.4:site failed: Invalid
>>>> byte
>>>> tag in constant pool: 18 -> [Help 1]
>>>>
>>>
>>> That's an issue I've seen with Java 8, should be OK with Java 7.
>>
>> Yes, I confirm this happens when maven is run with Java8.
> 
> So it is not possible to do "mvn site" with the currently supported version
> of Java...

mvn site is not possible as it is a maven problem.
However, building the jar is possible as the probem arise only
for site generation. I think it occurs during one of the reports
generation, as it involves parsing the class files since the tag 18
corresponds to something written by the compiler if I remember
correctly (and hence that cannot be read back by some plugin parsing
the class files and not yet Java 8 aware).

best regards,
Luc


> 
> At some point, it will be useful to list what is necessary and sufficient
> to be done and to be checked in order to release.
> 
>> If you have multiple Java versions on your machine,
> 
> I don't, at this moment.
> 
> Best regards,
> Gilles
> 
> 
>> you can do something
>> along these lines :
>>
>>  LANG=C JAVA_HOME=/usr/lib/jvm/java-1.7.0-openjdk-amd64/jre mvn site
>>
>> This sets up the language environment to a neutral choice and lets
>> maven rely on Java 7 (in this case) to avoid Java 8.
>>
>> best regards,
>> Luc
>>
>>
>>
>>>
>>> Gary
>>>
>>>
>>>> [ERROR]
>>>> [ERROR] To see the full stack trace of the errors, re-run Maven with
>>>> the
>>>> -e switch.
>>>> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
>>>> [ERROR]
>>>> [ERROR] For more information about the errors and possible solutions,
>>>> please read the following articles:
>>>> [ERROR] [Help 1]
>>>>
>>>> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
>>>>
>>>> ---CUT---
>>>>
>>>> $ mvn -v
>>>> Apache Maven 3.3.9
>>>> Maven home: /usr/share/maven
>>>> Java version: 1.8.0_72-internal, vendor: Oracle Corporation
>>>> Java home: /usr/lib/jvm/java-8-openjdk-amd64/jre
>>>> Default locale: en, platform encoding: UTF-8
>>>> OS name: "linux", version: "4.2.0-1-amd64", arch: "amd64", family:
>>>> "unix"
>>>>
>>>>
>>>> Regards,
>>>> Gilles
>>>>
>>>> best regards,
>>>>> Luc
>>>>>
>>>>> [...]
> 
> 
> -
> 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

[RESULT][VOTE][RC2] Release Commons Math 3.6

[Luc Maisonobe]

Le 02/01/2016 21:15, Luc Maisonobe a écrit :
> This is a [VOTE] for releasing Apache Commons Math 3.6 from release
> candidate 2.

This vote has PASSED, with the following votes:

+1:
 - Phil Steitz (binding)
 - Thomas Neidhart
 - Gilles Sadowski (binding)
 - Luc Maisonobe   (binding)

and no other votes.

I'll release the artifacts shortly.

Thanks to everyone who reviewed the release.

best regards,
Luc

> 
> Tag name:
>   MATH_3_6_RC2 (signature can be checked from git using 'git tag -v')
> 
> Tag URL:
> 
> <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=95a9d35e77f70ffc9bd5143880c236a760b42005>
> 
> Commit ID the tag points at:
>   95a9d35e77f70ffc9bd5143880c236a760b42005
> 
> Site:
>   <http://home.apache.org/~luc/commons-math-3.6-RC2-site>
> 
> Distribution files:
>   https://dist.apache.org/repos/dist/dev/commons/math/
> 
> Distribution files hashes (SHA1):
>  8b0b724b91102f63c7211f8de60dec19f94c4af7  commons-math3-3.6-bin.tar.gz
>  f3f2b3974e5ecd368aa3294f8c59a7aeae4c5d90  commons-math3-3.6-bin.zip
>  213985b076b344178cd2fb07e7257cb52b65e3b9  commons-math3-3.6-src.tar.gz
>  0c66a1aaf878aa7e6c0d9bbf917b25efa463b313  commons-math3-3.6-src.zip
> 
> KEYS file to check signatures:
>   http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1138/org/apache/commons/commons-math3/3.6/
> 
> [ ] +1 Release it.
> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few minor glitches: ...
> [ ] -1 No, do not release it because ...
> 
> This vote will close in 72 hours, at 2016-01-05T20:15:00Z (this is UTC
> time).
> 
> 
> 
> -
> 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: [all] Commons Parent - detach src/bin artifacts?

[Luc Maisonobe]

Le 05/01/2016 22:26, Emmanuel Bourg a écrit :
> Le 5/01/2016 21:42, Phil Steitz a écrit :
> 
>> Can you add file specs at the end to specify the .asc.md5 and
>> other cruft
> 
> I didn't see any .asc.md5 file when releasing JEXL, I guess this issue
> has been solved now?

I noticed the same thing when staging [math] artifacts on Nexus.
I only had to remove the bin and src zip and tar.gz files.

best regards,
Luc

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


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

Re: [VOTE][RC2] Release Commons Math 3.6

[Luc Maisonobe]

Le 02/01/2016 21:15, Luc Maisonobe a écrit :
> This is a [VOTE] for releasing Apache Commons Math 3.6 from release
> candidate 2.
> 
> Tag name:
>   MATH_3_6_RC2 (signature can be checked from git using 'git tag -v')
> 
> Tag URL:
> 
> <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=95a9d35e77f70ffc9bd5143880c236a760b42005>
> 
> Commit ID the tag points at:
>   95a9d35e77f70ffc9bd5143880c236a760b42005
> 
> Site:
>   <http://home.apache.org/~luc/commons-math-3.6-RC2-site>
> 
> Distribution files:
>   https://dist.apache.org/repos/dist/dev/commons/math/
> 
> Distribution files hashes (SHA1):
>  8b0b724b91102f63c7211f8de60dec19f94c4af7  commons-math3-3.6-bin.tar.gz
>  f3f2b3974e5ecd368aa3294f8c59a7aeae4c5d90  commons-math3-3.6-bin.zip
>  213985b076b344178cd2fb07e7257cb52b65e3b9  commons-math3-3.6-src.tar.gz
>  0c66a1aaf878aa7e6c0d9bbf917b25efa463b313  commons-math3-3.6-src.zip
> 
> KEYS file to check signatures:
>   http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1138/org/apache/commons/commons-math3/3.6/
> 
> [X] +1 Release it.

Luc

> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few minor glitches: ...
> [ ] -1 No, do not release it because ...
> 
> This vote will close in 72 hours, at 2016-01-05T20:15:00Z (this is UTC
> time).
> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


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

Re: "[VOTE][RC1] Release Commons Math 3.6

[Luc Maisonobe]

Le 02/01/2016 06:56, Phil Steitz a écrit :
> I have found no blockers thus far, but I am struggling to get the
> Ant build to work, in part so I can verify that the tests run
> against the release jar.  I am getting (understandable) errors when
> the ant test runner tries to execute
> AbstractAdamsFieldIntegratorTest and some other abstract tests. 
> What I don't get is that the pom appears to exclude only
> **/*AbstractTest.java which will not filter these tests out but they
> are not executed in the maven build.  Ant has the same filter and
> tries to execute them.  What am I missing?  I can't add an exclusion
> for **/Abstract*.java because we have non-abstract test classes
> named that way.  Is the surefire runner smart enough to skip these
> by itself somehow?

Perhaps. I could simply rename this base class
AdamsFieldIntegratorAbstractTest.

Best regards,
Luc


> 
> Phil
> 
> On 1/1/16 9:23 AM, Luc Maisonobe wrote:
>> This is a [VOTE] for releasing Apache Commons Math 3.6 from release
>> candidate 1.
>>
>> Tag name:
>>   MATH_3_6_RC1 (signature can be checked from git using 'git tag -v')
>>
>> Tag URL:
>>
>> <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=2525399e1654530f1eff026cf3a16e473cd07296>
>>
>> Commit ID the tag points at:
>>   2525399e1654530f1eff026cf3a16e473cd07296
>>
>> Site:
>>   <http://home.apache.org/~luc/commons-math-3.6-RC1-site>
>>
>> Distribution files:
>>   https://dist.apache.org/repos/dist/dev/commons/math/
>>
>> Distribution files hashes (SHA1):
>>  a41da1d7e9368132c7273c13ca760b6abaf0d3f6  commons-math3-3.6-bin.tar.gz
>>  ba2a94aee57f5bf6ce8b0afd0ef6362d724b139c  commons-math3-3.6-bin.zip
>>  008a3d156b59a78b98452684e9fe995676f1b773  commons-math3-3.6-src.tar.gz
>>  cb57f642ae87c20c8b084854a4dfcaf73a70998c  commons-math3-3.6-src.zip
>>
>> KEYS file to check signatures:
>>   http://www.apache.org/dist/commons/KEYS
>>
>> Maven artifacts:
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-051/org/apache/commons/commons-math3/3.4/
>>
>> [ ] +1 Release it.
>> [ ] +0 Go ahead; I don't care.
>> [ ] -0 There are a few minor glitches: ...
>> [ ] -1 No, do not release it because ...
>>
>> This vote will close in 72 hours, at 2016-01-04T16:30:00Z (this is UTC
>> time).
>>
>> -
>> 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: [math] Fixed ant build.

[Luc Maisonobe]

Le 02/01/2016 19:23, Phil Steitz a écrit :
> On 1/2/16 11:04 AM, Luc Maisonobe wrote:
>> Hi Phil,
>>
>>
>> Le 02/01/2016 18:26, pste...@apache.org a écrit :
>>> Repository: commons-math
>>> Updated Branches:
>>>   refs/heads/MATH_3_X c5e6ccb81 -> 68194a3bf
>>>
>>>
>>> Fixed ant build.
>> Do you want me to run another RC?
> 
> I was about to say no, and  you can see I just voted, but after
> finding an old 1.5 JDK, I just ran into this:
> 
> java/org/apache/commons/math3/random/BitsStreamGenerator.java:190:
> method does not override a method from its superclass
> [javac] @Override
> [javac]  ^
> 
> I think this snuck in after Thomas fixed these 1.5 compilation issues.
> 
> I am not sure if this is a blocker.  It means you can't build the
> code using a way end of life JDK.  But the (slightly fixed)
> test-jar.xml run under JDK 1.5 runs clean (so people just using the
> jar with 1.5 should not have a problem).
> 
>  There is one spurious test failure when the tests are run against
> the release jar under 1.5:
> 
> Testcase:
> testCreateFromIntegers(org.apache.commons.math3.distribution.EnumeratedIntegerDistributionTest):
>
> FAILED
> expected:<0.5> but was:<0.5001>
> junit.framework.AssertionFailedError: expected:<0.5> but
> was:<0.5001>
> 
> The test case uses 0 as the tolerance.  Newer JDKs get this exactly,
> but the 1.5 I have at least fails as above.

OK. I'll cut another RC.

best regards,
Luc

> 
> Phi
>>
>> best regards,
>> Luc
>>
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/commons-math/commit/68194a3b
>>> Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/68194a3b
>>> Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/68194a3b
>>>
>>> Branch: refs/heads/MATH_3_X
>>> Commit: 68194a3bf5496966ecfdfe1161ae91744782f670
>>> Parents: c5e6ccb
>>> Author: Phil Steitz <phil.ste...@gmail.com>
>>> Authored: Sat Jan 2 10:25:49 2016 -0700
>>> Committer: Phil Steitz <phil.ste...@gmail.com>
>>> Committed: Sat Jan 2 10:25:49 2016 -0700
>>>
>>> --
>>>  build.xml| 23 +--
>>>  test-jar.xml | 50 --
>>>  2 files changed, 33 insertions(+), 40 deletions(-)
>>> --
>>>
>>>
>>> http://git-wip-us.apache.org/repos/asf/commons-math/blob/68194a3b/build.xml
>>> --
>>> diff --git a/build.xml b/build.xml
>>> index 89cc433..3e97317 100644
>>> --- a/build.xml
>>> +++ b/build.xml
>>> @@ -30,12 +30,12 @@
>>>  
>>>  
>>>  
>>> +  >> "${user.home}/.m2/repository"/>
>>>  
>>>
>>> -  
>>> -  
>>> -  >> value="${junit.home}/junit-${junit.version}.jar"/>
>>> -
>>> +  
>>> +  >> value="$junit-{junit.version}.jar"/>
>>> +  
>>>  
>>>  
>>>  
>>> @@ -50,7 +50,7 @@
>>>
>>>  
>>>
>>> -  
>>> +  
>>>  
>>>
>>>
>>> @@ -111,6 +111,7 @@
>>>
>>>
>>>  >> location="${download.lib.dir}/junit-${junit.version}.jar"/>
>>> +   
>>>
>>>  
>>>  
>>> @@ -121,6 +122,7 @@
>>>  
>>>  
>>>  
>>> +   
>>>  
>>>
>>>  
>>> @@ -343,9 +345,10 @@
>>>  
>>>  
>>>  >> -   depends="check-availability" unless="skip.download">
>>> + depends="check-availability" unless="skip.download">
>>>  
>>>  
>>> +
>>>  
>>>  
>>>  
>>> @@ -360,6 +363,14 @@
>>>  usetimestamp="true" ignoreerrors="true"
>>>  
>>> src="http://repo1.maven.org/maven2/junit/junit/${junit.version}/junit-${junit.version}.jar"/>
>>>  
>>> +
>>> +   
>>> +   
>>> +   

[VOTE][RC2] Release Commons Math 3.6

[Luc Maisonobe]

This is a [VOTE] for releasing Apache Commons Math 3.6 from release
candidate 2.

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

Tag URL:

<https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=95a9d35e77f70ffc9bd5143880c236a760b42005>

Commit ID the tag points at:
  95a9d35e77f70ffc9bd5143880c236a760b42005

Site:
  <http://home.apache.org/~luc/commons-math-3.6-RC2-site>

Distribution files:
  https://dist.apache.org/repos/dist/dev/commons/math/

Distribution files hashes (SHA1):
 8b0b724b91102f63c7211f8de60dec19f94c4af7  commons-math3-3.6-bin.tar.gz
 f3f2b3974e5ecd368aa3294f8c59a7aeae4c5d90  commons-math3-3.6-bin.zip
 213985b076b344178cd2fb07e7257cb52b65e3b9  commons-math3-3.6-src.tar.gz
 0c66a1aaf878aa7e6c0d9bbf917b25efa463b313  commons-math3-3.6-src.zip

KEYS file to check signatures:
  http://www.apache.org/dist/commons/KEYS

Maven artifacts:

https://repository.apache.org/content/repositories/orgapachecommons-1138/org/apache/commons/commons-math3/3.6/

[ ] +1 Release it.
[ ] +0 Go ahead; I don't care.
[ ] -0 There are a few minor glitches: ...
[ ] -1 No, do not release it because ...

This vote will close in 72 hours, at 2016-01-05T20:15:00Z (this is UTC
time).



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

[CANCELED][VOTE][RC1] Release Commons Math 3.6

[Luc Maisonobe]

Le 01/01/2016 17:23, Luc Maisonobe a écrit :
> This is a [VOTE] for releasing Apache Commons Math 3.6 from release
> candidate 1.

This vote is canceled, in order to fix some issues with Java 5.

Thanks to thos who reviewed the release.

best regards,
Luc

> 
> Tag name:
>   MATH_3_6_RC1 (signature can be checked from git using 'git tag -v')
> 
> Tag URL:
> 
> <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=2525399e1654530f1eff026cf3a16e473cd07296>
> 
> Commit ID the tag points at:
>   2525399e1654530f1eff026cf3a16e473cd07296
> 
> Site:
>   <http://home.apache.org/~luc/commons-math-3.6-RC1-site>
> 
> Distribution files:
>   https://dist.apache.org/repos/dist/dev/commons/math/
> 
> Distribution files hashes (SHA1):
>  a41da1d7e9368132c7273c13ca760b6abaf0d3f6  commons-math3-3.6-bin.tar.gz
>  ba2a94aee57f5bf6ce8b0afd0ef6362d724b139c  commons-math3-3.6-bin.zip
>  008a3d156b59a78b98452684e9fe995676f1b773  commons-math3-3.6-src.tar.gz
>  cb57f642ae87c20c8b084854a4dfcaf73a70998c  commons-math3-3.6-src.zip
> 
> KEYS file to check signatures:
>   http://www.apache.org/dist/commons/KEYS
> 
> Maven artifacts:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-051/org/apache/commons/commons-math3/3.4/
> 
> [ ] +1 Release it.
> [ ] +0 Go ahead; I don't care.
> [ ] -0 There are a few minor glitches: ...
> [ ] -1 No, do not release it because ...
> 
> This vote will close in 72 hours, at 2016-01-04T16:30:00Z (this is UTC
> time).
> 
> -
> 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: [math] Fixed ant build.

[Luc Maisonobe]

Hi Phil,


Le 02/01/2016 18:26, pste...@apache.org a écrit :
> Repository: commons-math
> Updated Branches:
>   refs/heads/MATH_3_X c5e6ccb81 -> 68194a3bf
> 
> 
> Fixed ant build.

Do you want me to run another RC?

best regards,
Luc

> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-math/commit/68194a3b
> Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/68194a3b
> Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/68194a3b
> 
> Branch: refs/heads/MATH_3_X
> Commit: 68194a3bf5496966ecfdfe1161ae91744782f670
> Parents: c5e6ccb
> Author: Phil Steitz <phil.ste...@gmail.com>
> Authored: Sat Jan 2 10:25:49 2016 -0700
> Committer: Phil Steitz <phil.ste...@gmail.com>
> Committed: Sat Jan 2 10:25:49 2016 -0700
> 
> --
>  build.xml| 23 +--
>  test-jar.xml | 50 --
>  2 files changed, 33 insertions(+), 40 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/commons-math/blob/68194a3b/build.xml
> --
> diff --git a/build.xml b/build.xml
> index 89cc433..3e97317 100644
> --- a/build.xml
> +++ b/build.xml
> @@ -30,12 +30,12 @@
>  
>  
>  
> +   "${user.home}/.m2/repository"/>
>  
>
> -  
> -  
> -   value="${junit.home}/junit-${junit.version}.jar"/>
> -
> +  
> +   value="$junit-{junit.version}.jar"/>
> +  
>  
>  
>  
> @@ -50,7 +50,7 @@
>
>  
>
> -  
> +  
>  
>
>
> @@ -111,6 +111,7 @@
>
>
>  
> + 
>
>  
>  
> @@ -121,6 +122,7 @@
>  
>  
>  
> + 
>  
>
>  
> @@ -343,9 +345,10 @@
>  
>  
>   -   depends="check-availability" unless="skip.download">
> + depends="check-availability" unless="skip.download">
>  
>  
> +
>  
>  
>  
> @@ -360,6 +363,14 @@
>  usetimestamp="true" ignoreerrors="true"
>  
> src="http://repo1.maven.org/maven2/junit/junit/${junit.version}/junit-${junit.version}.jar"/>
>  
> +
> + 
> + 
> + 
> +  + usetimestamp="true" ignoreerrors="true"
> + 
> src="http://repo1.maven.org/maven2/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar"/>
> + 
>
>  
>  
> 
> http://git-wip-us.apache.org/repos/asf/commons-math/blob/68194a3b/test-jar.xml
> --
> diff --git a/test-jar.xml b/test-jar.xml
> index c6e12ec..e5a20a5 100644
> --- a/test-jar.xml
> +++ b/test-jar.xml
> @@ -21,25 +21,23 @@
> Compiles and runs unit tests against distribution jar(s).  Use .antrc or 
> the 
> command line to control the jdk used to execute this build file.  
> 
> -   Assumes that the distribution jar to be tested is in the base directory. 
> -   Use the "jardir" property to specify the path to the directory containing
> -   the jar. Any other jars in this directory will also be added to the
> -   classpath.  
> +   Assumes that the distribution jar to be tested is in the basedir/lib, 
> along
> +   with any dependent jars (junit, hamcrest). Use the "libdir" property to 
> specify
> +   the path to the directory containing these jars. 
> 
> The default target, "test," executes clean as a dependency.
>  -->
>
>  
> -  
> -  
> +  
>
>
>
> -  
> -   
> +  
> +  
> +  
>  
> -  
> -  
> +  
>  
>
>
> @@ -58,24 +56,17 @@
>  Java library path: ${java.library.path}
>  
> ===
>  
> -
> -
> -  
> -  
> -
> -
> -
> -
>
> depends="internal-test">
>  
>  
>
> -  
> +  
>  
> - fork="true" haltonerror="true">
> + +   fork="true" haltonerror="true" showOutput="true">
>
> -  
> +  
>
>  
>  
> @@ -88,14 +79,7 @@
>
>  
>
> -  
> -  
> -= WARNING 
> 
> -Junit isn't present in your ${ANT_HOME}/lib directory. Tests not 
> executed.
> -
> ==
> -  
> -  
> -  
> +  
>  
>optimize="false" excludes="**/package.html">
> @@ -106,12 +90,10 @@
>  
>
>  
> -
> -  
> -
> -
> + 
> +   
>
> -
> + 
>
>  
>  
> 
> 


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

Re: [math] Updated released howto after change from people to home.apache.org.

[Luc Maisonobe]

Le 01/01/2016 21:28, Phil Steitz a écrit :
> On 1/1/16 11:59 AM, l...@apache.org wrote:
>> Repository: commons-math
>> Updated Branches:
>>   refs/heads/MATH_3_X 77f0f2025 -> 445f091bc
>>
>>
>> Updated released howto after change from people to home.apache.org.
>>
>> Shell access is not possible anymore on home.apache.org, so the site
>> uplaoding must be done using sftp only.
> 
> Given the painfulness of that and the fact that the site is not what
> we are releasing, I think we should drop the site staging from the
> release process.  

I would be happy to drop it too!
Uploading the site is also painfully slow. I think it took about
two hours, for the 7081 files in the site.

best regards,
Luc

> 
> Phil
>>
>> Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
>> Commit: http://git-wip-us.apache.org/repos/asf/commons-math/commit/445f091b
>> Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/445f091b
>> Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/445f091b
>>
>> Branch: refs/heads/MATH_3_X
>> Commit: 445f091bcd93d76559279032865b26ffb46aa749
>> Parents: 77f0f20
>> Author: Luc Maisonobe <l...@apache.org>
>> Authored: Fri Jan 1 19:59:33 2016 +0100
>> Committer: Luc Maisonobe <l...@apache.org>
>> Committed: Fri Jan 1 19:59:33 2016 +0100
>>
>> --
>>  doc/release/release.howto.txt | 21 +++--
>>  1 file changed, 11 insertions(+), 10 deletions(-)
>> --
>>
>>
>> http://git-wip-us.apache.org/repos/asf/commons-math/blob/445f091b/doc/release/release.howto.txt
>> --
>> diff --git a/doc/release/release.howto.txt b/doc/release/release.howto.txt
>> index b620e55..a667aa2 100644
>> --- a/doc/release/release.howto.txt
>> +++ b/doc/release/release.howto.txt
>> @@ -313,18 +313,19 @@ edit README.html with released version number
>>  (13)
>>  As the web site staging area is shared among all commons components and 
>> therefore
>>  can be published before vote ends, it is not recommended to use the 
>> standard staging
>> -area for the release candidate. So you will just archive the site and 
>> transfer it on
>> -your apache personal area for review:
>> +area for the release candidate. So you will just archive the transfer the 
>> site it on
>> +your apache personal area for review. Here is how to do this using lftp to 
>> initiate
>> +the sftp transfer (lftp supports a mirror command for recursive transfers, 
>> don't
>> +forget the -R flag for uploading instead of downloading the site):
>>  
>>$ mvn site
>>$ cd target
>> -  $ tar czf site.tar.gz site
>> -  $ scp site.tar.gz __your_apache_logi...@people.apache.org:~/
>> -  $ ssh __your_apache_logi...@people.apache.org
>> - you@minotaur:~$ tar xzf site.tar.gz
>> - you@minotaur:~$ mv site public_html/commons-math-3.4-RC1-site
>> - you@minotaur:~$ rm site.tar.gz
>> - you@minotaur:~$ logout
>> +  $ mv site commons-math-3.4-RC1-site
>> +  $ lftp sftp://__your_apache_logi...@home.apache.org/
>> + lftp y...@home.apache.org:~> cd public_html
>> + lftp y...@home.apache.org:~/public_html> mirror -R 
>> commons-math-3.4-RC1-site
>> + lftp y...@home.apache.org:~/public_html> bye
>> +
>>  
>>  (14)
>>  Call to vote by sending a message to the "dev" ML with subject
>> @@ -343,7 +344,7 @@ Commit ID the tag points at:
>>cf4a9d70c9ac24dd7196995390171150e4e56451
>>  
>>  Site:
>> -  
>> <http://people.apache.org/~__Your_apache_login__/commons-math-3.4-RC1-site>
>> +  <http://home.apache.org/~__Your_apache_login__/commons-math-3.4-RC1-site>
>>  
>>  Distribution files:
>>https://dist.apache.org/repos/dist/dev/commons/math/
>>
>>
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


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

Re: "[VOTE][RC1] Release Commons Math 3.6

[Luc Maisonobe]

Le 01/01/2016 17:47, Gilles a écrit :
> Hi.
> 
> On Fri, 1 Jan 2016 17:23:58 +0100, Luc Maisonobe wrote:
>> This is a [VOTE] for releasing Apache Commons Math 3.6 from release
>> candidate 1.
> 
> There is a spurious quotation mark in the mail's subject line (just
> in case someone's automatic filter would discard it).
> 
>>
>> Tag name:
>>   MATH_3_6_RC1 (signature can be checked from git using 'git tag -v')
>>
>> Tag URL:
>>
>>
>> <https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=2525399e1654530f1eff026cf3a16e473cd07296>
>>
>>
>> Commit ID the tag points at:
>>   2525399e1654530f1eff026cf3a16e473cd07296
>>
>> Site:
>>   <http://home.apache.org/~luc/commons-math-3.6-RC1-site>
>>
>> Distribution files:
>>   https://dist.apache.org/repos/dist/dev/commons/math/
>>
>> Distribution files hashes (SHA1):
>>  a41da1d7e9368132c7273c13ca760b6abaf0d3f6  commons-math3-3.6-bin.tar.gz
>>  ba2a94aee57f5bf6ce8b0afd0ef6362d724b139c  commons-math3-3.6-bin.zip
>>  008a3d156b59a78b98452684e9fe995676f1b773  commons-math3-3.6-src.tar.gz
>>  cb57f642ae87c20c8b084854a4dfcaf73a70998c  commons-math3-3.6-src.zip
>>
>> KEYS file to check signatures:
>>   http://www.apache.org/dist/commons/KEYS
>>
>> Maven artifacts:
>>
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-051/org/apache/commons/commons-math3/3.4/
>>
> 
> ---
> 404 - Repository with ID="orgapachecommons-051" not found
> ---
> 
> But I found something there:
> 
>  
> https://repository.apache.org/content/repositories/orgapachecommons-1137/org/apache/commons/commons-math3/3.6/

Yes. Sorry it is a copy-paste error from the template. The correct link
is the one you gave.


best regards,
Luc

> 
> 
> Regards,
> Gilles
> 
>>
>> [ ] +1 Release it.
>> [ ] +0 Go ahead; I don't care.
>> [ ] -0 There are a few minor glitches: ...
>> [ ] -1 No, do not release it because ...
>>
>> This vote will close in 72 hours, at 2016-01-04T16:30:00Z (this is UTC
>> time).
>>
> 
> 
> -
> 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

"[VOTE][RC1] Release Commons Math 3.6

[Luc Maisonobe]

This is a [VOTE] for releasing Apache Commons Math 3.6 from release
candidate 1.

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

Tag URL:

<https://git-wip-us.apache.org/repos/asf?p=commons-math.git;a=commit;h=2525399e1654530f1eff026cf3a16e473cd07296>

Commit ID the tag points at:
  2525399e1654530f1eff026cf3a16e473cd07296

Site:
  <http://home.apache.org/~luc/commons-math-3.6-RC1-site>

Distribution files:
  https://dist.apache.org/repos/dist/dev/commons/math/

Distribution files hashes (SHA1):
 a41da1d7e9368132c7273c13ca760b6abaf0d3f6  commons-math3-3.6-bin.tar.gz
 ba2a94aee57f5bf6ce8b0afd0ef6362d724b139c  commons-math3-3.6-bin.zip
 008a3d156b59a78b98452684e9fe995676f1b773  commons-math3-3.6-src.tar.gz
 cb57f642ae87c20c8b084854a4dfcaf73a70998c  commons-math3-3.6-src.zip

KEYS file to check signatures:
  http://www.apache.org/dist/commons/KEYS

Maven artifacts:

https://repository.apache.org/content/repositories/orgapachecommons-051/org/apache/commons/commons-math3/3.4/

[ ] +1 Release it.
[ ] +0 Go ahead; I don't care.
[ ] -0 There are a few minor glitches: ...
[ ] -1 No, do not release it because ...

This vote will close in 72 hours, at 2016-01-04T16:30:00Z (this is UTC
time).

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

Re: [math] RealMatrixFormat.parse()

[Luc Maisonobe]

Le 31/12/2015 04:33, Ole Ersoy a écrit :
> Hi,
> 
> In RealMatrixFormat.parse() MatrixUtils makes the decision on what type
> of RealMatrix instance to return.  Flexibility is gained if it just
> returns double[][] letting the caller decide what type of RealMatrix
> instance to create.  It's also better for modularity, as is reduces
> RealMatrixFormat imports (The MatrixUtils supports Field matrices as
> well, and I'm attempting to separate real and field matrices into two
> difference modules).
> 
> Also just curious if Array2DRowRealMatrix is worth keeping?  It seems
> like the performance of BlockRealMatrix might be just as good or better
> regardless of matrix size ... although my testing is limited.

As far as I am concerned, Array2DRowRealMatrix is used in places where
I want to avoid copying the data. The can occur both at construction
and at data retrieval. See the constructor with the boolean to simply
reuse an allocated array rather, and see the getDataRef getter.

Of course, using this feature is rather expert use. Typically, it is
done when some algorithm creates the data array by itself, and then
wants to return it as a matrix, but will not use the array by itself
anymore. In this case, transfering ownership of the array to the matrix
instance is not a bad thing, particularly if the array is big.

I agree this case is really specific so it may not be sufficient to keep
this class (or to keep the constructor and the special getter).

best regards,
Luc

> 
> Cheers,
> Ole
> 
> -
> 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: [math] releasing 3.6

[Luc Maisonobe]

Hi Rostislav,

Le 31/12/2015 13:43, Rostislav Krasny a écrit :
> On Tue, Dec 29, 2015 at 8:39 PM, Luc Maisonobe <l...@spaceroots.org> wrote:
>> Hi all,
>>
>> A few weeks ago, I proposed to release 3.6. There were two
>> points I wanted to address before that, both related to
>> ODE. These points are now completed: the Adams methods
>> stability issues have been fixed, and a bunch a field-based
>> integrators are available.
>>
>> There are 3 issues in JIRA that are tagged for 3.6:
>>
>>  - MATH-1281 "Median" should not extend "Percentile"
>>  - MATH-1285 Description API ZipfDistribution
>>  - MATH-1308 Deprecate and remove "AbstractRandomGenerator"
> 
> What about MATH-1300 plus MATH-1304 plus MATH-1305?
> Could Gilles commits be back ported into 3.6?

Yes, they could be ported back to 3.6.

Gilles, would you mind doing that?


> There is no API change like in MATH-1308 and MATH-1307 and IMHO they
> are safe for the back port.
> BTW I don't know why MATH-1300, MATH-1304 and MATH-1305 are not marked
> as resolved yet.
> Aren't they?

I think they could.

> 
> P.S. when CM 4.0 is expected to be released?

Nobody knows. There are many things that we want to do and we didn't
even started them. The most obvious case is optimizers and fluent API.
This is something I have on my plate since more than one year :-(

best regards,
Luc


> 
> -
> 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: [math] RealMatrixPreservingVisitor and RealMatrixChangingVisitor the same?

[Luc Maisonobe]

Le 30/12/2015 20:18, Ole Ersoy a écrit :
> Hi Luc,
> 
> On 12/30/2015 03:55 AM, Luc Maisonobe wrote:
>> Le 30/12/2015 06:18, Ole Ersoy a écrit :
>>> Hi,
>> Hi Ole,
>>
>>> RealMatrixPreservingVisitor and RealMatrixChangingVisitor files look
>>> identical with the exception of a single @see Default... annotation
>>> (Which I think is redundant...same as > All known implementing
>>> classes...?).  Would it make sense to remove the annotation and have ons
>>> RealMatrixChangingVisitor extend RealMatrixPreservingVisitor?
>> No. They are different and used for different things.
>> The visit method returns void in one case and double in another
>> case. When it returns double, this double is used to update
>> the matrix that is visited, hence the "Changing" nature of the
>> visitor.
> Aha - Figured I was missing something - thanks for explaining.  What do
> you think about removing the @see annotation (IIUC javadoc generates a
> link to implementing classes) and having the changing visitor extend the
> preserving one while overriding `visit()`?

This would defeat the purpose of the overloaded signatures for the
various walk methods in RealMatrix.
There would also be an ambiguity when calling visit and ignoring the
returned value: would it be a call to the void method in the super
interface or a call to the new method in the lower interface? I don't
even think it is possible to override something based only on the return
type.

> 
> Also could you help me understand what the start() and() end methods are
> for?  Is there some test code I can look at (I did scan
> BlockRealMatrixTest)?

These methods are used before and after the walk. They are typically
used for initialization for the first one and to gather some results
for the second one.
You can see an exemple in the Adams-Moulton ODE integrator (package
org.apache.commons.math[34].ode.nonstiff. There is an internal class
named Corrector that implements RealMatrixPreservingVisitor.

best regards,
Luc

> 
> Cheers,
> Ole
> 
> -
> 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: [math] RealMatrixPreservingVisitor and RealMatrixChangingVisitor the same?

[Luc Maisonobe]

Le 30/12/2015 06:18, Ole Ersoy a écrit :
> Hi,

Hi Ole,

> 
> RealMatrixPreservingVisitor and RealMatrixChangingVisitor files look
> identical with the exception of a single @see Default... annotation
> (Which I think is redundant...same as > All known implementing
> classes...?).  Would it make sense to remove the annotation and have one
> RealMatrixChangingVisitor extend RealMatrixPreservingVisitor?

No. They are different and used for different things.
The visit method returns void in one case and double in another
case. When it returns double, this double is used to update
the matrix that is visited, hence the "Changing" nature of the
visitor.

best regards,
Luc

> 
> Cheers,
> Ole
> 
> -
> 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: [Math] About the refactoring of RNGs

[Luc Maisonobe]

hi all,

Le 29/12/2015 18:32, Phil Steitz a écrit :
> 
> 
>> On Dec 29, 2015, at 8:41 AM, Gilles <gil...@harfang.homelinux.org>
>> wrote:
>> 
>>> On Mon, 28 Dec 2015 20:33:24 -0700, Phil Steitz wrote:
>>>> On 12/28/15 8:08 PM, Gilles wrote:
>>>>> On Mon, 28 Dec 2015 11:08:56 -0700, Phil Steitz wrote: The
>>>>> significant refactoring to eliminate the (standard)
>>>>> next(int) included in these changes has the possibility of
>>>>> introducing subtle bugs or performance issues.  Please run
>>>>> some tests to verify that the same sequences are generated by
>>>>> the 3_X code
>>>> 
>>>> IIUC our unit tests of the RNGs, this is covered.
>>> 
>>> No.  Not sufficient.  What you have done is changed the internal 
>>> implementation of all of the Bitstream generators.  I am not 
>>> convinced that you have not broken anything.  I will have to do
>>> the testing myself.  I see no point in fiddling with the
>>> internals of this code that has had a lot of eyeballs and testing
>>> on it.  I was not personally looking forward to researching the
>>> algorithms to make sure any invariants may be broken by these
>>> changes; but I am now going to have to do this.  I have to ask
>>> why.  Please at some point read [1], especially the sections on
>>> "Avoid Flexibility Syndrom" and "Value Laziness as a Virtue."
>>> Gratuitous refactoring drains community energy.
>> 
>> It seems that again you don't read what I write.[1] Hence the above
>> paragraph is spreading F -> "I am not convinced that you have not
>> broken anything." U -> "I will have to do the testing myself." D ->
>> "I see no point in fiddling [...]" .
>> 
>> Or maybe I have to rant about email communication. Please reread
>> the thread to fully appreciate that you could have shared your
>> doubts among the opinions which you gave about some of my
>> questions. When the reply answers to only some of the direct
>> questions, the OP is legitimately tempted to assume that the
>> non-comment is akin to "I don't care" (as in "left to the judgment
>> of the one who does the job").
>> 
>> As is often the case, you can dislike my ideas of improvements
>> (ideas that come on the basis of the information provided by what
>> the code does) but I don't appreciate the use of the word
>> "gratuitous", given that I clearly stated the purpose of making
>> explicit what the code actually does (that is, *generating* 32
>> random bits and not the number of bits passed as a parameter to
>> "next(int)"). So, the code is now self-documenting; it is a small
>> change, to be sure, but hardly gratuitous.
> 
> I did not respond to the original question about eliminating
> next(int) because I was not (still am not) expert in the internals of
> how the generators work and how the generated ints-of-bits are
> transformed to make doubles, gaussians, etc.  I was hoping someone
> who was expert would chime in and say either "don't do that" or
> "that's ok".

I intend to look at these changes, but concentrated on the last
things I wanted to be included in 3.6 (another mail will come
about this later this evening).

I am not an expert either on PRNG, but did work on some of the
implementations we have, so maybe I will be able to give an
opinion.

One thing we coud do is set up a branch for such an experimentation.
Branches in Git are simple. The work could then be merged back
to master once it has stabilized. It would also be easy for any
developer to switch back and forth between this feature branch
and master to get convinced there are no hidden problems.

> That did not happen before you committed the changes.
> That obligates us to review them.  The tests cover only nextInt so
> we need to convince ourselves that the transformations (which have
> all changed) are still correct.  That is in my mind just extra work
> generated for the community.  I would rather see our cycles go toward
> getting 3.6 out.

So let the dust settle down for a few days, I would really like
to finalize 3.6 too.

best regards,
Luc

> 
> I stand by my assertion that the rebasing to eliminate next(bits)
> adds nothing. If you can demonstrate via benchmarks this it is
> faster, I will retract that statement.
> 
> I know we disagree fundamentally on the priorities of [math].  To me,
> stability, correctness and ease of use (including ease of upgrades)
> are paramount.  That means you don't make implementation changes to
> hardened code wi

[math] releasing 3.6

[Luc Maisonobe]

Hi all,

A few weeks ago, I proposed to release 3.6. There were two
points I wanted to address before that, both related to
ODE. These points are now completed: the Adams methods
stability issues have been fixed, and a bunch a field-based
integrators are available.

There are 3 issues in JIRA that are tagged for 3.6:

 - MATH-1281 "Median" should not extend "Percentile"
 - MATH-1285 Description API ZipfDistribution
 - MATH-1308 Deprecate and remove "AbstractRandomGenerator"

MATH-1281 could probably not be solved in 3.6 (or in any 3.X),
so I suggest to simply retag it for 4.0 only.

MATH-1285 seems complete to me, so I suggest to resolve it.

MATH-1308 is more 4.0-oriented and subject to experimentation.
As we can do what we want in 4.0, it seems possible to *not*
deprecate the class in 3.6, even if it completely disappears
in 4.0 (furthermore as users probably are more concerned with
the upper RandomGenerator interface or the lower specific
implementations than with the intermedaite abstract class).

If you agree with this, I could cut an RC as soon as tomorrow,
targeting a release for 2016-01-01 (so I would also change the
copyright years throughout the library).

What do you think?

best regards,
Luc

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

Re: [math] releasing 3.6

[Luc Maisonobe]

Le 29/12/2015 20:48, Phil Steitz a écrit :
> 
> 
>> On Dec 29, 2015, at 11:39 AM, Luc Maisonobe <l...@spaceroots.org>
>> wrote:
>> 
>> Hi all,
>> 
>> A few weeks ago, I proposed to release 3.6. There were two points I
>> wanted to address before that, both related to ODE. These points
>> are now completed: the Adams methods stability issues have been
>> fixed, and a bunch a field-based integrators are available.
>> 
>> There are 3 issues in JIRA that are tagged for 3.6:
>> 
>> - MATH-1281 "Median" should not extend "Percentile" - MATH-1285
>> Description API ZipfDistribution - MATH-1308 Deprecate and remove
>> "AbstractRandomGenerator"
>> 
>> MATH-1281 could probably not be solved in 3.6 (or in any 3.X), so I
>> suggest to simply retag it for 4.0 only.
>> 
>> MATH-1285 seems complete to me, so I suggest to resolve it.
>> 
>> MATH-1308 is more 4.0-oriented and subject to experimentation. As
>> we can do what we want in 4.0, it seems possible to *not* deprecate
>> the class in 3.6, even if it completely disappears in 4.0
>> (furthermore as users probably are more concerned with the upper
>> RandomGenerator interface or the lower specific implementations
>> than with the intermedaite abstract class).
>> 
>> If you agree with this, I could cut an RC as soon as tomorrow, 
>> targeting a release for 2016-01-01 (so I would also change the 
>> copyright years throughout the library).
>> 
>> What do you think?
> 
> +1 to issue comments.
> 
> I am working on 2 other things that I would like to get into 3.6 if
> possible.
> 
> 1. Fix javadoc to allow Java 8 build.
> 
> 2. Implement efficient 2-sample small sample exact KS.  I have found
> a reference and started work on this.  The current default impl uses
> Monte Carlo for relatively small samples and the convergence is poor,
> leading to dubious results. I would really like to fix this.
> 
> How about giving me until Friday before RCs start?  If I don't finish
> neither is a blocker for 3.6.  Thanks for pushing this along.

Sure. I'll wait until Friday.

best regards,
Luc

> 
> Phil
>> 
>> best regards, Luc
>> 
>> -
>>
>> 
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: [Math] About the refactoring of RNGs (Was: [01/18] [math] MATH-1307)

[Luc Maisonobe]

ntations, that was the only place where the "bits"
>>> parameter was used, from which I concluded that the randomness
>>> provider does not care if the request was to create less than 32
>>> random bits.
>>> Taking "nextBoolean()" for example, it looks like a waste of 31
>>> bits (or am I missing something?).
>>
>> Quite possibly, yes, you are missing something.

I would guess it is linked to performance consideration. Pseudo
random number generation is sometimes put under very heavy stress
with billions of numbers generated. It should run extremelly fast,
and the algorithms have been designed to have tremendously long periods
(things like 2^19937 -1). With such long periods, we can waste 31
bits each time we produce 1 bit if it saves some overhead.

best regards,
Luc

>>>
>>> Of course, if some implementation were able to store the bits not
>>> requested by the last call to "next(int)", then I'd understand that
>>> we must really provide access to a "next(int)" method.
>>>
>>> Perhaps that the overhead of such bookkeeping is why the practical
>>> algorithms chose to store integers rather than bits (?).
>>>
>>> As you dismissed my request about CM being able to care for a RNG
>>> implementation based on a "long", I don't quite understand the
>>> caring for a "next(int)" that serves no more purpose (as of current
>>> CM).
>>>
>> This change is
>>>
>>> Gilles
>>>
>>>
>>>> Phil
>>>>
>>>> On 12/28/15 10:23 AM, er...@apache.org wrote:
>>>>> Repository: commons-math
>>>>> Updated Branches:
>>>>>   refs/heads/master 7b62d0155 -> 81585a3c4
>>>>>
>>>>>
>>>>> MATH-1307
>>>>>
>>>>> New base class for RNG implementations.
>>>>> The source of randomness is provided through the "nextInt()"
>>>>> method (to be defined in subclasses).
>>>>>
>>>>>
>>>>> [...]
>>>
>> [1] http://www.apachecon.com/eu2007/materials/ac2006.2.pdf
>>>
>>> -
>>> 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
> 
> 


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

Re: [Math] New base class for all RNGs

[Luc Maisonobe]

Le 26/12/2015 18:52, Gilles a écrit :
> Hi.
> 
> There are currently two RNG hierarchies: "AbstractRandomGenerator" and
> "BitsStreamGenerator". They both implement the "RandomGenerator" interface.
> 
> In both classes, the "nextBytes(byte[])" method generates 4 bytes at a
> time.
> Thus, functionally the code is the same, even though one calls "nextInt"
> and
> the other "next(32)" (which is what its "nextInt()" also calls).
> 
> I propose that a new base class implements "nextBytes" (and perhaps other
> methods that can be coded in a generic way):
>   https://issues.apache.org/jira/browse/MATH-1307
> 
> Are there objections?

Go for it.

Luc

> 
> 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: [math] Exception Design

[Luc Maisonobe]

Le 25/12/2015 04:46, Gilles a écrit :
> On Thu, 24 Dec 2015 16:56:54 +0100, Luc Maisonobe wrote:
>>>> [...]
>>>>
>>>> When our users build a large application, they rely on numerous
>>>> different libraries and tools, both open-source and proprietary.
>>>> These libraries do have standard interfaces so they can be used
>>>> together. The Java standard library is one of them. the
>>>> getLocalizedMessage method is specified there. Many of the libraries
>>>> and tolls user will assemble rely on it. Deciding that for the sake
>>>> of Apache Commons Math we do not abide to this and decide that all
>>>> other existing code should adapt to a different design is a clear
>>>> no go for me.
>>>
>>> Does the JVM abide by this?
>>
>> Yes,
> 
> Then, how to explain that the following code
> 
> ---CUT---
> for (Locale loc : new Locale[] { Locale.ENGLISH, Locale.FRENCH }) {
> Locale.setDefault(loc);
> System.out.println("Locale=" + loc);
> 
> try {
> final int a = 2;
> double r = a / 0;
> } catch (Exception e) {
> System.out.println("JVM toString(): " + e);
> System.out.println("JVM getLocalizedMessage(): " +
> e.getLocalizedMessage());
> }
> 
> try {
> throw new NotStrictlyPositiveException(-1);
> } catch (Exception e) {
> System.out.println("CM -> toString(): " + e);
> System.out.println("CM -> getLocalizedMessage(): " +
> e.getLocalizedMessage());
> }
> }
> ---CUT---
> 
> produces this output:
> 
> ---CUT---
> Locale=en
> JVM toString(): java.lang.ArithmeticException: / by zero
> JVM getLocalizedMessage(): / by zero
> CM -> toString():
> org.apache.commons.math4.exception.NotStrictlyPositiveException: -1 is
> smaller than, or equal to, the minimum (0)
> CM -> getLocalizedMessage(): -1 is smaller than, or equal to, the
> minimum (0)
> Locale=fr
> JVM toString(): java.lang.ArithmeticException: / by zero
> JVM getLocalizedMessage(): / by zero
> CM -> toString():
> org.apache.commons.math4.exception.NotStrictlyPositiveException: -1
> n'est pas strictement plus grand que le minimum (0)
> CM -> getLocalizedMessage(): -1 n'est pas strictement plus grand que le
> minimum (0)
> ---CUT---
> 
> ?

I'm confused. If instead of the division by zero I try to open an
inexistent file, the message is translated in French. This is why I
assumed it was properly handled. However, it is also translated using
the regular getMessage(). So I guess the translated message is provided
at lower level by the operating system (Linux in my case) which uses
the LANG environment variable and does not follow the setDefaultLocale
setting.

best regards,
Luc


> 
>> as well as JUnit, Eclipse, Maven, and all tools I use.
>>
>>>
>>> The point is that CM code is not user-level code: requirements that
>>> have nothing to do with mathematical algorithms should not have
>>> top-level priority here.  This is what has always biased this
>>> discussion.
>>>
>>> This issue is not one of a design that would not use
>>> "getLocalizedMessage"
>>> just that CM is not the place to do so. CM throws exception; caller
>>> handle them in any way they want.
>>> For example:
>>>
>>> try {
>>>  // ...
>>>
>>>  // Use a low-level library: do not let foreign exceptions bubble up.
>>>  try {
>>>CMAlgo algo = new CMAlgo();
>>>algo.run();
>>>  } catch(RuntimeException e) {
>>>if (e instanceof CMAlgoException)
>>>  throw new MyCMAlgoException(e);
>>>} else {
>>>  throw new MyUnexpectedException(e);
>>>}
>>>  }
>>>
>>>  // ...
>>> } catch (MyRuntimeException e) {
>>>   LOG.error(e.getLocalizedMessage()); //
>>> }
>>
>> Times thousands times as CM call in complex applications that do
>> a lot of math occur everywhere.
> 
> But you do not have to do the above a thousand times only at the point
> where you need to extract the message.
> 
> public class MyApp {
> 
>   public static void main(String[] args) {
> final Locale loc = new locale(args[0]);
> try {
>   final MyApp app = new MyApp(args[1], args[2]);
>   app.run();
> } catch (RuntimeException e) {
>   if (e instanceof MathExceptio

Re: [09/10] [math] Prevent findbugs false positive.

[Luc Maisonobe]

Hi all,

Le 25/12/2015 17:23, l...@apache.org a écrit :
> Prevent findbugs false positive.

This commit was intended to fix a false positive in findbugs.
The field iterations has been deprecated and is not used
anymore in the library. However, as it is protected and not
private, it cannot be removed and it should be initialized
properly. In this case a dedicated wrapper class allow it
to delegate to its replacement field.

So I tried to add the following in our findbugs-exclude-filter.xml,
so it is no displayed anymore. This failed. The warning still
appears in the findbugs report.

Do anyone of you understand why the filter doesn't work? I have
reread 4 times the  element and did not see
what I wrote wrong.

Any help would be greatly appreciated.

best regards,
Luc

> 
> Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-math/commit/4757bc82
> Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/4757bc82
> Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/4757bc82
> 
> Branch: refs/heads/MATH_3_X
> Commit: 4757bc82f9bb3457db6c6ad1f825a9f9214a7d48
> Parents: 6259f3f
> Author: Luc Maisonobe <l...@apache.org>
> Authored: Fri Dec 25 16:54:16 2015 +0100
> Committer: Luc Maisonobe <l...@apache.org>
> Committed: Fri Dec 25 16:54:16 2015 +0100
> 
> --
>  findbugs-exclude-filter.xml | 8 
>  1 file changed, 8 insertions(+)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/commons-math/blob/4757bc82/findbugs-exclude-filter.xml
> --
> diff --git a/findbugs-exclude-filter.xml b/findbugs-exclude-filter.xml
> index 5a960ca..d32fbbe 100644
> --- a/findbugs-exclude-filter.xml
> +++ b/findbugs-exclude-filter.xml
> @@ -23,6 +23,14 @@
>  -->
>  
>  
> +  
> +  
> +  
> + name="org.apache.commons.math3.analysis.integration.BaseAbstractUnivariateIntegrator"
>  />
> +
> +
> +  
> +
>
>
>
> 
> 


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

Re: [09/10] [math] Prevent findbugs false positive.

[Luc Maisonobe]

Le 25/12/2015 19:50, Phil Steitz a écrit :
> On 12/25/15 9:29 AM, Luc Maisonobe wrote:
>> Hi all,
>>
>> Le 25/12/2015 17:23, l...@apache.org a écrit :
>>> Prevent findbugs false positive.
>> This commit was intended to fix a false positive in findbugs.
>> The field iterations has been deprecated and is not used
>> anymore in the library. However, as it is protected and not
>> private, it cannot be removed and it should be initialized
>> properly. In this case a dedicated wrapper class allow it
>> to delegate to its replacement field.
>>
>> So I tried to add the following in our findbugs-exclude-filter.xml,
>> so it is no displayed anymore. This failed. The warning still
>> appears in the findbugs report.
>>
>> Do anyone of you understand why the filter doesn't work? I have
>> reread 4 times the  element and did not see
>> what I wrote wrong.
>>
>> Any help would be greatly appreciated.
> 
> I just pushed a change that works for me, which was to emove the
> method spec in the match.  This makes sense, since the exclusion
> applies at the class level.

Thanks a lot, Phil !

best regards,
Luc

> 
> Phil
>>
>> best regards,
>> Luc
>>
>>> Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
>>> Commit: http://git-wip-us.apache.org/repos/asf/commons-math/commit/4757bc82
>>> Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/4757bc82
>>> Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/4757bc82
>>>
>>> Branch: refs/heads/MATH_3_X
>>> Commit: 4757bc82f9bb3457db6c6ad1f825a9f9214a7d48
>>> Parents: 6259f3f
>>> Author: Luc Maisonobe <l...@apache.org>
>>> Authored: Fri Dec 25 16:54:16 2015 +0100
>>> Committer: Luc Maisonobe <l...@apache.org>
>>> Committed: Fri Dec 25 16:54:16 2015 +0100
>>>
>>> --
>>>  findbugs-exclude-filter.xml | 8 
>>>  1 file changed, 8 insertions(+)
>>> --
>>>
>>>
>>> http://git-wip-us.apache.org/repos/asf/commons-math/blob/4757bc82/findbugs-exclude-filter.xml
>>> --
>>> diff --git a/findbugs-exclude-filter.xml b/findbugs-exclude-filter.xml
>>> index 5a960ca..d32fbbe 100644
>>> --- a/findbugs-exclude-filter.xml
>>> +++ b/findbugs-exclude-filter.xml
>>> @@ -23,6 +23,14 @@
>>>  -->
>>>  
>>>  
>>> +  
>>> +  
>>> +  
>>> +>> name="org.apache.commons.math3.analysis.integration.BaseAbstractUnivariateIntegrator"
>>>  />
>>> +>> />
>>> +
>>> +  
>>> +
>>>
>>>
>>>
>>>
>>>
>>
>> -
>> 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: [math] Exception Design

[Luc Maisonobe]

Le 24/12/2015 01:41, Gilles a écrit :
> On Wed, 23 Dec 2015 20:18:10 +0100, Luc Maisonobe wrote:
>> Le 23/12/2015 14:32, Gilles a écrit :
>>> Hello.
>>>
>>> On Wed, 23 Dec 2015 10:38:03 +0100, luc wrote:
>>>> Le 2015-12-23 01:41, Gilles a écrit :
>>>>> On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:
>>>>>> On 12/22/2015 11:46 AM, Gilles wrote:
>>>>>>> Hi.
>>>>>>> On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:
>>>>>>>> On 12/21/2015 06:44 PM, Gilles wrote:
>>>>>>>>> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> I was considering jumping into the JDKRandomGenerator exception
>>>>>>>>>> discussion, but I did not want to hijack it.
>>>>>>>>>> Not sure if any of you have had a chance to looks at this:
>>>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>> But I did not see how localization is handled.
>>>>>>>> I did leave localization out.  I think localization was a hard
>>>>>>>> requirement in earlier versions of CM, but I'm hoping that there is
>>>>>>>> some flexibility on this
>>>>>>> There was not, since I argued many times to leave it out.
>>>>>>> So unless you can show practically how it can work, I have my doubts
>>>>>>> that we'll be allowed to go forward with this approach.
>>>>>>>
>>>>>>>> and that future versions can defer to a
>>>>>>>> utility that uses the ExceptionTypes Enum instance as the key to
>>>>>>>> look
>>>>>>>> up the internationalized template string.
>>>>>>> Looks good.  Where is the code? ;-)
>>>>>> So CM clients would:
>>>>>> catch(MathException e) {
>>>>>> String exceptionTemplate =
>>>>>> ResourceBundle.getBundle("cm.exception.templates", new Locale("en",
>>>>>> "US")).getString(e.getType());
>>>>>> String i18Nmessage = buildMessage(exceptionTemplate,
>>>>>> e.getContext());
>>>>>> ...
>>>>>> }
>>>>>> I can prototype that out more.  Just trying to get a feel for how
>>>>>> viable the concept is first.
>>>>> I'm not sure I understand correctly.
>>>>> Does that mean that
>>>>> 1. Uncaught exceptions will lead to a message in English?
>>>>> 2. Every "catch" must repeat the same calls (although the arguments
>>>>> are likely
>>>>>to be the same for all clauses (and for all applications)?
>>>>> Comparing this with the current behaviour (where the translated
>>>>> message String
>>>>> is created when "e.getLocalizedMessage()" is called) is likely to
>>>>> make people
>>>>> unhappy.
>>>>
>>>> This could be made simpler with some task delegating between user
>>>> code and CM code.
>>>> What about :
>>>>
>>>>  interface ExceptionLocalizer {
>>>> /** Localize an exception message.
>>>>   * @param locale locale to use
>>>>   * @param me exception to localize
>>>>   * @return localized message for the exception
>>>>   */
>>>> String localize(Locale locale, MathException me);
>>>>  }
>>>>
>>>> and having ExceptionFactory hold a user-provided implementation of
>>>> this interface?
>>>>
>>>>  public class ExceptionFactory {
>>>>
>>>>private static ExceptionLocalizer localizer = new NoOpLocalizer();
>>>>
>>>>public static setLocalizer(ExceptionLocalizer l) {
>>>>   localizer = l;
>>>>}
>>>
>>&g

Re: [math] Exception Design

[Luc Maisonobe]

Le 24/12/2015 14:13, Gilles a écrit :
> On Thu, 24 Dec 2015 09:36:34 +0100, Luc Maisonobe wrote:
>> Le 24/12/2015 01:41, Gilles a écrit :
>>> On Wed, 23 Dec 2015 20:18:10 +0100, Luc Maisonobe wrote:
>>>> Le 23/12/2015 14:32, Gilles a écrit :
>>>>> Hello.
>>>>>
>>>>> On Wed, 23 Dec 2015 10:38:03 +0100, luc wrote:
>>>>>> Le 2015-12-23 01:41, Gilles a écrit :
>>>>>>> On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:
>>>>>>>> On 12/22/2015 11:46 AM, Gilles wrote:
>>>>>>>>> Hi.
>>>>>>>>> On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:
>>>>>>>>>> On 12/21/2015 06:44 PM, Gilles wrote:
>>>>>>>>>>> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> I was considering jumping into the JDKRandomGenerator exception
>>>>>>>>>>>> discussion, but I did not want to hijack it.
>>>>>>>>>>>> Not sure if any of you have had a chance to looks at this:
>>>>>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> [...]
>>>>>>>>>>> But I did not see how localization is handled.
>>>>>>>>>> I did leave localization out.  I think localization was a hard
>>>>>>>>>> requirement in earlier versions of CM, but I'm hoping that
>>>>>>>>>> there is
>>>>>>>>>> some flexibility on this
>>>>>>>>> There was not, since I argued many times to leave it out.
>>>>>>>>> So unless you can show practically how it can work, I have my
>>>>>>>>> doubts
>>>>>>>>> that we'll be allowed to go forward with this approach.
>>>>>>>>>
>>>>>>>>>> and that future versions can defer to a
>>>>>>>>>> utility that uses the ExceptionTypes Enum instance as the key to
>>>>>>>>>> look
>>>>>>>>>> up the internationalized template string.
>>>>>>>>> Looks good.  Where is the code? ;-)
>>>>>>>> So CM clients would:
>>>>>>>> catch(MathException e) {
>>>>>>>> String exceptionTemplate =
>>>>>>>> ResourceBundle.getBundle("cm.exception.templates", new Locale("en",
>>>>>>>> "US")).getString(e.getType());
>>>>>>>> String i18Nmessage = buildMessage(exceptionTemplate,
>>>>>>>> e.getContext());
>>>>>>>> ...
>>>>>>>> }
>>>>>>>> I can prototype that out more.  Just trying to get a feel for how
>>>>>>>> viable the concept is first.
>>>>>>> I'm not sure I understand correctly.
>>>>>>> Does that mean that
>>>>>>> 1. Uncaught exceptions will lead to a message in English?
>>>>>>> 2. Every "catch" must repeat the same calls (although the arguments
>>>>>>> are likely
>>>>>>>to be the same for all clauses (and for all applications)?
>>>>>>> Comparing this with the current behaviour (where the translated
>>>>>>> message String
>>>>>>> is created when "e.getLocalizedMessage()" is called) is likely to
>>>>>>> make people
>>>>>>> unhappy.
>>>>>>
>>>>>> This could be made simpler with some task delegating between user
>>>>>> code and CM code.
>>>>>> What about :
>>>>>>
>>>>>>  interface ExceptionLocalizer {
>>>>>&g

Re: [math] Exception Design

[luc]

f automating I18N requirements.

@ExceptionHandler(MathException.class)
someClientCodeThatUsesCM();



That would be quite necessary I'm afraid. ;-)


Not necessarily. The above support for I18N is quite simple.


best regards,
Luc



Best regards,
Gilles



Cheers,
Ole




-
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: [math] Exception Design

[Luc Maisonobe]

Le 23/12/2015 14:32, Gilles a écrit :
> Hello.
> 
> On Wed, 23 Dec 2015 10:38:03 +0100, luc wrote:
>> Le 2015-12-23 01:41, Gilles a écrit :
>>> On Tue, 22 Dec 2015 13:17:16 -0600, Ole Ersoy wrote:
>>>> On 12/22/2015 11:46 AM, Gilles wrote:
>>>>> Hi.
>>>>> On Mon, 21 Dec 2015 22:44:16 -0600, Ole Ersoy wrote:
>>>>>> On 12/21/2015 06:44 PM, Gilles wrote:
>>>>>>> On Mon, 21 Dec 2015 12:14:16 -0600, Ole Ersoy wrote:
>>>>>>>> Hi,
>>>>>>>> I was considering jumping into the JDKRandomGenerator exception
>>>>>>>> discussion, but I did not want to hijack it.
>>>>>>>> Not sure if any of you have had a chance to looks at this:
>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> https://github.com/firefly-math/firefly-math-exceptions/blob/master/src/main/java/com/fireflysemantics/math/exception/MathException.java
>>>>>>>>
>>>>>>> [...]
>>>>>>> But I did not see how localization is handled.
>>>>>> I did leave localization out.  I think localization was a hard
>>>>>> requirement in earlier versions of CM, but I'm hoping that there is
>>>>>> some flexibility on this
>>>>> There was not, since I argued many times to leave it out.
>>>>> So unless you can show practically how it can work, I have my doubts
>>>>> that we'll be allowed to go forward with this approach.
>>>>>
>>>>>> and that future versions can defer to a
>>>>>> utility that uses the ExceptionTypes Enum instance as the key to look
>>>>>> up the internationalized template string.
>>>>> Looks good.  Where is the code? ;-)
>>>> So CM clients would:
>>>> catch(MathException e) {
>>>> String exceptionTemplate =
>>>> ResourceBundle.getBundle("cm.exception.templates", new Locale("en",
>>>> "US")).getString(e.getType());
>>>> String i18Nmessage = buildMessage(exceptionTemplate,
>>>> e.getContext());
>>>> ...
>>>> }
>>>> I can prototype that out more.  Just trying to get a feel for how
>>>> viable the concept is first.
>>> I'm not sure I understand correctly.
>>> Does that mean that
>>> 1. Uncaught exceptions will lead to a message in English?
>>> 2. Every "catch" must repeat the same calls (although the arguments
>>> are likely
>>>to be the same for all clauses (and for all applications)?
>>> Comparing this with the current behaviour (where the translated
>>> message String
>>> is created when "e.getLocalizedMessage()" is called) is likely to
>>> make people
>>> unhappy.
>>
>> This could be made simpler with some task delegating between user
>> code and CM code.
>> What about :
>>
>>  interface ExceptionLocalizer {
>> /** Localize an exception message.
>>   * @param locale locale to use
>>   * @param me exception to localize
>>   * @return localized message for the exception
>>   */
>> String localize(Locale locale, MathException me);
>>  }
>>
>> and having ExceptionFactory hold a user-provided implementation of
>> this interface?
>>
>>  public class ExceptionFactory {
>>
>>private static ExceptionLocalizer localizer = new NoOpLocalizer();
>>
>>public static setLocalizer(ExceptionLocalizer l) {
>>   localizer = l;
>>}
> 
> I think that this is potentially dangerous for two reasons (if I'm
> not mistaken): it's not thread-safe and it can be called by any
> library used by the main application.

Intermedaite libraries could also call it, and I hope they would be
designed to use a consistent way for their own exception (they should
let the user specify the localization mechanism, use it for themselves
and pass the configuration to CM).

Thread safety here is really not a concern (but we could protect it
if desired). This setting is a configuration level setting, it is
usually done once near the beginning of the main program. You don't
change the mechanism every millisecond.

> 
> I think that the "localizer" instance must be obtained in a way which
> the end-user controls.

The user controls it. The setLocalizer method can be called directly by
user, and in fa

Re: [all] Commons Parent - detach src/bin artifacts?

[Luc Maisonobe]

Le 22/12/2015 09:14, Pascal Schumacher a écrit :
> I agree.
> 
> Maybe I misunderstand the issue, but please continue to attach sources
> to maven central releases. It's very helpful when the IDE can
> automatically download the source of jar and display it.

This is already done.
There is a difference between the source distribution in the zip file
and the source jar. The former contains everything necessary to rebuild,
the second contains only the source for the sake of IDE auto-completion
and similar features.

What we are talking about here is removing the source and binary zip,
not the source and binary jar.

best regards,
Luc

> 
> Thanks,
> Pascal
> 
> Am 21.12.2015 um 23:24 schrieb Christopher:
>> Why detach them at all? Why not permit them to be uploaded to Maven
>> Central?
>> It may not be as useful for Java builds, but Maven repository isn't
>> designed to hold only jars. It can hold any type of artifact.
>>
>> On Mon, Dec 21, 2015 at 3:30 AM Emmanuel Bourg <ebo...@apache.org> wrote:
>>
>>> Le 20/12/2015 23:06, Emmanuel Bourg a écrit :
>>>
>>>> I've tested with JEXL and it seems to work
>>>> fine, I haven't noticed undesirable side effects.
>>> Actually there is one side effect: the .sha1 and .md5 files for the
>>> src/bin archives no longer come for free (they are currently generated
>>> when the archives are deployed in the local repository). So if we detach
>>> the files we should compensate with an explicit generation of the
>>> checksums using the antrun plugin immediately after the assembly plugin.
>>>
>>> Emmanuel Bourg
>>>
>>>
>>> -
>>> 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: [Math] Exceptions from "JDKRandomGenerator"

[Luc Maisonobe]

issue.
>>>>
>>>> Perhaps that the multiple hierarchies are better, maybe not.
>>>> But we have to figure out arguments that are more convincing than
>>>> nostalgia.
>>>>
>>>> For instance, IMO, we have contradicting wishes:
>>>> * Have CM exception inherits from the JDK ones with the same
>>>> semantics.
>>>> * Have all CM exceptions provide the same additional functionality
>>>> (the
>>>>   "ExceptionContext").
>>>
>>> In 3.x, MIAE extends IAE and we have all the context stuff working.
>>>
>>> I guess you are concerned about the "duplicated code" in the
>>> multiple roots extending the standard exceptions.  Here is the full
>>> extent of it:
>>>
>>>  /**
>>>  * @param pattern Message pattern explaining the cause of the
>>> error.
>>>  * @param args Arguments.
>>>  */
>>> public MathIllegalArgumentException(Localizable pattern,
>>> Object ... args) {
>>> context = new ExceptionContext(this);
>>> context.addMessage(pattern, args);
>>> }
>>>
>>> /** {@inheritDoc} */
>>> public ExceptionContext getContext() {
>>> return context;
>>> }
>>>
>>> /** {@inheritDoc} */
>>> @Override
>>> public String getMessage() {
>>> return context.getMessage();
>>> }
>>>
>>> /** {@inheritDoc} */
>>> @Override
>>> public String getLocalizedMessage() {
>>> return context.getLocalizedMessage();
>>> }
>>>
>>> I see that as NOT_A_PROBLEM.  In 3.x, we have 6 classes that need
>>> this little bit of similar code.  That is after 10 years of
>>> development.  I doubt we will have more than a few more needed at
>>> the top level.
>>
>> It's not a problem of how many lines of code must be duplicated.
>>
>> The problem is the duplication.
>> Duplication is not a best practice AFAIK.
> 
> I agree that duplication is to be avoided; but I think it does make
> a difference how much / how complex the code is.  The duplicated
> code in this case is trivial.
>>
>>>> The first looks nice from a user POV (as in "I know this already").
>>>> The second is an internal requirement to avoid code duplication.
>>>>
>>>> IMO, it always comes back to those opposite views we have
>>>> concerning the
>>>> place where human-readable messages should be generated: my view
>>>> is that
>>>> if a low-level library message bubbles up to the console, then
>>>> it's not
>>>> our fault, but the application programmer's.
>>> Meaningful exception messages are a best practice in Java.  They are
>>> a very useful aid in debugging and production support.
>>>>
>>>> Please assume that for a moment; then CM could have its algorithms
>>>> throw
>>>> some internal subclass of "MathRuntimeException" (whose type is
>>>> known to
>>>> the caller) and the caller can decide whether he must trap it in
>>>> order
>>>> to rethrow a standard type, or his own type (tailored to the
>>>> context which
>>>> he knows but CM doesn't).
>>>>
>>>> In that scenario, it is much easier for the caller when the
>>>> low-level
>>>> library's exceptions hierarchy is unique (especially when he uses
>>>> several
>>>> libraries).
>>>> And it's also easier for us because we can avoid code duplication.
>>>
>>> Easiest is if the library follows the Java best practice, which is
>>> to favor standard exceptions.
>>
>> We do not favour standard exceptions because we _have_ to define our
>> own.
>> And we have done this for various "good" reasons in line with other
>> best practices, subject to internal requirements.
> 
> We can have it both ways if we define our own exceptions to extend
> the standard exceptions where that makes sense, which is the best
> practice.  Having MIAE extend IAE is good design, IMO.  What we are
> throwing on bad arguments is IAE.  Callers can catch that.  If they
> want to dig in deeper and differentiate their handlers based on
> which of our IAE subclasses is thrown, they can do that.  That is
> how exception hierarchies are supposed to work.  The "favor standard

Re: [Math] Exceptions from "JDKRandomGenerator"

[Luc Maisonobe]

Le 22/12/2015 17:44, Ole Ersoy a écrit :
> 
> .
> 
>> One of the point in having exceptions that extends our own root
>> exception is that users at higher level can catch this top level.
>> Currently, we don't even advertise properly what we throw. We even
>> miss to forward upward some exceptions thrown at low level in the
>> javadoc/signature of out upper level methods.
>>
>> So user may currently not know, only reading the javadoc/signature
>> of one of our implementation that they may get a MIAE or something
>> else. If we were using a single root,
> Or just a single MathException.
>>   they would at least be able
>> to do a catch (MathRootException) that would prevent a runtime
>> exception to bubble up too far. Currently, defensive programming
>> to protect against this failure is to catch all of
>> MathArithmeticException, MathIllegalArgumentException,
>> MathIllegalNumberException, MathIllegalStateException,
>> MathUnsupportedOperationException, and MathRuntimeException.
> With the design I proposed, and the design I'm using, we only have to
> catch one.  After it's caught the type code (Enum) indicates precisely
> what the issue is.
>>
>> In a perfect world, we would be able to extend a regular IAE while
>> implementing a MathRootException, but Throwable in Java is a class,
>> not an interface. Too bad.
> Luc - how do you feel about a single MathException that extends
> RuntimeException with an Enum that indicates what the root cause is and
> can be used as the key to look up the corresponding message template
> which can be resolved into a message using parameters attached to the
> MathException context?

I am fine with this.

I did not check your design yet, sorry I am overwhelmed with several
issues to fix for 3.6 that I would like to release soon.

best regards
Luc

> 
> Here's an example from my refactoring of ArithmeticUtils:
> 
> https://github.com/firefly-math/firefly-math-arithmetic/blob/master/src/main/java/com/fireflysemantics/math/arithmetic/Arithmetic.java
> 
> 
> /**
>  * Add two integers, checking for overflow.
>  *
>  * @param x
>  *an addend
>  * @param y
>  *an addend
>  * @return the sum {@code x+y}
>  * @throws MathException
>  * Of type {@code MAE__OVERFLOW_IN_ADDITION} if the
> result can
>  * not be represented as an {@code int}.
>  */
> public static int addAndCheck(int x, int y) throws MathException {
> long s = (long) x
> + (long) y;
> if (s < Integer.MIN_VALUE
> || s > Integer.MAX_VALUE) {
> throw new MathException(MAE__OVERFLOW_IN_ADDITION).put(X,
> x).put(Y, y);
> }
> return (int) s;
> }
> 
> The toString() method of the exception is implemented like this and
> delivers the exception root cause (Enum) and parameter name and value
> pairs:
> 
> @Override
> public String toString() {
> String parameters = context.entrySet().stream().map(e -> e.getKey()
> + "="
> + e.getValue()).collect(Collectors.joining(", "));
> 
> return "Firefly math exception type "
> + this.type
> + ".  Context ["
> + parameters
> + "]";
> }
> 
> So we get a pretty good indication of what the issue is by just using
> toString() to construct the message.
> 
> Cheers,
> Ole
> 
> 
> -
> 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: [math] branch merge to come, prepare for a huge flood of git messages

[luc]

Le 2015-12-09 16:49, Phil Steitz a écrit :

On Dec 9, 2015, at 8:39 AM, luc <l...@spaceroots.org> wrote:

Hi all,

The development status for the field-ode branch (linked to issue 
MATH-1288)
is now stable. I will therefore merge this branch into the MATH_3_X 
branch

very soon now.


What about master?


I may merge all the commits as a single one in master or reproduce all
commits from the branch one by one. A single big commit will probably be
more friendly to the list. Separate commits will show the development
steps.

Also in master, the primitive double API for ode will be changed to
be consistent with the new API developed for field ode. I could not
do that in 3.X because these are publis user-oriented interfaces, so
changing them would introduce a huge incompatibility.

At the end, this is a new feature, not a modification of an existing 
feature,

so I don't know if the steps before the feature is complete are
interesting or not. These steps will be available in the MATH_3_X
branch (and in the field-ode branch), but not in the master branche
if I do a single big commit.


What do you prefer?

best regards,
Luc



Phil

Unfortunately, our git/mail integration resends the mails
corresponding to all the individual commits performed on a branch when 
it
is merged into another branch. So the merge will probably generate a 
huge

flood of mails to the list, corresponding to all the work done on the
field-ode branch since last month.

I apologize for this flood.

best regards,
Luc

-
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

[math] branch merge to come, prepare for a huge flood of git messages

[luc]

Hi all,

The development status for the field-ode branch (linked to issue 
MATH-1288)
is now stable. I will therefore merge this branch into the MATH_3_X 
branch

very soon now. Unfortunately, our git/mail integration resends the mails
corresponding to all the individual commits performed on a branch when 
it
is merged into another branch. So the merge will probably generate a 
huge

flood of mails to the list, corresponding to all the work done on the
field-ode branch since last month.

I apologize for this flood.

best regards,
Luc

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

Re: [math] branch merge to come, prepare for a huge flood of git messages

[Luc Maisonobe]

Le 09/12/2015 19:22, James Ring a écrit :
> On Wed, Dec 9, 2015 at 9:45 AM, Phil Steitz <phil.ste...@gmail.com> wrote:
>> On 12/9/15 9:13 AM, luc wrote:
>>> Le 2015-12-09 16:49, Phil Steitz a écrit :
>>>>> On Dec 9, 2015, at 8:39 AM, luc <l...@spaceroots.org> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> The development status for the field-ode branch (linked to issue
>>>>> MATH-1288)
>>>>> is now stable. I will therefore merge this branch into the
>>>>> MATH_3_X branch
>>>>> very soon now.
>>>>
>>>> What about master?
>>>
>>> I may merge all the commits as a single one in master or reproduce
>>> all
>>> commits from the branch one by one. A single big commit will
>>> probably be
>>> more friendly to the list. Separate commits will show the development
>>> steps.
>>>
>>> Also in master, the primitive double API for ode will be changed to
>>> be consistent with the new API developed for field ode. I could not
>>> do that in 3.X because these are publis user-oriented interfaces, so
>>> changing them would introduce a huge incompatibility.
>>>
>>> At the end, this is a new feature, not a modification of an
>>> existing feature,
>>> so I don't know if the steps before the feature is complete are
>>> interesting or not. These steps will be available in the MATH_3_X
>>> branch (and in the field-ode branch), but not in the master branche
>>> if I do a single big commit.
>>>
>>>
>>> What do you prefer?
>>
>> I am not sure.  I just wanted to make sure the new feature got into
>> master as well as 3_X.
>>
>> I have been following the branch commits and as long as the record
>> of these granular commits can be traced, I am fine with the single
>> commit to master.  If you take the single commit approach to master,
>> will the steps be traceable from master or will we have to go back
>> to 3_X to trace things?  If the latter, it would be good to add
>> something to the big commit message to direct later archaeological
>> investigations back to the 3_X branch.

As MATH_3_X and master have forked a few months ago and will never
benn merged back, nothing in master will track back to anything
in MATH_3_X that occurred after the fork.

>> What is the standard git way
>> of dealing with kind of thing?

The standard way is to use a regular merge, but it doesn't work for us
as per our directories layout change.

> 
> Just an outsider's perspective, I would expect that people would want
> the branches to be merged without squashing all the commits down into
> one mega commit. It's unfortunate that an email would be generated for
> each one of these, but oh well. ;)

OK, then I think I will try to replay all the commits. It will just be a
few lines scripting with shell and sed. It will mean lots of mail on
the list. The good news will be we can refer back to the tracks at some
time in the future.

I don't now if I will do it very soon or not, it will depend on
available time and priorities.

best regards,
Luc

> 
>> Phil
> 
> Regards,
> James
> 
> -
> 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: [math] MATH 4 requires at least java 7, build also the MATH_3_X branch.

[Luc Maisonobe]

Hi Thomas,

Le 02/12/2015 21:08, t...@apache.org a écrit :
> Repository: commons-math
> Updated Branches:
>   refs/heads/master 7afc1c34f -> 25de9b780
> 
> 
> MATH 4 requires at least java 7, build also the MATH_3_X branch.

Do you mean MATH_3_X does not compile with Java 6 anymore?

best regards,
Luc

> 
> 
> Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
> Commit: http://git-wip-us.apache.org/repos/asf/commons-math/commit/25de9b78
> Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/25de9b78
> Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/25de9b78
> 
> Branch: refs/heads/master
> Commit: 25de9b7800887c12365f6a19b13cf32baf5bfe2f
> Parents: 7afc1c3
> Author: Thomas Neidhart <thomas.neidh...@gmail.com>
> Authored: Wed Dec 2 21:08:41 2015 +0100
> Committer: Thomas Neidhart <thomas.neidh...@gmail.com>
> Committed: Wed Dec 2 21:08:41 2015 +0100
> 
> --
>  .travis.yml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> --
> 
> 
> http://git-wip-us.apache.org/repos/asf/commons-math/blob/25de9b78/.travis.yml
> --
> diff --git a/.travis.yml b/.travis.yml
> index bd60a9f..3177040 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -2,14 +2,14 @@ language: java
>  sudo: false
>  
>  jdk:
> -  - openjdk6
>- openjdk7
>- oraclejdk8
>  
> -# only build trunk
> +# only build master and the MATH_3_X branch
>  branches:
>only:
>  - master
> +- MATH_3_X
>  
>  after_success:
>- mvn clean test jacoco:report coveralls:report
> 
> 


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

Re: [math] Adding badges

[Luc Maisonobe]

Le 02/12/2015 09:57, Thomas Neidhart a écrit :
> Hi,
> 
> recently I added some badges (building on travis, code coverage with
> coveralls, license tag, latest available version from maven) to
> collections, which can be seen here:
> https://github.com/apache/commons-collections
> 
> Any objection to add the same for math?

Go for it if you think it is useful.

For the record, there is a pending pull request about travis here:

 <https://github.com/apache/commons-math/pull/11>

best regards,
Luc

> 
> The travis integration can be quite useful for a RM as you can specify
> which jdks shall be automatically tested.
> 
> Thomas
> 


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

Re: [VOTE] Release Commons Collections 4.1 Based on RC2 (24h vote)

[Luc Maisonobe]

Le 25/11/2015 23:20, Thomas Neidhart a écrit :
> Hi all,
> 
> we have accumulated enough changes since the last 4.0 release as well as
> we need to provide a fix for the known remote code exploit via java
> de-serialization. Therefore, I would like to start a vote to release
> Commons Collections 4.1 based on RC2.
> 
> Note:
> 
>  * The fix for the security related issue results in Clirr errors as
>unsafe classes in the functor package do not implement the
>Serializable interface anymore. This is mentioned in the release
>notes.
> 
>  * There are 2 test failures with the IBM 6 JDK. The same failures were
>reported for the 4.0 release and are related to a buggy Map
>implementation in this JDK
> 
>  * Commons Collections 4.X does not successfully compile with JDK 9 EA
>This will be tackled in a later release.
> 
> Changes since RC1:
> 
>  * fixed compilation problems of test classes with some Java 8 compilers
>  * fixed some javadoc in IterableUtils and MultiValuedMap
>  * added travis configuration (only in the repository, not part of the
>release) to help a RM by building with different jdks
> 
> Collections 4.1 RC2 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/collections/
> (svn revision 11307)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1129/org/apache/commons/commons-collections4/4.1/
> 
> Details of changes since 4.0 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt
> 
> http://people.apache.org/builds/commons/collections/4.1/RC2/changes-report.html
> 
> The tag is here:
> 
> https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_1_RC2
> (svn revision 1716550)
> 
> Site:
> http://people.apache.org/builds/commons/collections/4.1/RC2/
> 
> Clirr Report (compared to 4.0):
> 
> http://people.apache.org/builds/commons/collections/4.1/RC2/clirr-report.html
> 
> RAT Report:
> 
> http://people.apache.org/builds/commons/collections/4.1/RC2/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 24 hours from now, i.e. after 2400
> GMT 26-November 2015
> 

>   [X] +1 Release these artifacts

Luc

> 
> Thanks,
> 
> Thomas
> 
> -
> 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: MathArrays -> JogAmp -> OpenCL

[luc]

Le 2015-11-24 22:26, Gilles a écrit :

On Tue, 24 Nov 2015 20:58:14 +, Eric Barnhill wrote:
Is anyone interested in some GPU support for MathArrays by using, say, 
the
JogAmp bindings and OpenCL methods. I have implemented such an 
architecture
for my own convolution library I am developing, and it would not be 
much
trouble for me to add this kind of support for commons-math some time 
in

the new year.

It would require the user to install the JOCL glue libraries to make 
use of
this and this may be out side of the commons mission. Overall I find 
JogAmp

very convenient and its creators support it.


Could you elaborate on this?
Would this mean we add a dependency?
What does "to make use of" mean, would this be an interface part of the
library that could be compiled only if the glue libraries are available?

Luc



There were some recent and not so recent discussions on parallel 
processing

as a way to enhance the performance of CM.

Actual experiments are certainly welcome to figure out the best way(s) 
to go.


And this would probably be a nice addition to the userguide.
Could you give pointers to the utilities and a slightly more detailed
description
of the intended usage?

Thanks,
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: [VOTE] Release Commons Collections 4.1 Based on RC1

[luc]

Le 2015-11-25 07:50, Thomas Neidhart a écrit :

On 11/24/2015 11:30 PM, Jörg Schaible wrote:

Hi Thomas,

Thomas Neidhart wrote:


Hi all,

we have accumulated enough changes since the last 4.0 release as well 
as

we need to provide a fix for the known remote code exploit via java
de-serialization. Therefore, I would like to start a vote to release
Commons Collections 4.1 based on RC1.

Note:

The fix for the security related issue results in Clirr errors as 
unsafe

classes in the functor package do not implement the Serializable
interface anymore. This is mentioned in the release notes.


Collections 4.1 RC1 is available for review here:
https://dist.apache.org/repos/dist/dev/commons/collections/
(svn revision 11263)

Maven artifacts are here:




https://repository.apache.org/content/repositories/orgapachecommons-1122/org/apache/commons/commons-collections4/4.1/


Details of changes since 4.0 are in the release notes:


https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt


http://people.apache.org/builds/commons/collections/4.1/RC1/changes-report.html

The tag is here:




https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_4_1_RC1

(svn revision 1715703)

Site:
http://people.apache.org/builds/commons/collections/4.1/RC1/

Clirr Report (compared to 4.0):


http://people.apache.org/builds/commons/collections/4.1/RC1/clirr-report.html

RAT Report:


http://people.apache.org/builds/commons/collections/4.1/RC1/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, i.e. after 
2400

GMT 25-November 2015

  [ ] +1 Release these artifacts


+1 for the release

Luc


  [ ] +0 OK, but...
  [ ] -0 OK, but really should fix...
  [ ] -1 I oppose this release because...

Thanks,

Thomas


It fails for IBM JDK 6:

 %< ===
Failed tests:
org.apache.commons.collections4.map.AbstractMapTest$TestMapEntrySet.testMapEntrySetIteratorEntrySetValue(org.apache.commons.collections4.map.AbstractMapTest$TestMapEntrySet)
  Run 1: PASS
  Run 2: PASS
  Run 3: PASS
  Run 4: PASS
  Run 5: PASS
  Run 6: PASS
  Run 7: PASS
  Run 8: PASS
  Run 9: PASS
  Run 10: PASS
  Run 11: PASS
  Run 12: PASS
  Run 13: PASS
  Run 14: PASS
  Run 15: PASS
  Run 16: PASS
  Run 17: PASS
  Run 18: PASS
  Run 19: PASS
  Run 20: PASS
  Run 21: PASS
  Run 22: PASS
  Run 23: PASS
  Run 24: PASS
  Run 25: PASS
  Run 26: PASS
  Run 27: PASS
  Run 28: PASS
  Run 29: PASS
  Run 30: PASS
  Run 31: PASS
  Run 32: PASS
  Run 33: PASS
  Run 34: PASS
  Run 35: PASS
  Run 36: PASS
  Run 37:
AbstractMapTest$TestMapEntrySet.testMapEntrySetIteratorEntrySetValue:1665
expected: but was:
  Run 38: PASS
  Run 39: PASS
  Run 40: PASS
  Run 41: PASS
  Run 42:
AbstractMapTest$TestMapEntrySet.testMapEntrySetIteratorEntrySetValue:1665
expected: but was:
  Run 43: PASS


These test failures exist since the 4.0 release, quoting your vote for
Collection 4.0 based on RC5:


+1, builds for all but one JDK flawlessly from source. I still have 2
failing tests for IBM JDK 1.6:

Failed tests:
  
AbstractMapTest$TestMapEntrySet.testMapEntrySetIteratorEntrySetValue:1656

expected: but was:
  
AbstractMapTest$TestMapEntrySet.testMapEntrySetIteratorEntrySetValue:1656

expected: but was:

However, since we already blamed that JDK, it does not influence the
release.


I can not remember anymore why these have not been worked-around 
though,

but I suspect that it was not so simple in this case.



 %< ===
$ mvn-3.0 -version
Apache Maven 3.0.5 (r01de14724cdef164cd33c7c8c2fe155faf9602da; 
2013-02-19

14:51:28+0100)
Maven home: /usr/share/maven-bin-3.0
Java version: 1.6.0, vendor: IBM Corporation
Java home: /opt/ibm-jdk-bin-1.6.0.9_p2/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.1.12-gentoo", arch: "amd64", family: 
"unix"

 %< ===

It fails to compile with Java 8:

 %< ===
[INFO] -
[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR] /home/joehni/tmp/download/commons-collections4-4.1-
src/src/test/java/org/apache/commons/collections4/FluentIterableTest.java:
[242,41] reference to forEach is ambiguous
  both method forEach(java.util.function.Consumer) in
java.lang.Iterable and method
forEach(org.apache.commons.collections4.Closure) in
org.apache.commons.collections4.FluentIterable match
[INFO] 1 error
[INFO] -


ok, this error has been already spotted by Oliver and fixed in trunk. 
It

is only in a test case where the type inference fails when passing 

[math] testing issue with Kolmogorov-Smirnov bootstrap methods

[Luc Maisonobe]

Hi all,

It seems the new bootstrap method introduced in fbc327e9 in order
to solve MATH-1246 creates some random test failures.

The reason is that an EnumeratedRealDistribution instance is
created without a random generator (there are no way to pass
a random generator in the bootstrap method). This
EnumeratedRealDistribution will therefore create a Well19937c
generator with the default constructor, which uses time to seed
the generator. Depending on the way this generator is seeded,
the testBootstrapSmallSamplesWithTies test fails quite often.

Would it be possible to pass a random generator somewhere and
to configure it with a fixed seed for the Junit tests?

best regards,
Luc

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

Re: [math] testing issue with Kolmogorov-Smirnov bootstrap methods

[Luc Maisonobe]

Le 24/11/2015 14:34, Phil Steitz a écrit :
> On 11/24/15 3:40 AM, Luc Maisonobe wrote:
>> Hi all,
>>
>> It seems the new bootstrap method introduced in fbc327e9 in order
>> to solve MATH-1246 creates some random test failures.
>>
>> The reason is that an EnumeratedRealDistribution instance is
>> created without a random generator (there are no way to pass
>> a random generator in the bootstrap method). This
>> EnumeratedRealDistribution will therefore create a Well19937c
>> generator with the default constructor, which uses time to seed
>> the generator. Depending on the way this generator is seeded,
>> the testBootstrapSmallSamplesWithTies test fails quite often.
>>
>> Would it be possible to pass a random generator somewhere and
>> to configure it with a fixed seed for the Junit tests?
> 
> I just changed the code (3_X: 3cfafe051 / master: 5f9cfa6eb) to have
> the bootstrap method use the rng configured for the class.  The
> tests supply a fixed seed generator to the KS instance, but that was
> not being passed by the bootstrap to the EnumeratedDistribution. 
> Sorry I missed that.

Never mind. Thanks a lot for this fast fix.

best regards,
Luc

> 
> Phil
>>
>> best regards,
>> Luc
>>
>> -
>> 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: [math] s/FieldUnivariateFunction/RealFieldUnivariateFunction?

[Luc Maisonobe]

Le 15/11/2015 20:47, Phil Steitz a écrit :
> Seems that is what it is.  We don't seem to have immediate need for
> the more general interface, but if we ever do, we will want to have
> the name available.

You are right, we could change it.
Would you mind doing it, I am quite busy with ODE right now
as you have probably noticed.

best regards,
Luc

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


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

Re: [VOTE] Release Commons Collections 3.2.2 Based on RC3

[Luc Maisonobe]

Le 13/11/2015 00:31, Thomas Neidhart a écrit :
> Hi all,
> 
> in order to provide a work-around for the known remote code exploit via
> java de-serialization of malicious InvokerTransformer instances, I would
> like to start a vote to release Commons Collections 3.2.2 based on RC3.
> 
> Notes:
> 
>  * the site will not be published, it just serves as a reference to
> access the various reports. After a successful vote, the current 4.X
> branch site will be updated with relevant information and published.
> 
>  * some tests might fail with various IBM JDK 6 JREs, these are known
> issues and have been worked-around in the 4.X branch but are not
> back-ported to this release.
> 
>  * Collections 3.2.2 can not be compiled with JDK 8 due to a name clash
> with a newly introduced default method in the Map interface.
> 
>  * the collections-testframework.jar that has been published in previous
> versions is not included in this release
> 
> Changes from RC2:
> 
>  * fixed false positives in RAT report
>  * fixed test execution and compilation problems with JDK 1.4 and 1.5
> 
> Changes from RC1:
> 
>  * fixed RAT report
>  * fixed NOTICE file
>  * improve the security fix: it has been made symmetric in the sense
>that also the serialization of an unsafe class is disabled by
>default and will result in an exception
>  * changed the system property to re-enable serialization of unsafe
>classes. It is now
>"org.apache.commons.collections.enableUnsafeSerialization"
>  * all classes in the functor package which (based on current
>knowledge) have to be considered unsafe cannot be serialized/
>de-serialized any more by default. This includes the following
>classes:
> 
>  ** CloneTransformer
>  ** PrototypeFactory (inner classes
>   PrototypeCloneFactory and
>   PrototypeSerializationFactory)
>  ** InstantiateFactory
>  ** InstantiateTransformer
>  ** ForClosure
>  ** WhileClosure
>  ** InvokerTransformer
> 
> 
> 
> Collections 3.2.2 RC3 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/collections/
> (svn revision 11167)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1117/commons-collections/commons-collections/3.2.2/
> 
> Details of changes since 3.2.1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt
> 
> http://people.apache.org/builds/commons/collections/3.2.2/RC3/changes-report.html
> 
> The tag is here:
> 
> https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_3_2_2_RC3
> (svn revision 1714131)
> 
> Site:
> http://people.apache.org/builds/commons/collections/3.2.2/RC3/
> 
> Clirr Report (compared to 3.2.1):
> 
> http://people.apache.org/builds/commons/collections/3.2.2/RC3/clirr-report.html
> 
> RAT Report:
> 
> http://people.apache.org/builds/commons/collections/3.2.2/RC3/rat-report.html
> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.
> 
> 
> Considering that this is a security related release and that RC2 did not
> show any functional problems with the release, I plan to close this vote
> in 24h from now, i.e. after 0100 GMT 14-November 2015
> 
>   [X] +1 Release these artifacts


Luc

>   [ ] +0 OK, but...
>   [ ] -0 OK, but really should fix...
>   [ ] -1 I oppose this release because...
> 
> Thanks,
> 
> Thomas
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
> 
> 


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

Re: [VOTE] Release Commons Collections 3.2.2 Based on RC3

[Luc Maisonobe]

Le 13/11/2015 20:26, Gary Gregory a écrit :
> +1
> 
> Tested with src zip.
> 
> BUT:
> 
> - The site Javadoc link is labeled "3.2.1" (fixed in
> https://svn.apache.org/repos/asf/commons/proper/collections/branches/COLLECTIONS_3_2_X
> )
> - The site history does not mentioned (fixed in svn)
> 
> ASC OK, MD5 OK, SHA1 OK. Everyone's checking these, right?

Yes. I check this for every release.

Luc

> 
> Reports OK.
> 
> Tested building with:
> 
> Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06;
> 2015-04-22T04:57:37-07:00)
> Maven home: C:\Java\apache-maven-3.3.3\bin\..
> Java version: 1.7.0_79, vendor: Oracle Corporation
> Java home: C:\Program Files\Java\jdk1.7.0_79\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
> 
> and:
> 
> Apache Ant(TM) version 1.9.6 compiled on June 29 2015
> 
> Gary
> 
> On Thu, Nov 12, 2015 at 3:31 PM, Thomas Neidhart <thomas.neidh...@gmail.com>
> wrote:
> 
>> Hi all,
>>
>> in order to provide a work-around for the known remote code exploit via
>> java de-serialization of malicious InvokerTransformer instances, I would
>> like to start a vote to release Commons Collections 3.2.2 based on RC3.
>>
>> Notes:
>>
>>  * the site will not be published, it just serves as a reference to
>> access the various reports. After a successful vote, the current 4.X
>> branch site will be updated with relevant information and published.
>>
>>  * some tests might fail with various IBM JDK 6 JREs, these are known
>> issues and have been worked-around in the 4.X branch but are not
>> back-ported to this release.
>>
>>  * Collections 3.2.2 can not be compiled with JDK 8 due to a name clash
>> with a newly introduced default method in the Map interface.
>>
>>  * the collections-testframework.jar that has been published in previous
>> versions is not included in this release
>>
>> Changes from RC2:
>>
>>  * fixed false positives in RAT report
>>  * fixed test execution and compilation problems with JDK 1.4 and 1.5
>>
>> Changes from RC1:
>>
>>  * fixed RAT report
>>  * fixed NOTICE file
>>  * improve the security fix: it has been made symmetric in the sense
>>that also the serialization of an unsafe class is disabled by
>>default and will result in an exception
>>  * changed the system property to re-enable serialization of unsafe
>>classes. It is now
>>"org.apache.commons.collections.enableUnsafeSerialization"
>>  * all classes in the functor package which (based on current
>>knowledge) have to be considered unsafe cannot be serialized/
>>de-serialized any more by default. This includes the following
>>classes:
>>
>>  ** CloneTransformer
>>  ** PrototypeFactory (inner classes
>>   PrototypeCloneFactory and
>>   PrototypeSerializationFactory)
>>  ** InstantiateFactory
>>  ** InstantiateTransformer
>>  ** ForClosure
>>  ** WhileClosure
>>  ** InvokerTransformer
>>
>>
>>
>> Collections 3.2.2 RC3 is available for review here:
>> https://dist.apache.org/repos/dist/dev/commons/collections/
>> (svn revision 11167)
>>
>> Maven artifacts are here:
>>
>>
>> https://repository.apache.org/content/repositories/orgapachecommons-1117/commons-collections/commons-collections/3.2.2/
>>
>> Details of changes since 3.2.1 are in the release notes:
>>
>>
>> https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt
>>
>>
>> http://people.apache.org/builds/commons/collections/3.2.2/RC3/changes-report.html
>>
>> The tag is here:
>>
>>
>> https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_3_2_2_RC3
>> (svn revision 1714131)
>>
>> Site:
>> http://people.apache.org/builds/commons/collections/3.2.2/RC3/
>>
>> Clirr Report (compared to 3.2.1):
>>
>>
>> http://people.apache.org/builds/commons/collections/3.2.2/RC3/clirr-report.html
>>
>> RAT Report:
>>
>>
>> http://people.apache.org/builds/commons/collections/3.2.2/RC3/rat-report.html
>>
>> KEYS:
>>   https://www.apache.org/dist/commons/KEYS
>>
>> Please review the release candidate and vote.
>>
>>
>> Considering that this is a security related release and that RC2 did not
>> show any functional problems with the release, I plan to close this vote
>> in 24h from now, i.e. after 0100 GMT 14-November 2015
>>
>>   [ ] +1 Release these artifacts
>>   [ ] +0 OK, but...
>>   [ ] -0 OK, but really should fix...
>>   [ ] -1 I oppose this release because...
>>
>> Thanks,
>>
>> Thomas
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
> 
> 


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

Re: [VOTE] Release Commons Collections 3.2.2 Based on RC2

[luc]

Le 2015-11-12 10:18, Stefan Bodewig a écrit :

On 2015-11-11, Thomas Neidhart wrote:


Please review the release candidate and vote.



+1 for the release.

Luc



+1

Stefan

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


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

Re: [VOTE] Release Commons Collections 3.2.2 Based on RC1

[Luc Maisonobe]

Le 09/11/2015 23:37, Thomas Neidhart a écrit :
> Hi all,
> 
> in order to provide a work-around for the known remote code exploit via
> java de-serialization of malicious InvokerTransformer instances, I would
> like to start a vote to release Commons Collections 3.2.2 based on RC1.
> 
> I would kindly ask people to review the RC especially wrt the following
> topics:
> 
>  * OSGI compatibility
>  * reproducing the exploits and verifying that it provides protection
>  * any kind of regression that this release might create with existing
> applications
> 
> Notes:
> 
>  * the site will not be published, it just serves as a reference to
> access the various reports. After a successful vote, the current 4.X
> branch site will be updated with relevant information and published.
> 
>  * some tests might fail with various IBM JDK 6 JREs, these are known
> issues and have been worked-around in the 4.X branch but are not
> back-ported to this release.
> 
> 
> Collections 3.2.2 RC1 is available for review here:
> https://dist.apache.org/repos/dist/dev/commons/collections/
> (svn revision 11092)
> 
> Maven artifacts are here:
> 
> https://repository.apache.org/content/repositories/orgapachecommons-1115/commons-collections/commons-collections/3.2.2/
> 
> Details of changes since 3.2.1 are in the release notes:
> 
> https://dist.apache.org/repos/dist/dev/commons/collections/RELEASE-NOTES.txt
> 
> http://people.apache.org/builds/commons/collections/3.2.2/RC1/changes-report.html
> 
> The tag is here:
> 
> https://svn.apache.org/repos/asf/commons/proper/collections/tags/COLLECTIONS_3_2_2_RC1
> (svn revision 1713561)

It seems the revision is 1713556 rather than 1713561.
It is both what I see in svn and what was used to generate the
binaries in dist (according to the Implementation-Build element
in the MANIFEST.MF embedded within the jar).

> 
> Site:
> http://people.apache.org/builds/commons/collections/3.2.2/RC1/
> 
> Clirr Report (compared to 3.2.1):
> 
> http://people.apache.org/builds/commons/collections/3.2.2/RC1/clirr-report.html
> 
> RAT Report:
> 
> http://people.apache.org/builds/commons/collections/3.2.2/RC1/rat-report.html

The single file with unknown license in this report is
xdocs/style.project.css. It is a one line file that imports
commons-maven.css). The file has been unchanged since April 2008.

Certainly not a blocker.

> 
> KEYS:
>   https://www.apache.org/dist/commons/KEYS
> 
> Please review the release candidate and vote.

I first got a compilation error when attempting a compilation with maven
3.3.3 and the default JVM on my system (java8 openJDK, on a Debian
stretch machine)

[ERROR] COMPILATION ERROR :
[INFO] -
[ERROR]
/home/luc/tmp/downloaded-RC/dist/source/commons-collections-3.2.2-src-t/src/java/org/apache/commons/collections/map/MultiValueMap.java:[156,19]
remove(java.lang.Object,java.lang.Object) in
org.apache.commons.collections.map.MultiValueMap cannot implement
remove(java.lang.Object,java.lang.Object) in java.util.Map
  return type java.lang.Object is not compatible with boolean
[ERROR]
/home/luc/tmp/downloaded-RC/dist/source/commons-collections-3.2.2-src-t/src/java/org/apache/commons/collections/MultiMap.java:[69,19]
remove(java.lang.Object,java.lang.Object) in
org.apache.commons.collections.MultiMap clashes with
remove(java.lang.Object,java.lang.Object) in java.util.Map
  return type java.lang.Object is not compatible with boolean
[ERROR]
/home/luc/tmp/downloaded-RC/dist/source/commons-collections-3.2.2-src-t/src/java/org/apache/commons/collections/map/MultiKeyMap.java:[200,19]
remove(java.lang.Object,java.lang.Object) in
org.apache.commons.collections.map.MultiKeyMap cannot implement
remove(java.lang.Object,java.lang.Object) in java.util.Map
  return type java.lang.Object is not compatible with boolean
[ERROR]
/home/luc/tmp/downloaded-RC/dist/source/commons-collections-3.2.2-src-t/src/java/org/apache/commons/collections/MultiHashMap.java:[334,19]
remove(java.lang.Object,java.lang.Object) in
org.apache.commons.collections.MultiHashMap cannot implement
remove(java.lang.Object,java.lang.Object) in java.util.Map
  return type java.lang.Object is not compatible with boolean

Then I forced maven to run using java7 and it was fine. The pom does
specify maven.compile.source and maven.compile.target to be 1.2. So
I don't think it is a real problem with the source code, but rather
a problem with maven 3.3.3 and openJDK8 (I also do have some problems
with [math], so I usually force maven to run with Java7).

So I don't think this probelm is a blocker.

> 
> This vote will close no sooner that 72 hours from now, i.e. after 2300
> GMT 12-November 2015
> 
>   [X] +1 Release these artifacts

Luc

>   [ ] +0 OK, but...
>   [ ] -0

Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)

[luc]

Le 2015-11-06 02:34, Gilles a écrit :

On Thu, 5 Nov 2015 15:41:57 -0700, Phil Steitz wrote:

On 11/5/15 1:58 PM, Luc Maisonobe wrote:

Le 05/11/2015 12:25, Gilles a écrit :

Hello.

On Wed, 04 Nov 2015 10:13:00 +0100, luc wrote:

Hi all,

I would like to release 3.6 in the upcoming weeks.
There have been a bunch of bug fixes and a few evolutions that are
important to me.

s/3.6/4.0/

And the statement is still true.


[...]

Of course, once 3.6 is out the MATH_3_X branch will remain alive 
and

we could also release other versions later on in the 3.x series.
Should we worry that the next major release will be endlessly 
delayed?
I think we are really quite far from releasing 4.0 as in many 
packages
we did not even start refactoring API. Optimization is clearly the 
most
well known example, but there are also other things waiting in the 
pipe

for geometry and ode.


Is there any specific target for 4.0?


Yes, at least having changed public API.


Could we judge how far we are from releasing a major release with the
same arguments which you used for 3.6 (many additions, bug fixes,
things someone would like to use, etc.)?

4.0 does not need to be perfect. [3.0 was supposed to be perfect ;-).]
4.1 will be!  Or 4.2, or 5.0...


4.x for x > 1 will have exactly the same problems as 4.0 API-wise since
once 4.0 is out the API will be fixed.



Let's not forget that we agreed to work towards 4.0, and that the 3.x
branch was an afterthought.


I agree and was slightly reluctant to continue on 3.X at that time. 
Deciding
to still keep this branch was indeed a good idea. I properly address the 
problem

that we did not find time to work on 4.0 as we wanted.



Since we now effectively maintain two versions of CM, it makes sense
to allow people to benefit from the extra work.


Yes, but our own overzealous rule about compatibility (I can take the
blame here, I am guilty for this) induces that we change API only when
major versions are published. We do have the opportunity to do this for
4.0, lets use it at least and not again postpone needed changes. Our 3.X
API sucks in many places and we know it.



My viewpoint is that we can have releases from both branches, making
it clear what is old/deprecated/broken in 3.x and what is still
missing in 4.y.


If it were only missing features, that can be added, I would agree. 
However

some of the changes are really modifications of existing interfaces.




I agree on this.  One thing I forgot to mention above is I think we
may have a few places in 3.x optimization where every way to do
something is deprecated.  I suggest we take a careful look and
undeprecate where necessary to make 3.6 usable without warnings.  I
may be wrong since I don't use that code myself; but I think its
worth taking a careful look and considering removal of some
deprecations.


I'm against this.  And is why I started the sure-to-be-controversial
discussion on 4.0.


I also don't really like the idea of undeprecating these things.



We agreed that things were (relatively) broken, and we agreed on a
way forward (fluent API, refactoring of the "optim" classes); yet
things don't move, because there is no urge to fix them since new
features can be back-ported indefinitely to the 3.x series.


No, things don't move because I didn't find time. I am really,
really busy doing lots of different stuff. I am also really, really
aware this API should be improved and fluent API is still a way I would
like to explore for this. And no, I am not sure this will work and
4.x will see the end of these problems.



Undeprecating what we agreed should be deprecated would only
reinforce that feeling, and certainly won't attract attention that
we need help to make progress.
[And, in addition, 3.x is tied to old Java5 (known tune)...]

In summary, I think that new features should only go to the master
branch, while only bug-fixes would be back-ported to MATH_3_X.
Thus everybody can have the best of both, while reducing the
amount of work for the developers.  Continuing in this way, and
we'll soon have to also "forward-port" bugs reported against the
3.x series. :-/


Hey, I already do that! The following one-liner is my new
favorite:

  git diff -p MATH_3_X~1 MATH_3_X | sed 's,math3,math4,g' | patch -p1

Yes, it is cumbersome.

best regards,
Luc




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: [math] Version mgt idea

[Luc Maisonobe]

Le 06/11/2015 18:18, sebb a écrit :
> On 6 November 2015 at 16:17, Phil Steitz  wrote:
>> Here is an idea that might break our deadlock re backward
>> compatibility, versioning and RERO:
>>
>> Agree that odd numbered versions have stable APIs - basically adhere
>> to Commons rules - no breaks within 3.0, 3.1, ..., 3.x... or 5.0,
>> 5.1... but even-numbered lines can include breaks - so 4.0 and 4.1
>> might not be compatible.  We would always maintain both an odd and
>> even branch - ideally in such a way that when an even numbered line
>> stabilized it would add a last hurrah of breaks and move to odd.
>> People wanting stable APIs could just stick with the odd-numbered
>> lines and [math] developers wanting to experiment with things and
>> not worry about compatibility could do that in the even-numbered
>> lines.  In effect, this is sort of what we are doing now in 3.x / 4.x.
>>
>> I know above violates Commons policy if we actually cut releases
>> from the even-numbered branches - we would have to get agreement
>> from the Commons PMC that this is OK or somehow label the releases
>> differently.  Just an idea to get us out of our current bind...
> 
> That would likely cause problems with Maven, which will pick the
> latest release, regardless of whether it is even or odd.

No because we change the artifact coordinates too.
So people who depend on apache.commons.math3 will never see
artifacts from the apache.commons.math4 series.

> [However changing the gid/uid without changing the package name also
> causes problems with Maven.]
> 
> Unless it is possible to add a marker to the release such that Maven
> does not consider it when looking for the latest release.
> The only such marker I know of is SNAPSHOT - such releases are not
> added to Maven Central so cannot be accidentally added to the
> classpath.
> 
> Maybe there is another marker which could be used that tells Maven not
> to consider that version.
> 
> If there is no other such marker, one way to avoid these issues would
> be to not publish the even releases to Maven Central.
> Users would have to download them some other way.
> 
> Maybe there is mileage in having a staging repo for Commons as a half-way 
> house.
> Users would need to specifically add the repo to their pom to use the repo.
> [I think I suggested something like this for some Commons Maven
> plugins that were for developer use only]
> 
> Note that publishing even-numbered releases to the ASF mirror service
> can also cause problems if the unstable releases are not clearly
> marked.
> 
>> Phil
>>
>>
>> -
>> 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: [math] Version mgt idea

[Luc Maisonobe]

Le 06/11/2015 18:31, Gilles a écrit :
> Hi.
> 
> On Fri, 6 Nov 2015 09:17:18 -0700, Phil Steitz wrote:
>> Here is an idea that might break our deadlock re backward
>> compatibility, versioning and RERO:
>>
>> Agree that odd numbered versions have stable APIs - basically adhere
>> to Commons rules - no breaks within 3.0, 3.1, ..., 3.x... or 5.0,
>> 5.1... but even-numbered lines can include breaks -
> 
> I like the proposal to be more lax on compatibility breaking than
> I ever dreamed of.  ;-)

Yeah, good idea!
Go for it.

> 
>> so 4.0 and 4.1
>> might not be compatible.
> 
> Isn't that going to cause JAR hell?

As long as people are aware there are no compliance implied,
then they know what they have to do when they decide to
use this.

best regards,
Luc

> 
> Gilles
> 
>> We would always maintain both an odd and
>> even branch - ideally in such a way that when an even numbered line
>> stabilized it would add a last hurrah of breaks and move to odd.
>> People wanting stable APIs could just stick with the odd-numbered
>> lines and [math] developers wanting to experiment with things and
>> not worry about compatibility could do that in the even-numbered
>> lines.  In effect, this is sort of what we are doing now in 3.x / 4.x.
>>
>> I know above violates Commons policy if we actually cut releases
>> from the even-numbered branches - we would have to get agreement
>> from the Commons PMC that this is OK or somehow label the releases
>> differently.  Just an idea to get us out of our current bind...
>>
>> Phil
>>
>>
>> -
>> 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: [Math] Releasing 4.0? (Was: releasing 3.6 ?)

[Luc Maisonobe]

Le 06/11/2015 14:55, Gilles a écrit :
> Hi Luc.
> 
> On Fri, 06 Nov 2015 10:04:23 +0100, luc wrote:
>> Le 2015-11-06 02:34, Gilles a écrit :
>>> On Thu, 5 Nov 2015 15:41:57 -0700, Phil Steitz wrote:
>>>> On 11/5/15 1:58 PM, Luc Maisonobe wrote:
>>>>> Le 05/11/2015 12:25, Gilles a écrit :
>>>>>> Hello.
>>>>>> On Wed, 04 Nov 2015 10:13:00 +0100, luc wrote:
>>>>>>> Hi all,
>>>>>>> I would like to release 3.6 in the upcoming weeks.
>>>>>>> There have been a bunch of bug fixes and a few evolutions that are
>>>>>>> important to me.
>>>>>> s/3.6/4.0/
>>>>>> And the statement is still true.
>>>>>>
>>>>>>> [...]
>>>>>>> Of course, once 3.6 is out the MATH_3_X branch will remain alive and
>>>>>>> we could also release other versions later on in the 3.x series.
>>>>>> Should we worry that the next major release will be endlessly
>>>>>> delayed?
>>>>> I think we are really quite far from releasing 4.0 as in many packages
>>>>> we did not even start refactoring API. Optimization is clearly the
>>>>> most
>>>>> well known example, but there are also other things waiting in the
>>>>> pipe
>>>>> for geometry and ode.
>>> Is there any specific target for 4.0?
>>
>> Yes, at least having changed public API.
> 
> There are two parts to that task: delete the deprecated code, and provide
> the same (or better) functionality with new code.

Not only that.
When an interface intended to be implemented by users is changed
(say FirstOrderDifferentialEquations for example, then as soon as a
user update to the version after the change, all its implementations
have to be changed at once.

> I thought that the "delete" updates had been performed by Thomas.
> Is there anything else that must go, but still is in master, and is not
> deprecated in MATH_3_X?

Yes, at least in ode (interface changes) and geometry (semantic changes).

> If so, a JIRA "task" issue should indicate what to do, and this should be
> resolved before release (IMHO).

OK for a JIRA task, but we cannot deprecate the user interfaces involved.

> 
>>> Could we judge how far we are from releasing a major release with the
>>> same arguments which you used for 3.6 (many additions, bug fixes,
>>> things someone would like to use, etc.)?
>>> 4.0 does not need to be perfect. [3.0 was supposed to be perfect ;-).]
>>> 4.1 will be!  Or 4.2, or 5.0...
>>
>> 4.x for x > 1 will have exactly the same problems as 4.0 API-wise since
>> once 4.0 is out the API will be fixed.
> 
> Yes, but I mean that
> 1. we should list all agreed changes even if they are not implemented
>(like for "optim"),
> 2. then, the scene is set for 4.0 (and the release could indeed miss
>many bits, for which users will need 3.6),
> 2. we can add classes and methods in 4.x (x > 0), and where not
>possible (Java "interface"), then we'll go on and create 5.x.
> [As someone said, plenty of integers left...]

With Phil proposal to use an even/odd scheme, things become simpler.

> 
> "Release early, release often".
> We still do neither.
> Despite several developers agreeing on the principle, I'm being put in
> the position to argue against "Release later"...
> 
>>> Let's not forget that we agreed to work towards 4.0, and that the 3.x
>>> branch was an afterthought.
>>
>> I agree and was slightly reluctant to continue on 3.X at that time.
>> Deciding
>> to still keep this branch was indeed a good idea. I properly address
>> the problem
>> that we did not find time to work on 4.0 as we wanted.
> 
> I've mixed feelings about MATH_3_X.  I now realize that I had unconsciously
> imagined that it would be short-lived (so the few new features introduced
> during that period could indeed be routinely back-ported).
> 
> Providing longer-term bug-fix support is a good thing.
> Back-porting everything is IMO definitely a bad idea.
> 
>>> Since we now effectively maintain two versions of CM, it makes sense
>>> to allow people to benefit from the extra work.
>>
>> Yes, but our own overzealous rule about compatibility (I can take the
>> blame here, I am guilty for this) induces that we change API only when
>> major versions are published. We do have the opportunity to do this for
>> 4.0, lets use it at least and not again postpone needed changes. Our 3.X
&g

Re: [Math] Releasing 4.0? (Was: releasing 3.6 ?)

[Luc Maisonobe]

Le 05/11/2015 12:25, Gilles a écrit :
> Hello.
> 
> On Wed, 04 Nov 2015 10:13:00 +0100, luc wrote:
>> Hi all,
>>
>> I would like to release 3.6 in the upcoming weeks.
>> There have been a bunch of bug fixes and a few evolutions that are
>> important to me.
> 
> s/3.6/4.0/
> 
> And the statement is still true.
> 
>> [...]
>>
>> Of course, once 3.6 is out the MATH_3_X branch will remain alive and
>> we could also release other versions later on in the 3.x series.
> 
> Should we worry that the next major release will be endlessly delayed?

I think we are really quite far from releasing 4.0 as in many packages
we did not even start refactoring API. Optimization is clearly the most
well known example, but there are also other things waiting in the pipe
for geometry and ode.

best regards,
Luc

> 
> Regards,
> Gilles
> 
>> What do other developers want to have in the 3.6 release?
>>
>> Of course, I volunteer to be the release manager.
>>
>> best regards,
>> Luc
> 
> 
> 
> -
> 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: [Math] PolynomialCurveFitter

[Luc Maisonobe]

Le 05/11/2015 19:00, Bruce Johnson a écrit :
> 
> Issue MATH-1009 was closed as resolved in version 3.3.
> 
> The issue raised was about the fact that the PolynomialFitter (now
> PolynomialCurveFitter) does the curve fit with non-linear regression
> (and requires initial guess and number of iterations).
> 
> I can’t think of any reason why a polynomial curve fit (with a least
> squares target) should be done this way instead of doing it with a
> linear method (like QR or SVD) and I don’t know of any other math
> package that does polynomial fits this way.
> 
> I’m not a numerical methods expert, so maybe I’m wrong, but it seems
> that this really should be resolved before the release of Math 4.0
> (or even 3.6).
> 
> Should MATH-1009 be reopened, or should I create a new issue (which
> will just be a copy of 1009 changed to refer to
> PolynomialCurveFitter).

Yes, a new issue would be better.

best regards,
Luc

> 
> Bruce
> 
> 
> 
> 
> -
>
> 
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: [5/6] [math] Fixed findbugs warning.

[luc]

Le 2015-11-04 14:34, Gilles a écrit :

On Wed, 04 Nov 2015 14:20:55 +0100, Gilles wrote:

[...]
But it was perhaps a bad design choice to have "PairNeuronDouble" 
implement

"Comparable".
I propose to use an explicit "Comparator" in order to fix the 
problem.


Good idea!
I have done it and pushed it on both master and MATH_3_X branches.


I was working on that! :-(


And I've just overwritten (sorry!) your changes in "master" with
something that would seem to be a little bit more efficient.

I've _not_ done so in the MATH_3_X branch.
Will you do the "back-porting"?


Fine, I've done it.
I have also removed the geValue method since it was not needed anymore.

best regards,
Luc



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: [5/6] [math] Fixed findbugs warning.

[luc]

Le 2015-11-04 13:44, Gilles a écrit :

On Tue, 03 Nov 2015 18:07:50 +0100, Luc Maisonobe wrote:

Le 03/11/2015 15:33, Gilles a écrit :

On Tue, 03 Nov 2015 11:06:50 -, l...@apache.org wrote:

Fixed findbugs warning.

When defining compareTo, we should also define equals and hashcode.


Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
Commit:
http://git-wip-us.apache.org/repos/asf/commons-math/commit/04454fc0
Tree: 
http://git-wip-us.apache.org/repos/asf/commons-math/tree/04454fc0
Diff: 
http://git-wip-us.apache.org/repos/asf/commons-math/diff/04454fc0


Branch: refs/heads/MATH_3_X
Commit: 04454fc0096d5d388e10c5b13024b2a947a4e923
Parents: b72d446
Author: Luc Maisonobe <l...@apache.org>
Authored: Tue Nov 3 11:23:46 2015 +0100
Committer: Luc Maisonobe <l...@apache.org>
Committed: Tue Nov 3 11:23:46 2015 +0100



--
 .../commons/math3/ml/neuralnet/MapUtils.java| 24
+---
 1 file changed, 21 insertions(+), 3 deletions(-)


--




http://git-wip-us.apache.org/repos/asf/commons-math/blob/04454fc0/src/main/java/org/apache/commons/math3/ml/neuralnet/MapUtils.java



--
diff --git
a/src/main/java/org/apache/commons/math3/ml/neuralnet/MapUtils.java
b/src/main/java/org/apache/commons/math3/ml/neuralnet/MapUtils.java
index 83036c2..6ef9327 100644
--- 
a/src/main/java/org/apache/commons/math3/ml/neuralnet/MapUtils.java
+++ 
b/src/main/java/org/apache/commons/math3/ml/neuralnet/MapUtils.java

@@ -17,14 +17,15 @@

 package org.apache.commons.math3.ml.neuralnet;

-import java.util.HashMap;
+import java.util.ArrayList;
 import java.util.Collection;
 import java.util.Collections;
+import java.util.HashMap;
 import java.util.List;
-import java.util.ArrayList;
+
+import org.apache.commons.math3.exception.NoDataException;
 import org.apache.commons.math3.ml.distance.DistanceMeasure;
 import 
org.apache.commons.math3.ml.neuralnet.twod.NeuronSquareMesh2D;

-import org.apache.commons.math3.exception.NoDataException;
 import org.apache.commons.math3.util.Pair;

 /**
@@ -320,5 +321,22 @@ public class MapUtils {
 public int compareTo(PairNeuronDouble other) {
 return Double.compare(this.value, other.value);
 }
+
+/** {@inheritDoc} */
+@Override
+public boolean equals(Object other) {
+if (!(other instanceof PairNeuronDouble)) {
+return false;
+}
+return Double.doubleToRawLongBits(value) ==
+   Double.doubleToRawLongBits(((PairNeuronDouble)
other).value);
+}
+
+/** {@inheritDoc} */
+@Override
+public int hashCode() {
+return Double.valueOf(value).hashCode();
+}
+
 }
 }


I think that in general, it is not correct to assume pair equality
by only taking "value" into account.
I also think that the default implementation provided the correct
semantics (for the sole usage of sorting).


Sure, but as the compareTo method did only use value, the equals 
method
should be consistent with it. Otherwise, you could have compareTo 
return

0 when equals does not return true for example.


It is plain wrong (in general) to consider two objects equal just 
because they
have the same rank according to an ordering based on part of their 
properties.
[It's akin to saying e.g. that two books are the same, because they 
happen

to have the same price tag.]

But it was perhaps a bad design choice to have "PairNeuronDouble" 
implement

"Comparable".
I propose to use an explicit "Comparator" in order to fix the problem.


Good idea!
I have done it and pushed it on both master and MATH_3_X branches.

best regards,
Luc



Best,
Gilles



best regards,
Luc



-
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

[math] releasing 3.6 ?

[luc]

Hi all,

I would like to release 3.6 in the upcoming weeks.
There have been a bunch of bug fixes and a few evolutions that are
important to me.

I am still working on two things both related to ode: first trying
to stabilize the Adams-BAshforth and Adams-Moulton integrators which
sometime get stuck in an infinite loop reducing step size, and second
adding a Field integrator, in exactly the same spirit we have added
a field version of other algorithms (geometry and linear algebra come
to my mind, as well as a specialized version of solver for Dfp).

Of course, once 3.6 is out the MATH_3_X branch will remain alive and
we could also release other versions later on in the 3.x series.

What do other developers want to have in the 3.6 release?

Of course, I volunteer to be the release manager.

best regards,
Luc

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

Re: [5/6] [math] Fixed findbugs warning.

[Luc Maisonobe]

Le 03/11/2015 15:33, Gilles a écrit :
> On Tue, 03 Nov 2015 11:06:50 -, l...@apache.org wrote:
>> Fixed findbugs warning.
>>
>> When defining compareTo, we should also define equals and hashcode.
>>
>>
>> Project: http://git-wip-us.apache.org/repos/asf/commons-math/repo
>> Commit:
>> http://git-wip-us.apache.org/repos/asf/commons-math/commit/04454fc0
>> Tree: http://git-wip-us.apache.org/repos/asf/commons-math/tree/04454fc0
>> Diff: http://git-wip-us.apache.org/repos/asf/commons-math/diff/04454fc0
>>
>> Branch: refs/heads/MATH_3_X
>> Commit: 04454fc0096d5d388e10c5b13024b2a947a4e923
>> Parents: b72d446
>> Author: Luc Maisonobe <l...@apache.org>
>> Authored: Tue Nov 3 11:23:46 2015 +0100
>> Committer: Luc Maisonobe <l...@apache.org>
>> Committed: Tue Nov 3 11:23:46 2015 +0100
>>
>>
>> --
>>  .../commons/math3/ml/neuralnet/MapUtils.java| 24
>> +---
>>  1 file changed, 21 insertions(+), 3 deletions(-)
>>
>> --
>>
>>
>>
>> http://git-wip-us.apache.org/repos/asf/commons-math/blob/04454fc0/src/main/java/org/apache/commons/math3/ml/neuralnet/MapUtils.java
>>
>>
>> --
>> diff --git
>> a/src/main/java/org/apache/commons/math3/ml/neuralnet/MapUtils.java
>> b/src/main/java/org/apache/commons/math3/ml/neuralnet/MapUtils.java
>> index 83036c2..6ef9327 100644
>> --- a/src/main/java/org/apache/commons/math3/ml/neuralnet/MapUtils.java
>> +++ b/src/main/java/org/apache/commons/math3/ml/neuralnet/MapUtils.java
>> @@ -17,14 +17,15 @@
>>
>>  package org.apache.commons.math3.ml.neuralnet;
>>
>> -import java.util.HashMap;
>> +import java.util.ArrayList;
>>  import java.util.Collection;
>>  import java.util.Collections;
>> +import java.util.HashMap;
>>  import java.util.List;
>> -import java.util.ArrayList;
>> +
>> +import org.apache.commons.math3.exception.NoDataException;
>>  import org.apache.commons.math3.ml.distance.DistanceMeasure;
>>  import org.apache.commons.math3.ml.neuralnet.twod.NeuronSquareMesh2D;
>> -import org.apache.commons.math3.exception.NoDataException;
>>  import org.apache.commons.math3.util.Pair;
>>
>>  /**
>> @@ -320,5 +321,22 @@ public class MapUtils {
>>  public int compareTo(PairNeuronDouble other) {
>>  return Double.compare(this.value, other.value);
>>  }
>> +
>> +/** {@inheritDoc} */
>> +@Override
>> +public boolean equals(Object other) {
>> +if (!(other instanceof PairNeuronDouble)) {
>> +return false;
>> +}
>> +return Double.doubleToRawLongBits(value) ==
>> +   Double.doubleToRawLongBits(((PairNeuronDouble)
>> other).value);
>> +}
>> +
>> +/** {@inheritDoc} */
>> +@Override
>> +public int hashCode() {
>> +return Double.valueOf(value).hashCode();
>> +}
>> +
>>  }
>>  }
> 
> I think that in general, it is not correct to assume pair equality
> by only taking "value" into account.
> I also think that the default implementation provided the correct
> semantics (for the sole usage of sorting).

Sure, but as the compareTo method did only use value, the equals method
should be consistent with it. Otherwise, you could have compareTo return
0 when equals does not return true for example.

best regards,
Luc

> 
> 
> 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: [3/4] [math] Fixed checkstyle warnings.

[luc]

Le 2015-11-02 16:00, Gilles a écrit :

Hi.

On Mon, 02 Nov 2015 14:35:09 -, l...@apache.org wrote:

Fixed checkstyle warnings.

These warnings correspond to redundant modifiers (public, static, 
...).


It is not clear to me why they are redundant.


This is explained here:

  
<http://checkstyle.sourceforge.net/config_modifier.html#RedundantModifier>





They are identified by recent versions of checkstyle, in particular 
the

one shipped with Eclipse. They are not detected by our
maven-checkstyle-plugin yet because it is not the latest one and still
depends on an older version of checkstyle.


Wouldn't have it been better to first update the plugin, so we can all
have the opportunity to understand the problems?


Until very recently, even the latest maven-checkstyle-plugin did not
depend on a recent-enough version of the checkstyle tool. The tool
evolves quite fast and it is difficult to keep track. Unfortunately,
on the Eclipse side they did depend on a recent version of the tool,
but I was not able to find which one.

Anyway, the checks will change at one point or another, and the
RedundantModifier check was activated in our checkstyle.xml since
a long time ago, as it was quite interesting. For all the checks we
have activated, up to now we have trusted the guys who make the tool
and only set up comment filter when there are false positive (there
are a few false positive in our project). One or two commits more are
in the pipe for this to deal with the new false positives that triggered
test failures on serialization.

best regards,
Luc



Best 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: [VOTE] Accept Naomi

[luc]

Le 2015-10-30 01:42, Phil Steitz a écrit :

This is a VOTE to accept the code discussed in [1] and available for
review using the git commands below.  All are welcome to vote, votes
from PMC members are binding.  Assuming a positive vote, we will
execute a software grant with the authors and use the code as the
basis for a new Commons Sandbox component.

This VOTE will close in 72 hours.  More discussion on the code and
its fit in Commons is always welcome, but please do not reply to
this thread with discussion, other than embedded justification for
negative VOTES.  Use the thread from [1] instead.

Git commands to grab the code:

git clone g...@github.com:NormanShapiro/Naomi.git
git checkout gh-pages

Thanks!

Phil
[1] http://markmail.org/message/imoi5aipf63f7rsa

[X] +1 Yes!


Luc


[ ] +0 OK...
[ ] -0 OK, but...
[ ] -1 We should not do this, because...


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


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

Re: [MATH] ComplexUtils pull request; some future proposals

[luc]

Le 2015-10-30 10:58, Gilles a écrit :

On Fri, 30 Oct 2015 09:20:00 +, Eric Barnhill wrote:

On 30/10/15 02:15, Gilles wrote:


There are some problems with the Javadoc (wrong "@return" comment).
Not all local variables that are constant are declared "final".


I am happy to give it all another proof read. I take it the procedure
is to fork the dedicated branch and then submit a pull request to that
branch?


I couldn't say; we don't have a procedure yet... :-}


In fact, pull requests are really github-specific, and we don't have
a complete integration between our Apache infrastructure and github
for Commons Math. As an example, the requests are not directly
forwarded to our mailing lists so we may miss them (and we already
missed several ones ...).

One Apache motto is: "if it didn't happen on the mailing lists,
it didn't happen". So the best medium for discussion is this mailing
list. The best medium for registering issues, evolution proposals
and patches is our JIRA instance. Typically, issues start at JIRA,
are discussed here if the discussion is lengthy or need to get
public oversight, and the patches coming for non-committers are attached
to the JIRA issue (our mailing list strips attachments).

best regards,
Luc





Shouldn't independent changes be performed in separate commits?
[Referring to "IntegerSequence" and "LaguerreSolver".]


I made edits to the Solver in particular because my commit would
otherwise have left it broken.


Since you added new methods, that should not be the case.
Whenever possible, it's clearer to modify calls in other parts of the
library in a separate commit, and then remove obsolete methods in a
third step.


If that is not best practice I am happy
to revert and submit independently.



Actually, I don't like the new "size" method in "IntegerSequence".
Although the number of elements is needed in the new methods in
ComplexUtils, I don't think that we should advertise the 
functionality

in its current (necessarily) poor implementation.
A better alternative is to have an instance that will hold the
number of elements it contains:
  https://issues.apache.org/jira/browse/MATH-1286


My first impulse was to see if I could add a field to the range
object that contained its size. But as the method returns an Iterator
I didn't see a way to do that without returning a subclass that
extended Iterator in some way instead. I figured that was not a
desired outcome. So instead I incorporated what as far as I know is
best practice:


http://stackoverflow.com/questions/9720195/what-is-the-best-way-to-get-the-count-length-size-of-an-iterator


They don't really say it's best practice, rather, it's all you can
do with an Iterator. ;-)


Alternatively I could just create a local private method in
ComplexUtils that determined the size by iterating through the range
and call that, and leave IntegerSequence alone.


When MATH-1286 is resolved, that won't be necessary.

Best 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: [MATH] ComplexUtils pull request; some future proposals

[Luc Maisonobe]

Le 28/10/2015 17:33, Eric Barnhill a écrit :
> Dear all,

Hi Eric,

> 
> Thanks for the feedback on ComplexUtils and I have submitted a pull request
> with the edits.

I have pulled this request into our git repository, with minor edits.
The changes are mainly removing tabs and trailing blanks, and fixing
some javadocs.

In the initialize methods, I have also replaced the construction of
a bunch of new Complex(0, 0) with the reuse of the constant
Complex.ZERO. As our complex instances are immutable, it seemed better
to me this way.

For now, it is in a dedicated branch named complex-and-primitive-arrays,
so the pull request may not close automatically as it is not on master.

Do other developers agree with merging this branch to master?

> 
> I have added functionality to convert between Complex arrays and real
> double, real float, interleaved double, interleaved float, split double
> (one real, one imag) and split float arrays. Per Gilles' suggestion I have
> included the use of IntegerSequence.range() arguments and the methods
> mostly refer to workhorse Extract() methods. I also added a method to
> initialize Complex[] arrays to all zeros, to avoid null pointer exceptions.
> 
> I have also updated ComplexUtilsTest to include JUnit tests of every
> method, which all pass. I had to define many arrays to run the tests and
> hopefully the comments make the purpose of each clear. I was not entirely
> clear how to use the tolerance parameter and submitted ulp each time, so
> contact me if I should do something else.
> 
> I am using nearly all of these methods in the medical imaging library I am
> working on so I don't think I overdid it.
> 
> Repeating the methods for different types, so many times, got me to
> thinking about the overall structure of arrays in math functions and what I
> would most like to see. So in my own library I am creating a MathArray
> superclass. This in turn can be Complex, real, split, or interleaved, and
> contain any type of primitive, kind of like the ImageJ ImageProcessor
> interface This will allow every method I have put in ComplexUtils, and many
> more I keep in other libraries, to be written only once for the superclass.
> Further the superclass will have a full range of math methods that operate
> on arrays element wise, enabling syntax approaching Matlab to be used for
> arrays that is basically the same as what is already in place for Complex
> objects, i.e. commands like
> array1.multiply(array2).pwr(2).zeroPad(n).resizeBicubic(2).stripPadding(n/2)
>  .
> 
> If this is of interest to the community I can submit a pull request when
> I've got it worked up. If someone has already designed such a library I'd
> be grateful if someone mentions it before I get started.

This should be discussed in a separate thread.

best regards,
Luc

> 
> Best,
> Eric
> 


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

Re: Issue using git checkouts of commons(-math) in Eclipse

[Luc Maisonobe]

Hi Eric,

Le 15/10/2015 00:13, Eric Barnhill a écrit :
> When I check out the commons-math repo from git and import into Eclipse,
> the package structure causes errors. Because the dir structure is
> src/main/java/org/apache etc., Eclipse throws an error on all import
> statements beginning with "org.apache" . It is looking for import
> statements that begin with "main.java.org.apache" and offers to switch the
> import statements.
> 
> This happens whether I import the project as of Git type, or as of Maven
> type.
> 
> Does anyone know how to fix this?

The packagage layout is a standard maven layout (you can check it
from the command line). Eclipse should knows this layout already, so
it seems strange it doesn't set the paths correctly.

Anyway, you can set the paths manually from eclipse by right-clicking
in the package explorer at project level and select in the context
menu the entry: Build Path -> Configure Build Path.

A popup wizard should appear, where you can select in the right-hand
panel the tab "Source". This tab is used to configure the source folders
to be included in the build path. The list of source folders that are
needed for proper build and test is:

  /src/main/java
  /src/main/resources
  /src/test/java
  /src/test/resources

Note also that in the libraries tab in the same wizard, you should also
have the Junit 4 library.

Hope this helps
Luc

> 
> Thanks,
> Eric
> 


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

Re: [Math] Utilitzation of SLF4J?

[Luc Maisonobe]

 the context of that asynchronous collaboration, the role of the
>>>> library's developer is to carefully choose what *could* be
>>>> interesting, if the need should arise.
>>>>
>>>> So, can we eventually discuss the _technical_ arguments against
>>>> logging inside CM, rather than personal opinion?
>>> again, what I want to see is an example what *should* be logged in the
>>> case of an algorithm. Take the LevenbergMarquardtOptimizer as an
>>> example:
>>>
>>>  * what did you log using System.out.println()?
>>>  * the algo computes a lot of internal data, which of these is
>>> interesting for debugging problems or for general logging?
>>>  * there are various branches the algo can take, are just some
>>> interesting to log, or all of them?
>>>
>>> the use-cases presented so far were mainly about debugging specific
>>> problems, and I am *strongly* against adding logging information just
>>> for this purpose as you are clearly facing a dilemma here:
>>>
>>>  you have to log *everything* an algo does as otherwise you might miss
>>> the part that creates problems
>>>
>>>  but logging everything is not useful for a standard user of the library
>>> so it contradicts the original proposal to include logging
>>>
>>> Again, CM is not an application where you need to log what it is doing,
>>> but a bunch of algorithms and utility methods to perform certain
>>> calculations. I fail to see the need to add logging. What could be
>>> useful, and we had requests like that in the past, is to observe the
>>> state of a certain algorithm and to decide how to proceed in certain
>>> cases.
>>>
>>> That is useful for users.
>>>
>>> Another useful addition would be to add more aggressive assertions. If
>>> one user encounters a problem, he/she could run the application with
>>> assertions enabled and spot potential problems e.g. due to wrong input.
>>>
>>> Logging is a solution for a non existing problem imho.
>>> Logging will not avoid the need to debug CM in case of problems imho.
>>
>> +1
>> The other thing I would add is that the one place where it does make
>> sense to dump text is in exception error messages, which is a place
>> where I think we could really improve things.  Fortunately, that is
>> fairly easily done.
>>
>> I have seen nothing in this thread to convince me that adding
>> logging in [math] will be net positive for either those of us who
>> maintain the component or for users.  If we are not providing clear
>> exception error messages and/or APIs (with complete documentation)
>> so that users can understand what they need to debug their
>> applications, then we should focus on solving those problems.
>>
>> Phil
> 
> First, you carefully do not reply to any of the concrete arguments
> given in this thread, second you give a conclusion to an issue not
> reported in this thread: exceptions and logging do not provide the
> same service.
> 
> At least, I'd wish that people sharing their own opinion (it's
> nothing more since _zero_ technical argument against logging have
> been put forth) stop taking the collective "users" on their side.
> As for *actual* users/maintainers, Ole and I have a need, while
> Thomas and you haven't.  Those are all the facts that exist until
> now.
> 
> In such a situation, what do we do as a project; maintain the status
> quo, or try for a change?
> On numerous occasions over the years, the status quo was enforced;
> and I don't see that it benefited the project in terms of new
> contributors.
> So I'm +1 for trying to change, for a change.

I think one thing has been written in this thread that is worth
noting and could be an intermediate position.

It seems to me one place where we could get some useful information,
and provide it to users is for iterative algorithms (both optimizers
and solvers have already been mentioned, we could add ode integrators
as well to this). For such algorithms, having some way to monitor how
the iterations perform seem an improvement. An observer pattern as
proposed a few days ago for this kind of algorithms would be fine.
Once again, something simple and that does not attempt to be hyper
generic but rather taylored to the algorithms (i.e. most probably
different observer interfaces for different algorithms types).

This intermediate position would provide something to both users
and developers, and it would not attempt to log everything and
add a dependency (I am probably the one who opposed to logging on
the grounds of dependencies).

best regards,
Luc

> 
> 
> Gilles
> 
>>>
>>> Thomas
>>>
>>>>>>>> My long-standing mentioning of slf4j was only because of its
>>>>>>>> "weightlessness" (thanks to the no-op implementation of its API).
>>>>>>>> If "Log4j 2" has followed this path, good for everyone.
>>>>>>>>
>>>>>>>> No objection, then?
>>>>>>>
>>>>>>> I'm still not clear what log4j 2 adds -- most Apache java projects
>>>>>>> seem to
>>>>>>> use log4j 1.2, seems to work well. -- H
>>>>>>>
>>>>>> I can only answer about "slf4j" where the "f" stands for facade: it's
>>>>>> "only"
>>>>>> an API, with bridges to several logging frameworks (log4j, logback,
>>>>>> etc.).
>>>>>>
>>>>>> The separation of concerns (API vs one of several implementations to
>>>>>> choose from)
>>>>>> allows the top-level application to uniformly configure logging or to
>>>>>> disable it
>>>>>> completely (if choosing the "no-op" implementation).
>>>>> That is virtually true for all logging frameworks, including log4j,
>>>>> slf4j, commons-logging.
>>>> Has it always been true?
>>>> I'm certainly no expert; I only try to stay clear of tools about which
>>>> people complain a lot.  A few years ago, that was the case of jcl and
>>>> jul as compared to slf4j.
>>>>
>>>>
>>>> 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
>>>
>>>
>>
>>
>>
>> -
>> 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: [Math] Utilitzation of SLF4J?

[Luc Maisonobe]

Le 26/09/2015 21:49, Romain Manni-Bucau a écrit :
> Le 26 sept. 2015 12:07, "Luc Maisonobe" <l...@spaceroots.org> a écrit :
>>
>> Le 26/09/2015 20:59, Ralph Goers a écrit :
>>> I don’t normally participate in Math but I do feel the need to stick my
> nose in here.
>>> 1. You are absolutely correct to determine whether you need logging at
> all before discussing what to choose.
>>> 2. If you do decide logging is required:
>>>   a. Please stay away from java.util.logging. It really would be the
> best solution for a framework like math except it is extremely difficult to
> redirect efficiently to some other logging framework. The methods used by
> SLF4J and Log4j are imperfect to say the least.
>>>   b. Log4j 1.x has reached eol. It effectively has not been supported
> for 5 years.
>>>   c. Log4j 2 has an API that can be redirected to another logging
> framework if desired.
>>>   d. Commons logging still works but its API is very primitive by
> todays standards. That said, it does work.
>>
>> From what I have seen, if I ever were to choose a logging framework for
>> any project, I agree log4j 2 is currently the best choice. I was
>> impressed by slf4j a few years ago, but think now the step further is
>> log4j 2 (without any accurate reason, just a rough feeling).
>>
> 
> And in 2 years foolog4j will be better. JUL is not perfect for sure but
> ensures:
> - no dep
> - always usable
> - allows to let the user integrate with the lib without having to fork it
> to get rid of a logging dep - think to tomee which consumes N commons deps,
> if all uses a different logging framework it is worse to configure and
> highly inconsistent - that is why we chose jul by default
> 
> That is for the logging framework choice.
> Now commons shouldnt log much IMO otherwise it would start to loose commons
> in sense of shareable component cause of the integration issues it
> generates in the final application.

Big +1 to this. For the [math] case (and commons at whole), dependencies
should be avoided. In fact looking at log4j pom (even the core pom) one
can notice it depends on several commons components. This makes me think
more and more that commons components are the lowest possible level,
just above java itself.

So I think my message above was already out of scope. It may apply to
some applications, but not to commons.

thanks for reminding me about that, Romain!

best regards,
Luc

> 
> - Romain
> 
>> best regards,
>> Luc
>>
>>>
>>> Ralph
>>>
>>>
>>>> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe <l...@spaceroots.org> wrote:
>>>>
>>>> Le 26/09/2015 18:42, Gilles a écrit :
>>>>> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
>>>>>> On 9/26/15 4:56 AM, Thomas Neidhart wrote:
>>>>>>> On 09/26/2015 01:11 PM, Gilles wrote:
>>>>>>>> On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
>>>>>>>>> On 09/26/2015 02:33 AM, Gilles wrote:
>>>>>>>>>> On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
>>>>>>>>>>> On 25 September 2015 at 16:47, Gilles <
> gil...@harfang.homelinux.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Sep 25, 2015 at 5:09 PM, Gilles
>>>>>>>>>>>>> <gil...@harfang.homelinux.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:
>>>>>>>>>>>>>> On 9/25/15 7:03 AM, Gilles wrote:
>>>>>>>>>>>>>>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
>>>>>>>>>>>>>>>> Hi Ole,
>>>>>>>>>>>>>>>>> for a start, I think you are asking the wrong question.
>>>>>>>>>>>>>>>>> First of all we need to agree that we want to add some
> kind of
>>>>>>>>>>>>>>>>> logging
>>>>>>>>>>>>>>>>> facility to CM.
>>>>>>>>>>>>>>>>> If the outcome is positive, there are a handful of
>&

Re: [Math] Utilitzation of SLF4J?

[Luc Maisonobe]

Le 26/09/2015 20:59, Ralph Goers a écrit :
> I don’t normally participate in Math but I do feel the need to stick my nose 
> in here.
> 1. You are absolutely correct to determine whether you need logging at all 
> before discussing what to choose.
> 2. If you do decide logging is required:
>   a. Please stay away from java.util.logging. It really would be the best 
> solution for a framework like math except it is extremely difficult to 
> redirect efficiently to some other logging framework. The methods used by 
> SLF4J and Log4j are imperfect to say the least.
>   b. Log4j 1.x has reached eol. It effectively has not been supported for 5 
> years.
>   c. Log4j 2 has an API that can be redirected to another logging framework 
> if desired.
>   d. Commons logging still works but its API is very primitive by todays 
> standards. That said, it does work.

>From what I have seen, if I ever were to choose a logging framework for
any project, I agree log4j 2 is currently the best choice. I was
impressed by slf4j a few years ago, but think now the step further is
log4j 2 (without any accurate reason, just a rough feeling).

best regards,
Luc

> 
> Ralph
> 
> 
>> On Sep 26, 2015, at 10:07 AM, Luc Maisonobe <l...@spaceroots.org> wrote:
>>
>> Le 26/09/2015 18:42, Gilles a écrit :
>>> On Sat, 26 Sep 2015 09:03:06 -0700, Phil Steitz wrote:
>>>> On 9/26/15 4:56 AM, Thomas Neidhart wrote:
>>>>> On 09/26/2015 01:11 PM, Gilles wrote:
>>>>>> On Sat, 26 Sep 2015 09:53:30 +0200, Thomas Neidhart wrote:
>>>>>>> On 09/26/2015 02:33 AM, Gilles wrote:
>>>>>>>> On Fri, 25 Sep 2015 16:52:26 -0700, Hasan Diwan wrote:
>>>>>>>>> On 25 September 2015 at 16:47, Gilles <gil...@harfang.homelinux.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Fri, 25 Sep 2015 17:30:33 +0200, Thomas Neidhart wrote:
>>>>>>>>>>
>>>>>>>>>>> On Fri, Sep 25, 2015 at 5:09 PM, Gilles
>>>>>>>>>>> <gil...@harfang.homelinux.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote:
>>>>>>>>>>>> On 9/25/15 7:03 AM, Gilles wrote:
>>>>>>>>>>>>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote:
>>>>>>>>>>>>>> Hi Ole,
>>>>>>>>>>>>>>> for a start, I think you are asking the wrong question.
>>>>>>>>>>>>>>> First of all we need to agree that we want to add some kind of
>>>>>>>>>>>>>>> logging
>>>>>>>>>>>>>>> facility to CM.
>>>>>>>>>>>>>>> If the outcome is positive, there are a handful of
>>>>>>>>>>>>>>> alternatives,
>>>>>>>>>>>>>>> some of
>>>>>>>>>>>>>>> them more viable than slf4j in the context of CM (e.g. JUL or
>>>>>>>>>>>>>>> commons-logging).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Could someone summarize why those alternatives were deemed
>>>>>>>>>>>>>> "more
>>>>>>>>>>>>>> viable"?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> btw. the same discussion has been done for other commons
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> components as
>>>>>>>>>>>>>>> well, and the result usually was: do not add logging
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What was the rationale?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>> Look at the archives.  We have discussed this multiple times
>>>>>>>>>>>>> in the
>>>>>>>>>>>>> past in [math] and each time came to the con

Re: [Math] LeastSquaresOptimizer Design

[luc]

Le 2015-09-24 04:16, Ole Ersoy a écrit :

On 09/23/2015 03:09 PM, Luc Maisonobe wrote:
CM is not intended to be a design pattern people should mimic. We are 
so bad at this it would be a shame. No one in its right mind would 
copy or reuse this stuff. It is for internal use only and we don't 
even have the resources to manage it by ourselves so we can't consider 
it as a path people should follow as we are leading them. Here we 
would be leading them directly against the wall.


Hehe - I think that's like Michael Jordan saying - "Guys, don't try to
be like me.  I just play a little ball.  Dunk from the free throw
line.  Six world championships, but THATs it!".  In any case, I really
appreciate you and Gilles taking the time to talk.  Luc (And possibly
Gilles) - I can actually see why you are getting a bit annoyed,
because I'm ignoring something important.

I've been doing 90% NodeJS stuff lately (Which is event loop based and
relies callbacks) so I forgot one very important thing that I think
you have both tried to tell me.  The exception undoes the current
callstack / breaks the current program flow, bubbling up to the
handler.  Thts a good point.

OK - So scratch the callback thinking for synchronous code.  The
Lombok stuff should still be good though and hopefully some of the
callback discussion around and asynchronous option - I hope!  Geez.

What do you think about having one exception per class with an Enum
that encodes the various types of exceptional conditions that the
class can find itself in?  So in the case of
LevenbergMarquardtOptimizer there would be a:
- LevenbergMarquardtOptimizerException:
- LevenbergMarquardtOptimizerExceptionEnum

When the exception is thrown it sets the Enum indicating the root
cause.  The enum can then be used as a key to lookup the corresponding
message.

Any better?


Sure. I would suggest adding some parameters to help the upper level 
formatting
a meaningful message (say the number of iterations performed if you hit 
a max
iteration, so users become aware they should have set the limit higher). 
Nothing
over-engineered, a simple Object[] that can be used as last argument to 
something

like String.format() would be enough.

best regards,
Luc



Cheers,
- Ole


-
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: [Math] LeastSquaresOptimizer Design

[luc]

Hi Gilles,

Le 2015-09-23 23:00, Gilles a écrit :

[...]

CM is not intended to be a design pattern people should mimic.
We are so bad at this


The crux is that the project's team is in effect not _interested_
in this.  [And I admit that I had not understood it for a long
time (hence the temptation to convince that it was important for
*some* people).]


it would be a shame. No one in its right mind would copy
or reuse this stuff. It is for internal use only


Then why is it so difficult to change (cf. all the nit-picking
about backward-compatibility)?
As was (relatively) recently discussed, we could "mark" some code
"for internal use" and be free to break compatibility at any time,
for the sake of (an attempt at) a better design.


I think it would be nice. IMHO, we are overzealous on compatibility.
Sometimes, I try to introduce some changes that may break compatibility
early for some non user-implementable interfaces but have to withdraw
my proposal (tried it for ode, tried ot for BSP trees, think I tried it
for optimizers).




and we don't even have
the resources to manage it by ourselves


There are (maybe) other people (like Ole?) who would like to
experiment with new design ideas (not new math algorithms!)
but are repelled by the (overly) conservative development process
which is mainly feature-driven (like in a commercial project,
shall I dare to say).


Surely. But it is not specifically commercial vs open source I think.
I know commercial projects that break compatibility all the time 
(perhaps

to force users buying a new licence) and some that are stable. I know
open-source projects that break compatibility all the time (perhaps
because the team is highly dynamic or doesn't care about users) and
some that are stable.




so we can't consider it as a
path people should follow as we are leading them. Here we would be
leading them directly against the wall.


True, unfortunately.
There is really no long-term design. Even short term (quasi-)decisions
when they concern the library as a whole, are not followed by action
(cf. "fluent API")...


I still have fluent API in my TODO list and still really wants to make
it appear. The major blocking factor is available time (and sometimes
also despair about probable endless forthcoming discussions but it is
only second in the list).

best regards,
Luc




[...]


Best,
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