[jira] [Work logged] (IMAGING-241) Copy byte arrays fixing TODO markers
[ https://issues.apache.org/jira/browse/IMAGING-241?focusedWorklogId=344895&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-344895 ] ASF GitHub Bot logged work on IMAGING-241: -- Author: ASF GitHub Bot Created on: 17/Nov/19 06:21 Start Date: 17/Nov/19 06:21 Worklog Time Spent: 10m Work Description: coveralls commented on issue #57: [IMAGING-241] Fix TODO markers for byte arrays URL: https://github.com/apache/commons-imaging/pull/57#issuecomment-554716971 [](https://coveralls.io/builds/27036933) Coverage remained the same at 74.762% when pulling **344597ef946a8bc2b43779e17ba0824aeb969b4d on kinow:todos-commented-code** into **0aa5c81ac02481ff987bf88bcb3d0d73ea198dde on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 344895) Time Spent: 20m (was: 10m) > Copy byte arrays fixing TODO markers > > > Key: IMAGING-241 > URL: https://issues.apache.org/jira/browse/IMAGING-241 > Project: Commons Imaging > Issue Type: Improvement > Components: imaging.* >Affects Versions: 1.0-alpha1 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 20m > Remaining Estimate: 0h > > During the first 1.0 RC vote, several TODO markers were added, noting that we > were returning byte arrays directly to users. Those arrays, if changed, would > invalidate the work done by parsers (can even result in runtime errors once > the array is altered and other methods are called). > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] coveralls commented on issue #57: [IMAGING-241] Fix TODO markers for byte arrays
coveralls commented on issue #57: [IMAGING-241] Fix TODO markers for byte arrays URL: https://github.com/apache/commons-imaging/pull/57#issuecomment-554716971 [](https://coveralls.io/builds/27036933) Coverage remained the same at 74.762% when pulling **344597ef946a8bc2b43779e17ba0824aeb969b4d on kinow:todos-commented-code** into **0aa5c81ac02481ff987bf88bcb3d0d73ea198dde on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Work logged] (IMAGING-241) Copy byte arrays fixing TODO markers
[ https://issues.apache.org/jira/browse/IMAGING-241?focusedWorklogId=344890&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-344890 ] ASF GitHub Bot logged work on IMAGING-241: -- Author: ASF GitHub Bot Created on: 17/Nov/19 06:15 Start Date: 17/Nov/19 06:15 Worklog Time Spent: 10m Work Description: kinow commented on 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 Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking --- Worklog Id: (was: 344890) Remaining Estimate: 0h Time Spent: 10m > Copy byte arrays fixing TODO markers > > > Key: IMAGING-241 > URL: https://issues.apache.org/jira/browse/IMAGING-241 > Project: Commons Imaging > Issue Type: Improvement > Components: imaging.* >Affects Versions: 1.0-alpha1 >Reporter: Bruno P. Kinoshita >Assignee: Bruno P. Kinoshita >Priority: Minor > Fix For: 1.0-alpha2 > > Time Spent: 10m > Remaining Estimate: 0h > > During the first 1.0 RC vote, several TODO markers were added, noting that we > were returning byte arrays directly to users. Those arrays, if changed, would > invalidate the work done by parsers (can even result in runtime errors once > the array is altered and other methods are called). > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-imaging] kinow opened a new pull request #57: [IMAGING-241] Fix TODO markers for byte arrays
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 Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Created] (IMAGING-241) Copy byte arrays fixing TODO markers
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 Issue Type: Improvement Components: imaging.* Affects Versions: 1.0-alpha1 Reporter: Bruno P. Kinoshita Assignee: Bruno P. Kinoshita Fix For: 1.0-alpha2 During the first 1.0 RC vote, several TODO markers were added, noting that we were returning byte arrays directly to users. Those arrays, if changed, would invalidate the work done by parsers (can even result in runtime errors once the array is altered and other methods are called). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-codec] aherbert commented on issue #27: Murmur3fix
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 method name for the same computation. Can you remove all the underscores from the method names please. That is not Java standard. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (VFS-617) isReadable fails if unable to determine group identity
[ https://issues.apache.org/jira/browse/VFS-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16975857#comment-16975857 ] Bernd Eckenfels commented on VFS-617: - Vineet, I would assume the simplest way to avoid this problem is to not use the isReadable method in this context. I don’t see in the stacktrace who is actually calling it, but if it is your code, just don’t do it. > isReadable fails if unable to determine group identity > -- > > Key: VFS-617 > URL: https://issues.apache.org/jira/browse/VFS-617 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 > Environment: Windows 7 Java 7. Failure occured connecting via SFTP to > a Synology box running DSM 6. >Reporter: Tim Nickels >Priority: Major > > The doIsReadable method of SftpFileObject throws an exception if the system > cannot identify group/owner permissions... > Exception in thread "main" org.apache.commons.vfs2.FileSystemException: Could > not determine if file "sftp://myURI"; is readable. > at > org.apache.commons.vfs2.provider.AbstractFileObject.isReadable(AbstractFileObject.java:1761) > at com.avenca.vfs.VFSUtils.main(VFSUtils.java:41) > Caused by: com.jcraft.jsch.JSchException: Could not get the groups id of the > current user (error code: 1) > at > org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getGroupsIds(SftpFileSystem.java:263) > at > org.apache.commons.vfs2.provider.sftp.SftpFileObject.getPermissions(SftpFileObject.java:317) > at > org.apache.commons.vfs2.provider.sftp.SftpFileObject.doIsReadable(SftpFileObject.java:335) > at > org.apache.commons.vfs2.provider.AbstractFileObject.isReadable(AbstractFileObject.java:1757) > The problem is the method is using > return getPermissions(true).isReadable() > The folder *is* readable without these permissions, and so should be set to > return getPermissions(false).isReadable() > Which correctly allows the system to identify a readable folder without > adding unnecessary restrictions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (VFS-617) isReadable fails if unable to determine group identity
[ https://issues.apache.org/jira/browse/VFS-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16975846#comment-16975846 ] Vineet Tyagi commented on VFS-617: -- [~nimlhug] Thanks a lot for your reply. It seems then it will not be working if someone tries to connect to sftp server at windows environment. But it seems very strange that no one complained about it. Are you aware if there is any workaround like any other library updates (jsch) for 2.4.1 or something else that it might work? Thanks Vineet > isReadable fails if unable to determine group identity > -- > > Key: VFS-617 > URL: https://issues.apache.org/jira/browse/VFS-617 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 > Environment: Windows 7 Java 7. Failure occured connecting via SFTP to > a Synology box running DSM 6. >Reporter: Tim Nickels >Priority: Major > > The doIsReadable method of SftpFileObject throws an exception if the system > cannot identify group/owner permissions... > Exception in thread "main" org.apache.commons.vfs2.FileSystemException: Could > not determine if file "sftp://myURI"; is readable. > at > org.apache.commons.vfs2.provider.AbstractFileObject.isReadable(AbstractFileObject.java:1761) > at com.avenca.vfs.VFSUtils.main(VFSUtils.java:41) > Caused by: com.jcraft.jsch.JSchException: Could not get the groups id of the > current user (error code: 1) > at > org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getGroupsIds(SftpFileSystem.java:263) > at > org.apache.commons.vfs2.provider.sftp.SftpFileObject.getPermissions(SftpFileObject.java:317) > at > org.apache.commons.vfs2.provider.sftp.SftpFileObject.doIsReadable(SftpFileObject.java:335) > at > org.apache.commons.vfs2.provider.AbstractFileObject.isReadable(AbstractFileObject.java:1757) > The problem is the method is using > return getPermissions(true).isReadable() > The folder *is* readable without these permissions, and so should be set to > return getPermissions(false).isReadable() > Which correctly allows the system to identify a readable folder without > adding unnecessary restrictions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[GitHub] [commons-codec] coveralls edited a comment on issue #27: Murmur3fix
coveralls edited a comment on issue #27: Murmur3fix URL: https://github.com/apache/commons-codec/pull/27#issuecomment-549122650 [](https://coveralls.io/builds/27033051) Coverage increased (+0.3%) to 93.067% when pulling **22fe0bdf2c3b18a97144305b2254dd11755f9be1 on Claudenw:murmur3fix** into **8b206b53077999a6d180ed1f4d1daa57523eda04 on apache:master**. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-codec] Claudenw commented on issue #27: Murmur3fix
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. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-codec] aherbert commented on issue #27: Murmur3fix
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. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-codec] Claudenw commented on issue #27: Murmur3fix
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, final int
length, final int seed) {
return hash32_x86( data, offset, length, seed );
}
The incremental hash test no longer passes. it fails with
java.lang.AssertionError: Block size 1 expected:<2094498084> but
was:<2002902189>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at
org.apache.commons.codec.digest.MurmurHash3Test.testIncremental(MurmurHash3Test.java:176)
.
.
.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [commons-codec] Claudenw commented on issue #27: Murmur3fix
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). (code can be coalesced around one implementation with hash32() delegating to hash32_x86() calls. hash128 is broken. However there are probably users that can not change from the broken implementation. I think it is the Cassandra project has the same issue and has elected not to change their hash as it breaks all the existing data sets. So hash128 deprecated with a note indicating the error in the code so that users can decide if they need to retain the broken one or not. I will make the changes for Hash32() to call hash30_x86 methods. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [commons-codec] aherbert commented on issue #27: Murmur3fix
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 method and delegate calls to a single implementation to eliminate
code duplication.
For the hash128x64 method this seems to be the easy solution:
```
// Current
public static long[] hash128(final byte[] data, final int offset, final int
length, final int seed) {
return hash128x64(data, offset, length, seed, seed);
}
// New
public static long[] hash128x64(final byte[] data, final int offset, final
int length, final int seed) {
return hash128x64(data, offset, length, seed & 0xL, seed &
0xL);
}
// Single implementation
private static long[] hash128x64(final byte[] data, final int offset, final
int length,
final long h1, final long h2) {
...
```
Would that work?
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] [commons-codec] Claudenw commented on issue #27: Murmur3fix
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 Seeley and the tests that go with it. I duplicated the existing 128 bit tests calling the new 128 hash and and renamed them with "_x86" in the middle (e.g. test128_Double became test128_x64_Double) to verify that all the old tests passed the new hash. The "testCorrectValues_x64" (which I now realize is misnamed) verifies that the 32_x86 and 128_x64 return the expected results when compared with the results of the original "C" implementation. If you modify the testCorrectValues_x86 code to call the original hash32 and hash128 version you will see that the 128 version fails because of the sign extension that occurs early in the process. (This is what I showed in the original bug) The effective change is at lines 1047 and 1048. I provided new names for the standard hash methods as there are x86 and x64 versions of the hashes and they do **not** produce the same values. The change of Hash32 to Hash32_x86 makes it clear which hash it is. The change from Hash128 to Hash128_x64 does the same. While the old Hash128 is incorrectly implemented it has been released and is in the wild, so we have to expect that some uses of the hash128 function can not change to hash128_x64. To this end the hash128 functions are deprecated (but will probably not be removed) and new implementations are expected to use the hash128_x64 version. The Hash32 methods are deprecated to refer to the new names. Given that the code returns the same values one of the implementations could be removed and just call the other. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Commented] (VFS-617) isReadable fails if unable to determine group identity
[ https://issues.apache.org/jira/browse/VFS-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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 never accepted because of a bunch of nitpicking. I'm not putting in the work again. > isReadable fails if unable to determine group identity > -- > > Key: VFS-617 > URL: https://issues.apache.org/jira/browse/VFS-617 > Project: Commons VFS > Issue Type: Bug >Affects Versions: 2.1 > Environment: Windows 7 Java 7. Failure occured connecting via SFTP to > a Synology box running DSM 6. >Reporter: Tim Nickels >Priority: Major > > The doIsReadable method of SftpFileObject throws an exception if the system > cannot identify group/owner permissions... > Exception in thread "main" org.apache.commons.vfs2.FileSystemException: Could > not determine if file "sftp://myURI"; is readable. > at > org.apache.commons.vfs2.provider.AbstractFileObject.isReadable(AbstractFileObject.java:1761) > at com.avenca.vfs.VFSUtils.main(VFSUtils.java:41) > Caused by: com.jcraft.jsch.JSchException: Could not get the groups id of the > current user (error code: 1) > at > org.apache.commons.vfs2.provider.sftp.SftpFileSystem.getGroupsIds(SftpFileSystem.java:263) > at > org.apache.commons.vfs2.provider.sftp.SftpFileObject.getPermissions(SftpFileObject.java:317) > at > org.apache.commons.vfs2.provider.sftp.SftpFileObject.doIsReadable(SftpFileObject.java:335) > at > org.apache.commons.vfs2.provider.AbstractFileObject.isReadable(AbstractFileObject.java:1757) > The problem is the method is using > return getPermissions(true).isReadable() > The folder *is* readable without these permissions, and so should be set to > return getPermissions(false).isReadable() > Which correctly allows the system to identify a readable folder without > adding unnecessary restrictions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (JEXL-307) Variable redeclaration option
[
https://issues.apache.org/jira/browse/JEXL-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16975645#comment-16975645
]
Henri Biestro commented on JEXL-307:
I may be missing your actual question but just because the lexical feature is
not equivalent to the lexical option.
Having seen many very heavy scripts (>2000 lines) and the most common source of
bugs, any _brand new_ solution using scripts should use the lexical feature and
"+lexical +lexicalShade -safe +strict" options IMHO.
The lexical feature throws a *parsing* exception when a variable is redeclared
whilst the lexical option throws exceptions at *execution* time (and that
option can be enabled/disabled at will through the jexl.options pragma). If
scripts are created before being used, the former fails at construction time -
and may prevent a whole app to start -, the latter at runtime - which may fail
some operation of that same app.
Considering any _existing_ solution using scripts, a smooth migration towards
using 3.2 safer scripting capabilities and the implied refactoring needs to be
achievable one script at a time; the current JEXL-307 implementation fits that
purpose.
(Production, migration, upgrade, support, legacy, resilience, stability...
burden vectors :))
> Variable redeclaration option
> -
>
> Key: JEXL-307
> URL: https://issues.apache.org/jira/browse/JEXL-307
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Dmitri Blinov
>Assignee: Henri Biestro
>Priority: Minor
> Fix For: 3.2
>
>
> As of now, JEXL allows a script writer to redeclare a local variable during
> script evaluation.
> {code:java}
> var a = 1; var a = 2;{code}
> This may lead to potential errors with misspelled names and clashed
> variables. Checking for already defined variable is a common feature of many
> languages. This feature can be implemented in JEXL as an additional option of
> JexlFeatures class, enabled by default, thus allowing compatibility with
> existing code.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (CONFIGURATION-770) Parse multiline values in INI files
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 Configuration Issue Type: Improvement Components: Format Affects Versions: 2.6 Reporter: Thomas Francart >From my test it looks like multiline values in INI files are not supported by >commons-configuration2. I need to parse files like this one : >[https://github.com/glottolog/glottolog/blob/master/languoids/tree/abin1243/md.ini], > and if I access configuration entry like "glottolog" on line 19 I am getting >an empty string since the values are on the following lines. ConfigParser in Python does support multiline values : [https://docs.python.org/3/library/configparser.html] (if they have one extra indentation compared to the line with the key). See this discussion on the mailing-list : https://mail-archives.apache.org/mod_mbox/commons-user/201911.mbox/%3C806464075.685871.1573878589303%40mail.yahoo.com%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
