Re: enabling off-main-thread animations on nightly/aurora

On Tuesday 2015-03-31 23:28 -0700, Jet Villegas wrote: > \o/ Hooray! This one took a lot of effort from many people across the > Rendering teams. Super-Happy to see it land. Well, it actually didn't, due to test failures introduced sometime in the past 3 days. Hopefully it will reland soon, thoug

[meta] "Intent to implement" and Security & Privacy concerns

One of the suggested additions to "intent to implement" emails: https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement is a statement regarding Security & Privacy concerns, because those have often been noted as brief summary statements in some past "intent to implement" emails.

Re: enabling off-main-thread animations on nightly/aurora

\o/ Hooray! This one took a lot of effort from many people across the Rendering teams. Super-Happy to see it land. --Jet On Tuesday, March 31, 2015, L. David Baron wrote: > I just landed (on mozilla-inbound) a patch for > https://bugzilla.mozilla.org/show_bug.cgi?id=980770 that enables > off-ma

enabling off-main-thread animations on nightly/aurora

I just landed (on mozilla-inbound) a patch for https://bugzilla.mozilla.org/show_bug.cgi?id=980770 that enables off-main-thread (OMT) animations on nightly and aurora. This feature has previously been enabled on Firefox OS since Firefox OS 1.0, but until now it has been disabled elsewhere. Off-ma

Re: PSA: nsFrameList now supports range-based for loop

On 03/31/2015 02:59 PM, Xidorn Quan wrote: > I've landed bug 1143513 > which enables using > range-based for loop on nsFrameList. Now, when you want to iterate > nsFrameList, you no longer need nsFrameList::Enumerator. Just write: > > for (nsI

Re: [meta] "Intent to implement" - captured some docs on wikimo

Ah, sorry, I misunderstood the intent of the wiki page. I retract my concern. / Jonas On Wed, Apr 1, 2015 at 12:41 AM, Tantek Çelik wrote: > Having pages go out of date can certainly be a challenge, hence why > this wiki page is descriptive (citing historical examples and other > external resour

Re: PSA: moz_malloc, moz_realloc, moz_calloc and moz_free are no more

Mike Hommey wrote: 1. if you look for it, you'll find cases of one family used for allocation and another for deallocation, for possibly close to all combinations of families (NS_Alloc, nsMemory, moz_malloc, malloc, new). It used to be that you didn't have to look very hard. (At one

Re: SpiderMonkey and XPConnect style changing from |T *p| to |T* p|

On 3/30/15 6:08 PM, Kan-Ru Chen (陳侃如) wrote: >>Is there an hg or git equivalent to Perforce's "Time-Lapse View" tool? It >>shows a global view of a file's blame history and you can visually "scrub" >>through the blame history. >> > >You mean like git log -p FILE? I'm sure there are fancier gra

Re: [meta] "Intent to implement" - captured some docs on wikimo

Having pages go out of date can certainly be a challenge, hence why this wiki page is descriptive (citing historical examples and other external resources), rather than prescriptive. No additional risk of becoming out of date beyond that from already existing pages. It's a general good practice to

Re: [meta] "Intent to implement" - captured some docs on wikimo

Will someone be maintaining this page? I'm worried that having an out-of-date page might create more confusion than information. / Jonas On Tue, Mar 31, 2015 at 3:58 AM, Tantek Çelik wrote: > Having followed the "Intent to implement" emails for a while, and > noticing that there was already an e

PSA: nsFrameList now supports range-based for loop

I've landed bug 1143513 which enables using range-based for loop on nsFrameList. Now, when you want to iterate nsFrameList, you no longer need nsFrameList::Enumerator. Just write: for (nsIFrame* frame : mFrames) { } Also, with the reverse ite

Re: PSA: moz_malloc, moz_realloc, moz_calloc and moz_free are no more

On Tue, Mar 31, 2015 at 09:43:39AM -0700, Kyle Huey wrote: > I assume that means that we have abandoned the plan to eventually make > malloc infallible? I think we should just use operator new more. We're writing C++ code after all. Mike ___ dev-platfor

Re: DevTools and Intent to Implement process

Excellent thread! Yes to more Dev Tools!!! Feel free to add a dev tooling section to the e-mail templates we use for "Intent to Implement" and "Intent to Ship" linked here: https://wiki.mozilla.org/Intent_to_implement We've started implementing the Web Animations API [1] with very early collabora

DevTools and Intent to Implement process

DevTools would like to get involved earlier in the implementation process for new platform features. In particular, we'd like to head towards a world where: 1. Platform features are architected in such a way from the start that adding debugging / instrumentation is (relatively) easy 2. DevTools f

MemShrink Meeting - Today, 31 Mar 2015 at 1:00pm PDT

The next Memshrink meeting begins in 1 hour and is brought to you by a slimmer JS BaseShape: https://bugzilla.mozilla.org/show_bug.cgi?id=1143256 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Prioritize unprioritized MemShrink bugs. * Discuss ho

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

On 31/03/15 02:31 PM, Gregory Szorc wrote: On Tue, Mar 31, 2015 at 10:44 AM, Andrew Halberstadt < ahalberst...@mozilla.com> wrote: Not yet, you still need to run the two suites separately. But we are working towards that. Eventually ./mach test will be able to not only run tags across suites, b

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

On Tue, Mar 31, 2015 at 10:44 AM, Andrew Halberstadt < ahalberst...@mozilla.com> wrote: > Not yet, you still need to run the two suites separately. But we are > working towards that. Eventually ./mach test will be able to not only run > tags across suites, but run directories across suites and aut

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

The main problem is that the current syntax is very inflexible. And tags are just one of many things we want to make easier when pushing to try (think of things like running directories or individual tests and all the debug options like --run-until-failure). A try syntax that knows how to handl

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

Is there any reason we couldn't put it in the try syntax instead? On Tue, Mar 31, 2015 at 10:39 AM, Andrew Halberstadt < ahalberst...@mozilla.com> wrote: > It's technically already possible by modifying the in-tree mozharness > configs here: > https://dxr.mozilla.org/mozilla-central/source/testi

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

I filed bug 1149670 for the mach try feature. On Tue, Mar 31, 2015 at 10:39 AM, Andrew Halberstadt < ahalberst...@mozilla.com> wrote: > It's technically already possible by modifying the in-tree mozharness > configs here: > https://dxr.mozilla.org/mozilla-central/source/testing/config/mozharness

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

Not yet, you still need to run the two suites separately. But we are working towards that. Eventually ./mach test will be able to not only run tags across suites, but run directories across suites and auto-determine which suite a test path belongs to. In other words, ./mach test will become the

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

It's technically already possible by modifying the in-tree mozharness configs here: https://dxr.mozilla.org/mozilla-central/source/testing/config/mozharness However it's not easy to figure out what needs to be modified to get the desired results. Some sort of |mach try| like command is going to

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

This sounds awesome! Is there an estimate of when we'll be able to use it for try pushes? On Tue, Mar 31, 2015 at 9:30 AM, Andrew Halberstadt < ahalberst...@mozilla.com> wrote: > As of bug 987360, you can now run all tests with a given tag for mochitest > (and variants), xpcshell and marionette b

Re: It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

On Tue, Mar 31, 2015 at 9:30 AM, Andrew Halberstadt < ahalberst...@mozilla.com> wrote: > > ​For example, we may implement a way to run all tests with a given tag > across multiple different suites. > > ​Does this mean that I can't do `./mach​ test --tag foobar` to run both xpcshell and mochitests

Re: PSA: moz_malloc, moz_realloc, moz_calloc and moz_free are no more

I assume that means that we have abandoned the plan to eventually make malloc infallible? - Kyle On Mon, Mar 30, 2015 at 10:59 PM, Mike Hommey wrote: > Hi, > > In the next few weeks, there is going to be a reduction in the number of > our memory allocator wrappers/functions, for essentially the

It is now possible to apply arbitrary tags to tests/manifests and run all tests with a given tag

As of bug 987360, you can now run all tests with a given tag for mochitest (and variants), xpcshell and marionette based harnesses. Tags can be applied to either individual tests, or the DEFAULT section in manifests. Tests can have multiple tags, in which case they should be comma delimited. To

Re: Changes to web-platform-tests

> ./mach testing/web-platform/tests/dom/historical.html > > It is also possible to use the path of the test relative to the server i.e. > > ./mach dom/historical.html Sorry, you still need the command name i.e. ./mach web-platform-tests [whatever] It isn't quite that magical yet :) _

Changes to web-platform-tests

This is just an update to make sure everyone is aware of recent improvements to the web-platform-tests, which should improve the UX for gecko hackers and make them suitable for more testing situations. == Summary == * Now possible to set per-test prefs so experimental features can be tested. * I

Re: SpiderMonkey and XPConnect style changing from |T *p| to |T* p|

On Mon, Mar 30, 2015 at 11:01:28AM -0700, Bobby Holley wrote: > On Mon, Mar 30, 2015 at 10:54 AM, Chris Peterson > wrote: > > > On 3/29/15 3:35 PM, smaug wrote: > > > >> Having the one commit in the blame doesn't really matter. Often one > >> needs to go to the first commit of the code anyway. >