Now, string.Normalize(NormalizationForm.FormC) doesn't do anything using
mono (r136228).
I've attached some test cases which will hopefully help in tracking down
what doesn't work.
On 6/15/09 1:58 AM, Atsushi Eno atsushi...@veritas-vos-liberabit.com
wrote:
Hi again,
It should be now fixed
Tom Philpot wrote:
Now, string.Normalize(NormalizationForm.FormC) doesn't do anything using
mono (r136228).
Have you updated and rebuilt both mono mcs trees?
Robert
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
1. updated mono and mcs from svn
2. Did 'make clean' from mcs/class and mono directories
3. Did 'make' from mono directory
4. Did 'sudo make install' from mono
WS1048:mono-project tom.philpot$ /opt/mono/bin/mono --version
Mono JIT compiler version 2.5 (/trunk/mono r136341 Wed Jun 17 11:53:03 PDT
Hi,
We've just released Mono 2.4.2p2 today!
Please help us out by giving it a try with your applications.
Excellent news - I'm building it for Fedora rawhide as I type this
email.
One thing - please when you release can you put a meaningful filename on
the website which says if something
You seem to have embedded raw native encoding in your land that
is *not* understandable in Japan. Anyways the input string you
posted in the previous sample was already in FormC which will
look like doing nothing as the conversion results.
There is a standalone normalization test generated from
Atsushi,
Thanks for the feedback. For some reason, the Mac when displaying unicode
always composes strings before display. I'll look at the test case in corlib
tomorrow when I get in to work. Would it be helpful for the test cases if I
gave you both the formD bytes and the formC bytes that I
