Done in rev r1178306.
Best regards,
Sébastien
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
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
this
On 2 October 2011 19:57, wrote:
> Author: ggregory
> Date: Sun Oct 2 18:57:51 2011
> New Revision: 1178220
>
> URL: http://svn.apache.org/viewvc?rev=1178220&view=rev
> Log:
> Update to JUnit 4.10 from 3.8.1. Use includeantruntime="false" for repeatable
> builds.
>
> Modified:
> commons/prope
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 superfluou
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)
> +++
> commons/proper/math/trunk/src/main/java/org/ap
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 wrote:
> On 1 October 2011 12:54, Jörg Schaible wrote:
> > Hi Hen,
> >
> > Henri Yandell wrote:
> >
> >> -1.
> >>
> >> I got th
2011/10/2 Phil Steitz :
> 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
> 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 t
> >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 objecti
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 dr
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?
P
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
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 i
2011/10/2 Gilles Sadowski :
> 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 somewhere else[2], to
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
> (coul
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,
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 Sat, Oct 1, 2011 at 10:58 PM, Phil Steitz wrote:
> > As for shortening the name, I'm all for it. For consistency, I would
> > do it for every class matching the pattern *LinearOperator* if you all
> > agree. Also, I think that "linear" is as important as "operator" in
> > "LinearOperator" (eve
18 matches
Mail list logo
