Re: Decommissioning "dumbmake"

2015-10-18 Thread Nicholas Alexander 
On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla  wrote:

>
>
> On Sun, Oct 18, 2015 at 2:52 PM, Nicholas Alexander <
> nalexan...@mozilla.com> wrote:
>
>>
>>
>> On Thu, Oct 15, 2015 at 5:15 PM, Mike Hommey  wrote:
>>
>>> Hi,
>>>
>>> I started a thread with the same subject almost two years ago. The
>>> motivation hasn't changed, but the context surely has, so it's probably
>>> time to reconsider.
>>>
>>> As a reminder, "dumbmake" is the feature that makes "mach build foo/bar"
>>> sometimes rebuild in some other directories as well. For example, "mach
>>> build gfx" will build gfx, as well as toolkit/library.
>>>
>>> OTOH, it is pretty limited, and, for instance, "mach build gfx/2d" will
>>> only build gfx/2d.
>>>
>>> There are however now two build targets that can do the right thing for
>>> most use cases:
>>> - mach build binaries, which will build C/C++ related things
>>>   appropriately
>>> - mach build faster, which will build JS, XUL, CSS, etc. (iow, non
>>>   C/C++) (although it skips what doesn't end up in dist/bin)
>>>
>>> At this point, I think "dumbmake" is more harmful than helpful, and the
>>> above two targets should be used instead. Removing "dumbmake" would mean
>>> that "mach build foo/bar" would still work, but would stop to "magically"
>>> do something else than what was requested (or fail to do that thing for
>>> all the cases it doesn't know about).
>>>
>>> Are there still objections to go forward, within the new context?
>>>
>>
>> I agree that dumbmake is more harmful than helpful.  I did some of the
>> work to port it forward to the mach world; IIRC, my motivation was to ease
>> the transition to "mach and smarter build targets".  We're now seeing
>> smarter build targets that aren't based on (recursive) Make, and dumbmake
>> hasn't helped anybody transition to anything: there have been a wopping 10
>> commits to the underlying dependency tree [1], some of which are backouts
>> and relandings.
>>
>> If we need smarter build targets, let's make that happen at the mach
>> level, not at the Make level
>>
>
> Slightly off-topic, but I'd like to argue against smarter build targets,
> if by that you mean more stuff like "mach build binaries"
>
> What's needed here is a dependency management system that
> simply builds what's needed regardless of what's changed, not more
> ways for the user to tell the build system "only rebuild some stuff".
>

In general, I agree, but there are legitimate differences in user intention
that do need to be capture somewhere.  I claim that should be at the mach
command level, but I don't really care if those are top-level (mach
rebuild-xul) or subcommand level (mach build xul), and whether they are
internally "smarter build targets".

In Android land, we're using Gradle to task switch like this -- build, yes;
but also lint; and also run tests; etc.

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

Re: Decommissioning "dumbmake"

2015-10-18 Thread Eric Rescorla 
On Sun, Oct 18, 2015 at 2:52 PM, Nicholas Alexander 
wrote:

>
>
> On Thu, Oct 15, 2015 at 5:15 PM, Mike Hommey  wrote:
>
>> Hi,
>>
>> I started a thread with the same subject almost two years ago. The
>> motivation hasn't changed, but the context surely has, so it's probably
>> time to reconsider.
>>
>> As a reminder, "dumbmake" is the feature that makes "mach build foo/bar"
>> sometimes rebuild in some other directories as well. For example, "mach
>> build gfx" will build gfx, as well as toolkit/library.
>>
>> OTOH, it is pretty limited, and, for instance, "mach build gfx/2d" will
>> only build gfx/2d.
>>
>> There are however now two build targets that can do the right thing for
>> most use cases:
>> - mach build binaries, which will build C/C++ related things
>>   appropriately
>> - mach build faster, which will build JS, XUL, CSS, etc. (iow, non
>>   C/C++) (although it skips what doesn't end up in dist/bin)
>>
>> At this point, I think "dumbmake" is more harmful than helpful, and the
>> above two targets should be used instead. Removing "dumbmake" would mean
>> that "mach build foo/bar" would still work, but would stop to "magically"
>> do something else than what was requested (or fail to do that thing for
>> all the cases it doesn't know about).
>>
>> Are there still objections to go forward, within the new context?
>>
>
> I agree that dumbmake is more harmful than helpful.  I did some of the
> work to port it forward to the mach world; IIRC, my motivation was to ease
> the transition to "mach and smarter build targets".  We're now seeing
> smarter build targets that aren't based on (recursive) Make, and dumbmake
> hasn't helped anybody transition to anything: there have been a wopping 10
> commits to the underlying dependency tree [1], some of which are backouts
> and relandings.
>
> If we need smarter build targets, let's make that happen at the mach
> level, not at the Make level
>

Slightly off-topic, but I'd like to argue against smarter build targets,
if by that you mean more stuff like "mach build binaries"

What's needed here is a dependency management system that
simply builds what's needed regardless of what's changed, not more
ways for the user to tell the build system "only rebuild some stuff".

-Ekr


> Nick
>
> [1]
> https://hg.mozilla.org/mozilla-central/filelog/e8c7dfe727cd970e2c3294934e2927b14143c205/build/dumbmake-dependencies
>
>
> ___
> 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: Decommissioning "dumbmake"

2015-10-18 Thread Nicholas Alexander 
On Thu, Oct 15, 2015 at 5:15 PM, Mike Hommey  wrote:

> Hi,
>
> I started a thread with the same subject almost two years ago. The
> motivation hasn't changed, but the context surely has, so it's probably
> time to reconsider.
>
> As a reminder, "dumbmake" is the feature that makes "mach build foo/bar"
> sometimes rebuild in some other directories as well. For example, "mach
> build gfx" will build gfx, as well as toolkit/library.
>
> OTOH, it is pretty limited, and, for instance, "mach build gfx/2d" will
> only build gfx/2d.
>
> There are however now two build targets that can do the right thing for
> most use cases:
> - mach build binaries, which will build C/C++ related things
>   appropriately
> - mach build faster, which will build JS, XUL, CSS, etc. (iow, non
>   C/C++) (although it skips what doesn't end up in dist/bin)
>
> At this point, I think "dumbmake" is more harmful than helpful, and the
> above two targets should be used instead. Removing "dumbmake" would mean
> that "mach build foo/bar" would still work, but would stop to "magically"
> do something else than what was requested (or fail to do that thing for
> all the cases it doesn't know about).
>
> Are there still objections to go forward, within the new context?
>

I agree that dumbmake is more harmful than helpful.  I did some of the work
to port it forward to the mach world; IIRC, my motivation was to ease the
transition to "mach and smarter build targets".  We're now seeing smarter
build targets that aren't based on (recursive) Make, and dumbmake hasn't
helped anybody transition to anything: there have been a wopping 10 commits
to the underlying dependency tree [1], some of which are backouts and
relandings.

If we need smarter build targets, let's make that happen at the mach level,
not at the Make level.

Nick

[1]
https://hg.mozilla.org/mozilla-central/filelog/e8c7dfe727cd970e2c3294934e2927b14143c205/build/dumbmake-dependencies
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Decommissioning "dumbmake"

2015-10-18 Thread Nicholas Nethercote 
On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla  wrote:
>
> What's needed here is a dependency management system that
> simply builds what's needed regardless of what's changed,

Otherwise known as "a proper build system". glandium and co. have been
working towards that for a long time. It's a big, difficult job. |mach
build binaries| and |mach build faster| are temporary waypoints along
the way that approximate "a proper build system" for a couple of
common workflows. Eventually |mach build| should just do the right
thing, no matter what files you've touched...

> not more ways for the user to tell the build system "only rebuild some stuff".

... except that bholley and ehsan are asking for a way to override the
dependency tracking and just rebuild particular directories. Which is
reasonable, up to a point. I argue that support for this kind of thing
should be very limited and simple, to avoid getting in glandium's way
as he works towards "a proper build system". IMO, if you're elite
enough that you're regularly telling the build system "I know better
than you" then you're elite enough to remember which directories need
to be built in which order, or to encode those ordering into some
aliases.

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

Re: Decommissioning "dumbmake"

2015-10-18 Thread Eric Rescorla 
On Sun, Oct 18, 2015 at 3:18 PM, Nicholas Alexander 
wrote:

>
>
> On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla  wrote:
>
>>
>>
>> On Sun, Oct 18, 2015 at 2:52 PM, Nicholas Alexander <
>> nalexan...@mozilla.com> wrote:
>>
>>>
>>>
>>> On Thu, Oct 15, 2015 at 5:15 PM, Mike Hommey  wrote:
>>>
 Hi,

 I started a thread with the same subject almost two years ago. The
 motivation hasn't changed, but the context surely has, so it's probably
 time to reconsider.

 As a reminder, "dumbmake" is the feature that makes "mach build foo/bar"
 sometimes rebuild in some other directories as well. For example, "mach
 build gfx" will build gfx, as well as toolkit/library.

 OTOH, it is pretty limited, and, for instance, "mach build gfx/2d" will
 only build gfx/2d.

 There are however now two build targets that can do the right thing for
 most use cases:
 - mach build binaries, which will build C/C++ related things
   appropriately
 - mach build faster, which will build JS, XUL, CSS, etc. (iow, non
   C/C++) (although it skips what doesn't end up in dist/bin)

 At this point, I think "dumbmake" is more harmful than helpful, and the
 above two targets should be used instead. Removing "dumbmake" would mean
 that "mach build foo/bar" would still work, but would stop to
 "magically"
 do something else than what was requested (or fail to do that thing for
 all the cases it doesn't know about).

 Are there still objections to go forward, within the new context?

>>>
>>> I agree that dumbmake is more harmful than helpful.  I did some of the
>>> work to port it forward to the mach world; IIRC, my motivation was to ease
>>> the transition to "mach and smarter build targets".  We're now seeing
>>> smarter build targets that aren't based on (recursive) Make, and dumbmake
>>> hasn't helped anybody transition to anything: there have been a wopping 10
>>> commits to the underlying dependency tree [1], some of which are backouts
>>> and relandings.
>>>
>>> If we need smarter build targets, let's make that happen at the mach
>>> level, not at the Make level
>>>
>>
>> Slightly off-topic, but I'd like to argue against smarter build targets,
>> if by that you mean more stuff like "mach build binaries"
>>
>> What's needed here is a dependency management system that
>> simply builds what's needed regardless of what's changed, not more
>> ways for the user to tell the build system "only rebuild some stuff".
>>
>
> In general, I agree, but there are legitimate differences in user
> intention that do need to be capture somewhere.
>

Can you provide some examples that aren't rebuilds of part of the system?

I agree that lint and tests are relevant, but that's a different category.

-Ekr




> I claim that should be at the mach command level, but I don't really care
> if those are top-level (mach rebuild-xul) or subcommand level (mach build
> xul), and whether they are internally "smarter build targets".
>
> In Android land, we're using Gradle to task switch like this -- build,
> yes; but also lint; and also run tests; etc.
>
> Nick
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Decommissioning "dumbmake"

2015-10-18 Thread Lawrence Mandel 
On Sun, Oct 18, 2015 at 7:14 PM, Nicholas Nethercote  wrote:

> On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla  wrote:
> >
> > What's needed here is a dependency management system that
> > simply builds what's needed regardless of what's changed,
>
> Otherwise known as "a proper build system". glandium and co. have been
> working towards that for a long time. It's a big, difficult job. |mach
> build binaries| and |mach build faster| are temporary waypoints along
> the way that approximate "a proper build system" for a couple of
> common workflows. Eventually |mach build| should just do the right
> thing, no matter what files you've touched...
>
> > not more ways for the user to tell the build system "only rebuild some
> stuff".
>
> ... except that bholley and ehsan are asking for a way to override the
> dependency tracking and just rebuild particular directories. Which is
> reasonable, up to a point. I argue that support for this kind of thing
> should be very limited and simple, to avoid getting in glandium's way
> as he works towards "a proper build system". IMO, if you're elite
> enough that you're regularly telling the build system "I know better
> than you" then you're elite enough to remember which directories need
> to be built in which order, or to encode those ordering into some
> aliases.
>

A proper build system is something that we needed yesterday. jgriffin and
co are working on a plan to create a proper build system (no doubt with
glandium) starting in Q1. (Actually, ground work has already started.) We
can hack on things until then but we really just need to do the right
things that have been discussed in this and other threads.

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

Re: Decommissioning "dumbmake"

2015-10-18 Thread Karl Tomlinson 
On Fri, 16 Oct 2015 10:31:43 -0700, Gregory Szorc wrote:

> But as awesome as
> these targets are, they can still build more than is desired (especially in
> the edit .h file case). This slows down iteration cycles and slows down
> developers.
>
> For this reason, I think dumbmake needs to remain or be replaced by
> something that allows Gecko developers to easily perform a partial (and
> probably incorrect end state) build. I /think/ this could be as simple as a
> "xul" target that linked libxul. This way, people could type `mach build
> dom/base xul` and build all binaries (including static libraries) under a
> source directory and link libxul.

Are you suggesting that would do something different to this?
./mach build dom/base toolkit/library
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Decommissioning "dumbmake"

2015-10-18 Thread Gerald Squelart 
On Monday, October 19, 2015 at 11:09:46 AM UTC+11, Eric Rescorla wrote:
> On Sun, Oct 18, 2015 at 4:14 PM, Nicholas Nethercote
> wrote:
> 
> > On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla wrote:
> > >
> > > What's needed here is a dependency management system that
> > > simply builds what's needed regardless of what's changed,
> >
> > Otherwise known as "a proper build system". glandium and co. have been
> > working towards that for a long time. It's a big, difficult job. |mach
> > build binaries| and |mach build faster| are temporary waypoints along
> > the way that approximate "a proper build system" for a couple of
> > common workflows. Eventually |mach build| should just do the right
> > thing, no matter what files you've touched...
> >
> > > not more ways for the user to tell the build system "only rebuild some
> > stuff".
> >
> > ... except that bholley and ehsan are asking for a way to override the
> > dependency tracking and just rebuild particular directories.
> 
> 
> I don't want to speak for bholley and ehsan, but when *I* run into this
> problem it's because the build system isn't doing the right thing. If it
> were, I wouldn't have to.
> 
> -Ekr

I think the situation they're talking about, and which I've experienced myself, 
is that sneezing at a header file that's included almost everywhere means a 
very long rebuild time -- which is the right thing for the build system to do 
of course!

But if we've only changed a comment, or added a method, or are just trying to 
implement/fix a bug and test a patch quickly in isolation, then we should have 
the ability to locally override the build system decisions.

There are probably ways around that (e.g. experiment in a cpp file before 
moving code to a header), but it's sometimes cumbersome or just not worth the 
effort, compared with rebuilding only parts of the system.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: HTMLElement.innerText

2015-10-18 Thread Robert O'Callahan 
https://bugzilla.mozilla.org/show_bug.cgi?id=264412

Webkit, Blink and Trident have been shipping this for years without a spec
and with poor interop. We held off on implementing it since you can
polyfill a better implementation in JS without much difficulty, but we have
to implement something for Web compat. Because Mozilla, I've drafted a spec
here: https://github.com/rocallahan/innerText-spec which will hopefully
find its way through the W3C WICG, but given the state of the world, us
shipping this with or without a spec can hardly cause any more harm.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Decommissioning "dumbmake"

2015-10-18 Thread Bobby Holley 
On Sun, Oct 18, 2015 at 8:37 PM, Boris Zbarsky  wrote:

> On 10/18/15 7:14 PM, Nicholas Nethercote wrote:
>
>> Eventually |mach build| should just do the right
>> thing, no matter what files you've touched...
>>
>
> The problem is that definitions of "right thing" differ depending on the
> goal, right?
>

Exactly. It's not clear to me that even the perfect build system would
solve this problem (unless it were perfectly fast, in which case I don't
care about any of this). The C++ compilation model requires that we rebuild
everything that #includes a header file that changed, which can take a long
time, so I use my wetware capabilities to short-circuit that heavy rebuild
when I know it isn't needed.

I know this may void my warranty in general, but (as Jonas points out) the
only thing I really care about is making sure that the stuff I rebuilt gets
linked, which IMO is something the build system should be able to
guarantee. This may be simpler than it used to be now that (most?)
everything is linked into libxul, but I think there are still various
corner cases in the tree (correct me if I'm wrong).

I've heard two compelling arguments against the current setup:
(1) It's inconsistent.
(2) It causes unnecessary overhead when you do |mach build foo bar| because
we link between foo and bar.

for (1), I would be satisfied with a stripped down version of dumbmake that
doesn't do any building, but _does_ guarantee to link everything. (2) could
be solved with a flag to |mach build| to indicate whether or not the link
step should be performed (though I think linking should be the default).

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

Re: Decommissioning "dumbmake"

2015-10-18 Thread Boris Zbarsky 

On 10/18/15 7:14 PM, Nicholas Nethercote wrote:

Eventually |mach build| should just do the right
thing, no matter what files you've touched...


The problem is that definitions of "right thing" differ depending on the 
goal, right?


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

Re: Decommissioning "dumbmake"

2015-10-18 Thread Jonas Sicking 
On Sun, Oct 18, 2015 at 4:14 PM, Nicholas Nethercote
 wrote:
>
>> not more ways for the user to tell the build system "only rebuild some 
>> stuff".
>
> ... except that bholley and ehsan are asking for a way to override the
> dependency tracking and just rebuild particular directories. Which is
> reasonable, up to a point. I argue that support for this kind of thing
> should be very limited and simple, to avoid getting in glandium's way
> as he works towards "a proper build system".

This makes sense to me.

It occurred to me that maybe this can be solved by having a mach
command similar to "build binaries", but which *only* links libraries
and doesn't compile any cpp files.

That way it's easy enough to do "mach build dom/whatever && mach build
linklibraries". This wouldn't need the smarts to figure out which
libraries needs to be relinked if a given source file has change, it
would just attempt to relink all of them.

I think the big timesave that bholley and ehsan is looking for is
avoiding recompiling a bunch of C++ files, which this would still
accomplish.

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

Re: Decommissioning "dumbmake"

2015-10-18 Thread Eric Rescorla 
On Sun, Oct 18, 2015 at 4:14 PM, Nicholas Nethercote  wrote:

> On Sun, Oct 18, 2015 at 3:12 PM, Eric Rescorla  wrote:
> >
> > What's needed here is a dependency management system that
> > simply builds what's needed regardless of what's changed,
>
> Otherwise known as "a proper build system". glandium and co. have been
> working towards that for a long time. It's a big, difficult job. |mach
> build binaries| and |mach build faster| are temporary waypoints along
> the way that approximate "a proper build system" for a couple of
> common workflows. Eventually |mach build| should just do the right
> thing, no matter what files you've touched...
>
> > not more ways for the user to tell the build system "only rebuild some
> stuff".
>
> ... except that bholley and ehsan are asking for a way to override the
> dependency tracking and just rebuild particular directories.


I don't want to speak for bholley and ehsan, but when *I* run into this
problem it's because the build system isn't doing the right thing. If it
were, I wouldn't have to.

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

Re: mozilla::RefPtr is dead, long live ::RefPtr

2015-10-18 Thread Kyle Huey 
Huzzah!

When are you going to do nsCOMPtr? ;)

- Kyle

On Sun, Oct 18, 2015 at 7:43 AM, Nathan Froyd  wrote:
> Hi all,
>
> Bug 1207245 has landed on mozilla-central.  Its main purpose in life is to
> unify mozilla::RefPtr and nsRefPtr (both of which live in MFBT) into a
> single RefPtr class.  This new RefPtr class, like nsRefPtr, lives at the
> *global* scope, not in the mozilla:: namespace.  Follow-up patches or ideas
> on how to fix this welcome; I have brute-force ideas on how to do it, but
> they require large quantities of machine time.
>
> The new RefPtr works exactly the same as the old nsRefPtr: getter_AddRefs,
> interoperation with nsCOMPtr, etc.  It's worth noting that if you used
> byRef with mozilla::RefPtr for (XP)COM outparam semantics, you'll have to
> use getter_AddRefs now instead.  Please note that getter_AddRefs zeroes out
> the pointer prior to passing it as an outparam (as it has always done),
> which byRef did *not* do.  (You should not have been depending on this
> behavior, but if you were...)
>
> Updating patches/commits affected by these changes should be as simple as
> running:
>
> perl -p -i -e 's#mozilla/nsRefPtr.h#mozilla/RefPtr.h#'
> perl -p -i -e 's#mozilla::RefPtr#RefPtr#'
> perl -p -i -e 's#nsRefPtr<#RefPtr<#'
> perl -p -i -e 's#byRef#getter_AddRefs#'
>
> over the affected files.
>
> As a side-effect of these changes, mozilla::RefCounted and
> mozilla::external::AtomicRefCounted have moved to their own header,
> mozilla/RefCounted.h.
>
> Happy hacking,
> -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: mozilla::RefPtr is dead, long live ::RefPtr

2015-10-18 Thread Boris Zbarsky 

On 10/18/15 10:43 AM, Nathan Froyd wrote:

Bug 1207245 has landed on mozilla-central.


Are we sure enough this will stick that we should update documentation 
(e.g. 
) to 
refer to RefPtr instead of nsRefPtr?


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

mozilla::RefPtr is dead, long live ::RefPtr

2015-10-18 Thread Nathan Froyd 
Hi all,

Bug 1207245 has landed on mozilla-central.  Its main purpose in life is to
unify mozilla::RefPtr and nsRefPtr (both of which live in MFBT) into a
single RefPtr class.  This new RefPtr class, like nsRefPtr, lives at the
*global* scope, not in the mozilla:: namespace.  Follow-up patches or ideas
on how to fix this welcome; I have brute-force ideas on how to do it, but
they require large quantities of machine time.

The new RefPtr works exactly the same as the old nsRefPtr: getter_AddRefs,
interoperation with nsCOMPtr, etc.  It's worth noting that if you used
byRef with mozilla::RefPtr for (XP)COM outparam semantics, you'll have to
use getter_AddRefs now instead.  Please note that getter_AddRefs zeroes out
the pointer prior to passing it as an outparam (as it has always done),
which byRef did *not* do.  (You should not have been depending on this
behavior, but if you were...)

Updating patches/commits affected by these changes should be as simple as
running:

perl -p -i -e 's#mozilla/nsRefPtr.h#mozilla/RefPtr.h#'
perl -p -i -e 's#mozilla::RefPtr#RefPtr#'
perl -p -i -e 's#nsRefPtr<#RefPtr<#'
perl -p -i -e 's#byRef#getter_AddRefs#'

over the affected files.

As a side-effect of these changes, mozilla::RefCounted and
mozilla::external::AtomicRefCounted have moved to their own header,
mozilla/RefCounted.h.

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

Re: mozilla::RefPtr is dead, long live ::RefPtr

2015-10-18 Thread Boris Zbarsky 

On 10/18/15 11:11 AM, Kyle Huey wrote:

When are you going to do nsCOMPtr? ;)


Are we sure there is no codesize hit when moving from nsCOMPtr (which 
tries to share implementation via nsCOMPtr_base) to RefPtr?


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

Re: mozilla::RefPtr is dead, long live ::RefPtr

2015-10-18 Thread Kyle Huey 
I meant removing the ns prefix (i.e. s/nsCOMPtr/COMPtr/), which is the
net effect of this change for places that previous used nsRefPtr,
AIUI.

- Kyle

On Sun, Oct 18, 2015 at 8:24 AM, Boris Zbarsky  wrote:
> On 10/18/15 11:11 AM, Kyle Huey wrote:
>>
>> When are you going to do nsCOMPtr? ;)
>
>
> Are we sure there is no codesize hit when moving from nsCOMPtr (which tries
> to share implementation via nsCOMPtr_base) to RefPtr?
>
> -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