coveralls commented on issue #57: [IMAGING-241] Fix TODO markers for byte arrays
URL: https://github.com/apache/commons-imaging/pull/57#issuecomment-554716971
[![Coverage
Status](https://coveralls.io/builds/27036933/badge)](https://coveralls.io/builds/27036933)
Coverage remained
[
https://issues.apache.org/jira/browse/IMAGING-241?focusedWorklogId=344890=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-344890
]
ASF GitHub Bot logged work on IMAGING-241:
--
Author: ASF GitHub Bot
kinow opened a new pull request #57: [IMAGING-241] Fix TODO markers for byte
arrays
URL: https://github.com/apache/commons-imaging/pull/57
Also removing some commented code.
This is an automated message from the Apache Git
Bruno P. Kinoshita created IMAGING-241:
--
Summary: Copy byte arrays fixing TODO markers
Key: IMAGING-241
URL: https://issues.apache.org/jira/browse/IMAGING-241
Project: Commons Imaging
aherbert commented on issue #27: Murmur3fix
URL: https://github.com/apache/commons-codec/pull/27#issuecomment-554695584
No need for a replacement class for IncrementalHash32. Only the `end()`
method of the class should be deprecated. You can just add `hash32x86()` to
match the static
[
https://issues.apache.org/jira/browse/VFS-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975857#comment-16975857
]
Bernd Eckenfels commented on VFS-617:
-
Vineet, I would assume the simplest way to avoid this problem is
[
https://issues.apache.org/jira/browse/VFS-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975846#comment-16975846
]
Vineet Tyagi commented on VFS-617:
--
[~nimlhug] Thanks a lot for your reply. It seems then it will not be
coveralls edited a comment on issue #27: Murmur3fix
URL: https://github.com/apache/commons-codec/pull/27#issuecomment-549122650
[![Coverage
Status](https://coveralls.io/builds/27033051/badge)](https://coveralls.io/builds/27033051)
Coverage increased (+0.3%) to 93.067% when
Claudenw commented on issue #27: Murmur3fix
URL: https://github.com/apache/commons-codec/pull/27#issuecomment-554660483
and the 128 has a sign extension issue at the start where the original does
not use a UINT_MASK., so both implementations have the error.
aherbert commented on issue #27: Murmur3fix
URL: https://github.com/apache/commons-codec/pull/27#issuecomment-554656219
The hash32 method is the one with the sign extension error in the
finalisation of any remaining bytes. It does not mask the byte with 0xff before
the left shift.
Claudenw commented on issue #27: Murmur3fix
URL: https://github.com/apache/commons-codec/pull/27#issuecomment-554652989
There must be a difference between hash32 and hash32_x86 because when I
change hash32() to
public static int hash32(final byte[] data, final int offset,
Claudenw commented on issue #27: Murmur3fix
URL: https://github.com/apache/commons-codec/pull/27#issuecomment-554651103
I think you have it backwards. hash32 is not broken.
hash32 -> hash32_x64 to indicate the implementation in the name (deprecate
hash32 infavor of the new name).
aherbert commented on issue #27: Murmur3fix
URL: https://github.com/apache/commons-codec/pull/27#issuecomment-554649535
In the case of hash32 I would deprecate those that are known to be broken
but not the ones that are not (i.e. the convenience methods). Then provide the
new hash32x86
Claudenw commented on issue #27: Murmur3fix
URL: https://github.com/apache/commons-codec/pull/27#issuecomment-554630047
The 128 bit was broken, the 32 bit was not, the 64 bit is not covered in the
original murmurhash implementation.
I brought across the implementation from Yonik
[
https://issues.apache.org/jira/browse/VFS-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975655#comment-16975655
]
Nim Lhûg commented on VFS-617:
--
I wrote a patch and created a PR that fixed this issue two years ago. It was
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16975645#comment-16975645
]
Henri Biestro commented on JEXL-307:
I may be missing your actual question but just because the lexical
Thomas Francart created CONFIGURATION-770:
-
Summary: Parse multiline values in INI files
Key: CONFIGURATION-770
URL: https://issues.apache.org/jira/browse/CONFIGURATION-770
Project: Commons
17 matches
Mail list logo