Re: [classlib][luni]Float.toString - inaccuracy in the last digit

2010-09-16 Thread Deven You
Thanks Chance, I have read the spec again. From my understanding, the spec requires the value "x" of finite decimal represented by the Float.toString() meet below conditions: 1. the "f" is one of float values which are nearest to "x". 2. the number of the fractional part of "x" must be as many as

Re: [classlib] String.toLowerCase/toUpperCase incorrect for supplementary characters (HARMONY-6649)

2010-09-16 Thread Tim Ellison
On 16/Sep/2010 16:04, Robert Muir wrote: > On Thu, Sep 16, 2010 at 10:50 AM, Tim Ellison wrote: > >> The principle works ok. I attached a patch on HARMONY-6649 to show that >> making a local toUpperCase() method for the charset names solves the >> circularity problem in bootstrapping, and does t

Re: [classlib] String.toLowerCase/toUpperCase incorrect for supplementary characters (HARMONY-6649)

2010-09-16 Thread Robert Muir
On Thu, Sep 16, 2010 at 10:50 AM, Tim Ellison wrote: > > The principle works ok. I attached a patch on HARMONY-6649 to show that > making a local toUpperCase() method for the charset names solves the > circularity problem in bootstrapping, and does the right thing > irrespective of locale. > > T

Re: [classlib] String.toLowerCase/toUpperCase incorrect for supplementary characters (HARMONY-6649)

2010-09-16 Thread Tim Ellison
On 16/Sep/2010 14:30, Robert Muir wrote: > On Thu, Sep 16, 2010 at 9:26 AM, Tim Ellison wrote: > >> Yes, I agree (though I don't know what happens when it is uppercased >> 'properly' in Turkish) >> > > in this case it would be uppercased to US-ASCİİ (note the dotted i's) > > >> Nah, the Charse

Re: [classlib] String.toLowerCase/toUpperCase incorrect for supplementary characters (HARMONY-6649)

2010-09-16 Thread Robert Muir
On Thu, Sep 16, 2010 at 9:26 AM, Tim Ellison wrote: > > Yes, I agree (though I don't know what happens when it is uppercased > 'properly' in Turkish) > in this case it would be uppercased to US-ASCİİ (note the dotted i's) > > Nah, the Charset name is obliged to be a strict subset of characters

Re: [classlib] String.toLowerCase/toUpperCase incorrect for supplementary characters (HARMONY-6649)

2010-09-16 Thread Tim Ellison
On 16/Sep/2010 14:16, Robert Muir wrote: > On Thu, Sep 16, 2010 at 9:05 AM, Tim Ellison wrote: > >> On 16/Sep/2010 12:32, Robert Muir (JIRA) wrote: >>> Does this mean harmony might need these methods for its own internal >>> use before ICU is available? >> Yes, String is used early in the bootstr

Re: [classlib] String.toLowerCase/toUpperCase incorrect for supplementary characters (HARMONY-6649)

2010-09-16 Thread Robert Muir
On Thu, Sep 16, 2010 at 9:05 AM, Tim Ellison wrote: > On 16/Sep/2010 12:32, Robert Muir (JIRA) wrote: > > Does this mean harmony might need these methods for its own internal > > use before ICU is available? > > Yes, String is used early in the bootstrapping, and having dependencies > on ICU func

[classlib] String.toLowerCase/toUpperCase incorrect for supplementary characters (HARMONY-6649)

2010-09-16 Thread Tim Ellison
On 16/Sep/2010 12:32, Robert Muir (JIRA) wrote: > Does this mean harmony might need these methods for its own internal > use before ICU is available? Yes, String is used early in the bootstrapping, and having dependencies on ICU functionality leads to an initialization circularity. i.e. if I simp