[GUMP@vmgump]: Project commons-proxy-test (in module apache-commons) failed

To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-proxy-test has an issue affecting its community integration. This

[GUMP@vmgump]: Project commons-email (in module apache-commons) failed

To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-email has an issue affecting its community integration. This issue

Re: [DISCUSS][POOL] Logging options for Pool2

I have a preference fo juli. IIRC, Tomcat has a bridge from juli to logging impl, it would help to keep [pool] dependencies-less. -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Feb 9, 2012 at

[continuum] BUILD FAILURE: Apache Commons - Commons Pool - Default Maven 2 Build Definition (Java 1.5)

Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=18572&projectId=98 Build statistics: State: Failed Previous State: Ok Started at: Thu 9 Feb 2012 23:44:36 + Finished at: Thu 9 Feb 2012 23:49:06 + Total time: 4m 30s Build Trigger: Schedule Build

[DISCUSS][POOL] Logging options for Pool2

One of the big design decisions left for pool2 is whether or not to add logging. If logging is added then that opens up the what to log and with which logging framework questions. I do think some form of logging is required. See POOL-131 for one example of where logging could be useful. I have a

Re: [math] Are all FieldElement Numbers?

Hi Sebastien, Am Donnerstag 09 Februar 2012, 11:18:43 schrieb Sébastien Brisard: > > I am slightly reluctant to change FieldElement to an abstract class. > > What do other people think about this ? > > Luc it would have been better to let Number only be an interface and not an abstract class. N

Re: [math] Merge of interface and implementation of *Test classes in stat.inference

Hi. > [...] > What do you think? No idea. > @Exceptions: while working on the migration to the new exceptions in > this package, I tried to stick to the rules from Phil/Luc: > > - add @throws clause to javadoc > - add throws declaration to method signature > > for each individual exception t

Re: [math] moving resources folder

Hello. > >> > >> Some times ago, we had a discussion about some issues with Android > >> devices. One issue was that the packaging system for Android did remove > >> some folders we put inside META-INF. The folder we put there was > >> localization. > >> > >> I would like to mode this folder from

[continuum] BUILD FAILURE: Apache Commons - Commons VFS - Default Maven 2 Build Definition (Java 1.5)

Online report : http://vmbuild.apache.org/continuum/buildResult.action?buildId=18565&projectId=129 Build statistics: State: Failed Previous State: Ok Started at: Thu 9 Feb 2012 20:42:58 + Finished at: Thu 9 Feb 2012 20:46:19 + Total time: 3m 20s Build Trigger: Schedule Build

Re: Hi everybody

Hi Felix and Leandro, helping hands are very much welcome! Cheers + good luck! Christian On Thu, Feb 9, 2012 at 8:00 PM, wrote: > Hi There Felix ! > > Welcome to the dev zone ! . I am rather new here myself. > > Looking forward to your contributions too ! > > Bye ! > > Leandro. > > On miércol

Re: Hi everybody

Hi There Felix ! Welcome to the dev zone ! . I am rather new here myself. Looking forward to your contributions too ! Bye ! Leandro. On miércoles, 08 de febrero de 2012 at 7:30 PM, Simone Tripodi wrote:Hi Felix, welcome in the brotherhood and yes, that's the way to go :) Looking forward to

Re: [math] Merge of interface and implementation of *Test classes in stat.inference

> On Fri, Feb 03, 2012 at 08:33:44PM +0100, Thomas Neidhart wrote: >> Hi, >> >> I have been working on the exceptions in the stat.inference package and >> have seen that all classes in this package follow the same scheme: >> >> - Interface for a statistical test >> - Implementation of this single

[Commons Wiki] Update of "UsingSVN" by sebbapache

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The "UsingSVN" page has been changed by sebbapache: http://wiki.apache.org/commons/UsingSVN?action=diff&rev1=22&rev2=23 Comment: Refer to canonical SVN settings list * Windows: C:\

Re: [math] moving resources folder

I think its a great idea. so i give a +1 to it. Leandro. On jueves, 09 de febrero de 2012 at 1:12 PM, Luc Maisonobe wrote:Hi, Some times ago, we had a discussion about some issues with Android devices. One issue was that the packaging system for Android did remove some folders we put inside MET

Re: [math] moving resources folder

On 9 February 2012 17:22, Luc Maisonobe wrote: > Le 09/02/2012 17:33, Gilles Sadowski a écrit : >> On Thu, Feb 09, 2012 at 05:13:14PM +0100, Luc Maisonobe wrote: >>> Hi, >>> >>> Some times ago, we had a discussion about some issues with Android >>> devices. One issue was that the packaging system

Re: svn commit: r1242237 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter: DefaultMeasurementModel.java DefaultProcessModel.java KalmanFilter.java MeasurementModel.java Pro

2012/2/9 sebb : > On 9 February 2012 16:01, Thomas Neidhart wrote: >> On 02/09/2012 03:46 PM, sebb wrote: >> >>> Both Id and Revision are fine, and can both be useful. >>> >>> There's no harm in having the keywords set - it's only a problem if >>> they are *used*. >>> But having them set might enc

Re: [math] moving resources folder

Le 09/02/2012 17:33, Gilles Sadowski a écrit : > On Thu, Feb 09, 2012 at 05:13:14PM +0100, Luc Maisonobe wrote: >> Hi, >> >> Some times ago, we had a discussion about some issues with Android >> devices. One issue was that the packaging system for Android did remove >> some folders we put inside ME

Re: [math] moving resources folder

On 9 February 2012 16:13, Luc Maisonobe wrote: > Hi, > > Some times ago, we had a discussion about some issues with Android > devices. One issue was that the packaging system for Android did remove > some folders we put inside META-INF. The folder we put there was > localization. > > I would like

Re: [math] moving resources folder

On Thu, Feb 09, 2012 at 05:13:14PM +0100, Luc Maisonobe wrote: > Hi, > > Some times ago, we had a discussion about some issues with Android > devices. One issue was that the packaging system for Android did remove > some folders we put inside META-INF. The folder we put there was > localization. >

Re: svn commit: r1242237 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter: DefaultMeasurementModel.java DefaultProcessModel.java KalmanFilter.java MeasurementModel.java Pro

On 9 February 2012 16:01, Thomas Neidhart wrote: > On 02/09/2012 03:46 PM, sebb wrote: > >> Both Id and Revision are fine, and can both be useful. >> >> There's no harm in having the keywords set - it's only a problem if >> they are *used*. >> But having them set might encourage their use. > > Ok,

[Commons Wiki] Update of "UsingSVN" by sebbapache

Dear Wiki user, You have subscribed to a wiki page or wiki category on "Commons Wiki" for change notification. The "UsingSVN" page has been changed by sebbapache: http://wiki.apache.org/commons/UsingSVN?action=diff&rev1=21&rev2=22 Comment: exec enable-auto-props = yes [auto-props] - *.c

[math] moving resources folder

Hi, Some times ago, we had a discussion about some issues with Android devices. One issue was that the packaging system for Android did remove some folders we put inside META-INF. The folder we put there was localization. I would like to mode this folder from META-INF/localization to a new assets

Re: svn commit: r1242237 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter: DefaultMeasurementModel.java DefaultProcessModel.java KalmanFilter.java MeasurementModel.java Pro

On 02/09/2012 03:46 PM, sebb wrote: > Both Id and Revision are fine, and can both be useful. > > There's no harm in having the keywords set - it's only a problem if > they are *used*. > But having them set might encourage their use. Ok, makes sense to not set the other keywords just in case. Btw

Re: svn commit: r1242237 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter: DefaultMeasurementModel.java DefaultProcessModel.java KalmanFilter.java MeasurementModel.java Pro

Hi, Le 09/02/2012 16:00, Gilles Sadowski a écrit : > On Thu, Feb 09, 2012 at 02:46:26PM +, sebb wrote: >> 2012/2/9 Sébastien Brisard : >>> 2012/2/9 sebb : 2012/2/9 Sébastien Brisard : > Hi, > >> >>svn:keywords = Id >> >> Propchange: >> commons/proper/math/

Re: svn commit: r1242237 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter: DefaultMeasurementModel.java DefaultProcessModel.java KalmanFilter.java MeasurementModel.java Pro

On 9 February 2012 15:00, Gilles Sadowski wrote: > On Thu, Feb 09, 2012 at 02:46:26PM +, sebb wrote: >> 2012/2/9 Sébastien Brisard : >> > 2012/2/9 sebb : >> >> 2012/2/9 Sébastien Brisard : >> >>> Hi, >> >>> >> >>    svn:keywords = Id >> >> Propchange: >> commons/prope

Re: svn commit: r1242237 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter: DefaultMeasurementModel.java DefaultProcessModel.java KalmanFilter.java MeasurementModel.java Pro

> > I think that we decided to stick with $Id$ only since it also contains the > revision number. > > Regards, > Gilles > OK, I do apologize for that. I'll keep it in mind in the future. Sébastien - To unsubscribe, e-mail: dev-un

Re: svn commit: r1242237 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter: DefaultMeasurementModel.java DefaultProcessModel.java KalmanFilter.java MeasurementModel.java Pro

On Thu, Feb 09, 2012 at 02:46:26PM +, sebb wrote: > 2012/2/9 Sébastien Brisard : > > 2012/2/9 sebb : > >> 2012/2/9 Sébastien Brisard : > >>> Hi, > >>> > >    svn:keywords = Id > > Propchange: > commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter/Defa

Re: svn commit: r1242237 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter: DefaultMeasurementModel.java DefaultProcessModel.java KalmanFilter.java MeasurementModel.java Pro

2012/2/9 Sébastien Brisard : > 2012/2/9 sebb : >> 2012/2/9 Sébastien Brisard : >>> Hi, >>>    svn:keywords = Id Propchange: commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter/DefaultProcessModel.java

Re: svn commit: r1242237 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter: DefaultMeasurementModel.java DefaultProcessModel.java KalmanFilter.java MeasurementModel.java Pro

2012/2/9 sebb : > 2012/2/9 Sébastien Brisard : >> Hi, >> >>> >>>    svn:keywords = Id >>> >>> Propchange: >>> commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter/DefaultProcessModel.java >>> -- >>>    sv

[GUMP@vmgump]: Project commons-exec-test (in module apache-commons) failed

To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project commons-exec-test has an issue affecting its community integration. This i

Re: [math] Are all FieldElement Numbers?

On 9 February 2012 10:02, Luc Maisonobe wrote: > Le 09/02/2012 10:15, Sébastien Brisard a écrit : >> Hi, > > Hi Sébastien, > >> I'm doing some calculations with FieldElement, and need at the end to >> convert the result to double. I notice that in the current CM, all >> classes that implement Fiel

Re: svn commit: r1242237 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter: DefaultMeasurementModel.java DefaultProcessModel.java KalmanFilter.java MeasurementModel.java Pro

2012/2/9 Sébastien Brisard : > Hi, > >> >>    svn:keywords = Id >> >> Propchange: >> commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter/DefaultProcessModel.java >> -- >>    svn:keywords = Id >> >> Propc

Re: [all] migration to svnpubsub

On 9 February 2012 11:37, Simone Tripodi wrote: > Hi Luc, > > just take it as a personal experience I want to share: publishing mvn > generated site on ASF svn is not painless, I already experienced it on > Apache Any23 and IMHO using the wagon-svn via maven is a suicide, > because it tries to com

Re: [math] Are all FieldElement Numbers?

On Thu, Feb 09, 2012 at 11:02:05AM +0100, Luc Maisonobe wrote: > Le 09/02/2012 10:15, Sébastien Brisard a écrit : > > Hi, > > Hi Sébastien, > > > I'm doing some calculations with FieldElement, and need at the end to > > convert the result to double. I notice that in the current CM, all > > classe

Re: [math] Package transform revisited

On Thu, Feb 09, 2012 at 11:02:36AM +0100, Luc Maisonobe wrote: > Le 09/02/2012 10:50, Sébastien Brisard a écrit : > > Hi Luc, > >> > >> I agree with you, enums are much better. There are other places in > >> [math] where we use boolean or even ints for such things. They mainly > >> came for pre-jav

Re: [all] migration to svnpubsub

Hi Luc, just take it as a personal experience I want to share: publishing mvn generated site on ASF svn is not painless, I already experienced it on Apache Any23 and IMHO using the wagon-svn via maven is a suicide, because it tries to commit the file one by one :S. The only more effective "turnar

Re: [all] migration to svnpubsub

Hi, we have a JIRA ticket with a proposal for a new Layout designed by Simo: https://issues.apache.org/jira/browse/COMMONSSITE-65 Regards, Benedikt - Original Message - From: luc.maison...@free.fr To: dev@commons.apache.org Date: 09.02.2012 11:12:30 Subject: [all] migration to svnpubsub

Re: [math] Are all FieldElement Numbers?

Hi Luc, > > Yes, all FieldElement are expected to be numbers, or at least there is > an homomorphism mapping the elements to numbers. However, FieldElement > cannot implement Number because number is a class, not an interface. If > we want to have this hierarchy, we also have to change FieldElement

[all] migration to svnpubsub

Hi all, Apache infrastructure policy mandates using svnpubsub to publish project websites by the end of 2012 (see ). At the same time, a Content Management System has been set up that does abide to this policy (see

Re: [VOTE] Release Daemon 1.0.9 based on RC1

On 07/02/2012 12:52, Mladen Turk wrote: > Hi, > > Version 1.0.9 is bug fix release. > > Daemon 1.0.9 RC1 is available for review at: > http://people.apache.org/~mturk/daemon-1.0.9/ > It is based on the svn tag > https://svn.apache.org/repos/asf/commons/proper/daemon/tags/COMMONS_DAEMON_1_0_9_RC1

Re: [math] Package transform revisited

Le 09/02/2012 10:50, Sébastien Brisard a écrit : > Hi Luc, >> >> I agree with you, enums are much better. There are other places in >> [math] where we use boolean or even ints for such things. They mainly >> came for pre-java 5 era when enums where not available. >> >> Luc >> > And what do you thin

Re: [math] Are all FieldElement Numbers?

Le 09/02/2012 10:15, Sébastien Brisard a écrit : > Hi, Hi Sébastien, > I'm doing some calculations with FieldElement, and need at the end to > convert the result to double. I notice that in the current CM, all > classes that implement FieldElement also implement Number, which would > be exactly w

Re: [math] Package transform revisited

Hi Luc, > > I agree with you, enums are much better. There are other places in > [math] where we use boolean or even ints for such things. They mainly > came for pre-java 5 era when enums where not available. > > Luc > And what do you think of replacing - transform(double[]) with transform(double[]

Re: [math] Package transform revisited

Le 09/02/2012 08:46, Sébastien Brisard a écrit : > Hi, > while working on MATH-732, I've made some amendments to the > FastFourierTransformer API. Basically, I've removed the factory > methods create() and createUnitary() I had previously introduced in > MATH-677. Instead, I introduced an enum {STA

[math] Are all FieldElement Numbers?

Hi, I'm doing some calculations with FieldElement, and need at the end to convert the result to double. I notice that in the current CM, all classes that implement FieldElement also implement Number, which would be exactly what I need. My question therefore is * Should we have the interface FieldEl

Re: svn commit: r1242237 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter: DefaultMeasurementModel.java DefaultProcessModel.java KalmanFilter.java MeasurementModel.java Pro

On 02/09/2012 09:52 AM, Sébastien Brisard wrote: > Hi, > I think the property should read > Author Date Id Revision Ok thanks, I have fixed it. My default config lists them, but I had to add them manually. Thomas - To unsubscri

Re: svn commit: r1242237 - in /commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter: DefaultMeasurementModel.java DefaultProcessModel.java KalmanFilter.java MeasurementModel.java Pro

Hi, > >    svn:keywords = Id > > Propchange: > commons/proper/math/trunk/src/main/java/org/apache/commons/math/filter/DefaultProcessModel.java > -- >    svn:keywords = Id > > Propchange: > commons/proper/math/trunk/src/m