On 11/29/13 4:47 AM, Robert Kaiser wrote:
> Just for my understanding (I have commented to users with huge, e.g.
> ~100MB sessionstore.js in bugs as well), I thought we were working on a
> rewrite of session store anyhow that would not kepp info of all tabs in
> one file?
>
> I think I have heard t
Hi all and FYI
unified build mode has increased memory usage of building with gcc
significantly.
On my laptop (8 gig mem) I started to see some swapping, and because of that
build times with unified mode weren't that much better than before.
But now, finally there is a use case for clang - it
The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm
PDT.
The next meeting will take place this coming Monday, December 2nd at 5:30 PM
US/Pacific
Please add to the agenda: https://wiki.mozilla.org/
Hi everyone,
Currently we're using the ICU library in our implementation of the JS Intl
API. We're also finding ourselves in the need of using ICU for other
things inside Gecko as well. Over in bug 915735, I've been working on a
number of strategies to make the ICU code callable form both mozjs.
On 11/29/13, 4:00 AM, Ehsan Akhgari wrote:
On 11/25/2013, 7:41 PM, Gregory Szorc wrote:
The repo was hiding that old changeset because it has been obsoleted
(Mercurial changeset evolution magic). I updated the server config to
expose hidden changesets, so the link works again.
However, the chan
On 11/30/13, 3:24 AM, smaug wrote:
Hi all and FYI
unified build mode has increased memory usage of building with gcc
significantly.
On my laptop (8 gig mem) I started to see some swapping, and because of
that
build times with unified mode weren't that much better than before.
But now, finally
On 11/29/13, 5:12 AM, Ehsan Akhgari wrote:
On 11/28/2013, 4:55 PM, Mike Hoye wrote:
On 11/28/2013, 4:45 PM, Nicholas Nethercote wrote:
I'm pretty sure that gps was saying "if you're paid to work by
Mozilla, get a faster machine". More generally, we're all in furious
agreement: fast builds are g
Hi,
Unified builds have been around for about two weeks. They are nice
because they make the build so much faster. On the other hand, we know
they currently break crash reports on mac (bug 943695), and can break
things in subtle ways (bug 942421, bug 943839). We don't know what
problems are still
On Sat, Nov 30, 2013 at 12:39:59PM +0900, Mike Hommey wrote:
> Incidentally, in those two weeks, I did two attempts at building
> without unified sources, resulting in me filing 4 bugs in different
> modules for problems caused by 6 different landings[1]. I think it is time
> to seriously think abo
On Sat, Nov 30, 2013 at 12:39:59PM +0900, Mike Hommey wrote:
> Hi,
>
> Unified builds have been around for about two weeks. They are nice
> because they make the build so much faster. On the other hand, we know
> they currently break crash reports on mac (bug 943695), and can break
> things in sub
If everyone puts "using namespace foo;" inside "namespace mozilla {}", that
won't help much, right?
I'd prefer to minimize the source code changes required here. A tinderbox
non-unified build seems like the way to go.
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eov
On Fri, Nov 29, 2013 at 8:01 PM, Mike Hommey wrote:
> That is:
>
> using namespace foo;
>
> would be forbidden, but
>
> namespace bar {
> using namespace foo;
> }
>
> wouldn't. In most cases, bar could be mozilla anyways.
>
Most XPConnect stuff isn't in an explicit namespace,
12 matches
Mail list logo
