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-math has an issue affecting its community integration.
This issue
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=13014&projectId=97
Build statistics:
State: Failed
Previous State: Ok
Started at: Fri 7 Oct 2011 06:23:57 +
Finished at: Fri 7 Oct 2011 06:24:23 +
Total time: 26s
Build Trigger: Schedule
Build Num
On Thu, Oct 6, 2011 at 9:13 PM, Phil Steitz wrote:
> Lets a) stop top-posting (Gilles has asked politely a couple of times now)
> and b) stay focused on solving the problems we actually have. We could
> endlessly debate refactoring approaches.
Sorry about the top posting, I am big culprit here
Lets a) stop top-posting (Gilles has asked politely a couple of times now) and
b) stay focused on solving the problems we actually have. We could endlessly
debate refactoring approaches. Or we could fix the stuff blocking 3.0 and get
a release out. Let's do that.
Phil
On Oct 6, 2011, at 6
Yeah... but this is a rough neighborhood for folk like you and me.
On Thu, Oct 6, 2011 at 5:52 PM, Greg Sterijevski wrote:
> If you really think about, all of the decomposition classes should be
> handled by factories. The decompositions all seem to occur in the
> constructor. Everything else is
If you really think about, all of the decomposition classes should be
handled by factories. The decompositions all seem to occur in the
constructor. Everything else is derived from those results, so one could
argue that the actual decomposition code could be written very procedurally
and put into t
On Thu, Oct 6, 2011 at 1:56 PM, Gilles Sadowski <
gil...@harfang.homelinux.org> wrote:
> On Thu, Oct 06, 2011 at 02:56:28PM -0500, Greg Sterijevski wrote:
> > Yes, this application would be similar to the ones you nixed. It would be
> a
> > factory returning an abstract class, with the appropriate
On Thu, Oct 06, 2011 at 02:56:28PM -0500, Greg Sterijevski wrote:
> Yes, this application would be similar to the ones you nixed. It would be a
> factory returning an abstract class, with the appropriate methods throwing
> exceptions (like getRank for the non-pivoting version-as Ted mentions in a
>
Hello.
> >In the code in the following classes
> > BaseMultiStartMultivariateRealOptimizer
> > BaseMultiStartMultivariateVectorialOptimizer
> >there is a
> > catch(RuntimeException e)
> >
> >This contradicts the statement (in "UnivariateRealFunction") stating that
> >user-defined exceptions a
My +1
Gary
On Mon, Oct 3, 2011 at 5:35 PM, Gary Gregory wrote:
> Good day to you all:
>
> I have prepared Commons IO 2.1-RC6.
>
> The differences with RC5 are:
>
> - build.xml: Pick up Sebb's fix for the JUnit download mess.
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/io/tags/c
Yes, this application would be similar to the ones you nixed. It would be a
factory returning an abstract class, with the appropriate methods throwing
exceptions (like getRank for the non-pivoting version-as Ted mentions in a
later entry in this blog).
As Ted asks, what is the issue with this?
On
Le 06/10/2011 17:24, Gilles Sadowski a écrit :
Hello.
In the code in the following classes
BaseMultiStartMultivariateRealOptimizer
BaseMultiStartMultivariateVectorialOptimizer
there is a
catch(RuntimeException e)
This contradicts the statement (in "UnivariateRealFunction") stating that
I've created a new bug: https://issues.apache.org/jira/browse/CHAIN-61 for
dealing with compiler warnings. I want to have chain build cleanly before I
work on the Context signature. I have just attached a patch for the compiler
warnings. I have annotated with @SuppressWarnings and @Deprecated where
Actually, you can easily get all the information at least in degenerate
form.
The two cases are:
- getPivot() ... the identity permutation can be returned
- getRank() ... it is reasonable to throw an exception stating that rank
is not available (UnsupportedOperationException, in particul
Why were these removed? Was it because the alternative implementations
weren't different enough?
On Thu, Oct 6, 2011 at 12:47 AM, Luc Maisonobe wrote:
> Le 06/10/2011 04:04, Sébastien Brisard a écrit :
>
>>
>>> What is the group's feeling on factory classes? +1 from me (obviously)
>>>
>>> +1 fo
Hello.
In the code in the following classes
BaseMultiStartMultivariateRealOptimizer
BaseMultiStartMultivariateVectorialOptimizer
there is a
catch(RuntimeException e)
This contradicts the statement (in "UnivariateRealFunction") stating that
user-defined exceptions are never caught by CM.
Re
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
Hello.
> >>
> >>What is the group's feeling on factory classes? +1 from me (obviously)
> >>
> >+1 for me, I like factories.
>
> -0. We used factories and removed most of them. In fact, what we
> removed was when factories are used to hide implementation and only
> an interface and a factory are a
Christian,
no objection from my side.
Thank you for taking care of it.
Maurizio Cucchiara
On 6 October 2011 10:24, Christian Grobmeier wrote:
> Hi,
>
> it seems the patches on the issue tracker are not straightforward to
> apply. As Simone suggested, I would like to commit the changes
> (basi
On Thu, Oct 6, 2011 at 11:08 AM, Simone Tripodi
wrote:
> +1
> can you kindly please include Daniel in the contributors list?
Yes, I will do that for sure.
Cheers
Christian
> TIA, all the best!
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Thu, Oct 6, 2
+1
can you kindly please include Daniel in the contributors list?
TIA, all the best!
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Thu, Oct 6, 2011 at 10:24 AM, Christian Grobmeier
wrote:
> Hi,
>
> it seems the patches on the issue tracker are not straightforward to
>
Hi,
it seems the patches on the issue tracker are not straightforward to
apply. As Simone suggested, I would like to commit the changes
(basically a combination of my own ideas, work of Daniel Pitts and
some inspiration from JEXL) to the trunk. Then everybody can review it
and - if necessary - rol
Le 06/10/2011 04:04, Sébastien Brisard a écrit :
What is the group's feeling on factory classes? +1 from me (obviously)
+1 for me, I like factories.
-0. We used factories and removed most of them. In fact, what we removed
was when factories are used to hide implementation and only an interf
23 matches
Mail list logo
