On Wed, Jul 31, 2013 at 6:53 AM, Joshua Cranmer 🐧 wrote:
> On 7/30/2013 10:39 PM, Brian Smith wrote:
>
>> Yes: Then we can use std::unique_ptr in parts of Gecko that are intended
>> to
>> be buildable without MFBT (see below).
>>
>
> One thing I want to point out is that, while compiler features a
On 30/07/2013 22.40, Andreas Gal wrote:
> Whats the main pain point? Whether promises are resolved immediately or
> from a future event loop iteration?
That. The migration from "core/promise.js" to "Promise.jsm" should
address consumers expecting callbacks to be called immediately.
"Promises.jsm"
On 30/07/2013 16.20, janjongb...@gmail.com wrote:
> From code I can use Cu.import("resource://gre/modules/Promise.jsm"); to use
> promises. But is it possible to have a promise as a return type in my .idl
> file (b2g)?
For the record, if you want to pass a "Promise.jsm" promise through an
XPCOM
On 29/07/2013 19:43, Gregory Szorc wrote:
I'm proposing that we merge all the release repositories (central,
aurora, beta, release, esr, and b2g) into a single Mercurial repository.
The "default" branch/bookmark of this repository would be the equivalent
of mozilla-central. At train uplift time,
On Wed, Jul 31, 2013 at 10:25:15AM +0200, Brian Smith wrote:
> We should be more aggressive in requiring newer compiler versions
> whenever practical, and we should choose to support as few
> compiler/library combinations as we can get away with. That way we can
> use as many C++11/14 features (not
On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey wrote:
> I strongly oppose to any requirement that would make ESR+2 (ESR31) not
> build on the current Debian stable (gcc 4.7) and make ESR+1 (ESR24) not
> build on the old Debian stable (gcc 4.4). We're not going to change the
> requirements for the
On 07/31/13 05:54 AM, Marco Bonardo wrote:
> On 29/07/2013 19:43, Gregory Szorc wrote:
>> I'm proposing that we merge all the release repositories (central,
>> aurora, beta, release, esr, and b2g) into a single Mercurial repository.
>> The "default" branch/bookmark of this repository would be the e
On Wed, Jul 31, 2013 at 01:06:27PM +0200, Brian Smith wrote:
> On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey wrote:
>
> > I strongly oppose to any requirement that would make ESR+2 (ESR31)
> > not build on the current Debian stable (gcc 4.7) and make ESR+1
> > (ESR24) not build on the old Debian
On 31/07/2013 13:14, Ben Hearsum wrote:
On 07/31/13 05:54 AM, Marco Bonardo wrote:
Now, maybe I'm wrong, but IIRC this is what we had before the rapid
release, and we switched away from that cause:
Releases have always had their own repositories (see
https://hg.mozilla.org/releases/mozilla-1.9
On 31/07/2013 00:35, Ehsan Akhgari wrote:
> bug 872127
I pushed a comm-central bustage fix:
https://hg.mozilla.org/comm-central/rev/e4c4ff49ed66
Phil
--
Philip Chee ,
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
On 07/31/13 08:43 AM, Marco Bonardo wrote:
> On 31/07/2013 13:14, Ben Hearsum wrote:
>> On 07/31/13 05:54 AM, Marco Bonardo wrote:
>>> Now, maybe I'm wrong, but IIRC this is what we had before the rapid
>>> release, and we switched away from that cause:
>>
>> Releases have always had their own repo
On 7/31/13 2:54 AM, Marco Bonardo wrote:
- handling queue of patches for different branches is a nightmare, I
often have patches in queues for aurora, beta and central at the same time
Wouldn't switching branches in the same repo clone touch many files and
trigger unfortunately clobber builds?
On 2013-07-29 4:07 PM, Gregory Szorc wrote:
On 7/29/13 12:49 PM, Ehsan Akhgari wrote:
On 2013-07-29 2:06 PM, Benjamin Smedberg wrote:
Given all the things that we could be doing instead, why is this
important to do now?
I share Benjamin's concern.
Legit concern. Probably low priority. I wan
On 2013-07-31 11:49 AM, Chris Peterson wrote:
On 7/31/13 2:54 AM, Marco Bonardo wrote:
- handling queue of patches for different branches is a nightmare, I
often have patches in queues for aurora, beta and central at the same
time
Wouldn't switching branches in the same repo clone touch many f
On 2013-07-31 8:47 AM, Philip Chee wrote:
On 31/07/2013 00:35, Ehsan Akhgari wrote:
bug 872127
I pushed a comm-central bustage fix:
https://hg.mozilla.org/comm-central/rev/e4c4ff49ed66
Thank you! Sorry that I missed c-c.
Cheers,
Ehsan
___
dev-pl
On Tue, Jul 30, 2013 at 6:26 PM, Ehsan Akhgari wrote:
> Please let me know if you have any questions.
I'm not at all comfortable with adding data races to the platform. Or
did we solve them in some manner?
--
http://annevankesteren.nl/
___
dev-platfo
>> Wouldn't switching branches in the same repo clone touch many files and
>> trigger unfortunately clobber builds? Even with ccache and separate
>> per-branch objdirs, this seems like a problem.
>
> Yes.
Nothing about this proposal forces you to have only one clone and
switch back and forth betwe
On 2013-07-31 1:25 PM, Anne van Kesteren wrote:
On Tue, Jul 30, 2013 at 6:26 PM, Ehsan Akhgari wrote:
Please let me know if you have any questions.
I'm not at all comfortable with adding data races to the platform. Or
did we solve them in some manner?
We have not implemented the racy versio
tl;dr - I ask some questions near the end, you probably need to read the
entire post to be able to insightfully answer them.
The Mozilla codebase, which I define loosely as mozilla-central,
comm-central, JS, NSS, NSPR, LDAP C SDKs, and any other small project
included in mozilla-central that i
On 7/31/2013 3:25 AM, Brian Smith wrote:
On Wed, Jul 31, 2013 at 6:53 AM, Joshua Cranmer 🐧 wrote:
On 7/30/2013 10:39 PM, Brian Smith wrote:
Yes: Then we can use std::unique_ptr in parts of Gecko that are intended
to
be buildable without MFBT (see below).
One thing I want to point out is tha
On 2013-07-31 1:41 PM, Joshua Cranmer 🐧 wrote:
With all of that stated, the questions I want to pose to the community
at large are as follows:
1. How much, and where, should we be using standard C++ library
functionality in Mozilla code?
I'm not sure if it's easy to have this discussion in gene
> 1. How much, and where, should we be using standard C++ library
> functionality in Mozilla code?
We've tuned tarray, nsthashtable, strings, etc. to meet our precise
needs, and the implementations are consistent across all platforms.
I can imagine things becoming quite messy we had three or four
On 7/31/2013 2:08 PM, Ehsan Akhgari wrote:
On 2013-07-31 1:41 PM, Joshua Cranmer 🐧 wrote:
With all of that stated, the questions I want to pose to the community
at large are as follows:
1. How much, and where, should we be using standard C++ library
functionality in Mozilla code?
I'm not sure
On 7/31/2013 2:38 PM, Justin Lebar wrote:
1. How much, and where, should we be using standard C++ library
functionality in Mozilla code?
We've tuned tarray, nsthashtable, strings, etc. to meet our precise
needs, and the implementations are consistent across all platforms.
I can imagine things be
On Wed, Jul 31, 2013 at 10:28:38AM -0700, Justin Lebar wrote:
> >> Wouldn't switching branches in the same repo clone touch many files
> >> and trigger unfortunately clobber builds? Even with ccache and
> >> separate per-branch objdirs, this seems like a problem.
> >
> > Yes.
>
> Nothing about thi
> Sadly, mercurial doesn't support having multiple working directories
> from a single clone, which would be useful to avoid wasting so much disk
> space on .hg.
I'm not usually one to defend hg, but hg does have the |relink|
command, which gets you most of the way there in terms of saving disk
sp
On 7/31/13 5:59 PM, Justin Lebar wrote:
Sadly, mercurial doesn't support having multiple working directories
from a single clone, which would be useful to avoid wasting so much disk
space on .hg.
I'm not usually one to defend hg, but hg does have the |relink|
command, which gets you most of the
On Wed, Jul 31, 2013 at 12:41:12PM -0500, Joshua Cranmer ? wrote:
> Thoughts/comments/corrections/questions/concerns/flames/insightful
> discussion?
My feeling is that, while these are interesting questions, they are one
step ahead. I think we should step back and start by defining what we
want to
On 7/31/2013 9:19 PM, Mike Hommey wrote:
On Wed, Jul 31, 2013 at 12:41:12PM -0500, Joshua Cranmer ? wrote:
Thoughts/comments/corrections/questions/concerns/flames/insightful
discussion?
My feeling is that, while these are interesting questions, they are one
step ahead. I think we should step ba
On Wed, Jul 31, 2013 at 3:22 PM, Joshua Cranmer 🐧 wrote:
> We also have needs like
> sizeOfIncludingThis/sizeOfExcludingThis that can't be as easily satisfied
> with STL code.
This is, unsurprisingly, a requirement that's close to my heart. We
actually have a few instances of std:: classes alrea
30 matches
Mail list logo
