Re: PSA: Cancel your old Try pushes

[Tim Guan-tin Chien]

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 other
workflow-breaking solutions.

I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1266602 for this.


On Tue, Apr 19, 2016 at 2:54 AM, William Lachance 
wrote:

> On 2016-04-18 2:46 PM, William Lachance wrote:
>
>>
>> Treeherder did trigger a rather large memory leak which got fixed in the
>> browser a while back (Dec 2015), so please consider revisiting it if you
>> gave up around then:
>> ...
>> If anyone feels like profiling and submitting patches, we'd welcome the
>> help. :) Getting a UI-only development environment going is trivial:
>> http://treeherder.readthedocs.org/ui/installation.html#installation
>>
>
> Just realized that this last comment might make it seem like I'm passing
> the buck, which wasn't my intention. :) I do have a lot of other things to
> do, but if you continue to have problems using treeherder due to memory
> leaks or whatever feel free to file a bug against treeherder and needinfo
> me; I promise to give it my attention.
>
> Will
>
> ___
> 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: Proposal: use nsresult& outparams in constructors to represent failure

[Martin Thomson]

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 generally, but this
example is a good one to show.  Note that this happens very early in a
fairly complex initialization.  In general, doing this sort of thing
means that you have released a pointer to an incompletely initialized
object.  That means that whatever partial initialization might happen,
all methods on the class need to handle the state the object might be
in.

It might be that this call could be deferred until after the fallible
stuff happens, but I don't understand this code well-enough to know
for certain.  I certainly hope that the success of the Initialize
function doesn't depend on receiving upcalls during the process.

(As an aside, when I worked in Java, we had static analysis tools that
prevented us from passing `this` to others during constructors.  It's
a nice rule to have.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Jeff Gilbert]

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:
>
>> Hi,
>>
>> C++ constructors can't be made fallible without using exceptions. As a 
>> result,
>> for many classes we have a constructor and a fallible Init() method which 
>> must
>> be called immediately after construction.
>>
>> Except... there is one way to make constructors fallible: use an |nsresult&
>> aRv| outparam to communicate possible failure. I propose that we start doing
>> this.
>
> Current coding style guidelines suggest that out parameters should use
> pointers instead of references. The suggested |nsresult&| will be
> consistent with |ErrorResult&| usage from DOM but against many other out
> parameters, especially XPCOM code.
>
> Should we special case that nsresult and ErrorResult as output
> parameters should always use references, or make it also the default
> style for out parameters?
>
> I think this topic has been discussed before didn't reach a
> consensus. Based the recent effort to make the code using somewhat
> consistent style, should we expend on this on the wiki?
>
>Kanru
> ___
> 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: Proposal: use nsresult& outparams in constructors to represent failure

[Jeff Gilbert]

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:
https://dxr.mozilla.org/mozilla-central/rev/4feb4dd910a5a2d3061dbdd376a80975206819c6/gfx/gl/GLScreenBuffer.cpp#46
https://dxr.mozilla.org/mozilla-central/rev/4feb4dd910a5a2d3061dbdd376a80975206819c6/gfx/gl/SharedSurfaceEGL.cpp#19

Example fallible stack-createable:
https://dxr.mozilla.org/mozilla-central/rev/4feb4dd910a5a2d3061dbdd376a80975206819c6/dom/canvas/WebGLContextDraw.cpp#254
(Definition is at the top of the file)

Generally my preference for static Create functions is that they don't
allocate the actual class until they are infallible, and thus they are
never in partially-valid states. The ctor is almost always trivial, so
as to keep all the logic centralized in the Create function.

Static Create funcs with thin ctors also allow you to use const to a
greater extent, which can be really nice. (many getters can become
direct access to public const members)


Shoehorning is not my favorite. I'd much rather get the minor
refactoring done to modernize the cruft, rather than limp it along.

On Thu, Apr 21, 2016 at 8:36 AM, Nick Fitzgerald
 wrote:
> 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 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. Something like:
>> >
>> > static
>> > already_AddRefed Foo::Create(SomeParams...) {
>> > // logic that may fail...
>> > if (failed) {
>> >  return nullptr;
>> > }
>> > return MakeAndAddRef(stuffThatDidNotFail);
>> > }
>>
>> So instead of doing the infallible part in the constructor and the
>> fallible part in the Init() function, you're suggesting doing the
>> fallible part first and only calling the constructor once it succeeds?
>> Interesting. I can see it would work nicely for some heap-allocated
>> objects. But I see two possible problems:
>>
>> - It doesn't appear to work with stack-allocated objects?
>>
>
> I think `mozilla::Maybe` works well, as mentioned elsewhere in the
> thread. Here is an example of a non-boxed class whose ctor is infallible
> and has a factory method returning a `Maybe` where
> `None` indicates failure:
> https://dxr.mozilla.org/mozilla-central/rev/4feb4dd910a5a2d3061dbdd376a80975206819c6/js/public/UbiNodeDominatorTree.h#207-274
>
> In general I agree with Nicolas: use patterns that make half-constructed
> things impossible and avoid the whole mess.
> ___
> 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: Intent to ship: Restrict geolocation.watchPosition to secure contexts

[Chris Peterson]

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 getCurrentPosition() in 
non-secure contexts?



Our telemetry shows that only ~0.1% of the usage of watchPosition() is in
non-secure contexts.

http://mzl.la/1VEBbZq

That's low enough that we should go ahead and turn it off.


Curiously, getCurrentPosition() is called in non-secure contexts 77% of 
the time, compared to watchPosition()'s 0.12%.


I would have assumed that getCurrentPosition() is used much more often 
than watchPosition(), as most map sites only need a one-shot location. 
However, telemetry shows getCurrentPosition() has sample count 10M with 
metric count ~1M compared to watchPosition() has sample count 39M and 
metric count 488K. Why the disparity? Why does watchPosition() have 4x 
sample count but only half the metric count? I wondered whether 
watchPosition() was incorrectly recording telemetry on every watch 
callback, but the code looks like it is doing the right thing.

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

Re: Moving XP to ESR?

[Jonathan Kew]

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 branch that we
only ship to XP users.

I suspect that backporting to this would get very difficult very
quickly. We'd be better off moving XP to ESR IMO.



I think you're right about that.

What we should keep in mind, though, is that if we decide to move XP 
users to ESR now, we are in effect making the decision to end support 
for them altogether in a year (when the ESR we've moved them to reaches 
EOL). At that point, the next ESR will be based on a mozilla-central 
that has long since abandoned XP, and there's no chance that we'll 
somehow magically backport it; nor, I think, will there be any appetite 
for extending the life of ESR45 beyond its normal term.


So the question we need to ask ourselves, before making a decision to 
move XP users to ESR, is whether we're prepared to commit ourselves 
_now_ to an EOL date roughly a year away, regardless of how XP usage 
develops over the coming year.


My hunch is that XP usage will decline pretty slowly, and I'm not very 
comfortable with making decisions now that imply we'll be abandoning 
those users in a year.


JK

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

Intent to ship: Restrict geolocation.watchPosition to secure contexts

[Richard Barnes]

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.

http://mzl.la/1VEBbZq

That's low enough that we should go ahead and turn it off.

I have filed Bug 1266494 to track this issue.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: multiple Rust crates are now supported

[Lars Bergstrom]

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 themselves to
all of the bugs, we try to keep https://wiki.mozilla.org/Oxidation up
to date with the current status of this integration work.


On Thu, Apr 21, 2016 at 10:38 AM, Ralph Giles  wrote:
> 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 people developing Rust components
>> easier, and it comes with several caveats:
>>
>> 1) There is zero support for interdependencies between crates, so you
>> have to structure your crate as one big crate that includes any
>> dependencies, rather than several separate crates, as is the norm.
>> This is clearly suboptimal, and it will be fixed.  I think it's an
>> open question exactly how we're going to integrate multiple crates and
>> external projects anyway, so feel free to experiment!
>>
>> 2) We do not have Rust support on all of our Tier 1 platforms (Android
>> is still being worked on), so actually depending on Rust code
>> everywhere is still not possible.
>>
>> 3) Due to bug 1178897, Rust code uses a completely different memory
>> allocator than the rest of Gecko.  We therefore don't have any
>> visibility into Rust's memory allocations through things like
>> about:memory, using Rust code worsens fragmentation issues, and there
>> are also edge cases with allocating in C++ and freeing in Rust (or
>> vice versa).  This is obviously something we're going to fix, ideally
>> soon.
>>
>> We --enable-rust on all of our Tier 1 desktop platforms, but given 2)
>> and 3) above, it seems best to limit the amount of Rust code we
>> actually ship.  So if you want to land Rust components in-tree right
>> now, I'd recommend gating your component behind an --enable-shiny
>> configure option.  Ideally 2) and 3) will be fixed in short order, 1)
>> will be ironed out, and then the real fun can begin!
>>
>> Thanks,
>> -Nathan
>> ___
>> 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

crash stats query tools

[vladimir]

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 included or not).  You 
can use these queries/buckets to create custom top crash lists, or otherwise 
pull out data from crash stats.

They're node.js tools; you can find the repository and some instructions here: 
https://github.com/vvuk/crystalball  You'll need an API key from crash stats, 
and be aware that the initial data download is expensive on the server; you can 
copy the cache files to multiple machines instead of re-downloading (they're 
static; all the data for a given day is downloaded).

Let me know if anyone finds this useful, or if there are features you'd like to 
see added (pull requests accepted as well).

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

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

[Jason Orendorff]

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,
> > for many classes we have a constructor and a fallible Init() method
> which must
> > be called immediately after construction.
> >
> > Except... there is one way to make constructors fallible: use an
> |nsresult&
> > aRv| outparam to communicate possible failure. I propose that we start
> doing
> > this.
>
> Current coding style guidelines suggest that out parameters should use
> pointers instead of references. The suggested |nsresult&| will be
> consistent with |ErrorResult&| usage from DOM but against many other out
> parameters, especially XPCOM code.
>
> Should we special case that nsresult and ErrorResult as output
> parameters should always use references, or make it also the default
> style for out parameters?
>
> I think this topic has been discussed before didn't reach a
> consensus. Based the recent effort to make the code using somewhat
> consistent style, should we expend on this on the wiki?
>
>Kanru
> ___
> 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: Moving XP to ESR?

[Daniel Veditz]

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?

> IIRC ESRs are stable for a period but when we uplift we uplift
> everything new.
> For this XP relbranch we would only take security patches.

That's what we do with an ESR: security and stability patches only. In
practice not many stability patches once it's in decent shape after the
first couple releases--only if one of the security patches breaks
something. We don't uplift things to ESR, ESRs reach their end-of-life
and then people migrate to the next ESR.

> It would serve the purpose of keeping our users secure where they're but
> saving some energy in making new features also XP compatible.
> 
> Setting an N months EOL expectation (plus another criteria[s]) might be
> wise rather than leaving it open ended.

Putting XP people on an existing ESR does both those things. It's the
second that's problematic. When the ESR we've diverted the XP folks to
dies, what then? If we still have a significant chunk of XP users they
will have nowhere to go. We could try to extend the life of that ESR,
but that could result in more work back-porting fixes and
building/testing/shipping extra releases than simply working around XP
issues until ESR 52 next year.

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

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

[Nick Fitzgerald]

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 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. Something like:
> >
> > static
> > already_AddRefed Foo::Create(SomeParams...) {
> > // logic that may fail...
> > if (failed) {
> >  return nullptr;
> > }
> > return MakeAndAddRef(stuffThatDidNotFail);
> > }
>
> So instead of doing the infallible part in the constructor and the
> fallible part in the Init() function, you're suggesting doing the
> fallible part first and only calling the constructor once it succeeds?
> Interesting. I can see it would work nicely for some heap-allocated
> objects. But I see two possible problems:
>
> - It doesn't appear to work with stack-allocated objects?
>

​I think `mozilla::Maybe` works well, as mentioned elsewhere in the
thread. Here is an example of a non-boxed class whose ctor is infallible
and has a factory method returning a `Maybe` where​
​ `None` indicates failure: ​
https://dxr.mozilla.org/mozilla-central/rev/4feb4dd910a5a2d3061dbdd376a80975206819c6/js/public/UbiNodeDominatorTree.h#207-274

​In general I agree with Nicolas: use patterns that make half-constructed
things impossible and avoid the whole mess.​
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: multiple Rust crates are now supported

[Ralph Giles]

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 people developing Rust components
> easier, and it comes with several caveats:
>
> 1) There is zero support for interdependencies between crates, so you
> have to structure your crate as one big crate that includes any
> dependencies, rather than several separate crates, as is the norm.
> This is clearly suboptimal, and it will be fixed.  I think it's an
> open question exactly how we're going to integrate multiple crates and
> external projects anyway, so feel free to experiment!
>
> 2) We do not have Rust support on all of our Tier 1 platforms (Android
> is still being worked on), so actually depending on Rust code
> everywhere is still not possible.
>
> 3) Due to bug 1178897, Rust code uses a completely different memory
> allocator than the rest of Gecko.  We therefore don't have any
> visibility into Rust's memory allocations through things like
> about:memory, using Rust code worsens fragmentation issues, and there
> are also edge cases with allocating in C++ and freeing in Rust (or
> vice versa).  This is obviously something we're going to fix, ideally
> soon.
>
> We --enable-rust on all of our Tier 1 desktop platforms, but given 2)
> and 3) above, it seems best to limit the amount of Rust code we
> actually ship.  So if you want to land Rust components in-tree right
> now, I'd recommend gating your component behind an --enable-shiny
> configure option.  Ideally 2) and 3) will be fixed in short order, 1)
> will be ironed out, and then the real fun can begin!
>
> Thanks,
> -Nathan
> ___
> 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: Proposal: use nsresult& outparams in constructors to represent failure

[Nicolas Silva]

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 use a static Create method
which would go something like:

static
already_addRefed Create(...)
{
  nsRefPtr thread = new nsThread(...);
  if (!thread->Init()) {
// the destructor still has to account for failed init but oh
well...
return nullptr;
  }
  // at least no external code will get access to a nsThread that is not
  fully initialized
  return thread.forget();
}

with the constructor and Init() method protected.

It's not as good as not having to run the destructor on a partially
invalid object, but it is way less foot-gun prone for external code,
since they won't see a half-initialized nsThread and maybe forget to
call IsValid(), Init() or whatnot.

We had a lot of code in gfx that was using the constructor then Init() 
and constructor then check patterns, and we ran into bugs related to
using invalid objects. Eventually we converted a lot of that code to the
static Create() style and I am very happy about how simpler and safer
things got as a result.

In my opinion, making it impossible by construction to get a pointer to
a half-initialized or partially invalid object is the important part. If
you can avoid instantiating the object all together in case of failure
it's perfect, if you have to do the instantiation because poor code
forces that on you, it's not perfect, but I think it is still better
than the risk of passing invalid objects around.

Cheers,

Nical

On Thu, Apr 21, 2016, at 05:05 PM, Nicholas Nethercote wrote:
> 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 that necessary state can't be fully
> > established before constructing an object.  If you find a way in which
> > this is possible, please let me know.
> 
> I just tried this pattern in three classes I've been experimenting
> with and hit problems in all three.
> 
> In bug 1265965 I wrote patches to convert nsThread+Init style to the
> nsThread+outparam style, which worked well. So I tried the style
> Nicolas and you are advocating, which I'll calls
> "falllible-then-infallible". Here is the Init() function, from the
> current trunk code:
> 
> nsresult
> nsThread::Init()
> {
>   // spawn thread and wait until it is fully setup
>   RefPtr startup = new nsThreadStartupEvent();
> 
>   NS_ADDREF_THIS();
> 
>   mShutdownRequired = true;
> 
>   // ThreadFunc is responsible for setting mThread
>   PRThread* thr = PR_CreateThread(PR_USER_THREAD, ThreadFunc, this,
>   PR_PRIORITY_NORMAL, PR_GLOBAL_THREAD,
>   PR_JOINABLE_THREAD, mStackSize);
>   if (!thr) {
> NS_RELEASE_THIS();
> return NS_ERROR_OUT_OF_MEMORY;
>   }
> 
>   // ThreadFunc will wait for this event to be run before it tries to
>   access
>   // mThread.  By delaying insertion of this event into the queue, we
>   ensure
>   // that mThread is set properly.
>   {
> MutexAutoLock lock(mLock);
> mEventsRoot.PutEvent(startup, lock); // retain a reference
>   }
> 
>   // Wait for thread to call ThreadManager::SetupCurrentThread, which
>   completes
>   // initialization of ThreadFunc.
>   startup->Wait();
>   return NS_OK;
> }
> 
> So this is the code that must run before we construct an actual
> nsThread object, right? The PR_CreateThread() call is the main
> problem. It takes |this| as a parameter and proceeds to do all sorts
> of stuff with it. It's probably not *impossible* to rewrite this as
> fallible-then-infallible, but I'm struggling to see what it would look
> like.
> 
> The second example I looked at was nsScriptSecurityManager. The
> constructor+outparam style worked well there, but
> fallible-then-infallible again hits a problem -- InitPrefs() is called
> in the fallible section of initialization, and it calls
> ScriptSecurityPrefChanged(), which touches lots of class members.
> Maybe InitPrefs() could be moved out of the fallible section, but I
> don't know this code well enough to say one way or the other.
> 
> The third example I looked at was CycleCollectedJSRuntime. Again
> problems, specifically this line in Init():
> 
>   mOwningThread->SetScriptObserver(this);
> 
> So, for all three examples I looked at fallible-then-infallible had
> problems ranging from moderate to severe. My conclusion is that
> partially initializing an object when the object doesn't exist is
> difficult, and, as a result, fallible-then-infallible is not a
> reliable general-purpose pattern.
> 
> Nick
___

multiple Rust crates are now supported

[Nathan Froyd]

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 crates, so you
have to structure your crate as one big crate that includes any
dependencies, rather than several separate crates, as is the norm.
This is clearly suboptimal, and it will be fixed.  I think it's an
open question exactly how we're going to integrate multiple crates and
external projects anyway, so feel free to experiment!

2) We do not have Rust support on all of our Tier 1 platforms (Android
is still being worked on), so actually depending on Rust code
everywhere is still not possible.

3) Due to bug 1178897, Rust code uses a completely different memory
allocator than the rest of Gecko.  We therefore don't have any
visibility into Rust's memory allocations through things like
about:memory, using Rust code worsens fragmentation issues, and there
are also edge cases with allocating in C++ and freeing in Rust (or
vice versa).  This is obviously something we're going to fix, ideally
soon.

We --enable-rust on all of our Tier 1 desktop platforms, but given 2)
and 3) above, it seems best to limit the amount of Rust code we
actually ship.  So if you want to land Rust components in-tree right
now, I'd recommend gating your component behind an --enable-shiny
configure option.  Ideally 2) and 3) will be fixed in short order, 1)
will be ironed out, and then the real fun can begin!

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

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

[Nicholas Nethercote]

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 that necessary state can't be fully
> established before constructing an object.  If you find a way in which
> this is possible, please let me know.

I just tried this pattern in three classes I've been experimenting
with and hit problems in all three.

In bug 1265965 I wrote patches to convert nsThread+Init style to the
nsThread+outparam style, which worked well. So I tried the style
Nicolas and you are advocating, which I'll calls
"falllible-then-infallible". Here is the Init() function, from the
current trunk code:

nsresult
nsThread::Init()
{
  // spawn thread and wait until it is fully setup
  RefPtr startup = new nsThreadStartupEvent();

  NS_ADDREF_THIS();

  mShutdownRequired = true;

  // ThreadFunc is responsible for setting mThread
  PRThread* thr = PR_CreateThread(PR_USER_THREAD, ThreadFunc, this,
  PR_PRIORITY_NORMAL, PR_GLOBAL_THREAD,
  PR_JOINABLE_THREAD, mStackSize);
  if (!thr) {
NS_RELEASE_THIS();
return NS_ERROR_OUT_OF_MEMORY;
  }

  // ThreadFunc will wait for this event to be run before it tries to access
  // mThread.  By delaying insertion of this event into the queue, we ensure
  // that mThread is set properly.
  {
MutexAutoLock lock(mLock);
mEventsRoot.PutEvent(startup, lock); // retain a reference
  }

  // Wait for thread to call ThreadManager::SetupCurrentThread, which completes
  // initialization of ThreadFunc.
  startup->Wait();
  return NS_OK;
}

So this is the code that must run before we construct an actual
nsThread object, right? The PR_CreateThread() call is the main
problem. It takes |this| as a parameter and proceeds to do all sorts
of stuff with it. It's probably not *impossible* to rewrite this as
fallible-then-infallible, but I'm struggling to see what it would look
like.

The second example I looked at was nsScriptSecurityManager. The
constructor+outparam style worked well there, but
fallible-then-infallible again hits a problem -- InitPrefs() is called
in the fallible section of initialization, and it calls
ScriptSecurityPrefChanged(), which touches lots of class members.
Maybe InitPrefs() could be moved out of the fallible section, but I
don't know this code well enough to say one way or the other.

The third example I looked at was CycleCollectedJSRuntime. Again
problems, specifically this line in Init():

  mOwningThread->SetScriptObserver(this);

So, for all three examples I looked at fallible-then-infallible had
problems ranging from moderate to severe. My conclusion is that
partially initializing an object when the object doesn't exist is
difficult, and, as a result, fallible-then-infallible is not a
reliable general-purpose pattern.

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

Re: Moving XP to ESR?

[Chris H-C]

>  * 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 SSE2.

In "real numbers" we're looking at fractions of a million users, say
somewhere on the order of 100k Firefox users on Windows 7 have no SSE2.

(there may also be some tens or hundreds of Linux users, but with sizes so
small I don't have confidence in the numbers produced).

:chutten

On Wed, Apr 20, 2016 at 3:14 PM, 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 branch that we only
> ship to XP users.
>
> I suspect that backporting to this would get very difficult very quickly.
> We'd be better off moving XP to ESR IMO.
>
> On 2016-04-20 02:53 PM, Armen Zambrano G. wrote:
>
>> Would it make more sense to have a relbranch instead of using ESR?
>> IIRC ESRs are stable for a period but when we uplift we uplift
>> everything new.
>> For this XP relbranch we would only take security patches.
>>
>> It would serve the purpose of keeping our users secure where they're but
>> saving some energy in making new features also XP compatible.
>>
>> Setting an N months EOL expectation (plus another criteria[s]) might be
>> wise rather than leaving it open ended.
>>
>> regards,
>> Armen
>>
>> On 16-04-20 11:46 AM, Henri Sivonen wrote:
>>
>>> On Mon, Apr 18, 2016 at 4:46 PM, Thomas Zimmermann
>>>  wrote:
>>>
 And XP still runs on ~10% of all desktops. That's an opportunity to
 convert some of the users to Firefox.

>>>
>>> This assumes that
>>>
>>> 1) users who are still on XP still make active browser choices
>>> 2) ESR wouldn't be good enough to for these users
>>> 3) XP will still run ~10% of desktops in 11 months.
>>>
>>> (FWIW, StatCounter puts XP's Web usage share of desktop closer to 7%
>>> than 10%.)
>>>
>>> On Mon, Apr 18, 2016 at 7:56 PM, Milan Sreckovic
>>>  wrote:
>>>
 What’s the “XP tax”?

>>>
>>> It's our attention being diverted to being backward-looking instead of
>>> forward-looking by a thousand cuts. Here are some examples off the top
>>> of my head:
>>>
>>>   * We don't have EME-style DRM on XP, but if we hadn't even tried to
>>> accommodate XP, we could have avoided some grief. (For obvious
>>> reasons, I'm not going to elaborate on this on this list.)
>>>
>>>   * The Rust team has had to do extra work to support XP, since XP is a
>>> Firefox product requirement.
>>>
>>>   * 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.
>>>
>>>   * XP failing to preserve register state on newer CPUs caused an
>>> investigation like
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1263495#c13
>>>
>>> Obviously, none of the above alone seems decisive, but those are just
>>> a few recent things that I can think of without searching. I'm sure
>>> there are a lots and lots of things, each smallish taken alone, but
>>> they add up and take our collective attention away from making our
>>> product better on current systems. Moving XP to ESR would liberate us
>>> from thinking of some of them, but, granted, we might feel compelled
>>> to figure out stuff like the AVX thing even on ESR. Also, some of the
>>> above are sunk cost now, but my point is that as long as XP is treated
>>> as supported, it can inflict new analogous costs on us.
>>>
>>> On Tue, Apr 19, 2016 at 11:24 PM, Kyle Huey  wrote:
>>>
 We jump through some hoops to support things like Linux and Mac too, and
 those platforms combined have far fewer users than XP.

>>>
>>> Linux and Mac will still be as relevant in 11 months. XP's relevance
>>> is declining. If our estimate was that XP won't be worthwhile in 11
>>> months, putting it on ESR now would make sense compared to expending
>>> the effort of full support over the next 11 months.
>>>
>>>
>>
>>
> ___
> 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: Proposal: use nsresult& outparams in constructors to represent failure

[Martin Thomson]

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 advantage with a heap-allocated object is that it exists or not.

Sticking something on the stack has advantages, is the intent here to
allow the creation of stack objects with these properties, because it
seems like Maybe<> or something Maybe<>-like is the best choice there,
maybe (hah) following the same pattern.

> - 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 that necessary state can't be fully
established before constructing an object.  If you find a way in which
this is possible, please let me know.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Nicholas Nethercote]

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 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 tend to be fewer of them also. So I am perfectly
> happy with handling them differently, and I can't think of a stack
> allocated object in the code I work with that would need something as
> involved as a static creation method or an nsresult& out param, to be
> honest.
>
> Cheers,
>
> Nical
>
> On Thu, Apr 21, 2016, at 12:24 PM, 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 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. Something like:
>> >
>> > static
>> > already_AddRefed Foo::Create(SomeParams...) {
>> > // logic that may fail...
>> > if (failed) {
>> >  return nullptr;
>> > }
>> > return MakeAndAddRef(stuffThatDidNotFail);
>> > }
>>
>> So instead of doing the infallible part in the constructor and the
>> fallible part in the Init() function, you're suggesting doing the
>> fallible part first and only calling the constructor once it succeeds?
>> Interesting. I can see it would work nicely for some heap-allocated
>> objects. But I see two possible problems:
>>
>> - It doesn't appear to work with stack-allocated objects?
>>
>> - 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.
>>
>> Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Nicolas Silva]

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 tend to be fewer of them also. So I am perfectly
happy with handling them differently, and I can't think of a stack
allocated object in the code I work with that would need something as
involved as a static creation method or an nsresult& out param, to be
honest.

Cheers,

Nical 

On Thu, Apr 21, 2016, at 12:24 PM, 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 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. Something like:
> >
> > static
> > already_AddRefed Foo::Create(SomeParams...) {
> > // logic that may fail...
> > if (failed) {
> >  return nullptr;
> > }
> > return MakeAndAddRef(stuffThatDidNotFail);
> > }
> 
> So instead of doing the infallible part in the constructor and the
> fallible part in the Init() function, you're suggesting doing the
> fallible part first and only calling the constructor once it succeeds?
> Interesting. I can see it would work nicely for some heap-allocated
> objects. But I see two possible problems:
> 
> - It doesn't appear to work with stack-allocated objects?
> 
> - 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.
> 
> Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Nicholas Nethercote]

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
> only instantiate the object in case of success, and mark the constructor
> protected. Something like:
>
> static
> already_AddRefed Foo::Create(SomeParams...) {
> // logic that may fail...
> if (failed) {
>  return nullptr;
> }
> return MakeAndAddRef(stuffThatDidNotFail);
> }

So instead of doing the infallible part in the constructor and the
fallible part in the Init() function, you're suggesting doing the
fallible part first and only calling the constructor once it succeeds?
Interesting. I can see it would work nicely for some heap-allocated
objects. But I see two possible problems:

- It doesn't appear to work with stack-allocated objects?

- 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.

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

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

[Nicolas Silva]

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. Something like:

static
already_AddRefed Foo::Create(SomeParams...) {
// logic that may fail...
if (failed) {
 return nullptr;
}
return MakeAndAddRef(stuffThatDidNotFail);
}

Between having ways to communicate that an object is constructed in an
invalid state, and never having invalid states, I much prefer the
latter.

Cheers,

Nical

On Thu, Apr 21, 2016, at 07:05 AM, Gerald Squelart wrote:
> On Thursday, April 21, 2016 at 11:15:10 AM UTC+10, Nicholas Nethercote
> wrote:
> > Hi,
> > 
> > C++ constructors can't be made fallible without using exceptions. As a 
> > result,
> > for many classes we have a constructor and a fallible Init() method which 
> > must
> > be called immediately after construction.
> > 
> > Except... there is one way to make constructors fallible: use an |nsresult&
> > aRv| outparam to communicate possible failure. I propose that we start doing
> > this.
> > 
> > Here's an example showing stack allocation and heap allocation. Currently, 
> > we
> > do this (boolean return type):
> > 
> >   T ts();
> >   if (!ts.Init()) {
> > return NS_ERROR_FAILURE;
> >   }
> >   T* th = new T();
> >   if (!th.Init()) {
> > delete th;
> > return NS_ERROR_FAILURE;
> >   }
> > 
> > or this (nsresult return type):
> > 
> >   T ts();
> >   nsresult rv = ts.Init();
> >   if (NS_FAILED(rv)) {
> > return rv;
> >   }
> >   T* th = new T();
> >   rv = th.Init();
> >   if (NS_FAILED(rv)) {
> > delete th;
> > return rv;
> >   }
> > 
> > (In all the examples you could use a smart pointer to avoid the explicit
> > |delete|. This doesn't affect my argument in any way.)
> > 
> > Instead, we would do this:
> > 
> >   nsresult rv;
> >   T ts(rv);
> >   if (NS_FAILED(rv)) {
> > return rv;
> >   }
> >   T* th = new T(rv);
> >   if (NS_FAILED(rv)) {
> > delete th;
> > return rv;
> >   }
> > 
> > For constructors with additional argument, I propose that the |nsresult&|
> > argument go last.
> > 
> > Using a bool outparam would be possible some of the time, but I suggest 
> > always
> > using nsresult for consistency, esp. given that using bool here would be no
> > more concise.
> > 
> > SpiderMonkey is different because (a) its |operator new| is fallible and 
> > (b) it
> > doesn't use nsresult. So for heap-allocated objects we *would* use bool, 
> > going
> > from this:
> > 
> >   T* th = new T();
> >   if (!th) {
> > return false;
> >   }
> >   if (!th.Init()) {
> > delete th;
> > return false;
> >   }
> > 
> > to this:
> > 
> >   bool ok;
> >   T* th = new T(ok);
> >   if (!th || !ok) {
> > delete th;
> > return false;
> >   }
> > 
> > These examples don't show inheritance, but this proposal works out
> > straightforwardly in that case.
> > 
> > The advantages of this proposal are as follows.
> > 
> > - Construction is atomic. It's not artificially split into two, and there's 
> > no
> >   creation of half-initialized objects. This tends to make the code nicer
> >   overall.
> > 
> > - Constructors are special because they have initializer lists -- there are
> >   things you can do in initializer lists that you cannot do in normal
> >   functions. In particular, using an Init() function prevents you from using
> >   references and |const| for some members. This is bad because references 
> > and
> >   |const| are good things that can make code more reliable.
> > 
> > - There are fewer things to forget at call sites. With our current approach 
> > you
> >   can forget (a) to call Init(), and (b) to check the result of
> > Init(). With this
> >   proposal you can only forget to check |rv|.
> > 
> > The only disadvantage I can see is that it looks a bit strange at first. 
> > But if
> > we started using it that objection would quickly go away.
> > 
> > I have some example patches that show what this code pattern looks like in
> > practice. See bug 1265626 parts 1 and 4, and bug 1265965 part 1.
> > 
> > Thoughts?
> > 
> > Nick
> 
> (busy right now, please excuse terseness & typos!)
> 
> Big thumbs up for trying to remove split construction
> 
> My main beef with this proposal is the use of out-params, which require
> (usually uninitialized) declaration of the out-param.
> But I see that it may indeed be the best solution here, so ... fne!
> 
> However, since lots of Mozilla objects are unique-ptr'd or ref-counted, I
> would argue that we could easily fold the construction checks with the
> nullptr-checks that we all know!
> 
> So in addition to your proposal, I would like to see a small library of
> tools that will build on top of your new style, and make it easier &
> cleaner & consistent to use in those cases.
> 
> E.g.:
>   template 
>   T* 

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

[Eric Rescorla]

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 an object in an ill-defined half-constructed
> > state. At least for heap allocations, I'd much rather have the property
> that
> > failures leave you with a null pointer.
>
> First of all, with neither approach do you end up with a null pointer,
> at least not in Gecko where we have infallible new. So let's ignore
> that sentence.
>

No, let's not ignore that sentence. I'm aware that the current idioms don't
provide that. I'm saying that if we are going to bother to add a new idiom
it should have this property.


> 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 (as you should) then
> > they automatically validate correct construction and if not return an
> empty
> > pointer.
>
> MakeUnique() just allocates and calls the constructor. If you have
> fallible steps in your intialization then MakeUnique() won't help you;
> you'll still have either call your Init() function afterwards or check
> your nsresult& outparam. So that's not relevant.
>

Yes, what I'm saying is that we should modify MakeUnique so that if a
constructor has the form you are recommending, it should end up with an
empty UniquePtr rather than requiring you to explicitly check the result.



Maybe you're referring to factory methods,


I'm not.



> 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 stack-allocated
> objects. Second, you still have to do your fallible initialization
> *within* the factory method, and so you still have to choose with
> either constructor+Init or constructor+outparam, so you still have to
> make a choice.
>

This is why I didn't suggest it.

-Ekr


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

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

[Chris Peterson]

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 classes with Init() member functions could be shoehorned, 
unchanged, into this pattern with a MakeUnique() variant that called and 
checked Init(). Something like:


MakeUniqueAndInit(Args&&... aArgs)
{
  UniquePtr up(new T(Forward(aArgs)...));
  return NS_SUCCEEDED(up.Init()) ? up : UniquePtr();
}


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

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

[Gerald Squelart]

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 methods can be useful, but
> >> there's two problems. First, they're not applicable to stack-allocated
> >> objects. Second, you still have to do your fallible initialization
> >> *within* the factory method, and so you still have to choose with
> >> either constructor+Init or constructor+outparam, so you still have to
> >> make a choice.
> >
> > You can probably merge Init into this factory method, and make constructors
> > private.
> 
> Inlining Init into the factory method doesn't change the fundamentals.
> Initialization is still split across two functions. You still can't
> use references and |const| as much.
> 
> > For stack-allocated objects, you can probably return a Maybe<>?
> 
> I played around with Maybe<> and couldn't come up with something nice.
> I may have missed something. Even if there is a nice way involving
> Maybe<>, I'm pretty sure you'll still end up having to make a choice
> between constructor+Init and constructor+outparam within the factory
> method.
> 
> Nick

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();
  }

No need for factory methods. ;-)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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

[Nicholas Nethercote]

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 stack-allocated
>> objects. Second, you still have to do your fallible initialization
>> *within* the factory method, and so you still have to choose with
>> either constructor+Init or constructor+outparam, so you still have to
>> make a choice.
>
> You can probably merge Init into this factory method, and make constructors
> private.

Inlining Init into the factory method doesn't change the fundamentals.
Initialization is still split across two functions. You still can't
use references and |const| as much.

> For stack-allocated objects, you can probably return a Maybe<>?

I played around with Maybe<> and couldn't come up with something nice.
I may have missed something. Even if there is a nice way involving
Maybe<>, I'm pretty sure you'll still end up having to make a choice
between constructor+Init and constructor+outparam within the factory
method.

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

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

[Xidorn Quan]

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 (as you should) then
> > they automatically validate correct construction and if not return an
> empty
> > pointer.
>
> MakeUnique() just allocates and calls the constructor. If you have
> fallible steps in your intialization then MakeUnique() won't help you;
> you'll still have either call your Init() function afterwards or check
> your nsresult& outparam. So that's not relevant.
>
> 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 stack-allocated
> objects. Second, you still have to do your fallible initialization
> *within* the factory method, and so you still have to choose with
> either constructor+Init or constructor+outparam, so you still have to
> make a choice.
>

You can probably merge Init into this factory method, and make constructors
private.

For stack-allocated objects, you can probably return a Maybe<>?

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

Re: Update on Webcomponents?

[Anne van Kesteren]

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
> reached on the final implementation and I agree it would not be a good
> idea to just implement something to be compatible to Chrome.

The Chrome developers refer to what they implement as v0. They are
working on v1 and I believe we will be again working on that soonish
too, now the platform team has some more breathing room.


> Nevertheless, since it was mentioned that the new consensus-based shadow
> dom implementation is expected to ship in Q1, I'd appreciate if someone
> (Anne? Wilson?) could give an update, maybe even as a blog post if there
> is news.

Well, the specification took a little longer and there's still issues
with shadow trees that are rather hard to resolve (e.g., how should
 work), but custom elements is ready and now integrated into
the DOM and HTML Standards (rather than existing as a monkey patch on
top of those standards). From what I know our plan is to implement
custom elements first.


> How far from generally usable are web components? I think it would be
> great to get more support in, as it would be particularly useful to
> replace XBL bindings on the mission to deprecate XUL.

Yeah, though I suspect that might take a while either way.


> Personally I've run into a few issues regarding ::content styling, but I
> understand this might change anyway if the slots pattern is used. Also,
> it seems devtools does not fully support custom elements.

Yes, we won't implement ::content. It's now called ::slotted I believe
with slightly different semantics.


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