[jira] [Commented] (SANDBOX-493) Change (R) StringMetric.compare(CS left, CS right) to "apply" so that it is consistent with BiFunction.
[ https://issues.apache.org/jira/browse/SANDBOX-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344678#comment-14344678 ] Benedikt Ritter commented on SANDBOX-493: - Go for it! IMHO we can even update to Java 8 and make StringMetric extend java.util.function.BiFunction. Java 7 is almost EOL... > Change (R) StringMetric.compare(CS left, CS right) to "apply" so that it is > consistent with BiFunction. > --- > > Key: SANDBOX-493 > URL: https://issues.apache.org/jira/browse/SANDBOX-493 > Project: Commons Sandbox > Issue Type: Improvement > Components: Commons Text >Reporter: Jonathan Baker >Priority: Minor > > Whenever commons-text supports Java 8, StringMetric should extend > BiFunction. Renaming "compare" to "apply" now > will make that transition smoother later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-493) Change (R) StringMetric.compare(CS left, CS right) to "apply" so that it is consistent with BiFunction.
[ https://issues.apache.org/jira/browse/SANDBOX-493?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344141#comment-14344141 ] Bruno P. Kinoshita commented on SANDBOX-493: +1 from me. I like how compare gives an idea of that the method is clearly doing, but if it will make the transition to Java 8 easier, than I'd say let's change it. What do you think [~britter]? > Change (R) StringMetric.compare(CS left, CS right) to "apply" so that it is > consistent with BiFunction. > --- > > Key: SANDBOX-493 > URL: https://issues.apache.org/jira/browse/SANDBOX-493 > Project: Commons Sandbox > Issue Type: Improvement > Components: Commons Text >Reporter: Jonathan Baker >Priority: Minor > > Whenever commons-text supports Java 8, StringMetric should extend > BiFunction. Renaming "compare" to "apply" now > will make that transition smoother later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-491) Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance.
[ https://issues.apache.org/jira/browse/SANDBOX-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344138#comment-14344138 ] Bruno P. Kinoshita commented on SANDBOX-491: Hi Jonathan That was probably my mistake while migrating the code from [lang]. We may have to change the design of some objects to fit this (i.e. we could add another distance object, or make it one parameterized). Would you like to send a pull request with some suggestion? :-) > Allow extra information (e.g. Levenshtein threshold) to be stored as (final) > fields in the StringMetric instance. > - > > Key: SANDBOX-491 > URL: https://issues.apache.org/jira/browse/SANDBOX-491 > Project: Commons Sandbox > Issue Type: Improvement > Components: Commons Text >Reporter: Jonathan Baker >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (BCEL-209) Bug fixes and improvements to InvokeDynamic and BootStrapMethods implementation
[ https://issues.apache.org/jira/browse/BCEL-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14344136#comment-14344136 ] Mark Roberts commented on BCEL-209: --- I guess I was reflecting the fact that this field is in the class file format. Also, if you don't make it a member of BootStrapMethod, it makes it a little messier to write the three different constructors. I like the recursive call to the 'basic' constructor. But you could certainly code it the way you describe if you wish. > Bug fixes and improvements to InvokeDynamic and BootStrapMethods > implementation > --- > > Key: BCEL-209 > URL: https://issues.apache.org/jira/browse/BCEL-209 > Project: Commons BCEL > Issue Type: Bug >Reporter: Mark Roberts > Attachments: counter.diff, invoke4.diff > > > (Apologies in advance - this is a very large diff.) > During the past year, both the Apache Commons BCEL team and our group here at > the UW independently completed the support for InvokeDynamic . Some things > we chose to do the same way, but there are a few items that are quite > different. Trying not to be too biased, I believe our method is better. One > of the larger differences is your decision to add the abstract class > NameSignatureMethod between FieldOrMethod and CPInstruction and then have > InvokeDynamic extend from that instead of from InvokeInstruction. To me this > seems wrong. In addition to forcing InvokeDynamic to duplicate all the > methods from InvokeInstruction and FieldOrMethod, it is awkward that it is > the only form of the Invoke Instruction that doesn't derive from > InvokeInstruction. > This patch also includes several methods missing from the current > implementation: alternative initializers, toString, and support for the > Visitor paradigm. > There are bug fixes to Constants.java and InstructionFinder.java as well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (SANDBOX-491) Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance.
[ https://issues.apache.org/jira/browse/SANDBOX-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14343563#comment-14343563 ] Bruno P. Kinoshita edited comment on SANDBOX-491 at 3/3/15 12:22 AM: - Hi Bruno, Do you know why [non-threshold version|https://commons.apache.org/proper/commons-lang/javadocs/api-3.3/org/apache/commons/lang3/StringUtils.html#getLevenshteinDistance%28java.lang.CharSequence,%20java.lang.CharSequence%29] of the Levenshtein distance was removed when commons-test was spawned from commons-lang3? The commons-text version is just delegating to the other method with Integer.MAX_VALUE. The two commons-lang3 methods were different. Would it make sense to bring it back for use when "threshold" is set null? Thanks was (Author: jbaker): Hi Bruno, Do you know why [non-threshold version](https://commons.apache.org/proper/commons-lang/javadocs/api-3.3/org/apache/commons/lang3/StringUtils.html#getLevenshteinDistance%28java.lang.CharSequence,%20java.lang.CharSequence%29) of the Levenshtein distance was removed when commons-test was spawned from commons-lang3? The commons-text version is just delegating to the other method with Integer.MAX_VALUE. The two commons-lang3 methods were different. Would it make sense to bring it back for use when "threshold" is set null? Thanks > Allow extra information (e.g. Levenshtein threshold) to be stored as (final) > fields in the StringMetric instance. > - > > Key: SANDBOX-491 > URL: https://issues.apache.org/jira/browse/SANDBOX-491 > Project: Commons Sandbox > Issue Type: Improvement > Components: Commons Text >Reporter: Jonathan Baker >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (BCEL-209) Bug fixes and improvements to InvokeDynamic and BootStrapMethods implementation
[
https://issues.apache.org/jira/browse/BCEL-209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14343999#comment-14343999
]
Emmanuel Bourg commented on BCEL-209:
-
Mark, why adding {{num_bootstrap_arguments}} to {{BootstrapMethod}}? The number
of arguments could be retrieved with {{getBootstrapArguments().length}}, and
there is no need to keep in sync {{num_bootstrap_arguments}} with the actual
number of elements in {{bootstrap_arguments}}.
> Bug fixes and improvements to InvokeDynamic and BootStrapMethods
> implementation
> ---
>
> Key: BCEL-209
> URL: https://issues.apache.org/jira/browse/BCEL-209
> Project: Commons BCEL
> Issue Type: Bug
>Reporter: Mark Roberts
> Attachments: counter.diff, invoke4.diff
>
>
> (Apologies in advance - this is a very large diff.)
> During the past year, both the Apache Commons BCEL team and our group here at
> the UW independently completed the support for InvokeDynamic . Some things
> we chose to do the same way, but there are a few items that are quite
> different. Trying not to be too biased, I believe our method is better. One
> of the larger differences is your decision to add the abstract class
> NameSignatureMethod between FieldOrMethod and CPInstruction and then have
> InvokeDynamic extend from that instead of from InvokeInstruction. To me this
> seems wrong. In addition to forcing InvokeDynamic to duplicate all the
> methods from InvokeInstruction and FieldOrMethod, it is awkward that it is
> the only form of the Invoke Instruction that doesn't derive from
> InvokeInstruction.
> This patch also includes several methods missing from the current
> implementation: alternative initializers, toString, and support for the
> Visitor paradigm.
> There are bug fixes to Constants.java and InstructionFinder.java as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (MATH-958) Remove support for NaNStrategy.REMOVED in SpearmansCorrelation
[ https://issues.apache.org/jira/browse/MATH-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-958. -- Resolution: Fixed The ctors of SpearmansCorrelation will now throw a MathIllegalArgumentException if provided with a NaturalRanking instance with NaNStrategy#REMOVED. Committed in 4e08e17ec536038c9c0dd888f77b912cae82816c. > Remove support for NaNStrategy.REMOVED in SpearmansCorrelation > -- > > Key: MATH-958 > URL: https://issues.apache.org/jira/browse/MATH-958 > Project: Commons Math > Issue Type: Task >Reporter: Thomas Neidhart > Fix For: 4.0 > > > The temporary fix applied for MATH-891 shall be removed and in case a > RankingAlgorithm with a NaNStrategy.Removed is used, an Exception shall be > thrown. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (LANG-1090) FastDateParser does not set error indication in ParsePosition
[ https://issues.apache.org/jira/browse/LANG-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved LANG-1090. Resolution: Fixed Fix Version/s: 3.4 URL: http://svn.apache.org/r1663438 Log: LANG-1090 FastDateParser does not set error indication in ParsePosition Modified: commons/proper/lang/trunk/src/changes/changes.xml commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/FastDateParserSDFTest.java > FastDateParser does not set error indication in ParsePosition > - > > Key: LANG-1090 > URL: https://issues.apache.org/jira/browse/LANG-1090 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb >Priority: Minor > Fix For: 3.4 > > > FastDateParser#parse(String,ParsePosition) does not throw ParseException if > the input cannot be matched. > If the parse succeeds, the ParsePosition is updated to the index of the next > character after the last one used, and the error index is left as -1. > If the parse fails, at present the ParsePosition is not updated at all, > unlike SimpleDateFormat which is able to set the error Index to the location > where the error occurr. > It does not appear to be possible to determine the error location because the > matching against the format string is all or nothing. > This means that a successful parse can only be detected by checking whether > the ParsePosition has been updated. > This needs to be documented, and some unit tests added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-643) Rename RealVector.map* to RealVector.ebe* (mapAdd(...) to ebeAdd(...) and mapAddToSelf(...) to ebeAddToSelf(...) for instance
[ https://issues.apache.org/jira/browse/MATH-643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14343760#comment-14343760 ] Thomas Neidhart commented on MATH-643: -- element-by-element is simply the wrong term for this kind of operation. The referenced page of octave also makes the distinction between element-by-element operations and overloaded operations with different operands. The prefix map comes from the functional world and is well understood imho. As we have not deprecated anything in 3.x and the proposal is not very convincing for me, I propose to close it finally as won't fix. > Rename RealVector.map* to RealVector.ebe* (mapAdd(...) to ebeAdd(...) and > mapAddToSelf(...) to ebeAddToSelf(...) for instance > - > > Key: MATH-643 > URL: https://issues.apache.org/jira/browse/MATH-643 > Project: Commons Math > Issue Type: Improvement >Reporter: Arne Plöse >Priority: Minor > Fix For: 4.0 > > > I think the map* methods have historical names. Today I would prefer ebe as > prefix like ebeMultiply(...). > This would describe the methods better from a users view. > If this is a valid issue, I could provide a patch. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (LANG-1090) FastDateParser does not set error indication in ParsePosition
Sebb created LANG-1090: -- Summary: FastDateParser does not set error indication in ParsePosition Key: LANG-1090 URL: https://issues.apache.org/jira/browse/LANG-1090 Project: Commons Lang Issue Type: Bug Reporter: Sebb Priority: Minor FastDateParser#parse(String,ParsePosition) does not throw ParseException if the input cannot be matched. If the parse succeeds, the ParsePosition is updated to the index of the next character after the last one used, and the error index is left as -1. If the parse fails, at present the ParsePosition is not updated at all, unlike SimpleDateFormat which is able to set the error Index to the location where the error occurr. It does not appear to be possible to determine the error location because the matching against the format string is all or nothing. This means that a successful parse can only be detected by checking whether the ParsePosition has been updated. This needs to be documented, and some unit tests added. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (MATH-738) Incomplete beta function I(x, a, b) is inaccurate for large values of a and/or b
[ https://issues.apache.org/jira/browse/MATH-738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14343732#comment-14343732 ] Thomas Neidhart commented on MATH-738: -- The deprecated method has been removed for 4.0. > Incomplete beta function I(x, a, b) is inaccurate for large values of a > and/or b > > > Key: MATH-738 > URL: https://issues.apache.org/jira/browse/MATH-738 > Project: Commons Math > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Sébastien Brisard > Labels: special-functions > Fix For: 4.0 > > > This was first reported in MATH-718. The result of the current implementation > of the incomplete beta function I(x, a, b) is inaccurate when a and/or b are > large-ish. > I've skimmed through [slatec|http://www.netlib.org/slatec/fnlib/betai.f], > GSL, > [Boost|http://www.boost.org/doc/libs/1_38_0/libs/math/doc/sf_and_dist/html/math_toolkit/special/sf_beta/ibeta_function.html] > as well as NR. At first sight, neither uses the same method to compute this > function. I think [TOMS-708|http://www.netlib.org/toms/708] is probably the > best option. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (MATH-1187) Pom to run examples from Maven repo
[ https://issues.apache.org/jira/browse/MATH-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Neidhart resolved MATH-1187. --- Resolution: Won't Fix The uber configuration in the pom has been removed, the README in the userguide directory explains how to run individual examples. As we do not have a classical main class to include in the pom as suggested, I propose to close this issue for now. > Pom to run examples from Maven repo > --- > > Key: MATH-1187 > URL: https://issues.apache.org/jira/browse/MATH-1187 > Project: Commons Math > Issue Type: New Feature >Reporter: Sebb >Priority: Minor > Attachments: pom.xml > > > The Pom (to follow) allows one to run the examples assuming an examples jar > has been installed / uploaded to Maven. > There would be no need to create an Uber jar (with all the potential > licensing/jar hell issues) as the pom would download any necessary > dependencies to the local repo. > As an enhancement, if it proved necessary to optionally depend on a > non-permitted jar, it would be possible to add a profile to add that as a > proper dependency (the main dependency would have to use "provided"). I think > this would satisfy the ASF requirement that users should not be landed with > non-AL code unless they specifically agree to it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (SANDBOX-491) Allow extra information (e.g. Levenshtein threshold) to be stored as (final) fields in the StringMetric instance.
[ https://issues.apache.org/jira/browse/SANDBOX-491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14343563#comment-14343563 ] Jonathan Baker commented on SANDBOX-491: Hi Bruno, Do you know why [non-threshold version](https://commons.apache.org/proper/commons-lang/javadocs/api-3.3/org/apache/commons/lang3/StringUtils.html#getLevenshteinDistance%28java.lang.CharSequence,%20java.lang.CharSequence%29) of the Levenshtein distance was removed when commons-test was spawned from commons-lang3? The commons-text version is just delegating to the other method with Integer.MAX_VALUE. The two commons-lang3 methods were different. Would it make sense to bring it back for use when "threshold" is set null? Thanks > Allow extra information (e.g. Levenshtein threshold) to be stored as (final) > fields in the StringMetric instance. > - > > Key: SANDBOX-491 > URL: https://issues.apache.org/jira/browse/SANDBOX-491 > Project: Commons Sandbox > Issue Type: Improvement > Components: Commons Text >Reporter: Jonathan Baker >Priority: Minor > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (LANG-1089) FastDateParser does not handle excess hours as per SimpleDateFormat
[ https://issues.apache.org/jira/browse/LANG-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebb resolved LANG-1089. Resolution: Fixed Fix Version/s: 3.4 URL: http://svn.apache.org/r1663348 Log: LANG-1089 FastDateParser does not handle excess hours as per SimpleDateFormat Modified: commons/proper/lang/trunk/src/changes/changes.xml commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/time/FastDateParser.java commons/proper/lang/trunk/src/test/java/org/apache/commons/lang3/time/FastDateParserSDFTest.java > FastDateParser does not handle excess hours as per SimpleDateFormat > --- > > Key: LANG-1089 > URL: https://issues.apache.org/jira/browse/LANG-1089 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > Fix For: 3.4 > > > FastDateParser does not do any validation of dates/times. > It acts similarly to SimpleDateFormat (SDF) in lenient mode. > However it does not generate the same output as SDF for input where the > number of hours is greater than the normal range (e.g. > 12 for hh or > 23 > for HH) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (EMAIL-150) Proxy support
Perriman created EMAIL-150:
--
Summary: Proxy support
Key: EMAIL-150
URL: https://issues.apache.org/jira/browse/EMAIL-150
Project: Commons Email
Issue Type: Improvement
Reporter: Perriman
Support to use socket proxy. In javamail it can be done with:
props.setProperty("proxySet", "true");
props.setProperty("socksProxyHost", proxyHost);
props.setProperty("socksProxyPort", proxyPort);
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (SANDBOX-493) Change (R) StringMetric.compare(CS left, CS right) to "apply" so that it is consistent with BiFunction.
Jonathan Baker created SANDBOX-493: -- Summary: Change (R) StringMetric.compare(CS left, CS right) to "apply" so that it is consistent with BiFunction. Key: SANDBOX-493 URL: https://issues.apache.org/jira/browse/SANDBOX-493 Project: Commons Sandbox Issue Type: Improvement Components: Commons Text Reporter: Jonathan Baker Priority: Minor Whenever commons-text supports Java 8, StringMetric should extend BiFunction. Renaming "compare" to "apply" now will make that transition smoother later. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (LANG-1089) FastDateParser does not handle excess hours as per SimpleDateFormat
[ https://issues.apache.org/jira/browse/LANG-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14343081#comment-14343081 ] Sebb commented on LANG-1089: The 'h' and 'k' formats display hour 0 as 12/24 respectively, so the code needs to convert 12/24 to 0 on input. The code uses modulo arithmetic to handle the conversion from 12 => 0 and 24 => 0. Modulo has the same result for 12/24, but behaves differently from SDF lenient mode when the values are greater than 12/24. Furthermore, the code applies the modulo conversion to the 'h' and 'H' formats, instead of the 'h' and 'k' formats. This was not picked up by the unit tests as there were no tests that covered the conditions. > FastDateParser does not handle excess hours as per SimpleDateFormat > --- > > Key: LANG-1089 > URL: https://issues.apache.org/jira/browse/LANG-1089 > Project: Commons Lang > Issue Type: Bug >Reporter: Sebb > > FastDateParser does not do any validation of dates/times. > It acts similarly to SimpleDateFormat (SDF) in lenient mode. > However it does not generate the same output as SDF for input where the > number of hours is greater than the normal range (e.g. > 12 for hh or > 23 > for HH) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
