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

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

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

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

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

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

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

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

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

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

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 ___

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

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

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 >

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

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

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

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