Jenkins build is back to normal : Commons-Compress #122

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

Jenkins build is back to normal : Commons-Compress » Apache Commons Compress #122

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

[compress] Update to Java 7?

Hi, I was looking at some compress code that I wanted to update to switch-on-string but realized the code is still on Java 6. OK to bump to Java 7? Gary -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition

Re: [MATH] MATH-1378: KMeansPlusPlusClusterer optimize seeding procedure.

Thanks, now then I've looked on it again, I think I can improve it more, since I currently at each iteration of the seed each points sampled with worst case complexity of O(n) (n is number of points) I think it's possible to reduce it to O(log(n)), while using O(n) of additional space. Best

Re: [math] Go back to the basics

On Thu, Jun 23, 2016 at 3:54 PM, Dimitri Pourbaix wrote: > > What about the actual users? What do they/we want? My first guess would > be that most of them simply do not want to have to reinvent the wheel +1

Re: DiskFileItem at Apache Commons FileUpload 1.3.2

On Thu, Jun 23, 2016 at 4:10 PM, Kensuke Matsuzaki wrote: > Hi, > > I tried commons-fileupload-1.3.2.jar, and same exploit works. > I agree with that binary compatible is important, but also `rm /etc/foo` is > important too. > Isn't it possible to disable serialization of

Re: [Math] Getting things done

Le 23/06/2016 à 19:20, Jörg Schaible a écrit : > Hmm. Here I got lost. Do you now try to keep the "unsupported" parts in CM4 > or leave them out as proposed two lines above? Well, that really depends on the usefulness of the parts considered. For example even if we have no developer expert in

Re: [Math] Getting things done

Hi Emmanuel, Emmanuel Bourg wrote: > Le 23/06/2016 à 14:33, Jochen Wiedmann a écrit : > >> The important part, to me, is to find something on which we can agree. >> That doesn't mean that everyone is happy with the outcome, but that >> everyone's got the feeling "I can live with that". In

Re: [Math] Getting things done

Hi Gilles, Gilles wrote: [snip] > Indeed, it will be much more productive to let the new(bie) team > experiment within Commons by creating the following new components: > * Commons RNG > * Commons AltMath > * Commons MathTools > > The first one, pretty much, was accepted. Amazing. Not

Re: [BCEL] Clirr report setting

On Thu, Jun 23, 2016 at 8:25 AM, sebb wrote: > I think we are all agreed that it's not a problem that the classes no > longer implement Serializable. > > I did a Clirr run with just the Serializable errors suppressed, and it > now looks quite reasonable[1]. > > I think it would

Re: [math] Go back to the basics

what "textbook?" ... why not model apache math after the GSL ... not all of it ... just the useful bits ??? supposedly, GSL is just Numerical Recipes. On Thu, Jun 23, 2016 at 6:54 AM, Dimitri Pourbaix wrote: > Hello, > > For the past 10 years, I have followed the

Re: [configuration] Please review pull request for CONFIGURATION-634

Hi, Raviteja Lokineni wrote: > Any commons-configuration developers around the place? Well, we're all volunteers, working in our spare time. So don't expect any real time reviews. This might take some days to be processed. - Jörg

Re: [configuration] Please review pull request for CONFIGURATION-634

Any commons-configuration developers around the place? On Jun 23, 2016 10:41 AM, "Raviteja Lokineni" wrote: > Hi, > > Sorry for bugging too much guys. > > Someone please review my pull request > https://github.com/apache/commons-configuration/pull/3 > > JIRA link:

Re: [Math] Getting things done

Hello. On Thu, 23 Jun 2016 14:33:05 +0200, Jochen Wiedmann wrote: Hi, I'd like an attempt to put an end to all those discussions regarding Commons Math (CM). That means, in particular, that we find an common agreement on a course of action. So, here's a suggestion (might as well call it an

[BCEL] Clirr report setting

I think we are all agreed that it's not a problem that the classes no longer implement Serializable. I did a Clirr run with just the Serializable errors suppressed, and it now looks quite reasonable[1]. I think it would make sense to release that as the Clirr report, and make sure that the

Re: [validator] Mastercard numbers should be 16, 17, 18, 19 digits long

Hi Sebb, On Wed, Jun 22, 2016 at 6:21 PM, sebb wrote: > On 22 June 2016 at 23:15, Bert Put wrote: > > Hello, > > > > Fist post, so please let me know if I have posted to the wrong place. > > Right place for initial contact. > - but we prefer people not to

[configuration] Please review pull request for CONFIGURATION-634

Hi, Sorry for bugging too much guys. Someone please review my pull request https://github.com/apache/commons-configuration/pull/3 JIRA link: https://issues.apache.org/jira/browse/CONFIGURATION-634 This issue is a blocker in my project and stops me from proceeding into the production. Thanks,

[math] Go back to the basics

Hello, For the past 10 years, I have followed the discussions about commons-math on the dev ML and I even contributed to the Levenberg-Marquardt code some years ago. Before I leave this ML because I am fed up, I would like to give my final 1 cent comment. What I have seen over these years are

Re: [Math] Getting things done

Thank you for the clarification. I like the idea of a commons-math base component, suiting the commons mission. If commons math were transmuted to a large scale new math project, that competes with Hipparchus. Both projects are forks of the same scope and at the same time. But in the Hipparchus

Re: [Math] Getting things done

+1 - Tell me how I can help. I like the idea that we contribute a (or some) component(s) back to commons, but I think it makes a lot of sense to just work towards community future state before concerning ourselves with code future state, as that will happen naturally over time. -Rob > On Jun

Re: [MATH] MATH-1378: KMeansPlusPlusClusterer optimize seeding procedure.

I use kmeans a bit and I will look at it. On Thu, Jun 23, 2016 at 2:10 PM, Artem Barger wrote: > Hi all, > > While I understand there is a project decision threads are going on ML, > however I'd like to suggest and provide some improvements of CM kmeans++ > implementation in

Re: [Math] Getting things done

Le 23/06/2016 à 14:33, Jochen Wiedmann a écrit : > The important part, to me, is to find something on which we can agree. > That doesn't mean that everyone is happy with the outcome, but that > everyone's got the feeling "I can live with that". In particular, > there must not be any serious

Re: [Math] Getting things done

I realize there are good intentions here. But what the common theme of all these email chains, when you filter out the disagreements, is, "deferred until" If 'deferring' is the only thing we can agree on, i think something is broken with the system. IMO let the doers do. Clearly Gilles is

Re: [Math] Getting things done

My answer would be slightly different. It doesn’t. All topics related to the code should be deferred until we know what is happening with the community. Ralph > On Jun 23, 2016, at 5:50 AM, Jochen Wiedmann > wrote: > > It doesn't, at least in my opinion. If the

Re: [Math] Getting things done

It doesn't, at least in my opinion. If the future Math project decides to have a "base" component: Very well. But, if the other components are elsewhere: Why should the base stay at Commons? On Thu, Jun 23, 2016 at 2:48 PM, Eric Barnhill wrote: > There has been a lot of

Re: [Math] Getting things done

There has been a lot of support in the discussions for, as Emmanuel put it, a "base commons-math component". Where does that factor into this proposal? On Thu, Jun 23, 2016 at 2:33 PM, Jochen Wiedmann wrote: > Hi, > > I'd like an attempt to put an end to all those

Re: [Math] Getting things done

+1 - Go for it! Ralph > On Jun 23, 2016, at 5:33 AM, Jochen Wiedmann > wrote: > > Hi, > > I'd like an attempt to put an end to all those discussions regarding > Commons Math (CM). That means, in particular, that we find an common > agreement on a course of action.

[Math] Getting things done

Hi, I'd like an attempt to put an end to all those discussions regarding Commons Math (CM). That means, in particular, that we find an common agreement on a course of action. So, here's a suggestion (might as well call it an offer, because acceptance would mean a lot of work on my side) 1.)

[MATH] MATH-1378: KMeansPlusPlusClusterer optimize seeding procedure.

Hi all, While I understand there is a project decision threads are going on ML, however I'd like to suggest and provide some improvements of CM kmeans++ implementation in the seeding procedure. Currently sum of squared distances computed each iteration during initial centers seeding, which is

Re: DiskFileItem at Apache Commons FileUpload 1.3.2

Hi, the reference for Apache Commons (in general) and FileUpload (in particular) is the Apache SVN repository, and not Github. Have a look at [1], which is the source code of FileItem for 1.3.2. This release is intended to be completely binary compatible to previous releases. As a consequence,

Re: [DISCUSS][VOTE] New component: Rational numbers

On Thu, 23 Jun 2016 08:53:22 +0200, Emmanuel Bourg wrote: Le 23/06/2016 à 01:36, Gilles a écrit : the only thing that was concretely accepted as "fine" is the fork of Commons Math outside Apache! I don't remember voting and accepting the fork, do you? I did not mention "voting". And

Re: [DISCUSS][VOTE] New component: Rational numbers

Le 23/06/2016 à 01:36, Gilles a écrit : > the only thing that > was concretely accepted as "fine" is the fork of Commons Math > outside Apache! I don't remember voting and accepting the fork, do you? The fork was not a decision from the Commons PMC. We had no other choice than acknowledging it,