Re: PSA: Cancel your old Try pushes

Any conclusions out of the discussion here? Try is getting slower as we speak... I would opt to less disruptive way at first, per what Brian Grinstead said. We don't even have to implement interactive prompt first. If that makes people cancel old Try runs more, great, if not, we could consider

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Fri, Apr 22, 2016 at 1:05 AM, Nicholas Nethercote wrote: > The third example I looked at was CycleCollectedJSRuntime. Again > problems, specifically this line in Init(): > > mOwningThread->SetScriptObserver(this); Others have already said what I would have here

Re: Out parameters, References vs. Pointers (was: Proposal: use nsresult& outparams in constructors to represent failure)

Pointers are prefereable for outparams because it makes it clearer what's going on at the callsite. (at least indicating that something non-trivial is happening) On Wed, Apr 20, 2016 at 8:07 PM, Kan-Ru Chen (陳侃如) wrote: > Nicholas Nethercote writes: >

Re: Proposal: use nsresult& outparams in constructors to represent failure

FWIW, I use static Create functions for fallible heap-only objects, and StackFallible::ctor(bool* const out_success/error) for the rarer fallible stack-createable objects. It sounds like this lines up with existing proposals here. Example fallible heap-only:

Re: Intent to ship: Restrict geolocation.watchPosition to secure contexts

On 4/21/16 11:00 AM, Richard Barnes wrote: This is clearly a powerful feature, so it's a natural candidate for restriction. Chromium is restricting all of navigator.geolocation as of 50: https://codereview.chromium.org/1530403002/ Just to be clear, Firefox will still allow

Re: Moving XP to ESR?

On 20/4/16 20:14, Ben Hearsum wrote: This would require a new update channel to support, because it would be a unique line of code that isn't "release" or "esr". It couldn't be implemented as a relbranch either, because we'd need CI for it. You're basically proposing a long lived esr-like

Intent to ship: Restrict geolocation.watchPosition to secure contexts

This is clearly a powerful feature, so it's a natural candidate for restriction. Chromium is restricting all of navigator.geolocation as of 50: https://codereview.chromium.org/1530403002/ Our telemetry shows that only ~0.1% of the usage of watchPosition() is in non-secure contexts.

Re: multiple Rust crates are now supported

Agreed! Thanks to you, Ralph, and everyone (especially the build peers!) who has been providing feedback/reviews and trying to stand up examples integrating various Rust or Servo code into Gecko so that we could find the blockers quickly. For people who would like to follow along without adding

crash stats query tools

Hi all, I wrote some tools a while back intended to make it possible to do complex crash stats queries locally, using downloaded crash stats data. It can do queries using a mongodb-like query language; even based on functions (running a function on each crash to decide whether it should be

Re: Out parameters, References vs. Pointers (was: Proposal: use nsresult& outparams in constructors to represent failure)

More evidence that our coding conventions need an owner... -j On Wed, Apr 20, 2016 at 10:07 PM, Kan-Ru Chen (陳侃如) wrote: > Nicholas Nethercote writes: > > > Hi, > > > > C++ constructors can't be made fallible without using exceptions. As a > result,

Re: Moving XP to ESR?

On 4/20/16 11:53 AM, Armen Zambrano G. wrote: > Would it make more sense to have a relbranch instead of using ESR? Oh lordy, no! It's hard enough diverting engineering work to supporting a single ESR 9 months after the fork. Why would we do two of them? How would a relbranch differ from ESR? >

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 3:24 AM, Nicholas Nethercote wrote: > On Thu, Apr 21, 2016 at 7:38 PM, Nicolas Silva > wrote: > > Fallible construction (even with a way to report failure) is annoying if > > only because the object's destructor has to

Re: multiple Rust crates are now supported

Thanks, Nathan. This is really great to see! -r On Thu, Apr 21, 2016 at 7:57 AM, Nathan Froyd wrote: > Bug 1163224 has landed on inbound, which means that Gecko builds with > --enable-rust now support multiple Rust crates. This change is > intended to make the lives of

Re: Proposal: use nsresult& outparams in constructors to represent failure

Your example is suffering from the fact that PR_CreateThread is taking as parameter an object that is half-initialized, and then continues constructing it. I believe this to be a poor design and that unfortunately leaks into the creating of nsThread. In such a situation I would personally still

multiple Rust crates are now supported

Bug 1163224 has landed on inbound, which means that Gecko builds with --enable-rust now support multiple Rust crates. This change is intended to make the lives of people developing Rust components easier, and it comes with several caveats: 1) There is zero support for interdependencies between

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 8:41 PM, Martin Thomson wrote: > >> - I suspect that in some heap-allocated objects it will be hard to do >> the fallible parts without having an object of the relevant type. I >> don't have specific examples, just a hunch. > > I'm not aware of any way

Re: Moving XP to ESR?

> * Lack of SSE2, though not an XP problem per se, coincides with XP, so we could just require SSE2 if we didn't support XP. We have data about this. Unfortunately we'd also have to kick out some Windows 7 users. For every ten WinXP Firefox users without SSE2 we have a Win7 Firefox user without

Re: Proposal: use nsresult& outparams in constructors to represent failure

I prefer the fallible, if failed return null else return new pattern myself also. With a little RAII, it keeps manual cleanup to a minimum. On Thu, Apr 21, 2016 at 8:24 PM, Nicholas Nethercote wrote: > - It doesn't appear to work with stack-allocated objects? The

Re: Proposal: use nsresult& outparams in constructors to represent failure

FWIW, bug 1265035 was an example that got me thinking about this whole thing, and it was a crash involving a stack-allocated object (WorkerJSRuntime) in which initialization failed. On Thu, Apr 21, 2016 at 8:35 PM, Nicolas Silva wrote: > My experience is that stack

Re: Proposal: use nsresult& outparams in constructors to represent failure

My experience is that stack allocated objects tend to be simpler, shorter-lived and less prone to accumulating invalid state somewhere and crash somewhere else. All in all they haven't been a source of pain the way heap-allocated objects often are when it comes to invalid state creeping up. There

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 7:38 PM, Nicolas Silva wrote: > Fallible construction (even with a way to report failure) is annoying if > only because the object's destructor has to account for the possible > invalid states. I much prefer having a static creation method that will

Re: Proposal: use nsresult& outparams in constructors to represent failure

Fallible construction (even with a way to report failure) is annoying if only because the object's destructor has to account for the possible invalid states. I much prefer having a static creation method that will only instantiate the object in case of success, and mark the constructor protected.

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 7:57 AM, Nicholas Nethercote wrote: > On Thu, Apr 21, 2016 at 3:05 PM, Eric Rescorla wrote: > > The general problem that > > it doesn't alleviate is that failure to check the return value leaves you > > with a reference/pointer to

Re: Proposal: use nsresult& outparams in constructors to represent failure

On 4/20/16 11:43 PM, Gerald Squelart wrote: How about another generic helper, e.g.: template Maybe MakeCheckedMaybe(Args&&... aArgs) { nsresult rv; Maybe m = Some(T(std::forward(aArgs)..., )); if (NS_SUCCEEDED(rv)) { return m; } return Nothing(); } Existing

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thursday, April 21, 2016 at 4:33:40 PM UTC+10, Nicholas Nethercote wrote: > On Thu, Apr 21, 2016 at 4:19 PM, Xidorn Quan wrote: > >> > >> Maybe you're referring to factory methods, like this: > >> > >> static T* T::New(); > >> > >> which would return null on failure. Such

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 4:19 PM, Xidorn Quan wrote: >> >> Maybe you're referring to factory methods, like this: >> >> static T* T::New(); >> >> which would return null on failure. Such methods can be useful, but >> there's two problems. First, they're not applicable to

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 3:57 PM, Nicholas Nethercote wrote: > On Thu, Apr 21, 2016 at 3:05 PM, Eric Rescorla wrote: > > So, if we are going to do something along these lines, I would want it > to be > > a convention that if you use MakeUnique and the like

Re: Update on Webcomponents?

On Thu, Apr 21, 2016 at 5:36 AM, Philipp Kewisch wrote: > I was experimenting with web components and noticed how there are gaps > between what Firefox supports and what Chrome supports. Reading blog > posts and such I am aware that this is because consensus has not been >