[jira] [Updated] (COMPRESS-36) Add Zip64 Suport
[ https://issues.apache.org/jira/browse/COMPRESS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated COMPRESS-36: --- Attachment: 5GB_of_Zeros_WindowsCompressedFolders.zip 5GB_of_Zeros_jar.zip 5GB_of_Zeros_7ZIP.zip Same file content as 5GB_of_Zeros.zip but generated by 7ZIP, Java7's jar (using jar cM) and Windows Compressed Folders feature on Win7. The Windows Compressed Folders archive uses compression method 9 (Deflate64) which we don't support. It is here only for reference right now. Add Zip64 Suport Key: COMPRESS-36 URL: https://issues.apache.org/jira/browse/COMPRESS-36 Project: Commons Compress Issue Type: New Feature Components: Archivers Reporter: Christian Grobmeier Assignee: Stefan Bodewig Fix For: 1.3 Attachments: 5GB_of_Zeros.zip, 5GB_of_Zeros_7ZIP.zip, 5GB_of_Zeros_WindowsCompressedFolders.zip, 5GB_of_Zeros_jar.zip, zip64-sample.zip Add Zip64 support. This will make it work to deal with zipfiles 2 GB. Planned for compress 1.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-36) Add Zip64 Suport
[ https://issues.apache.org/jira/browse/COMPRESS-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073499#comment-13073499 ] Stefan Bodewig commented on COMPRESS-36: http://people.apache.org/~bodewig/commons-compress/ now contains three more archives containing 100k files, generated by Windows Compressed Folders, 7ZIP and Java7's jar respectively. The current ZipArchiveInputStream code successfully reads all of them. Add Zip64 Suport Key: COMPRESS-36 URL: https://issues.apache.org/jira/browse/COMPRESS-36 Project: Commons Compress Issue Type: New Feature Components: Archivers Reporter: Christian Grobmeier Assignee: Stefan Bodewig Fix For: 1.3 Attachments: 5GB_of_Zeros.zip, 5GB_of_Zeros_7ZIP.zip, 5GB_of_Zeros_WindowsCompressedFolders.zip, 5GB_of_Zeros_jar.zip, zip64-sample.zip Add Zip64 support. This will make it work to deal with zipfiles 2 GB. Planned for compress 1.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MATH-639) numerical problems in rotation creation
numerical problems in rotation creation --- Key: MATH-639 URL: https://issues.apache.org/jira/browse/MATH-639 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Environment: Linux Reporter: Luc Maisonobe Assignee: Luc Maisonobe Fix For: 3.0 building a rotation from the following vector pairs leads to NaN: u1 = -4921140.837095533, -2.1512094250440013E7, -890093.279426377 u2 = -2.7238580938724895E9, -2.169664921341876E9, 6.749688708885301E10 v1 = 1, 0, 0 v2 = 0, 0, 1 The constructor first changes the (v1, v2) pair into (v1', v2') ensuring the following scalar products hold: v1'|v1' == u1|u1 v2'|v2' == u2|u2 u1 |u2 == v1'|v2' Once the (v1', v2') pair has been computed, we compute the cross product: k = (v1' - u1)^(v2' - u2) and the scalar product: c = k | (u1^u2) By construction, c is positive or null and the quaternion axis we want to build is q = k/[2*sqrt(c)]. c should be null only if some of the vectors are aligned, and this is dealt with later in the algorithm. However, there are numerical problems with the vector above with the way these computations are done, as shown by the following comparisons, showing the result we get from our Java code and the result we get from manual computation with the same formulas but with enhanced precision: commons math: k = 38514476.5,-84., -1168590144 high precision: k = 38514410.36093388..., -0.374075245201180409222711..., -1168590152.10599715208... and it becomes worse when computing c because the vectors are almost orthogonal to each other, hence inducing additional cancellations. We get: commons mathc = -1.2397173627587605E20 high precision: c = 558382746168463196.7079627... We have lost ALL significant digits in cancellations, and even the sign is wrong! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-639) numerical problems in rotation creation
[ https://issues.apache.org/jira/browse/MATH-639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073554#comment-13073554 ] Luc Maisonobe commented on MATH-639: The expected result quaternion computed to high precision manually and checked afterwards is: q0 = 0.62283703596082005783621150 q1 = 0.02577076214564987845778149 q2 = -0.025030122695149900 q3 = -0.78192703908611094998656730 numerical problems in rotation creation --- Key: MATH-639 URL: https://issues.apache.org/jira/browse/MATH-639 Project: Commons Math Issue Type: Bug Affects Versions: 2.2 Environment: Linux Reporter: Luc Maisonobe Assignee: Luc Maisonobe Fix For: 3.0 building a rotation from the following vector pairs leads to NaN: u1 = -4921140.837095533, -2.1512094250440013E7, -890093.279426377 u2 = -2.7238580938724895E9, -2.169664921341876E9, 6.749688708885301E10 v1 = 1, 0, 0 v2 = 0, 0, 1 The constructor first changes the (v1, v2) pair into (v1', v2') ensuring the following scalar products hold: v1'|v1' == u1|u1 v2'|v2' == u2|u2 u1 |u2 == v1'|v2' Once the (v1', v2') pair has been computed, we compute the cross product: k = (v1' - u1)^(v2' - u2) and the scalar product: c = k | (u1^u2) By construction, c is positive or null and the quaternion axis we want to build is q = k/[2*sqrt(c)]. c should be null only if some of the vectors are aligned, and this is dealt with later in the algorithm. However, there are numerical problems with the vector above with the way these computations are done, as shown by the following comparisons, showing the result we get from our Java code and the result we get from manual computation with the same formulas but with enhanced precision: commons math: k = 38514476.5,-84., -1168590144 high precision: k = 38514410.36093388..., -0.374075245201180409222711..., -1168590152.10599715208... and it becomes worse when computing c because the vectors are almost orthogonal to each other, hence inducing additional cancellations. We get: commons mathc = -1.2397173627587605E20 high precision: c = 558382746168463196.7079627... We have lost ALL significant digits in cancellations, and even the sign is wrong! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CONFIGURATION-458) SubnodeConfiguration.clear() does not work correctly
SubnodeConfiguration.clear() does not work correctly Key: CONFIGURATION-458 URL: https://issues.apache.org/jira/browse/CONFIGURATION-458 Project: Commons Configuration Issue Type: Bug Affects Versions: 1.6 Reporter: Oliver Heger If clear() is called on a SubnodeConfiguration obtained through the configurationAt() method of HierarchicalConfiguration, the node structure of the parent configuration (outside of the area of the sub configuration) may also be manipulated. Properties added to the SubnodeConfiguration after a clear() are not visible from the parent configuration. The problem is caused by the implementation of the clear() method inherited from AbstractConfiguration. This will call clearProperty() for each property found in the configuration. clearProperty() in turn clears the value of nodes and recursively clears the parent node if it does not contain any data. Here the structure owned by the SubnodeConfiguration can be left so that the parent gets manipulated. A possible solution would be to provide a specific implementation of clear() for hierarchical configurations. This could also be more efficient than the base implementation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DAEMON-211) [patch] make sure files get closed
[ https://issues.apache.org/jira/browse/DAEMON-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk resolved DAEMON-211. Resolution: Fixed Applied and will be part of 1.0.7. Thanks! [patch] make sure files get closed -- Key: DAEMON-211 URL: https://issues.apache.org/jira/browse/DAEMON-211 Project: Commons Daemon Issue Type: Improvement Affects Versions: 1.0.6 Reporter: Dave Brosius Priority: Trivial Fix For: Nightly Builds Attachments: closefile.diff code opens file to read properties but doesn't close it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DAEMON-213) procun log rotation support
[ https://issues.apache.org/jira/browse/DAEMON-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13073694#comment-13073694 ] Mladen Turk commented on DAEMON-213: Think this will not be possible since we redirect the stdout/stderr before loading JVM. After it is loaded JVM uses those descriptors to write to the console. The user application if desired should call System.setOut and System.setErr and manage the log rotation on its own. Think I'll mark this as WONTFIX unless someone figures out how to do it from the procrun. procun log rotation support --- Key: DAEMON-213 URL: https://issues.apache.org/jira/browse/DAEMON-213 Project: Commons Daemon Issue Type: Improvement Components: Procrun Affects Versions: 1.0.4, 1.0.5, 1.0.6 Environment: os: winxp Reporter: viola.lu Priority: Minor Fix For: Nightly Builds currently, procun doesn't support log rotation. Should add an option -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-213) procun log rotation support
[ https://issues.apache.org/jira/browse/DAEMON-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk updated DAEMON-213: --- Fix Version/s: Nightly Builds procun log rotation support --- Key: DAEMON-213 URL: https://issues.apache.org/jira/browse/DAEMON-213 Project: Commons Daemon Issue Type: Improvement Components: Procrun Affects Versions: 1.0.4, 1.0.5, 1.0.6 Environment: os: winxp Reporter: viola.lu Priority: Minor Fix For: Nightly Builds currently, procun doesn't support log rotation. Should add an option -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (DAEMON-211) [patch] make sure files get closed
[ https://issues.apache.org/jira/browse/DAEMON-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk updated DAEMON-211: --- Fix Version/s: (was: Nightly Builds) 1.0.7 [patch] make sure files get closed -- Key: DAEMON-211 URL: https://issues.apache.org/jira/browse/DAEMON-211 Project: Commons Daemon Issue Type: Improvement Affects Versions: 1.0.6 Reporter: Dave Brosius Priority: Trivial Fix For: 1.0.7 Attachments: closefile.diff code opens file to read properties but doesn't close it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-733) Add containsAny(CharSequence cs, CharSequence... searchChars) to StringUtils
[
https://issues.apache.org/jira/browse/LANG-733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-733:
---
Fix Version/s: (was: 3.0.1)
3.x
It would mean changing the containsAny(CharSequence, CharSequence) method; in
which the 2nd CharSequence acts as an array of single chars.
The second method, containsIgnoreCase(CharSequence, CharSequence...) seems
fair, and simple to implement. Need to confirm whether or not there's an effect
on binary compat.
(Moving to 3.x as no patches available yet/no decision that this should be
fixed yet)
Here's the full API for StringUtils.contains*. I've no idea why I missed the
containsOnly and containsNone String parameters. Ugh.
public static boolean contains(CharSequence seq, int searchChar) {
public static boolean contains(CharSequence seq, CharSequence searchSeq) {
public static boolean containsIgnoreCase(CharSequence str, CharSequence
searchStr) {
public static boolean containsWhitespace(CharSequence seq) {
public static boolean containsAny(CharSequence cs, char... searchChars) {
public static boolean containsAny(CharSequence cs, CharSequence
searchChars) {
public static boolean containsOnly(CharSequence cs, char... valid) {
public static boolean containsOnly(CharSequence cs, String validChars) {
public static boolean containsNone(CharSequence cs, char... searchChars) {
public static boolean containsNone(CharSequence cs, String invalidChars) {
Add containsAny(CharSequence cs, CharSequence... searchChars) to StringUtils
Key: LANG-733
URL: https://issues.apache.org/jira/browse/LANG-733
Project: Commons Lang
Issue Type: New Feature
Components: lang.*
Affects Versions: 3.0
Reporter: Eugen Paraschiv
Fix For: 3.x
This method is missing from StringUtils. The corresponding method:
public static boolean containsAny(CharSequence cs, char... searchChars) {
does exist, so this was probably just forgotten.
Also
public static boolean containsIgnoreCase(CharSequence str, CharSequence...
searchStr) {
needs to be added as well.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
