On 08/03/04 Leon Brocard wrote:
> IIRC the mono people wrote their own, but with the ICU data files.
> Apart from license issues, this might be an interesting thing to look
> at.

We use some of the ICU data files for locale info like day/month names,
date/time formats etc. We have a tool that takes the data, merges with
our 'fixes' to the data and spits out C data structures.
We still use ICU for string collation if the libs are available.
For a number of reasons (ICU is huge for what we need from it, its
behaviour doesn't always match our requirements, it is an external
dependency, it uses C++ and others) we'd like to drop the ICU dependency
as soon as possible.
If people are interested, we might be able to cooperate to develop a 
library which does just that (unicode string collation) and which 
could be imported and used both in mono and parrot (with minimal or no
changes).
>From the mono point of view, the license would have to be of the MIT/X11
kind (though initially written in C, I'd like to be able to move the 
code to C# later to take advantage of the jit: our C# libs are MIT/X11
licensed). I guess this would be fine for parrot as well, but let me
know if it's not.
The other requirement is to efficiently handle UTF-16 strings, which are
the internal representation in the CLR (I don't care if the library can
also handle UTF-8 or UCS4: we just won't use those bits): ie as long as the
code doesn't need to convert the strings to UCS4 before operation, it 
should be fine.
I haven't investigated all the issues with collation support, so it
might end up that it's not practical to use the same code in mono and
parrot, but I thought I'd ask and see what people think.

lupus

-- 
-----------------------------------------------------------------
[EMAIL PROTECTED]                                     debian/rules
[EMAIL PROTECTED]                             Monkeys do it better

Reply via email to