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-id has an issue affecting its community integration.
This issue af
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
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-configuration-test has an issue affecting its community
integrati
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-scxml-test has an issue affecting its community integration.
This
On Mar 14, 2012, at 10:14 AM, Emmanuel Bourg wrote:
> Le 14/03/2012 18:11, sebb a écrit :
>
>> Sometimes single char names are clearer.
>> E.g. in for loops, using i and j is such a common idiom that renaming
>> won't necessarily improve readability.
>
> Same thing for x and y as coordinates.
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-collections4-testframework has an issue affecting its community
i
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-digester3 has an issue affecting its community integration.
This i
There is another alternative, we might replace the records returned as a
String[] by a CSVRecord class able to access the fields by id or by
name. This would be similar to a JDBC resultset (except for the looping
logic)
This avoids the duplication of the parser, which might still be
generifie
Le 15/03/2012 00:32, sebb a écrit :
I don't see why, so long as you fetch the values once at the start.
I tried that and the parser was slower. Don't ask me why.
There's a theoretical problem with using a valid char value as a
disabled indicator, at least with the parser as it stands.
It as
On 14 March 2012 22:54, Emmanuel Bourg wrote:
> Le 14/03/2012 23:35, sebb a écrit :
>
>
>> It's not too late to change to using Character.
>
>
> The issue is the parser, this will probably degrade the performance. Unless
> the fields are made package private and accessed directly by the parser.
I
Le 14/03/2012 23:35, sebb a écrit :
It's not too late to change to using Character.
The issue is the parser, this will probably degrade the performance.
Unless the fields are made package private and accessed directly by the
parser.
It's not possible currently to create a format with enc
On 14 March 2012 21:56, Emmanuel Bourg wrote:
> Le 14/03/2012 22:44, sebb a écrit :
>
>
>> It's not possible to use null for a char value.
>
>
> It assumed we changed the signature of the methods with java.lang.Character,
> while retaining the primitive internally. But that's not possible due to t
Le 14/03/2012 22:44, sebb a écrit :
It's not possible to use null for a char value.
It assumed we changed the signature of the methods with
java.lang.Character, while retaining the primitive internally. But
that's not possible due to the getters.
If possible I'd like to not expose this con
On 14 March 2012 21:40, Benedikt Ritter wrote:
> Am 14. März 2012 22:33 schrieb Emmanuel Bourg :
>> Le 14/03/2012 22:25, Benedikt Ritter a écrit :
>>
>>
>>> I agree with you on this. However, I think it would be better to tie
>>> validation to the object creation. Maybe the Builder Pattern like
>>
On 14 March 2012 21:41, Emmanuel Bourg wrote:
> Le 14/03/2012 22:16, sebb a écrit :
>
>
>> In which case, reversing the order would work.
>> We would just have to document this as a restriction.
>
>
> Too much burden on the user.
>
>
>
>> The problem with leaving the validation until later is that
Le 14/03/2012 22:16, sebb a écrit :
In which case, reversing the order would work.
We would just have to document this as a restriction.
Too much burden on the user.
The problem with leaving the validation until later is that it
decouples the cause and effect.
This makes it a bit harder to
On 14 March 2012 21:25, Benedikt Ritter wrote:
> Am 14. März 2012 22:16 schrieb sebb :
>> On 14 March 2012 21:02, Emmanuel Bourg wrote:
>>> Le 14/03/2012 21:52, Benedikt Ritter a écrit :
>>>
>>>
the subject of this mail is pretty self-explanatory. Why do we need a
package private valida
Am 14. März 2012 22:33 schrieb Emmanuel Bourg :
> Le 14/03/2012 22:25, Benedikt Ritter a écrit :
>
>
>> I agree with you on this. However, I think it would be better to tie
>> validation to the object creation. Maybe the Builder Pattern like
>> shown in Effective Java p. 14-15 is a reasonable solut
Le 14/03/2012 22:25, Benedikt Ritter a écrit :
I agree with you on this. However, I think it would be better to tie
validation to the object creation. Maybe the Builder Pattern like
shown in Effective Java p. 14-15 is a reasonable solution for this
case? It would be a bit more verbose, but we ca
Le 14/03/2012 22:15, Benedikt Ritter a écrit :
okay, I understand. But doesn't that make things worse? Users can
create invalid formats, but they can not call validate(), because it
is package private.
Worse? There was no validation originally, users could do any kind of
absurd things.
I do
Am 14. März 2012 22:16 schrieb sebb :
> On 14 March 2012 21:02, Emmanuel Bourg wrote:
>> Le 14/03/2012 21:52, Benedikt Ritter a écrit :
>>
>>
>>> the subject of this mail is pretty self-explanatory. Why do we need a
>>> package private validate() method, given the fact, that users can not
>>> crea
On 14 March 2012 21:02, Emmanuel Bourg wrote:
> Le 14/03/2012 21:52, Benedikt Ritter a écrit :
>
>
>> the subject of this mail is pretty self-explanatory. Why do we need a
>> package private validate() method, given the fact, that users can not
>> create custom instances (constructor is package pr
Am 14. März 2012 22:02 schrieb Emmanuel Bourg :
> Le 14/03/2012 21:52, Benedikt Ritter a écrit :
>
>
>> the subject of this mail is pretty self-explanatory. Why do we need a
>> package private validate() method, given the fact, that users can not
>> create custom instances (constructor is package p
Le 14/03/2012 21:52, Benedikt Ritter a écrit :
the subject of this mail is pretty self-explanatory. Why do we need a
package private validate() method, given the fact, that users can not
create custom instances (constructor is package private)? You could
even argue, that no validation is needed
Hey,
the subject of this mail is pretty self-explanatory. Why do we need a
package private validate() method, given the fact, that users can not
create custom instances (constructor is package private)? You could
even argue, that no validation is needed at all, since we are in
control of what form
Am 14. März 2012 20:48 schrieb :
> Author: sebb
> Date: Wed Mar 14 19:48:12 2012
> New Revision: 1300699
>
> URL: http://svn.apache.org/viewvc?rev=1300699&view=rev
> Log:
> Javadoc
>
> Modified:
>
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
>
> Modified:
> c
Am 14. März 2012 20:33 schrieb Benedikt Ritter :
> Am 14. März 2012 18:43 schrieb :
>> Author: sebb
>> Date: Wed Mar 14 17:43:35 2012
>> New Revision: 1300661
>>
>> URL: http://svn.apache.org/viewvc?rev=1300661&view=rev
>> Log:
>> CSV-60 CSVParser.iterator().remove() should throw throw new
>> Uns
Am 14. März 2012 18:43 schrieb :
> Author: sebb
> Date: Wed Mar 14 17:43:35 2012
> New Revision: 1300661
>
> URL: http://svn.apache.org/viewvc?rev=1300661&view=rev
> Log:
> CSV-60 CSVParser.iterator().remove() should throw throw new
> UnsupportedOperationException()
>
is it reasonable to add a u
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=20121&projectId=68
Build statistics:
State: Failed
Previous State: Ok
Started at: Wed 14 Mar 2012 18:20:15 +
Finished at: Wed 14 Mar 2012 18:20:39 +
Total time: 23s
Build Trigger: Schedule
Build N
On 14 March 2012 17:42, wrote:
> Author: ebourg
> Date: Wed Mar 14 17:42:28 2012
> New Revision: 1300659
>
> URL: http://svn.apache.org/viewvc?rev=1300659&view=rev
> Log:
> Replaced CharBuffer with StringBuilder (CSV-59)
>
> Removed:
>
> commons/proper/csv/trunk/src/main/java/org/apache/commo
Except in nested loops: Which integer is being incremented, the inner
loop or outer loop? If the outer loop used outer instead of i, and the
inner loop used inner instead of j, then the loop being incremented is
obvious.
Idioms make sense as long as they're *your* idioms. To others it's
confu
Le 14/03/2012 18:11, sebb a écrit :
Sometimes single char names are clearer.
E.g. in for loops, using i and j is such a common idiom that renaming
won't necessarily improve readability.
Same thing for x and y as coordinates.
Emmanuel Bourg
smime.p7s
Description: S/MIME Cryptographic Signat
On 14 March 2012 16:39, Adrian Crum wrote:
> Personally, I despise single character parameters/variable names. Seriously,
> is it that much work to type a few extra characters and make the name
> meaningful?
Sometimes single char names are clearer.
E.g. in for loops, using i and j is such a commo
On 13 March 2012 11:48, sebb wrote:
> Commons Parent 24 includes the following reports:
>
> Javadoc
> Jxr
> Surefire
> RAT
> Cobertura
> Clirr
> JDepend
>
> I think the following should be added:
>
> Changes/JIRA
Done.
> The following could be added:
>
> Findbugs
> Checkstyle
>
> Any others?
Th
On 14 March 2012 16:27, Honton, Charles wrote:
> As a user of commons libraries, I look at several reports. I'll consult
> Javadoc first. In the case the javadoc is silent about behavior, I look at
> JXR.
+1, JXR has been very useful to me.
> When I am debugging my code's interaction with th
Personally, I despise single character parameters/variable names.
Seriously, is it that much work to type a few extra characters and make
the name meaningful?
-Adrian
On 3/14/2012 1:33 PM, sebb wrote:
I noticed that some of the CSV methods uses "int l" (ell).
This is unfortunately very simila
Why should the developer site be any different than the release site?
-Original Message-
From: Gilles Sadowski [mailto:gil...@harfang.homelinux.org]
Sent: Wednesday, March 14, 2012 2:18 AM
To: dev@commons.apache.org
Subject: Re: [ALL] Commons Parent reports
On Tue, Mar 13, 2012 at 06:37:
As a user of commons libraries, I look at several reports. I'll consult
Javadoc first. In the case the javadoc is silent about behavior, I look at
JXR. When I am debugging my code's interaction with the commons library, I
want to have the sources available to my IDE, so that I can step throug
On Wed, Mar 14, 2012 at 10:27 AM, sebb wrote:
> On 14 March 2012 14:00, Gary Gregory wrote:
> > On Wed, Mar 14, 2012 at 9:33 AM, sebb wrote:
> >
> >> I noticed that some of the CSV methods uses "int l" (ell).
> >> This is unfortunately very similar to 1 (one) in many fonts.
> >>
> >> ExtendedBu
On 14 March 2012 14:00, Gary Gregory wrote:
> On Wed, Mar 14, 2012 at 9:33 AM, sebb wrote:
>
>> I noticed that some of the CSV methods uses "int l" (ell).
>> This is unfortunately very similar to 1 (one) in many fonts.
>>
>> ExtendedBufferedReader.read(...) and UnicodeUnescapeReader.read(...)
>>
Le 14/03/2012 13:45, sebb a écrit :
What if the sequence is not exactly 5 characters long?
Nothing because it never happens :)
Emmanuel Bourg
smime.p7s
Description: S/MIME Cryptographic Signature
On Wed, Mar 14, 2012 at 9:33 AM, sebb wrote:
> I noticed that some of the CSV methods uses "int l" (ell).
> This is unfortunately very similar to 1 (one) in many fonts.
>
> ExtendedBufferedReader.read(...) and UnicodeUnescapeReader.read(...)
> both do this.
>
> Now that would perhaps be a good ca
On 14 March 2012 12:01, wrote:
> Author: ebourg
> Date: Wed Mar 14 12:01:47 2012
> New Revision: 1300516
>
> URL: http://svn.apache.org/viewvc?rev=1300516&view=rev
> Log:
> Improved test coverage
>
> Modified:
>
> commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/UnicodeUnescapeRe
On Tue, Mar 13, 2012 at 4:33 AM, Ralph Goers wrote:
>> I don't think we should be trying to recode JDK classes.
>
> If the implementations suck, why not?
+1
--
http://www.grobmeier.de
https://www.timeandbill.de
-
To unsubscri
On Tue, Mar 13, 2012 at 06:37:21PM +0100, Emmanuel Bourg wrote:
> Le 13/03/2012 17:52, Gilles Sadowski a écrit :
>
> >What about the "Useful for the developer" category?
>
> They are useful at release time only, then they become quickly
> outdated as the code evolves after the release.
>
> If I
On Tue, Mar 13, 2012 at 01:59:25PM -0400, Gary Gregory wrote:
> On Mar 13, 2012, at 12:40, Gilles Sadowski
> wrote:
>
> > Hi.
> >
> >>>
> > [...]
> >
> > The tools are there, but you have to tell people that they _must_ use
> > them.
>
> Commons has already enough rule
On Tue, Mar 13, 2012 at 01:52:32PM -0400, Gary Gregory wrote:
> On Mar 13, 2012, at 12:40, Gilles Sadowski
> wrote:
>
> >>>
> > [...]
> >
> > The tools are there, but you have to tell people that they _must_ use
> > them.
>
> Commons has already enough rules and proces
After more experiments I'm less enthusiastic about providing an
optimized BufferedReader. The result of the performance test is
significantly different if the test is run alone or after all the other
unit tests (about 30% slower). When all the tests are executed, the
removal of the synchronized
48 matches
Mail list logo
