On 06/18/2014 10:53 PM, Gary Gregory wrote:
> On Wed, Jun 18, 2014 at 4:51 PM, Thomas Neidhart
> wrote:
>
>> On 06/18/2014 09:54 PM, ggreg...@apache.org wrote:
>>> Author: ggregory
>>> Date: Wed Jun 18 19:54:52 2014
>>> New Revision: 1603607
>>>
>>> URL: http://svn.apache.org/r1603607
>>> Log:
>>
On Wed, Jun 18, 2014 at 4:51 PM, Thomas Neidhart
wrote:
> On 06/18/2014 09:54 PM, ggreg...@apache.org wrote:
> > Author: ggregory
> > Date: Wed Jun 18 19:54:52 2014
> > New Revision: 1603607
> >
> > URL: http://svn.apache.org/r1603607
> > Log:
> > [CODEC-187] Beider Morse Phonetic Matching produc
On 06/18/2014 09:54 PM, ggreg...@apache.org wrote:
> Author: ggregory
> Date: Wed Jun 18 19:54:52 2014
> New Revision: 1603607
>
> URL: http://svn.apache.org/r1603607
> Log:
> [CODEC-187] Beider Morse Phonetic Matching producing incorrect tokens.
>
> Modified:
> commons/proper/codec/trunk/NOT
Le 18/06/2014 20:28, venkatesha m a écrit :
> Hi Luc, Gilles
Hi Venkat
>
> First of, Iam immensly thankful to all your comments on this patch.
> Next, i am attaching my new patch with today's date(18-jun). However
> please advise if i need to remove the old patch file if it confuses.
OK, I'll r
Lombok depends on a particular compiler, etc. Commons [weaver] provides a
foundation for recreating anything that lombok does, AFAIK.
Matt
On Wed, Jun 18, 2014 at 2:40 PM, venkatesha m wrote:
> Hi,
>
> I would like to understand if there are any concerns regarding introducing
> annotation libr
Hi,
I would like to understand if there are any concerns regarding introducing
annotation libraries such as lombok(http://projectlombok.org/) to commons-math .
The most advantages i have seen using it are as follows:
a) A majority of code drudge such as equals, hashcode, getter and setter can be
Online report :
https://continuum-ci.apache.org/continuum/buildResult.action?buildId=32663&projectId=70
Build statistics:
State: Failed
Previous State: Ok
Started at: Wed 18 Jun 2014 19:20:12 +
Finished at: Wed 18 Jun 2014 19:21:05 +
Total time: 53s
Build Trigger: Schedule
B
Hi Luc, Gilles
First of, Iam immensly thankful to all your comments on this patch. Next, i am
attaching my new patch with today's date(18-jun). However please advise if i
need to remove the old patch file if it confuses.
Please find my response below. The new patch has the suggested changes in
On Wed, 18 Jun 2014 16:39:12 +0200, Luc Maisonobe wrote:
Hi Gilles and Venkat,
Le 18/06/2014 15:40, Gilles a écrit :
On Wed, 18 Jun 2014 15:02:41 +0200, Luc Maisonobe wrote:
Le 18/06/2014 14:32, Gilles a écrit :
Hello Luc.
See
https://issues.apache.org/jira/browse/MATH-1129
The problem
Hi Gilles and Venkat,
Le 18/06/2014 15:40, Gilles a écrit :
> On Wed, 18 Jun 2014 15:02:41 +0200, Luc Maisonobe wrote:
>> Le 18/06/2014 14:32, Gilles a écrit :
>>> Hello Luc.
>>>
>
> See
> https://issues.apache.org/jira/browse/MATH-1129
>
> The problem reported was due to the
On Wed, 18 Jun 2014 15:02:41 +0200, Luc Maisonobe wrote:
Le 18/06/2014 14:32, Gilles a écrit :
Hello Luc.
See
https://issues.apache.org/jira/browse/MATH-1129
The problem reported was due to the sorting procedure not behaving
correctly in the presence of NaN.
This procedure could be replace
Le 18/06/2014 14:32, Gilles a écrit :
> Hello Luc.
>
>>>
>>> See
>>> https://issues.apache.org/jira/browse/MATH-1129
>>>
>>> The problem reported was due to the sorting procedure not behaving
>>> correctly in the presence of NaN.
>>> This procedure could be replaced by an equivalent method from
Hello Luc.
See
https://issues.apache.org/jira/browse/MATH-1129
The problem reported was due to the sorting procedure not behaving
correctly in the presence of NaN.
This procedure could be replaced by an equivalent method from the
JDK:
java.util.Arrays.sort(double[],int,int)
Any objectio
Le 18/06/2014 13:37, Gilles a écrit :
> Hi.
Hi Gilles,
>
> See
> https://issues.apache.org/jira/browse/MATH-1129
>
> The problem reported was due to the sorting procedure not behaving
> correctly in the presence of NaN.
> This procedure could be replaced by an equivalent method from the JDK:
Hi.
See
https://issues.apache.org/jira/browse/MATH-1129
The problem reported was due to the sorting procedure not behaving
correctly in the presence of NaN.
This procedure could be replaced by an equivalent method from the JDK:
java.util.Arrays.sort(double[],int,int)
Any objection?
Regard
15 matches
Mail list logo