> On 29 Dec 2019, at 18:39, Gary Gregory wrote:
>
> It depends on the platform you are using, which is the bug. What is most
> important WRT compatibility is the API signature's binary compatibility
> which would be maintained.
>
> As the code is now, a result value is effectively meaningless
It depends on the platform you are using, which is the bug. What is most
important WRT compatibility is the API signature's binary compatibility
which would be maintained.
As the code is now, a result value is effectively meaningless without
knowing the "file.encoding" at the time the value was ge
Changing the getBytes() call will change the operation vs the previous
release. That would be a major release change would it not?
On Sun, Dec 29, 2019 at 4:20 PM Gary Gregory wrote:
> On Sun, Dec 29, 2019 at 10:58 AM Gary Gregory
> wrote:
>
> > The two murmur hash classes call String#getBytes
On Sun, Dec 29, 2019 at 10:58 AM Gary Gregory
wrote:
> The two murmur hash classes call String#getBytes() instead of
> String#getBytes(Charset|String).
>
> This means you can get different results depending on where in the world
> you run the code or by changing the "file.encoding" system propert
The two murmur hash classes call String#getBytes() instead of
String#getBytes(Charset|String).
This means you can get different results depending on where in the world
you run the code or by changing the "file.encoding" system property. I
can't imagine that's the intention here.
Why not use UTF-8
On Sun, Dec 29, 2019 at 4:20 AM Alex Herbert
wrote:
> On Sun, 29 Dec 2019, 01:14 Gary Gregory, wrote:
>
> > It looks like public methods have been removed
> > from org.apache.commons.codec.digest.MurmurHash3$IncrementalHash32, These
> > need to go back in to maintain binary compatibility. Then w
On Sun, 29 Dec 2019, 01:14 Gary Gregory, wrote:
> It looks like public methods have been removed
> from org.apache.commons.codec.digest.MurmurHash3$IncrementalHash32, These
> need to go back in to maintain binary compatibility. Then we can have a
> release candidate.
>
To fix the broken hash imp
It looks like public methods have been removed
from org.apache.commons.codec.digest.MurmurHash3$IncrementalHash32, These
need to go back in to maintain binary compatibility. Then we can have a
release candidate.
Gary
On Fri, Dec 27, 2019 at 7:02 PM Gary Gregory wrote:
> On Fri, Dec 27, 2019 at
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 th
> 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
stateme
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, 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, wrote:
> Hi Claude,
>
> Is there any way we could get 100% code coverage
> on MurmurHash3$IncrementalHash32x86 ? There is a corner case left untested
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 japicmp'
For the contributions and issues I was involved in, the javadoc appear to
be correct.
Claude
On Thu, Dec 26, 2019 at 1:30 PM Gary Gregory wrote:
> It looks like we will need a new version of Commons Codec out before we can
> use new code there from Commons Collections. So now's the time to poli
It looks like we will need a new version of Commons Codec out before we can
use new code there from Commons Collections. So now's the time to polish,
PR, and so on.
If you've contributed code to Codec, please make sure the Javadoc are
helpful and the site up to date.
Thank you!
Gary
15 matches
Mail list logo
