[jira] Updated: (MATH-181) Specify the maximum of digits when parsing a Fraction
[ https://issues.apache.org/jira/browse/MATH-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton updated MATH-181: - Attachment: MATH-181-FractionDigitsLimit-v2.patch version 2 patch attached with (hopefully) improved JavaDocs > Specify the maximum of digits when parsing a Fraction > - > > Key: MATH-181 > URL: https://issues.apache.org/jira/browse/MATH-181 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Attachments: MATH-181-FractionDigitsLimit-v2.patch, > MATH-181-FractionDigitsLimit.patch > > > Firstly, thanks for the Fraction code - I've adapated it for something I'm > working on and I didn't have a clue how to convert a decimal to a fraction :) > Excel spreadsheets have the facility to specify a fraction format where you > specify the maximum number of denominator digits to display. > So for example: > format "?/?" displays decimal values formatted in the range 1/2 to n/9 > format "??/??" displays decimal values formatted in the range 1/2 to n/99 > format "???/???" displays decimal values formatted in the range 1/2 to > n/999 etc > In excel then the value 0.6152 displays as 3/5, 8/13 and 510/829 respectively > for the above 3 formats. > I'm attaching a patch for the Fraction class which adds a new constructor > where the maximum number of digits can be specified, rather than the epsilon > value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-181) Specify the maximum of digits when parsing a Fraction
[ https://issues.apache.org/jira/browse/MATH-181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562626#action_12562626 ] Luc Maisonobe commented on MATH-181: I understand your rationale here. I also don't like copying code that is almost identical, it leads to a maintenance nightmare. Updating only the javadoc to explain the two exclusive operating modes for this constructor and hence to strongly advise this constructor remains private should be sufficient. > Specify the maximum of digits when parsing a Fraction > - > > Key: MATH-181 > URL: https://issues.apache.org/jira/browse/MATH-181 > Project: Commons Math > Issue Type: Improvement >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Attachments: MATH-181-FractionDigitsLimit.patch > > > Firstly, thanks for the Fraction code - I've adapated it for something I'm > working on and I didn't have a clue how to convert a decimal to a fraction :) > Excel spreadsheets have the facility to specify a fraction format where you > specify the maximum number of denominator digits to display. > So for example: > format "?/?" displays decimal values formatted in the range 1/2 to n/9 > format "??/??" displays decimal values formatted in the range 1/2 to n/99 > format "???/???" displays decimal values formatted in the range 1/2 to > n/999 etc > In excel then the value 0.6152 displays as 3/5, 8/13 and 510/829 respectively > for the above 3 formats. > I'm attaching a patch for the Fraction class which adds a new constructor > where the maximum number of digits can be specified, rather than the epsilon > value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MATH-180) Add support for OSGi to Commons Math
[ https://issues.apache.org/jira/browse/MATH-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562624#action_12562624 ] Luc Maisonobe commented on MATH-180: All packages can be used by end users. The only thing that should be kept away from distribution is the "mantissa" directory in the subversion repository which is only used as a code base for [math] developers. Some packages have already been transfered for 1.2 release, other packages will follow later, and still others will probably be dropped sometimes. This directory will therefore reduce as code is transfered to o.a.c.math and finally disappear. However I think this directory will be manually discarded when the release will be cut out and that the OSGi configuration in pom will never see it. > Add support for OSGi to Commons Math > > > Key: MATH-180 > URL: https://issues.apache.org/jira/browse/MATH-180 > Project: Commons Math > Issue Type: Task >Affects Versions: 1.1 >Reporter: Niall Pemberton >Priority: Minor > Fix For: 1.2 > > > I saw mentioned that Commons Math 1.2 is on the horizon and it would be good > to add support for OSGi. Is the release likely to be done using Maven1 or > Maven2? I can provide a patch for either, but if its m2 then will probably > hold off until nearer the release to see if we get anything done in the > commons-parent pom. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LANG-404) Add Calendar flavour format methods to DateFormatUtils
[ https://issues.apache.org/jira/browse/LANG-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Niall Pemberton resolved LANG-404. -- Resolution: Fixed Fixed http://svn.apache.org/viewvc?view=rev&revision=615243 > Add Calendar flavour format methods to DateFormatUtils > -- > > Key: LANG-404 > URL: https://issues.apache.org/jira/browse/LANG-404 > Project: Commons Lang > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Niall Pemberton >Assignee: Niall Pemberton >Priority: Minor > Fix For: 2.4 > > > Add Calendar flavour format methods to DateFormatUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (LANG-404) Add Calendar flavour format methods to DateFormatUtils
Add Calendar flavour format methods to DateFormatUtils -- Key: LANG-404 URL: https://issues.apache.org/jira/browse/LANG-404 Project: Commons Lang Issue Type: Improvement Affects Versions: 2.3 Reporter: Niall Pemberton Assignee: Niall Pemberton Priority: Minor Fix For: 2.4 Add Calendar flavour format methods to DateFormatUtils -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LANG-180) [lang] adding a StringUtils.replace method that takes an array or List of replacement strings
[ https://issues.apache.org/jira/browse/LANG-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562494#action_12562494 ] Sebb commented on LANG-180: --- The Exception messages could be improved, e.g. "Lengths don't match: " - which lengths? The above should perhaps be an IllegalArgumentException rather than IndexOutOfBoundsException, as it's not an actual out of bounds, more a potential out of bounds - but either type will do. " is under 0: " => " is less than 0:" I don't like the names "repl" and "with"; particularly "repl" could mean the replacement text rather than the replaced text. RE engines tend to use words such as: Perl: searchlist replacementlist ORO: pattern replacement Java has String.replace(regex, replacement) In all cases, "replacement" is used. Seems to me that searchlist and replacementlist would be unambiguous as well as descriptive. > [lang] adding a StringUtils.replace method that takes an array or List of > replacement strings > - > > Key: LANG-180 > URL: https://issues.apache.org/jira/browse/LANG-180 > Project: Commons Lang > Issue Type: Improvement > Environment: Operating System: other > Platform: Other >Reporter: Chris >Priority: Minor > Fix For: 2.4 > > Attachments: LANG-180.patch, LANG-180.patch, StringUtilsAndText.java > > > I have the situation where I have a String template with a dozen replacements > I need to make. When I loop through and use StringUtils.replace each time, > it > has to make a StringBuffer of the whole template each time. I think we could > make this more efficient if we had a replace() method which took an array of > Strings to search for, and an array of Strings to replace with (or we could > use a Collection or List or something). This way we could possibly do the > replace in one StringBuffer result. > One issue is if the replacement text has Strings to be replaced, do we > iterate > through again until there are no Strings to search for? Based on your > replaceChars(String str, String searchChars, String replaceChars) method, I > assume the answer is no, but we could have a boolean flag to have it both > ways. > I can write this for you if you are interested, please let me know. > Thanks! > Chris -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DAEMON-96) Classpath is being truncated
[ https://issues.apache.org/jira/browse/DAEMON-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562435#action_12562435 ] Francesco Dalan commented on DAEMON-96: --- Hi, I have the same error but the classpath have been trucated to 1023th character. The truncation happens when I open the monitor (prunmgr.exe) and save any modification on the java tab. Looking into the source (prunmgr.c, __generalJvmSave routine), the variable szB, used to store the classpath value from the input field, is 1024 byte length. I have changed the source using a new more longer variable and same to work. I attach my modified prunmgr.c file with the modification (see the "start DAEMON-96" and "end DAEMON-96" comments) to propose the fixing > Classpath is being truncated > > > Key: DAEMON-96 > URL: https://issues.apache.org/jira/browse/DAEMON-96 > Project: Commons Daemon > Issue Type: Bug > Environment: Windows >Reporter: James Woodward > > [2007-03-26 10:33:38] [info] Starting service... > [2007-03-26 10:33:38] [408 javajni.c] [debug] Jvm Option[0] > -Djava.class.path=C:\Java\ftpserver-1.0-M1-incubator\common\classes;C:\Java\ftpserver-1.0-M1-incubator\common\lib\activation.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\backport-util-concurrent-2.2.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\commons-dbcp-1.2.1.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\commons-lang-2.3.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\commons-logging-1.1.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\commons-pool-1.3.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\dom4j-1.6.1.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\ejb3-persistence.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\ftplet-api-1.0-M1-incubator.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\ftpserver-admin-gui-1.0-M1-incubator.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\ftpserver-core-1.0-M1-incubator.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\hibernate-annotations.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\hibernate-commons-annotations.jar;C > [2007-03-26 10:33:38] [408 javajni.c] [debug] Jvm Option[1] vfprintf > [2007-03-26 10:33:40] [494 javajni.c] [debug] argv[0] = start > [2007-03-26 10:33:40] [494 javajni.c] [debug] argv[1] = -xml > [2007-03-26 10:33:40] [494 javajni.c] [debug] argv[2] = ./res/conf/ftpd.xml > [2007-03-26 10:33:41] [919 prunsrv.c] [debug] Java started > org/apache/ftpserver/commandline/Daemon > [2007-03-26 10:33:41] [info] Service started in 2162 ms. > The class path is being truncated at the 1010th character. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (DAEMON-96) Classpath is being truncated
[ https://issues.apache.org/jira/browse/DAEMON-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Dalan updated DAEMON-96: -- Attachment: prunmgr.c > Classpath is being truncated > > > Key: DAEMON-96 > URL: https://issues.apache.org/jira/browse/DAEMON-96 > Project: Commons Daemon > Issue Type: Bug > Environment: Windows >Reporter: James Woodward > Attachments: prunmgr.c > > > [2007-03-26 10:33:38] [info] Starting service... > [2007-03-26 10:33:38] [408 javajni.c] [debug] Jvm Option[0] > -Djava.class.path=C:\Java\ftpserver-1.0-M1-incubator\common\classes;C:\Java\ftpserver-1.0-M1-incubator\common\lib\activation.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\backport-util-concurrent-2.2.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\commons-dbcp-1.2.1.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\commons-lang-2.3.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\commons-logging-1.1.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\commons-pool-1.3.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\dom4j-1.6.1.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\ejb3-persistence.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\ftplet-api-1.0-M1-incubator.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\ftpserver-admin-gui-1.0-M1-incubator.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\ftpserver-core-1.0-M1-incubator.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\hibernate-annotations.jar;C:\Java\ftpserver-1.0-M1-incubator\common\lib\hibernate-commons-annotations.jar;C > [2007-03-26 10:33:38] [408 javajni.c] [debug] Jvm Option[1] vfprintf > [2007-03-26 10:33:40] [494 javajni.c] [debug] argv[0] = start > [2007-03-26 10:33:40] [494 javajni.c] [debug] argv[1] = -xml > [2007-03-26 10:33:40] [494 javajni.c] [debug] argv[2] = ./res/conf/ftpd.xml > [2007-03-26 10:33:41] [919 prunsrv.c] [debug] Java started > org/apache/ftpserver/commandline/Daemon > [2007-03-26 10:33:41] [info] Service started in 2162 ms. > The class path is being truncated at the 1010th character. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LANG-180) [lang] adding a StringUtils.replace method that takes an array or List of replacement strings
[ https://issues.apache.org/jira/browse/LANG-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-180: --- Attachment: LANG-180.patch I managed to find a bit of time to look at the core of the code and am attaching my modifications. I've folded the other static methods inside the main functions. On the one hand, that's bad coding, on the other this is a huge file with many static methods and doing the code inline when it's not being reused much helps keep things simpler. Also I've modified the API slightly - passing in a null 'with' is also a no-op. Previously a null repl but existent 'with' was a no-op, but a null 'with' and existent 'repl' was considered an exception due to different lengths. Possibly the correct solution is to make both cases exceptions rather than no-ops. > [lang] adding a StringUtils.replace method that takes an array or List of > replacement strings > - > > Key: LANG-180 > URL: https://issues.apache.org/jira/browse/LANG-180 > Project: Commons Lang > Issue Type: Improvement > Environment: Operating System: other > Platform: Other >Reporter: Chris >Priority: Minor > Fix For: 2.4 > > Attachments: LANG-180.patch, LANG-180.patch, StringUtilsAndText.java > > > I have the situation where I have a String template with a dozen replacements > I need to make. When I loop through and use StringUtils.replace each time, > it > has to make a StringBuffer of the whole template each time. I think we could > make this more efficient if we had a replace() method which took an array of > Strings to search for, and an array of Strings to replace with (or we could > use a Collection or List or something). This way we could possibly do the > replace in one StringBuffer result. > One issue is if the replacement text has Strings to be replaced, do we > iterate > through again until there are no Strings to search for? Based on your > replaceChars(String str, String searchChars, String replaceChars) method, I > assume the answer is no, but we could have a boolean flag to have it both > ways. > I can write this for you if you are interested, please let me know. > Thanks! > Chris -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
