Do builds feel like they've gotten faster in the last few weeks^hours?
It's because they have.
When I did my MacBook Pro comparison [1] with a changeset from Oct 28,
build times on my 2013 2.6 GHz MacBook Pro were as follows:
Wall 11:13 (673)
User 69:55 (4195)
Sys6:04 (364)
Total 75:59 (4
On Tuesday 2013-11-19 17:08 +1300, Robert O'Callahan wrote:
> Fortunately two static variables with the same name in the same translation
> unit is an error in C++, at least with gcc.
Ah, indeed. I'd tested in C, where it wasn't an error, but I also
see an error with gcc in C++.
-David
--
𝄞
On 11/18/2013 8:02 PM, Mike Hommey wrote:
Hi,
I am going to land a long series of patches that changes how Gecko code
linkage is defined.
As a comm-central build system peer (best viewed in fixed-width font):
_ _ ___ _ _ __ __ _ _ _ _
|_ _| | | | / \ | \ | | |/ /
On Tue, Nov 19, 2013 at 4:04 PM, L. David Baron wrote:
> I expect that otherwise we'd get pretty frequent bustage with people
> forgetting to add #includes, and that bustage would then show up
> when we add or remove files, which would make it a huge pain to add
> or remove files.
>
> But I'm act
On 2013-11-18 10:16 PM, Mike Hommey wrote:
On Tue, Nov 19, 2013 at 11:04:25AM +0800, L. David Baron wrote:
On Monday 2013-11-18 18:44 -0500, Ehsan Akhgari wrote:
On 2013-11-17 7:50 PM, L. David Baron wrote:
On Sunday 2013-11-17 16:45 -0800, Jonas Sicking wrote:
On Thu, Nov 14, 2013 at 2:49 PM
On 2013-11-18 10:04 PM, L. David Baron wrote:
On Monday 2013-11-18 18:44 -0500, Ehsan Akhgari wrote:
On 2013-11-17 7:50 PM, L. David Baron wrote:
On Sunday 2013-11-17 16:45 -0800, Jonas Sicking wrote:
On Thu, Nov 14, 2013 at 2:49 PM, Ehsan Akhgari wrote:
I've started to work on a project in
On Tue, Nov 19, 2013 at 11:04:25AM +0800, L. David Baron wrote:
> On Monday 2013-11-18 18:44 -0500, Ehsan Akhgari wrote:
> > On 2013-11-17 7:50 PM, L. David Baron wrote:
> > >On Sunday 2013-11-17 16:45 -0800, Jonas Sicking wrote:
> > >>On Thu, Nov 14, 2013 at 2:49 PM, Ehsan Akhgari
> > >>wrote:
>
On Monday 2013-11-18 18:44 -0500, Ehsan Akhgari wrote:
> On 2013-11-17 7:50 PM, L. David Baron wrote:
> >On Sunday 2013-11-17 16:45 -0800, Jonas Sicking wrote:
> >>On Thu, Nov 14, 2013 at 2:49 PM, Ehsan Akhgari
> >>wrote:
> >>>I've started to work on a project in my spare time to switch us to use
On Tue, Nov 19, 2013 at 3:32 PM, Mike Hommey wrote:
> FWIW, there's an open bug to fold gkmedias back into xul, but it looks
> like it's not going to happen soon.
> https://bugzilla.mozilla.org/show_bug.cgi?id=922912
>
Egad! Oh well.
Rob
--
Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanut
On Tue, Nov 19, 2013 at 03:12:23PM +1300, Robert O'Callahan wrote:
> Lovely!!!
>
> On Tue, Nov 19, 2013 at 3:02 PM, Mike Hommey wrote:
>
> > - FINAL_LIBRARY defines what library your code is going to be linked
> > into. That needs to match an existing LIBRARY_NAME in some other
> > moz.build
Lovely!!!
On Tue, Nov 19, 2013 at 3:02 PM, Mike Hommey wrote:
> - FINAL_LIBRARY defines what library your code is going to be linked
> into. That needs to match an existing LIBRARY_NAME in some other
> moz.build. Most code will go in either xul, gkmedias or gklayout. Note
> gklayout may go
Hi,
I am going to land a long series of patches that changes how Gecko code
linkage is defined.
Currently, when you add new code (like, a new module) to Gecko, you:
- Add a new directory
- Edit the parent moz.build to add the directory
- Add your source files
- Add a new moz.build defining at lea
On 11/18/2013 4:54 PM, Dave Townsend wrote:
There are add-ons using the existing promises implementations. Is there any
reason not to make those wrappers around the DOM promises to avoid
potential bustage?
At least the add-on SDK promises library provides functionality beyond that
that appears t
Hi,
I'm wondering if there's any further development going on for persistent tabs
in Firefox that can't be accidentally closed - it's mentioned here
https://bugzilla.mozilla.org/show_bug.cgi?id=551849 but Pinned Tabs aren't
quite what I'm looking for.
In fact, it looks like the original project
> My intention is:
> 1) Enable Promises for all chrome code.
Is this plan that enable to use DOM Promise in all chrome code?
I think, Promise will be introduced in ECMA6, then we will be able to
use Promise as one of the standard library of ECMAScript in js code
module environment, when Spidermon
There are add-ons using the existing promises implementations. Is there any
reason not to make those wrappers around the DOM promises to avoid
potential bustage?
At least the add-on SDK promises library provides functionality beyond that
that appears to be in the DOM promises (custom prototypes fo
(Cross posted to firefox-dev, please reply on dev.platform)
DOM Promise has been in the tree for a while, and is enabled for
ChromeWorkers and certified apps. With a couple of patches, it will achieve
conformance with the AP2 spec [1], which is what TC39 has accepted as the
bare minimum for Promis
On 2013-11-17 7:50 PM, L. David Baron wrote:
On Sunday 2013-11-17 16:45 -0800, Jonas Sicking wrote:
On Thu, Nov 14, 2013 at 2:49 PM, Ehsan Akhgari wrote:
I've started to work on a project in my spare time to switch us to use
unified builds for C/C++ compilation. The way that unified builds wo
On 2013-11-17 7:45 PM, Jonas Sicking wrote:
On Thu, Nov 14, 2013 at 2:49 PM, Ehsan Akhgari wrote:
I've started to work on a project in my spare time to switch us to use
unified builds for C/C++ compilation. The way that unified builds work is
by using the UNIFIED_SOURCES instead of the SOURCES
On 2013-11-18 9:53 AM, Boris Zbarsky wrote:
On 11/18/13 9:49 AM, Benoit Jacob wrote:
2) Keep these cpp files, that #include system headers, in plain old
SOURCES, not in UNIFIED_SOURCES.
Maybe that's the right way to go. Enforce that no .cpp file that's in
UNIFIED_SOURCES ever includes the b
On 2013-11-18 3:52 PM, Robert O'Callahan wrote:
On Tue, Nov 19, 2013 at 3:31 AM, Boris Zbarsky wrote:
While true, in the new setup we have a different problem: adding or
removing a .cpp file makes other random .cpp files not compile.
I don't think we should worry much about this until we ha
On 2013-11-17 7:53 PM, Jonas Sicking wrote:
On Sat, Nov 16, 2013 at 1:34 AM, Ms2ger wrote:
One issue I only thought of today: this means that Source2.cpp can use all
headers included into Source1.cpp–until enough files are added between
Source1 and Source2 that Source2 ends up in the next unif
On 2013-11-18 4:33 AM, Neil wrote:
Ehsan Akhgari wrote:
I've started to work on a project in my spare time to switch us to use
unified builds for C/C++ compilation. The way that unified builds
work is by using the UNIFIED_SOURCES instead of the SOURCES variable
in moz.build files. With that,
On 2013-11-17 5:39 PM, Mike Hommey wrote:
On Sat, Nov 16, 2013 at 10:34:38AM +0100, Ms2ger wrote:
On 11/14/2013 11:49 PM, Ehsan Akhgari wrote:
I've started to work on a project in my spare time to switch us to use
unified builds for C/C++ compilation. The way that unified builds work is
by usi
On 2013-11-18 7:17 AM, Ed Morley wrote:
On 16/11/2013 15:17, smaug wrote:
the recent OOM cases have been really annoying. They have slowed down
development, even for those who
haven't been dealing with the actual issue(s).
Could we handle this kind of cases differently. Perhaps clone the bad
st
On Tue, Nov 19, 2013 at 3:31 AM, Boris Zbarsky wrote:
> While true, in the new setup we have a different problem: adding or
> removing a .cpp file makes other random .cpp files not compile.
>
I don't think we should worry much about this until we have more data on
how often it's a problem in pra
On Tue, Nov 19, 2013 at 3:51 AM, Benjamin Smedberg
wrote:
> I'd like to announce and welcome Nathan Froyd as a peer of the XPCOM module.
> Nathan is a careful and thoughtful reviewer, and I'm happy that he has
> agreed to help spread review load and serve as the resident expert on
> performance an
On 11/16/13, 1:34 AM, Ms2ger wrote:
One way around it would be not to unify sources in automation. On one
hand, this could cause more bustage when changes that built locally turn
out not to have enough includes; on the other, it might be better than
having to fix up a dozen unrelated files whenev
Our weeklyesque DOM bindings meetings continue on Monday Nov 18 at 12:30 PM PDT.
http://arewemeetingyet.com/Los%20Angeles/Mon/12:30/w/DOM%20Bindings%20Meeting
Meeting details:
* Monday, November 18, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST)
* Dial-in Info:
- Vidyo room: Boris Zbarsky
- Mou
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 today, Monday, November 18th at 2:30 PM
US/Pacific
Please add to the agenda: https://wiki.mozilla.org/
I'd like to announce and welcome Nathan Froyd as a peer of the XPCOM
module. Nathan is a careful and thoughtful reviewer, and I'm happy that
he has agreed to help spread review load and serve as the resident
expert on performance and memshrink issues within XPCOM.
--BDS
__
Boris Zbarsky wrote:
On 11/17/13 5:26 PM, Ehsan Akhgari wrote:
I don't think that we need to try to fix this problem any more than
the general problem of denoting our dependencies explicitly. It's
common for you to remove an #include from a header and find dozens of
.cpp files in the tree t
On 11/18/13 9:49 AM, Benoit Jacob wrote:
2) Keep these cpp files, that #include system headers, in plain old
SOURCES, not in UNIFIED_SOURCES.
Maybe that's the right way to go. Enforce that no .cpp file that's in
UNIFIED_SOURCES ever includes the broken system headers, like we already
do fo
2013/11/18 Boris Zbarsky
> On 11/17/13 5:26 PM, Ehsan Akhgari wrote:
>
>> I don't think that we need to try to fix this problem any more than the
>> general problem of denoting our dependencies explicitly. It's common for
>> you to remove an #include from a header and find dozens of .cpp files i
On 11/17/13 5:26 PM, Ehsan Akhgari wrote:
I don't think that we need to try to fix this problem any more than the
general problem of denoting our dependencies explicitly. It's common for
you to remove an #include from a header and find dozens of .cpp files in
the tree that implicitly depended on
On 16/11/2013 15:17, smaug wrote:
the recent OOM cases have been really annoying. They have slowed down
development, even for those who
haven't been dealing with the actual issue(s).
Could we handle this kind of cases differently. Perhaps clone the bad
state of m-i to
some other repository we're
Ehsan Akhgari wrote:
I've started to work on a project in my spare time to switch us to use unified
builds for C/C++ compilation. The way that unified builds work is by using the
UNIFIED_SOURCES instead of the SOURCES variable in moz.build files. With that,
the build system creates files su
37 matches
Mail list logo
