[jira] [Commented] (OGNL-38) [PATCH] Use StringBuilder instead of StringBuffer, deprecate =JDK1.5 conditionals and use CONSTANT.equals(variable).
[ https://issues.apache.org/jira/browse/OGNL-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145297#comment-13145297 ] Hudson commented on OGNL-38: Integrated in ognl #186 (See [https://builds.apache.org/job/ognl/186/]) OGNL-38 - Remove JDK1.5 checking since OGNL now requires =JDK1.5. The isJdk15() method is now deprecated. Variable naming (don't use acronyms. getPointerString(int) now uses StringBuilder instead of StringBuffer. getUniqueDescriptor(Object, boolean) now uses StringBuilder instead of StringBuffer. package private method findType() unused to removed. Simplify getMethods(Class?,boolean) with ternary. getStaticField(OgnlContext,String,String) test CONSTANT.equals(variable) and remove JDK1.5 conditionals. A lot of variable naming! OGNL-38 - Use StringBuilder instead of StringBuffer. OGNL-38 - Simplify conditionals. OGNL-38 - Test CONSTANT.equals(variable). OGNL-38 - Test CONSTANT.equals(variable). OGNL-38 - Test CONSTANT.equals(variable), remove JDK1.5 conditionals and variable naming. OGNL-38 - Variable naming (don't use acronyms), remove OgnlRuntime.isJdk15() check. OGNL-38 - Test CONSTANT.equals(variable). OGNL-38 - Test CONSTANT.equals(variable). mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198670 Files : * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/OgnlRuntime.java mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198668 Files : * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/OgnlOps.java mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198666 Files : * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/MapPropertyAccessor.java mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198665 Files : * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/IteratorPropertyAccessor.java mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198664 Files : * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/EnumerationPropertyAccessor.java mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198661 Files : * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/ASTStaticField.java mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198659 Files : * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/ASTMethod.java mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198657 Files : * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/ArrayPropertyAccessor.java mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198656 Files : * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/enhance/ExpressionCompiler.java [PATCH] Use StringBuilder instead of StringBuffer, deprecate =JDK1.5 conditionals and use CONSTANT.equals(variable). - Key: OGNL-38 URL: https://issues.apache.org/jira/browse/OGNL-38 Project: OGNL Issue Type: Improvement Reporter: Adrian Cumiskey Priority: Minor Attachments: patch-OGNL38.txt This patch replaces all StringBuffer references with StringBuilder for better performance. Improved performance has not been verified but it is fairly well established that StringBuilder performs better in single threaded use cases (see http://littletutorials.com/2008/07/16/stringbuffer-vs-stringbuilder-performance-comparison/). All JDK1.5 checking has also been deprecated/removed since OGNL is now dependent upon =JDK1.5 these days. Lastly, all remaining variable.equals(CONSTANT) has been flipped to the null safe CONSTANT.equals(variable). A list of modified classes and changes are given here :- MenuItem: toString() now uses a chained StringBuilder instead of StringBuffer. StaticsAndConstructorsTest: use StringBuilder instead of StringBuffer. EnumerationPropertyAccessor: Test CONSTANT.equals(variable). ExpressionCompiler: Test CONSTANT.equals(variable). ASTMethod: Variable naming (don't use acronyms), remove OgnlRuntime.isJdk15() check. OgnlRuntime: * Remove JDK1.5 checking since OGNL now requires =JDK1.5. * The isJdk15() method is now deprecated. * Variable naming (don't use acronyms. * getPointerString(int) now uses StringBuilder instead of StringBuffer. * getUniqueDescriptor(Object, boolean) now uses StringBuilder instead of StringBuffer. * package private method findType() unused to removed. * Simplify getMethods(Class?,boolean) with ternary. * getStaticField(OgnlContext,String,String) test CONSTANT.equals(variable) and remove JDK1.5 conditionals. * A lot of variable naming! SetPropertyAccessor: Test CONSTANT.equals(variable) and simplify conditionals. ASTStaticField: Test CONSTANT.equals(variable), remove JDK1.5 conditionals and variable
[jira] [Resolved] (OGNL-38) [PATCH] Use StringBuilder instead of StringBuffer, deprecate =JDK1.5 conditionals and use CONSTANT.equals(variable).
[ https://issues.apache.org/jira/browse/OGNL-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maurizio Cucchiara resolved OGNL-38. Resolution: Fixed Assignee: Maurizio Cucchiara Another good patch. Thank you, Adrian. [PATCH] Use StringBuilder instead of StringBuffer, deprecate =JDK1.5 conditionals and use CONSTANT.equals(variable). - Key: OGNL-38 URL: https://issues.apache.org/jira/browse/OGNL-38 Project: OGNL Issue Type: Improvement Reporter: Adrian Cumiskey Assignee: Maurizio Cucchiara Priority: Minor Attachments: patch-OGNL38.txt This patch replaces all StringBuffer references with StringBuilder for better performance. Improved performance has not been verified but it is fairly well established that StringBuilder performs better in single threaded use cases (see http://littletutorials.com/2008/07/16/stringbuffer-vs-stringbuilder-performance-comparison/). All JDK1.5 checking has also been deprecated/removed since OGNL is now dependent upon =JDK1.5 these days. Lastly, all remaining variable.equals(CONSTANT) has been flipped to the null safe CONSTANT.equals(variable). A list of modified classes and changes are given here :- MenuItem: toString() now uses a chained StringBuilder instead of StringBuffer. StaticsAndConstructorsTest: use StringBuilder instead of StringBuffer. EnumerationPropertyAccessor: Test CONSTANT.equals(variable). ExpressionCompiler: Test CONSTANT.equals(variable). ASTMethod: Variable naming (don't use acronyms), remove OgnlRuntime.isJdk15() check. OgnlRuntime: * Remove JDK1.5 checking since OGNL now requires =JDK1.5. * The isJdk15() method is now deprecated. * Variable naming (don't use acronyms. * getPointerString(int) now uses StringBuilder instead of StringBuffer. * getUniqueDescriptor(Object, boolean) now uses StringBuilder instead of StringBuffer. * package private method findType() unused to removed. * Simplify getMethods(Class?,boolean) with ternary. * getStaticField(OgnlContext,String,String) test CONSTANT.equals(variable) and remove JDK1.5 conditionals. * A lot of variable naming! SetPropertyAccessor: Test CONSTANT.equals(variable) and simplify conditionals. ASTStaticField: Test CONSTANT.equals(variable), remove JDK1.5 conditionals and variable naming. MapPropertyAccessor: Simplify conditionals. ArrayPropertyAccessor: Test CONSTANT.equals(variable). IteratorPropertyAccessor: Test CONSTANT.equals(variable). OgnlOps: Use StringBuilder instead of StringBuffer. ognl.jjt: Variable naming, use StringBuilder instead of StringBuffer. Replace new String(stringBuffer) with stringBuffer.toString(). Cheers, Adrian. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OGNL-38) [PATCH] Use StringBuilder instead of StringBuffer, deprecate =JDK1.5 conditionals and use CONSTANT.equals(variable).
[ https://issues.apache.org/jira/browse/OGNL-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145313#comment-13145313 ] Hudson commented on OGNL-38: Integrated in ognl #187 (See [https://builds.apache.org/job/ognl/187/]) Added OGNL-38 to the change list OGNL-38 - Use StringBuilder instead of StringBuffer, removed boxing, replaced for loop with foreach OGNL-38 - Use StringBuilder instead of StringBuffer. OGNL-38 - Variable naming, use StringBuilder instead of StringBuffer. Replace new String(stringBuffer) with stringBuffer.toString(). OGNL-38 - Variable naming, use StringBuilder instead of StringBuffer. Replace new String(stringBuffer) with stringBuffer.toString(). OGNL-38 - Test CONSTANT.equals(variable) and simplify conditionals. OGNL-38 - Removed useless extends object. mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198685 Files : * /commons/proper/ognl/trunk/src/changes/changes.xml mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198683 Files : * /commons/proper/ognl/trunk/src/test/java/org/apache/commons/ognl/test/StaticsAndConstructorsTest.java mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198682 Files : * /commons/proper/ognl/trunk/src/test/java/org/apache/commons/ognl/test/objects/MenuItem.java mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198681 Files : * /commons/proper/ognl/trunk/src/main/jjtree/ognl.jjt mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198680 Files : * /commons/proper/ognl/trunk/src/main/javacc/ognl.jj mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198679 Files : * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/SetPropertyAccessor.java mcucchiara : http://svn.apache.org/viewvc/?view=revrev=1198671 Files : * /commons/proper/ognl/trunk/src/main/java/org/apache/commons/ognl/OgnlRuntime.java [PATCH] Use StringBuilder instead of StringBuffer, deprecate =JDK1.5 conditionals and use CONSTANT.equals(variable). - Key: OGNL-38 URL: https://issues.apache.org/jira/browse/OGNL-38 Project: OGNL Issue Type: Improvement Reporter: Adrian Cumiskey Assignee: Maurizio Cucchiara Priority: Minor Attachments: patch-OGNL38.txt This patch replaces all StringBuffer references with StringBuilder for better performance. Improved performance has not been verified but it is fairly well established that StringBuilder performs better in single threaded use cases (see http://littletutorials.com/2008/07/16/stringbuffer-vs-stringbuilder-performance-comparison/). All JDK1.5 checking has also been deprecated/removed since OGNL is now dependent upon =JDK1.5 these days. Lastly, all remaining variable.equals(CONSTANT) has been flipped to the null safe CONSTANT.equals(variable). A list of modified classes and changes are given here :- MenuItem: toString() now uses a chained StringBuilder instead of StringBuffer. StaticsAndConstructorsTest: use StringBuilder instead of StringBuffer. EnumerationPropertyAccessor: Test CONSTANT.equals(variable). ExpressionCompiler: Test CONSTANT.equals(variable). ASTMethod: Variable naming (don't use acronyms), remove OgnlRuntime.isJdk15() check. OgnlRuntime: * Remove JDK1.5 checking since OGNL now requires =JDK1.5. * The isJdk15() method is now deprecated. * Variable naming (don't use acronyms. * getPointerString(int) now uses StringBuilder instead of StringBuffer. * getUniqueDescriptor(Object, boolean) now uses StringBuilder instead of StringBuffer. * package private method findType() unused to removed. * Simplify getMethods(Class?,boolean) with ternary. * getStaticField(OgnlContext,String,String) test CONSTANT.equals(variable) and remove JDK1.5 conditionals. * A lot of variable naming! SetPropertyAccessor: Test CONSTANT.equals(variable) and simplify conditionals. ASTStaticField: Test CONSTANT.equals(variable), remove JDK1.5 conditionals and variable naming. MapPropertyAccessor: Simplify conditionals. ArrayPropertyAccessor: Test CONSTANT.equals(variable). IteratorPropertyAccessor: Test CONSTANT.equals(variable). OgnlOps: Use StringBuilder instead of StringBuffer. ognl.jjt: Variable naming, use StringBuilder instead of StringBuffer. Replace new String(stringBuffer) with stringBuffer.toString(). Cheers, Adrian. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (VFS-179) Traversal of directory tree with FileSelector fails with symbolic links in SFTP
[ https://issues.apache.org/jira/browse/VFS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145320#comment-13145320 ] Kirill Safonov commented on VFS-179: There's a bug the the patch: one should call fileSystem.putChannel() in finally{} block otherwise SFTP connection will be open forever. This inevitably leads to 'Channel is not opened' errors once connection limit on server is reached. Traversal of directory tree with FileSelector fails with symbolic links in SFTP --- Key: VFS-179 URL: https://issues.apache.org/jira/browse/VFS-179 Project: Commons VFS Issue Type: Bug Reporter: Andrew Franklin Attachments: VFS-179.patch It seems to me that when using the FileSelector to traverse a directory tree using SFTP, a symbolic link will return as type File (even when the link points to a directory), which will result in the directory node not being followed. By using a mechanism similar to that of FtpFileObject this can be resolved with the following... {noformat} protected FileType doGetType() throws Exception { if (attrs == null) { statSelf(); } if (attrs == null) { return FileType.IMAGINARY; } if ((attrs.getFlags() SftpATTRS.SSH_FILEXFER_ATTR_PERMISSIONS) == 0) { throw new FileSystemException( vfs.provider.sftp/unknown-permissions.error); } if(attrs.isLink()) { return getLinkDestination().getType(); } else if (attrs.isDir()) { return FileType.FOLDER; } else { return FileType.FILE; } } /** * Return the destination of this file object if it's a symbolic link * @return FileObject representing the linked to location */ private FileObject getLinkDestination() throws Exception { if (linkDestination == null) { final String path = fileSystem.getChannel().readlink( relPath ); FileName relativeTo = getName().getParent(); if (relativeTo == null) { relativeTo = getName(); } FileName linkDestinationName = getFileSystem().getFileSystemManager().resolveName(relativeTo, path); linkDestination = getFileSystem().resolveFile(linkDestinationName); } return linkDestination; } {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (VFS-179) Traversal of directory tree with FileSelector fails with symbolic links in SFTP
[ https://issues.apache.org/jira/browse/VFS-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145320#comment-13145320 ] Kirill Safonov edited comment on VFS-179 at 11/7/11 10:27 AM: -- There's a bug in getLinkDestination() method: one should call fileSystem.putChannel() in finally{} block otherwise SFTP connection will be open forever. This inevitably leads to 'Channel is not opened' errors once connection limit on server is reached. was (Author: ksafonov): There's a bug the the patch: one should call fileSystem.putChannel() in finally{} block otherwise SFTP connection will be open forever. This inevitably leads to 'Channel is not opened' errors once connection limit on server is reached. Traversal of directory tree with FileSelector fails with symbolic links in SFTP --- Key: VFS-179 URL: https://issues.apache.org/jira/browse/VFS-179 Project: Commons VFS Issue Type: Bug Reporter: Andrew Franklin Attachments: VFS-179.patch It seems to me that when using the FileSelector to traverse a directory tree using SFTP, a symbolic link will return as type File (even when the link points to a directory), which will result in the directory node not being followed. By using a mechanism similar to that of FtpFileObject this can be resolved with the following... {noformat} protected FileType doGetType() throws Exception { if (attrs == null) { statSelf(); } if (attrs == null) { return FileType.IMAGINARY; } if ((attrs.getFlags() SftpATTRS.SSH_FILEXFER_ATTR_PERMISSIONS) == 0) { throw new FileSystemException( vfs.provider.sftp/unknown-permissions.error); } if(attrs.isLink()) { return getLinkDestination().getType(); } else if (attrs.isDir()) { return FileType.FOLDER; } else { return FileType.FILE; } } /** * Return the destination of this file object if it's a symbolic link * @return FileObject representing the linked to location */ private FileObject getLinkDestination() throws Exception { if (linkDestination == null) { final String path = fileSystem.getChannel().readlink( relPath ); FileName relativeTo = getName().getParent(); if (relativeTo == null) { relativeTo = getName(); } FileName linkDestinationName = getFileSystem().getFileSystemManager().resolveName(relativeTo, path); linkDestination = getFileSystem().resolveFile(linkDestinationName); } return linkDestination; } {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (VALIDATOR-299) POM misses dependency to oro
POM misses dependency to oro Key: VALIDATOR-299 URL: https://issues.apache.org/jira/browse/VALIDATOR-299 Project: Commons Validator Issue Type: Bug Components: Framework Affects Versions: 1.3.1 Release Reporter: Gregor B. Rosenauer when including commons-validator, you get Runtime errors that refer to the oro library, which is indeed referenced by commons-validator, but not declared in the POM. A fix is to manually include the ORO lib in your own POM, but that should be fixed in commons-validator's POM. {code:xml} dependency groupIdoro/groupId artifactIdoro/artifactId version2.0.8/version /dependency {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (NET-429) FTPClient storeFile method creates a file of 0 bytes
FTPClient storeFile method creates a file of 0 bytes Key: NET-429 URL: https://issues.apache.org/jira/browse/NET-429 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 3.0.1, 1.4 Environment: jdk1.6.0_27 Windows 7 Pro SP1 Reporter: Allen Atamer Using the FTPClient object in commons net the way it is shown in the Javadoc results in a file that is 0 bytes on the remote host. I've tried a number of different things 1. commons-net version 3.0.1 (supposedly had the bug fix for this, but didn't work for me) 2. [boolean] storeFile (String, InputStream) 3. [OutputStream] storeFile (String) 4. commons-net version 1.4 (still no dice) Here's my code: {quote} boolean error = false; FTPClient ftp = new FTPClient(); InputStream localStream = null; try { int reply; String server = ftp.myserver.com; ftp.connect(server, 21); System.out.println(Connected to + server + .); System.out.print(ftp.getReplyString()); // After connection attempt, you should check the reply code to // verify // success. reply = ftp.getReplyCode(); if (!FTPReply.isPositiveCompletion(reply)) { ftp.disconnect(); System.err.println(FTP server refused connection.); System.exit(1); } boolean wasSuccessful = ftp.login(user, password); if (!wasSuccessful) { System.err.println(Login unsuccessful); System.exit(1); } System.out.println(login successful); String localPath=C:/projects/TEMP/uga.html; File localFile = new File(localPath); if (localFile.exists()) { localStream = new BufferedInputStream(new FileInputStream(localPath)); wasSuccessful = ftp.storeFile(uga.html, localStream); if (!wasSuccessful) { System.err.println(could not store file: + localPath); System.exit(1); } else { System.out.println(Successfully saved file!); } } // transfer files ftp.logout(); } catch (IOException e) { error = true; e.printStackTrace(); } finally { if (ftp.isConnected()) { try { ftp.disconnect(); } catch (IOException ioe) { // do nothing } } if (localStream != null) { try { localStream.close(); } catch (IOException e) { } } System.exit(error ? 1 : 0); } {quote} Here's my System.out: {quote} Connected to ftp.harmari.com. 220-- Welcome to Pure-FTPd [privsep] [TLS] -- 220-You are user number 16 of 500 allowed. 220-Local time is now 05:59. Server port: 21. 220-This is a private system - No anonymous login 220 You will be disconnected after 3 minutes of inactivity. login successful could not store file: 2482049866.html {quote} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-429) FTPClient storeFile method creates a file of 0 bytes
[ https://issues.apache.org/jira/browse/NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Atamer updated NET-429: - Description: Using the FTPClient object in commons net the way it is shown in the Javadoc results in a file that is 0 bytes on the remote host. When you get to the storeFile(..) method, it waits for about 20 seconds before it returns the error message shown to System.out. I've tried a number of different things 1. commons-net version 3.0.1 (supposedly had the bug fix for this, but didn't work for me) 2. [boolean] storeFile (String, InputStream) 3. [OutputStream] storeFile (String) 4. commons-net version 1.4 (still no dice) Here's my code: {quote} boolean error = false; FTPClient ftp = new FTPClient(); InputStream localStream = null; try { int reply; String server = ftp.myserver.com; ftp.connect(server, 21); System.out.println(Connected to + server + .); System.out.print(ftp.getReplyString()); // After connection attempt, you should check the reply code to // verify // success. reply = ftp.getReplyCode(); if (!FTPReply.isPositiveCompletion(reply)) { ftp.disconnect(); System.err.println(FTP server refused connection.); System.exit(1); } boolean wasSuccessful = ftp.login(user, password); if (!wasSuccessful) { System.err.println(Login unsuccessful); System.exit(1); } System.out.println(login successful); String localPath=C:/projects/TEMP/uga.html; File localFile = new File(localPath); if (localFile.exists()) { localStream = new BufferedInputStream(new FileInputStream(localPath)); wasSuccessful = ftp.storeFile(uga.html, localStream); if (!wasSuccessful) { System.err.println(could not store file: + localPath); System.exit(1); } else { System.out.println(Successfully saved file!); } } // transfer files ftp.logout(); } catch (IOException e) { error = true; e.printStackTrace(); } finally { if (ftp.isConnected()) { try { ftp.disconnect(); } catch (IOException ioe) { // do nothing } } if (localStream != null) { try { localStream.close(); } catch (IOException e) { } } System.exit(error ? 1 : 0); } {quote} Here's my System.out: {quote} Connected to ftp.harmari.com. 220-- Welcome to Pure-FTPd [privsep] [TLS] -- 220-You are user number 16 of 500 allowed. 220-Local time is now 05:59. Server port: 21. 220-This is a private system - No anonymous login 220 You will be disconnected after 3 minutes of inactivity. login successful could not store file: 2482049866.html {quote} More background: FileZilla works on my machine I've also tried the primitive Sun API, and it works perfectly: {quote} try { url = new URL(ftp://harmari:U!jxm9...@ftp.harmari.com/offline3/uga.html;type=i;); URLConnection urlc = url.openConnection(); OutputStream os = urlc.getOutputStream(); // To upload String localPath = C:/projects/TEMP/uga.html; InputStream bis = new BufferedInputStream(new FileInputStream(localPath)); byte[] bstr = new byte[1024]; while (bis.read(bstr) 0) { os.write(bstr); } } catch (MalformedURLException e) {
[jira] [Updated] (NET-429) FTPClient storeFile method creates a file of 0 bytes
[ https://issues.apache.org/jira/browse/NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Atamer updated NET-429: - Environment: jdk1.6.0_27 Windows 7 Pro SP1 local machine Uploading to a GoDaddy Linux shared hosting environment. File is created with 0x604 permissions. was: jdk1.6.0_27 Windows 7 Pro SP1 FTPClient storeFile method creates a file of 0 bytes Key: NET-429 URL: https://issues.apache.org/jira/browse/NET-429 Project: Commons Net Issue Type: Bug Components: FTP Affects Versions: 1.4, 3.0.1 Environment: jdk1.6.0_27 Windows 7 Pro SP1 local machine Uploading to a GoDaddy Linux shared hosting environment. File is created with 0x604 permissions. Reporter: Allen Atamer Labels: bytes, ftp, storeFile, zero Using the FTPClient object in commons net the way it is shown in the Javadoc results in a file that is 0 bytes on the remote host. When you get to the storeFile(..) method, it waits for about 20 seconds before it returns the error message shown to System.out. I've tried a number of different things 1. commons-net version 3.0.1 (supposedly had the bug fix for this, but didn't work for me) 2. [boolean] storeFile (String, InputStream) 3. [OutputStream] storeFile (String) 4. commons-net version 1.4 (still no dice) Here's my code: {quote} boolean error = false; FTPClient ftp = new FTPClient(); InputStream localStream = null; try { int reply; String server = ftp.myserver.com; ftp.connect(server, 21); System.out.println(Connected to + server + .); System.out.print(ftp.getReplyString()); // After connection attempt, you should check the reply code to // verify // success. reply = ftp.getReplyCode(); if (!FTPReply.isPositiveCompletion(reply)) { ftp.disconnect(); System.err.println(FTP server refused connection.); System.exit(1); } boolean wasSuccessful = ftp.login(user, password); if (!wasSuccessful) { System.err.println(Login unsuccessful); System.exit(1); } System.out.println(login successful); String localPath=C:/projects/TEMP/uga.html; File localFile = new File(localPath); if (localFile.exists()) { localStream = new BufferedInputStream(new FileInputStream(localPath)); wasSuccessful = ftp.storeFile(uga.html, localStream); if (!wasSuccessful) { System.err.println(could not store file: + localPath); System.exit(1); } else { System.out.println(Successfully saved file!); } } // transfer files ftp.logout(); } catch (IOException e) { error = true; e.printStackTrace(); } finally { if (ftp.isConnected()) { try { ftp.disconnect(); } catch (IOException ioe) { // do nothing } } if (localStream != null) { try { localStream.close(); } catch (IOException e) { } } System.exit(error ? 1 : 0); } {quote} Here's my System.out: {quote} Connected to ftp.harmari.com. 220-- Welcome to Pure-FTPd [privsep] [TLS] -- 220-You are user number 16 of 500 allowed. 220-Local time is now 05:59. Server port: 21. 220-This is a private system - No anonymous login 220 You will be disconnected after 3 minutes of inactivity. login successful could not store file: 2482049866.html {quote} More background: FileZilla works on my machine I've also tried the primitive Sun API, and it works perfectly: {quote} try {
[jira] [Updated] (NET-429) FTPClient storeFile method creates a file of 0 bytes
[ https://issues.apache.org/jira/browse/NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Atamer updated NET-429: - Description: Using the FTPClient object in commons net the way it is shown in the Javadoc results in a file that is 0 bytes on the remote host. When you get to the storeFile(..) method, it waits for about 20 seconds before it returns the error message shown to System.out. I've tried a number of different things 1. commons-net version 3.0.1 (supposedly had the bug fix for this, but didn't work for me) 2. [boolean] storeFile (String, InputStream) 3. [OutputStream] storeFile (String) 4. commons-net version 1.4 (still no dice) 5. ftp.connect(server) and ftp.connect(server, 21) Here's my code: {quote} boolean error = false; FTPClient ftp = new FTPClient(); InputStream localStream = null; try { int reply; String server = ftp.myserver.com; ftp.connect(server, 21); System.out.println(Connected to + server + .); System.out.print(ftp.getReplyString()); // After connection attempt, you should check the reply code to // verify // success. reply = ftp.getReplyCode(); if (!FTPReply.isPositiveCompletion(reply)) { ftp.disconnect(); System.err.println(FTP server refused connection.); System.exit(1); } boolean wasSuccessful = ftp.login(user, password); if (!wasSuccessful) { System.err.println(Login unsuccessful); System.exit(1); } System.out.println(login successful); String localPath=C:/projects/TEMP/uga.html; File localFile = new File(localPath); if (localFile.exists()) { localStream = new BufferedInputStream(new FileInputStream(localPath)); wasSuccessful = ftp.storeFile(uga.html, localStream); if (!wasSuccessful) { System.err.println(could not store file: + localPath); System.exit(1); } else { System.out.println(Successfully saved file!); } } // transfer files ftp.logout(); } catch (IOException e) { error = true; e.printStackTrace(); } finally { if (ftp.isConnected()) { try { ftp.disconnect(); } catch (IOException ioe) { // do nothing } } if (localStream != null) { try { localStream.close(); } catch (IOException e) { } } System.exit(error ? 1 : 0); } {quote} Here's my System.out: {quote} Connected to ftp.harmari.com. 220-- Welcome to Pure-FTPd [privsep] [TLS] -- 220-You are user number 16 of 500 allowed. 220-Local time is now 05:59. Server port: 21. 220-This is a private system - No anonymous login 220 You will be disconnected after 3 minutes of inactivity. login successful could not store file: 2482049866.html {quote} More background: FileZilla works on my machine I've also tried the primitive Sun API, and it works perfectly: {quote} try { url = new URL(ftp://harmari:U!jxm9...@ftp.harmari.com/offline3/uga.html;type=i;); URLConnection urlc = url.openConnection(); OutputStream os = urlc.getOutputStream(); // To upload String localPath = C:/projects/TEMP/uga.html; InputStream bis = new BufferedInputStream(new FileInputStream(localPath)); byte[] bstr = new byte[1024]; while (bis.read(bstr) 0) { os.write(bstr); }
[jira] [Updated] (NET-429) FTPClient storeFile method creates a file of 0 bytes
[ https://issues.apache.org/jira/browse/NET-429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Allen Atamer updated NET-429: - Description: Using the FTPClient object in commons net the way it is shown in the Javadoc results in a file that is 0 bytes on the remote host. When you get to the storeFile(..) method, it waits for about 20 seconds before it returns the error message shown to System.out. I've tried a number of different things 1. commons-net version 3.0.1 (supposedly had the bug fix for this, but didn't work for me) 2. [boolean] storeFile (String, InputStream) 3. [OutputStream] storeFile (String) 4. commons-net version 1.4 (still no dice) 5. ftp.connect(server) and ftp.connect(server, 21) Here's my code: {quote} boolean error = false; FTPClient ftp = new FTPClient(); InputStream localStream = null; try { int reply; String server = ftp.myserver.com; ftp.connect(server, 21); System.out.println(Connected to + server + .); System.out.print(ftp.getReplyString()); // After connection attempt, you should check the reply code to // verify // success. reply = ftp.getReplyCode(); if (!FTPReply.isPositiveCompletion(reply)) { ftp.disconnect(); System.err.println(FTP server refused connection.); System.exit(1); } boolean wasSuccessful = ftp.login(user, password); if (!wasSuccessful) { System.err.println(Login unsuccessful); System.exit(1); } System.out.println(login successful); String localPath=C:/projects/TEMP/uga.html; File localFile = new File(localPath); if (localFile.exists()) { localStream = new BufferedInputStream(new FileInputStream(localPath)); wasSuccessful = ftp.storeFile(uga.html, localStream); if (!wasSuccessful) { System.err.println(could not store file: + localPath); System.exit(1); } else { System.out.println(Successfully saved file!); } } // transfer files ftp.logout(); } catch (IOException e) { error = true; e.printStackTrace(); } finally { if (ftp.isConnected()) { try { ftp.disconnect(); } catch (IOException ioe) { // do nothing } } if (localStream != null) { try { localStream.close(); } catch (IOException e) { } } System.exit(error ? 1 : 0); } {quote} Here's my System.out: {quote} Connected to ftp.harmari.com. 220-- Welcome to Pure-FTPd [privsep] [TLS] -- 220-You are user number 16 of 500 allowed. 220-Local time is now 05:59. Server port: 21. 220-This is a private system - No anonymous login 220 You will be disconnected after 3 minutes of inactivity. login successful could not store file: 2482049866.html {quote} More background: FileZilla works on my machine I've also tried the primitive Sun API, and it works perfectly: {quote} try { url = new URL(ftp://username:passw...@ftp.myserver.com/offline3/uga.html;type=i;); URLConnection urlc = url.openConnection(); OutputStream os = urlc.getOutputStream(); // To upload String localPath = C:/projects/TEMP/uga.html; InputStream bis = new BufferedInputStream(new FileInputStream(localPath)); byte[] bstr = new byte[1024]; while (bis.read(bstr) 0) { os.write(bstr); }
[jira] [Created] (MATH-702) CMA-ES optimizer input sigma should not be normalized by user
CMA-ES optimizer input sigma should not be normalized by user - Key: MATH-702 URL: https://issues.apache.org/jira/browse/MATH-702 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Luc Maisonobe Priority: Minor Fix For: 3.0 I am trying to use CMA-ES optimizer with simple boundaries. It seems the inputSigma parameter should be normalized as it is checked against the [0 - 1] range in the checkParameters private method and as its value defaults to 0.3 if not not set in the initializeCMA private method. I would have expected this value to be in the same units as the user parameters and to be normalized as part of an internal processing step instead of relying to the user doing this. I think the method need normalized values internally, as per the encode/decode methods in the inner class FitnessFunction suggest. The optimizer should accept values in the same units as the other parameters and use encode (or a similar function) to do the normalization. This way, normalization is considered an internal implementation detail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MATH-702) CMA-ES optimizer input sigma should not be normalized by user
[ https://issues.apache.org/jira/browse/MATH-702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Luc Maisonobe resolved MATH-702. Resolution: Fixed Fixed in subversion repository as of r1198741. CMA-ES optimizer input sigma should not be normalized by user - Key: MATH-702 URL: https://issues.apache.org/jira/browse/MATH-702 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Luc Maisonobe Priority: Minor Fix For: 3.0 I am trying to use CMA-ES optimizer with simple boundaries. It seems the inputSigma parameter should be normalized as it is checked against the [0 - 1] range in the checkParameters private method and as its value defaults to 0.3 if not not set in the initializeCMA private method. I would have expected this value to be in the same units as the user parameters and to be normalized as part of an internal processing step instead of relying to the user doing this. I think the method need normalized values internally, as per the encode/decode methods in the inner class FitnessFunction suggest. The optimizer should accept values in the same units as the other parameters and use encode (or a similar function) to do the normalization. This way, normalization is considered an internal implementation detail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (DIGESTER-158) Use the APT to process Digester Annotations and generate RulesModule instances at compile-time
[ https://issues.apache.org/jira/browse/DIGESTER-158?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145517#comment-13145517 ] Matt Benson commented on DIGESTER-158: -- No, not that I've heard. There is the com.sun.codemodel that more than one person has used; this is what my (again, untested) code uses. Use the APT to process Digester Annotations and generate RulesModule instances at compile-time -- Key: DIGESTER-158 URL: https://issues.apache.org/jira/browse/DIGESTER-158 Project: Commons Digester Issue Type: New Feature Affects Versions: 3.2 Reporter: Simone Tripodi Assignee: Simone Tripodi Fix For: 3.2 Using the [APT Tool|http://download.oracle.com/javase/1,5.0/docs/guide/apt/GettingStarted.html] it would be possible to process Digester annotations rules and generate {{RulesModule}} instances at compile time. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145544#comment-13145544 ] Phil Steitz commented on MATH-699: -- My inclination would be to keep the implementation in the base class as simple as possible, documenting what it does and pushing the responsibility for dealing with plateaus in the distribution to the implementations that have these. I don't think any of the currently implemented real distributions have this problem. Correct? The invariant you are proposing for when to return infinities for domain lower and upper bounds would make sense if these were intended to be the bounds of support for the distribution, but this is not what these properties represent. They are initial guesses for where to start when trying to bracket a root. That means they have to be values that can be fed into the cumulative probability function. Have you convinced yourself that we do not need to bracket a root at the beginning? What bounds would we then provide to the solver? The code you reference is trying to do the bracketing, starting with the domain upper and lower bounds as initial guesses. Remember to consider convergence problems when the actual parameter to inverse cum is close to or exactly equal to 0 or 1. Per the comment in the code above the test that uses (or should use) the function value absolute accuracy, if the distribution has bounded support and the argument is 0 or 1, bracketing will fail. inverseCumulativeDistribution fails with cumulative distribution having a plateau - Key: MATH-699 URL: https://issues.apache.org/jira/browse/MATH-699 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Sébastien Brisard Assignee: Sébastien Brisard Priority: Minor Attachments: AbstractContinuousDistributionTest.java This bug report follows MATH-692. The attached unit test fails. As required by the definition in MATH-692, the lower-bound of the interval on which the cdf is constant should be returned. This is not so at the moment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145544#comment-13145544 ] Phil Steitz edited comment on MATH-699 at 11/7/11 3:18 PM: --- My inclination would be to keep the implementation in the base class as simple as possible, documenting what it does and pushing the responsibility for dealing with plateaus in the distribution to the implementations that have these. I don't think any of the currently implemented real distributions have this problem. Correct? The invariant you are proposing for when to return infinities for domain lower and upper bounds would make sense if these were intended to be the bounds of support for the distribution, but this is not what these properties represent. They are initial guesses for where to start when trying to bracket a root. That means they have to be values that can be fed into the cumulative probability function. I may be missing the point that you and Christian are making, but the basic problem is that as Christian points out, we always need to start with finite values and that is what led to the somewhat inelegant construct of the domain lower/upper bounds as guesses and the need to do the bracketing step. The code you reference is trying to do the bracketing, starting with the domain upper and lower bounds as initial guesses. Remember to consider convergence problems when the actual parameter to inverse cum is close to or exactly equal to 0 or 1. Per the comment in the code above the test that uses (or should use) the function value absolute accuracy, if the distribution has bounded support and the argument is 0 or 1, bracketing will fail. was (Author: psteitz): My inclination would be to keep the implementation in the base class as simple as possible, documenting what it does and pushing the responsibility for dealing with plateaus in the distribution to the implementations that have these. I don't think any of the currently implemented real distributions have this problem. Correct? The invariant you are proposing for when to return infinities for domain lower and upper bounds would make sense if these were intended to be the bounds of support for the distribution, but this is not what these properties represent. They are initial guesses for where to start when trying to bracket a root. That means they have to be values that can be fed into the cumulative probability function. Have you convinced yourself that we do not need to bracket a root at the beginning? What bounds would we then provide to the solver? The code you reference is trying to do the bracketing, starting with the domain upper and lower bounds as initial guesses. Remember to consider convergence problems when the actual parameter to inverse cum is close to or exactly equal to 0 or 1. Per the comment in the code above the test that uses (or should use) the function value absolute accuracy, if the distribution has bounded support and the argument is 0 or 1, bracketing will fail. inverseCumulativeDistribution fails with cumulative distribution having a plateau - Key: MATH-699 URL: https://issues.apache.org/jira/browse/MATH-699 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Sébastien Brisard Assignee: Sébastien Brisard Priority: Minor Attachments: AbstractContinuousDistributionTest.java This bug report follows MATH-692. The attached unit test fails. As required by the definition in MATH-692, the lower-bound of the interval on which the cdf is constant should be returned. This is not so at the moment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DAEMON-227) Support both flavors of Java on HP-UX IA64
[ https://issues.apache.org/jira/browse/DAEMON-227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk resolved DAEMON-227. Resolution: Fixed Fix Version/s: 1.0.8 Fixed HP-UX configure on IA64 For 32-bit use ./configure --build i386-hp-hpux11 For 64-bit use ./configure Support both flavors of Java on HP-UX IA64 -- Key: DAEMON-227 URL: https://issues.apache.org/jira/browse/DAEMON-227 Project: Commons Daemon Issue Type: Improvement Components: Jsvc Affects Versions: Nightly Builds Reporter: Michael Osipov Assignee: Mladen Turk Priority: Minor Fix For: 1.0.8 Attachments: DAEMON-227.patch Compared to Linux and other OS on IA64, HP delivers two types of JVMs in IA64. A normal (32 bit) and a wide (64 bit). Any binary or lib can be compiled that way. {noformat} smartld@blnn721x - /opt/java6/jre/lib bash $ ll | grep '^d' dr-xr-xr-x 19 binbin 8192 Jun 28 12:20 ./ dr-xr-xr-x 8 binbin 8192 Jan 22 2009 ../ dr-xr-xr-x 8 binbin 8192 Jun 28 12:20 IA64N/ dr-xr-xr-x 8 binbin 8192 Jun 28 12:20 IA64W/ dr-xr-xr-x 3 binbin 96 Dec 4 2007 PA_RISC2.0/ dr-xr-xr-x 2 binbin 96 Oct 16 2009 applet/ dr-xr-xr-x 2 binbin 96 Dec 4 2007 audio/ ... {noformat} The apsupport.m4 does not reflect that in ia64). I have adapted it to support both options. Default is 32 bit build on HP-UX 64 bit can be enabled with a switch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-161) bzip2 decompression terminates after 900000 bytes
[ https://issues.apache.org/jira/browse/COMPRESS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145550#comment-13145550 ] Stefan Bodewig commented on COMPRESS-161: - I can confirm the limit with the file you have attached. At the same time I can easily uncompress even larger files completely so there must be something specific to the archive you are using. Any hints on how you have created it? bzip2 decompression terminates after 90 bytes - Key: COMPRESS-161 URL: https://issues.apache.org/jira/browse/COMPRESS-161 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.3 Environment: Windows7 64bit JDK7u1,2 Reporter: Hans horn Priority: Critical Fix For: 1.3 Attachments: INT1_aminey.inp.bz2 bzip2 decompression terminates (w/o error) after 90 bytes try { InputStream iin = new BZip2CompressorInputStream(new FileInputStream(bzip2 compressed file that was uncompressed 90 bytes in size); int data = iin.read(); while (data != -1) { System.out.print((char) data); ++nBytes; data = iin.read(); } } catch (IOException iox) { /**/ } System.out.println(#Bytes read + nBytes); prints: #Bytes read 90 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DAEMON-228) Add default location of JDK and libjvm on HP-UX IA64
[ https://issues.apache.org/jira/browse/DAEMON-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk resolved DAEMON-228. Resolution: Fixed Fix Version/s: 1.0.8 Fixed by using correct CPU and new SO_EXT inside configure. Added some parts from your patch like /opt/java* stuff Add default location of JDK and libjvm on HP-UX IA64 Key: DAEMON-228 URL: https://issues.apache.org/jira/browse/DAEMON-228 Project: Commons Daemon Issue Type: Improvement Components: Jsvc Affects Versions: Nightly Builds Reporter: Michael Osipov Assignee: Mladen Turk Priority: Minor Fix For: 1.0.8 Attachments: DAEMON-228.patch 1. Added two more recent JDK locations. 2. libraries on IA64 end with .so and PA-RISC on .sl. I have added a further flag to switch between these. {noformat} smartld@blnn721x - /opt/java6/jre/lib/IA64N/server bash $ ll total 308976 -r-xr-xr-x 1 binbin76798188 May 11 2010 #libjvm.so* dr-xr-xr-x 2 binbin 8192 Jun 28 12:20 ./ dr-xr-xr-x 8 binbin 8192 Jun 28 12:20 ../ -r--r--r-- 1 binbin 2400 Mar 11 2011 Xusage.txt lr-xr-xr-x 1 binbin 13 Jun 28 12:20 libjsig.so@ - ../libjsig.so -r-xr-xr-x 1 binbin 234296 Mar 11 2011 libjunwind.so* -r-xr-xr-x 1 binbin 238304 Mar 11 2011 libjunwind64.so* -r-xr-xr-x 1 binbin80868772 Mar 11 2011 libjvm.so* {noformat} This patch includes DAEMON-227. If 227 is applied separately, I can recreate this patch. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DAEMON-136) Jsvc does not exit when all non-daemon threads are died
[ https://issues.apache.org/jira/browse/DAEMON-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk resolved DAEMON-136. Resolution: Incomplete Please provide a test case so we can verify your claims. I'm closing this issue, but you are free to reopen it wit something we can use for testing Jsvc does not exit when all non-daemon threads are died --- Key: DAEMON-136 URL: https://issues.apache.org/jira/browse/DAEMON-136 Project: Commons Daemon Issue Type: Bug Components: Jsvc Affects Versions: 1.0.2 Environment: Ubuntu 9.10, Sun Java 1.6.0_16 Reporter: Hontvari Jozsef Priority: Minor Attachments: stack, stack-long, stack-mixed-long A jsvc dameon keeps running even if all non-dameon Java threads are exited. It can be reproduced by creating a start class with the usual four, but empty functions. The symtom does not change if init() takes a few seconds of time. I have attached three stack traces, using different jstack options, I don't see anything special, however. The workaround is to explicitly call System.exit() at places where the system can finish its work. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-111) support for lzma files
[ https://issues.apache.org/jira/browse/COMPRESS-111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145564#comment-13145564 ] Stefan Bodewig commented on COMPRESS-111: - I think support for the old lzma format would be beneficial for all people having to deal with legacy archives, so at least read-only support would be great. Then again adding write support won't hurt either. We could recommend people use XZ instead inside the docs, of course. support for lzma files -- Key: COMPRESS-111 URL: https://issues.apache.org/jira/browse/COMPRESS-111 Project: Commons Compress Issue Type: New Feature Components: Compressors Affects Versions: 1.0 Reporter: maurel jean francois Attachments: compress-trunk-lzmaRev0.patch, compress-trunk-lzmaRev1.patch adding support for compressing and decompressing of files with LZMA algoritm (Lempel-Ziv-Markov chain-Algorithm) (see http://markmail.org/search/?q=list%3Aorg.apache.commons.users/#query:list%3Aorg.apache.commons.users%2F+page:1+mid:syn4uuvbzusevtko+state:results) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (DAEMON-216) Add command line switch to hide console window when switch --type interactive is used.
[ https://issues.apache.org/jira/browse/DAEMON-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mladen Turk resolved DAEMON-216. Resolution: Fixed Fix Version/s: 1.0.8 Fixed in the trunk. AllocConsole is now followed by ShowWindow(GetConsoleWindow(), SW_HIDE) This will cause invisible console window which shouldn't be displayed from the service anyhow. Not because its ugly, but because user can hit CTRL+C and close the service Add command line switch to hide console window when switch --type interactive is used. Key: DAEMON-216 URL: https://issues.apache.org/jira/browse/DAEMON-216 Project: Commons Daemon Issue Type: New Feature Components: Procrun Environment: windows family Reporter: Kurt Järmann Priority: Minor Fix For: 1.0.8 I have a Java Service and it is creating a tasktray. This only works with the switch --type interactive but its creating a not needed console window to fetch user input. I wish a switch to hide the unwanted window. Thank you for your efforts. Kurt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-161) bzip2 decompression terminates after 900000 bytes
[ https://issues.apache.org/jira/browse/COMPRESS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145574#comment-13145574 ] Hans horn commented on COMPRESS-161: Stefan, I probably compressed it using cygwin's pbzip2 in August when I started to run out of disk space. I just unpacked that file and repacked it using the non-parallel version of cygwin bzip2 and it decompresses just fine with Commons Compress! Nice catch, Stefan What now? I've got about 500GB of stuff compressed that way, that has become inaccessible to Java. Are there any plans to support multiple concatenated streams in Commons Compress in the not so distant future? Thx., H. bzip2 decompression terminates after 90 bytes - Key: COMPRESS-161 URL: https://issues.apache.org/jira/browse/COMPRESS-161 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.3 Environment: Windows7 64bit JDK7u1,2 Reporter: Hans horn Priority: Critical Fix For: 1.3 Attachments: INT1_aminey.inp.bz2 bzip2 decompression terminates (w/o error) after 90 bytes try { InputStream iin = new BZip2CompressorInputStream(new FileInputStream(bzip2 compressed file that was uncompressed 90 bytes in size); int data = iin.read(); while (data != -1) { System.out.print((char) data); ++nBytes; data = iin.read(); } } catch (IOException iox) { /**/ } System.out.println(#Bytes read + nBytes); prints: #Bytes read 90 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COMPRESS-161) bzip2 decompression terminates after 900000 bytes
[ https://issues.apache.org/jira/browse/COMPRESS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145592#comment-13145592 ] Stefan Bodewig commented on COMPRESS-161: - COMPRESS-146 has got a patch attached that I'll look into. If it fixes the problem with your archive I'm going to commit it. bzip2 decompression terminates after 90 bytes - Key: COMPRESS-161 URL: https://issues.apache.org/jira/browse/COMPRESS-161 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.3 Environment: Windows7 64bit JDK7u1,2 Reporter: Hans horn Priority: Critical Fix For: 1.3 Attachments: INT1_aminey.inp.bz2 bzip2 decompression terminates (w/o error) after 90 bytes try { InputStream iin = new BZip2CompressorInputStream(new FileInputStream(bzip2 compressed file that was uncompressed 90 bytes in size); int data = iin.read(); while (data != -1) { System.out.print((char) data); ++nBytes; data = iin.read(); } } catch (IOException iox) { /**/ } System.out.println(#Bytes read + nBytes); prints: #Bytes read 90 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145596#comment-13145596 ] Sebb commented on IO-291: - bq. No tabs. The file io-291-simple.diff still contains some tabs. By the way, when uploading a replacement patch, please delete any file(s) that are totally superseded by the new patch. Unfortunately JIRA does not have any way to mark patches as obsolete. Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: FileUtils.isContained.patch, io-291-simple.diff, io-291-v4.patch, io-291.diff I added a function that determines whether the specified leaf is contains by the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (COMPRESS-146) BZip2CompressorInputStream always treats 0x177245385090 as EOF, but should treat this as EOS
[ https://issues.apache.org/jira/browse/COMPRESS-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-146. - Resolution: Fixed Fix Version/s: 1.4 applied Lasse's patch with a small modification. The default constructor will not support concatenated streams for maximum backwards compatibility. This will need some docs that I'm going to add once I've looked into the similar patch by Lasse for gzip as well. Thanks! BZip2CompressorInputStream always treats 0x177245385090 as EOF, but should treat this as EOS Key: COMPRESS-146 URL: https://issues.apache.org/jira/browse/COMPRESS-146 Project: Commons Compress Issue Type: Bug Components: Compressors Environment: all Reporter: Dmitriy Smirnov Priority: Critical Labels: 0x177245385090 Fix For: 1.4 Attachments: bzip2-concatenated.patch Original Estimate: 4h Remaining Estimate: 4h BZip2CompressorInputStream always treats 0x177245385090 as EOF, but should treat this as EOS This error occurs mostly on large size files as sudden EOF somwere in the middle of the file. An example of data from archived file: $ cat fastq.ax.bz2 | od -t x1 | grep -A 1 '17 72 45' 22711660 d0 ff b6 01 20 10 ff ff 17 72 45 38 50 90 2e ff 22711700 b2 d3 42 5a 68 39 31 41 59 26 53 59 84 3c 41 75 -- 24637020 c5 49 ff 19 80 49 20 7f ff 17 72 45 38 50 90 a4 24637040 a8 ac bd 42 5a 68 39 31 41 59 26 53 59 0d 9a b4 -- 40302720 ff b1 24 80 10 ff ff 17 72 45 38 50 90 24 cb c5 40302740 90 42 5a 68 39 31 41 59 26 53 59 42 05 ae 5e 05 . Suggested solution: private void initBlock() throws IOException { char magic0 = bsGetUByte(); char magic1 = bsGetUByte(); char magic2 = bsGetUByte(); char magic3 = bsGetUByte(); char magic4 = bsGetUByte(); char magic5 = bsGetUByte(); if( magic0 == 0x17 magic1 == 0x72 magic2 == 0x45 magic3 == 0x38 magic4 == 0x50 magic5 == 0x90 ) { if( complete() ) // end of file); { return; } else { magic0 = bsGetUByte(); magic1 = bsGetUByte(); magic2 = bsGetUByte(); magic3 = bsGetUByte(); magic4 = bsGetUByte(); magic5 = bsGetUByte(); } } if (magic0 != 0x31 || // '1' magic1 != 0x41 || // 'A' magic2 != 0x59 || // 'Y' magic3 != 0x26 || // '' magic4 != 0x53 || // 'S' magic5 != 0x59 // 'Y' ) { this.currentState = EOF; throw new IOException(bad block header); } else { this.storedBlockCRC = bsGetInt(); this.blockRandomised = bsR(1) == 1; /** * Allocate data here instead in constructor, so we do not allocate * it if the input file is empty. */ if (this.data == null) { this.data = new Data(this.blockSize100k); } // currBlockNo++; getAndMoveToFrontDecode(); this.crc.initialiseCRC(); this.currentState = START_BLOCK_STATE; } } private boolean complete() throws IOException { boolean result = false; this.storedCombinedCRC = bsGetInt(); try { if (in.available() == 0 ) { throw new IOException( EOF ); } checkMagicChar('B', first); checkMagicChar('Z', second); checkMagicChar('h', third); int blockSize = this.in.read(); if ((blockSize '1') || (blockSize '9')) { throw new IOException(Stream is not BZip2 formatted: illegal + blocksize + (char) blockSize); } this.blockSize100k = blockSize - '0'; this.bsLive = 0; this.bsBuff = 0; } catch( IOException e ) { this.currentState = EOF; result = true; } this.data = null; if (this.storedCombinedCRC != this.computedCombinedCRC) { throw new IOException(BZip2 CRC error); } this.computedCombinedCRC = 0; return result; } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators:
[jira] [Resolved] (COMPRESS-161) bzip2 decompression terminates after 900000 bytes
[ https://issues.apache.org/jira/browse/COMPRESS-161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved COMPRESS-161. - Resolution: Duplicate Fix Version/s: (was: 1.3) 1.4 This is COMPRESS-146 which has just been fixed. In order to make it work you must use the new two-arg constructor of the stream and pass in true as second argument. bzip2 decompression terminates after 90 bytes - Key: COMPRESS-161 URL: https://issues.apache.org/jira/browse/COMPRESS-161 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.3 Environment: Windows7 64bit JDK7u1,2 Reporter: Hans horn Priority: Critical Fix For: 1.4 Attachments: INT1_aminey.inp.bz2 bzip2 decompression terminates (w/o error) after 90 bytes try { InputStream iin = new BZip2CompressorInputStream(new FileInputStream(bzip2 compressed file that was uncompressed 90 bytes in size); int data = iin.read(); while (data != -1) { System.out.print((char) data); ++nBytes; data = iin.read(); } } catch (IOException iox) { /**/ } System.out.println(#Bytes read + nBytes); prints: #Bytes read 90 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: (was: io-291.diff) Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: FileUtils.isContained.patch, io-291-simple.diff, io-291-v4.patch I added a function that determines whether the specified leaf is contains by the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: (was: io-291-simple.diff) Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: FileUtils.isContained.patch, io-291-simple.diff, io-291-v4.patch I added a function that determines whether the specified leaf is contains by the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Attachment: io-291-simple.diff Let's try again: Attached is a much simpler implementation that works with: Unrealized File objects No recursion. Correct Javadoc No tabs. Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: FileUtils.isContained.patch, io-291-simple.diff, io-291-v4.patch I added a function that determines whether the specified leaf is contains by the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145718#comment-13145718 ] Sébastien Brisard commented on MATH-699: {quote} I don't think any of the currently implemented real distributions have this problem. Correct? {quote} Maybe I misunderstood, but in MATH-692 asked for a more precise definition of {{inverseCumulativeProbability}} as inf{x in R | P(X=x) = p}. If we exclude distribution with plateaus, I think that the current implementation is satisfactory (but for the use of the wrong tolerance I've already pointed out). But it was agreed that this implementation should be made more robust. So what was it exactly that needed improvement? What do you want me to do on this method? {quote} They are initial guesses for where to start when trying to bracket a root. That means they have to be values that can be fed into the cumulative probability function. {quote} I'm aware of that, but the current solver does fail when {{inverseCumulativeProbability(0)}} should return -inf, or {{inverseCumulativeProbability(1)}} should return +inf. See for example the implementation of {{NormalDistributionImpl}}. {code:java} public double inverseCumulativeProbability(final double p) { if (p == 0) { return Double.NEGATIVE_INFINITY; } if (p == 1) { return Double.POSITIVE_INFINITY; } return super.inverseCumulativeProbability(p); } {code} So currently, people who want to implement a distribution must be aware of the fact that the default implementation of {{inverseCumulativeProbability}} *must* be overriden. This rather unusual fact should be made clear in the Javadoc, unless a workaround can be thought of. I agree the one I proposed was far from perfect. {quote} Remember to consider convergence problems when the actual parameter to inverse cum is close to or exactly equal to 0 or 1. {quote} Thank you for pointing this out earlier. I do keep this important point in mind. But again, if we do not widen the scope of this method, I don't see what is required of me (appart from some cosmetic alterations to the Javadoc). inverseCumulativeDistribution fails with cumulative distribution having a plateau - Key: MATH-699 URL: https://issues.apache.org/jira/browse/MATH-699 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Sébastien Brisard Assignee: Sébastien Brisard Priority: Minor Attachments: AbstractContinuousDistributionTest.java This bug report follows MATH-692. The attached unit test fails. As required by the definition in MATH-692, the lower-bound of the interval on which the cdf is constant should be returned. This is not so at the moment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Created] (MATH-702) CMA-ES optimizer input sigma should not be normalized by user
good point. However, if the encoding/decoding methods can be defined coordinate-wise differently or are even non-linear (I am not aware whether they can be or not), I am not sure you can come up with a sufficiently reasonable and comprehensible way to apply this transformation to sigma. sigma is a scalar and positive, so it is a different object than the encoding/decoding methods are operating on, right? The interplay between sigma and an encoding is an unfortunately delicate part in the user interface, but I don't really see a way to make it right *and* look entirely obvious to the user. On Mon, 07 Nov 2011 14:48:51 +0100, Luc Maisonobe (Created) (JIRA) j...@apache.org wrote: CMA-ES optimizer input sigma should not be normalized by user - Key: MATH-702 URL: https://issues.apache.org/jira/browse/MATH-702 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Luc Maisonobe Priority: Minor Fix For: 3.0 I am trying to use CMA-ES optimizer with simple boundaries. It seems the inputSigma parameter should be normalized as it is checked against the [0 - 1] range in the checkParameters private method and as its value defaults to 0.3 if not not set in the initializeCMA private method. I would have expected this value to be in the same units as the user parameters and to be normalized as part of an internal processing step instead of relying to the user doing this. I think the method need normalized values internally, as per the encode/decode methods in the inner class FitnessFunction suggest. The optimizer should accept values in the same units as the other parameters and use encode (or a similar function) to do the normalization. This way, normalization is considered an internal implementation detail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira -- Science is a way of trying not to fool yourself. The first principle is that you must not fool yourself, and you are the easiest person to fool. So you have to be very careful about that. After you've not fooled yourself, it's easy not to fool other[ scientist]s. You just have to be honest in a conventional way after that. -- Richard P. Feynman Nikolaus Hansen INRIA, Research Centre Saclay – Ile-de-France Machine Learning and Optimization group (TAO) University Paris-Sud (Orsay) LRI (UMR 8623), building 490 91405 ORSAY Cedex, France Phone: +33-1-691-56495, Fax: +33-1-691-54240 URL: http://www.lri.fr/~hansen
[jira] [Commented] (MATH-702) CMA-ES optimizer input sigma should not be normalized by user
[ https://issues.apache.org/jira/browse/MATH-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145736#comment-13145736 ] Nikolaus Hansen commented on MATH-702: -- good point. However, if the encoding/decoding methods can be defined coordinate-wise differently or are even non-linear (I am not aware whether they can be or not), I am not sure you can come up with a sufficiently reasonable and comprehensible way to apply this transformation to sigma. sigma is a scalar and positive, so it is a different object than the encoding/decoding methods are operating on, right? The interplay between sigma and an encoding is an unfortunately delicate part in the user interface, but I don't really see a way to make it right *and* look entirely obvious to the user. On Mon, 07 Nov 2011 14:48:51 +0100, Luc Maisonobe (Created) (JIRA) -- Science is a way of trying not to fool yourself. The first principle is that you must not fool yourself, and you are the easiest person to fool. So you have to be very careful about that. After you've not fooled yourself, it's easy not to fool other[ scientist]s. You just have to be honest in a conventional way after that. -- Richard P. Feynman Nikolaus Hansen INRIA, Research Centre Saclay – Ile-de-France Machine Learning and Optimization group (TAO) University Paris-Sud (Orsay) LRI (UMR 8623), building 490 91405 ORSAY Cedex, France Phone: +33-1-691-56495, Fax: +33-1-691-54240 URL: http://www.lri.fr/~hansen CMA-ES optimizer input sigma should not be normalized by user - Key: MATH-702 URL: https://issues.apache.org/jira/browse/MATH-702 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Luc Maisonobe Priority: Minor Fix For: 3.0 I am trying to use CMA-ES optimizer with simple boundaries. It seems the inputSigma parameter should be normalized as it is checked against the [0 - 1] range in the checkParameters private method and as its value defaults to 0.3 if not not set in the initializeCMA private method. I would have expected this value to be in the same units as the user parameters and to be normalized as part of an internal processing step instead of relying to the user doing this. I think the method need normalized values internally, as per the encode/decode methods in the inner class FitnessFunction suggest. The optimizer should accept values in the same units as the other parameters and use encode (or a similar function) to do the normalization. This way, normalization is considered an internal implementation detail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-702) CMA-ES optimizer input sigma should not be normalized by user
[ https://issues.apache.org/jira/browse/MATH-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145744#comment-13145744 ] Luc Maisonobe commented on MATH-702: You are right. for now, encoding/decoding is both liner only and hidden in a private inner class (FitnessFunction), so users only see simple bounds and inside these bounds the transform is linear. For sure if we come up with a different mapping, we will need to come up with a way to define also the mapping of covariance. One way would be to rely on the Jacobian, but it would be strange to propose mapping function and requiring them to be smooth while the goal function by itself could be highly non-smooth. So for now, the simple linear mapping seems sufficient to me, and would need improvement only if we change some internals of the class. CMA-ES optimizer input sigma should not be normalized by user - Key: MATH-702 URL: https://issues.apache.org/jira/browse/MATH-702 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Luc Maisonobe Priority: Minor Fix For: 3.0 I am trying to use CMA-ES optimizer with simple boundaries. It seems the inputSigma parameter should be normalized as it is checked against the [0 - 1] range in the checkParameters private method and as its value defaults to 0.3 if not not set in the initializeCMA private method. I would have expected this value to be in the same units as the user parameters and to be normalized as part of an internal processing step instead of relying to the user doing this. I think the method need normalized values internally, as per the encode/decode methods in the inner class FitnessFunction suggest. The optimizer should accept values in the same units as the other parameters and use encode (or a similar function) to do the normalization. This way, normalization is considered an internal implementation detail. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-470) Extract classes generated by JavaCC
[ https://issues.apache.org/jira/browse/CONFIGURATION-470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13145928#comment-13145928 ] Emmanuel Bourg commented on CONFIGURATION-470: -- I preferred keeping the generated files, they could have been excluded from checkstyle and findbugs if that was an issue. Now the build is slower and my IDE complains about missing classes :( Extract classes generated by JavaCC --- Key: CONFIGURATION-470 URL: https://issues.apache.org/jira/browse/CONFIGURATION-470 Project: Commons Configuration Issue Type: Improvement Components: Build Affects Versions: 1.7 Reporter: Oliver Heger Assignee: Oliver Heger Priority: Minor Fix For: 1.8 In the plist package classes generated by JavaCC are used to parse specific configuration files. Currently these files are stored in SVN like regular source files. This does not conform to best practices, is confusing, and requires a special treatment in the configuration of tools like checkstyle or findbugs. It would be better to let these files be generated during the build process by the maven JavaCC plug-in. A working configuration can kindly be borrowed from the OGNL component. The additional generation step should not slow down the build significantly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pier-Luc Caron St-Pierre updated IO-291: Attachment: (was: FileUtils.isContained.patch) Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: io-291-simple.diff, io-291-v4.patch I added a function that determines whether the specified leaf is contains by the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pier-Luc Caron St-Pierre updated IO-291: Attachment: (was: io-291-v4.patch) Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: io-291-simple.diff I added a function that determines whether the specified leaf is contains by the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pier-Luc Caron St-Pierre updated IO-291: Attachment: io-291-v5.patch Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: io-291-simple.diff, io-291-v5.patch I added a function that determines whether the specified leaf is contains by the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146045#comment-13146045 ] Pier-Luc Caron St-Pierre edited comment on IO-291 at 11/8/11 2:38 AM: -- I built on top of your patch. So if you apply my patch (io-291-v5.patch) from scratch, you should have our combined changes. * I have implemented the directoryContains(final File directory, final File child) * I have added some test case for the newly implemented function. * I have added some javadoc, renamed some parameters * I have corrected the code style of the test to match the original style. We have some issues to address : * Actually the test case fail on testSameFile() because the case is tester on a file. It fail the rule that a directory cannot be a file * Does a directory contain itself? I do not have strong opinions about that. * Does a file contain itself? I do not have strong opinions about that. * In the scope of the method directoryContains(final File directory, final File child), what will happens if the files is an empty collection? was (Author: plcstpierre): I build on top of your patch. So if you apply my patch (io-291-v5.patch) from scratch, you should have our combined changes. * I have implemented the directoryContains(final File directory, final File child) * I have added some test case for the newly implemented function. * I have Added some javadoc, renamed some parameters * I have corrected the code style of the test to match the original style. We have some issues to address : * Actually the test case fail on testSameFile() because the case is tester on a file. It fail the rule that a directory cannot be a file * Does a directory contain itself? I do not have strong opinions about that. * Does a file contain itself? I do not have strong opinions about that. * In the scope of the method directoryContains(final File directory, final File child), what will happens if the files is an empty collection? Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: io-291-simple.diff, io-291-v5.patch I added a function that determines whether the specified leaf is contains by the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146045#comment-13146045 ] Pier-Luc Caron St-Pierre commented on IO-291: - I build on top of your patch. So if you apply my patch (io-291-v5.patch) from scratch, you should have our combined changes. * I have implemented the directoryContains(final File directory, final File child) * I have added some test case for the newly implemented function. * I have Added some javadoc, renamed some parameters * I have corrected the code style of the test to match the original style. We have some issues to address : * Actually the test case fail on testSameFile() because the case is tester on a file. It fail the rule that a directory cannot be a file * Does a directory contain itself? I do not have strong opinions about that. * Does a file contain itself? I do not have strong opinions about that. * In the scope of the method directoryContains(final File directory, final File child), what will happens if the files is an empty collection? Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Fix For: 2.1 Attachments: io-291-simple.diff, io-291-v5.patch I added a function that determines whether the specified leaf is contains by the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-291) Add new function FileUtils.isContained
[ https://issues.apache.org/jira/browse/IO-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gary D. Gregory updated IO-291: --- Fix Version/s: (was: 2.1) Add new function FileUtils.isContained -- Key: IO-291 URL: https://issues.apache.org/jira/browse/IO-291 Project: Commons IO Issue Type: New Feature Components: Utilities Affects Versions: 2.1 Reporter: Pier-Luc Caron St-Pierre Assignee: Gary D. Gregory Labels: patch Attachments: io-291-simple.diff, io-291-v5.patch I added a function that determines whether the specified leaf is contains by the specified composite. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146060#comment-13146060 ] Phil Steitz commented on MATH-699: -- I am sorry, Sebastien. I am not being very helpful here. As I dig deeper into the code and archaeology, I am having a hard time seeing how we can really improve the default impl without knowledge of the underlying distribution. I agree with you that we should clearly document its limitations, though, and fix the javadoc contracts everywhere to be correct and consistent. The default impl was never really intended to be universal - just a simple solver-based impl that would work for well-behaved distributions. The normal distribution example above points to a slight improvement that could now be done. When that code was written, we had yet to define the supportLowerBound and supportUpperBound properties. Now that we have those, the test in the normal dist case could be moved up into the default impl, using the getters on the distribution for the return values. By all means if you can find a way to deal with plateaus or otherwise improve robustness of the default impl, go for it. In particular, if you can come up with a better way to set up the solver, possibly eliminating the domainLower/upperBound methods, that would be great. It has always seemed a little ugly to me that we had to implement these methods for every distribution just so we could get initial guesses for the inverse cum solver. inverseCumulativeDistribution fails with cumulative distribution having a plateau - Key: MATH-699 URL: https://issues.apache.org/jira/browse/MATH-699 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Sébastien Brisard Assignee: Sébastien Brisard Priority: Minor Attachments: AbstractContinuousDistributionTest.java This bug report follows MATH-692. The attached unit test fails. As required by the definition in MATH-692, the lower-bound of the interval on which the cdf is constant should be returned. This is not so at the moment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (COMPRESS-162) BZip2CompressorInputStream still stops after 900,000 decompressed bytes of large compressed file
BZip2CompressorInputStream still stops after 900,000 decompressed bytes of large compressed file Key: COMPRESS-162 URL: https://issues.apache.org/jira/browse/COMPRESS-162 Project: Commons Compress Issue Type: Bug Components: Compressors Affects Versions: 1.3 Environment: Linux (Fedora Cores 13 [2.6.34.9-69.fc13.i686.PAE] and 15, at latest 'yum upgrade' as of 7 Nov 2011), Sun Java 1.6.0_22 Reporter: Andrew Pavlin Attempting to unzip the planet-110921.osm.bz2 file downloaded directly from planet.OpenStreetMaps.org aborts after exactly 90 bytes are uncompressed. The uncompressed content looks like valid XML, and causes my application's parser to blow up with XML syntax errors due to missing closing tags. Tried using the example code to just uncompress, and got the same exact behavior. Uncompressing the same file planet-110921.osm.bz2 (19357793489 bytes long compressed) with the Linux bzip2 command-line utility (bzip2-1.0.6-1.fc13.i686.rpm) succeeds and produces a valid (and enormous) XML file that can be successfully parsed. Tried getting a subversion snapshot of the commons-compress trunk on 7 Nov 2011 and replacing the org.apache.commons.compress.compressors.bzip2 package in the commons-compress-1.3.jar with compiled code from the trunk (Subversion log reported that the fix for COMPRESS-146 (?) was in). Still the same failure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-699) inverseCumulativeDistribution fails with cumulative distribution having a plateau
[ https://issues.apache.org/jira/browse/MATH-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146108#comment-13146108 ] Sébastien Brisard commented on MATH-699: I agree with you: however careful we are, the default implementation will never be perfect, and it should be clearly stated in the javadoc. I see (but haven't dug into it yet) there is an abstract test for continuous distributions. I'll try and make sure that most possible cases of failure of {{inverseCumulativeProbability}} are tested in this abstract framework, so that users could be *strongly* encouraged to implement this test for their very specific distribution. I do think we can widen a little bit the scope of the default implementation. I actually worked towards eliminating the bracketing step, but you convinced me that it should be the other way round: can we eliminate the domainLower/upperBound methods (which I agree are very efficient, but a little bit of a pain in the neck...). Here is an idea I'm going to check (keeping in mind the accuracy issues you've already pointed at) * for distributions with bounded support: maybe the bounds (possibly shifted if the bounds are not inclusive) of the support itself could be used as an initial bracketting range. * for distributions with unbounded support: start from *any* (? or a better guess? average value?) point in the support, and do bracketting. However, I do agree with Christian, we should use geometric progressions in this case, instead of arithmetic progressions. This would probably lead to a very large interval, but it would provide us an interval more quickly, and the solver itself would probably be quite good at narrowing it very quickly. I can try some monitoring on this issue. As for plateaus, I think what I'm currently working on is not too inefficient. I'm sure it's not *the* answer (which is, anyway, 42 :)), but I'm struggling to fail this algo... Don't worry, I'll break it. I think that what I've done entails very little additional cost (maybe one more evaluation of cumulativeProbability) for distributions *without* plateau, but I need to check that (we do not want to pay a heavy price for plateaus, since most of our distributions do not have one, as you rightly pointed out). I would be grateful for any idea on these topics, and will keep you informed. All the best for now, Sébastien inverseCumulativeDistribution fails with cumulative distribution having a plateau - Key: MATH-699 URL: https://issues.apache.org/jira/browse/MATH-699 Project: Commons Math Issue Type: Bug Affects Versions: 3.0 Reporter: Sébastien Brisard Assignee: Sébastien Brisard Priority: Minor Attachments: AbstractContinuousDistributionTest.java This bug report follows MATH-692. The attached unit test fails. As required by the definition in MATH-692, the lower-bound of the interval on which the cdf is constant should be returned. This is not so at the moment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira