On Wed, Jul 31, 2013 at 6:53 AM, Joshua Cranmer pidgeo...@gmail.comwrote:
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
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 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 m...@glandium.org 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
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
On Wed, Jul 31, 2013 at 01:06:27PM +0200, Brian Smith wrote:
On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey m...@glandium.org 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
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 phi...@aleytys.pc.my, philip.c...@gmail.com
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf
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 repositories
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
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
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
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
___
On Tue, Jul 30, 2013 at 6:26 PM, Ehsan Akhgari ehsan.akhg...@gmail.com 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/
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
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
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 this proposal
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
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
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
On Wed, Jul 31, 2013 at 3:22 PM, Joshua Cranmer pidgeo...@gmail.com 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
22 matches
Mail list logo
