Feathercast on Apache Commons

Our own Gary Gregory being interviewed by Feathercast.org: http://feathercast.org/?p=97 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [sandbox] new sandbox component

On Wed, Feb 2, 2011 at 10:35 PM, Luc Maisonobe wrote: > Hi all, > > -Original Message- > From: luc.maison...@free.fr [mailto:luc.maison...@free.fr] > Sent: Monday, January 31, 2011 11:23 > To: Commons Developers List > Subject: [sandbox] new sandbox

Re: [sandbox] new sandbox component

Hi all, -Original Message- From: luc.maison...@free.fr [mailto:luc.maison...@free.fr] Sent: Monday, January 31, 2011 11:23 To: Commons Developers List Subject: [sandbox] new sandbox component Hi all, I have a

Re: svn commit: r1066668 - /commons/trunks-sandbox/

Le 02/02/2011 23:31, nia...@apache.org a écrit : > Author: niallp > Date: Wed Feb 2 22:31:33 2011 > New Revision: 108 > > URL: http://svn.apache.org/viewvc?rev=108&view=rev > Log: > Add bsp to trunks-sandbox Thanks Niall :-) I was writing a mail to ask what I should do for trunk-sandbox

Re: [pool] potential new method for interface ObjectPool

Hi Zoly, nice to meet you and thanks for your collaboration! Sorry to say that honestly I didn't understand where the optimization is - please take in consideration I woke up at 6am and at 10pm I'm still working, ehehe :P So I would appreciate if you can provide more details about your thoughts so

Re: [pool] potential new method for interface ObjectPool

Done: https://issues.apache.org/jira/browse/POOL-183 - Original Message From: Phil Steitz To: Commons Developers List Sent: Wed, February 2, 2011 2:18:52 PM Subject: Re: [pool] potential new method for interface ObjectPool On 2/2/11 1:46 PM, zoly farkas wrote: > Would it be possibl

Re: [pool] potential new method for interface ObjectPool

On 2/2/11 1:46 PM, zoly farkas wrote: > Would it be possible to add a method: > > void returnAndValidateObject(T obj) throws Exception > > In general I was thinking of the following use case: > > Object o = pool.borrowObject(); > try > { > . > o.doStuff(); > . > pool

[pool] potential new method for interface ObjectPool

Would it be possible to add a method: void returnAndValidateObject(T obj) throws Exception In general I was thinking of the following use case: Object o = pool.borrowObject(); try {     .     o.doStuff();     .     pool.returnObject(o); } catch(Exception e) {     // not sure what

RE: [all][math] Help wanted with exceptions API design

> -Original Message- > From: jodastep...@gmail.com [mailto:jodastep...@gmail.com] On Behalf Of > Stephen Colebourne > Sent: Wednesday, February 02, 2011 03:57 > To: Commons Developers List > Subject: Re: [all][math] Help wanted with exceptions API design > > On 2 February 2011 00:12, Gille

Re: [all][math] Help wanted with exceptions API design

Hi Gilles, Gilles Sadowski wrote: > Hello. > >> > [...] >> > >> > Do I understand correctly that, if we go down that road, there would >> > only be a single exception (every failure will raise the same >> > exception)? >> >> No, not at all, but your exceptions would provide all the same mechan

Re: [math] deciding about 2.2

Hello. > > It seems the thread asking for help on the exception API design is going > to be fruitful, and it starts well with interesting ideas. I guess some > of these ideas will change again our view and we will converge > (hopefully not throwing an exception ourselves ...) to a stable design >

Re: [all][math] Help wanted with exceptions API design

On Wed, Feb 02, 2011 at 09:41:12AM +0100, Luc Maisonobe wrote: > Le 02/02/2011 08:53, Gary Gregory a écrit : > > Why are the messages not externalized in a properties file? > > They are externalized in a properties file: > > They enum Phil pointed out here: >http://s.apa

Re: [all][math] Help wanted with exceptions API design

On Wed, Feb 02, 2011 at 07:53:00AM +, Gary Gregory wrote: > Why are the messages not externalized in a properties file? The translations are (currently, only French is available). Having the default messages inside a class (using the "constructor" feature for enums) is perhaps more efficient

Re: [all][math] Help wanted with exceptions API design

Hi. > My new approach to coding. Say what you see. Expressed with other words, but that's indeed what I'm suggesting for CM. > a) is IllegalArgEx (JDK) or a subclass. > b) is CalculationException or a subclass if there is truly valuable info to > add > c) some other random RuntimeException Al

Re: [all][math] Help wanted with exceptions API design

On Wed, Feb 02, 2011 at 08:57:10AM +, Stephen Colebourne wrote: > On 2 February 2011 00:12, Gilles Sadowski > wrote: > >> Here is a probably too simple example: > >> > >> com.example defines IOException > >> com.example.input uses IOException > >> com.example.output uses IOException > > > > W

Re: [all][math] Help wanted with exceptions API design

Hello. > > [...] > > > > Do I understand correctly that, if we go down that road, there would only > > be a single exception (every failure will raise the same exception)? > > No, not at all, but your exceptions would provide all the same mechanism to > add valuable information up the stack. Ha

[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

Re: [all][math] Help wanted with exceptions API design

On Tue, Feb 01, 2011 at 10:40:47PM -0800, Stephen Williams wrote: > On 2/1/11 10:04 PM, Phil Steitz wrote: > >... > >Agreed. This is why we had a very flat hierarchy through version > >2.0 of [math]. Where we are having trouble gaining consensus is how > >to represent specializing context informa

Re: [all][math] Help wanted with exceptions API design

Hi. > [...] > > Trap for retry errors should be rare if present at all. I would much > > prefer to see a proper result object which everyone is forced to check > > to describe the success or failure of something that might be retried. > "Retry" is not in general meaningful for our stuff, though in

Re: [all][math] Help wanted with exceptions API design

Hi. > >I know I've recently seen a great example of a library that > >started with generic exception classes then later changed to a > >specific hierarchy. But I can't remember off hand which library > >it was... > > > >There is some low level where you just want to get back the raw > >exception,

[GUMP@vmgump]: Project commons-scxml-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-scxml-test has an issue affecting its community integration. This

Re: [math] deciding about 2.2 (was Re: [all][math] Help wanted with exceptions API design)

On 2 February 2011 09:23, Luc Maisonobe wrote: > It seems the thread asking for help on the exception API design is going > to be fruitful, and it starts well with interesting ideas. I guess some > of these ideas will change again our view and we will converge > (hopefully not throwing an exceptio

Re: svn commit: r1066176 - /commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/StepFunctionTest.java

On 2 February 2011 09:25, Gilles Sadowski wrote: > On Wed, Feb 02, 2011 at 01:07:28AM +, sebb wrote: >> On 2 February 2011 00:24, Gilles Sadowski >> wrote: >> > Hi. >> > >> >> Tidy up test >> > >> > Hmm. Not convinced. >> > Factorizing that way all the CM unit tests is a lot of work for a du

Re: svn commit: r1066299 - /commons/proper/math/trunk/src/test/java/org/apache/commons/math/linear/RealVectorFormatAbstractTest.java

Hi. > Author: sebb > Date: Wed Feb 2 01:37:49 2011 > New Revision: 1066299 > > URL: http://svn.apache.org/viewvc?rev=1066299&view=rev > Log: > No point catching and then calling fail - just let JUnit do the work > > Modified: > > commons/proper/math/trunk/src/test/java/org/apache/commons/m

Re: svn commit: r1066176 - /commons/proper/math/trunk/src/test/java/org/apache/commons/math/analysis/function/StepFunctionTest.java

On Wed, Feb 02, 2011 at 01:07:28AM +, sebb wrote: > On 2 February 2011 00:24, Gilles Sadowski > wrote: > > Hi. > > > >> Tidy up test > > > > Hmm. Not convinced. > > Factorizing that way all the CM unit tests is a lot of work for a dubious > > (IMO) improvement in readability. > > I'm not sug

[math] deciding about 2.2 (was Re: [all][math] Help wanted with exceptions API design)

Le 02/02/2011 05:54, Phil Steitz a écrit : > On 2/1/11 2:06 PM, Luc Maisonobe wrote: >> Le 01/02/2011 18:22, Jörg Schaible a écrit : >>> Hi, >>> >>> Phil Steitz wrote: >>> We are in process of redesigning our exceptions hierarchy in [math] and we could use some input / perspective from ot

Re: [all][math] Help wanted with exceptions API design

On 2 February 2011 06:04, Phil Steitz wrote: > What we report back to the application using [math] is that one of > the following kinds of bad things has happened > > a) they have violated preconditions - they get > MathIllegalArgumentException (same semantics as anywhere else) > b) they have not

Re: [all][math] Help wanted with exceptions API design

On 2 February 2011 00:12, Gilles Sadowski wrote: >> Here is a probably too simple example: >> >> com.example defines IOException >> com.example.input uses IOException >> com.example.output uses IOException > > Well, I don't see that as obviously better than storing all exceptions in an > "exceptio

Re: [all][math] Help wanted with exceptions API design

Le 02/02/2011 08:53, Gary Gregory a écrit : > Why are the messages not externalized in a properties file? They are externalized in a properties file: They enum Phil pointed out here: >http://s.apache.org/NNd> defines a default English message in case a message is not tra