I think that to have ICU included both in CVS and tarballs created for parrot is not the best way. I know Dan (and maybe some others) do not want to depend on too much libraries. The main problem should not be on depend on ICU, but ICU not being usual on most systems.
So, we are scripting people (or this wouldn't be a perl mailing list). Then, we should be able to make Configure to test if ICU is in the system. If not, use the Internet connection to get it, untar, configure and compile. I think that nowadays it is very difficult to find someone trying to compile parrot without a network connection.
OK, this is my feeling to the problem.
Cheers, Alb
Garrett Goebel wrote:
Joshua Gatcomb wrote:
Dan Sugalski <dan at sidhe dot org> wrote:
... and therefore ICU will continue to stay in CVS as part of parrot. Period.
The alternative here is the same alternative as with GMP and big numbers--we can yank ICU *if* someone writes an alternate Unicode implementation for us.
The following comments aren't directed at you Dan, just my personal opinion on ICU.
ICU is giving Parrot a black eye. The ICU we have in CVS right now is really old and broken. We are shipping a "bare bones" version of ICU that doesn't build very easily anywhere.
This sounds familiar. There was a Wine project interview with Wine's
internationalization guy, Shachar Shemesh a couple weeks back:
http://www.winehq.com/?interview=16
Shachar: ICU has all the BiDi support we will ever need.
Well, almost - it will probably be too hard to make it
more MS BiDi compatible, but that is not a major issue.
What is a major issue with ICU is that it is an entire
Unicode implementation. This means it has lots and lots
of stuff that Wine does itself. For example - GDI without
BiDi support is ~2MB. With BiDi support from ICU
statically linked, after ICU has been trimmed of all the
easy-to-remove stuff, it grows to ~4MB. Without this
trimming, it grows an additional 7MB to 11MB! Don't
forget that GDI neither uses nor needs most of that code.
I guess things would not be so bad if you could just say
"I'll just dynamically link it". For all practical
purposes, you can't. As a design decision, ICU has the
library version mangled into each function name. This
means that you have to have the same version installed
on the machine as the one you compiled with, or it won't
be usable. As a byproduct of this, nobody uses ICU
dynamically. Both Mozilla and OpenOffice use ICU for
their reordering, and both of them statically link it. As
a byproduct of that, almost no distro carries ICU, or
carry a very old version of it. In short, I would like to
ditch ICU as soon as possible.
-- Garrett Goebel IS Development Specialist
ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com garrett at scriptpro dot com
-- Alberto Simões
Much as I hate to say it, the Computer Science view of language design
has gotten too inbred in recent years. The Computer Scientists should
pay more attention to the Linguists, who have a much better handle on
how people prefer to communicate.
--Larry Wall
