I have reverted the commit and commented why we use an anonymous subclass
of DefaultExpectionContext. But to be honest I don't really see the point.
Since the signature of the constructor is
public ContextedRuntimeException(final String message, final Throwable
cause, ExceptionContext context)
2013/5/7 sebb seb...@gmail.com
On 6 May 2013 15:19, Benedikt Ritter brit...@apache.org wrote:
2013/5/6 s...@apache.org
Author: sebb
Date: Mon May 6 14:09:05 2013
New Revision: 1479574
URL: http://svn.apache.org/r1479574
Log:
Fix up internal raw types
Keep in mind, that
2013/5/6 Gary Gregory garydgreg...@gmail.com
On Mon, May 6, 2013 at 5:49 PM, sebb seb...@gmail.com wrote:
The line number returned by
ExtendedBufferedReader.getLineNumber()
currently starts at zero, so an error in the first line in the file is
reported as being in line 0.
There
2013/5/6 sebb seb...@gmail.com
On 6 May 2013 18:53, Benedikt Ritter brit...@apache.org wrote:
2013/5/5 sebb seb...@gmail.com
On 3 May 2013 14:37, Benedikt Ritter brit...@apache.org wrote:
(moving this to a new thread)
Hi,
I did a very small refactoring in Lexer
Hi Benedikt,
Benedikt Ritter wrote:
I have reverted the commit and commented why we use an anonymous subclass
of DefaultExpectionContext. But to be honest I don't really see the point.
Since the signature of the constructor is
public ContextedRuntimeException(final String message, final
I've been looking at it further and there is an issue with 1-based counting.
The line number currently counts the number of EOLs seen.
This means it is currently accurate for total line count (which a
1-based system would not be) and is accurate for any completed
records.
It's only during
Maybe the method could be named better, something like
ExtendedBufferedReader.getCurrentLineNumber() - which would be different
than total lines processed.
-Adrian
On 5/7/2013 11:05 AM, sebb wrote:
I've been looking at it further and there is an issue with 1-based counting.
The line number
On 7 May 2013 11:36, Adrian Crum adrian.c...@sandglass-software.com wrote:
Maybe the method could be named better, something like
ExtendedBufferedReader.getCurrentLineNumber() - which would be different
than total lines processed.
Indeed, but at present there is no method which accurately
From my perspective, it should be fairly easy to make it clear...
1. File is opened, but not processed. Current line number = 1, total
lines processed = 0, records processed = 0.
2. First line is processed. Current line number = 2, lines processed =
1, records processed = 0.
3. Second line is
On 7 May 2013 15:40, Adrian Crum adrian.c...@sandglass-software.com wrote:
From my perspective, it should be fairly easy to make it clear...
1. File is opened, but not processed. Current line number = 1, total lines
processed = 0, records processed = 0.
I would say the current line number is
2013/5/7 s...@apache.org
Author: sebb
Date: Tue May 7 15:12:48 2013
New Revision: 1479936
URL: http://svn.apache.org/r1479936
Log:
CSV-98 Line number counting is confusing
Modified:
commons/proper/csv/trunk/src/main/java/org/apache/commons/csv/CSVLexer.java
On 7 May 2013 16:18, Benedikt Ritter brit...@apache.org wrote:
2013/5/7 s...@apache.org
Author: sebb
Date: Tue May 7 15:12:48 2013
New Revision: 1479936
URL: http://svn.apache.org/r1479936
Log:
CSV-98 Line number counting is confusing
Modified:
On Tue, May 7, 2013 at 6:09 AM, Stefan Bodewig bode...@apache.org wrote:
On 2013-05-06, Damjan Jovanovic wrote:
I've been hacking on a patch that adds support for reading 7zip archives.
COMPRESS-54 is the most popular issue so you'd make quite a few people
happy.
I doubt it - without LZMA
13 matches
Mail list logo
