On Mon, Dec 03, 2012 at 05:25:55PM -0500, Rafael Ávila de Espíndola
wrote:
> >
> > Actually, ICU has several options for how its data is packaged. One
> > option is libraries (which are not sharable between architectures,
> > AFAIK), but another possibility is to use data package (.dat) files,
> >
Hi,
- Original Message -
> From: "Justin Lebar"
> To: "Norbert Lindenberg"
> Cc: "Benjamin Smedberg" ,
> dev-platform@lists.mozilla.org
> Sent: Monday, December 3, 2012 7:54:34 PM
> Subject: Re: Integrating ICU into Mozilla build
>
> > Is all code loaded into memory as one lump on B2G,
A year ago, I investigated to replace uconv with ICU.
Many (most is IBM code page) converters in ICU isn't compatible with
uconv, and ICU isn't have all character set converters that we already
use in uconv.
If using ICU for uconv, we can remove a few table code into uconv, but
not all.
-
> Is all code loaded into memory as one lump on B2G, or is it paged in as
> needed? There may be quite a bit of code in there that's not commonly needed.
I don't know how it works, to be honest. I can't imagine that library
pages are loaded only on demand with no pre-fetching, since that would
b
On Tue, Dec 4, 2012 at 2:04 PM, Norbert Lindenberg
wrote:
> Understood. Now, how does B2G support internationalization in the absence of
> ICU?
Possibly it uses ICU already. There's an external/icu4c in the B2G repository.
Chris.
--
http://www.bluishcoder.co.nz
On Tue, Dec 4, 2012 at 1:12 PM, wrote:
> I've seen issue https://bugzilla.mozilla.org/show_bug.cgi?id=504071 in a
> lot of sites I've been working on recently. There are white lines between
> two adjacent scaled images.
>
> I'd like to help with a fix, if possible. Does anyone have any deep
> ins
On Dec 3, 2012, at 14:10 , Jonathan Kew wrote:
> On 3/12/12 20:11, Mike Hommey wrote:
>> On Mon, Dec 03, 2012 at 02:48:06PM -0500, Benjamin Smedberg wrote:
>>> On 12/3/2012 2:32 PM, Norbert Lindenberg wrote:
As part of implementing the ECMAScript Internationalization API [1, 2] in
Spid
On Dec 3, 2012, at 16:15 , Justin Lebar wrote:
> On Mon, Dec 3, 2012 at 5:39 PM, Norbert Lindenberg
> wrote:
>>
>> Well, the first question is what size increase would be acceptable given the
>> benefits that ICU provides.
>
>> I have currently trimmed it to 9.7 MB for the data library and 3.
On Mon, Dec 3, 2012 at 5:39 PM, Norbert Lindenberg
wrote:
>
> Well, the first question is what size increase would be acceptable given the
> benefits that ICU provides.
> I have currently trimmed it to 9.7 MB for the data library and 3.1 MB for two
> code libraries.
Ignoring download size for
I've seen issue https://bugzilla.mozilla.org/show_bug.cgi?id=504071 in a lot of
sites I've been working on recently. There are white lines between two adjacent
scaled images.
I'd like to help with a fix, if possible. Does anyone have any deep insight
into this bug that could point me in the rig
Neil wrote:
>> static const PRUnichar* kResetBackupDirectory =
>> NS_LITERAL_STRING("resetBackupDirectory").get();
Isn't this an anti-pattern anyway because the string (and the memory owned by
it) will get destructed after the semicolon "runs" leaving
kResetBackupDirectory pointing at deleted me
On Dec 3, 2012, at 11:48 , Benjamin Smedberg wrote:
> On 12/3/2012 2:32 PM, Norbert Lindenberg wrote:
>> As part of implementing the ECMAScript Internationalization API [1, 2] in
>> SpiderMonkey, and as an aid in internationalizing other functionality in
>> Mozilla products [3], I need to integ
>
> Actually, ICU has several options for how its data is packaged. One option is
> libraries (which are not sharable between architectures, AFAIK), but another
> possibility is to use data package (.dat) files, which I believe *could* be
> shared between the 32- and 64-bit builds.
getting a b
On 3/12/12 20:11, Mike Hommey wrote:
On Mon, Dec 03, 2012 at 02:48:06PM -0500, Benjamin Smedberg wrote:
On 12/3/2012 2:32 PM, Norbert Lindenberg wrote:
As part of implementing the ECMAScript Internationalization API [1, 2] in
SpiderMonkey, and as an aid in internationalizing other functionalit
Peter,
The FirefoxDriver drive does, as Clint points out, speak via XPCOM to
the browser to get access. Granted there is a lot of JavaScript that
needs to be executed for calls. We are doing rewriting it to put it into
Gecko[1] because it allows us to implement the Browser Automation W3C
Spec
On Mon, Dec 03, 2012 at 09:11:58PM +0100, Mike Hommey wrote:
> On Mon, Dec 03, 2012 at 02:48:06PM -0500, Benjamin Smedberg wrote:
> > On 12/3/2012 2:32 PM, Norbert Lindenberg wrote:
> > >As part of implementing the ECMAScript Internationalization API [1, 2] in
> > >SpiderMonkey, and as an aid in i
On Mon, Dec 03, 2012 at 02:48:06PM -0500, Benjamin Smedberg wrote:
> On 12/3/2012 2:32 PM, Norbert Lindenberg wrote:
> >As part of implementing the ECMAScript Internationalization API [1, 2] in
> >SpiderMonkey, and as an aid in internationalizing other functionality in
> >Mozilla products [3], I
On 12/3/2012 2:32 PM, Norbert Lindenberg wrote:
As part of implementing the ECMAScript Internationalization API [1, 2] in
SpiderMonkey, and as an aid in internationalizing other functionality in
Mozilla products [3], I need to integrate the ICU library (International
Components for Unicode [4]
On Mon, Dec 3, 2012 at 11:32 AM, Norbert Lindenberg <
mozillali...@lindenbergsoftware.com> wrote:
> As part of implementing the ECMAScript Internationalization API [1, 2] in
> SpiderMonkey, and as an aid in internationalizing other functionality in
> Mozilla products [3], I need to integrate the I
As part of implementing the ECMAScript Internationalization API [1, 2] in
SpiderMonkey, and as an aid in internationalizing other functionality in
Mozilla products [3], I need to integrate the ICU library (International
Components for Unicode [4]) into the source tree and the build.
For integra
I originally sent this as a reply to the "Minimum Required Python
Version" thread. Per request, I'm reposting as a new topic so it doesn't
go unnoticed. We will also likely discuss this at the engineering
meeting tomorrow. SeaMonkey has also requested an additional week to
switch things over, s
On Mon, Dec 3, 2012 at 12:05 PM, romaxa wrote:
> Native Theme implementation in Qt port is in very bad shape, and
> practically was never tested, because Qt XUL Fennec use css scrollbars, and
> native scroll indicators are disabled.
> there are 2 ways to fix this problem:
> 1) Fix Qt native theme
Native Theme implementation in Qt port is in very bad shape, and practically
was never tested, because Qt XUL Fennec use css scrollbars, and native scroll
indicators are disabled.
there are 2 ways to fix this problem:
1) Fix Qt native themeing.
2) disable widget native themeing (set preference
m
On 12/1/2012 2:29 PM, Gregory Szorc wrote:
The bump to Python 2.6 seemed to go OK. So, I think it's time to finish
the transition and bump the minimum to Python 2.7.
Per the previous discussion on this list, I don't believe we have any
outstanding objections. So, I propose we move forward with t
I'm not sure what you mean because as best I understand it, the Selenium
Firefox driver is an extension and thus runs in the same process space
as Firefox itself. If you're looking for a closer binding between your
automation code and Firefox, you can take a look at our new automation
mechanis
On Dec 3, 5:41 am, Felipe Junges wrote:
> Em quinta-feira, 29 de novembro de 2012 14h48min56s UTC-3, Jeff Hammel
> escreveu:
>
>
>
>
>
>
>
>
>
> > Wild guess in the dark here, and assuming `py` == "the python
>
> > executable", it looks like you're using python 3.x (again wild guess)
>
> > where
This is what happens now:
1. Updates checked for in versino 0.0.1, says that 0.0.2 is available
2. The partial update downloads and applies as per above, and a restart is
prompted
3. After restart, the old version is still running, and checking for updates
downloads the full update
4. After resta
Em quinta-feira, 29 de novembro de 2012 14h48min56s UTC-3, Jeff Hammel
escreveu:
> Wild guess in the dark here, and assuming `py` == "the python
>
> executable", it looks like you're using python 3.x (again wild guess)
>
> whereas in python 2.x "print
>
> getBuiltinOrNativeTypeName(self.par
28 matches
Mail list logo