[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 be going live tomorrow Tuesday 30th. On 2013-07-23 4:38 PM, Armen Zambrano G. wrote: I need these new changesets to spread across the FF25 trees before going ahead with this: https://hg.mozilla.org/integration/mozilla-inbound/rev/0d4ab37e3f3e https://hg.mozilla.org/integration/mozilla-inbound/rev/496a7582cf9e I'm postponing this until Monday. Sorry for the noise. I want to make sure that it all goes as expected. cheers, Jason Armen On 2013-07-22 2:44 PM, Armen Zambrano G. wrote: Last week we enabled mozharness for talos on the try server and we have resolved all found issues since then. The issues were related to proper integration with tbpl and talos's try support. We will switch talos jobs to be driven by mozharness rather than through buildbot by Wednesday morning in the morning of EDT. I assume that changeset 3d1c2ca7efe8 is already on your local checkout after a week being in the tree but worth raising it up again. There's one thing to do on your part if you want to not have failing *talos* jobs on the try server, make sure that the changeset 3d1c2ca7efe8 is in your local checkout [5][6]. If you have updated your repo from m-i by Friday 12th at 10:19AM PDT you should be good to go. regards, Jason Armen [5] http://hg.mozilla.org/integration/mozilla-inbound/rev/3d1c2ca7efe8 [6] http://hg.mozilla.org/mozilla-central/rev/3d1c2ca7efe8 On 2013-07-16 8:51 AM, Armen Zambrano G. wrote: Hi, We have recently been working hard to separate the buildbot logic that runs our talos jobs on tbpl to its own separate script (using mozharness). [1][2] This has the advantage of permitting anyone (specially the a-team) to adjust how our harnesses run talos inside of our infrastructure without having to set up buildbot (which is what currently runs our talos jobs). This also permits anyone to run the jobs locally in the same manner as Releng's infrastructure. This also allows for further development and flexibility on how we configure the jobs we run. Initially, we will enable it on the try server today to see production-like load. So far, it's been looking great on Cedar. [3] The only gotcha is that there will be a small performance hit for the ts tests that we are willing to take. [4] There's one thing to do on your part if you want to not have failing *talos* jobs on the try server, make sure that the changeset 3d1c2ca7efe8 is in your local checkout [5][6]. If you have updated your repo from m-i by Friday 12th at 10:19AM PDT you should be good to go. Once we get a couple of days worth of load on the try server and see nothing new we will go ahead and enable it for every m-c based repository. If you have any questions/concerns please write a comment on bug 713055. Best regards, Jason Armen Release Engineering [1] https://bugzilla.mozilla.org/show_bug.cgi?id=713055 [2] https://developer.mozilla.org/en-US/docs/Mozharness_FAQ [3] https://tbpl.mozilla.org/?tree=Cedarjobname=talos [4] https://bugzilla.mozilla.org/show_bug.cgi?id=802801#c10 [5] http://hg.mozilla.org/integration/mozilla-inbound/rev/3d1c2ca7efe8 [6] http://hg.mozilla.org/mozilla-central/rev/3d1c2ca7efe8 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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...@gmail.com wrote: 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-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 about Gecko's Promise implementation, not a manual impl in JS. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 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. Wait. Why do we have multiple Promise implementations now? :( -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: mozilla/StandardInteger.h is now dead, use stdint.h
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 stdint.h. Please use that in new code (the compiler will remind you if you forget!) See bug 872127 for more details. Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 work to be finished, and there are a few spec issues to be resolved, but we're relatively confident that we can address all of these issues by the time we release Firefox 25, therefore I would like to announce the intent to ship this API. There is some risk involved from the spec level discussions which we're currently having in that the discussions may not finish in a timely manner. In that case, we will delay shipping this API until we reach a resolution on the W3C Audio Working Group, and I will follow-up to the list. Please let me know if you have any questions. Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Ship: Web Audio
I forgot to mention that the tracking bug for this is *779297https://bugzilla.mozilla.org/show_bug.cgi?id=779297 .* -- Ehsan http://ehsanakhgari.org/ On Tue, Jul 30, 2013 at 1:26 PM, Ehsan Akhgari ehsan.akhg...@gmail.comwrote: 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 work to be finished, and there are a few spec issues to be resolved, but we're relatively confident that we can address all of these issues by the time we release Firefox 25, therefore I would like to announce the intent to ship this API. There is some risk involved from the spec level discussions which we're currently having in that the discussions may not finish in a timely manner. In that case, we will delay shipping this API until we reach a resolution on the W3C Audio Working Group, and I will follow-up to the list. Please let me know if you have any questions. Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 ready to ship this API by default. What led you to feel comfortable with shipping? Is it based on interoperability with some significant content and another UA? Is there a test suite? There is still some implementation work to be finished, and there are a few spec issues to be resolved, but we're relatively confident that we can address all of these issues by the time we release Firefox 25, therefore I would like to announce the intent to ship this API. Ship means no longer behind a flag, right? There is some risk involved from the spec level discussions which we're currently having in that the discussions may not finish in a timely manner. In that case, we will delay shipping this API until we reach a resolution on the W3C Audio Working Group, and I will follow-up to the list. Please let me know if you have any questions. I'm admittedly a little bit concerned - if we ship, it's a strong signals to the W3C Web Audio WG we are happy with the API that is spec'ed as is (that may be true - it might be the best that the group can do and it might very well be a spec from which interoperable implementations can be created). My personal opinion about the spec is that it could be improved (lots of stuff seemed underspecified, etc. when I tried to read it a few months ago - but maybe it's better now) - if it mostly works across at least 2 browsers, then I guess it's time to ship. -- Marcos Caceres ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 close to a stage where we feel that we're ready to ship this API by default. What led you to feel comfortable with shipping? Is it based on interoperability with some significant content and another UA? Is there a test suite? We will probably be the first and only spec conformant implementation when we ship (the WebKit and Blink implementation does not conform to more recent spec changes.) The reason that I feel comfortable shipping this is that we're getting close to the spec being considered stable, and I believe that we can just land any future fixes based on further spec changes after we ship. There is still some implementation work to be finished, and there are a few spec issues to be resolved, but we're relatively confident that we can address all of these issues by the time we release Firefox 25, therefore I would like to announce the intent to ship this API. Ship means no longer behind a flag, right? Yes, that's correct. (Technically, it means flipping the default value of the flag to true. We will still preserve the flag as a disaster recovery tool.) There is some risk involved from the spec level discussions which we're currently having in that the discussions may not finish in a timely manner. In that case, we will delay shipping this API until we reach a resolution on the W3C Audio Working Group, and I will follow-up to the list. Please let me know if you have any questions. I'm admittedly a little bit concerned - if we ship, it's a strong signals to the W3C Web Audio WG we are happy with the API that is spec'ed as is (that may be true - it might be the best that the group can do and it might very well be a spec from which interoperable implementations can be created). My personal opinion about the spec is that it could be improved (lots of stuff seemed underspecified, etc. when I tried to read it a few months ago - but maybe it's better now) - if it mostly works across at least 2 browsers, then I guess it's time to ship. 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 doesn't mean that we're necessarily happy with all parts of the spec, but we're making trade-offs between having a good API that everybody agrees on, and shipping code which works with some of the existing content. We have heavily discussed these issues in the working group. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 the DOM Promises in b2g (see bug 897913), how do people feel about enabling the Promise API in at least chrome globals (and via Xrays), and setting up Promise in things like JS component globals as well? This shouldn't be too difficult to do... Then anyone who wants to use Promises in Chrome code can use the DOM ones. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 remind you! :-) Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 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 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. Wait. Why do we have multiple Promise implementations now? :( -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- jst ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: NavigationController
On Mon, Jul 29, 2013 at 4:58 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Tue, Jul 30, 2013 at 11:52 AM, Gavin Sharp ga...@gavinsharp.com 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 pretty dangerous. On the other hand, I think that the approach of spec and build 100 narrowly-focused features to solve 100 similar-but-different use-cases, as followed by (e.g.) CSS to date, is also dangerous. Guess what the right feature is, build it, and ship it, because you can't prototype solutions on top of the existing platform is dangerous too. It's certainly a balancing act :) I think we've been swinging a bit too far towards letting the perfect be the enemy of the good, is all. Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: XPIDL Promises
On Tue, Jul 30, 2013 at 11:17 AM, Boris Zbarsky bzbar...@mit.edu 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 that there is also a desire to be able to use the DOM Promises in b2g (see bug 897913), how do people feel about enabling the Promise API in at least chrome globals (and via Xrays), and setting up Promise in things like JS component globals as well? This shouldn't be too difficult to do... Then anyone who wants to use Promises in Chrome code can use the DOM ones. Sounds great. We'll need to investigate whether the implementations are compatible, though - we've been going through various existing JS consumers switching them to a different promise implementation (Promise.jsm, https://bugzilla.mozilla.org/show_bug.cgi?id=856878 tracks several instances) and have been running into issues with different behavior related to promise resolution. There is a significant amount of existing chrome code using one of the two existing JS implementations (Promise.jsm and core/promise.js from the Add-on SDK), and porting them to DOM promises will take some effort. Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 Zbarskybzbar...@mit.edu 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 that there is also a desire to be able to use the DOM Promises in b2g (see bug 897913), how do people feel about enabling the Promise API in at least chrome globals (and via Xrays), and setting up Promise in things like JS component globals as well? This shouldn't be too difficult to do... Then anyone who wants to use Promises in Chrome code can use the DOM ones. Sounds great. We'll need to investigate whether the implementations are compatible, though - we've been going through various existing JS consumers switching them to a different promise implementation (Promise.jsm, https://bugzilla.mozilla.org/show_bug.cgi?id=856878 tracks several instances) and have been running into issues with different behavior related to promise resolution. There is a significant amount of existing chrome code using one of the two existing JS implementations (Promise.jsm and core/promise.js from the Add-on SDK), and porting them to DOM promises will take some effort. Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 Promises you might do:
function doAsync(){
return new Promise(function(resolver) {
somethingRemote(function(err, result) {
if (err) {
resolver.reject(err);
} else {
resolver.resolve(result);
}
});
});
}
With the Promise implementation used in Addon SDK and devtools (and
perhaps elsewhere), you would do:
function doAsync(){
let deferred = Promise.defer();
somethingRemote(function(err, result){
if (err) {
deferred.reject(err);
} else {
deferred.resolve(result);
}
});
return deferred.promise;
}
It's not a transformation that can be done mechanically really. On the
other hand, it's pretty trivial to wrap the DOM Promise API in an API
that would be compatible with the old Promise implementation.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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 rob...@ocallahan.org wrote: On Tue, Jul 30, 2013 at 11:52 AM, Gavin Sharp ga...@gavinsharp.com 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 pretty dangerous. On the other hand, I think that the approach of spec and build 100 narrowly-focused features to solve 100 similar-but-different use-cases, as followed by (e.g.) CSS to date, is also dangerous. Guess what the right feature is, build it, and ship it, because you can't prototype solutions on top of the existing platform is dangerous too. It's certainly a balancing act :) I think we've been swinging a bit too far towards letting the perfect be the enemy of the good, is all. Do you have specific concerns about NavigationController? If yes, I'd like to know them! Thanks! Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 that there is also a desire to be able to use the DOM
Promises in b2g (see bug 897913), how do people feel about enabling
the Promise API in at least chrome globals (and via Xrays), and
setting up Promise in things like JS component globals as well? This
shouldn't be too difficult to do... Then anyone who wants to use
Promises in Chrome code can use the DOM ones.
For what it's worth, I've pondered what it would take to give a
C++-ish API to promises. It turns out to not be extremely difficult,
except for the fact that there are a bajillion ways to represent
functions in C++, so the approach really requires std::function to work
properly, and even then, template argument deduction fails (this could
probably be remedied with more function overloading to get what you need
in common cases, or people can suck it up and manually specify the
return type for Then). An example implementation, tested with both
libstdc++ 4.8 [I'm told std::function exists as far back as 4.5, and it
looks like stlport even has it] and MSVC10, is as follows:
#include functional
#include memory
#include vector
/// Returns a promise to return something of type T
template typename T
class Promise {
public:
Promise() : mResolvers(new std::vectorstd::functionvoid(T)()) {}
void Resolve(T aValue) {
for (auto it = mResolvers-begin(); it != mResolvers-end(); ++it) {
(*it)(aValue);
}
}
template typename U
PromiseU Then(const std::functionU(T) resolve) {
ReinvokerU x(resolve);
mResolvers-push_back(x);
return *x.getPromise();
}
template typename U class Reinvoker {
std::shared_ptrPromiseU mResult;
std::functionU(T) mCallee;
public:
Reinvoker(const std::functionU(T) callee) :
mResult(new PromiseU()),
mCallee(callee) {}
std::shared_ptrPromiseU getPromise() { return mResult; }
void operator()(T x) { mResult-Resolve(mCallee(x)); }
};
private:
std::shared_ptrstd::vectorstd::functionvoid(T) mResolvers;
};
Given that this kind of thing works, I wonder if it would make sense to
use this sort of thing in C++ as well...
--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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 browser remote=true to do thumbnailing of pages in the background. That means that desktop Firefox now makes use of E10S content processes. They have a short life time (one page load) and are generally triggered by opening about:newtab when thumbnails are missing or out of date (2 days old). This has exposed some e10s crashes that previously weren't exposed on desktop. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=899758 to track them - please hang any other such crashes off that bug. If you're working in a component that has e10s-related crashes, please fix them :) (Bug 891218 is also planning to make use of content processes for some Social-related functionality. Those remote processes will be longer-lived, typically having the same lifetime as the parent process.) Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: requiring build peer review for Makefile.in changes
On Fri, Jul 26, 2013 at 9:36 PM, Brad Lassey blas...@mozilla.com 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 strongly opposed to the idea of the commit hook enforcing it. I've commented on the bug. + 1 I also think a commit hook is a bit of overkill I also agree that a commit hook seems like overkill. I have found the build system team to be very responsive and helpful regarding my more involved build system change review requests, so in general I agree with the idea of the proposed policy given the current state of things, though I think it is worded more strictly than necessary. For example, it is OK to make something build conditionally based on a flag when previously it was always built. Similarly, if I'm just adding a new subdirectory of code or tests or whatever to an existing module, or re-arranging the files across directories in a module, it is hardly worth anybody's time to get a build system peer to review it; if even that is so prone to being problematic, then that is a bug in the build system that should be corrected. I think there is something more important than publishing a policy that you could do: publish the guidelines for modifying the build system. I.e. document the things that you'd say in a code review so that if/when I ask you for a review, we're not rehashing stuff you have told 1,000 people 1,000 times. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 m...@glandium.org 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 semantics instead of copy semantics, we can't use std::unique_ptr. I saw bug 896100 [1] wants to add mozilla::Move and mozilla::Forward. Obviously, that is a clear improvement that we can build on. 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:: namespace normally, but that's exactly what STLPort is doing. And, more to the point, shouldn't we just add std::unique_ptr to STLPort for Android so we can use std::unique_ptr everywhere? And/or just backport the libstdc++ version to GCC 4.4. Isn't it all just templates? Cheers, Brian [1] https://bugzilla.mozilla.org/show_bug.cgi?id=896100 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 browser remote=true in a limited fashion with this. Tom On Tue, Jul 30, 2013 at 7:10 PM, Gavin Sharp ga...@gavinsharp.com wrote: 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 browser remote=true to do thumbnailing of pages in the background. That means that desktop Firefox now makes use of E10S content processes. They have a short life time (one page load) and are generally triggered by opening about:newtab when thumbnails are missing or out of date (2 days old). This has exposed some e10s crashes that previously weren't exposed on desktop. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=899758 to track them - please hang any other such crashes off that bug. If you're working in a component that has e10s-related crashes, please fix them :) (Bug 891218 is also planning to make use of content processes for some Social-related functionality. Those remote processes will be longer-lived, typically having the same lifetime as the parent process.) Gavin ___ firefox-dev mailing list firefox-...@mozilla.org https://mail.mozilla.org/listinfo/firefox-dev ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 t...@schuster.me 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 browser remote=true in a limited fashion with this. Tom On Tue, Jul 30, 2013 at 7:10 PM, Gavin Sharp ga...@gavinsharp.com wrote: 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 browser remote=true to do thumbnailing of pages in the background. That means that desktop Firefox now makes use of E10S content processes. They have a short life time (one page load) and are generally triggered by opening about:newtab when thumbnails are missing or out of date (2 days old). This has exposed some e10s crashes that previously weren't exposed on desktop. I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=899758to track them - please hang any other such crashes off that bug. If you're working in a component that has e10s-related crashes, please fix them :) (Bug 891218 is also planning to make use of content processes for some Social-related functionality. Those remote processes will be longer-lived, typically having the same lifetime as the parent process.) Gavin ___ firefox-dev mailing list firefox-...@mozilla.org https://mail.mozilla.org/listinfo/firefox-dev ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: reminder: content processes (e10s) are now used by desktop Firefox
On Tue, Jul 30, 2013 at 5:05 PM, Tom Schuster t...@schuster.me 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 browser remote=true in a limited fashion with this. Tom Most of the content-exposed DOM APIs have to work out of process today for B2G, so I'm not sure why you'd expect them to crash. There are probably some fun exceptions like the ancient window.crypto APIs though. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 br...@briansmith.org wrote: On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey m...@glandium.org 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 semantics instead of copy semantics, we can't use std::unique_ptr. I saw bug 896100 [1] wants to add mozilla::Move and mozilla::Forward. Obviously, that is a clear improvement that we can build on. Agreed. 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:: namespace normally, but that's exactly what STLPort is doing. We've avoided doing this so far in MFBT for everything in the language or the standard library that we had to reimplement ourselves. I'm not aware of any practical problems in putting things in the std namespace (besides watching out for name clashes, which most standard library implementations avoid by either using nested namespaces for their implementation helpers, or symbols with underscore at the beginning of their name which are supposed to be reserved for implementations -- but real code in the while violates that all the time.) But it still feels a bit unclean to put things into namespace std. Is there a good reason why we should do that in this case? (Also remember that STLport is an STL implementation, so it is entirely ok for them to put things into namespace std!) And, more to the point, shouldn't we just add std::unique_ptr to STLPort for Android so we can use std::unique_ptr everywhere? And/or just backport the libstdc++ version to GCC 4.4. Isn't it all just templates? I believe that std::unique_ptr can be implemented in C++ without any compiler magics, and this sounds like a good idea (but I still think we should call ours mozilla::UniquePtr.) Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 br...@briansmith.org wrote: On Fri, Jul 19, 2013 at 4:46 AM, Mike Hommey m...@glandium.org 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 semantics instead of copy semantics, we can't use std::unique_ptr. I saw bug 896100 [1] wants to add mozilla::Move and mozilla::Forward. Obviously, that is a clear improvement that we can build on. Agreed. 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:: namespace normally, but that's exactly what STLPort is doing. We've avoided doing this so far in MFBT for everything in the language or the standard library that we had to reimplement ourselves. I'm not aware of any practical problems in putting things in the std namespace (besides watching out for name clashes, which most standard library implementations avoid by either using nested namespaces for their implementation helpers, or symbols with underscore at the beginning of their name which are supposed to be reserved for implementations -- but real code in the while violates that all the time.) But it still feels a bit unclean to put things into namespace std. Is there a good reason why we should do that in this case? (Also remember that STLport is an STL implementation, so it is entirely ok for them to put things into namespace std!) Note that if STLport is the only thing preventing us from using some C++11 std:: features, we can implement them and contribute them upstream. That being said, it does look like the STLport git has unique_ptr, forward and move. It's not part of any release, though, and I'm not sure how good the current trunk is. The version we're currently using is 5.2.1 + some Android patches (pristine from the android NDK) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 ehsan.akhg...@gmail.comwrote: On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith br...@briansmith.orgwrote: 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:: namespace normally, but that's exactly what STLPort is doing. We've avoided doing this so far in MFBT for everything in the language or the standard library that we had to reimplement ourselves. I'm not aware of any practical problems in putting things in the std namespace (besides watching out for name clashes, which most standard library implementations avoid by either using nested namespaces for their implementation helpers, or symbols with underscore at the beginning of their name which are supposed to be reserved for implementations -- but real code in the while violates that all the time.) But it still feels a bit unclean to put things into namespace std. Is there a good reason why we should do that in this case? Yes: Then we can use std::unique_ptr in parts of Gecko that are intended to be buildable without MFBT (see below). (Also remember that STLport is an STL implementation, so it is entirely ok for them to put things into namespace std!) To be clear, I am not proposing that we add std::move/forward/unique_ptr to MFBT. I am suggesting that we add them to STLPort. We could even eventually upstream them. EDIT: I just saw Mike's post that STLPort upstream already has unique_ptr/move/forward. Perhaps we can backport them into our STLPort tree. FWIW, we have created a new certificate verification library written in C++. One of my goals is to eventually make it so that it can be embedded in server-side software to support things like OCSP stapling, short-lived certificates, and auto-fixing of certificate chains in servers, which are things that make SSL faster and easier to deploy. Basically, the idea is that the server can (pre-)build/verify their certificate chain exactly as Firefox would. There are also some security researchers interested in using a real browser's certificate processing logic in studies they are doing. This kind of research directly benefits my work on Gecko and I'm intending to share this library with them so they can use it in their research. For this sub-project, I've been trying to avoid any Gecko (including MFBT) dependencies and I will be cutting down (removing?) the NSPR and NSS dependencies over time. In order to avoid the MFBT dependency, I created my own ScopedPtr class and cviecco added a hack for GCC 4.4's nullptr. We also have been doing the typical hacky/dangerous stuff to deal with a world without std::move()/forward() and without cstdint. Now we can use cstdint (or at least stdint.h?), and I'm eager to fix these last mile issues. Besides that, in general I'd like to continue making Gecko's code less foreign to C++ coders. In particular, I'd like to get rid of nsAutoPtrT and mozilla::ScopedPtrT completely. Cheers, Brian ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 ehsan.akhg...@gmail.comwrote: On Tue, Jul 30, 2013 at 7:40 PM, Brian Smith br...@briansmith.orgwrote: 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:: namespace normally, but that's exactly what STLPort is doing. We've avoided doing this so far in MFBT for everything in the language or the standard library that we had to reimplement ourselves. I'm not aware of any practical problems in putting things in the std namespace (besides watching out for name clashes, which most standard library implementations avoid by either using nested namespaces for their implementation helpers, or symbols with underscore at the beginning of their name which are supposed to be reserved for implementations -- but real code in the while violates that all the time.) But it still feels a bit unclean to put things into namespace std. Is there a good reason why we should do that in this case? 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 are relatively easy to select based on catching macro versions, the C++ standard library is not, since compiler versions don't necessarily correlate with standard library versions. We basically support 4 standard libraries (MSVC, libstdc++, stlport, and libc++); under the right conditions, clang could be using any of those four versions. This means it's hard to tell when #include'ing a standard header will give us the feature or not. The C++ committee is actively working on a consensus solution to this issue, but it would not be rolled out to production compilers until 2014 at the earliest. For this sub-project, I've been trying to avoid any Gecko (including MFBT) dependencies and I will be cutting down (removing?) the NSPR and NSS dependencies over time. In order to avoid the MFBT dependency, I created my own ScopedPtr class and cviecco added a hack for GCC 4.4's nullptr. We also have been doing the typical hacky/dangerous stuff to deal with a world without std::move()/forward() and without cstdint. Now we can use cstdint (or at least stdint.h?), and I'm eager to fix these last mile issues. One of the goals of MFBT is to bridge over the varying support of C++11/C++14 in current compilers, although it also includes useful data structures that are not necessary for C++ compatibility. Since we have an increasing number of semi-autonomous C++ projects in mozilla-central, it makes sense that we should have a smallish (header-only, if possible?) compatibility bridge library, but if that is not MFBT, then I don't know what it is or should be. As it stands, we have a fair amount of duplication right now. Besides that, in general I'd like to continue making Gecko's code less foreign to C++ coders. In particular, I'd like to get rid of nsAutoPtrT and mozilla::ScopedPtrT completely. I'm actually planning on discussing this in more detail in a newsgroup post I'm working on right now. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
