[jira] [Commented] (CONFIGURATION-653) ConfigurationUtils.dump and other methods should use ImmutableConfiguration
[
https://issues.apache.org/jira/browse/CONFIGURATION-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15900856#comment-15900856
]
Vincent Maurin commented on CONFIGURATION-653:
--
Thank you Oliver
{code:xml}
Vincent Maurin
vincent.maurin...@gmail.com
glispa GmbH
{code}
> ConfigurationUtils.dump and other methods should use ImmutableConfiguration
> ---
>
> Key: CONFIGURATION-653
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-653
> Project: Commons Configuration
> Issue Type: Bug
>Affects Versions: 2.1, 2.1.1
>Reporter: Vincent Maurin
>Priority: Minor
> Fix For: 2.2
>
> Attachments: two_versions.diff, use_immutable.diff
>
>
> Since the read-only ImmutableConfiguration/ImmutableHierarchicalConfiguration
> has been introduced, several methods that uses Configuration in a read-only
> fashion should be adapted to use these ones instead of the read/write
> alternative.
> For example :
> ConfigurationUtils.dump
> ConfigurationUtils.toString
> ConfigurationUtils.copy (for the source)
> ConfigurationUtils.append (for the source)
> ConfigurationUtils.convertToHierarchical
> ConfigurationConverter.getProperties
> ... and maybe others
> It should not break any existing code as Configuration implements
> ImmutableConfiguration and it could enable code that manipulates read only
> configurations to use these utilities
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user Tomschi commented on the issue: https://github.com/apache/commons-lang/pull/231 I changed the HashMap to a ConcurrentHashMap. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/231 [](https://coveralls.io/builds/10485308) Coverage decreased (-0.05%) to 94.483% when pulling **6eb918e78fd2b12da9cebeeedf13b882096a3502 on Tomschi:master** into **d43e1d01981d321b85a8ccae788da4d818548dbe on apache:master**. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user coveralls commented on the issue: https://github.com/apache/commons-lang/pull/231 [](https://coveralls.io/builds/10484777) Coverage decreased (-0.05%) to 94.483% when pulling **6eb918e78fd2b12da9cebeeedf13b882096a3502 on Tomschi:master** into **d43e1d01981d321b85a8ccae788da4d818548dbe on apache:master**. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang pull request #231: Evaluate Architecure
Github user kinow commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/231#discussion_r104819886
--- Diff: src/main/java/org/apache/commons/lang3/ArchUtils.java ---
@@ -0,0 +1,446 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3;
+
+import java.util.HashMap;
+import java.util.Map;
+
+/**
+ * An utility class for the os.arch System Property. The class defines
methods for
+ * identifying the architecture of the current JVM.
+ *
+ *
+ * Important: The os.arch System Property returns the architecture used by
the JVM
+ * not of the operating system.
+ *
+ *
+ * @author Tomschi
+ */
+public class ArchUtils {
+
+/**
+ * This {@link Map} contains the the possible os.arch property {@link
String}'s.
+ */
+private static final Map map;
+
+/**
+ * The value for x86 architecture.
+ */
+private static final String X86 = "x86";
+
+/**
+ * The value for x86_64 architecture.
+ */
+private static final String X86_64 = "x86_64";
+
+/**
+ * The value for ia64_32 architecture.
+ */
+private static final String IA64_32 = "ia64_32";
+
+/**
+ * The value for ia64 architecture.
+ */
+private static final String IA64 = "ia64";
+
+/**
+ * The value for ppc architecture.
+ */
+private static final String PPC = "ppc";
+
+/**
+ * The value for ppc64 architecture.
+ */
+private static final String PPC64 = "ppc64";
+
+static {
+map = new HashMap<>();
+
--- End diff --
Indeed. The crypto implementation doesn't allow changes to the map after it
has been created. I think we can use a ConcurrentHashMap, or simply follow what
was done in crypto.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] commons-lang pull request #231: Evaluate Architecure
Github user sebbASF commented on a diff in the pull request:
https://github.com/apache/commons-lang/pull/231#discussion_r104807087
--- Diff: src/main/java/org/apache/commons/lang3/ArchUtils.java ---
@@ -0,0 +1,446 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.commons.lang3;
+
+import java.util.HashMap;
+import java.util.Map;
+
+/**
+ * An utility class for the os.arch System Property. The class defines
methods for
+ * identifying the architecture of the current JVM.
+ *
+ *
+ * Important: The os.arch System Property returns the architecture used by
the JVM
+ * not of the operating system.
+ *
+ *
+ * @author Tomschi
+ */
+public class ArchUtils {
+
+/**
+ * This {@link Map} contains the the possible os.arch property {@link
String}'s.
+ */
+private static final Map map;
+
+/**
+ * The value for x86 architecture.
+ */
+private static final String X86 = "x86";
+
+/**
+ * The value for x86_64 architecture.
+ */
+private static final String X86_64 = "x86_64";
+
+/**
+ * The value for ia64_32 architecture.
+ */
+private static final String IA64_32 = "ia64_32";
+
+/**
+ * The value for ia64 architecture.
+ */
+private static final String IA64 = "ia64";
+
+/**
+ * The value for ppc architecture.
+ */
+private static final String PPC = "ppc";
+
+/**
+ * The value for ppc64 architecture.
+ */
+private static final String PPC64 = "ppc64";
+
+static {
+map = new HashMap<>();
+
--- End diff --
HashMap is not thread-safe.
Since there are public methods which can also update the map, this means
the class is not thread-safe either.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Comment Edited] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
[
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15900317#comment-15900317
]
Shon Vella edited comment on VFS-620 at 3/7/17 10:35 PM:
-
This appears to be a duplicate of both VFS-188 and VFS-292, both of which had
patches submitted last decade without so much as an acknowledgment, though
neither patch is exactly right, in that they don't account for the possibility
of a decorator on the source FileObject no include an updated test case. Here
is a new patch VFS-620.patch that accounts for that and adds in a test case
that causes the entire suite being run against the FTP provider to be run both
with and without the UserDirIsRoot option.
was (Author: svella):
This appears to be a duplicate of both VFS-188 and VFS-292, both of which had
patches submitted last decade without so much as an acknowledgment, though
neither patch is exactly right, in that they don't account for the possibility
of a decorator on the source FileObject no include an updated test case. Here
is a new patch that accounts for that and adds in a test case that causes the
entire suite being run against the FTP provider to be run both with and without
the UserDirIsRoot option.
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
> ---
>
> Key: VFS-620
> URL: https://issues.apache.org/jira/browse/VFS-620
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: ubuntu vsftpd
>Reporter: stevezhuang
> Attachments: VFS-620.patch
>
>
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP,
> especially for setting a user directory as its root directory case,
> For example, for a ubuntu vsftpd, which is having "/home/user1" as its root
> directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will
> throw an exception.
> In this case, it should consider the workingDirectory(would be "/home/user1")
> together and append it to the from/to path to make the API work.
> Sample codes,
> FileObject fileObject = null;
> FileObject toFileObject = null;
> try {
> StandardFileSystemManager fsManager = new
> StandardFileSystemManager();
> fsManager.init();
> FileSystemOptions fsOpts = new FileSystemOptions();
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts,
> true);
> FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts,
> true);
> UserAuthenticator auth = new StaticUserAuthenticator(null,
> "", "");
>
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts,
> auth);
> fileObject = fsManager.resolveFile("ftp:// address>/test/test.txt", fsOpts);
> System.out.println("File exists:" + fileObject.exists());
> toFileObject = fsManager.resolveFile("ftp:// address>/test1/test1.txt", fsOpts);
> System.out.println("File exists:" + toFileObject.exists());
> if (!toFileObject.exists()) {
> toFileObject.createFile();
> }
> fileObject.moveTo(toFileObject);
> } catch (FileSystemException ex) {
> ex.printStackTrace();
> } finally {
> if (fileObject != null) {
> try {
> fileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> if (toFileObject != null) {
> try {
> toFileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> }
> And the output,
> File exists:true
> File exists:false
> org.apache.commons.vfs2.FileSystemException: Could not rename
> "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
> at TestFTP.main(TestFTP.java:59)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP
> file "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (VFS-620) FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
[
https://issues.apache.org/jira/browse/VFS-620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shon Vella updated VFS-620:
---
Attachment: VFS-620.patch
This appears to be a duplicate of both VFS-188 and VFS-292, both of which had
patches submitted last decade without so much as an acknowledgment, though
neither patch is exactly right, in that they don't account for the possibility
of a decorator on the source FileObject no include an updated test case. Here
is a new patch that accounts for that and adds in a test case that causes the
entire suite being run against the FTP provider to be run both with and without
the UserDirIsRoot option.
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP
> ---
>
> Key: VFS-620
> URL: https://issues.apache.org/jira/browse/VFS-620
> Project: Commons VFS
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: ubuntu vsftpd
>Reporter: stevezhuang
> Attachments: VFS-620.patch
>
>
> FileObject.moveTo(FileObject) API doesn't work well for a Linux FTP,
> especially for setting a user directory as its root directory case,
> For example, for a ubuntu vsftpd, which is having "/home/user1" as its root
> directory, when renaming "/test/test.txt" to "/test1/test1.txt", it will
> throw an exception.
> In this case, it should consider the workingDirectory(would be "/home/user1")
> together and append it to the from/to path to make the API work.
> Sample codes,
> FileObject fileObject = null;
> FileObject toFileObject = null;
> try {
> StandardFileSystemManager fsManager = new
> StandardFileSystemManager();
> fsManager.init();
> FileSystemOptions fsOpts = new FileSystemOptions();
> FtpFileSystemConfigBuilder.getInstance().setPassiveMode(fsOpts,
> true);
> FtpFileSystemConfigBuilder.getInstance().setUserDirIsRoot(fsOpts,
> true);
> UserAuthenticator auth = new StaticUserAuthenticator(null,
> "", "");
>
> DefaultFileSystemConfigBuilder.getInstance().setUserAuthenticator(fsOpts,
> auth);
> fileObject = fsManager.resolveFile("ftp:// address>/test/test.txt", fsOpts);
> System.out.println("File exists:" + fileObject.exists());
> toFileObject = fsManager.resolveFile("ftp:// address>/test1/test1.txt", fsOpts);
> System.out.println("File exists:" + toFileObject.exists());
> if (!toFileObject.exists()) {
> toFileObject.createFile();
> }
> fileObject.moveTo(toFileObject);
> } catch (FileSystemException ex) {
> ex.printStackTrace();
> } finally {
> if (fileObject != null) {
> try {
> fileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> if (toFileObject != null) {
> try {
> toFileObject.close();
> } catch (FileSystemException ex) {
> }
> }
> }
> And the output,
> File exists:true
> File exists:false
> org.apache.commons.vfs2.FileSystemException: Could not rename
> "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1902)
> at TestFTP.main(TestFTP.java:59)
> Caused by: org.apache.commons.vfs2.FileSystemException: Could not rename FTP
> file "ftp:///test/test.txt" to "ftp:// address>/test1/test1.txt".
> at
> org.apache.commons.vfs2.provider.ftp.FtpFileObject.doRename(FtpFileObject.java:524)
> at
> org.apache.commons.vfs2.provider.AbstractFileObject.moveTo(AbstractFileObject.java:1887)
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user Tomschi commented on the issue: https://github.com/apache/commons-lang/pull/231 I'm sorry. I removed the tabs. Style should be ok now. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/231 Excellent @Tomschi I'm dropping a note to the mailing list to ask for feedback from crypto devs, as there could be some synergy. I will play with the code at home, but one thing that I noticed is that it seems to contain tabs... minor nit pick, but could you check checkstyle and make sure the code is not introducing any warnings / errors there, please? That way it will be easier to merge the PR. Thanks! B --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (CONFIGURATION-653) ConfigurationUtils.dump and other methods should use ImmutableConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oliver Heger resolved CONFIGURATION-653. Resolution: Fixed Fix Version/s: 2.2 Patch applied with minor changes in revision 1785888. Many thanks! If you want to be added to the contributors section in the pom, just post the data you want to have in there. > ConfigurationUtils.dump and other methods should use ImmutableConfiguration > --- > > Key: CONFIGURATION-653 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-653 > Project: Commons Configuration > Issue Type: Bug >Affects Versions: 2.1, 2.1.1 >Reporter: Vincent Maurin >Priority: Minor > Fix For: 2.2 > > Attachments: two_versions.diff, use_immutable.diff > > > Since the read-only ImmutableConfiguration/ImmutableHierarchicalConfiguration > has been introduced, several methods that uses Configuration in a read-only > fashion should be adapted to use these ones instead of the read/write > alternative. > For example : > ConfigurationUtils.dump > ConfigurationUtils.toString > ConfigurationUtils.copy (for the source) > ConfigurationUtils.append (for the source) > ConfigurationUtils.convertToHierarchical > ConfigurationConverter.getProperties > ... and maybe others > It should not break any existing code as Configuration implements > ImmutableConfiguration and it could enable code that manipulates read only > configurations to use these utilities -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user Tomschi commented on the issue: https://github.com/apache/commons-lang/pull/231 Yes, the base of my code references to the commons crypto lib. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] commons-lang issue #231: Evaluate Architecure
Github user kinow commented on the issue: https://github.com/apache/commons-lang/pull/231 Looks better now @Tomschi did you use Crypto's code as reference? cc @michael-o --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1300) Clarify or improve behaviour of int-based methods in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15899583#comment-15899583
]
ASF GitHub Bot commented on LANG-1300:
--
Github user chtompki commented on the issue:
https://github.com/apache/commons-lang/pull/251
@dmjones500 - You're correct there, I wasn't thinking about it properly
because I was thinking in terms of `lastIndexOf` moving in from the end of the
`CharSequence` and then having to traverse in from the beginning to sort out
the number of surrogate pairs in the prefix to the matching character. But, if
you simply start with that traversal, then you remain at *O(n)*.
> Clarify or improve behaviour of int-based methods in StringUtils
>
>
> Key: LANG-1300
> URL: https://issues.apache.org/jira/browse/LANG-1300
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Discussion
>
>
> The following methods use an {{int}} to represent a search character:
> {code:java}
> boolean contains(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar, final int startPos)
> int lastIndexOf(final CharSequence seq, final int searchChar)
> int lastIndexOf(final CharSequence seq, final int searchChar, final int
> startPos)
> {code}
> When I see an {{int}} representing a character, I tend to assume the method
> can handle supplementary characters. However, the current behaviour of these
> methods depends upon whether the {{CharSequence}} is a {{String}} or not.
> {code:java}
> StringBuilder builder = new StringBuilder();
> builder.appendCodePoint(0x2070E);
> System.out.println(StringUtils.lastIndexOf(builder, 0x2070E)); // -1
> System.out.println(StringUtils.lastIndexOf(builder.toString(), 0x2070E)); // 0
> {code}
> The Javadoc for these methods are ambiguous on this point, stating:
> {quote}
> This method uses {{String.lastIndexOf(int)}} if possible.
> {quote}
> I think we should consider updating the {{CharSequenceUtils}} methods used by
> this class to convert all {{CharSequence}} parameters to strings, enabling
> full code point support. The docs could be updated to make this crystal clear.
> There is a question of whether this breaks backwards compatibility.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #251: LANG-1300: Change CharSequenceUtils to support supp...
Github user chtompki commented on the issue: https://github.com/apache/commons-lang/pull/251 @dmjones500 - You're correct there, I wasn't thinking about it properly because I was thinking in terms of `lastIndexOf` moving in from the end of the `CharSequence` and then having to traverse in from the beginning to sort out the number of surrogate pairs in the prefix to the matching character. But, if you simply start with that traversal, then you remain at *O(n)*. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (LANG-1300) Clarify or improve behaviour of int-based methods in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15899531#comment-15899531
]
ASF GitHub Bot commented on LANG-1300:
--
Github user dmjones500 commented on the issue:
https://github.com/apache/commons-lang/pull/251
@chtompki I'm far from a complexity expert, but if we keep a running tally
of the current index in terms of code points, I don't see us going from _O(n)_
to _O(n2)_. Wouldn't _O(n2)_ imply that for each item in
the input, we traverse the entire input again?
> Clarify or improve behaviour of int-based methods in StringUtils
>
>
> Key: LANG-1300
> URL: https://issues.apache.org/jira/browse/LANG-1300
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Discussion
>
>
> The following methods use an {{int}} to represent a search character:
> {code:java}
> boolean contains(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar, final int startPos)
> int lastIndexOf(final CharSequence seq, final int searchChar)
> int lastIndexOf(final CharSequence seq, final int searchChar, final int
> startPos)
> {code}
> When I see an {{int}} representing a character, I tend to assume the method
> can handle supplementary characters. However, the current behaviour of these
> methods depends upon whether the {{CharSequence}} is a {{String}} or not.
> {code:java}
> StringBuilder builder = new StringBuilder();
> builder.appendCodePoint(0x2070E);
> System.out.println(StringUtils.lastIndexOf(builder, 0x2070E)); // -1
> System.out.println(StringUtils.lastIndexOf(builder.toString(), 0x2070E)); // 0
> {code}
> The Javadoc for these methods are ambiguous on this point, stating:
> {quote}
> This method uses {{String.lastIndexOf(int)}} if possible.
> {quote}
> I think we should consider updating the {{CharSequenceUtils}} methods used by
> this class to convert all {{CharSequence}} parameters to strings, enabling
> full code point support. The docs could be updated to make this crystal clear.
> There is a question of whether this breaks backwards compatibility.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #251: LANG-1300: Change CharSequenceUtils to support supp...
Github user dmjones500 commented on the issue: https://github.com/apache/commons-lang/pull/251 @chtompki I'm far from a complexity expert, but if we keep a running tally of the current index in terms of code points, I don't see us going from _O(n)_ to _O(n2)_. Wouldn't _O(n2)_ imply that for each item in the input, we traverse the entire input again? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (NUMBERS-10) Revamp "Complex" representation ?
[
https://issues.apache.org/jira/browse/NUMBERS-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15899484#comment-15899484
]
Gilles commented on NUMBERS-10:
---
It may have been interesting to benchmark a few cases (FFT, fractals, ...) but
I won't have the time to delve more into this.
Do what you think is best.
> Revamp "Complex" representation ?
> -
>
> Key: NUMBERS-10
> URL: https://issues.apache.org/jira/browse/NUMBERS-10
> Project: Commons Numbers
> Issue Type: Wish
>Reporter: Gilles
> Labels: API, design, review
> Fix For: 1.0
>
> Attachments: CartesianRepresentation.java, Complex.java,
> MixedRepresentation.java, PolarRepresentation.java
>
>
> This is a proposal to enhance the internal representation of complex numbers.
> The purpose is to allow usage of both cartesian and polar representations,
> with the aim that calculations are performed (transparently) with the one
> that will be more accurate and/or faster.
> The API would certainly be improved, from
> {code}
> final Complex c1 = Complex.valueOf(1, 2);
> final Complex c2 = ComplexUtils.polar2Complex(2, 7);
> final Complex r = c1.add(c2);
> {code}
> with the current code, to
> {code}
> final Complex c1 = Complex.createCartesian(1, 2);
> final Complex c2 = Complex.createPolar(2, 7);
> final Complex r = c1.add(c2);
> {code}
> Please refer to the attached files (they are self-documenting, but of course,
> Javadoc must be added if the proposal is validated).
> Would there be merit in pursuing in that direction?
> Or is there any show-stopper?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IMAGING-201) Significant change in color of output image of tiff file
[
https://issues.apache.org/jira/browse/IMAGING-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Praful Vaishnav updated IMAGING-201:
Description:
Hii.. I am reading tiff image file and using this library to convert it to PNG
format. Resultant png file has significant change in color wrt its original
tiff file. Below is the code :
File file = new File("C:\\original.tiff");
BufferedImage bi = Imaging.getBufferedImage(file);
File dstFile = new File("C:\\result.png");
Imaging.writeImage(bi, dstFile, ImageFormats.PNG, null);
Reason could be :
original image is 32 bit depth and result image is 24 bit depth. Is there any
issue with 32 bit depth image file.
Link for source tiff file -
https://www.dropbox.com/s/kgqgdcygelkor8b/original.tiff?dl=0
Attachements:
SS_source.png - Screenshot of original tiff file
SS_result.png - Screenshot of result png file
was:
Hii.. I am reading tiff image file and using this library to convert it to PNG
format. Resultant png file has significant change in color wrt its original
tiff file. Below is the code :
File file = new File("C:\\original.tiff");
BufferedImage bi = Imaging.getBufferedImage(file);
File dstFile = new File("C:\\result.png");
Imaging.writeImage(bi, dstFile, ImageFormats.PNG, null);
Reason could be :
original image is 32 bit depth and result image is 24 bit depth. Is there any
issue with 32 bit depth image file.
Attachements:
SS_source.png - Screenshot of original tiff file
SS_result.png - Screenshot of result png file
> Significant change in color of output image of tiff file
>
>
> Key: IMAGING-201
> URL: https://issues.apache.org/jira/browse/IMAGING-201
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0
>Reporter: Praful Vaishnav
> Attachments: SS_result.png, SS_source.png
>
>
> Hii.. I am reading tiff image file and using this library to convert it to
> PNG format. Resultant png file has significant change in color wrt its
> original tiff file. Below is the code :
>File file = new File("C:\\original.tiff");
> BufferedImage bi = Imaging.getBufferedImage(file);
> File dstFile = new File("C:\\result.png");
> Imaging.writeImage(bi, dstFile, ImageFormats.PNG, null);
> Reason could be :
> original image is 32 bit depth and result image is 24 bit depth. Is there any
> issue with 32 bit depth image file.
> Link for source tiff file -
> https://www.dropbox.com/s/kgqgdcygelkor8b/original.tiff?dl=0
> Attachements:
> SS_source.png - Screenshot of original tiff file
> SS_result.png - Screenshot of result png file
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IMAGING-201) Significant change in color of output image of tiff file
[
https://issues.apache.org/jira/browse/IMAGING-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Praful Vaishnav updated IMAGING-201:
Attachment: SS_result.png
SS_source.png
> Significant change in color of output image of tiff file
>
>
> Key: IMAGING-201
> URL: https://issues.apache.org/jira/browse/IMAGING-201
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0
>Reporter: Praful Vaishnav
> Attachments: SS_result.png, SS_source.png
>
>
> Hii.. I am reading tiff image file and using this library to convert it to
> PNG format. Resultant png file has significant change in color wrt its
> original tiff file. Below is the code :
>File file = new File("C:\\original.tiff");
> BufferedImage bi = Imaging.getBufferedImage(file);
> File dstFile = new File("C:\\result.png");
> Imaging.writeImage(bi, dstFile, ImageFormats.PNG, null);
> Reason could be :
> original image is 32 bit depth and result image is 24 bit depth. Is there any
> issue with 32 bit depth image file.
> Attachements:
> SS_source.png - Screenshot of original tiff file
> SS_result.png - Screenshot of result png file
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Comment Edited] (LANG-1300) Clarify or improve behaviour of int-based methods in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15899421#comment-15899421
]
Rob Tompkins edited comment on LANG-1300 at 3/7/17 1:20 PM:
Github user chtompki commented on the issue:
https://github.com/apache/commons-lang/pull/251
@dmjones500 - no worries on the being busy, we all end up there for time to
time... :-)
@dmjones500 has an interesting point. The problem seems to lie with the
number of "Supplementary Code Points" preceding the *findable* `searchChar`
that have been previously split into their complementary surrogate pairs.
You may need to consider using `Character.isSurrogate(char ch)` as well as
`Character.isSurrogatePair(char high, char low)` for all characters preceding
our *findable* code point. Granted, that adds an *O( n )* multiplier on our
method's efficiency pushing us to *O(n2)*. It feels like only then
can we be absolutely certain that we are not over counting using *code units*
as opposed to *code points*.
If indeed we do move this direction, we should be quite clear, in the
javadoc, that there is a notable performance reduction when operating outside
the "Basic Multilingual Plane" (ref. [Oracle's Character
documentation](https://docs.oracle.com/javase/8/docs/api/java/lang/Character.html#supplementary)).
@PascalSchumacher - you have any thoughts here as well?
was (Author: githubbot):
Github user chtompki commented on the issue:
https://github.com/apache/commons-lang/pull/251
@dmjones500 - no worries on the being busy, we all end up there for time to
time... :-)
@dmjones500 has an interesting point. The problem seems to lie with the
number of "Supplementary Code Points" preceding the *findable* `searchChar`
that have been previously split into their complementary surrogate pairs.
You may need to consider using `Character.isSurrogate(char ch)` as well as
`Character.isSurrogatePair(char high, char low)` for all characters preceding
our *findable* code point. Granted, that adds an *O(n)* multiplier on our
method's efficiency pushing us to *O(n2)*. It feels like only then
can we be absolutely certain that we are not over counting using *code units*
as opposed to *code points*.
If indeed we do move this direction, we should be quite clear, in the
javadoc, that there is a notable performance reduction when operating outside
the "Basic Multilingual Plane" (ref. [Oracle's Character
documentation](https://docs.oracle.com/javase/8/docs/api/java/lang/Character.html#supplementary)).
@PascalSchumacher - you have any thoughts here as well?
> Clarify or improve behaviour of int-based methods in StringUtils
>
>
> Key: LANG-1300
> URL: https://issues.apache.org/jira/browse/LANG-1300
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Discussion
>
>
> The following methods use an {{int}} to represent a search character:
> {code:java}
> boolean contains(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar, final int startPos)
> int lastIndexOf(final CharSequence seq, final int searchChar)
> int lastIndexOf(final CharSequence seq, final int searchChar, final int
> startPos)
> {code}
> When I see an {{int}} representing a character, I tend to assume the method
> can handle supplementary characters. However, the current behaviour of these
> methods depends upon whether the {{CharSequence}} is a {{String}} or not.
> {code:java}
> StringBuilder builder = new StringBuilder();
> builder.appendCodePoint(0x2070E);
> System.out.println(StringUtils.lastIndexOf(builder, 0x2070E)); // -1
> System.out.println(StringUtils.lastIndexOf(builder.toString(), 0x2070E)); // 0
> {code}
> The Javadoc for these methods are ambiguous on this point, stating:
> {quote}
> This method uses {{String.lastIndexOf(int)}} if possible.
> {quote}
> I think we should consider updating the {{CharSequenceUtils}} methods used by
> this class to convert all {{CharSequence}} parameters to strings, enabling
> full code point support. The docs could be updated to make this crystal clear.
> There is a question of whether this breaks backwards compatibility.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (IMAGING-201) Significant change in color of output image of tiff file
[
https://issues.apache.org/jira/browse/IMAGING-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Praful Vaishnav updated IMAGING-201:
Description:
Hii.. I am reading tiff image file and using this library to convert it to PNG
format. Resultant png file has significant change in color wrt its original
tiff file. Below is the code :
File file = new File("C:\\original.tiff");
BufferedImage bi = Imaging.getBufferedImage(file);
File dstFile = new File("C:\\result.png");
Imaging.writeImage(bi, dstFile, ImageFormats.PNG, null);
Reason could be :
original image is 32 bit depth and result image is 24 bit depth. Is there any
issue with 32 bit depth image file.
Attachements:
SS_source.png - Screenshot of original tiff file
SS_result.png - Screenshot of result png file
was:
Hii.. I am reading tiff image file and using this library to convert it to PNG
format. Resultant png file has significant change in color wrt its original
tiff file. Below is the code :
*File file = new File("C:\\original.tiff");
BufferedImage bi = Imaging.getBufferedImage(file);
File dstFile = new File("C:\\result.png");
Imaging.writeImage(bi, dstFile, ImageFormats.PNG, null);*
> Significant change in color of output image of tiff file
>
>
> Key: IMAGING-201
> URL: https://issues.apache.org/jira/browse/IMAGING-201
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0
>Reporter: Praful Vaishnav
>
> Hii.. I am reading tiff image file and using this library to convert it to
> PNG format. Resultant png file has significant change in color wrt its
> original tiff file. Below is the code :
>File file = new File("C:\\original.tiff");
> BufferedImage bi = Imaging.getBufferedImage(file);
> File dstFile = new File("C:\\result.png");
> Imaging.writeImage(bi, dstFile, ImageFormats.PNG, null);
> Reason could be :
> original image is 32 bit depth and result image is 24 bit depth. Is there any
> issue with 32 bit depth image file.
> Attachements:
> SS_source.png - Screenshot of original tiff file
> SS_result.png - Screenshot of result png file
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (LANG-1300) Clarify or improve behaviour of int-based methods in StringUtils
[
https://issues.apache.org/jira/browse/LANG-1300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15899421#comment-15899421
]
ASF GitHub Bot commented on LANG-1300:
--
Github user chtompki commented on the issue:
https://github.com/apache/commons-lang/pull/251
@dmjones500 - no worries on the being busy, we all end up there for time to
time... :-)
@dmjones500 has an interesting point. The problem seems to lie with the
number of "Supplementary Code Points" preceding the *findable* `searchChar`
that have been previously split into their complementary surrogate pairs.
You may need to consider using `Character.isSurrogate(char ch)` as well as
`Character.isSurrogatePair(char high, char low)` for all characters preceding
our *findable* code point. Granted, that adds an *O(n)* multiplier on our
method's efficiency pushing us to *O(n2)*. It feels like only then
can we be absolutely certain that we are not over counting using *code units*
as opposed to *code points*.
If indeed we do move this direction, we should be quite clear, in the
javadoc, that there is a notable performance reduction when operating outside
the "Basic Multilingual Plane" (ref. [Oracle's Character
documentation](https://docs.oracle.com/javase/8/docs/api/java/lang/Character.html#supplementary)).
@PascalSchumacher - you have any thoughts here as well?
> Clarify or improve behaviour of int-based methods in StringUtils
>
>
> Key: LANG-1300
> URL: https://issues.apache.org/jira/browse/LANG-1300
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 3.5
>Reporter: Duncan Jones
>Priority: Minor
> Fix For: Discussion
>
>
> The following methods use an {{int}} to represent a search character:
> {code:java}
> boolean contains(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar)
> int indexOf(final CharSequence seq, final int searchChar, final int startPos)
> int lastIndexOf(final CharSequence seq, final int searchChar)
> int lastIndexOf(final CharSequence seq, final int searchChar, final int
> startPos)
> {code}
> When I see an {{int}} representing a character, I tend to assume the method
> can handle supplementary characters. However, the current behaviour of these
> methods depends upon whether the {{CharSequence}} is a {{String}} or not.
> {code:java}
> StringBuilder builder = new StringBuilder();
> builder.appendCodePoint(0x2070E);
> System.out.println(StringUtils.lastIndexOf(builder, 0x2070E)); // -1
> System.out.println(StringUtils.lastIndexOf(builder.toString(), 0x2070E)); // 0
> {code}
> The Javadoc for these methods are ambiguous on this point, stating:
> {quote}
> This method uses {{String.lastIndexOf(int)}} if possible.
> {quote}
> I think we should consider updating the {{CharSequenceUtils}} methods used by
> this class to convert all {{CharSequence}} parameters to strings, enabling
> full code point support. The docs could be updated to make this crystal clear.
> There is a question of whether this breaks backwards compatibility.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[GitHub] commons-lang issue #251: LANG-1300: Change CharSequenceUtils to support supp...
Github user chtompki commented on the issue: https://github.com/apache/commons-lang/pull/251 @dmjones500 - no worries on the being busy, we all end up there for time to time... :-) @dmjones500 has an interesting point. The problem seems to lie with the number of "Supplementary Code Points" preceding the *findable* `searchChar` that have been previously split into their complementary surrogate pairs. You may need to consider using `Character.isSurrogate(char ch)` as well as `Character.isSurrogatePair(char high, char low)` for all characters preceding our *findable* code point. Granted, that adds an *O(n)* multiplier on our method's efficiency pushing us to *O(n2)*. It feels like only then can we be absolutely certain that we are not over counting using *code units* as opposed to *code points*. If indeed we do move this direction, we should be quite clear, in the javadoc, that there is a notable performance reduction when operating outside the "Basic Multilingual Plane" (ref. [Oracle's Character documentation](https://docs.oracle.com/javase/8/docs/api/java/lang/Character.html#supplementary)). @PascalSchumacher - you have any thoughts here as well? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Updated] (IMAGING-201) Significant change in color of output image of tiff file
[
https://issues.apache.org/jira/browse/IMAGING-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Praful Vaishnav updated IMAGING-201:
Description:
Hii.. I am reading tiff image file and using this library to convert it to PNG
format. Resultant png file has significant change in color wrt its original
tiff file. Below is the code :
*File file = new File("C:\\original.tiff");
BufferedImage bi = Imaging.getBufferedImage(file);
File dstFile = new File("C:\\result.png");
Imaging.writeImage(bi, dstFile, ImageFormats.PNG, null);*
was:
Hii.. I am reading tiff image file and using this library to convert it to PNG
format. Resultant png file has significant change in color wrt its original
tiff file. Below is the code :
_ File file = new File("C:\\original.tiff");
BufferedImage bi = Imaging.getBufferedImage(file);
File dstFile = new File("C:\\result.png");
Imaging.writeImage(bi, dstFile, ImageFormats.PNG, null);_
> Significant change in color of output image of tiff file
>
>
> Key: IMAGING-201
> URL: https://issues.apache.org/jira/browse/IMAGING-201
> Project: Commons Imaging
> Issue Type: Bug
> Components: Format: TIFF
>Affects Versions: 1.0
>Reporter: Praful Vaishnav
>
> Hii.. I am reading tiff image file and using this library to convert it to
> PNG format. Resultant png file has significant change in color wrt its
> original tiff file. Below is the code :
>*File file = new File("C:\\original.tiff");
> BufferedImage bi = Imaging.getBufferedImage(file);
> File dstFile = new File("C:\\result.png");
> Imaging.writeImage(bi, dstFile, ImageFormats.PNG, null);*
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (IMAGING-201) Significant change in color of output image of tiff file
Praful Vaishnav created IMAGING-201:
---
Summary: Significant change in color of output image of tiff file
Key: IMAGING-201
URL: https://issues.apache.org/jira/browse/IMAGING-201
Project: Commons Imaging
Issue Type: Bug
Components: Format: TIFF
Affects Versions: 1.0
Reporter: Praful Vaishnav
Hii.. I am reading tiff image file and using this library to convert it to PNG
format. Resultant png file has significant change in color wrt its original
tiff file. Below is the code :
_ File file = new File("C:\\original.tiff");
BufferedImage bi = Imaging.getBufferedImage(file);
File dstFile = new File("C:\\result.png");
Imaging.writeImage(bi, dstFile, ImageFormats.PNG, null);_
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (MATH-1405) Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have significant effect
[
https://issues.apache.org/jira/browse/MATH-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15899360#comment-15899360
]
Gilles commented on MATH-1405:
--
bq. I like this solution a lot
Great. :)
All proposed changes are now in "master" (commit
b0b23c179ac55334f760aa29fce262c73a909268).
bq. Also, why switch the RandomSource from JDK to TWO_CMRES?
See [Commons
RNG|http://commons.apache.org/proper/commons-rng/userguide/rng.html#a4._Performance]:
{{RandomSource.JDK}} is only for reference purpose, but any of the other
alternatives is better, performance-wise and/or quality-wise.
> Kolmogorov-Smirnov fixTies can set minDelta too small for jiggler to have
> significant effect
>
>
> Key: MATH-1405
> URL: https://issues.apache.org/jira/browse/MATH-1405
> Project: Commons Math
> Issue Type: Bug
>Affects Versions: 3.6.1
>Reporter: Daniil Finkel
>
> For samples that do not exceed LARGE_SAMPLE_PRODUCT with their product and
> relatively large values, a minDelta can be calculated in fixTies() that is
> too small to have any effect on the "tied" values. This results in a
> MathInternalError, as the jiggling with the ineffective minDelta fails to fix
> the ties.
> The following arrays exhibit this behavior when run with
> kolmogorovSmirnovTest(x, y) in 3.6.1
> x = [1.3750969645841487, 1.0845460746754014, 1.3693352427126644,
> 1.329688765445783, 1.3392109491039106, 1.3532766470312723,
> 1.3187287426697727, 1.386273031970554, 1.3416950149276097,
> 1.0510872606482404, 1.3532766470312723, 1.3075923871137798,
> 1.3862730319705543, 1.3814421433922548, 1.0527927570919202,
> 1.3847314864464313, 1.319362658529506, 1.3579238253227275,
> 1.2455452272301641, 1.329688765445783, 1.3827781646781876,
> 1.0755168081687903, 1.2566273460024566, 1.3099622795250825,
> 1.357440924560318, 1.3519397370266515, 1.0927347979524134,
> 1.3566357346921618, 1.238800036669969, 1.2931730628634528, 1.048463407884969,
> 1.3779471642491719, 1.2978533797116658, 1.376230881554943, 1.166901202345226,
> 1.3690425182006263, 1.166901202345226, 1.2953476417603207,
> 1.0827945761165951, 1.2942406680885112, 1.224414840377028,
> 1.3910905417259205, 1.303231085263425, 1.348635183816037, 1.3750969645841487,
> 1.049648651501274, 1.3119534979602083, 1.0446033225080773,
> 1.0494686631294756, 1.3862026705844126, 1.2719496963348844,
> 1.3489938748102903, 1.3780468374004164, 1.3884878389662338,
> 1.3352682241994538, 1.3348722240568909, 1.3921944407986777,
> 1.0476833161122294, 1.0845460746754008, 1.344165352323966, 1.298548179079665,
> 1.1979240079667628, 1.3539078973394736, 1.3187287426697725,
> 1.082794576116595, 1.3779471642491719, 1.3771347858434184,
> 1.3921944407986777, 1.193793081523992, 1.362050393265006, 1.076638744462226,
> 1.3551174562135766, 1.3393693468578751, 1.2470361076952952,
> 1.3696023478216113, 1.3750969645841487, 1.2964734722088322,
> 1.2953476417603207, 1.2470361076952952, 1.382661263313539,
> 1.3862026705844126, 1.3771240109822156, 1.25443884328785, 1.3136690818105938,
> 1.3853832858443051, 1.3486351838160378, 1.348026557887345,
> 1.0604869883721861, 1.3352682241994536, 1.3480480718535308,
> 1.3363233390543028, 1.154658436584056, 1.3921944407986775,
> 1.1979240079667626, 1.3620503932650059, 1.0881358731694244,
> 1.369042518200626, 1.3532766470312723, 1.2890012831575908, 1.3735565244300663]
> and
> y = [1.1262991662205104, 1.3136690818105938, 1.0446033225080773,
> 1.3551174562135764, 1.3032310852634252, 1.3806258468851462,
> 1.227061245983, 1.2719496963348844, 1.3601566259413194,
> 1.3756888280688913, 1.3475322202511097, 1.1937930815239919,
> 1.0510872606482404, 1.3441653523239654, 1.359738761905118,
> 1.3382152957887032, 1.0766387444622263, 1.1937930815239919,
> 1.0820779503060238, 1.1448104521200428, 1.3853832858443051, 1.28757746537949,
> 1.298548179079665, 1.067255392172351, 1.3168701741293156, 1.3910905417259205,
> 1.2908594990421354, 1.3750969645841487, 1.329688765445783, 1.386649365275275,
> 1.285486511663053, 1.2566273460024566, 1.323664826995234, 1.3862730319705538,
> 1.049346328049449]
> which produce minDelta = 1.11022302462516E-016
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CONFIGURATION-653) ConfigurationUtils.dump and other methods should use ImmutableConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15898934#comment-15898934 ] Vincent Maurin commented on CONFIGURATION-653: -- I have attached a new patch : * a comment is added on the old method (expect for two that were already "might be deprecated") * I have reverted change on HierarchicalConfigurationConverter. It has a protected method and I don't see an easy way to preserve the compatibility here > ConfigurationUtils.dump and other methods should use ImmutableConfiguration > --- > > Key: CONFIGURATION-653 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-653 > Project: Commons Configuration > Issue Type: Bug >Affects Versions: 2.1, 2.1.1 >Reporter: Vincent Maurin >Priority: Minor > Attachments: two_versions.diff, use_immutable.diff > > > Since the read-only ImmutableConfiguration/ImmutableHierarchicalConfiguration > has been introduced, several methods that uses Configuration in a read-only > fashion should be adapted to use these ones instead of the read/write > alternative. > For example : > ConfigurationUtils.dump > ConfigurationUtils.toString > ConfigurationUtils.copy (for the source) > ConfigurationUtils.append (for the source) > ConfigurationUtils.convertToHierarchical > ConfigurationConverter.getProperties > ... and maybe others > It should not break any existing code as Configuration implements > ImmutableConfiguration and it could enable code that manipulates read only > configurations to use these utilities -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CONFIGURATION-653) ConfigurationUtils.dump and other methods should use ImmutableConfiguration
[ https://issues.apache.org/jira/browse/CONFIGURATION-653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Maurin updated CONFIGURATION-653: - Attachment: two_versions.diff > ConfigurationUtils.dump and other methods should use ImmutableConfiguration > --- > > Key: CONFIGURATION-653 > URL: https://issues.apache.org/jira/browse/CONFIGURATION-653 > Project: Commons Configuration > Issue Type: Bug >Affects Versions: 2.1, 2.1.1 >Reporter: Vincent Maurin >Priority: Minor > Attachments: two_versions.diff, use_immutable.diff > > > Since the read-only ImmutableConfiguration/ImmutableHierarchicalConfiguration > has been introduced, several methods that uses Configuration in a read-only > fashion should be adapted to use these ones instead of the read/write > alternative. > For example : > ConfigurationUtils.dump > ConfigurationUtils.toString > ConfigurationUtils.copy (for the source) > ConfigurationUtils.append (for the source) > ConfigurationUtils.convertToHierarchical > ConfigurationConverter.getProperties > ... and maybe others > It should not break any existing code as Configuration implements > ImmutableConfiguration and it could enable code that manipulates read only > configurations to use these utilities -- This message was sent by Atlassian JIRA (v6.3.15#6346)
