On 2016-01-15 7:44 PM, Trevor Saunders wrote:
On Fri, Jan 15, 2016 at 04:28:13PM -0800, Jonas Sicking wrote:
On Fri, Jan 15, 2016 at 11:41 AM, Joshua Cranmer 🐧 wrote:
On 1/15/2016 1:21 PM, Bobby Holley wrote:
Has anyone measured recently whether there's still a significant perf win
to making
On Fri, Jan 15, 2016 at 04:28:13PM -0800, Jonas Sicking wrote:
> On Fri, Jan 15, 2016 at 11:41 AM, Joshua Cranmer 🐧
> wrote:
> > On 1/15/2016 1:21 PM, Bobby Holley wrote:
> >>
> >> Has anyone measured recently whether there's still a significant perf win
> >> to making IIDs 32-bit? If we stop usi
On Fri, Jan 15, 2016 at 11:41 AM, Joshua Cranmer 🐧 wrote:
> On 1/15/2016 1:21 PM, Bobby Holley wrote:
>>
>> Has anyone measured recently whether there's still a significant perf win
>> to making IIDs 32-bit? If we stop using them as a versioning tool, we
>> could
>> potentially relax our uniquenes
On Fri, Jan 15, 2016 at 08:21:09AM -0500, Ted Mielczarek wrote:
> Hello,
>
> I'm interested in feedback from anyone out there that's doing builds on
> non-Tier 1 platforms. Specifically, I want to know if you build
> --with-system-nspr or not. I've got patches[1] to stop using NSPR's
> autoconf bu
On 2016-01-15 1:27 PM, Boris Zbarsky wrote:
On 1/15/16 10:58 AM, Ehsan Akhgari wrote:
* My proposal has no bearing on whether changes to XPIDL interfaces
needs to be considered as part of the uplift approval process, as such
changes can still have an impact on JS extension compatibility.
This
On 2016-01-15 2:21 PM, Bobby Holley wrote:
Has anyone measured recently whether there's still a significant perf
win to making IIDs 32-bit? If we stop using them as a versioning tool,
we could potentially relax our uniqueness requirements, and save a lot
of comparisons on each QI. Addon-compat wo
On 1/15/2016 1:21 PM, Bobby Holley wrote:
Has anyone measured recently whether there's still a significant perf win
to making IIDs 32-bit? If we stop using them as a versioning tool, we could
potentially relax our uniqueness requirements, and save a lot of
comparisons on each QI. Addon-compat wou
Has anyone measured recently whether there's still a significant perf win
to making IIDs 32-bit? If we stop using them as a versioning tool, we could
potentially relax our uniqueness requirements, and save a lot of
comparisons on each QI. Addon-compat would be tricky, but is potentially
solvable.
This is awesome. We've talked about how much we've wanted this since the
early days of MemShrink back in 2011. Thanks to everyone who was involved.
- Kyle
On Thu, Jan 14, 2016 at 1:50 PM, Nick Fitzgerald
wrote:
> Hi folks!
>
> Dominator trees give you fine-grained insight into memory retentio
On Fri, Jan 15, 2016 at 10:58 AM, Ehsan Akhgari
wrote:
> Please let me know if you have any questions or concerns.
or cheers.
cheers!
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 1/14/16 9:46 PM, Kyle Machulis wrote:
*Summary*: We don't currently support documents.elementsFromPoint, while IE
and Chrome do (I'm not sure if Opera and Safari have gotten around to it
yet).
Opera does have document.elementsFromPoint and Safari does not (yet). I
couldn't find an open bug
On 1/15/16 10:58 AM, Ehsan Akhgari wrote:
* My proposal has no bearing on whether changes to XPIDL interfaces
needs to be considered as part of the uplift approval process, as such
changes can still have an impact on JS extension compatibility.
This should probably include Web IDL interfaces to
On 2016-01-06 5:54 PM, William Lachance wrote:
1. Effective immediately (well, as soon as possible): Stop emailing
developers graphserver regression reports. These reports will continue
to be sent to mozilla.dev.tree-alerts (mostly so that they can be picked
up by the existing AlertManager system
On 1/14/16 9:09 PM, L. David Baron wrote:
It seems to me this is important to have behind a preference that is
specific to new webkit-prefixed features, given the compatibility
risks of shipping support for some but not all webkit-prefixed
features.
(It's possible it could be the same preference
As the XPIDL module owner, I support this.
- Kyle
On Fri, Jan 15, 2016 at 7:58 AM, Ehsan Akhgari
wrote:
> Historically we have enforced updating the XPIDL interface UUIDs when you
> made any changes to it. This was needed because of two reasons:
>
> * Backwards compatibility with binary extens
Historically we have enforced updating the XPIDL interface UUIDs when
you made any changes to it. This was needed because of two reasons:
* Backwards compatibility with binary extensions. Since many changes to
XPIDL interfaces caused the underlying v-table layout to change, revving
the UUID
Hello,
I'm interested in feedback from anyone out there that's doing builds on
non-Tier 1 platforms. Specifically, I want to know if you build
--with-system-nspr or not. I've got patches[1] to stop using NSPR's
autoconf build system in favor of moz.build files, but I've only made
them support our
It's not enabled by default because the API is probably not fully baked
yet; until the spec reaches Stage 3 at TC39 we should expect things to be
fluid. I don't expect that milestone to be reached until this summer.
We've discussed enabling by default on Aurora, DevEd, and Beta once we
reach Stag
18 matches
Mail list logo