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
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-id has an issue affecting its community integration.
This issue
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-vfs2-test has an issue affecting its community integration.
This
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
On Tue, Mar 13, 2012 at 01:52:32PM -0400, Gary Gregory wrote:
On Mar 13, 2012, at 12:40, Gilles Sadowski gil...@harfang.homelinux.org
wrote:
[...]
The tools are there, but you have to tell people that they _must_ use
them.
Commons has already enough rules and process. As long
On Tue, Mar 13, 2012 at 01:59:25PM -0400, Gary Gregory wrote:
On Mar 13, 2012, at 12:40, Gilles Sadowski gil...@harfang.homelinux.org
wrote:
Hi.
[...]
The tools are there, but you have to tell people that they _must_ use
them.
Commons has already enough rules and process.
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 want to
On Tue, Mar 13, 2012 at 4:33 AM, Ralph Goers ralph.go...@dslextreme.com 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
On 14 March 2012 12:01, ebo...@apache.org wrote:
Author: ebourg
Date: Wed Mar 14 12:01:47 2012
New Revision: 1300516
URL: http://svn.apache.org/viewvc?rev=1300516view=rev
Log:
Improved test coverage
Modified:
On Wed, Mar 14, 2012 at 9:33 AM, sebb seb...@gmail.com 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
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 14 March 2012 14:00, Gary Gregory garydgreg...@gmail.com wrote:
On Wed, Mar 14, 2012 at 9:33 AM, sebb seb...@gmail.com 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
On Wed, Mar 14, 2012 at 10:27 AM, sebb seb...@gmail.com wrote:
On 14 March 2012 14:00, Gary Gregory garydgreg...@gmail.com wrote:
On Wed, Mar 14, 2012 at 9:33 AM, sebb seb...@gmail.com wrote:
I noticed that some of the CSV methods uses int l (ell).
This is unfortunately very similar to 1
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
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
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 similar
On 14 March 2012 16:27, Honton, Charles charles_hon...@intuit.com 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
On 13 March 2012 11:48, sebb seb...@gmail.com 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?
On 14 March 2012 16:39, Adrian Crum adrian.c...@sandglass-software.com 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
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
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
On 14 March 2012 17:42, ebo...@apache.org wrote:
Author: ebourg
Date: Wed Mar 14 17:42:28 2012
New Revision: 1300659
URL: http://svn.apache.org/viewvc?rev=1300659view=rev
Log:
Replaced CharBuffer with StringBuilder (CSV-59)
Removed:
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=20121projectId=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
Am 14. März 2012 18:43 schrieb s...@apache.org:
Author: sebb
Date: Wed Mar 14 17:43:35 2012
New Revision: 1300661
URL: http://svn.apache.org/viewvc?rev=1300661view=rev
Log:
CSV-60 CSVParser.iterator().remove() should throw throw new
UnsupportedOperationException()
is it reasonable to
Am 14. März 2012 20:33 schrieb Benedikt Ritter benerit...@googlemail.com:
Am 14. März 2012 18:43 schrieb s...@apache.org:
Author: sebb
Date: Wed Mar 14 17:43:35 2012
New Revision: 1300661
URL: http://svn.apache.org/viewvc?rev=1300661view=rev
Log:
CSV-60 CSVParser.iterator().remove()
Am 14. März 2012 20:48 schrieb s...@apache.org:
Author: sebb
Date: Wed Mar 14 19:48:12 2012
New Revision: 1300699
URL: http://svn.apache.org/viewvc?rev=1300699view=rev
Log:
Javadoc
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVFormat.java
Modified:
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
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
Am 14. März 2012 22:02 schrieb Emmanuel Bourg ebo...@apache.org:
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
On 14 March 2012 21:02, Emmanuel Bourg ebo...@apache.org 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
Am 14. März 2012 22:16 schrieb sebb seb...@gmail.com:
On 14 March 2012 21:02, Emmanuel Bourg ebo...@apache.org 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
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
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
Am 14. März 2012 22:33 schrieb Emmanuel Bourg ebo...@apache.org:
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
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:41, Emmanuel Bourg ebo...@apache.org 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
On 14 March 2012 21:40, Benedikt Ritter benerit...@googlemail.com wrote:
Am 14. März 2012 22:33 schrieb Emmanuel Bourg ebo...@apache.org:
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.
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
On 14 March 2012 21:56, Emmanuel Bourg ebo...@apache.org 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
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
On 14 March 2012 22:54, Emmanuel Bourg ebo...@apache.org 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
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
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
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
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
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.
I doubt
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
48 matches
Mail list logo
