Howdy and as always, thank you for reading.
In a recent project, I have found that it has been very useful to
implement something akin to Google's Guava ByteSource. I happen to
call mine InputStreamSource. Would such a feature be of interest for
inclusion into Commons IO?
--
d into ASF?
As always, thanks for your input!
On Fri, Nov 29, 2013 at 2:57 AM, Stefan Bodewig wrote:
> On 2013-11-29, dam6923 . wrote:
>
>> Is there any policy in place or method already laid out for putting
>> bounties on certain task items? In particular, I could chip some
Hello,
Is there any policy in place or method already laid out for putting
bounties on certain task items? In particular, I could chip something
in for the following two tickets:
1) https://issues.apache.org/jira/browse/COMPRESS-88
2) https://issues.apache.org/jira/browse/COMPRESS-238
Both are
Thanks for all the work. I'm excited to finally incorporate the
changes into some of my professional work.
I just took a peek at the website and there is an advertisement for
ApacheCon NA 2013. Perhaps its time to drop the mention? :)
Thanks.
On Sat, Oct 26, 2013 at 9:52 AM, Stefan Bodewig w
I am guilty/victim of that issue just last night. Was the fix implemented
before that? If so, it's still a problem.
On Oct 25, 2013 10:31 AM, "sebb" wrote:
> There was a problem with the Create Issue dialog not closing when an
> issue was created, so it looked like it had failed, leading to
> r
Let not the perfect be the enemy of the good +1
On Tue, Oct 15, 2013 at 2:26 PM, Stefan Bodewig wrote:
> Hi all,
>
> I've addressed most of the issues brought up during the RC1 vote. I'll
> have limited net time the next three days, but hopefully I won't be
> needed.
>
> Stefan
>
> Compress 1.
org.apache.commons.compress.archivers.ar.ArArchiveInputStream#getNextArEntry()
The code to "skip to the next available entry" looks a bit inefficient
because it reads one byte at a time in a loop. Consider using
org.apache.commons.compress.utils.IOUtils.skip(InputStream, long)
Consider using org
org.apache.commons.compress.compressors.lzma.LZMACompressorInputStream#read()
Current: count(ret == -1 ? -1 : 1);
Change: count(ret == -1 ? 0 : 1);
On Mon, Oct 14, 2013 at 12:17 AM, Stefan Bodewig wrote:
> I think enough issues have been identified to warrant a second RC.
>
> I'll take care of t
Just a couple of immediate thoughts (just starting to look things over...)
In SevenZFile.java
Constructor...
1) Close file on exception instead of the current technique of keeping
a "succeeded" flag.
2) Move setting the password to the last line of the constructor so
that it isn't stored if an ex
> Since we now have multiple archivers that require seeking, I suggest
> we add a SeekableStream class or something along those lines. The
> Commons Imaging project also has the same problem to solve for images,
> and it uses ByteSources, which can be arrays, files, or an InputStream
> wrapper that
Benedikt,
You may also following Google's approach. I think it's clever:
"To get help on a specific question or problem, post a question to
Stack Overflow with the tag "guava". We monitor these questions using
this RSS feed."
Clearly, the tag could be "apache-commons." I mean, the tag already
So, I'm fairly new to the world of compression implementations. Is
ZLIB (RFC 1950) supported by the current COMPRESS library? If not,
perhaps we can borrow from APACHE MINA? I see on their "thank you
page" a reference to "Vinod Panicker - Zlib compression."
~BB
Hello,
I am a big fan of the commons VFS and commons compress libraries. I
use them a lot of work and have been real time savers. Having dug
through the code of commons compress, I noticed a big "TODO" comment
about the TarInputStream#skip() method. I have corrected the issue
and the performanc
13 matches
Mail list logo
