[jira] [Resolved] (PROXY-29) plugins.netbeans.org is unreachable
[ https://issues.apache.org/jira/browse/PROXY-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved PROXY-29. --- Resolution: Invalid This is nothing to do with Commons Proxy > plugins.netbeans.org is unreachable > --- > > Key: PROXY-29 > URL: https://issues.apache.org/jira/browse/PROXY-29 > Project: Commons Proxy > Issue Type: Bug >Reporter: Janos Boldoczki >Priority: Major > > I can't activate or download any plugins, because I always get "network > connection problem" messages. > Looks like it's down: plugins.netbeans.org > I have tried to reach it from many devices with different internet > connections - also from a different country (by a windows server) - nothing. > Could you please fix it? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLI-295) Does commons-cli support the confirmation(ask user again):yes/no ?
[ https://issues.apache.org/jira/browse/CLI-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CLI-295. -- Resolution: Information Provided No, CLI parses command line arguments only. I/O is out of scope. In future, please ask such questions on the Commons user list, where you are likely to get a faster response. > Does commons-cli support the confirmation(ask user again):yes/no ? > -- > > Key: CLI-295 > URL: https://issues.apache.org/jira/browse/CLI-295 > Project: Commons CLI > Issue Type: Wish >Reporter: maoling >Priority: Major > > e.g: > [zk: 127.0.0.1:2180(CONNECTED) 0] snapshot > Are you sure to exec:snapshot [yes/no] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (COLLECTIONS-716) Don't include email address in Exception messages
[ https://issues.apache.org/jira/browse/COLLECTIONS-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16866050#comment-16866050 ] Sebb commented on COLLECTIONS-716: -- Fixed LRUMap: cb57e04 COLLECTIONS-716 Don't include email address in Exception messages > Don't include email address in Exception messages > - > > Key: COLLECTIONS-716 > URL: https://issues.apache.org/jira/browse/COLLECTIONS-716 > Project: Commons Collections > Issue Type: Bug >Reporter: Sebb >Priority: Major > > There are several messages in LRUMap which reference dev@commons. > These need to be replaced, see: > https://lists.apache.org/thread.html/5c3805daf30768034ae18576b7275b0535b4e5aec839cd13de2103c1@%3Cdev.commons.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CODEC-254) ColognePhonetic does not treat the letter H correctly
[ https://issues.apache.org/jira/browse/CODEC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary Gregory updated CODEC-254: --- Summary: ColognePhonetic does not treat the letter H correctly (was: ColognePhonetic does not treat the letter H correct) > ColognePhonetic does not treat the letter H correctly > - > > Key: CODEC-254 > URL: https://issues.apache.org/jira/browse/CODEC-254 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.12 >Reporter: Holger Grote >Priority: Major > > With the fix in CODEC-250 the letter H is not treaten correct any more. > A String 'shch' is coded as 8 and not as 84. (This string is sometimes in > foreign surnames) > The reasen is the letter h is ignored completely and not stored in the > lastChar anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (STATISTICS-18) Information relevant to STATISTICS-7
[ https://issues.apache.org/jira/browse/STATISTICS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Virendra Singh updated STATISTICS-18: - Description: +*Relevant Jira issues:*+ * Percentile computational accuracy issue https://issues.apache.org/jira/browse/MATH-1491 was: *Relevant Jira issues:* * Percentile computational accuracy issue https://issues.apache.org/jira/browse/MATH-1491 > Information relevant to STATISTICS-7 > - > > Key: STATISTICS-18 > URL: https://issues.apache.org/jira/browse/STATISTICS-18 > Project: Apache Commons Statistics > Issue Type: Sub-task >Reporter: Virendra Singh >Priority: Blocker > > +*Relevant Jira issues:*+ > * Percentile computational accuracy issue > https://issues.apache.org/jira/browse/MATH-1491 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (STATISTICS-18) Information relevant to STATISTICS-7
[ https://issues.apache.org/jira/browse/STATISTICS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Virendra Singh updated STATISTICS-18: - Summary: Information relevant to STATISTICS-7 (was: Relevant Information) > Information relevant to STATISTICS-7 > - > > Key: STATISTICS-18 > URL: https://issues.apache.org/jira/browse/STATISTICS-18 > Project: Apache Commons Statistics > Issue Type: Sub-task >Reporter: Virendra Singh >Priority: Blocker > > *Relevant Jira issues:* > * Percentile computational accuracy issue > https://issues.apache.org/jira/browse/MATH-1491 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (STATISTICS-18) Relevant Information
Virendra Singh created STATISTICS-18: Summary: Relevant Information Key: STATISTICS-18 URL: https://issues.apache.org/jira/browse/STATISTICS-18 Project: Apache Commons Statistics Issue Type: Sub-task Reporter: Virendra Singh *Relevant Jira issues:* * Percentile computational accuracy issue https://issues.apache.org/jira/browse/MATH-1491 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-rng] aherbert opened a new pull request #52: RNG-100: Add a GuideTableDiscreteSampler.
aherbert opened a new pull request #52: RNG-100: Add a GuideTableDiscreteSampler. URL: https://github.com/apache/commons-rng/pull/52 This can sample from any distribution defined by an array of probabilities. 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] [Updated] (BCEL-321) Subclasses of ClassPathRepository only differ by its underlying cache?
[ https://issues.apache.org/jira/browse/BCEL-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-321: - Description: (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) BCEL has different ClassPathRepository classes with slight modification in its underlying cache: * ClassPathRepository uses HashMap for JavaClass cache * MemorySensitiveClassPathRepository uses HashMap * New LruCacheClassPathRepository by BCEL-320 will use LinkedHashMap for JavaClass cache The logic of loadClass, storeClass, and findClass methods are almost same (attached screenshot of ClassPathRepository and MemorySensitiveClassPathRepository as below). I think they can leverage an abstraction over the internal cache so that they will have less duplicate code. After BCEL-320, I'm thinking to create a PR for the abstraction. !classpathrepository_code_duplicate.png! was: (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) BCEL has different ClassPathRepository classes with slight modification in its underlying cache: * ClassPathRepository uses HashMap for JavaClass cache * MemorySensitiveClassPathRepository uses HashMap * New LruCacheClassPathRepository by BCEL-320 will use LinkedHashMap for JavaClass cache The logic of loadClass, storeClass, and findClass methods are almost same (attached screenshot of ClassPathRepository and MemorySensitiveClassPathRepository as !classpathrepository_code_duplicate.png! ). I think they can leverage an abstraction over the internal cache so that they will have less duplicate code. After BCEL-320, I'm thinking to create a PR for the abstraction. > Subclasses of ClassPathRepository only differ by its underlying cache? > -- > > Key: BCEL-321 > URL: https://issues.apache.org/jira/browse/BCEL-321 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > Attachments: classpathrepository_code_duplicate.png > > > (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) > BCEL has different ClassPathRepository classes with slight modification in > its underlying cache: > * ClassPathRepository uses HashMap for JavaClass cache > * MemorySensitiveClassPathRepository uses HashMap SoftReference > * New LruCacheClassPathRepository by BCEL-320 will use LinkedHashMap JavaClass> for JavaClass cache > The logic of loadClass, storeClass, and findClass methods are almost same > (attached screenshot of ClassPathRepository and > MemorySensitiveClassPathRepository as below). I think they can leverage an > abstraction over the internal cache so that they will have less duplicate > code. > After BCEL-320, I'm thinking to create a PR for the abstraction. > !classpathrepository_code_duplicate.png! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BCEL-321) Subclasses of ClassPathRepository only differ by its underlying cache?
[ https://issues.apache.org/jira/browse/BCEL-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-321: - Description: (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) BCEL has different ClassPathRepository classes with slight modification in its underlying cache: * ClassPathRepository uses HashMap for JavaClass cache * MemorySensitiveClassPathRepository uses HashMap * New LruCacheClassPathRepository by BCEL-320 will use LinkedHashMap for JavaClass cache The logic of loadClass, storeClass, and findClass methods are almost same (attached screenshot of ClassPathRepository and MemorySensitiveClassPathRepository as !classpathrepository_code_duplicate.png! ). I think they can leverage an abstraction over the internal cache so that they will have less duplicate code. After BCEL-320, I'm thinking to create a PR for the abstraction. was: (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) BCEL has different ClassPathRepository classes with slight modification in its underlying cache: * ClassPathRepository uses HashMap for JavaClass cache * MemorySensitiveClassPathRepository uses HashMap * New LruCacheClassPathRepository by BCEL-320 will use LinkedHashMap for JavaClass cache The logic of loadClass, storeClass, and findClass methods are almost same (attached screenshot of ClassPathRepository and MemorySensitiveClassPathRepository as ). I think they can leverage an abstraction over the internal cache so that they will have less duplicate code. After BCEL-320, I'm thinking to create a PR for the abstraction. > Subclasses of ClassPathRepository only differ by its underlying cache? > -- > > Key: BCEL-321 > URL: https://issues.apache.org/jira/browse/BCEL-321 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > Attachments: classpathrepository_code_duplicate.png > > > (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) > BCEL has different ClassPathRepository classes with slight modification in > its underlying cache: > * ClassPathRepository uses HashMap for JavaClass cache > * MemorySensitiveClassPathRepository uses HashMap SoftReference > * New LruCacheClassPathRepository by BCEL-320 will use LinkedHashMap JavaClass> for JavaClass cache > The logic of loadClass, storeClass, and findClass methods are almost same > (attached screenshot of ClassPathRepository and > MemorySensitiveClassPathRepository as > !classpathrepository_code_duplicate.png! ). I think they can leverage an > abstraction over the internal cache so that they will have less duplicate > code. > After BCEL-320, I'm thinking to create a PR for the abstraction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BCEL-321) Subclasses of ClassPathRepository only differ by its underlying cache?
[ https://issues.apache.org/jira/browse/BCEL-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-321: - Description: (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) BCEL has different ClassPathRepository classes with slight modification in its underlying cache: * ClassPathRepository uses HashMap for JavaClass cache * MemorySensitiveClassPathRepository uses HashMap * New LruCacheClassPathRepository by BCEL-320 will use LinkedHashMap for JavaClass cache The logic of loadClass, storeClass, and findClass methods are almost same (attached screenshot of ClassPathRepository and MemorySensitiveClassPathRepository as ). I think they can leverage an abstraction over the internal cache so that they will have less duplicate code. After BCEL-320, I'm thinking to create a PR for the abstraction. was: (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) BCEL has different ClassPathRepository classes with slight modification in its underlying cache: * ClassPathRepository uses HashMap for JavaClass cache * MemorySensitiveClassPathRepository uses HashMap * BCEL-320 will use LinkedHashMap for JavaClass cache The logic of loadClass, storeClass, and findClass methods are almost same. I think they can leverage an abstraction over the internal cache so that they will have less duplicate code. After BCEL-320, I'm thinking to create a PR for the abstraction. > Subclasses of ClassPathRepository only differ by its underlying cache? > -- > > Key: BCEL-321 > URL: https://issues.apache.org/jira/browse/BCEL-321 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > Attachments: classpathrepository_code_duplicate.png > > > (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) > BCEL has different ClassPathRepository classes with slight modification in > its underlying cache: > * ClassPathRepository uses HashMap for JavaClass cache > * MemorySensitiveClassPathRepository uses HashMap SoftReference > * New LruCacheClassPathRepository by BCEL-320 will use LinkedHashMap JavaClass> for JavaClass cache > The logic of loadClass, storeClass, and findClass methods are almost same > (attached screenshot of ClassPathRepository and > MemorySensitiveClassPathRepository as ). I think they can leverage an > abstraction over the internal cache so that they will have less duplicate > code. > After BCEL-320, I'm thinking to create a PR for the abstraction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BCEL-321) Subclasses of ClassPathRepository only differ by its underlying cache?
[ https://issues.apache.org/jira/browse/BCEL-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-321: - Description: (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) BCEL has different ClassPathRepository classes with slight modification in its underlying cache: * ClassPathRepository uses HashMap for JavaClass cache * MemorySensitiveClassPathRepository uses HashMap * BCEL-320 will use LinkedHashMap for JavaClass cache The logic of loadClass, storeClass, and findClass methods are almost same. I think they can leverage an abstraction over the internal cache so that they will have less duplicate code. After BCEL-320, I'm thinking to create a PR for the abstraction. was: (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) BCEL has different ClassPathRepository classes with slight modification in its underlying cache: * ClassPathRepository uses HashMap for JavaClass cache * MemorySensitiveClassPathRepository uses HashMap * BCEL-320 will use LinkedHashMap for JavaClass cache I think they can leverage an abstraction over the internal cache. After BCEL-320, I'm thinking to create a PR for the abstraction. > Subclasses of ClassPathRepository only differ by its underlying cache? > -- > > Key: BCEL-321 > URL: https://issues.apache.org/jira/browse/BCEL-321 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > Attachments: classpathrepository_code_duplicate.png > > > (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) > BCEL has different ClassPathRepository classes with slight modification in > its underlying cache: > * ClassPathRepository uses HashMap for JavaClass cache > * MemorySensitiveClassPathRepository uses HashMap SoftReference > * BCEL-320 will use LinkedHashMap for JavaClass cache > The logic of loadClass, storeClass, and findClass methods are almost same. I > think they can leverage an abstraction over the internal cache so that they > will have less duplicate code. > After BCEL-320, I'm thinking to create a PR for the abstraction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BCEL-321) Subclasses of ClassPathRepository only differ by its underlying cache?
[ https://issues.apache.org/jira/browse/BCEL-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-321: - Attachment: classpathrepository_code_duplicate.png > Subclasses of ClassPathRepository only differ by its underlying cache? > -- > > Key: BCEL-321 > URL: https://issues.apache.org/jira/browse/BCEL-321 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > Attachments: classpathrepository_code_duplicate.png > > > (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) > BCEL has different ClassPathRepository classes with slight modification in > its underlying cache: > * ClassPathRepository uses HashMap for JavaClass cache > * MemorySensitiveClassPathRepository uses HashMap SoftReference > * BCEL-320 will use LinkedHashMap for JavaClass cache > I think they can leverage an abstraction over the internal cache. > After BCEL-320, I'm thinking to create a PR for the abstraction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-compress] coveralls commented on issue #81: Performance Improvement: Call toArray with 0 Array Size
coveralls commented on issue #81: Performance Improvement: Call toArray with 0 Array Size URL: https://github.com/apache/commons-compress/pull/81#issuecomment-502826329 [](https://coveralls.io/builds/24046367) Coverage increased (+0.02%) to 86.59% when pulling **f925a0c62a74199b0869614f7a266297af26dc3b on DaGeRe:master** into **1e9c8fd34c69b5a7f107c40fb4203b3b74946634 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-compress] DaGeRe opened a new pull request #81: Performance Improvement: Call toArray with 0 Array Size
DaGeRe opened a new pull request #81: Performance Improvement: Call toArray with 0 Array Size URL: https://github.com/apache/commons-compress/pull/81 Since Java 6, calling toArray with an array of size is faster than calling it with the size of the array (https://shipilev.net/blog/2016/arrays-wisdom-ancients/). This is also a PMD recommendation: https://pmd.github.io/latest/pmd_rules_java_performance.html#optimizabletoarraycall I changed this in the 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] [Commented] (JEXL-253) Permissions by super type in JexlSandbox
[
https://issues.apache.org/jira/browse/JEXL-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865874#comment-16865874
]
Woonsan Ko commented on JEXL-253:
-
(y)
Thank you so much!
> Permissions by super type in JexlSandbox
>
>
> Key: JEXL-253
> URL: https://issues.apache.org/jira/browse/JEXL-253
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Woonsan Ko
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> At the moment, the permissions in {{JexlSandbox}} takes the object's class
> name only into the consideration. So, if someone adds {{java.util.Set}} into
> the white list, but if the real object is an empty set
> ({{Collections.emptySet()}}), then it cannot allow invocations on
> {{#contains(Object)}} operation, for instance.
> I think it would be very convenient if it optionally allows to set whites or
> blacks based on super type (interfaces or base classes).
> To minimize the effort, I'd suggest adding
> {{JexlSandbox#permissionsByType(Class type, ...)}}, where the {{type}}
> means the object type or any super types.
> So, if {{JexlSandbox#permissionsByType(java.util.Set.class, ...)}}, then any
> invocations on any concrete {{java.util.Set}} objects will be affected by
> that.
> Related e-mail thread: "[JEXL] white list classes, not by interfaces?"
> (10/19/17).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (CODEC-254) ColognePhonetic does not treat the letter H correct
[ https://issues.apache.org/jira/browse/CODEC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CODEC-254. Resolution: Fixed 4f8662a CODEC-254 - ColognePhonetic does not treat the letter H correct > ColognePhonetic does not treat the letter H correct > --- > > Key: CODEC-254 > URL: https://issues.apache.org/jira/browse/CODEC-254 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.12 >Reporter: Holger Grote >Priority: Major > > With the fix in CODEC-250 the letter H is not treaten correct any more. > A String 'shch' is coded as 8 and not as 84. (This string is sometimes in > foreign surnames) > The reasen is the letter h is ignored completely and not stored in the > lastChar anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BCEL-320) A new ClassPathRepository that can scan many JAR files without OutOfMemoryError
[ https://issues.apache.org/jira/browse/BCEL-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-320: - Description: (This ticket is derivation from [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], which I found creating ConstantUtf8 cache is not straightforward under current ClassPathRepository design.) We use BCEL library in https://github.com/GoogleCloudPlatform/cloud-opensource-java . Thank you for great library. h1. Background Our use of BCEL ClassPathRepository and MemorySensitiveClassPathRepository causes OutOfMemoryError when they scan many (~200) JAR files. Initially I thought this problem could be fixed by [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], but it turned out that it's not straightforward under current design. Instead of focusing on ConstantUtf8, I decided to use my own custom ClassPathRepository that uses LRU cache internally to hold JavaClass instances. It worked. This ticket is to contribute the idea to BCEL library so that other users can benefit from it. h1. Test Case This GitHub project is a example of OutOfMemoryError caused by scanning many JAR files using BCEL ClassPathRepository and MemorySensitiveClassPathRepository: https://github.com/suztomo/bcel-oome-example was: (This ticket is derivation from [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], which I found creating ConstantUtf8 cache is not straightforward under current ClassPathRepository design.) We use BCEL library in https://github.com/GoogleCloudPlatform/cloud-opensource-java . Thank you for great library. h1. Background Our use of BCEL ClassPathRepository and MemorySensitiveClassPathRepository causes OutOfMemoryError when they scan many (~200) JAR files. Initially I thought this problem could be fixed by [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], but it turned out that it's not straightforward under current design. Instead of focusing on ConstantUtf8, I decided to use my own custom ClassPathRepository that uses LRU cache internally to hold JavaClass instances. It worked. This ticket is to contribute the idea to BCEL library so that other users can benefit from it. h1. Test Case https://github.com/suztomo/bcel-oome-example > A new ClassPathRepository that can scan many JAR files without > OutOfMemoryError > --- > > Key: BCEL-320 > URL: https://issues.apache.org/jira/browse/BCEL-320 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > > (This ticket is derivation from > [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], which I found > creating ConstantUtf8 cache is not straightforward under current > ClassPathRepository design.) > We use BCEL library in > https://github.com/GoogleCloudPlatform/cloud-opensource-java . Thank you for > great library. > h1. Background > Our use of BCEL ClassPathRepository and MemorySensitiveClassPathRepository > causes OutOfMemoryError when they scan many (~200) JAR files. Initially I > thought this problem could be fixed by > [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], but it turned out > that it's not straightforward under current design. Instead of focusing on > ConstantUtf8, I decided to use my own custom ClassPathRepository that uses > LRU cache internally to hold JavaClass instances. It worked. > This ticket is to contribute the idea to BCEL library so that other users can > benefit from it. > h1. Test Case > This GitHub project is a example of OutOfMemoryError caused by scanning many > JAR files using BCEL ClassPathRepository and > MemorySensitiveClassPathRepository: > https://github.com/suztomo/bcel-oome-example -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BCEL-320) A new ClassPathRepository that can scan many JAR files without OutOfMemoryError
[ https://issues.apache.org/jira/browse/BCEL-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-320: - Description: (This ticket is derivation from [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], which I found creating ConstantUtf8 cache is not straightforward under current ClassPathRepository design.) We use BCEL library in https://github.com/GoogleCloudPlatform/cloud-opensource-java . Thank you for great library. h1. Background Our use of BCEL ClassPathRepository and MemorySensitiveClassPathRepository causes OutOfMemoryError when they scan many (~200) JAR files. Initially I thought this problem could be fixed by [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], but it turned out that it's not straightforward under current design. Instead of focusing on ConstantUtf8, I decided to use my own custom ClassPathRepository that uses LRU cache internally to hold JavaClass instances. It worked. This ticket is to contribute the idea to BCEL library so that other users can benefit from it. h1. Test Case https://github.com/suztomo/bcel-oome-example was: (This ticket is derivation from [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], which I found creating ConstantUtf8 cache is not straightforward under current ClassPathRepository design.) We use BCEL library in https://github.com/GoogleCloudPlatform/cloud-opensource-java . Thank you for great library. I'm going to add an example case where existing ClassPathRepository and MemorySensitiveClassPathRepository throw OutOfMemoryError upon scanning many JAR files. Initially I thought it could be fixed by [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], but it turned out that it's not straightforward under current design. Instead of focusing on ConstantUtf8, I decided to use my own custom ClassPathRepository that uses LRU cache internally to hold JavaClass instances. This ticket is to contribute the idea to BCEL library so that other users can benefit from it. > A new ClassPathRepository that can scan many JAR files without > OutOfMemoryError > --- > > Key: BCEL-320 > URL: https://issues.apache.org/jira/browse/BCEL-320 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > > (This ticket is derivation from > [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], which I found > creating ConstantUtf8 cache is not straightforward under current > ClassPathRepository design.) > We use BCEL library in > https://github.com/GoogleCloudPlatform/cloud-opensource-java . Thank you for > great library. > h1. Background > Our use of BCEL ClassPathRepository and MemorySensitiveClassPathRepository > causes OutOfMemoryError when they scan many (~200) JAR files. Initially I > thought this problem could be fixed by > [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], but it turned out > that it's not straightforward under current design. Instead of focusing on > ConstantUtf8, I decided to use my own custom ClassPathRepository that uses > LRU cache internally to hold JavaClass instances. It worked. > This ticket is to contribute the idea to BCEL library so that other users can > benefit from it. > h1. Test Case > https://github.com/suztomo/bcel-oome-example -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BCEL-320) A new ClassPathRepository that can scan many JAR files without OutOfMemoryError
[ https://issues.apache.org/jira/browse/BCEL-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-320: - Summary: A new ClassPathRepository that can scan many JAR files without OutOfMemoryError (was: A new ClassPathRepository that can scan 200 JAR files without OutOfMemoryError) > A new ClassPathRepository that can scan many JAR files without > OutOfMemoryError > --- > > Key: BCEL-320 > URL: https://issues.apache.org/jira/browse/BCEL-320 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > > (This ticket is derivation from > [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], which I found > creating ConstantUtf8 cache is not straightforward under current > ClassPathRepository design.) > We use BCEL library in > https://github.com/GoogleCloudPlatform/cloud-opensource-java . Thank you for > great library. > I'm going to add an example case where existing ClassPathRepository and > MemorySensitiveClassPathRepository throw OutOfMemoryError upon scanning many > JAR files. > Initially I thought it could be fixed by > [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], but it turned out > that it's not straightforward under current design. Instead of focusing on > ConstantUtf8, I decided to use my own custom ClassPathRepository that uses > LRU cache internally to hold JavaClass instances. > This ticket is to contribute the idea to BCEL library so that other users can > benefit from it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (JEXL-253) Permissions by super type in JexlSandbox
[
https://issues.apache.org/jira/browse/JEXL-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro resolved JEXL-253.
Resolution: Fixed
Changeset: 757dcb90f2ca2ba92fd9ec43291deb4305eee02c
Author:henrib
Date: 2019-06-17 16:36
Message: JEXL-253: Added public API to allow creation of inheritable
permissions in sandbox; added tests
> Permissions by super type in JexlSandbox
>
>
> Key: JEXL-253
> URL: https://issues.apache.org/jira/browse/JEXL-253
> Project: Commons JEXL
> Issue Type: New Feature
>Affects Versions: 3.1
>Reporter: Woonsan Ko
>Assignee: Henri Biestro
>Priority: Major
> Fix For: 3.2
>
>
> At the moment, the permissions in {{JexlSandbox}} takes the object's class
> name only into the consideration. So, if someone adds {{java.util.Set}} into
> the white list, but if the real object is an empty set
> ({{Collections.emptySet()}}), then it cannot allow invocations on
> {{#contains(Object)}} operation, for instance.
> I think it would be very convenient if it optionally allows to set whites or
> blacks based on super type (interfaces or base classes).
> To minimize the effort, I'd suggest adding
> {{JexlSandbox#permissionsByType(Class type, ...)}}, where the {{type}}
> means the object type or any super types.
> So, if {{JexlSandbox#permissionsByType(java.util.Set.class, ...)}}, then any
> invocations on any concrete {{java.util.Set}} objects will be affected by
> that.
> Related e-mail thread: "[JEXL] white list classes, not by interfaces?"
> (10/19/17).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMMONSSITE-100) "mvn site" fails with commons-parent 43
[
https://issues.apache.org/jira/browse/COMMONSSITE-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865619#comment-16865619
]
Alex D Herbert commented on COMMONSSITE-100:
The change was to {{src/site/site.xml}}. The pages where the MathJax script is
not present are all the pages generated by the site plugin, e.g. the userguide
pages.
The pom file is OK. It has settings for MathJax for the javadoc pages and they
work fine.
I do not understand why the site plugin is ignoring the mathjax script
inclusion. According to the documentation it should work.
This is only an issue if some pages on the site have embedded equations.
Searching in the userguide xml files finds nothing from:
{noformat}
`
$$
{
{noformat}
I found this in stat.xml for an embedded equation:
{noformat}
\(
{noformat}
I can confirm that locally the stat.html page of the user guide has not
rendered this equation. It is in section 1.8:
{noformat}
\(D_n=\sup_x |F_n(x)-F(x)|\), where \(F\) is the expected distribution and
\(F_n\) is the empirical distribution of the \(n\) sample data points. Both
one-sample tests against a RealDistribution and two-sample tests
(comparing two empirical distributions) are supported. For one-sample tests,
the distribution of \(D_n\) is estimated using the method in
{noformat}
> "mvn site" fails with commons-parent 43
> ---
>
> Key: COMMONSSITE-100
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-100
> Project: Commons All
> Issue Type: Bug
> Components: Commons Parent Pom
>Reporter: Gilles
>Priority: Major
>
> See [this post|http://markmail.org/message/zgfb5h774aigatx2].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMMONSSITE-100) "mvn site" fails with commons-parent 43
[ https://issues.apache.org/jira/browse/COMMONSSITE-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865597#comment-16865597 ] Gilles commented on COMMONSSITE-100: bq. the mathjax script does not appear in the tag of the generated pages Yes, now that you mention it, I recall having seen it when I first noticed the problem (months ago). I wonder whether it wouldn't be worth to try and completely overwrite the "CM" POM. \[And just add back the list of contributors\]. (?) > "mvn site" fails with commons-parent 43 > --- > > Key: COMMONSSITE-100 > URL: https://issues.apache.org/jira/browse/COMMONSSITE-100 > Project: Commons All > Issue Type: Bug > Components: Commons Parent Pom >Reporter: Gilles >Priority: Major > > See [this post|http://markmail.org/message/zgfb5h774aigatx2]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (BCEL-320) A new ClassPathRepository that can scan 200 JAR files without OutOfMemoryError
[ https://issues.apache.org/jira/browse/BCEL-320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-320: - Priority: Minor (was: Major) > A new ClassPathRepository that can scan 200 JAR files without OutOfMemoryError > -- > > Key: BCEL-320 > URL: https://issues.apache.org/jira/browse/BCEL-320 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > > (This ticket is derivation from > [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], which I found > creating ConstantUtf8 cache is not straightforward under current > ClassPathRepository design.) > We use BCEL library in > https://github.com/GoogleCloudPlatform/cloud-opensource-java . Thank you for > great library. > I'm going to add an example case where existing ClassPathRepository and > MemorySensitiveClassPathRepository throw OutOfMemoryError upon scanning many > JAR files. > Initially I thought it could be fixed by > [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], but it turned out > that it's not straightforward under current design. Instead of focusing on > ConstantUtf8, I decided to use my own custom ClassPathRepository that uses > LRU cache internally to hold JavaClass instances. > This ticket is to contribute the idea to BCEL library so that other users can > benefit from it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work logged] (BCEL-317) Pluggable cache for ConstantUtf8
[
https://issues.apache.org/jira/browse/BCEL-317?focusedWorklogId=261311=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-261311
]
ASF GitHub Bot logged work on BCEL-317:
---
Author: ASF GitHub Bot
Created on: 17/Jun/19 12:36
Start Date: 17/Jun/19 12:36
Worklog Time Spent: 10m
Work Description: suztomo commented on pull request #27: [BCEL-317]
Constant to switch ConstantUtf8.getInstance or getCachedInstance
URL: https://github.com/apache/commons-bcel/pull/27
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: 261311)
Time Spent: 40m (was: 0.5h)
> Pluggable cache for ConstantUtf8
>
>
> Key: BCEL-317
> URL: https://issues.apache.org/jira/browse/BCEL-317
> Project: Commons BCEL
> Issue Type: Improvement
> Components: Main
>Affects Versions: 6.3.1
>Reporter: Tomo Suzuki
>Priority: Minor
> Attachments: 2644k_constantutf8_without_getCachedInstance.png,
> 621k_constantutf8_with_getCachedInstance.png
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Follow-up of BCEL-186. This enhancement is to provide an option to cache
> ConstantUtf8 instances that have the same value.
>
> Email thread: [bcel] Idea to share ConstantUtf8 of same value among JavaClass
> instances
>
> We use BCEL library to inspect Java class. Thank you for the great library.
>
> When our tool checks classes in ~200 jar files, it creates more than 2
> million BCEL ConstantUtf8 instances. I suspect many of them share the same
> values such as "java.lang.String".
>
> Without cache, my tool created 2,6 million ConstantUtf8 instances (before
> failing OutOfMemoryError: GC overhead limit exceeded) to check ~200 jar files.
> !2644k_constantutf8_without_getCachedInstance.png!
>
> With the cache, my tool created just 0.6 million ConstantUtf8 instances. It
> didn't throw the OutOfMemoryError.
> !621k_constantutf8_with_getCachedInstance.png!
>
> Old commit that made ConstantUtf8.getInstance
> [https://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/Constant.java?r1=1481383=1481382=1481383]
> The ConstantUtf8.getInstance has been unused in BCEL since BCEL-186
> [http://svn.apache.org/viewvc/commons/proper/bcel/trunk/src/main/java/org/apache/bcel/classfile/ConstantUtf8.java?r1=1652541=1652540=1652541]
>
> h1. How our project uses BCEL
> - Our tool (Linkage Checker) creates BCEL's ClassPathRepository with around
> 200 JAR files as its input class path in
> ClassDumper.createClassRepository([source code
> URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L83])
> {code:java}
> private static Repository createClassRepository(List paths) {
> ClassPath classPath = new LinkageCheckClassPath(paths);
> return new ClassPathRepository(classPath); # This is BCEL API
> }{code}
> - reads JavaClasses one by one in ClassDumper.listClassesInJar ([source code
> URL|https://github.com/GoogleCloudPlatform/cloud-opensource-java/blob/239fb82e368b2c181e358359f758b33c0a122787/dependencies/src/main/java/com/google/cloud/tools/opensource/classpath/ClassDumper.java#L360])
> through the ClassPathRepository.
> {code:java}
> private ImmutableSet listClassesInJar(Path jar) throws
> IOException {
> ImmutableSet.Builder javaClasses = ImmutableSet.builder();
> for (String className : listClassNamesInJar(jar)) {
> try {
> JavaClass javaClass = classRepository.loadClass(className); # This is
> BCEL API. ConstantUtf8 is not cached.
> javaClasses.add(javaClass);
> ...(omit)
> return javaClasses.build();
> }{code}
> Stacktrace from the ClassDumper.listClassesInJar to BCEL's
> ConstantUtf8.getInstance would look like this:
> {code:java}
> ConstantUtf8.getInstance
> Constant.readConstant
> ConstantPool.
> ClassParser.readConstantPool
> ClassParser.parse
> ClassPathRepository.loadClass
> ClassPathRepository.loadClass
> ClassDumper.listClassesInJar {code}
> - Use the JavaClass instances to check if any symbol references (entries in
> constant pool [Java Virtual Machine Specification 4.4. The Constant
> Pool|https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.4]:
> CONSTANT_Class, CONSTANT_Fieldref, CONSTANT_Methodref, and
> CONSTANT_InterfaceMethodref) has invalid referent in
[jira] [Updated] (BCEL-321) Subclasses of ClassPathRepository only differ by its underlying cache?
[ https://issues.apache.org/jira/browse/BCEL-321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomo Suzuki updated BCEL-321: - Priority: Minor (was: Major) > Subclasses of ClassPathRepository only differ by its underlying cache? > -- > > Key: BCEL-321 > URL: https://issues.apache.org/jira/browse/BCEL-321 > Project: Commons BCEL > Issue Type: Improvement >Reporter: Tomo Suzuki >Priority: Minor > > (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) > BCEL has different ClassPathRepository classes with slight modification in > its underlying cache: > * ClassPathRepository uses HashMap for JavaClass cache > * MemorySensitiveClassPathRepository uses HashMap SoftReference > * BCEL-320 will use LinkedHashMap for JavaClass cache > I think they can leverage an abstraction over the internal cache. > After BCEL-320, I'm thinking to create a PR for the abstraction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-bcel] suztomo commented on issue #27: [BCEL-317] Constant to switch ConstantUtf8.getInstance or getCachedInstance
suztomo commented on issue #27: [BCEL-317] Constant to switch ConstantUtf8.getInstance or getCachedInstance URL: https://github.com/apache/commons-bcel/pull/27#issuecomment-502664628 Closing as per https://issues.apache.org/jira/browse/BCEL-317?focusedCommentId=16859059=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16859059. Leveraging ConstantUtf8 cache is not straightforward without introducing static variables or relying on system property. 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-bcel] suztomo closed pull request #27: [BCEL-317] Constant to switch ConstantUtf8.getInstance or getCachedInstance
suztomo closed pull request #27: [BCEL-317] Constant to switch ConstantUtf8.getInstance or getCachedInstance URL: https://github.com/apache/commons-bcel/pull/27 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] (BCEL-321) Subclasses of ClassPathRepository only differ by its underlying cache?
Tomo Suzuki created BCEL-321: Summary: Subclasses of ClassPathRepository only differ by its underlying cache? Key: BCEL-321 URL: https://issues.apache.org/jira/browse/BCEL-321 Project: Commons BCEL Issue Type: Improvement Reporter: Tomo Suzuki (After implementing [BCEL-320|https://issues.apache.org/jira/browse/BCEL-320]) BCEL has different ClassPathRepository classes with slight modification in its underlying cache: * ClassPathRepository uses HashMap for JavaClass cache * MemorySensitiveClassPathRepository uses HashMap * BCEL-320 will use LinkedHashMap for JavaClass cache I think they can leverage an abstraction over the internal cache. After BCEL-320, I'm thinking to create a PR for the abstraction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (BCEL-320) A new ClassPathRepository that can scan 200 JAR files without OutOfMemoryError
Tomo Suzuki created BCEL-320: Summary: A new ClassPathRepository that can scan 200 JAR files without OutOfMemoryError Key: BCEL-320 URL: https://issues.apache.org/jira/browse/BCEL-320 Project: Commons BCEL Issue Type: Improvement Reporter: Tomo Suzuki (This ticket is derivation from [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], which I found creating ConstantUtf8 cache is not straightforward under current ClassPathRepository design.) We use BCEL library in https://github.com/GoogleCloudPlatform/cloud-opensource-java . Thank you for great library. I'm going to add an example case where existing ClassPathRepository and MemorySensitiveClassPathRepository throw OutOfMemoryError upon scanning many JAR files. Initially I thought it could be fixed by [BCEL-317|https://issues.apache.org/jira/browse/BCEL-317], but it turned out that it's not straightforward under current design. Instead of focusing on ConstantUtf8, I decided to use my own custom ClassPathRepository that uses LRU cache internally to hold JavaClass instances. This ticket is to contribute the idea to BCEL library so that other users can benefit from it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (RNG-16) Linear congruential generators
[ https://issues.apache.org/jira/browse/RNG-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865548#comment-16865548 ] Abhishek Singh Dhadwal commented on RNG-16: --- Hello, I shall be working on the task at hand. Upon discussion with Gilles and Alex Herbert, following are the details about the plan for implementation of the RNG. There shall be a base abstract class (AbstractLCG) which shall take inputs of a,c,m and the seed and return integer values as required. There shall be a child class (KnuthLewisLCG) which shall extend the aforementioned class with the values of a, c and m referred from [Numerical Recipes |https://en.wikipedia.org/wiki/Linear_congruential_generator#Parameters_in_common_use] The current questions/queries at hand are : * Will it pass the test suite? * Can using modulo 2^32 increase performance (to be tested using JMH) * Comparison between KnuthLewisDirect and the aforementioned child class > Linear congruential generators > -- > > Key: RNG-16 > URL: https://issues.apache.org/jira/browse/RNG-16 > Project: Commons RNG > Issue Type: Sub-task >Reporter: Emmanuel Bourg >Priority: Minor > Labels: gsoc2019 > > This is a RFE for implementing linear congruential generators: > https://en.wikipedia.org/wiki/Linear_congruential_generator > This type of random generator is often used in language runtimes (Borland C, > GCC, Delphi, VB and even Java). Preconfigured generators using the same > parameters as these languages would be convenient for reproducing the same > number sequences in Java. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (RNG-32) Implement more generators
[
https://issues.apache.org/jira/browse/RNG-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Singh Dhadwal updated RNG-32:
--
Comment: was deleted
(was: Hello,
I shall be working on the task at hand. Upon discussion with Gilles and Alex
Herbert, following are the details about the plan for implementation of the RNG.
There shall be a base abstract class (AbstractLCG) which shall take inputs of
a,c,m and the seed and return integer values as required.
There shall be a child class (KnuthLewisLCG) which shall extend the
aforementioned class with the values of a, c and m referred from [Numerical
Recipes
|https://en.wikipedia.org/wiki/Linear_congruential_generator#Parameters_in_common_use]
The current questions/queries at hand are :
* Will it pass the test suite?
* Can using modulo 2^32 increase performance (to be tested using JMH)
* Comparison between KnuthLewisDirect and the aforementioned child class)
> Implement more generators
> -
>
> Key: RNG-32
> URL: https://issues.apache.org/jira/browse/RNG-32
> Project: Commons RNG
> Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
> Labels: contributors, gsoc2019, scope
> Attachments: lsf.java
>
>
> Commons RNG is focused on pure-Java implementations of standard deterministic
> generators.
> Quite a few algorithms could be added, but priority is on fast generators
> that generate sequences of _pseudo-random_ numbers; i.e. the requirement is
> strong _uniformity_, but *not* strong _unpredictability_ (a.k.a. _true_
> random numbers).
> In particular, in Commons RNG, there is no provision for using an external
> entropy pool.
> Beware that some well-known (and much used) algorithms have been proven to
> fail spectacularly on the uniformity requirement.
> Would-be contributors should look at the {{commons-rng-core}} module for how
> to implement a generator, and at the {{commons-rng-examples}} module for how
> to test the uniformity requirement.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (RNG-32) Implement more generators
[
https://issues.apache.org/jira/browse/RNG-32?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865545#comment-16865545
]
Abhishek Singh Dhadwal commented on RNG-32:
---
Hello,
I shall be working on the task at hand. Upon discussion with Gilles and Alex
Herbert, following are the details about the plan for implementation of the RNG.
There shall be a base abstract class (AbstractLCG) which shall take inputs of
a,c,m and the seed and return integer values as required.
There shall be a child class (KnuthLewisLCG) which shall extend the
aforementioned class with the values of a, c and m referred from [Numerical
Recipes
|https://en.wikipedia.org/wiki/Linear_congruential_generator#Parameters_in_common_use]
The current questions/queries at hand are :
* Will it pass the test suite?
* Can using modulo 2^32 increase performance (to be tested using JMH)
* Comparison between KnuthLewisDirect and the aforementioned child class
> Implement more generators
> -
>
> Key: RNG-32
> URL: https://issues.apache.org/jira/browse/RNG-32
> Project: Commons RNG
> Issue Type: Wish
>Reporter: Gilles
>Priority: Minor
> Labels: contributors, gsoc2019, scope
> Attachments: lsf.java
>
>
> Commons RNG is focused on pure-Java implementations of standard deterministic
> generators.
> Quite a few algorithms could be added, but priority is on fast generators
> that generate sequences of _pseudo-random_ numbers; i.e. the requirement is
> strong _uniformity_, but *not* strong _unpredictability_ (a.k.a. _true_
> random numbers).
> In particular, in Commons RNG, there is no provision for using an external
> entropy pool.
> Beware that some well-known (and much used) algorithms have been proven to
> fail spectacularly on the uniformity requirement.
> Would-be contributors should look at the {{commons-rng-core}} module for how
> to implement a generator, and at the {{commons-rng-examples}} module for how
> to test the uniformity requirement.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (COMMONSSITE-100) "mvn site" fails with commons-parent 43
[
https://issues.apache.org/jira/browse/COMMONSSITE-100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865527#comment-16865527
]
Alex D Herbert commented on COMMONSSITE-100:
I ran {{mvn -X -e clean site}}. The final statement before it blows up is:
{noformat}
[DEBUG] Reading site descriptor from
/home/ah403/git/commons-math/src/site/site.xml
...
Caused by: org.codehaus.plexus.util.xml.pull.XmlPullParserException: TEXT must
be immediately followed by END_TAG and not START_TAG (position: START_TAG seen
...thjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">...
@86:122)
{noformat}
So looking at the difference between commons-math and commons-rng (where this
works) is that the site.xml uses a CDATA tag around the mathjax script in
commons-rng:
{noformat}
http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML";>
{noformat}
verses:
{noformat}
{noformat}
This is the documented way to [inject xhtml into
|https://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html#Inject_xhtml_into_.3Chead.3E]
since version 3.5. This corresponds to the problem starting with commons
parent 43 which changed 3.4 -> 3.6.
I've pushed a commit to add this change to commons-math.
Strangely even though the site now builds the mathjax script does not appear in
the tag of the generated pages. This used to happen as the live website
for 3.6.1 [http://commons.apache.org/proper/commons-math/] contains the mathjax
sccript. But my local site build for CM4 does not.
> "mvn site" fails with commons-parent 43
> ---
>
> Key: COMMONSSITE-100
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-100
> Project: Commons All
> Issue Type: Bug
> Components: Commons Parent Pom
>Reporter: Gilles
>Priority: Major
>
> See [this post|http://markmail.org/message/zgfb5h774aigatx2].
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CODEC-254) ColognePhonetic does not treat the letter H correct
[ https://issues.apache.org/jira/browse/CODEC-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865466#comment-16865466 ] Sebb commented on CODEC-254: I agree, the code currently handles SHCH incorrectly. I've checked with the Perl Text::Phonetic::Koeln module and that says SHCH => 84. I think the error occurs because the code only takes account of H as the next character, and ignores the fact that it affects the previous character. So it looks like the C directly follows the S. > ColognePhonetic does not treat the letter H correct > --- > > Key: CODEC-254 > URL: https://issues.apache.org/jira/browse/CODEC-254 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.12 >Reporter: Holger Grote >Priority: Major > > With the fix in CODEC-250 the letter H is not treaten correct any more. > A String 'shch' is coded as 8 and not as 84. (This string is sometimes in > foreign surnames) > The reasen is the letter h is ignored completely and not stored in the > lastChar anymore. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] [commons-vfs] boris-petrov opened a new pull request #66: Implement AutoCloseable for RandomAccessContent
boris-petrov opened a new pull request #66: Implement AutoCloseable for RandomAccessContent URL: https://github.com/apache/commons-vfs/pull/66 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] [Resolved] (CODEC-256) ColognePhonetic.encode() calculates wrong code
[ https://issues.apache.org/jira/browse/CODEC-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved CODEC-256. Resolution: Invalid Closing as invalid > ColognePhonetic.encode() calculates wrong code > -- > > Key: CODEC-256 > URL: https://issues.apache.org/jira/browse/CODEC-256 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.12 > Environment: Java 8u181 64, Windows 7 Professional 64 >Reporter: Andreas Schnur >Priority: Major > Attachments: ColognePhonetic.java > > > Example String: "ARTMANN". Code of M is 6, Code of A is Zero (and therefore > is left out), Code of N is 6 and should be left out because 6 is previous, > but Code assumes wrongly 0 as previous (which was left out). So the result is > 07266, but has to be 0726 (see Description of algorithm in class). > Solution: In method colognePhonetic() move the last two LOC into if-block > above, see attached version of class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CODEC-256) ColognePhonetic.encode() calculates wrong code
[ https://issues.apache.org/jira/browse/CODEC-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16865419#comment-16865419 ] Sebb commented on CODEC-256: Note that the class Javadoc says: bq. Stage 3: Removal of all codes "0" except at the beginning. This means that two or more identical consecutive digits can occur if they occur after removing the "0" digits. This can no longer occur if 0 removal is done before de-duplication > ColognePhonetic.encode() calculates wrong code > -- > > Key: CODEC-256 > URL: https://issues.apache.org/jira/browse/CODEC-256 > Project: Commons Codec > Issue Type: Bug >Affects Versions: 1.12 > Environment: Java 8u181 64, Windows 7 Professional 64 >Reporter: Andreas Schnur >Priority: Major > Attachments: ColognePhonetic.java > > > Example String: "ARTMANN". Code of M is 6, Code of A is Zero (and therefore > is left out), Code of N is 6 and should be left out because 6 is previous, > but Code assumes wrongly 0 as previous (which was left out). So the result is > 07266, but has to be 0726 (see Description of algorithm in class). > Solution: In method colognePhonetic() move the last two LOC into if-block > above, see attached version of class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
