On Fri, Dec 27, 2019 at 11:36 AM Claude Warren wrote:
> On Fri, Dec 27, 2019 at 1:02 AM Gary Gregory
> wrote:
>
> > Hi Claude and all:
> >
> > Here are a couple of comments on the bloom filter PR.
> >
> > 10,100 ft level comment we do not have to worry about today: Before the
> > release, we
On Fri, Dec 27, 2019 at 8:17 PM wrote:
> This is an automated email from the ASF dual-hosted git repository.
>
> aherbert pushed a commit to branch master
> in repository https://gitbox.apache.org/repos/asf/commons-codec.git
>
>
> The following commit(s) were added to refs/heads/master by this
On Fri, Dec 27, 2019 at 3:18 PM Alex Herbert
wrote:
>
>
> > On 27 Dec 2019, at 16:35, Gary Gregory wrote:
> >
> > Great, TY. Feel free to add more tests if need be. Edge cases and so on.
> >
> > Gary
>
> If you look at the Jacoco report for MurmurHash3 the only line missing
> execution is the
> On 27 Dec 2019, at 16:35, Gary Gregory wrote:
>
> Great, TY. Feel free to add more tests if need be. Edge cases and so on.
>
> Gary
If you look at the Jacoco report for MurmurHash3 the only line missing
execution is the throwing of an AssertionError in a default block of a switch
It's somewhat logical, though, that T[0] is faster than T[size]. In
both cases, the given array is checked to see if it's large enough to
fit the collection contents. If it isn't, then a new array is
allocated. By deferring the new array allocation operation to the
toArray() method call, you avoid
Great, TY. Feel free to add more tests if need be. Edge cases and so on.
Gary
On Fri, Dec 27, 2019 at 10:54 AM Alex Herbert
wrote:
> I'll have a look at this since I rewrote the code and all the tests to fix
> the hash implementation.
>
> Alex
>
> On Fri, 27 Dec 2019, 15:18 Gary Gregory,
On Fri, Dec 27, 2019 at 1:02 AM Gary Gregory wrote:
> Hi Claude and all:
>
> Here are a couple of comments on the bloom filter PR.
>
> 10,100 ft level comment we do not have to worry about today: Before the
> release, we might want to split Commons Collection into a multi-module
> project and
I'll have a look at this since I rewrote the code and all the tests to fix
the hash implementation.
Alex
On Fri, 27 Dec 2019, 15:18 Gary Gregory, wrote:
> Hi Claude,
>
> Is there any way we could get 100% code coverage
> on MurmurHash3$IncrementalHash32x86 ? There is a corner case left
Hi Claude,
Is there any way we could get 100% code coverage
on MurmurHash3$IncrementalHash32x86 ? There is a corner case left untested.
To see the code coverage, look at the JaCoCo report in
target\site\index.html under 'Project Reports' after running 'mvn clean
package site -P jacoco -P
I used Java 8. Using Java >= 9 runs the risk of binding to the wrong
ByteBuffer APIs and causing problems at runtime on Java < 9.
Gary
On Thu, Dec 26, 2019 at 12:38 PM Rob Tompkins wrote:
> +1
>
> I couldn’t get java 11 to fully build the site. I recall that being an
> ongoing problem with
I wonder where this should be documented. We could add a // comment to each
call site, that seems the simplest. Adding a package or component level
documentation in the style guideline for example could easily be overlooked
by someone in a debugger for example. So each call site would be best IMO
Feel free to revert the changes.
I would revert my changes, but Garry did some follow-up changes so these
would to be reverted first.
Am 27.12.2019 um 12:33 schrieb sebb:
As that article says in conclusion, T[0] seems currently faster, but that
may not always be the case with future VMs.
Also
As that article says in conclusion, T[0] seems currently faster, but that
may not always be the case with future VMs.
Also it says that IntelliJ IDEA and PMD recommend using T[size] rather than
T[0].
If we release code with T[0], I suspect we will get complaints that the
code is not efficient
[X] +1 Release these artifacts
Successfully built from tag, and from dist area source, using JDK8 on Ubuntu
LTS.
Reports look good. Inspected a few files picked at random from maven staged
repo and from dist area, all looks good.
Found nothing wrong looking at signatures from maven & dist.
see https://shipilev.net/blog/2016/arrays-wisdom-ancients/
Am 27.12.2019 um 01:24 schrieb sebb:
Also, where is it documented that modern JVMs are faster?
To which JVMs does this apply?
S.
On Thu, 26 Dec 2019 at 22:08, Gary Gregory wrote:
Please do not cause garbage to apparently be
15 matches
Mail list logo
