Re: [compress] Unused CRC in ZipArchiveInputStream

2013-12-18 Thread Stefan Bodewig
On 2013-12-19, Emmanuel Bourg wrote: > ZipArchiveInputStream updates a CRC32 for each entry but the result is > never used. Any objection to remove it? Hmm, we also set the CRC on the ZipArchiveEntry so it may be worth to actually verify it. ZipFile doesn't verify it either, by the way. I'd pre

Re: [compress] Unused CRC in ZipArchiveInputStream

2013-12-18 Thread sebb
On 19 December 2013 00:16, Emmanuel Bourg wrote: > Hi all, > > ZipArchiveInputStream updates a CRC32 for each entry but the result is > never used. Any objection to remove it? Presumably there is a CRC field in the archive against which this could be checked? If so, how difficult would it be to

[compress] Unused CRC in ZipArchiveInputStream

2013-12-18 Thread Emmanuel Bourg
Hi all, ZipArchiveInputStream updates a CRC32 for each entry but the result is never used. Any objection to remove it? Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail:

RE: [exec] 1.1.1 release?

2013-12-18 Thread Gary Gregory
No, it's not bad for to ask :) it sound like no one has the need for a release. Are there fixes you are looking for? Gary Original message From: Ryan Hendrickson Date:12/18/2013 16:53 (GMT-05:00) To: "'dev@commons.apache.org'" Subject: [exec] 1.1.1 release? Sorry if it

[exec] 1.1.1 release?

2013-12-18 Thread Ryan Hendrickson
Sorry if it's bad form to ask this, but is there any plan for a non-snapshot release of commons-exec 1.1.1? It looks like the exec subtree hasn't seen any real development in just over a year, and the 1.1 release was three years ago. Thanks, Ryan This

[all] ApacheCon North America 2014

2013-12-18 Thread Phil Steitz
The Call For Proposals for ApacheCon NA, 2014 will go out in the next couple of weeks. PMCs have been asked for volunteers for the Content Committee to review proposals related to their projects. Before we all rush to raise our hands, we thought it best to get a sense for what talks might be prop

Re: [math] Release Plan for 3.3

2013-12-18 Thread Phil Steitz
On 12/18/13, 4:05 AM, Thomas Neidhart wrote: > Hi, > > I wanted to check what others think about making a 3.3 release in the next > 1-2 months. > > My plans are as follows: > > - finish the open documentation / userguide issues over Christmas > - finish a few of my feature requests for which I ha

Re: [math] Release Plan for 3.3

2013-12-18 Thread Luc Maisonobe
Le 18/12/2013 13:05, Thomas Neidhart a écrit : > Hi, Hi Thomas, > > I wanted to check what others think about making a 3.3 release in the next > 1-2 months. > > My plans are as follows: > > - finish the open documentation / userguide issues over Christmas > - finish a few of my feature reque

[math] Release Plan for 3.3

2013-12-18 Thread Thomas Neidhart
Hi, I wanted to check what others think about making a 3.3 release in the next 1-2 months. My plans are as follows: - finish the open documentation / userguide issues over Christmas - finish a few of my feature requests for which I have a patch ready but are missing tests till mid/end of Ja

Re: svn commit: r1551026 - in /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress: archivers/zip/UnshrinkingInputStream.java compressors/z/AbstractLZWInputStream.java compressors/

2013-12-18 Thread Emmanuel Bourg
Le 18/12/2013 09:21, Stefan Bodewig a écrit : > The end-of-information part could probably be dealt with in the subclass > specific implementation of decompressNextSymbol and increasing the code > size may happen in addEntry, not sure. As for endianess, Emmanuel > briefly mentioned a BitInputStre

Re: svn commit: r1551026 - in /commons/proper/compress/trunk/src/main/java/org/apache/commons/compress: archivers/zip/UnshrinkingInputStream.java compressors/z/AbstractLZWInputStream.java compressors/

2013-12-18 Thread Stefan Bodewig
On 2013-12-17, Damjan Jovanovic wrote: > I am wondering how far this can be taken. TIFF's LZW uses an > end-of-information code after the clear code, allows both > little-endian and big-endian packing of bytes, and increases the code > size one step too early. Is it even possible to generalize LZW