On 2013-05-07, Damjan Jovanovic wrote:
> On Tue, May 7, 2013 at 6:09 AM, Stefan Bodewig 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
>> hap
On Tue, May 7, 2013 at 6:09 AM, Stefan Bodewig 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 support, only
On 7 May 2013 16:18, Benedikt Ritter wrote:
> 2013/5/7
>
>> 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/apach
2013/5/7
> 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
>
> commons/proper/csv/trunk/sr
On 7 May 2013 15:40, Adrian Crum 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 also zero at this point; we
hav
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 p
On 7 May 2013 11:36, Adrian Crum 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 reports the
current line number fo
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 c
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 process
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, fina
2013/5/6 sebb
> On 6 May 2013 18:53, Benedikt Ritter wrote:
>
> > 2013/5/5 sebb
> >
> > > On 3 May 2013 14:37, Benedikt Ritter wrote:
> > >
> > > > (moving this to a new thread)
> > > >
> > > > Hi,
> > > >
> > > > I did a very small refactoring in Lexer just to realize that the
> > > isXXX(int
2013/5/6 Gary Gregory
> On Mon, May 6, 2013 at 5:49 PM, sebb 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 does not seem to be a
12 matches
Mail list logo