Re: std::unique_ptr, std::move,

On 7/30/2013 10:39 PM, Brian Smith wrote: On Wed, Jul 31, 2013 at 4:50 AM, Ehsan Akhgari wrote: On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith wrote: But, shouldn't we just name these std::move and std::forward and use these implementations only when we're using STLPort? I know we're not suppos

Re: std::unique_ptr, std::move, and std::forward (was Re: Using C++0x auto)

On Wed, Jul 31, 2013 at 4:50 AM, Ehsan Akhgari wrote: > On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith wrote: > >> But, shouldn't we just name these std::move and std::forward and use these >> implementations only when we're using STLPort? I know we're not supposed >> to >> add stuff to the std:: na

Re: std::unique_ptr, std::move, and std::forward (was Re: Using C++0x auto)

On Tue, Jul 30, 2013 at 10:50:39PM -0400, Ehsan Akhgari wrote: > On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith > wrote: > > > On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey > > wrote: > > > > > Note that STL is another story. We're not using libstdc++ that > > > comes with the compiler on android a

Re: std::unique_ptr, std::move, and std::forward (was Re: Using C++0x auto)

On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith wrote: > On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey wrote: > > > Note that STL is another story. We're not using libstdc++ that comes > > with the compiler on android and b2g. We use STLport instead, and STLport > > has, afaik, no support for C++11

Re: reminder: content processes (e10s) are now used by desktop Firefox

On Tue, Jul 30, 2013 at 5:05 PM, Tom Schuster wrote: > Do we run JS code in these? I can imagine all sorts of things that > would cause a crash if JS code can invoke random dom apis. I however > very happy that we are testing in a limited > fashion with this. > > Tom > Most of the content-expos

Re: reminder: content processes (e10s) are now used by desktop Firefox

Yes, JS is enabled in the pages loaded by the background thumbnailing service (with JS disabled the thumbnails would likely not be very representative in a lot of cases). Gavin On Tue, Jul 30, 2013 at 5:05 PM, Tom Schuster wrote: > Do we run JS code in these? I can imagine all sorts of things

Re: reminder: content processes (e10s) are now used by desktop Firefox

Do we run JS code in these? I can imagine all sorts of things that would cause a crash if JS code can invoke random dom apis. I however very happy that we are testing in a limited fashion with this. Tom On Tue, Jul 30, 2013 at 7:10 PM, Gavin Sharp wrote: > I've mentioned this at the engineering

std::unique_ptr, std::move, and std::forward (was Re: Using C++0x auto)

On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey wrote: > Note that STL is another story. We're not using libstdc++ that comes > with the compiler on android and b2g. We use STLport instead, and STLport > has, afaik, no support for C++11 STL types. So, while we can now fix > nsAutoPtr to use move sem

Re: Proposal: requiring build peer review for Makefile.in changes

On Fri, Jul 26, 2013 at 9:36 PM, Brad Lassey wrote: > On 7/26/13 9:30 AM, Ehsan Akhgari wrote: > >> I've written up the review policy at [1] and filed bug 898089 [2] to >>> enforce/communicate this policy via Mercurial hooks. >>> >>> >> While I supported the review policy change here, I'm fairly

reminder: content processes (e10s) are now used by desktop Firefox

I've mentioned this at the engineering meeting, but thought it worth a note here just to ensure everyone is aware: Bug 870100 enabled use of the background thumbnail service in Firefox desktop, which uses a to do thumbnailing of pages in the background. That means that desktop Firefox now makes

Re: XPIDL & Promises

On 7/30/2013 1:17 PM, Boris Zbarsky wrote: On 7/30/13 11:13 AM, Dave Townsend wrote: The JS promise implementation came out of a desire to use promises in add-ons and devtools amongst others. I believe the C++ implementation came out of the DOM spec. I'm not sure why we need both. OK. Given

Re: Intent to implement: NavigationController

On 2013-07-30 4:14 PM, Gavin Sharp wrote: On Mon, Jul 29, 2013 at 4:58 PM, Robert O'Callahan wrote: On Tue, Jul 30, 2013 at 11:52 AM, Gavin Sharp wrote: Indeed. Somewhat off-topic for this thread, but I think this "let's provide primitives and let other people build higher-level libraries" tr

Re: XPIDL & Promises

On 7/30/2013 1:41 PM, Boris Zbarsky wrote: On 7/30/13 1:37 PM, Gavin Sharp wrote: We'll need to investigate whether the implementations are compatible, though That's fair. DOM Promises are definitely modeled after Promises/A+, but the APIs might not quite match up. :( They don't. With DOM

Re: XPIDL & Promises

On 7/30/13 1:37 PM, Gavin Sharp wrote: We'll need to investigate whether the implementations are compatible, though That's fair. DOM Promises are definitely modeled after Promises/A+, but the APIs might not quite match up. :( -Boris ___ dev-platf

Re: XPIDL & Promises

Whats the main pain point? Whether promises are resolved immediately or from a future event loop iteration? Andreas Gavin Sharp wrote: On Tue, Jul 30, 2013 at 11:17 AM, Boris Zbarsky wrote: On 7/30/13 11:13 AM, Dave Townsend wrote: The JS promise implementation came out of a desire to use

Re: XPIDL & Promises

On Tue, Jul 30, 2013 at 11:17 AM, Boris Zbarsky wrote: > On 7/30/13 11:13 AM, Dave Townsend wrote: >> >> The JS promise implementation came out of a desire to use promises in >> add-ons and devtools amongst others. I believe the C++ implementation came >> out of the DOM spec. I'm not sure why we n

Re: Intent to implement: NavigationController

On Mon, Jul 29, 2013 at 4:58 PM, Robert O'Callahan wrote: > On Tue, Jul 30, 2013 at 11:52 AM, Gavin Sharp wrote: >> Indeed. Somewhat off-topic for this thread, but I think this "let's >> provide primitives and let other people build higher-level libraries" >> trend for Web platform features is pr

Re: XPIDL & Promises

Maybe, but also, generally speaking we shouldn't be using .idl files for b2g any more, at least not writing new ones. We should be implementing things with WebIDL. What's the case where we need/want this here? On 7/30/2013 7:51 AM, Andreas Gal wrote: > > Yeah, I just saw that grepping through the

PSA: MOZ_STATIC_ASSERT removed in C++ code, replaced by C++11 static_assert

I just landed bug 895322, which removes the MOZ_STATIC_ASSERT macro in C++ code, and replaces it with the C++11 static_assert keyword. You should use static_assert in C++ code from now on. MOZ_STATIC_ASSERT still remains supported for C code. If you forget this, the compiler will helpfully remin

Re: XPIDL & Promises

On 7/30/13 11:13 AM, Dave Townsend wrote: The JS promise implementation came out of a desire to use promises in add-ons and devtools amongst others. I believe the C++ implementation came out of the DOM spec. I'm not sure why we need both. OK. Given that there is also a desire to be able to use

Re: XPIDL & Promises

The JS promise implementation came out of a desire to use promises in add-ons and devtools amongst others. I believe the C++ implementation came out of the DOM spec. I'm not sure why we need both. On Tue, Jul 30, 2013 at 7:51 AM, Andreas Gal wrote: > > Yeah, I just saw that grepping through the

Re: Intent to Ship: Web Audio

On Tuesday, July 30, 2013 at 6:54 PM, Ehsan Akhgari wrote: > On 2013-07-30 1:44 PM, Marcos Caceres wrote: > > I have previously indicated our intent to ship to the working group for > Firefox 24, but that slipped. I need to update the working group on the > new plans. > > Shipping Web Audio

Re: Intent to Ship: Web Audio

On 2013-07-30 1:44 PM, Marcos Caceres wrote: On Tuesday, July 30, 2013 at 6:26 PM, Ehsan Akhgari wrote: We have been working on implementing the Web Audio API for quite a while now, and we've had an experimental implementation on Nightly and Aurora for several cycles now. We're getting clos

Re: Intent to Ship: Web Audio

On Tuesday, July 30, 2013 at 6:26 PM, Ehsan Akhgari wrote: > We have been working on implementing the Web Audio API for quite a while > now, and we've had an experimental implementation on Nightly and Aurora for > several cycles now. > > We're getting close to a stage where we feel that we're

Re: Intent to Ship: Web Audio

I forgot to mention that the tracking bug for this is *779297 .* -- Ehsan On Tue, Jul 30, 2013 at 1:26 PM, Ehsan Akhgari wrote: > We have been working on implementing the Web Audio API for quite a while > now, and w

Intent to Ship: Web Audio

We have been working on implementing the Web Audio API for quite a while now, and we've had an experimental implementation on Nightly and Aurora for several cycles now. We're getting close to a stage where we feel that we're ready to ship this API by default. There is still some implementation wo

PSA: mozilla/StandardInteger.h is now dead, use

mozilla/StandardInteger.h was supposed to make it possible to get stdint types on Visual C++ 2005 and 2008. We recently dropped support for those compilers, and today I landed patches on inbound which remove mozilla/StandardInteger.h from the tree, and replace its usages with . Please use that in

Re: XPIDL & Promises

Yeah, I just saw that grepping through the tree. Both completely independent, too. On the upside, this might solve Jan's problem. Andreas Boris Zbarsky wrote: On 7/30/13 7:36 AM, Andreas Gal wrote: For that we would have to implement Promise via IDL. Definitely possible. All you need is a b

Re: XPIDL & Promises

On 7/30/13 7:43 AM, Boris Zbarsky wrote: On 7/30/13 7:20 AM, janjongb...@gmail.com wrote: But is it possible to have a promise as a return type in my .idl file (b2g)? Just list it as nsISupports in the .idl. XPConnect will do the right thing. Ignore the above; I thought you were talking abo

Re: XPIDL & Promises

On 7/30/13 7:20 AM, janjongb...@gmail.com wrote: But is it possible to have a promise as a return type in my .idl file (b2g)? Just list it as nsISupports in the .idl. XPConnect will do the right thing. -Boris ___ dev-platform mailing list dev-platfo

Re: XPIDL & Promises

On 7/30/13 7:36 AM, Andreas Gal wrote: For that we would have to implement Promise via IDL. Definitely possible. All you need is a bit IDL and some JS that implements it. It would be a lot slower than the jsm since it wraps into C++ objects that call into JS, but in most cases that doesn't really

Re: XPIDL & Promises

For that we would have to implement Promise via IDL. Definitely possible. All you need is a bit IDL and some JS that implements it. It would be a lot slower than the jsm since it wraps into C++ objects that call into JS, but in most cases that doesn't really matter. Andreas janjongb...@gmai

XPIDL & Promises

Hi, >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)? Something like Promise blah(); won't just work and I'm a bit lost :-) ___ dev-pla

[LIVE] Enabling mozharness for talos for FF25 projects

Talos mozharness is now live on all FF25 trees. Remember that we will see some ts regressions. More info in: http://armenzg.blogspot.ca/2013/07/enabling-talos-mozharness-for-ff25.html This will ride the trains. cheers, Jason & Armen On 2013-07-29 1:04 PM, Armen Zambrano G. wrote: This will

Re: Rethinking separate Mercurial repositories

On 7/29/13 8:06 PM, Benjamin Smedberg wrote: On 7/29/2013 1:43 PM, Gregory Szorc wrote: I don't particularly care for our model of a single Mercurial repository per logical entity. I think it makes sense for things like twigs and to some extent integration repositories - you can do your work in