OK Phil,
I'm just worried about naming consistency. So should I drop Linear
everywhere? Only in exception names (where I agree, it's not that
important)?
Thanks,
Sébastien
2011/10/2 Phil Steitz phil.ste...@gmail.com:
On 10/1/11 9:42 PM, Sébastien Brisard wrote:
My mistake! I was convinced 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
Right. I tend to like self-describing names also good. In french
(you've rightly spotted a non-native speaker...), an operator is not
necessarily linear, and I think same goes to english terminology
(could you confirm please). So a linear operator is not exactly
identical to an operator.
However,
Hi Sébastien.[1]
On Sun, Oct 02, 2011 at 01:34:50PM +0200, Sébastien Brisard wrote:
Right. I tend to like self-describing names also good. In french
(you've rightly spotted a non-native speaker...), an operator is not
necessarily linear, and I think same goes to english terminology
(could you
2011/10/2 Gilles Sadowski gil...@harfang.homelinux.org:
Hi Sébastien.[1]
Hi Gilles,
took me some time to figure out what your [1] meant, but I think I got
it (or did I?)... I'm a bit on the slow side.
+1 also because it is the standard style in Java (for better or worse).
As I've pointed out
Hello.
took me some time to figure out what your [1] meant, but I think I got
it (or did I?)... I'm a bit on the slow side.
The first time I saw this quote, it also took me a lot of time to understand
what they were talking about. Indeed, the mere fact of having a hard time
understanding it
On 10/2/11 7:38 AM, Gilles Sadowski wrote:
Hello.
took me some time to figure out what your [1] meant, but I think I got
it (or did I?)... I'm a bit on the slow side.
The first time I saw this quote, it also took me a lot of time to understand
what they were talking about. Indeed, the mere
These classes are not used anywhere else in [math] and I am not sure
it is the best separation of concerns between [math] and client apps
to provide this stuff. If we want to keep them, the generic
parameterization should be fixed. I propose that we drop them from
3.0. Any objections to this?
Le 02/10/2011 18:14, Phil Steitz a écrit :
These classes are not used anywhere else in [math] and I am not sure
it is the best separation of concerns between [math] and client apps
to provide this stuff. If we want to keep them, the generic
parameterization should be fixed. I propose that we
These classes are not used anywhere else in [math] and I am not sure
it is the best separation of concerns between [math] and client apps
to provide this stuff. If we want to keep them, the generic
parameterization should be fixed. I propose that we drop them from
3.0. Any objections to
These classes are not used anywhere else in [math] and I am not sure
it is the best separation of concerns between [math] and client apps
to provide this stuff. If we want to keep them, the generic
parameterization should be fixed. I propose that we drop them from
3.0. Any objections to
2011/10/2 Phil Steitz phil.ste...@gmail.com:
On 10/2/11 7:38 AM, Gilles Sadowski wrote:
Hello.
took me some time to figure out what your [1] meant, but I think I got
it (or did I?)... I'm a bit on the slow side.
The first time I saw this quote, it also took me a lot of time to understand
This vote is canceled.
Ant build refers to JUnit 3.x.
I'll fix that and see if I can reproduce the tailer fail.
Thank you,
Gary
On Sat, Oct 1, 2011 at 8:57 AM, sebb seb...@gmail.com wrote:
On 1 October 2011 12:54, Jörg Schaible joerg.schai...@gmx.de wrote:
Hi Hen,
Henri Yandell wrote:
On 10/2/11 12:43 PM, l...@apache.org wrote:
==
---
commons/proper/math/trunk/src/main/java/org/apache/commons/math/ode/AbstractIntegrator.java
(original)
+++
Good day to you all:
I have prepared Commons IO 2.1-RC5.
The differences with RC4 are:
- TailerTest: Make the test sleep longer while the Tailer works.
- Use includeantruntime=false in build.xml
- Update build.xml to JUnit 4.10 from 3.8.1
- Update POM to JUnit 4.10 from 4.9
- Remove superfluous
On 2 October 2011 19:57, ggreg...@apache.org wrote:
Author: ggregory
Date: Sun Oct 2 18:57:51 2011
New Revision: 1178220
URL: http://svn.apache.org/viewvc?rev=1178220view=rev
Log:
Update to JUnit 4.10 from 3.8.1. Use includeantruntime=false for repeatable
builds.
Modified:
I've finally got a little time to work on Chain again. Anyways, I have
logged this bug in Jira (https://issues.apache.org/jira/browse/CHAIN-60) and
uploaded a patch to fix it. In the future, I think it would it would be
helpful in unit test were randomized on each execution in order to prevent
17 matches
Mail list logo
