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
Le 12/03/2012 00:16, Benedikt Ritter a écrit :
I just saw that CSVFormat implements Serializable, but neither does it
provide a no-arg constructor nor any of the special serialization
methods (and it has no custom serialUID). Is this the way it is
supposed to be?
I wrote a test and it seems
Emmanuel Bourg wrote:
Le 12/03/2012 00:16, Benedikt Ritter a écrit :
I just saw that CSVFormat implements Serializable, but neither does it
provide a no-arg constructor nor any of the special serialization
methods (and it has no custom serialUID). Is this the way it is
supposed to be?
I
I have identified the performance killer, it's the
ExtendedBufferedReader. It implements a complex logic to fetch one
character ahead, but this extra character is rarely used. I have
implemented a simpler look ahead using mark/reset as suggested by Bob
Smith in CSV-42 and the performance
Hi,
I was unable to download the binaries of this release from the
website. Downloading the source works fine. Maybe I did something
wrong, could anyone else check?
Sébastien
-
To unsubscribe, e-mail:
I do not think we need to tickets for this kind of change.
Gary
On Mar 12, 2012, at 9:59, Benedikt Ritter (Created) (JIRA) j...@apache.org
wrote:
Replace while(true)-loop in CSVParser.getRecord() with do-while-loop
Hey Gary,
thanks for the hint. Should I just send patches for minor changes like
that to the ML (plain text, not as attachment of course ;)?
Benedikt
Am 12. März 2012 15:03 schrieb Gary Gregory ggreg...@rocketsoftware.com:
I do not think we need to tickets for this kind of change.
Gary
On
On Mon, Mar 12, 2012 at 10:17 AM, Benedikt Ritter benerit...@googlemail.com
wrote:
Hey Gary,
thanks for the hint. Should I just send patches for minor changes like
that to the ML (plain text, not as attachment of course ;)?
Hm, I thought a comitter was submitting these... JIRA is the way
Am 12. März 2012 15:39 schrieb Gary Gregory garydgreg...@gmail.com:
On Mon, Mar 12, 2012 at 10:17 AM, Benedikt Ritter benerit...@googlemail.com
wrote:
Hey Gary,
thanks for the hint. Should I just send patches for minor changes like
that to the ML (plain text, not as attachment of course ;)?
On Mon, Mar 12, 2012 at 10:47 AM, Benedikt Ritter benerit...@googlemail.com
wrote:
Am 12. März 2012 15:39 schrieb Gary Gregory garydgreg...@gmail.com:
On Mon, Mar 12, 2012 at 10:17 AM, Benedikt Ritter
benerit...@googlemail.com
wrote:
Hey Gary,
thanks for the hint. Should I just
2012/3/12 Sébastien Brisard sebastien.bris...@m4x.org
Hi,
I was unable to download the binaries of this release from the
website. Downloading the source works fine. Maybe I did something
wrong, could anyone else check?
Did not work for me too, the reason is the link is wrong, the -bin
On 12 March 2012 09:02, Jörg Schaible joerg.schai...@scalaris.com wrote:
Emmanuel Bourg wrote:
Le 12/03/2012 00:16, Benedikt Ritter a écrit :
I just saw that CSVFormat implements Serializable, but neither does it
provide a no-arg constructor nor any of the special serialization
methods (and
On 12 March 2012 15:08, Thomas Neidhart thomas.neidh...@gmail.com wrote:
2012/3/12 Sébastien Brisard sebastien.bris...@m4x.org
Hi,
I was unable to download the binaries of this release from the
website. Downloading the source works fine. Maybe I did something
wrong, could anyone else check?
On Mon, Mar 12, 2012 at 11:23 AM, sebb seb...@gmail.com wrote:
On 12 March 2012 09:02, Jörg Schaible joerg.schai...@scalaris.com wrote:
Emmanuel Bourg wrote:
Le 12/03/2012 00:16, Benedikt Ritter a écrit :
I just saw that CSVFormat implements Serializable, but neither does it
provide
On 12 March 2012 10:31, Emmanuel Bourg ebo...@apache.org wrote:
I have identified the performance killer, it's the ExtendedBufferedReader.
It implements a complex logic to fetch one character ahead, but this extra
character is rarely used. I have implemented a simpler look ahead using
Le 12/03/2012 16:44, sebb a écrit :
Java has a PushbackReader class - could that not be used?
I considered it, but it doesn't mix well with line reading. The
mark/reset solution is really simple and efficient.
Emmanuel Bourg
smime.p7s
Description: S/MIME Cryptographic Signature
2012/3/12 sebb seb...@gmail.com:
On 12 March 2012 15:08, Thomas Neidhart thomas.neidh...@gmail.com wrote:
2012/3/12 Sébastien Brisard sebastien.bris...@m4x.org
Hi,
I was unable to download the binaries of this release from the
website. Downloading the source works fine. Maybe I did something
In addition to Javadoc for 3.0 and 2.2, the website still offers the following:
Javadoc (2.1 release)
Javadoc (2.0 release)
Javadoc (1.2 release)
Javadoc (1.1 release)
Javadoc (1.0 release)
This seems rather unnecessary. Surely we should only offer Javadoc for
current releases?
Am 12. März 2012 11:31 schrieb Emmanuel Bourg ebo...@apache.org:
I have identified the performance killer, it's the ExtendedBufferedReader.
It implements a complex logic to fetch one character ahead, but this extra
character is rarely used. I have implemented a simpler look ahead using
Le 12/03/2012 17:03, Benedikt Ritter a écrit :
The hole logic behind CSVLexer.nextToken() is very hard to read
(IMHO). Maybe a some refactoring would help to make it easier to
identify bottle necks?
Yes I started investigating in this direction. I filed a few bugs
regarding the behavior of
We could say we support short-term storage (or transmission-only) only when
it comes to serialization. That would help eliminate some of the burden
On Mar 12, 2012 11:23 AM, sebb seb...@gmail.com wrote:
On 12 March 2012 09:02, Jörg Schaible joerg.schai...@scalaris.com wrote:
Emmanuel Bourg
Would one of the parser libraries not work here?
On Mar 12, 2012 12:22 PM, Emmanuel Bourg ebo...@apache.org wrote:
Le 12/03/2012 17:03, Benedikt Ritter a écrit :
The hole logic behind CSVLexer.nextToken() is very hard to read
(IMHO). Maybe a some refactoring would help to make it easier to
On 12 March 2012 16:25, James Carman jcar...@carmanconsulting.com wrote:
We could say we support short-term storage (or transmission-only) only when
it comes to serialization. That would help eliminate some of the burden
Perhaps, but why take on any burden without a good use case?
Any form of
Am 12. März 2012 17:22 schrieb Emmanuel Bourg ebo...@apache.org:
Le 12/03/2012 17:03, Benedikt Ritter a écrit :
The hole logic behind CSVLexer.nextToken() is very hard to read
(IMHO). Maybe a some refactoring would help to make it easier to
identify bottle necks?
Yes I started
Le 12/03/2012 17:28, James Carman a écrit :
Would one of the parser libraries not work here?
You think at something like JavaCC or AntLR? Not sure it'll be more
efficient than a handcrafted parser. The CSV format is simple enough to
do it manually.
Emmanuel Bourg
smime.p7s
Description:
On 12 March 2012 08:45, ebo...@apache.org wrote:
Author: ebourg
Date: Mon Mar 12 08:45:34 2012
New Revision: 1299580
URL: http://svn.apache.org/viewvc?rev=1299580view=rev
Log:
Serialization test for CSVFormat
Note: this does not test serialisation between versions or JDKs as the
same JVM
On Mon, Mar 12, 2012 at 5:30 PM, sebb seb...@gmail.com wrote:
On 12 March 2012 16:25, James Carman jcar...@carmanconsulting.com wrote:
We could say we support short-term storage (or transmission-only) only when
it comes to serialization. That would help eliminate some of the burden
Perhaps,
On Mon, Mar 12, 2012 at 5:41 PM, Emmanuel Bourg ebo...@apache.org wrote:
Le 12/03/2012 17:28, James Carman a écrit :
Would one of the parser libraries not work here?
You think at something like JavaCC or AntLR? Not sure it'll be more
efficient than a handcrafted parser. The CSV format is
On Mon, Mar 12, 2012 at 5:48 PM, sebb seb...@gmail.com wrote:
On 12 March 2012 08:45, ebo...@apache.org wrote:
Author: ebourg
Date: Mon Mar 12 08:45:34 2012
New Revision: 1299580
URL: http://svn.apache.org/viewvc?rev=1299580view=rev
Log:
Serialization test for CSVFormat
Note: this does
Yes this is what I mean. It might be worth a shot. Folks who specialize
in parsing have spent much time on these libraries. It would make sense
that they are quite fast. It gets us out of the parsing business.
On Mar 12, 2012 12:41 PM, Emmanuel Bourg ebo...@apache.org wrote:
Le 12/03/2012
Hi,
while looking for potential performance optimization I came across
CSVLexer.isEndOfLine(int c). Here is the source:
private boolean isEndOfLine(int c) throws IOException {
// check if we have \r\n...
if (c == '\r' in.lookAhead() == '\n') {
// note: does not
Le 12/03/2012 18:17, Benedikt Ritter a écrit :
this method assumes, that a line separator will always be \r or
\r\n. This is true for the pre-configured CSVFormats EXCEL, TDF and
MYSQL. I'm not a pro when it comes to file encoding, but isn't there
the possibility that new encodings will have
Am 12. März 2012 18:24 schrieb Emmanuel Bourg ebo...@apache.org:
Le 12/03/2012 18:17, Benedikt Ritter a écrit :
this method assumes, that a line separator will always be \r or
\r\n. This is true for the pre-configured CSVFormats EXCEL, TDF and
MYSQL. I'm not a pro when it comes to file
Le 12/03/2012 18:31, Benedikt Ritter a écrit :
I'm not sure if I got you right. You have to pass a CSVFormat if you
want to construct a CSVLexer(), so we could use the lexer's internal
CSVformat.
Yes that's what I understood, when I mention the parser it includes the
lexer as well.
I think
Am 12. März 2012 18:38 schrieb Emmanuel Bourg ebo...@apache.org:
Le 12/03/2012 18:31, Benedikt Ritter a écrit :
I'm not sure if I got you right. You have to pass a CSVFormat if you
want to construct a CSVLexer(), so we could use the lexer's internal
CSVformat.
Yes that's what I
On 12 March 2012 17:38, Emmanuel Bourg ebo...@apache.org wrote:
Le 12/03/2012 18:31, Benedikt Ritter a écrit :
I'm not sure if I got you right. You have to pass a CSVFormat if you
want to construct a CSVLexer(), so we could use the lexer's internal
CSVformat.
Yes that's what I understood,
Le 12/03/2012 18:52, sebb a écrit :
The only possible ambiguity is whether the file uses CR, LF, or CRLF.
Yes that's what I mean by knowing in advance.
The line separator is not obvious when you open the file in an editor.
That's not the case for the delimiter.
Emmanuel Bourg
smime.p7s
Le 12/03/2012 18:51, Benedikt Ritter a écrit :
you wrote about the printer ;)
Yes, because the line separator of CSVFormat is only used there.
Usually you have to be permissive in what your read, but strict on what
your write.
Emmanuel Bourg
smime.p7s
Description: S/MIME Cryptographic
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
Le 12/03/2012 16:50, sebb a écrit :
In addition to Javadoc for 3.0 and 2.2, the website still offers the
following:
Javadoc (2.1 release)
Javadoc (2.0 release)
Javadoc (1.2 release)
Javadoc (1.1 release)
Javadoc (1.0 release)
This seems rather unnecessary. Surely we should only offer
Hello,
can we commit now that 3.0 is out?
Do we need to update the pom.xml to 3.1-SNAPSHOT?
Best regards,
Sébastien
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
Le 12/03/2012 20:38, Sébastien Brisard a écrit :
Hello,
Hi Sébastien,
can we commit now that 3.0 is out?
Sure!
Do we need to update the pom.xml to 3.1-SNAPSHOT?
I think Seeb did it today.
We should also close the Jira issues that have been solved as of 3.0.
For newcomers, our policy on
Hi,
on the weekend, I started to work on issue LANG-680
(https://issues.apache.org/jira/browse/LANG-680), which is about adding
support for finding the longest common substring of a set of Strings.
Suffix Trees are a standard data structure to efficiently solve this
problem, and I created a
Am 12. März 2012 21:20 schrieb Thomas Neidhart thomas.neidh...@gmail.com:
Hi,
on the weekend, I started to work on issue LANG-680
(https://issues.apache.org/jira/browse/LANG-680), which is about adding
support for finding the longest common substring of a set of Strings.
Suffix Trees are a
[csv] is missing some elements to ease the use of headers. I have no
clear idea on how to address this, here are my thoughts.
Headers are used when the fields are accessed by the column name rather
than by the index. This provides some flexibility because the input file
can be slightly
A lot of bioinformaticians would love us if we added this!
On Mar 12, 2012 4:20 PM, Thomas Neidhart thomas.neidh...@gmail.com
wrote:
Hi,
on the weekend, I started to work on issue LANG-680
(https://issues.apache.org/jira/browse/LANG-680), which is about adding
support for finding the longest
On 12 March 2012 22:11, Emmanuel Bourg ebo...@apache.org wrote:
[csv] is missing some elements to ease the use of headers. I have no clear
idea on how to address this, here are my thoughts.
Headers are used when the fields are accessed by the column name rather than
by the index. This
I kept tickling ExtendedBufferedReader and I have some interesting results.
First I tried to simplify it by extending java.io.LineNumberReader
instead of BufferedReader. The performance decreased by 20%, probably
because the class is synchronized internally.
But wait, isn't BufferedReader
On 13 March 2012 00:12, Emmanuel Bourg ebo...@apache.org wrote:
I kept tickling ExtendedBufferedReader and I have some interesting results.
First I tried to simplify it by extending java.io.LineNumberReader instead
of BufferedReader. The performance decreased by 20%, probably because the
Le 13/03/2012 01:25, sebb a écrit :
I'm concerned that the CSV code may grow and grow with private
versions of code that could be provided by the JDK.
By all means make sure the code is efficient in the way it uses the
JDK classes, but I don't think we should be recoding standard classes.
I
Le 13/03/2012 00:56, sebb a écrit :
1. Do nothing and address it in the next release with the bean mapping.
Parsing the file would then look like this:
CSVFormatPerson format = CSVFormat.DEFAULT.withType(Person.class);
for (Person person : format.parse(in)) {
persons.add(person);
On Mar 12, 2012, at 20:25, sebb seb...@gmail.com wrote:
On 13 March 2012 00:12, Emmanuel Bourg ebo...@apache.org wrote:
I kept tickling ExtendedBufferedReader and I have some interesting results.
First I tried to simplify it by extending java.io.LineNumberReader instead
of BufferedReader.
On Mar 12, 2012, at 20:30, Emmanuel Bourg ebo...@apache.org wrote:
Le 13/03/2012 01:25, sebb a écrit :
I'm concerned that the CSV code may grow and grow with private
versions of code that could be provided by the JDK.
By all means make sure the code is efficient in the way it uses the
JDK
On 13 March 2012 00:29, Emmanuel Bourg ebo...@apache.org wrote:
Le 13/03/2012 01:25, sebb a écrit :
I'm concerned that the CSV code may grow and grow with private
versions of code that could be provided by the JDK.
By all means make sure the code is efficient in the way it uses the
JDK
On 10 March 2012 01:02, sebb seb...@gmail.com wrote:
This is a VOTE to release commons-parent 24 based on RC2.
As agreed previously, commons parent release votes operate on lazy
consensus, i.e. the vote is assumed to have passed if 72 hours have
elapsed without an objection.
72 hours have
On Mon, Mar 12, 2012 at 9:12 PM, sebb seb...@gmail.com wrote:
On 10 March 2012 01:02, sebb seb...@gmail.com wrote:
This is a VOTE to release commons-parent 24 based on RC2.
As agreed previously, commons parent release votes operate on lazy
consensus, i.e. the vote is assumed to have
On Tue, Mar 13, 2012 at 12:29 AM, Emmanuel Bourg ebo...@apache.org wrote:
Le 13/03/2012 01:25, sebb a écrit :
I'm concerned that the CSV code may grow and grow with private
versions of code that could be provided by the JDK.
By all means make sure the code is efficient in the way it uses
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-io-test has an issue affecting its community integration.
This
On 13 March 2012 01:47, Niall Pemberton niall.pember...@gmail.com wrote:
On Tue, Mar 13, 2012 at 12:29 AM, Emmanuel Bourg ebo...@apache.org wrote:
Le 13/03/2012 01:25, sebb a écrit :
I'm concerned that the CSV code may grow and grow with private
versions of code that could be provided by the
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
On Mar 12, 2012, at 5:44 PM, sebb wrote:
On 13 March 2012 00:29, Emmanuel Bourg ebo...@apache.org wrote:
Le 13/03/2012 01:25, sebb a écrit :
I'm concerned that the CSV code may grow and grow with private
versions of code that could be provided by the JDK.
By all means make sure the
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
65 matches
Mail list logo
