[jira] [Updated] (LANG-611) Consider improvements in LANG-396
[ https://issues.apache.org/jira/browse/LANG-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-611: --- Fix Version/s: (was: 3.x) 3.0.1 > Consider improvements in LANG-396 > - > > Key: LANG-611 > URL: https://issues.apache.org/jira/browse/LANG-611 > Project: Commons Lang > Issue Type: Improvement > Components: General >Reporter: Henri Yandell > Fix For: 3.0.1 > > > Richard's patch in LANG-396 had various improvement suggestions in addition > to vararg fixing. Consider. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LANG-660) Add methods to insert arrays into arrays at an index
[
https://issues.apache.org/jira/browse/LANG-660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066595#comment-13066595
]
Matt Benson commented on LANG-660:
--
There are issues here:
* {{addAll(int[], int, int...)}} conflicts with {{addAll(int[], int...)}}
* {{addAll(int[], int, int[])}} violates symmetry with {{addAll(int[], int...)}}
* putting the target index first e.g. {{addAll(int, int[], int...)}} works, but
violates symmetry with {{add(int[], int, int)}}
Beats me.
> Add methods to insert arrays into arrays at an index
>
>
> Key: LANG-660
> URL: https://issues.apache.org/jira/browse/LANG-660
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 2.5
>Reporter: Aaron Digulla
>Priority: Minor
> Fix For: 3.x
>
> Attachments: ArrayUtils.txt, ArrayUtilsAddTest.txt,
> ArrayUtilsAddTest_addAll.patch, ArrayUtils_addAll.patch
>
>
> Please add methods with this signature: ArrayUtils.addAll(int[] target, int
> index, int[] source) (i.e. insert an array into an array at a certain
> position).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-726) Add a method e.g. Range Range.intersectionWith(Range)
[
https://issues.apache.org/jira/browse/LANG-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved LANG-726.
--
Resolution: Fixed
Committed revision 1147537.
> Add a method e.g. Range Range.intersectionWith(Range)
> --
>
> Key: LANG-726
> URL: https://issues.apache.org/jira/browse/LANG-726
> Project: Commons Lang
> Issue Type: Sub-task
> Components: General
>Affects Versions: 3.0
>Reporter: Matt Benson
>Priority: Minor
> Fix For: 3.x
>
>
> in case of non-overlapping ranges, should probably throw
> {{IllegalArgumentException}}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-726) Add a method e.g. Range Range.intersectionWith(Range)
[
https://issues.apache.org/jira/browse/LANG-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson updated LANG-726:
-
Fix Version/s: (was: 3.x)
3.0.1
> Add a method e.g. Range Range.intersectionWith(Range)
> --
>
> Key: LANG-726
> URL: https://issues.apache.org/jira/browse/LANG-726
> Project: Commons Lang
> Issue Type: Sub-task
> Components: General
>Affects Versions: 3.0
>Reporter: Matt Benson
>Priority: Minor
> Fix For: 3.0.1
>
>
> in case of non-overlapping ranges, should probably throw
> {{IllegalArgumentException}}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-611) Consider improvements in LANG-396
[ https://issues.apache.org/jira/browse/LANG-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved LANG-611. -- Resolution: Fixed All subtasks addressed. > Consider improvements in LANG-396 > - > > Key: LANG-611 > URL: https://issues.apache.org/jira/browse/LANG-611 > Project: Commons Lang > Issue Type: Improvement > Components: General >Reporter: Henri Yandell > Fix For: 3.x > > > Richard's patch in LANG-396 had various improvement suggestions in addition > to vararg fixing. Consider. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-725) Convert NumberUtils.min/max array-accepting methods to use varargs
[ https://issues.apache.org/jira/browse/LANG-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved LANG-725. -- Resolution: Invalid Fix Version/s: (was: 3.x) The rules of promotion among primitive numeric types seem to make this impossible to implement; feel free to reopen if you are able to prove me wrong here. > Convert NumberUtils.min/max array-accepting methods to use varargs > -- > > Key: LANG-725 > URL: https://issues.apache.org/jira/browse/LANG-725 > Project: Commons Lang > Issue Type: Sub-task > Components: General >Affects Versions: 3.0 >Reporter: Matt Benson >Priority: Minor > > These will then be in competition with our three-arg variants, and we will > have to validate that at least one arg is supplied. If for some reason v3.0 > RC4 is unsuccessful we should tackle this right away so that we can remove > the three-arg variants; else we will be living with them. Pretty sure > compilers will just pick the three-arg variant when three args are specified. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-724) Convert Validate.noNullElements(Object[]) to varargs
[ https://issues.apache.org/jira/browse/LANG-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved LANG-724. -- Resolution: Won't Fix > Convert Validate.noNullElements(Object[]) to varargs > > > Key: LANG-724 > URL: https://issues.apache.org/jira/browse/LANG-724 > Project: Commons Lang > Issue Type: Sub-task > Components: General >Affects Versions: 3.0 >Reporter: Matt Benson >Priority: Minor > Fix For: 3.x, 3.0.1 > > > IIRC such is binary-compatible and so is not a worry. Typically the call > would exist to validate an array that was already constructed and so wouldn't > serve much purpose; however it is conceivable that a caller might wish to > validate together several arguments _he_ received separately. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-724) Convert Validate.noNullElements(Object[]) to varargs
[ https://issues.apache.org/jira/browse/LANG-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated LANG-724: - Fix Version/s: (was: 3.0.1) (was: 3.x) > Convert Validate.noNullElements(Object[]) to varargs > > > Key: LANG-724 > URL: https://issues.apache.org/jira/browse/LANG-724 > Project: Commons Lang > Issue Type: Sub-task > Components: General >Affects Versions: 3.0 >Reporter: Matt Benson >Priority: Minor > > IIRC such is binary-compatible and so is not a worry. Typically the call > would exist to validate an array that was already constructed and so wouldn't > serve much purpose; however it is conceivable that a caller might wish to > validate together several arguments _he_ received separately. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (LANG-724) Convert Validate.noNullElements(Object[]) to varargs
[ https://issues.apache.org/jira/browse/LANG-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson reopened LANG-724: -- actually, making this change results in compilation errors for code that previously had no ambiguity, due to the overloaded signature of noNullElements(Object[], String, Object...). > Convert Validate.noNullElements(Object[]) to varargs > > > Key: LANG-724 > URL: https://issues.apache.org/jira/browse/LANG-724 > Project: Commons Lang > Issue Type: Sub-task > Components: General >Affects Versions: 3.0 >Reporter: Matt Benson >Priority: Minor > Fix For: 3.x, 3.0.1 > > > IIRC such is binary-compatible and so is not a worry. Typically the call > would exist to validate an array that was already constructed and so wouldn't > serve much purpose; however it is conceivable that a caller might wish to > validate together several arguments _he_ received separately. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-724) Convert Validate.noNullElements(Object[]) to varargs
[ https://issues.apache.org/jira/browse/LANG-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson updated LANG-724: - Fix Version/s: 3.0.1 > Convert Validate.noNullElements(Object[]) to varargs > > > Key: LANG-724 > URL: https://issues.apache.org/jira/browse/LANG-724 > Project: Commons Lang > Issue Type: Sub-task > Components: General >Affects Versions: 3.0 >Reporter: Matt Benson >Priority: Minor > Fix For: 3.x, 3.0.1 > > > IIRC such is binary-compatible and so is not a worry. Typically the call > would exist to validate an array that was already constructed and so wouldn't > serve much purpose; however it is conceivable that a caller might wish to > validate together several arguments _he_ received separately. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-724) Convert Validate.noNullElements(Object[]) to varargs
[ https://issues.apache.org/jira/browse/LANG-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved LANG-724. -- Resolution: Fixed Committed revision 1147524. > Convert Validate.noNullElements(Object[]) to varargs > > > Key: LANG-724 > URL: https://issues.apache.org/jira/browse/LANG-724 > Project: Commons Lang > Issue Type: Sub-task > Components: General >Affects Versions: 3.0 >Reporter: Matt Benson >Priority: Minor > Fix For: 3.x, 3.0.1 > > > IIRC such is binary-compatible and so is not a worry. Typically the call > would exist to validate an array that was already constructed and so wouldn't > serve much purpose; however it is conceivable that a caller might wish to > validate together several arguments _he_ received separately. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-728) StringEscapeUtils.escapeXml(str) does not support supplemental characters.
[
https://issues.apache.org/jira/browse/LANG-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-728:
---
Fix Version/s: 3.0.1
> StringEscapeUtils.escapeXml(str) does not support supplemental characters.
> --
>
> Key: LANG-728
> URL: https://issues.apache.org/jira/browse/LANG-728
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 2.6
>Reporter: Taro Yabuki
>Priority: Minor
> Labels: patch
> Fix For: 3.0.1
>
> Attachments: lang_2_6_escapexml_20110716.diff
>
>
> Hello.
> StringEscapeUtils.escapeXml(str) escapes Unicode characters greater than 0x7f
> to their numerical \\u equivalent:
> String str = StringEscapeUtils.escapeXml("\uD84C\uDFB4");
> System.out.println(str);
> //��
> But, the output should be 𣎴.
> According to W3C document "Using character escapes in markup and CSS," We
> must use the single, code point value for supplemental character.
> http://www.w3.org/International/questions/qa-escapes
> In fact, �� is not rendered correctly in some web browsers
> e.g., Firefox 5.0 and Chrome 12.0.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-729) StringEscapeUtils.unescapeXml(str) does not support supplemental characters.
[
https://issues.apache.org/jira/browse/LANG-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-729:
---
Fix Version/s: 3.0.1
> StringEscapeUtils.unescapeXml(str) does not support supplemental characters.
>
>
> Key: LANG-729
> URL: https://issues.apache.org/jira/browse/LANG-729
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 2.6
>Reporter: Taro Yabuki
>Priority: Trivial
> Labels: patch
> Fix For: 3.0.1
>
> Attachments: lang_2_6_unescapexml_20110716.diff
>
>
> StringEscapeUtils.unescapeXml(str) does not unescape numeric character
> references of supplemental characters:
> String str2 = StringEscapeUtils.unescapeXml("𣎴");
> System.out.println(str2.codePointAt(0));
> //38 (it means '&'.)
> This output should be 144308.
> Currently, StringEscapeUtils.unescapeXml(StringEscapeUtils.escapeXml(str)) is
> equal to str, so it doesn't seem to be wrong. But, as we reported in
> LANG-728, StringEscapeUtils.escapeXml(str) has a bug. When the bug is fixed,
> StringEscapeUtils.unescapeXml(StringEscapeUtils.escapeXml(str)) would not be
> equal to str. We do not expect it. (Of course, we don't expect that
> StringEscapeUtils.unescapeXml(StringEscapeUtils.escapeXml(str)) is always
> equal to str.)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-721) Complement ArrayUtils.addAll() variants with by-index and by-value removal methods
[
https://issues.apache.org/jira/browse/LANG-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell updated LANG-721:
---
Fix Version/s: (was: 3.x)
> Complement ArrayUtils.addAll() variants with by-index and by-value removal
> methods
> --
>
> Key: LANG-721
> URL: https://issues.apache.org/jira/browse/LANG-721
> Project: Commons Lang
> Issue Type: Sub-task
> Components: lang.*
>Affects Versions: 3.0
>Reporter: Matt Benson
>Priority: Minor
> Fix For: 3.0.1
>
>
> these are:
> {noformat}
> T[] removeAll(T[] array, int... indices);
> byte[] removeAll(byte[] array, int... indices);
> short[] removeAll(short[] array, int... indices);
> int[] removeAll(int[] array, int... indices);
> char[] removeAll(char[] array, int... indices);
> long[] removeAll(long[] array, int... indices);
> float[] removeAll(float[] array, int... indices);
> double[] removeAll(double[] array, int... indices);
> boolean[] removeAll(boolean[] array, int... indices);
> T[] removeElements(T[] array, Object... values);
> byte[] removeElements(byte[] array, byte... values);
> short[] removeElements(short[] array, short... values);
> int[] removeElements(int[] array, int... values);
> char[] removeElements(char[] array, char... values);
> long[] removeElements(long[] array, long... values);
> float[] removeElements(float[] array, float... values);
> double[] removeElements(double[] array, double... values);
> boolean[] removeElements(boolean[] array, boolean... values);
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-722) Add BooleanUtils.and/or varargs methods to complement xor
[ https://issues.apache.org/jira/browse/LANG-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Yandell updated LANG-722: --- Fix Version/s: (was: 3.x) 3.0.1 > Add BooleanUtils.and/or varargs methods to complement xor > - > > Key: LANG-722 > URL: https://issues.apache.org/jira/browse/LANG-722 > Project: Commons Lang > Issue Type: Sub-task > Components: General >Reporter: Matt Benson >Priority: Minor > Fix For: 3.0.1 > > > object and primitive variants; clone from xor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (LANG-723) Add mode and median Comparable... methods to ObjectUtils
[
https://issues.apache.org/jira/browse/LANG-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066583#comment-13066583
]
Matt Benson edited comment on LANG-723 at 7/17/11 4:25 AM:
---
Committed revision 1147522.
Implemented median with the decision that an even number of values would result
in an approximation by simply returning the lower of the two middle values.
Also included:
{{ /* not required to be comparable */ T median(Comparator, T...)}}
was (Author: mbenson):
Committed revision 1147522.
Implemented median with the decision that an even number of values would result
in an approximation by simply returning the lower of the two middle values.
Also included {{ /* not required to be comparable */ T median(Comparator,
T...)}}
> Add mode and median Comparable... methods to ObjectUtils
>
>
> Key: LANG-723
> URL: https://issues.apache.org/jira/browse/LANG-723
> Project: Commons Lang
> Issue Type: Sub-task
> Components: General
>Reporter: Matt Benson
>Priority: Minor
> Fix For: 3.x
>
>
> ObjectUtils is the class where we have our Comparable support, so is the
> correct place for these.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-723) Add mode and median Comparable... methods to ObjectUtils
[
https://issues.apache.org/jira/browse/LANG-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved LANG-723.
--
Resolution: Fixed
Committed revision 1147522.
Implemented median with the decision that an even number of values would result
in an approximation by simply returning the lower of the two middle values.
Also included {{ /* not required to be comparable */ T median(Comparator,
T...)}}
> Add mode and median Comparable... methods to ObjectUtils
>
>
> Key: LANG-723
> URL: https://issues.apache.org/jira/browse/LANG-723
> Project: Commons Lang
> Issue Type: Sub-task
> Components: General
>Reporter: Matt Benson
>Priority: Minor
> Fix For: 3.x
>
>
> ObjectUtils is the class where we have our Comparable support, so is the
> correct place for these.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-722) Add BooleanUtils.and/or varargs methods to complement xor
[ https://issues.apache.org/jira/browse/LANG-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Benson resolved LANG-722. -- Resolution: Fixed Committed revision 1147511. > Add BooleanUtils.and/or varargs methods to complement xor > - > > Key: LANG-722 > URL: https://issues.apache.org/jira/browse/LANG-722 > Project: Commons Lang > Issue Type: Sub-task > Components: General >Reporter: Matt Benson >Priority: Minor > Fix For: 3.x > > > object and primitive variants; clone from xor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LANG-721) Complement ArrayUtils.addAll() variants with by-index and by-value removal methods
[
https://issues.apache.org/jira/browse/LANG-721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved LANG-721.
--
Resolution: Fixed
Fix Version/s: 3.0.1
Committed revision 1147507.
> Complement ArrayUtils.addAll() variants with by-index and by-value removal
> methods
> --
>
> Key: LANG-721
> URL: https://issues.apache.org/jira/browse/LANG-721
> Project: Commons Lang
> Issue Type: Sub-task
> Components: lang.*
>Affects Versions: 3.0
>Reporter: Matt Benson
>Priority: Minor
> Fix For: 3.x, 3.0.1
>
>
> these are:
> {noformat}
> T[] removeAll(T[] array, int... indices);
> byte[] removeAll(byte[] array, int... indices);
> short[] removeAll(short[] array, int... indices);
> int[] removeAll(int[] array, int... indices);
> char[] removeAll(char[] array, int... indices);
> long[] removeAll(long[] array, int... indices);
> float[] removeAll(float[] array, int... indices);
> double[] removeAll(double[] array, int... indices);
> boolean[] removeAll(boolean[] array, int... indices);
> T[] removeElements(T[] array, Object... values);
> byte[] removeElements(byte[] array, byte... values);
> short[] removeElements(short[] array, short... values);
> int[] removeElements(int[] array, int... values);
> char[] removeElements(char[] array, char... values);
> long[] removeElements(long[] array, long... values);
> float[] removeElements(float[] array, float... values);
> double[] removeElements(double[] array, double... values);
> boolean[] removeElements(boolean[] array, boolean... values);
> {noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dr. Dietmar Wolz updated MATH-621: -- Attachment: bobyqav0.3.zip rescue was as I feared not correct, the fixed version v0.3 behaves exactly as the original. A breakup of the working area in separate double arrays should be straightforward, but still some work because of the nasty loop counting starting with 1. Something like double[] xbase = new double[n]; double[] xpt = new double[n * npt]; double[] fval = new double[npt]; double[] xopt = new double[n]; double[] gopt = new double[n]; double[] hq = new double[n * np / 2]; double[] pq = new double[npt]; double[] bmat = new double[ndim * n]; double[] zmat = new double[npt * (npt - np)]; double[] sl = new double[n]; double[] su = new double[n]; double[] xnew = new double[n]; double[] xalt = new double[n]; double[] d__ = new double[n]; double[] vlag = new double[ndim]; double[] w = new double[?]; Class ScopePtr could then be removed and the code should get even faster. The "gotos"/ switches are much harder to eliminate. > BOBYQA is missing in optimization > - > > Key: MATH-621 > URL: https://issues.apache.org/jira/browse/MATH-621 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dr. Dietmar Wolz > Fix For: 3.0 > > Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip, > bobyqav0.3.zip > > Original Estimate: 8h > Remaining Estimate: 8h > > During experiments with space flight trajectory optimizations I recently > observed, that the direct optimization algorithm BOBYQA > http://plato.asu.edu/ftp/other_software/bobyqa.zip > from Mike Powell is significantly better than the simple Powell algorithm > already in commons.math. It uses significantly lower function calls and is > more reliable for high dimensional problems. You can replace CMA-ES in many > more application cases by BOBYQA than by the simple Powell optimizer. > I would like to contribute a Java port of the algorithm. > I maintained the structure of the original FORTRAN code, so the > code is fast but not very nice. > License status: Michael Powell has sent the agreement via snail mail > - it hasn't arrived yet. > Progress: The attached patch relative to the trunk contains both the > optimizer and the related unit tests - which are all green now. > Performance: > Performance difference (number of function evaluations) > PowellOptimizer / BOBYQA for different test functions (taken from > the unit test of BOBYQA, dimension=13 for most of the > tests. > Rosen = 9350 / 1283 > MinusElli = 118 / 59 > Elli = 223 / 58 > ElliRotated = 8626 / 1379 > Cigar = 353 / 60 > TwoAxes = 223 / 66 > CigTab = 362 / 60 > Sphere = 223 / 58 > Tablet = 223 / 58 > DiffPow = 421 / 928 > SsDiffPow = 614 / 219 > Ackley = 757 / 97 > Rastrigin = 340 / 64 > The number for DiffPow should be dicussed with Michael Powell, > I will send him the details. > Open Problems: > Some checkstyle violations because of the original Fortran source: > - Original method comments were copied - doesn't follow javadoc standard > - Multiple variable declarations in one line as in the original source > - Problems related to "goto" conversions: > "gotos" not convertible in loops were transated into a finite automata > (switch statement) > "no default in switch" > "fall through from previos case in switch" > which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CONFIGURATION-454) Malformed pom uploaded to repositories
[
https://issues.apache.org/jira/browse/CONFIGURATION-454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066530#comment-13066530
]
Joerg Schaible commented on CONFIGURATION-454:
--
I think this is a left-over from a M1 POM where the POM was actually a Jelly
script. Can't remember currently, but it might be that 1.6 was stilkl released
with M1 and the POM you're facing has been auto-converted" by Maven folks'
repository tools.
> Malformed pom uploaded to repositories
> --
>
> Key: CONFIGURATION-454
> URL: https://issues.apache.org/jira/browse/CONFIGURATION-454
> Project: Commons Configuration
> Issue Type: Bug
> Components: Build
>Affects Versions: 1.6
>Reporter: Kevin Meyer
>Priority: Minor
> Labels: maven
>
> The pom downloaded, for example, from:
> http://uk.maven.org/maven2/commons-configuration/commons-configuration/1.6/commons-configuration-1.6.pom
> is damaged: e.g. the is given as:
> http://commons.apache.org/${pom.artifactId.substring(8)}/
> ${basedir}
> etc.
> This affects the generated licenses for other projects.
> Compare with commons-collections, which is fine.
> Problems seems to be in trunk/project.xml ?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CONFIGURATION-454) Malformed pom uploaded to repositories
Malformed pom uploaded to repositories
--
Key: CONFIGURATION-454
URL: https://issues.apache.org/jira/browse/CONFIGURATION-454
Project: Commons Configuration
Issue Type: Bug
Components: Build
Affects Versions: 1.6
Reporter: Kevin Meyer
Priority: Minor
The pom downloaded, for example, from:
http://uk.maven.org/maven2/commons-configuration/commons-configuration/1.6/commons-configuration-1.6.pom
is damaged: e.g. the is given as:
http://commons.apache.org/${pom.artifactId.substring(8)}/
${basedir}
etc.
This affects the generated licenses for other projects.
Compare with commons-collections, which is fine.
Problems seems to be in trunk/project.xml ?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066464#comment-13066464 ] Gilles commented on MATH-621: - There's no hurry. I'm not going to stop sleeping until the conversion is done; there is so much to do... I've also started reading the reference [paper|http://www.optimization-online.org/DB_FILE/2010/05/2616.pdf] in the hope to figure the algorithm bits out of the Fortran gigantic functions. > BOBYQA is missing in optimization > - > > Key: MATH-621 > URL: https://issues.apache.org/jira/browse/MATH-621 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dr. Dietmar Wolz > Fix For: 3.0 > > Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip > > Original Estimate: 8h > Remaining Estimate: 8h > > During experiments with space flight trajectory optimizations I recently > observed, that the direct optimization algorithm BOBYQA > http://plato.asu.edu/ftp/other_software/bobyqa.zip > from Mike Powell is significantly better than the simple Powell algorithm > already in commons.math. It uses significantly lower function calls and is > more reliable for high dimensional problems. You can replace CMA-ES in many > more application cases by BOBYQA than by the simple Powell optimizer. > I would like to contribute a Java port of the algorithm. > I maintained the structure of the original FORTRAN code, so the > code is fast but not very nice. > License status: Michael Powell has sent the agreement via snail mail > - it hasn't arrived yet. > Progress: The attached patch relative to the trunk contains both the > optimizer and the related unit tests - which are all green now. > Performance: > Performance difference (number of function evaluations) > PowellOptimizer / BOBYQA for different test functions (taken from > the unit test of BOBYQA, dimension=13 for most of the > tests. > Rosen = 9350 / 1283 > MinusElli = 118 / 59 > Elli = 223 / 58 > ElliRotated = 8626 / 1379 > Cigar = 353 / 60 > TwoAxes = 223 / 66 > CigTab = 362 / 60 > Sphere = 223 / 58 > Tablet = 223 / 58 > DiffPow = 421 / 928 > SsDiffPow = 614 / 219 > Ackley = 757 / 97 > Rastrigin = 340 / 64 > The number for DiffPow should be dicussed with Michael Powell, > I will send him the details. > Open Problems: > Some checkstyle violations because of the original Fortran source: > - Original method comments were copied - doesn't follow javadoc standard > - Multiple variable declarations in one line as in the original source > - Problems related to "goto" conversions: > "gotos" not convertible in loops were transated into a finite automata > (switch statement) > "no default in switch" > "fall through from previos case in switch" > which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-279) Tailer erroneously consider file as new
Tailer erroneously consider file as new
---
Key: IO-279
URL: https://issues.apache.org/jira/browse/IO-279
Project: Commons IO
Issue Type: Bug
Affects Versions: 2.0.1
Reporter: Sergio Bossa
Tailer sometimes erroneously consider the tailed file as new, forcing a
repositioning at the start of the file: I'm still unable to reproduce this in a
test case, because it only happens to me with huge log files during Apache
Tomcat startup.
This is the piece of code causing the problem:
// See if the file needs to be read again
if (length > position) {
// The file has more content than it did last time
last = System.currentTimeMillis();
position = readLines(reader);
} else if (FileUtils.isFileNewer(file, last)) {
/* This can happen if the file is truncated or overwritten
* with the exact same length of information. In cases like
* this, the file position needs to be reset
*/
position = 0;
reader.seek(position); // cannot be null here
// Now we can read new lines
last = System.currentTimeMillis();
position = readLines(reader);
}
What probably happens is that the new file content is about to be written on
disk, the date is already updated but content is still not flushed, so actual
length is untouched and there you go.
In other words, I think there should be some better method to verify the
condition above, rather than relying only on dates: keeping and comparing the
hash code of the latest line may be a solution, but may hurt performances ...
other ideas?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[
https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066425#comment-13066425
]
Dr. Dietmar Wolz commented on MATH-621:
---
Now I remember that I debugged rescue (and removed a nasty infinite loop)
testing MinusElli with GoalType.MAXIMIZE before I fixed the
GoalType.MAXIMIZE handling. Testing MinusElli with GoalType.MINIMIZE still
calls rescue:
@Test
public void testRescue() {
double[] startPoint = point(DIM,1.0);
double[][] boundaries = null;
RealPointValuePair expected =
new RealPointValuePair(point(DIM,0.0),-7.5072566333E53);
doTest(new MinusElli(), startPoint, boundaries,
GoalType.MINIMIZE,
1e45, 1e24, 1000, expected);
}
But parallel testing with the original revealed a problem, so please wait a few
hours before working on rescue, I will fix it soon.
> BOBYQA is missing in optimization
> -
>
> Key: MATH-621
> URL: https://issues.apache.org/jira/browse/MATH-621
> Project: Commons Math
> Issue Type: New Feature
>Affects Versions: 3.0
>Reporter: Dr. Dietmar Wolz
> Fix For: 3.0
>
> Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> During experiments with space flight trajectory optimizations I recently
> observed, that the direct optimization algorithm BOBYQA
> http://plato.asu.edu/ftp/other_software/bobyqa.zip
> from Mike Powell is significantly better than the simple Powell algorithm
> already in commons.math. It uses significantly lower function calls and is
> more reliable for high dimensional problems. You can replace CMA-ES in many
> more application cases by BOBYQA than by the simple Powell optimizer.
> I would like to contribute a Java port of the algorithm.
> I maintained the structure of the original FORTRAN code, so the
> code is fast but not very nice.
> License status: Michael Powell has sent the agreement via snail mail
> - it hasn't arrived yet.
> Progress: The attached patch relative to the trunk contains both the
> optimizer and the related unit tests - which are all green now.
> Performance:
> Performance difference (number of function evaluations)
> PowellOptimizer / BOBYQA for different test functions (taken from
> the unit test of BOBYQA, dimension=13 for most of the
> tests.
> Rosen = 9350 / 1283
> MinusElli = 118 / 59
> Elli = 223 / 58
> ElliRotated = 8626 / 1379
> Cigar = 353 / 60
> TwoAxes = 223 / 66
> CigTab = 362 / 60
> Sphere = 223 / 58
> Tablet = 223 / 58
> DiffPow = 421 / 928
> SsDiffPow = 614 / 219
> Ackley = 757 / 97
> Rastrigin = 340 / 64
> The number for DiffPow should be dicussed with Michael Powell,
> I will send him the details.
> Open Problems:
> Some checkstyle violations because of the original Fortran source:
> - Original method comments were copied - doesn't follow javadoc standard
> - Multiple variable declarations in one line as in the original source
> - Problems related to "goto" conversions:
> "gotos" not convertible in loops were transated into a finite automata
> (switch statement)
> "no default in switch"
> "fall through from previos case in switch"
> which usually are bad style make no sense here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JEXL-117) JEXL not evaluating java Long
[
https://issues.apache.org/jira/browse/JEXL-117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066421#comment-13066421
]
Henri Biestro commented on JEXL-117:
No defined date and most likely a 2.1 instead (see
http://apache-commons.680414.n4.nabble.com/JEXL-Towards-a-JEXL-2-1-release-tt3669436.html).
In the mean time, you can use a 2.0.2-SNAPSHOT available in
https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-jexl/
.
Cheers,
Henrib
> JEXL not evaluating java Long
> -
>
> Key: JEXL-117
> URL: https://issues.apache.org/jira/browse/JEXL-117
> Project: Commons JEXL
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Dave Marion
>Assignee: Henri Biestro
> Labels: Long, NumberFormatException
> Fix For: 2.0.2
>
>
> Trying to evaluate a long in a Jexl expression and the engine tries to cast
> it to an Integer.
> Expression e = engine.createExpression("TIMESTAMP > 2010010200");
> JexlContext ctx = new MapContext();
> ctx.set("TIMESTAMP", new Long("2010010300"));
> e.evaluate(ctx);
> throws a NumberFormatException at Integer.parseInt().
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IO-278) Improve Tailer performance with buffered reads
[ https://issues.apache.org/jira/browse/IO-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066415#comment-13066415 ] Sergio Bossa commented on IO-278: - Also, while I was at it I fixed a concurrency bug in TestTailerListener causing intermittent test failures (the lines list needed to be thread safe). > Improve Tailer performance with buffered reads > -- > > Key: IO-278 > URL: https://issues.apache.org/jira/browse/IO-278 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 2.0.1 >Reporter: Sergio Bossa > Attachments: Tailer.diff, TailerTest.diff > > > I noticed Tailer read performances are pretty poor when dealing with large, > frequently written, log files, and this is due to the use of RandomAccessFile > which does unbuffered reads, hence causing lots of disk I/O. > So I improved the Tailer implementation by introducing buffered reads: it > works by loading large (configurable) file chunks in memory, and reading > lines from there; this enhances performances in my tests from 10x to 30x > depending on the file size. > I also added two test cases: one to simulate reading of a large file (you can > use it to compare performances), the other to verify correct handling on > buffer breaks; obviously, all tests pass. > I'm attaching the diff files, let me know if it's okay for you guys! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (IO-278) Improve Tailer performance with buffered reads
Improve Tailer performance with buffered reads -- Key: IO-278 URL: https://issues.apache.org/jira/browse/IO-278 Project: Commons IO Issue Type: Improvement Affects Versions: 2.0.1 Reporter: Sergio Bossa Attachments: Tailer.diff, TailerTest.diff I noticed Tailer read performances are pretty poor when dealing with large, frequently written, log files, and this is due to the use of RandomAccessFile which does unbuffered reads, hence causing lots of disk I/O. So I improved the Tailer implementation by introducing buffered reads: it works by loading large (configurable) file chunks in memory, and reading lines from there; this enhances performances in my tests from 10x to 30x depending on the file size. I also added two test cases: one to simulate reading of a large file (you can use it to compare performances), the other to verify correct handling on buffer breaks; obviously, all tests pass. I'm attaching the diff files, let me know if it's okay for you guys! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (IO-278) Improve Tailer performance with buffered reads
[ https://issues.apache.org/jira/browse/IO-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergio Bossa updated IO-278: Attachment: TailerTest.diff Tailer.diff > Improve Tailer performance with buffered reads > -- > > Key: IO-278 > URL: https://issues.apache.org/jira/browse/IO-278 > Project: Commons IO > Issue Type: Improvement >Affects Versions: 2.0.1 >Reporter: Sergio Bossa > Attachments: Tailer.diff, TailerTest.diff > > > I noticed Tailer read performances are pretty poor when dealing with large, > frequently written, log files, and this is due to the use of RandomAccessFile > which does unbuffered reads, hence causing lots of disk I/O. > So I improved the Tailer implementation by introducing buffered reads: it > works by loading large (configurable) file chunks in memory, and reading > lines from there; this enhances performances in my tests from 10x to 30x > depending on the file size. > I also added two test cases: one to simulate reading of a large file (you can > use it to compare performances), the other to verify correct handling on > buffer breaks; obviously, all tests pass. > I'm attaching the diff files, let me know if it's okay for you guys! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066399#comment-13066399 ] Gilles commented on MATH-621: - In fact I'm more worried about introducing bugs that will go unnoticed. ;) > BOBYQA is missing in optimization > - > > Key: MATH-621 > URL: https://issues.apache.org/jira/browse/MATH-621 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dr. Dietmar Wolz > Fix For: 3.0 > > Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip > > Original Estimate: 8h > Remaining Estimate: 8h > > During experiments with space flight trajectory optimizations I recently > observed, that the direct optimization algorithm BOBYQA > http://plato.asu.edu/ftp/other_software/bobyqa.zip > from Mike Powell is significantly better than the simple Powell algorithm > already in commons.math. It uses significantly lower function calls and is > more reliable for high dimensional problems. You can replace CMA-ES in many > more application cases by BOBYQA than by the simple Powell optimizer. > I would like to contribute a Java port of the algorithm. > I maintained the structure of the original FORTRAN code, so the > code is fast but not very nice. > License status: Michael Powell has sent the agreement via snail mail > - it hasn't arrived yet. > Progress: The attached patch relative to the trunk contains both the > optimizer and the related unit tests - which are all green now. > Performance: > Performance difference (number of function evaluations) > PowellOptimizer / BOBYQA for different test functions (taken from > the unit test of BOBYQA, dimension=13 for most of the > tests. > Rosen = 9350 / 1283 > MinusElli = 118 / 59 > Elli = 223 / 58 > ElliRotated = 8626 / 1379 > Cigar = 353 / 60 > TwoAxes = 223 / 66 > CigTab = 362 / 60 > Sphere = 223 / 58 > Tablet = 223 / 58 > DiffPow = 421 / 928 > SsDiffPow = 614 / 219 > Ackley = 757 / 97 > Rastrigin = 340 / 64 > The number for DiffPow should be dicussed with Michael Powell, > I will send him the details. > Open Problems: > Some checkstyle violations because of the original Fortran source: > - Original method comments were copied - doesn't follow javadoc standard > - Multiple variable declarations in one line as in the original source > - Problems related to "goto" conversions: > "gotos" not convertible in loops were transated into a finite automata > (switch statement) > "no default in switch" > "fall through from previos case in switch" > which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SANSELAN-13) Problem loading JPEG metada
[ https://issues.apache.org/jira/browse/SANSELAN-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066388#comment-13066388 ] Damjan Jovanovic commented on SANSELAN-13: -- For one, the JPEG comment segment is too long, causing either parsing to fail, or the next segment to be skipped (depending on how resilient the parser is). I've just committed a patch to SVN that should allow getBufferedImage() to work for both files and getImageInfo() to work for 10200023936.jpg, but getMetadata() still fails for both files because of other, TIFF-related problems. > Problem loading JPEG metada > --- > > Key: SANSELAN-13 > URL: https://issues.apache.org/jira/browse/SANSELAN-13 > Project: Commons Sanselan > Issue Type: Question >Reporter: Bruno Abreu >Priority: Minor > Attachments: 10200023566.jpg, 10200023936.jpg > > > I'm trying to load the metadata from image files generated by a JAI-PULNIX > camera, model TS-1327EN. > I am specifically interested in getting the following tag values: > ExifTagConstants.EXIF_TAG_IMAGE_DESCRIPTION, > ExifTagConstants.EXIF_TAG_DATE_TIME_ORIGINAL and > ExifTagConstants.EXIF_TAG_SUB_SEC_TIME_ORIGINAL. > But, when the following line of code is executed: > IImageMetadata metadata = Sanselan.getMetadata(file); > I get one of two errors: > java.io.IOException: Invalid Segment: insufficient data > at > org.apache.sanselan.common.BinaryFileFunctions.readByteArray(BinaryFileFunctions.java:497) > at > org.apache.sanselan.formats.jpeg.JpegUtils.traverseJFIF(JpegUtils.java:88) > at > org.apache.sanselan.formats.jpeg.JpegImageParser.readSegments(JpegImageParser.java:175) > at > org.apache.sanselan.formats.jpeg.JpegImageParser.readSegments(JpegImageParser.java:273) > at > org.apache.sanselan.formats.jpeg.JpegImageParser.getExifRawData(JpegImageParser.java:383) > at > org.apache.sanselan.formats.jpeg.JpegImageParser.getExifMetadata(JpegImageParser.java:363) > at > org.apache.sanselan.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:314) > at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:871) > at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:864) > at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:839) > at MetadataExample.metadataExample(MetadataExample.java:21) > or > java.io.IOException: Could not read block (block start: 1020, block length: > 1447680, data length: 900). > at > org.apache.sanselan.common.byteSources.ByteSourceArray.getBlock(ByteSourceArray.java:47) > at > org.apache.sanselan.formats.tiff.TiffReader.getTiffRawImageData(TiffReader.java:409) > at > org.apache.sanselan.formats.tiff.TiffReader.readDirectory(TiffReader.java:197) > at > org.apache.sanselan.formats.tiff.TiffReader.readDirectory(TiffReader.java:100) > at > org.apache.sanselan.formats.tiff.TiffReader.readDirectories(TiffReader.java:92) > at org.apache.sanselan.formats.tiff.TiffReader.read(TiffReader.java:399) > at > org.apache.sanselan.formats.tiff.TiffReader.readContents(TiffReader.java:390) > at > org.apache.sanselan.formats.tiff.TiffImageParser.getMetadata(TiffImageParser.java:125) > at org.apache.sanselan.ImageParser.getMetadata(ImageParser.java:76) > at > org.apache.sanselan.formats.jpeg.JpegImageParser.getExifMetadata(JpegImageParser.java:376) > at > org.apache.sanselan.formats.jpeg.JpegImageParser.getMetadata(JpegImageParser.java:314) > at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:871) > at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:864) > at org.apache.sanselan.Sanselan.getMetadata(Sanselan.java:839) > at MetadataExample.metadataExample(MetadataExample.java:21) > Is there something wrong with the encoding of these images? > If that is the case I could contact JAI-PULNIX and ask them to fix it, but > I'm not sure what the problem is. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-729) StringEscapeUtils.unescapeXml(str) does not support supplemental characters.
StringEscapeUtils.unescapeXml(str) does not support supplemental characters.
Key: LANG-729
URL: https://issues.apache.org/jira/browse/LANG-729
Project: Commons Lang
Issue Type: Improvement
Components: lang.*
Affects Versions: 2.6
Reporter: Taro Yabuki
Priority: Trivial
Attachments: lang_2_6_unescapexml_20110716.diff
StringEscapeUtils.unescapeXml(str) does not unescape numeric character
references of supplemental characters:
String str2 = StringEscapeUtils.unescapeXml("𣎴");
System.out.println(str2.codePointAt(0));
//38 (it means '&'.)
This output should be 144308.
Currently, StringEscapeUtils.unescapeXml(StringEscapeUtils.escapeXml(str)) is
equal to str, so it doesn't seem to be wrong. But, as we reported in LANG-728,
StringEscapeUtils.escapeXml(str) has a bug. When the bug is fixed,
StringEscapeUtils.unescapeXml(StringEscapeUtils.escapeXml(str)) would not be
equal to str. We do not expect it. (Of course, we don't expect that
StringEscapeUtils.unescapeXml(StringEscapeUtils.escapeXml(str)) is always equal
to str.)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-729) StringEscapeUtils.unescapeXml(str) does not support supplemental characters.
[
https://issues.apache.org/jira/browse/LANG-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taro Yabuki updated LANG-729:
-
Attachment: lang_2_6_unescapexml_20110716.diff
Test code and patch for org/apache/commons/lang/Entities.java.
> StringEscapeUtils.unescapeXml(str) does not support supplemental characters.
>
>
> Key: LANG-729
> URL: https://issues.apache.org/jira/browse/LANG-729
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.*
>Affects Versions: 2.6
>Reporter: Taro Yabuki
>Priority: Trivial
> Labels: patch
> Attachments: lang_2_6_unescapexml_20110716.diff
>
>
> StringEscapeUtils.unescapeXml(str) does not unescape numeric character
> references of supplemental characters:
> String str2 = StringEscapeUtils.unescapeXml("𣎴");
> System.out.println(str2.codePointAt(0));
> //38 (it means '&'.)
> This output should be 144308.
> Currently, StringEscapeUtils.unescapeXml(StringEscapeUtils.escapeXml(str)) is
> equal to str, so it doesn't seem to be wrong. But, as we reported in
> LANG-728, StringEscapeUtils.escapeXml(str) has a bug. When the bug is fixed,
> StringEscapeUtils.unescapeXml(StringEscapeUtils.escapeXml(str)) would not be
> equal to str. We do not expect it. (Of course, we don't expect that
> StringEscapeUtils.unescapeXml(StringEscapeUtils.escapeXml(str)) is always
> equal to str.)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LANG-728) StringEscapeUtils.escapeXml(str) does not support supplemental characters.
[
https://issues.apache.org/jira/browse/LANG-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taro Yabuki updated LANG-728:
-
Attachment: lang_2_6_escapexml_20110716.diff
Test code and patch for org/apache/commons/lang/Entities.java.
> StringEscapeUtils.escapeXml(str) does not support supplemental characters.
> --
>
> Key: LANG-728
> URL: https://issues.apache.org/jira/browse/LANG-728
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
>Affects Versions: 2.6
>Reporter: Taro Yabuki
>Priority: Minor
> Labels: patch
> Attachments: lang_2_6_escapexml_20110716.diff
>
>
> Hello.
> StringEscapeUtils.escapeXml(str) escapes Unicode characters greater than 0x7f
> to their numerical \\u equivalent:
> String str = StringEscapeUtils.escapeXml("\uD84C\uDFB4");
> System.out.println(str);
> //��
> But, the output should be 𣎴.
> According to W3C document "Using character escapes in markup and CSS," We
> must use the single, code point value for supplemental character.
> http://www.w3.org/International/questions/qa-escapes
> In fact, �� is not rendered correctly in some web browsers
> e.g., Firefox 5.0 and Chrome 12.0.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LANG-728) StringEscapeUtils.escapeXml(str) does not support supplemental characters.
StringEscapeUtils.escapeXml(str) does not support supplemental characters.
--
Key: LANG-728
URL: https://issues.apache.org/jira/browse/LANG-728
Project: Commons Lang
Issue Type: Bug
Components: lang.*
Affects Versions: 2.6
Reporter: Taro Yabuki
Priority: Minor
Hello.
StringEscapeUtils.escapeXml(str) escapes Unicode characters greater than 0x7f
to their numerical \\u equivalent:
String str = StringEscapeUtils.escapeXml("\uD84C\uDFB4");
System.out.println(str);
//��
But, the output should be 𣎴.
According to W3C document "Using character escapes in markup and CSS," We must
use the single, code point value for supplemental character.
http://www.w3.org/International/questions/qa-escapes
In fact, �� is not rendered correctly in some web browsers e.g.,
Firefox 5.0 and Chrome 12.0.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-621) BOBYQA is missing in optimization
[ https://issues.apache.org/jira/browse/MATH-621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13066380#comment-13066380 ] Dr. Dietmar Wolz commented on MATH-621: --- Confirmed - this also happens with the original code, I will ask Mike Powell to provide us with a function exercising rescue. You are probably suspicious whether the Java rescue works, as am I. > BOBYQA is missing in optimization > - > > Key: MATH-621 > URL: https://issues.apache.org/jira/browse/MATH-621 > Project: Commons Math > Issue Type: New Feature >Affects Versions: 3.0 >Reporter: Dr. Dietmar Wolz > Fix For: 3.0 > > Attachments: BOBYQA.math.patch, BOBYQA.v02.math.patch, bobyqa.zip > > Original Estimate: 8h > Remaining Estimate: 8h > > During experiments with space flight trajectory optimizations I recently > observed, that the direct optimization algorithm BOBYQA > http://plato.asu.edu/ftp/other_software/bobyqa.zip > from Mike Powell is significantly better than the simple Powell algorithm > already in commons.math. It uses significantly lower function calls and is > more reliable for high dimensional problems. You can replace CMA-ES in many > more application cases by BOBYQA than by the simple Powell optimizer. > I would like to contribute a Java port of the algorithm. > I maintained the structure of the original FORTRAN code, so the > code is fast but not very nice. > License status: Michael Powell has sent the agreement via snail mail > - it hasn't arrived yet. > Progress: The attached patch relative to the trunk contains both the > optimizer and the related unit tests - which are all green now. > Performance: > Performance difference (number of function evaluations) > PowellOptimizer / BOBYQA for different test functions (taken from > the unit test of BOBYQA, dimension=13 for most of the > tests. > Rosen = 9350 / 1283 > MinusElli = 118 / 59 > Elli = 223 / 58 > ElliRotated = 8626 / 1379 > Cigar = 353 / 60 > TwoAxes = 223 / 66 > CigTab = 362 / 60 > Sphere = 223 / 58 > Tablet = 223 / 58 > DiffPow = 421 / 928 > SsDiffPow = 614 / 219 > Ackley = 757 / 97 > Rastrigin = 340 / 64 > The number for DiffPow should be dicussed with Michael Powell, > I will send him the details. > Open Problems: > Some checkstyle violations because of the original Fortran source: > - Original method comments were copied - doesn't follow javadoc standard > - Multiple variable declarations in one line as in the original source > - Problems related to "goto" conversions: > "gotos" not convertible in loops were transated into a finite automata > (switch statement) > "no default in switch" > "fall through from previos case in switch" > which usually are bad style make no sense here. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
