On 2014-04-25, 3:31 AM, Henri Sivonen wrote:
On Fri, Apr 25, 2014 at 2:03 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:
* Are we building and shipping dead code in ICU on B2G?
No. That is at least partly covered by bug 864843.
Using system ICU seems wrong in terms of correctness. That's the
reason why we don't use system ICU on Mac and desktop Linux, right?
If I'm reading that bug correctly, we're not trying to use the system
ICU there.
In my experience, ICU is unfortunately a hot potato. :( The real blocker
there is finding someone who can tell us what bits of ICU _are_ used in the
JS engine.
Apart from ICU initialization/shutdown, the callers seem to be
http://mxr.mozilla.org/mozilla-central/source/js/src/builtin/Intl.cpp
and http://mxr.mozilla.org/mozilla-central/source/js/src/jsstr.cpp#852
.
So the JS engine uses:
* Collation
* Number formatting
* Date and time formatting
* Normalization
It looks like the JS engine has its own copy of the Unicode database
for other purposes. It seems like that should be unified with ICU so
that there'd be only one copy of the Unicode database.
Additionally, we should probably rewrite nsCollation users to use ICU
collation and delete nsCollation.
Therefore, it looks like we should turn off (if we haven't already):
* The ICU LayoutEngine.
* Ustdio
* ICU encoding converters and their mapping tables.
* ICU break iterators and their data.
* ICU transliterators and their data.
http://apps.icu-project.org/datacustom/ gives a good idea of what
there is to turn off.
Are you looking into these? They all seem like great things to investigate.
Also, If the ICU build system is an configurable enough, I think we
should consider identifying what parts of ICU we can delete even
though the build system doesn't let us to and then automate the
deletion as a script so that it can be repeated with future imports of
ICU.
You need to ask Waldo about that, I think, since he is the person who
did the latest ICU update.
* Do we have any mechanisms in place for preventing stuff like the
ICU encoding converters becoming part of the building the future?
No, that is not possible to automate.
I was thinking of policy / review solutions.
Oh I see. I think this should be part of the normal code review process
already. But perhaps we just need to act on it better. I can't think
of any policy changes which would be of a substantial help, the best
that I can think of is reminding people through these kinds of
discussions (and thanks for starting this one!)
* How should we identify code that we build but that isn't used
anywhere?
I'm afraid we need humans for that.
Yeah, but how do we get humans to do that?
It's a hard question. Not everybody is going to care much about this.
In the case of something like ICU it's actually relatively easy for
someone to detect the dead code here even without intimate knowledge of
the code being used, but in many cases determining dead code really
requires a bit of domain expertise, or the willingness to read and learn
some new code.
I think it would be a great idea if module owners filed mentored bugs on
deleting the dead code that they already know of, or even to investigate
whether something that they suspect is actually dead code.
Cheers,
Ehsan
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
