Re: Triage for Component Leads

[Kartikaya Gupta]

The wiki says everything from July 1 onwards should be triaged, but
the triage-center tool produces bugzilla links from June 1 onwards
(when you select the "no priority decision" link). Is this
intentional, or just a mix-up?

On Thu, Jun 16, 2016 at 5:17 PM, Emma Humphries  wrote:
> This afternoon I introduced the new triage process we've developed for bugs
> in Firefox-related components.
>
> My presentation is at
> https://docs.google.com/presentation/d/1qlXlDsMnvcpA5ppJVJWIBaBDPEyw5hbjU-Q7wjjrZQM/edit?usp=sharing
>
> The guide to the process is on the Mozilla wiki:
> https://wiki.mozilla.org/Bugmasters/Process/Triage
>
> If you are on this list,
> https://wiki.mozilla.org/Bugmasters/Project/Bug_Handling/Triage_Leads, you
> are on the hook to make decisions on bugs in the component. And I'll be
> following up with you over the next two weeks to see how you are doing, and
> what questions you have about this process.
>
> After I return from London, I'll also put together a short video for Air
> Mozilla introducing the process.
>
> -- Emma
> ___
> 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: Return-value-optimization when return type is RefPtr

[smaug]

On 05/24/2016 08:33 AM, jww...@mozilla.com wrote:

For

RefPtr GetFoo() {
   RefPtr foo;
   // ...
}

should we:

1. return foo and expect RVO to kick in to eliminate additional AddRef/Release
2. return foo.forget()
3. return Move(foo)

Which one is preferred?

ps: I find gcc is able to apply RVO even with "-O0". Not sure if it is also 
true for other compilers.



Can we somehow guarantee that RVO kicks in? It feels quite error prone to rely 
on compiler optimization when dealing with
possibly slow Addref/Release calls.
https://en.wikipedia.org/wiki/Return_value_optimization#Compiler_support hints 
that there are cases when RVO might not happen.


-Olli
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Triage for Component Leads

[Emma Humphries]

This afternoon I introduced the new triage process we've developed for bugs
in Firefox-related components.

My presentation is at
https://docs.google.com/presentation/d/1qlXlDsMnvcpA5ppJVJWIBaBDPEyw5hbjU-Q7wjjrZQM/edit?usp=sharing

The guide to the process is on the Mozilla wiki:
https://wiki.mozilla.org/Bugmasters/Process/Triage

If you are on this list,
https://wiki.mozilla.org/Bugmasters/Project/Bug_Handling/Triage_Leads, you
are on the hook to make decisions on bugs in the component. And I'll be
following up with you over the next two weeks to see how you are doing, and
what questions you have about this process.

After I return from London, I'll also put together a short video for Air
Mozilla introducing the process.

-- Emma
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Return-value-optimization when return type is RefPtr

[Eric Rescorla]

On Thu, Jun 16, 2016 at 2:15 PM, Michael Layzell 
wrote:

> We pass T* as an argument to a function too often for this to e practical.
>

Can you explain why? Is your point here to avoid people having to type
.get() or the mass
conversion from the current code? The former seems like it's a feature
rather than a bug...

-Ekr

The best solution is probably to remove the conversion from RefPtr&& to
> T* which is I believe what froydnj is planning to do.
>
> This requires ref qualifiers for methods, which isn't supported in MSVC
> 2013, but is supported in 2015. See
> https://bugzilla.mozilla.org/show_bug.cgi?id=1280295
>
> On Thu, Jun 16, 2016 at 12:27 PM, Eric Rescorla  wrote:
>
>> Is it worth reconsidering removing implicit conversion from RefPtr to
>> T*?
>>
>> -Ekr
>>
>>
>> On Thu, Jun 16, 2016 at 9:50 AM, Boris Zbarsky  wrote:
>>
>> > On 6/16/16 3:15 AM, jww...@mozilla.com wrote:
>> >
>> >> I think that is the legacy when we don't have move semantics. Returning
>> >> RefPtr won't incur ref-counting overhead and is more expressive and
>> >> functional.
>> >>
>> >
>> > Except for the footgun described in <
>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1280296#c0>, yes?
>> >
>> > -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
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Return-value-optimization when return type is RefPtr

[Michael Layzell]

We pass T* as an argument to a function too often for this to e practical.
The best solution is probably to remove the conversion from RefPtr&& to
T* which is I believe what froydnj is planning to do.

This requires ref qualifiers for methods, which isn't supported in MSVC
2013, but is supported in 2015. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1280295

On Thu, Jun 16, 2016 at 12:27 PM, Eric Rescorla  wrote:

> Is it worth reconsidering removing implicit conversion from RefPtr to
> T*?
>
> -Ekr
>
>
> On Thu, Jun 16, 2016 at 9:50 AM, Boris Zbarsky  wrote:
>
> > On 6/16/16 3:15 AM, jww...@mozilla.com wrote:
> >
> >> I think that is the legacy when we don't have move semantics. Returning
> >> RefPtr won't incur ref-counting overhead and is more expressive and
> >> functional.
> >>
> >
> > Except for the footgun described in <
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1280296#c0>, yes?
> >
> > -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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Nightly Only Containers Feature

[Tanvi Vyas]

Looks like there are some formatting issues with the blogpost link, so 
sending it again: 
https://blog.mozilla.org/tanvi/2016/06/16/contextual-identities-on-the-web/


On 6/16/16 11:42 AM, Tanvi Vyas wrote:
This week we enabled the Containers feature for testing in Nightly. 
Containers is a way for users to have multiple browsing contexts 
within the sameprofile. With these different contexts, 
Containersallows users to login to multiple accounts on the same 
domain simultaneouslyin the same browser window. Containers also 
improves privacy as it enables users to partition their online 
identities and helps prevent tracking across them.


If this capability interests you, please tryoutthe feature and 
provideus withfeedback[1].  We want to ensure that the 
OriginAttributes infrastructure it is built uponin platformis 
sound,and we would like to validate and improve our ideas on the 
Containers concept.  Note this feature is an experimental Nightly only 
feature, thereforeit is not goingto ride the trains.


To learn more about the feature, you can come to my lightning talk 
today at the London All Hands[2] and/or read this blog post[3].


Thank you!

~Tanvi

[1] Take this 2-minute survey or email contain...@mozilla.com.
https://docs.google.com/forms/d/1oQN14TUnqj-MDErp8MKxH_v7YttOASVdER4lwCgbGKY/viewform?c=0&w=1

[2] Platform Lightning Talks
Thursday 4:30 pm to 6:00 pm (Containers will be the 5th talk)
Location: Balmoral 2/Metropole West Wing/
Sched: 
https://mozillalondonallhands2016.sched.org/event/73DN/platform-lightning-talks


[3] 
_https://blog.mozilla.org/tanvi/2016/06/16/contextual-identities-on-the-web/_


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Return-value-optimization when return type is RefPtr

[Eric Rescorla]

Is it worth reconsidering removing implicit conversion from RefPtr to T*?

-Ekr


On Thu, Jun 16, 2016 at 9:50 AM, Boris Zbarsky  wrote:

> On 6/16/16 3:15 AM, jww...@mozilla.com wrote:
>
>> I think that is the legacy when we don't have move semantics. Returning
>> RefPtr won't incur ref-counting overhead and is more expressive and
>> functional.
>>
>
> Except for the footgun described in <
> https://bugzilla.mozilla.org/show_bug.cgi?id=1280296#c0>, yes?
>
> -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

Nightly Only Containers Feature

[Tanvi Vyas]

This week we enabled the Containers feature for testing in Nightly. 
Containers is a way for users to have multiple browsing contexts within 
the sameprofile. With these different contexts, Containersallows users 
to login to multiple accounts on the same domain simultaneouslyin the 
same browser window.  Containers also improves privacy as it enables 
users to partition their online identities and helps prevent tracking 
across them.


If this capability interests you, please tryoutthe feature and provideus 
withfeedback[1]. We want to ensure that the OriginAttributes 
infrastructure it is built uponin platformis sound,and we would like to 
validate and improve our ideas on the Containers concept.  Note this 
feature is an experimental Nightly only feature, thereforeit is not 
goingto ride the trains.


To learn more about the feature, you can come to my lightning talk today 
at the London All Hands[2] and/or read this blog post[3].


Thank you!

~Tanvi

[1] Take this 2-minute survey or email contain...@mozilla.com.
https://docs.google.com/forms/d/1oQN14TUnqj-MDErp8MKxH_v7YttOASVdER4lwCgbGKY/viewform?c=0&w=1

[2] Platform Lightning Talks
Thursday 4:30 pm to 6:00 pm (Containers will be the 5th talk)
Location: Balmoral 2/Metropole West Wing/
Sched: 
https://mozillalondonallhands2016.sched.org/event/73DN/platform-lightning-talks


[3] 
_https://blog.mozilla.org/tanvi/2016/06/16/contextual-identities-on-the-web/_

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Return-value-optimization when return type is RefPtr

[Boris Zbarsky]

On 6/16/16 3:15 AM, jww...@mozilla.com wrote:

I think that is the legacy when we don't have move semantics. Returning 
RefPtr won't incur ref-counting overhead and is more expressive and 
functional.


Except for the footgun described in 
, yes?


-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Return-value-optimization when return type is RefPtr

[Gerald Squelart]

Coincidentally: (?)
https://bugzilla.mozilla.org/show_bug.cgi?id=1280296
"remove already_AddRefed"
:-)


For your original question, I would vote for RVO when possible, and Move() 
otherwise.

It feels like static analysis should be able to detect cases where RVO is 
possible and suggest it if missing; and also detect cases where it's not 
possible and warn about a missing Move().
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform