Thanks to everyone for this interesting discussion.
I've attached a new file to the MATH-581 JIRA ticket, including your comments
(I hope).
Hope this will get integrated into Commons-Math !
Sebastien
-
To unsubscribe, e-mail: dev-
Hi All
Following the advice from the previous failed vote, I've rolled another RC
for Commons Validator 1.4 beta 1. As per advice, this one was generated
using Maven[1] rather than Ant. Just for a reminder, the idea of this
release is to get some wider testing of the codebase, owing to the 4.5
Hi Marko,
Marko Klopcic wrote:
> Hi,
>
> It is probably a bit late, but it is only these days I've checked
> javadoc of the commons-lang ver. 3 on the web, and found contexted
> exceptions. I found the context info useful already some time ago, so
> I've implemented my own classes, which you can
As your measurements indicate, the allocation of large objects is rarely a
speed issue. It can be a memory fragmentation issue, but a full GC will fix
that as well.
People who are stressed about allocation of result vectors such as what you
are doing are mostly worried about the wrong thing.
201
Le 08/07/2011 13:06, Gilles Sadowski a écrit :
Hi Luc.
Reminded of this issue by your last post: I think that the default format
should be the scientific notation. Currently, only 2 digits are printed
after the decimal point which entails the loss of all information when the
number is "close" to
Le 08/07/2011 12:28, Sébastien Brisard a écrit :
I would go to the natural type we get when building the exception. If we may
build the exception from both types, then I would select RealVector. We do
not intend to perform large processing on elements, but we want to display
them and I think we
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
On Fri, Jul 08, 2011 at 12:28:23PM +0200, Sébastien Brisard wrote:
> >
> > I would go to the natural type we get when building the exception. If we may
> > build the exception from both types, then I would select RealVector. We do
> > not intend to perform large processing on elements, but we want
Hi Luc.
Reminded of this issue by your last post: I think that the default format
should be the scientific notation. Currently, only 2 digits are printed
after the decimal point which entails the loss of all information when the
number is "close" to zero.
I remember absurd messsages such as (recal
>
> I would go to the natural type we get when building the exception. If we
may
> build the exception from both types, then I would select RealVector. We do
> not intend to perform large processing on elements, but we want to display
> them and I think we do have formatting for vectors.
>
> best r
>
> I would go to the natural type we get when building the exception. If we may
> build the exception from both types, then I would select RealVector. We do
> not intend to perform large processing on elements, but we want to display
> them and I think we do have formatting for vectors.
>
> best r
The Apache Commons Daemon team is pleased to announce the
commons-daemon-1.0.6 release!
Version 1.0.6 is both a bug fix and feature update release.
Source and binary distributions are available for download
from the Apache Commons download site:
http://commons.apache.org/daemon/download_daemon.c
Le 08/07/2011 08:44, Sebastien Brisard a écrit :
Hi everyone,
well the message below did not raise much of an interest... My apology, I
forgot to quote [math] in the title.
Sorry, I forgot to reply in a timely fashion.
Anyway, I have a new proposal regarding this issue. I do not know what you
On Fri, Jul 08, 2011 at 08:44:15AM +0200, Sebastien Brisard wrote:
> Hi everyone,
> well the message below did not raise much of an interest... My apology, I
> forgot to quote [math] in the title.
> Anyway, I have a new proposal regarding this issue. I do not know what your
> view on the subject is
Hi all again folks,
+1 I think we can resolve all items in the status page,
we just need a release then IMHO we're ready to submit our graduation
proposal by the next board report :)
I don't know if it could be the quickest, but of course one of the quicker ;)
Have a nice day, all the best!
Simo
On Fri, Jul 08, 2011 at 05:06:38AM +0200, Sebastien Brisard wrote:
> Ted,
> Mahout seems to be fairly large (!). What classes should I look at more
> specifically?
If not done already, you could also have a look at class
o.a.c.m.analysis.FunctionUtils
(in CM).
Gilles
-
Well done Simone!!
On 8 July 2011 09:02, Simone Tripodi wrote:
> Hi all guys,
> please review and add/modify what is missing: Mentors can copy & sign
> once agreed it is the version we agree.
> TIA, have a nice day!!!
> Simo
>
> OGNL
>
> Apache OGNL is a Java development framework for Object-Gra
> http://incubator.apache.org/projects/ognl.html
>
> In fact, I think we can resolve every item there. At which point I'd
> argue we can be graduated by the next board report :)
+1
Was it the quickest incubation ever then? :-)
-
On Fri, Jul 8, 2011 at 12:02 AM, Simone Tripodi
wrote:
> Community activity decreased since codebase has been imported &
> polished; we finally reached Luc Blanchard, the other OGNL original
> author, that signed & submitted the OGNL SoftwareGrant & ICLA - we
> also voted him as a new committer s
Sorry, side effect of C'n'P:
OGNL
Apache OGNL is a Java development framework for Object-Graph
Navigation Language, plus other extras such as list projection and
selection and lambda expressions.
The project joined the Incubator on April 26, 2011.
* A list of the three most important issues t
Hi all guys,
please review and add/modify what is missing: Mentors can copy & sign
once agreed it is the version we agree.
TIA, have a nice day!!!
Simo
OGNL
Apache OGNL is a Java development framework for Object-Graph
Navigation Language, plus other extras such as list projection and
selection an
21 matches
Mail list logo
