Hello,
Paolo Molaro wrote:
All of that is fine, except that you get incorrect data, since we have arrays
of shorts or ints, so we either give incorrect results on bigendian systems
or we introduce code to byteswap at runtime, needlessly slowing down the code.
The code should do what we already do for the char data: embed the arrays
in mono so the endianess is correct and there are no build systems changes.
Using managed resources for this is a net loss. Using and mmapping external
files
instead of embedding them has the same (well, less) build system complexity
of embedding the correct endian files as managed resources.
After some thoughts, I made some changes and all ushort tables
are gone (removed widthCompat table and made cjk* table as byte
arrays). I still have integer and char based array
(collation.tailoring.bin), but it is the smallest collation
resource - the half of it is not directly mapped (it consists of
a complex structure) and the latter half is not that big, nearly
2000 characters for now. So I don't think it is a big problem.
So I think the problems w/ managed resource are gone. But I'm
still open to make changes on the code to unmanaged one, if there
are still problems on managed resource way.
Atsushi Eno
_______________________________________________
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
