OK, I'm happy to do it.
Sébastien
2011/9/5 Gilles Sadowski gil...@harfang.homelinux.org:
Hi Sébastien.
Gilles,
if you're going to do that soon, I'll stop removing methods
solve(double[]) from DecompositionSolvers (I've only done Cholesky so
far), so that our modifications do not conflict.
Hi,
as agreed in this ticket, references to double[] solve(double[]) have
been wiped out from all decomposition solvers.
The same thing should probably be done with solve(double[][]), but
Gilles suggested we should probably wait and see what is going to
happen to the RealMatrix interface (creating
2011/9/5 Phil Steitz phil.ste...@gmail.com:
I have a couple of proposals for this class:
0) Merge the interface and impl. This is consistent with what we
are doing in some other places where we have only one implementation.
Fine with me.
1) Extend this class to actually provide a
As shown in this exemple the exception is really something local to
user code and there is a guarantee [math] will not mess with it. The
user is safe.
I would like to finish implementing this for ODE (i.e. simply commit
what I have already done), and to extend it to the rest of [math],
completely
Hi Niall,
thanks for the hint!
Anyway (DISCLAIMER: I'm putting in the original chain author's shoes,
so I couldn't say the truth) I immagine that users would be interested
on having, as a Context, not just a place where storing computed
element to be shared between chain commands, but having also
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 Sep 5, 2011, at 23:35, sebb seb...@gmail.com wrote:
On 6 September 2011 04:26, Gary Gregory ggreg...@seagullsoftware.com wrote:
Can the clirr version be inherited from the parent pom?
Tried that just now.
Has to be defined in reporting section.
That works fine, except it does not
On Sep 5, 2011, at 23:34, Henri Yandell flame...@gmail.com wrote:
On Sat, Sep 3, 2011 at 8:10 AM, sebb seb...@gmail.com wrote:
On 3 September 2011 05:37, Henri Yandell flame...@gmail.com wrote:
I'm less concerned with the 115 errors, unless they're all as grievous
as the StringUtils one - ie)
Not sure it went through the first time...
Le 6 septembre 2011 08:33, Sébastien Brisard
sebastien.bris...@m4x.org a écrit :
Hi,
as agreed in this ticket, references to double[] solve(double[]) have
been wiped out from all decomposition solvers.
The same thing should probably be done with
Hello.
as agreed in this ticket, references to double[] solve(double[]) have
been wiped out from all decomposition solvers.
That's done already but might have been the object of another JIRA ticket,
as the changes did not depend on RealVector.
The same thing should probably be done with
On 9/6/11 12:00 AM, Mikkel Meyer Andersen wrote:
2011/9/5 Phil Steitz phil.ste...@gmail.com:
I have a couple of proposals for this class:
0) Merge the interface and impl. This is consistent with what we
are doing in some other places where we have only one implementation.
Fine with me.
1)
On 6 September 2011 05:44, David Karlsen davidkarl...@gmail.com wrote:
I think tying to sun classes is a bad idea.
Yes, which is why the code checks to see if the class is present.
If the Java 6 method is available, then it uses that, otherwise it
checks for the Sun method.
If neither is
On 6 September 2011 13:46, ggreg...@apache.org wrote:
Author: ggregory
Date: Tue Sep 6 12:46:39 2011
New Revision: 1165645
URL: http://svn.apache.org/viewvc?rev=1165645view=rev
Log:
Changes for [parent] 22-SNAPSHOT.
Modified:
commons/proper/lang/trunk/src/test/resources/java.policy
We use in XStream a dynamic approach:
http://svn.codehaus.org/xstream/trunk/xstream/src/test/com/thoughtworks/xstream/testutil/DynamicSecurityManager.java
http://svn.codehaus.org/xstream/trunk/xstream/src/test/com/thoughtworks/acceptance/SecurityManagerTest.java
sebb wrote:
On 6 September 2011
I added the file ComplexOctaveTest.java to JIRA MATH-620.
What really will happen, if Inf and NaN values com up I dont know at
this point - the complex signal path is in its infancy at the moment ...
(I currently have no need for that)
Arne
Make the sun class be loaded dynamically -- not statically -- and if
it is not present, just throw an UnsupportedOperationException? I
think that would solve Android's problem.
On Tue, Sep 6, 2011 at 8:36 AM, sebb seb...@gmail.com wrote:
On 6 September 2011 05:44, David Karlsen
As a user of chain in a number of projects over the years, I've found
that the combination of extending Map and defining your own getter /
setter properties on the context to be ideal. With your own getters
and setters, you get better code completion and you have a more
old-fashioned entity
I'm working on a fix now. Have a look when it is committed to see if
it can be improved.
On 6 September 2011 15:48, Paul Benedict pbened...@apache.org wrote:
Make the sun class be loaded dynamically -- not statically -- and if
it is not present, just throw an UnsupportedOperationException? I
On Tue, Sep 6, 2011 at 9:48 AM, sebb seb...@gmail.com wrote:
On 6 September 2011 13:46, ggreg...@apache.org wrote:
Author: ggregory
Date: Tue Sep 6 12:46:39 2011
New Revision: 1165645
URL: http://svn.apache.org/viewvc?rev=1165645view=rev
Log:
Changes for [parent] 22-SNAPSHOT.
On 6 September 2011 15:44, Gary Gregory garydgreg...@gmail.com wrote:
On Tue, Sep 6, 2011 at 9:48 AM, sebb seb...@gmail.com wrote:
On 6 September 2011 13:46, ggreg...@apache.org wrote:
Author: ggregory
Date: Tue Sep 6 12:46:39 2011
New Revision: 1165645
URL:
I doubt there is a policy, but practically speaking it helps a lot if JIRA's
don't live forever. They should express an issue and that should get fixed
and the JIRA closed. The scope of work shouldn't be extended to cover
additional work.
Tasks under blanket JIRA's might help.
2011/9/6
2011/9/6 Phil Steitz phil.ste...@gmail.com:
On 9/6/11 12:00 AM, Mikkel Meyer Andersen wrote:
2011/9/5 Phil Steitz phil.ste...@gmail.com:
I have a couple of proposals for this class:
0) Merge the interface and impl. This is consistent with what we
are doing in some other places where we
@since 3.0? Should this be 2.0? :) Same for previous commit to this...
Matt
On Mon, Sep 5, 2011 at 2:07 PM, simonetrip...@apache.org wrote:
Author: simonetripodi
Date: Mon Sep 5 19:07:51 2011
New Revision: 1165395
URL: http://svn.apache.org/viewvc?rev=1165395view=rev
Log:
added
I am an idiot and I don't have to commit while watching TV :)
Thanks for notifying, going to fix it now!
All the best,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Tue, Sep 6, 2011 at 6:01 PM, Matt Benson gudnabr...@gmail.com wrote:
@since 3.0? Should this be 2.0?
On Tue, Sep 6, 2011 at 11:14 AM, sebb seb...@gmail.com wrote:
On 6 September 2011 15:44, Gary Gregory garydgreg...@gmail.com wrote:
On Tue, Sep 6, 2011 at 9:48 AM, sebb seb...@gmail.com wrote:
On 6 September 2011 13:46, ggreg...@apache.org wrote:
Author: ggregory
Date: Tue Sep 6
On 6 September 2011 17:16, Gary Gregory garydgreg...@gmail.com wrote:
On Tue, Sep 6, 2011 at 11:14 AM, sebb seb...@gmail.com wrote:
On 6 September 2011 15:44, Gary Gregory garydgreg...@gmail.com wrote:
On Tue, Sep 6, 2011 at 9:48 AM, sebb seb...@gmail.com wrote:
On 6 September 2011 13:46,
Here is the current set up:
- To run tests: Same as before: mvn test
- To runt tests with the Java security manager: comment out some XML in the
POM and run mvn integration-test
The policy file does for Sufire+JUnit 4 what Surefire does by itself for
JUnit 3: It grants Surefire and JUnit just
Le 06/09/2011 14:29, Gilles Sadowski a écrit :
Hello.
Hi,
as agreed in this ticket, references to double[] solve(double[]) have
been wiped out from all decomposition solvers.
That's done already but might have been the object of another JIRA ticket,
as the changes did not depend on
[...]
Also, when
opening a new ticket, should it be assigned to someone, if this person
agrees to take care of it?
If you are willing to fix some issue, you should probably assign it to
yourself. That would help prevent duplicate work.
As far as I know, it's this other way round. When
Am 06.09.2011 04:40, schrieb sebb:
On 5 September 2011 21:20, sebbseb...@gmail.com wrote:
On 5 September 2011 19:19, Oliver Hegeroliver.he...@oliver-heger.de wrote:
Am 05.09.2011 15:52, schrieb sebb:
On 5 September 2011 10:42, Oliver Hegeroliver.he...@oliver-heger.de
wrote:
Am
On 6 September 2011 17:55, Gary Gregory garydgreg...@gmail.com wrote:
Here is the current set up:
- To run tests: Same as before: mvn test
- To runt tests with the Java security manager: comment out some XML in the
POM and run mvn integration-test
The policy file does for Sufire+JUnit 4
On 6 September 2011 19:47, Oliver Heger oliver.he...@oliver-heger.de wrote:
Am 06.09.2011 04:40, schrieb sebb:
On 5 September 2011 21:20, sebbseb...@gmail.com wrote:
On 5 September 2011 19:19, Oliver Hegeroliver.he...@oliver-heger.de
wrote:
Am 05.09.2011 15:52, schrieb sebb:
On 5
On Tue, Sep 6, 2011 at 4:53 PM, sebb seb...@gmail.com wrote:
On 6 September 2011 17:55, Gary Gregory garydgreg...@gmail.com wrote:
Here is the current set up:
- To run tests: Same as before: mvn test
- To runt tests with the Java security manager: comment out some XML in
the
POM and
Hello.
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
URL:
http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java?rev=1165846r1=1165845r2=1165846view=diff
On 7 September 2011 00:04, Gilles Sadowski gil...@harfang.homelinux.org wrote:
Hello.
Modified:
commons/proper/math/trunk/src/main/java/org/apache/commons/math/util/FastMath.java
URL:
Hi,
please let me know what you think of the modified code I've attached
to MATH-655. I took Phil's into account (composition vs. inheritance).
I believe the provided classes would go into o.a.c.m.util.
Thanks beforehand for your comments,
Sébastien
Hi,
as noted in MATH-653, these two methods are redundant, and one should
go. Pros and cons are
* toArray() is fairly classical in the Java world
* but getData() is consistent with ArrayRealVector.getDataRef().
Personnaly, my preference goes to keeping toArray(). In order to
maintain consistency,
Hi All:
It feels like it's about time to vote on releasing version 22?
Thoughts?
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://s.apache.org/rl
Spring Batch in Action: http://s.apache.org/HOq
Blog: http://garygregory.wordpress.com
Home:
Why is the idea plugin defined? IntelliJ hasn't needed it in a long time.
Ralph
On Sep 6, 2011, at 7:23 PM, Gary Gregory wrote:
Hi All:
It feels like it's about time to vote on releasing version 22?
Thoughts?
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action,
On Wed, Sep 7, 2011 at 12:22 AM, Ralph Goers ralph.go...@dslextreme.comwrote:
Why is the idea plugin defined? IntelliJ hasn't needed it in a long time.
Good question.
Should we get rid of it?
The warning at the start of all commons build is annoying.
Gary
Ralph
On Sep 6, 2011, at
40 matches
Mail list logo
