Hello,
I keep silent as it's rather about runtime issue, but since there is no
one giving further comments on the bug, I think no one can complain if
it got checked in svn.
Damien, thanks for the patch.
Atsushi Eno
On 2010/06/11 23:36, Damien Diederen wrote:
Hello,
Has anybody had a look
Hi Miguel,
I finally had an opportunity to look into this, and just uploaded v5 of
this series:
- The non-BMP portions of the tables are omitted when the
preprocessor symbol DISABLE_ASTRAL is defined;
- The runtime now supports two sets of tables, one for 2.0–3.5 and
one for 4.0.
Also, this patch (for string normalization) has nothing to do with
string collation, which is very windows-specific and has nothing to do
with unicode standards. .NET's string collation has (hence) nothing to
do with Char.GetUnicodeCategory() either.
It is getting obsoleted and turned off by
Hello,
This approach grows the category data table from 64 to ~70kB, and
requires an additional 8kB index for the astral planes. The resulting
runtime produces the same results as Microsoft's v2.0.50727 and
v3.5.21022 for the whole Unicode range, but has no support for v4.
Would that be
Hi Miguel,
Miguel de Icaza mig...@novell.com writes:
Hello,
This approach grows the category data table from 64 to ~70kB, and
requires an additional 8kB index for the astral planes. The resulting
runtime produces the same results as Microsoft's v2.0.50727 and
v3.5.21022 for the whole
Hello,
MS have (or used to on 2.0) a lot of broken stuff when it comes to
unicode/locales.
So sometimes fixing for MS compatibility means breaking correctness.
It might be time to revisit this policy.
Currently the situation is that we kept compatibility with Microsoft as
Microsoft's work on
Hi
To me this seems like it is time for a change in policy: our string
collation should reflect what the rules are in Unicode as it will be
easier for us to maintain.
Miguel.
In that case, we might as well use ICU.
Zoltan
___
That can certainly be done. I suppose you envision a compile-time
switch? Is there already such an option/flag/preprocessor symbol I
should use as a model?
For C code, just use the symbol DISABLE_ASTRAL, then we can add that to
configure.in
Sure. I guess this means some more compile-time
To me this seems like it is time for a change in policy: our
string
collation should reflect what the rules are in Unicode as it
will be easier for us to maintain.
In that case, we might as well use ICU.
I do not want to go back to the business of
-list@lists.ximian.com
Betreff: [Mono-dev] [PATCHES] Bug 480178 -
System.Globalization.CharUnicodeInfo.GetUnicodeCategory() does not handle
surrogate characters appropriately.
Hi,
I just uploaded an updated series of patches addressing bug 480178:
https://bugzilla.novell.com/show_bug.cgi?id
Hi Andreas,
Andreas Nahr classdevelopm...@a-softtech.com writes:
Hi,
I'm the author (of a large part) of the current Char class and
unfortunately I think you overlooked some things with the changes.
What you are doing is (heavily) degrading the performance of most of
the char methods
There are a few things to notice when extending unicode data.
MS have (or used to on 2.0) a lot of broken stuff when it comes to
unicode/locales.
So sometimes fixing for MS compatibility means breaking correctness.
On Sat, May 15, 2010 at 12:04 PM, Damien Diederen d...@crosstwine.com wrote:
Hi Rodrigo,
Rodrigo Kumpera kump...@gmail.com writes:
There are a few things to notice when extending unicode data.
MS have (or used to on 2.0) a lot of broken stuff when it comes to
unicode/locales.
So sometimes fixing for MS compatibility means breaking correctness.
I'm sure you are
Hi,
I just uploaded an updated series of patches addressing bug 480178:
https://bugzilla.novell.com/show_bug.cgi?id=480178#c27
This is ready to be committed as far as I am concerned, but comments are
of course welcome. Note that I do *not* have commit privileges, so
somebody else will have
14 matches
Mail list logo
