Those C libraries are pthread (don't need that in Java as it has its own
thread API) and zlib (pretty standard gz library). With that in mind, this
may be a useful reference: http://www.jcraft.com/jzlib/
On 9 May 2017 at 19:22, sebb wrote:
> AFAICT the implementation is written in C and uses som
I think the question is can/should [Compress] use any of the stock code
in java.util.zip in a multi-threaded fashion for performance gains.
Gary
On Tue, May 9, 2017 at 5:22 PM, sebb wrote:
> AFAICT the implementation is written in C and uses some C libraries.
>
> It would have to be completely
AFAICT the implementation is written in C and uses some C libraries.
It would have to be completely rewritten for Java.
Not a trivial job, though it may be possible to use the algorithm.
On 10 May 2017 at 01:03, Gary Gregory wrote:
> I've not heard of it on the ML yet. Go for it! ;-)
>
> Gary
>
I've not heard of it on the ML yet. Go for it! ;-)
Gary
On Tue, May 9, 2017 at 4:44 PM, Roger Whitcomb
wrote:
> Someone here was doing benchmarks using "pigz" (see here:
> http://zlib.net/pigz/, basically multi-threaded "gzip") and I couldn't
> find any "reasonable" Java implementations. Anyon
Someone here was doing benchmarks using "pigz" (see here:
http://zlib.net/pigz/, basically multi-threaded "gzip") and I couldn't find any
"reasonable" Java implementations. Anyone thought about it for Commons
Compress?
Thanks,
Roger Whitcomb
> If I make the method static and rename it to "gamma", then I can do the
much
> simpler:
> Stream d = numbers.parallelStream().map(Gamma::gamma);
It seems to me like the above, suggested by Stian earlier if I am not
mistaken, is the best option of the ones you have discussed, once you agree
o
GitHub user acoburn opened a pull request:
https://github.com/apache/commons-rdf/pull/37
Minor documentation updates
As can be seen on [this javadoc page](
https://commons.apache.org/proper/commons-rdf/apidocs/org/apache/commons/rdf/api/package-summary.html),
some of the docume
On Tue, 09 May 2017 14:52:09 +0200, Gilles wrote:
> [I specifically avoided "apply" so that it is free for when the
> component
> targets Java 8.]
>
> Can the "apply" method be static?
No, interface implementations can't be static (and it is not possible to
make an interface of static methods).
On Tue, 9 May 2017 13:29:21 +0100, Stian Soiland-Reyes wrote:
> I can only see this "value()" style make sense if there is also a common
> interface, perhaps DoubleFunction?
> https://docs.oracle.com/javase/8/docs/api/java/util/function/DoubleFunction.html
DoubleUnaryOperator would be better - do
On Tue, 9 May 2017 15:19:13 +0100, sebb wrote:
On 9 May 2017 at 14:28, Gilles wrote:
On Tue, 9 May 2017 09:03:13 -0400, Raymond DeCampo wrote:
How does MathJax interact with HTML entities?
Seems that javadoc8 breaks the build even before MathJax has the
chance
to interpret the LaTeX code
On 9 May 2017 at 14:28, Gilles wrote:
> On Tue, 9 May 2017 09:03:13 -0400, Raymond DeCampo wrote:
>>
>> How does MathJax interact with HTML entities?
>
>
> Seems that javadoc8 breaks the build even before MathJax has the chance
> to interpret the LaTeX code.
>
> See this for a more complete answer
Hello,
I'm using the MultiKeyMap implementation for a project but I've realized
that there is no general method for removing a full MultiKey object, but
different and individual keys.
For example, I can remove a key using: MultiKeyMap#removeAll(key1, key2,
key3), but I can't do the same with Mult
On Tue, 9 May 2017 09:03:13 -0400, Raymond DeCampo wrote:
How does MathJax interact with HTML entities?
Seems that javadoc8 breaks the build even before MathJax has the chance
to interpret the LaTeX code.
See this for a more complete answer:
http://docs.mathjax.org/en/latest/tex.html
My L
How does MathJax interact with HTML entities?
My LateX is very rusty - is there a suitable escape sequence (like the \leq
used in other parts of the doc) that could be used instead?
On Tue, May 9, 2017 at 7:17 AM, Gilles wrote:
> On Tue, 09 May 2017 11:09:49 -, st...@apache.org wrote:
>
>>
Hi.
On Tue, 9 May 2017 13:29:21 +0100, Stian Soiland-Reyes wrote:
On Mon, 08 May 2017 14:16:12 +0200, Gilles
wrote:
> Overall the addition looks good and well commented. The javadoc is
a
> bit
> sparse and could do with some more hyperlinks.
Strange; I thought that it was doing rather well on
Hi,
>>> There are some issues reported that come with a proposed fix.>> If you
>>> think that the change is adequate, do not hesitate to
>> apply it. E.g.:
>> https://issues.apache.org/jira/browse/MATH-1381
Done, pull request submitted [1] and merged.
>> Some may be fixed already. If you can
On Mon, 08 May 2017 14:16:12 +0200, Gilles wrote:
> > Overall the addition looks good and well commented. The javadoc is a
> > bit
> > sparse and could do with some more hyperlinks.
> Strange; I thought that it was doing rather well on this point.
> Can you be more specific? [Please open a JIRA r
On Tue, 09 May 2017 11:09:47 -, st...@apache.org wrote:
NUMBERS-36 Alternative CDN for MathJax: CDNJS via CloudFlare
Project: http://git-wip-us.apache.org/repos/asf/commons-numbers/repo
Commit:
http://git-wip-us.apache.org/repos/asf/commons-numbers/commit/b29de0ea
Tree:
http://git-wip-us.
On Tue, 09 May 2017 11:09:49 -, st...@apache.org wrote:
Avoid "malformed HTML" javadoc error
-1
This is not malformed HTML! It is LateX (to be interpreted by
MathJax).
Regards,
Gilles
Project: http://git-wip-us.apache.org/repos/asf/commons-numbers/repo
Commit:
http://git-wip-us.ap
Github user bodewig commented on the issue:
https://github.com/apache/commons-compress/pull/24
@kvr000 what do you think about
https://github.com/apache/commons-compress/commit/620196621e15a87cdd5e3382504bd8a9829f4698
?
---
If your project is set up for it, you can reply to this ema
20 matches
Mail list logo