Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/23
Many thanks Philippe
see my comments on the test.
Also I haven't checked whether the brotli lib is an OSGi bundle, we may
need to update the bundle-plugin configur
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/23#discussion_r114257473
--- Diff: pom.xml ---
@@ -85,6 +91,13 @@ jar, tar, zip, dump, 7z, arj.
${powermock.version}
test
Github user bindul commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/23#discussion_r114257132
--- Diff: pom.xml ---
@@ -68,6 +68,12 @@ jar, tar, zip, dump, 7z, arj.
test
+ org.brotli
+ dec
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/23
[](https://coveralls.io/builds/11327289)
Coverage decreased (-0.09%) to 84.202% when pulling
GitHub user pmouawad opened a pull request:
https://github.com/apache/commons-compress/pull/23
Add Brotli Support
Fix for:
https://issues.apache.org/jira/browse/COMPRESS-392
You can merge this pull request into a Git repository by running:
$ git pull https://github.com
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/22
[](https://coveralls.io/builds/11326518)
Coverage increased (+0.04%) to 84.329% when pulling
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/22
[](https://coveralls.io/builds/11244036)
Coverage decreased (-0.02%) to 84.286% when pulling
GitHub user kvr000 opened a pull request:
https://github.com/apache/commons-compress/pull/22
COMPRESS-390: Expose stream offsets and size
Pull request for https://issues.apache.org/jira/browse/COMPRESS-390
You can merge this pull request into a Git repository by running
Github user asfgit closed the pull request at:
https://github.com/apache/commons-compress/pull/20
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user asfgit closed the pull request at:
https://github.com/apache/commons-compress/pull/21
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/20
[](https://coveralls.io/builds/11230515)
Coverage increased (+0.06%) to 84.294% when pulling
Github user tballison commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/20#discussion_r113181027
--- Diff:
src/main/java/org/apache/commons/compress/compressors/lzma/LZMACompressorInputStream.java
---
@@ -56,7 +56,7 @@ public
Github user kinow commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/20#discussion_r113178004
--- Diff:
src/main/java/org/apache/commons/compress/compressors/lzma/LZMACompressorInputStream.java
---
@@ -56,7 +56,7 @@ public
Github user tballison commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/20#discussion_r113176495
--- Diff:
src/main/java/org/apache/commons/compress/compressors/lzma/LZMACompressorInputStream.java
---
@@ -56,7 +56,7 @@ public
Github user garydgregory commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/20#discussion_r113141961
--- Diff:
src/main/java/org/apache/commons/compress/compressors/lzma/LZMACompressorInputStream.java
---
@@ -56,7 +56,7 @@ public
Github user kinow commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/20#discussion_r113141080
--- Diff:
src/main/java/org/apache/commons/compress/compressors/lzma/LZMACompressorInputStream.java
---
@@ -56,7 +56,7 @@ public
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/20
[](https://coveralls.io/builds/11224344)
Coverage increased (+0.03%) to 84.263% when pulling
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/20
[](https://coveralls.io/builds/11223865)
Coverage increased (+0.02%) to 84.26% when pulling
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/20
[](https://coveralls.io/builds/11213136)
Coverage increased (+0.04%) to 84.274% when pulling
Github user tballison commented on the issue:
https://github.com/apache/commons-compress/pull/20
+1 to both suggestions. Will do. Thank you.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have
Github user kvr000 commented on the issue:
https://github.com/apache/commons-compress/pull/21
Additionally, I was thinking about exposing the entry raw stream starting
offset and length via public API so in case of need one can either map it into
memory, directly access the raw data
Github user kvr000 commented on the issue:
https://github.com/apache/commons-compress/pull/21
Update, improving few things:
- made the fields private again
- simplified to single read(long pos, ByteBuffer buf) method
- allocating the instance buffer only for single byte
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/21
[](https://coveralls.io/builds/11205671)
Coverage increased (+0.04%) to 84.277% when pulling
Github user sebbASF commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/21#discussion_r112838915
--- Diff:
src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java ---
@@ -,14 +1122,11 @@ public int read() throws IOException
Github user kvr000 commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/21#discussion_r112838864
--- Diff:
src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java ---
@@ -,14 +1122,11 @@ public int read() throws IOException
Github user kvr000 commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/21#discussion_r112838711
--- Diff:
src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java ---
@@ -1081,16 +1082,26 @@ private boolean startsWithLocalFileHeader
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/21#discussion_r112838584
--- Diff:
src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java ---
@@ -,14 +1122,11 @@ public int read() throws IOException
Github user sebbASF commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/21#discussion_r112838372
--- Diff:
src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java ---
@@ -,14 +1122,11 @@ public int read() throws IOException
Github user sebbASF commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/21#discussion_r112838358
--- Diff:
src/main/java/org/apache/commons/compress/archivers/zip/ZipFile.java ---
@@ -1081,16 +1082,26 @@ private boolean
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/21
[](https://coveralls.io/builds/11201739)
Coverage increased (+0.07%) to 84.303% when pulling
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/21
[](https://coveralls.io/builds/11199449)
Coverage decreased (-0.02%) to 84.214% when pulling
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/21
[](https://coveralls.io/builds/11199449)
Coverage decreased (-0.02%) to 84.214% when pulling
GitHub user kvr000 opened a pull request:
https://github.com/apache/commons-compress/pull/21
COMPRESS-388: Fix concurrent reads performance
Ticket: https://issues.apache.org/jira/browse/COMPRESS-388
Concurrent reads on the ZipFile archive is terribly slow on multiprocessor
Github user bodewig commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/20#discussion_r112810573
--- Diff:
src/test/java/org/apache/commons/compress/compressors/DetectCompressorTestCase.java
---
@@ -167,6 +171,26 @@ private String detect
Github user kinow commented on a diff in the pull request:
https://github.com/apache/commons-compress/pull/20#discussion_r112810239
--- Diff:
src/test/java/org/apache/commons/compress/compressors/DetectCompressorTestCase.java
---
@@ -167,6 +171,26 @@ private String detect(String
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/20
[](https://coveralls.io/builds/11191052)
Coverage increased (+0.2%) to 84.437% when pulling
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/20
[](https://coveralls.io/builds/11191052)
Coverage increased (+0.2%) to 84.437% when pulling
See
<https://builds.apache.org/job/Commons-Compress/243/display/redirect?page=changes>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
See
<https://builds.apache.org/job/Commons-Compress/org.apache.commons$commons-compress/243/display/redirect?page=changes>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
See
<https://builds.apache.org/job/Commons-Compress/242/display/redirect?page=changes>
Changes:
[bodewig] COMPRESS-387
[bodewig] COMPRESS-387 record changes
--
Started by an SCM change
[EnvInject] - Loading node environment variables.
Building re
See
<https://builds.apache.org/job/Commons-Compress/org.apache.commons$commons-compress/242/display/redirect?page=changes>
Changes:
[bodewig] COMPRESS-387
[bodewig] COMPRESS-387 record changes
--
Established TCP socket on 35626
maven33-agent.jar a
Github user asfgit closed the pull request at:
https://github.com/apache/commons-compress/pull/19
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
See
<https://builds.apache.org/job/Commons-Compress/org.apache.commons$commons-compress/241/display/redirect?page=changes>
Changes:
[bodewig] COMPRESS-385, first draft
[bodewig] COMPRESS-385, add ArchiveStreamFactory; undo boneheaded
[bodewig] COMPRESS-385, flip jar/zip back to wher
See
<https://builds.apache.org/job/Commons-Compress/241/display/redirect?page=changes>
Changes:
[bodewig] COMPRESS-385, first draft
[bodewig] COMPRESS-385, add ArchiveStreamFactory; undo boneheaded
[bodewig] COMPRESS-385, flip jar/zip back to where they belong
[bodewig] COMPRESS-38
Github user asfgit closed the pull request at:
https://github.com/apache/commons-compress/pull/18
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
On 2017-04-14, Allison, Timothy B. wrote:
>> enum wouldn't work for formats added via ServiceLoader. LZO supports a
>> couple of names of its own and you couldn't inject them into the enum.
> Doh! Got it. New code base...Sorry.
No problem :-)
I've taken a prolonged offline Easter-weekend, wi
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/20
[](https://coveralls.io/builds/11091808)
Coverage increased (+0.04%) to 84.215% when pulling
GitHub user tballison opened a pull request:
https://github.com/apache/commons-compress/pull/20
COMPRESS-382
first draft of preventing OOM in LZMA
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/tballison/commons-compress
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/19
[](https://coveralls.io/builds/11090454)
Coverage decreased (-0.02%) to 84.15% when pulling
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/19
[](https://coveralls.io/builds/11090454)
Coverage decreased (-0.02%) to 84.15% when pulling
GitHub user tballison opened a pull request:
https://github.com/apache/commons-compress/pull/19
COMPRESS-387
Fix specification of ARCDIR to allow spaces in path in Windows
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/tballison
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/18
[](https://coveralls.io/builds/11089922)
Coverage increased (+0.06%) to 84.233% when pulling
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/18
[](https://coveralls.io/builds/11089584)
Coverage increased (+0.06%) to 84.233% when pulling
>enum wouldn't work for formats added via ServiceLoader. LZO supports a couple
>of names of its own and you couldn't inject them into the enum.
Doh! Got it. New code base...Sorry.
-
To unsubscribe, e-mail: dev-unsubscr...@comm
On 2017-04-14, Allison, Timothy B. wrote:
>>> If there is anything COMPRESS can do to detect and avoid the
>>> situation, then please open an issue over here.
> Done: COMPRESS-385, PR submitted
Thanks.
>>> If we wanted to add such a method, what would the return v
>> If there is anything COMPRESS can do to detect and avoid the situation, then
>> please open an issue over here.
Done: COMPRESS-385, PR submitted
>> If we wanted to add such a method, what would the return value be? One of
>> the String constants contained inside the
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/18
[](https://coveralls.io/builds/11088637)
Coverage increased (+0.02%) to 84.198% when pulling
GitHub user tballison opened a pull request:
https://github.com/apache/commons-compress/pull/18
COMPRESS-385
add detect() to CompressorStreamFactory
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/tballison/commons-compress
press's JIRA?
If there is anything COMPRESS can do to detect and avoid the situation,
then please open an issue over here.
> A second question, we're creating a stream with the
> CompressorStreamFactory when all we want to do is detect. Is there a
> recommended way to detect
I have reported a similar issue to them, see Compress-382, maybe those
issues should be handled at Compress side, if I understood correctly the
API contract.
Luis
Em 13 de abr de 2017 3:36 PM, "Allison, Timothy B."
escreveu:
On TIKA-1631 [1], users have observed that a corrupt
On TIKA-1631 [1], users have observed that a corrupt Z file can cause an OOM at
Internal_.InternalLZWStream.initializeTable. Should we try to protect against
this at the Tika level, or should we open an issue on commons-compress's JIRA?
A second question, we're creating a stream with the Comp
On 2017-04-11, Benedikt Ritter wrote:
>> Am 11.04.2017 um 14:47 schrieb bode...@apache.org:
>> Repository: commons-compress
>> Updated Branches:
>> refs/heads/master 5ce60be9d -> 08113862c
>> reduce GC pressure by avoiding File(In|Out)putStreams
> So you
> Am 11.04.2017 um 14:47 schrieb bode...@apache.org:
>
> Repository: commons-compress
> Updated Branches:
> refs/heads/master 5ce60be9d -> 08113862c
>
>
> reduce GC pressure by avoiding File(In|Out)putStreams
So you also saw the blog post by CloudBees ;-)
Regards
On 2017-04-05, Stefan Bodewig wrote:
> I'll need to debug this further which is cumbersome. In either case this
> will block all attempts of cutting a 1.14 release.
Fixed now, BTW.
Stefan
-
To unsubscribe, e-mail: dev-unsubscr.
See
<https://builds.apache.org/job/Commons-Compress/239/display/redirect?page=changes>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
See
<https://builds.apache.org/job/Commons-Compress/org.apache.commons$commons-compress/239/display/redirect?page=changes>
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail:
See
<https://builds.apache.org/job/Commons-Compress/238/display/redirect?page=changes>
Changes:
[bodewig] actually use 4MB when you say 4MB
--
[...truncated 298.71 KB...]
[INFO] Downloaded:
https://repo.maven.apache.org/maven2/org/codehaus/plexus/
See
<https://builds.apache.org/job/Commons-Compress/org.apache.commons$commons-compress/238/display/redirect?page=changes>
Changes:
[bodewig] actually use 4MB when you say 4MB
--
[...truncated 292.18 KB...]
[INFO] Downloaded:
Hi
after fixing my benchmark to actually measure decompression I'm facing a
"checksum mismatch" when compressing the source tarball of Commons
Compress 1.13. It seems to be sheer luck I'm using this file as a
roundtrip using many other files - including the binary tarball -
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
I just realized I had benchmarked compression rather than decompression,
I've now updated
https://github.com/bodewig/commons-compress-benchmarks/wiki/PR13
Fortunately the resu
ion format").
https://github.com/bodewig/commons-compress-benchmarks/wiki/Comparison-of-Compression-Formats
Our implementation of Snappy is quite a bit faster than LZ4, but LZ4's
compression ratio is better.
I'd be grateful for a few more eyes looking over the new code (Snappy
output, lz
Github user asfgit closed the pull request at:
https://github.com/apache/commons-compress/pull/17
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/17
Great, many thanks,
I've just found
https://people.freebsd.org/~kientzle/libarchive/man/cpio.5.txt states
> The CRC format is identical to the new ASCII format desc
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/17
[](https://coveralls.io/builds/10826707)
Coverage increased (+0.001%) to 84.176% when pulling
GitHub user dcollin opened a pull request:
https://github.com/apache/commons-compress/pull/17
CPIO crc overflow resolved for large files
When unpacking a CPIO file containing a large file the crc check will
overflow and throw an IOException("CRC Error...").
Di
On 2017-02-25, Stefan Bodewig wrote:
> While I was at it I thought it would be nice to compare the performance
> of the compression formats we support:
>
> https://github.com/bodewig/commons-compress-benchmarks/wiki/Comparison-of-Compression-Formats
> As expected the performa
On 2017-02-25, Stefan Bodewig wrote:
> On 2017-02-25, Stefan Bodewig wrote:
>> I'll write benchmarks for the Checksum algos next, it might be the
>> xxhash32 implementation being slower than the crc32-c we've got.
> It is, by a factor of two.
It was, by now xxhash32 is a tiny bit faster :-)
St
On 2017-02-25, Stefan Bodewig wrote:
> I'll write benchmarks for the Checksum algos next, it might be the
> xxhash32 implementation being slower than the crc32-c we've got.
It is, by a factor of two.
Stefan
-
To unsubscribe, e-
https://github.com/bodewig/commons-compress-benchmarks/wiki/Comparison-of-Compression-Formats
As expected the performance of the zlib based native gzip/deflate
compressors/decompressors is superior to all others. The performance of
the pure Java LZ77 I've implemented for snappy and lz4 doesn't lo
Github user asfgit closed the pull request at:
https://github.com/apache/commons-compress/pull/13
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
@thomasmey I've made some minor changes and pushed it to the branch PR13
My benchmarks at
https://github.com/bodewig/commons-compress-benchmarks/wiki/PR13 sees the
changed
Github user thomasmey closed the pull request at:
https://github.com/apache/commons-compress/pull/16
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/16
True, a unit-test wouldn't hurt.
I'm afraid I can't close the PR myself.
---
If your project is set up for it, you can reply to this email and have your
reply appe
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
For starters, https://github.com/bodewig/commons-compress-benchmarks -
right now I'm not sure where it'll end up.
---
If your project is set up for it, you can reply to this emai
Github user thomasmey commented on the issue:
https://github.com/apache/commons-compress/pull/16
Oops.
True, my mistake. Maybe we should cover this with a unit test...
Sorry for the fuss.
---
If your project is set up for it, you can reply to this email and have
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/16
Hmm, the no-arg `read` returns the byte read. So when reading an `'A'` your
code would count 65 bytes rather than 1, wouldn't it?
---
If your project is set up for it, y
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
I'm planning to set up a JMH based benchmark soonish and would like to get
some statistical information before merging this.
---
If your project is set up for it, you can reply to
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Commons Wiki" for
change notification.
The "Compress" page has been changed by StefanBodewig:
https://wiki.apache.org/commons/Compress?action=diff&rev1=8&rev2=9
Comment:
COMPRESS-381 - impr
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/16
[](https://coveralls.io/builds/9882175)
Coverage increased (+0.2%) to 84.291% when pulling
GitHub user thomasmey opened a pull request:
https://github.com/apache/commons-compress/pull/16
Don't duplicate count() functionality.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/thomasmey/commons-compress work
On 2017-01-24, Gary Gregory wrote:
> Once [compress] has its next release, what about copying XXHash32 to
> [codec]? That seems to me like the proper home for such things.
That's why I started the other thread ;-)
Stefan
-
Once [compress] has its next release, what about copying XXHash32 to
[codec]? That seems to me like the proper home for such things.
Gary
-- Forwarded message --
From:
Date: Tue, Jan 24, 2017 at 11:53 AM
Subject: commons-compress git commit: COMPRESS-271 xxhash32 checksum
To
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/13
Sorry, I didn't realize you had updated the PR, will have a look later.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as wel
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/14
Thanks!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or
Github user asfgit closed the pull request at:
https://github.com/apache/commons-compress/pull/14
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user asfgit closed the pull request at:
https://github.com/apache/commons-compress/pull/15
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/15
Thanks!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/15
[](https://coveralls.io/builds/9753635)
Coverage decreased (-0.001%) to 83.383% when pulling
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/14
[](https://coveralls.io/builds/9753610)
Coverage decreased (-0.03%) to 83.359% when pulling
Github user coveralls commented on the issue:
https://github.com/apache/commons-compress/pull/13
[](https://coveralls.io/builds/9753579)
Coverage increased (+0.1%) to 83.502% when pulling
901 - 1000 of 3222 matches
Mail list logo
