PSA: moz_malloc, moz_realloc, moz_calloc and moz_free are no more
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 following reasons: - we have too many of them, - developers rarely know which one to use, which results in: - developers often make mistakes[1] This started today with the landing of bug 1138293, which effectively removed moz_malloc, moz_realloc, moz_calloc and moz_free. They were replaced, respectively, with malloc, realloc, calloc and free, because that works™. If you have pending patches that use moz_malloc, moz_realloc, moz_calloc, moz_free, you can just remove the moz_ prefix. The infallible moz_xmalloc, moz_xrealloc and moz_xcalloc still do exist, and memory allocated with them can be freed with free. With that being said, please refrain from using any of the functions mentioned above. Please prefer the C++y new and delete. new is infallible by default (equivalent to moz_xmalloc). If you need an equivalent to moz_malloc, use fallible new instead: new (fallible) Foo() Please note that this shouldn't make uplifting harder. Platform patches using malloc/free/new/delete should apply and work just fine on beta, aurora and esr (with a few exceptions ; if you uplift something from mfbt/mozglue that uses the memory allocator, please check with me). Cheers, Mike 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). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 cpeter...@mozilla.com 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. 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 graphic ways to visualize it, but that's the way I usually scrub my way back through restyles etc. I've been finding git log -L works pretty well. Trev ___ 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: PSA: nsFrameList now supports range-based for loop
On 03/31/2015 02:59 PM, Xidorn Quan wrote:
I've landed bug 1143513
https://bugzilla.mozilla.org/show_bug.cgi?id=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) { }
This is awesome! Goodbye to extra e.get() boilerplate.
~Daniel
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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-main-thread animations means that we run animations of some CSS properties (currently only opacity and transform) on the compositor thread, and stop doing style updates on the main thread. Running the updates on the compositor thread makes the animations run more smoothly (since their smoothness is no longer dependent on other things not hogging the main thread), and not doing the style updates on the main thread reduces the amount of work that we do (rather than increasing it). Depending on merge timing, and presuming that the change isn't backed out, this might hit nightly either tomorrow (April 1) or Thursday (April 2). Regressions from enabling it should be made to block bug 980770. If you want to test if something is a regression from it, toggle the pref layers.offmainthreadcomposition.async-animations. (Reloading the page is probably needed for it to take effect fully, although it shouldn't require a restart, unless it's a bug in the Firefox UI.) Since this is the beginning of the six-week release cycle, I'm hoping that we'll be able to flip the pref unconditionally by the end of this cycle and let it ride the trains to release. However, it's currently enabled only for nightly and aurora. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 tan...@cs.stanford.edu 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 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 write wiki-pages in such a future-defensive way. I'll also add a note about any questions about intent to ... should go to dev-platform to provide direction should anything actually go out of date and someone is potentially confused. Thanks, Tantek On Tue, Mar 31, 2015 at 3:10 PM, Jonas Sicking jo...@sicking.cc wrote: 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 tan...@cs.stanford.edu wrote: Having followed the Intent to implement emails for a while, and noticing that there was already an email template for it on wikimo: https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement I went ahead and wrote up a page about this practice, along with links to Blink/MS equivalents: https://wiki.mozilla.org/Intent_to_implement Hopefully others find this useful. Feedback and as usual, direct edits/contribution to the page welcome and encouraged. Thanks, Tantek ___ 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
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. * It is possible to check in test changes directly to mozilla-inbound and have them upstreamed when we next sync. * The command line behaviour is more compatible with mochitest. In particular individual tests can now be run using positional arguments containing paths to the test files. * The runner will now pause before closing the browser if only a single test is run. * js stack traces are reported when an assert fails a test, making debugging easier. * Reftest semantics have been aligned with the conventions of the CSS testsuite. == Introduction == web-platform-tests is a W3C-coordinated attempt to build a cross-browser testsuite for the web-platform stack. Writing tests in a way that allows them to be run in all browsers gives us confidence that we are shipping software that is compatible with other implementations, and that later implementations will be compatible with us. This in turn gives authors confidence that they can actually rely on the web platform to deliver on the promise of working across browsers and devices without needing extra layers of abstraction to paper over the gaps we left. It is possible to run the full web-platform-tests suite in gecko with |mach web-platform-tests| and these tests are run on buildbot for desktop opt builds. A subset, corresponding to the implemented features, of the tests are also run on CI by Servo. Given these advantages you should give serious consideration to writing web-platform-tests in place of Mozilla-only tests for platform development. == Recent Improvements == === Setting Prefs == It's now possible to set per-test preferences. In order to do this, the test must have a corresponding ini file (also used for expectation data). For example a test in /testing/web-platform/tests/example/example-test.html would have an ini file in /testing/web-platform/meta/example/example-test.html.ini. To set a pref use a key with name prefs with a value that's a list of the form [pref.name:pref value]. For example if the above test needs the dom.example pref set to true, and the dom.example.value pref set to 5 it would have an ini file like: [example-test.html] type: testharness prefs: [dom.example:true, dom.example.value:5] === Upstreaming Tests === The script used to sync changes from upstream has grown the ability to push changes made in the Mozilla tree upstream as part of the sync process. Therefore it should be possible to work on web-platform-tests in your Mozilla tree just like other test types, and have them upstreamed once they reach inbound. There are a couple of things to be aware of: * If you add new tests or change metadata (particularly timeouts) of existing tests the manifest file needs to be regenerated. You could do this by hand, but it is recommended to use |mach web-platform-tests --manifest-update| the first time after adding the tests. * With great power comes great responsibility. If we start upstreaming tests that depend on Mozilla-specific behaviour or are poorly written people won't be enthused about continuing with the system treating r+ in bugzilla as sufficient review for landing upstream. If possible test that your tests at least behave sensibly in other browsers. I am always happy to give feedback on tests for style and harness usage. Typically syncs happen about once a week, although this process still needs to be manually initiated. === Command Line Behaviour === |mach web-platform-tests| now works more like |mach mochitest| in its command line behaviour. In particular to run the test in testing/web-platform/tests/dom/historical.html you can now write ./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 which is shorter but won't have command line completion :) === Runner Pause === The test runner will now pause until the browser closes if only a single test file is run. In this case in-page output will not be surpressed as it is for normal runs. It's also possible to pause after any test that gets an unexpected result with --pause-on-unexpected. === js stacks === testharness.js now provides nicely formatted js stacks whenever an assert_*() causes a test to fail. Hopefully this helps debugging, particularly in the face of tests that don't provide lots of annotations of what's being asserted. === RefTest changes === web-plaform-tests reftests have now been aligned with CSSWG reftests in terms of the way that references, particularly multiple references, are specified. This means that wptrunner can run the CSS testsuite as well (Servo plans to take advantage of this fact). == Future Work == Depends on
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 :) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 m...@glandium.org 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 following reasons: - we have too many of them, - developers rarely know which one to use, which results in: - developers often make mistakes[1] This started today with the landing of bug 1138293, which effectively removed moz_malloc, moz_realloc, moz_calloc and moz_free. They were replaced, respectively, with malloc, realloc, calloc and free, because that works™. If you have pending patches that use moz_malloc, moz_realloc, moz_calloc, moz_free, you can just remove the moz_ prefix. The infallible moz_xmalloc, moz_xrealloc and moz_xcalloc still do exist, and memory allocated with them can be freed with free. With that being said, please refrain from using any of the functions mentioned above. Please prefer the C++y new and delete. new is infallible by default (equivalent to moz_xmalloc). If you need an equivalent to moz_malloc, use fallible new instead: new (fallible) Foo() Please note that this shouldn't make uplifting harder. Platform patches using malloc/free/new/delete should apply and work just fine on beta, aurora and esr (with a few exceptions ; if you uplift something from mfbt/mozglue that uses the memory allocator, please check with me). Cheers, Mike 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). ___ 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
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 run all tests with a given tag, pass in --tag tag name to the mach command. For example, let's say we want to group all mochitest-plain tests related to canvas together. First we'd add a 'canvas' tag to the DEFAULT section in https://dxr.mozilla.org/mozilla-central/source/dom/canvas/test/mochitest.ini [DEFAULT] tags = canvas We notice there is also a canvas related test under dom/media, namely: https://dxr.mozilla.org/mozilla-central/source/dom/media/test/mochitest.ini#541 Let's pretend it is already tagged with the 'media' tag, but that's ok, we can add a second tag no problem: [test_video_to_canvas.html] tags = media,canvas Repeat above for any other tests or manifests scattered in the tree that are related to canvas. Now we can run all mochitest-plain tests with: ./mach mochitest-plain --tag canvas You can also run the union of two tags by specifying --tag more than once (though the intersection of two tags is not supported): ./mach mochitest-plain --tag canvas --tag media So far the xpcshell (./mach xpcshell-test --tag name) and marionette (./mach marionette-test --tag name) commands are also supported. Reftest is not supported as it has its own special manifest format. Applying tags to tests will not affect automation or other people's tags. So each organization or team should feel free to use tags in whatever creative ways they see fit. Eventually, we'll start using tags as a foundation for some more advanced features and analysis. For example, we may implement a way to run all tests with a given tag across multiple different suites. If you have any questions or things aren't working, please let me know! Cheers, Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 tagged with foobar yet? Do I have to do `./mach xpcshell-test --tag foobar` and `./mach mochitest-whatever --tag foobar` separately? Anyways, this looks like a very cool capability. Looking forward to using it! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 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 run all tests with a given tag, pass in --tag tag name to the mach command. For example, let's say we want to group all mochitest-plain tests related to canvas together. First we'd add a 'canvas' tag to the DEFAULT section in https://dxr.mozilla.org/mozilla-central/source/dom/ canvas/test/mochitest.ini [DEFAULT] tags = canvas We notice there is also a canvas related test under dom/media, namely: https://dxr.mozilla.org/mozilla-central/source/dom/ media/test/mochitest.ini#541 Let's pretend it is already tagged with the 'media' tag, but that's ok, we can add a second tag no problem: [test_video_to_canvas.html] tags = media,canvas Repeat above for any other tests or manifests scattered in the tree that are related to canvas. Now we can run all mochitest-plain tests with: ./mach mochitest-plain --tag canvas You can also run the union of two tags by specifying --tag more than once (though the intersection of two tags is not supported): ./mach mochitest-plain --tag canvas --tag media So far the xpcshell (./mach xpcshell-test --tag name) and marionette (./mach marionette-test --tag name) commands are also supported. Reftest is not supported as it has its own special manifest format. Applying tags to tests will not affect automation or other people's tags. So each organization or team should feel free to use tags in whatever creative ways they see fit. Eventually, we'll start using tags as a foundation for some more advanced features and analysis. For example, we may implement a way to run all tests with a given tag across multiple different suites. If you have any questions or things aren't working, please let me know! Cheers, Andrew ___ 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: 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, but run directories across suites and auto-determine which suite a test path belongs to. In other words, ./mach test will become the norm, and running a specific test harness directly will become the edge case. There is some work around this specifically slotted in our Q2 goals. The ability to `mach test dir` and have it run multiple suites is already supported. https://hg.mozilla.org/mozilla-central/file/0aa30282f496/testing/mach_commands.py#l166 Cool, in that case getting it to run tags across suites that support --tag shouldn't be terribly difficult. I filed bug 1149695. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 how we measure progress. * Discuss approaches to getting more data. Meeting details: * Tue, 31 Mar 2015, 1:00 PM PDT * http://arewemeetingyet.com/Los%20Angeles/2015-03-31/13:00/MemShrink%20Meeting * Vidyo: Memshrink * Dial-in Info: - In office or soft phone: extension 92 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92 - Toll-free: 800-707-2533 then password 369 - Conference num 98802 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 handle all those cases will be just as convoluted as editing the mozharness configs. Also, how things are currently set up, we'd need to get the try syntax to somehow modify how buildbot runs tests. This would be difficult if not impossible. Taskcluster may make this easier, but I wouldn't count on it.. On 31/03/15 02:12 PM, Bobby Holley wrote: 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/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 be worked on in Q2 to make pushing various test configurations to try easier, I'm not 100% sure how it will be implemented yet though. In the meantime, if you get stuck trying to modify the mozharness configs, let me know and I can come up with an example patch. -Andrew On 31/03/15 01:06 PM, Bobby Holley wrote: 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 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 run all tests with a given tag, pass in --tag tag name to the mach command. For example, let's say we want to group all mochitest-plain tests related to canvas together. First we'd add a 'canvas' tag to the DEFAULT section in https://dxr.mozilla.org/mozilla-central/source/dom/canvas/test/mochitest.ini [DEFAULT] tags = canvas We notice there is also a canvas related test under dom/media, namely: https://dxr.mozilla.org/mozilla-central/source/dom/media/test/mochitest.ini#541 Let's pretend it is already tagged with the 'media' tag, but that's ok, we can add a second tag no problem: [test_video_to_canvas.html] tags = media,canvas Repeat above for any other tests or manifests scattered in the tree that are related to canvas. Now we can run all mochitest-plain tests with: ./mach mochitest-plain --tag canvas You can also run the union of two tags by specifying --tag more than once (though the intersection of two tags is not supported): ./mach mochitest-plain --tag canvas --tag media So far the xpcshell (./mach xpcshell-test --tag name) and marionette (./mach marionette-test --tag name) commands are also supported. Reftest is not supported as it has its own special manifest format. Applying tags to tests will not affect automation or other people's tags. So each organization or team should feel free to use tags in whatever creative ways they see fit. Eventually, we'll start using tags as a foundation for some more advanced features and analysis. For example, we may implement a way to run all tests with a given tag across multiple different suites. If you have any questions or things aren't working, please let me know! Cheers, Andrew ___ 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: 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 be worked on in Q2 to make pushing various test configurations to try easier, I'm not 100% sure how it will be implemented yet though. In the meantime, if you get stuck trying to modify the mozharness configs, let me know and I can come up with an example patch. -Andrew On 31/03/15 01:06 PM, Bobby Holley wrote: 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 mailto: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 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 run all tests with a given tag, pass in --tag tag name to the mach command. For example, let's say we want to group all mochitest-plain tests related to canvas together. First we'd add a 'canvas' tag to the DEFAULT section in https://dxr.mozilla.org/mozilla-central/source/dom/canvas/test/mochitest.ini [DEFAULT] tags = canvas We notice there is also a canvas related test under dom/media, namely: https://dxr.mozilla.org/mozilla-central/source/dom/media/test/mochitest.ini#541 Let's pretend it is already tagged with the 'media' tag, but that's ok, we can add a second tag no problem: [test_video_to_canvas.html] tags = media,canvas Repeat above for any other tests or manifests scattered in the tree that are related to canvas. Now we can run all mochitest-plain tests with: ./mach mochitest-plain --tag canvas You can also run the union of two tags by specifying --tag more than once (though the intersection of two tags is not supported): ./mach mochitest-plain --tag canvas --tag media So far the xpcshell (./mach xpcshell-test --tag name) and marionette (./mach marionette-test --tag name) commands are also supported. Reftest is not supported as it has its own special manifest format. Applying tags to tests will not affect automation or other people's tags. So each organization or team should feel free to use tags in whatever creative ways they see fit. Eventually, we'll start using tags as a foundation for some more advanced features and analysis. For example, we may implement a way to run all tests with a given tag across multiple different suites. If you have any questions or things aren't working, please let me know! Cheers, Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org mailto: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: 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 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 be worked on in Q2 to make pushing various test configurations to try easier, I'm not 100% sure how it will be implemented yet though. In the meantime, if you get stuck trying to modify the mozharness configs, let me know and I can come up with an example patch. -Andrew On 31/03/15 01:06 PM, Bobby Holley wrote: 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 mailto: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 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 run all tests with a given tag, pass in --tag tag name to the mach command. For example, let's say we want to group all mochitest-plain tests related to canvas together. First we'd add a 'canvas' tag to the DEFAULT section in https://dxr.mozilla.org/mozilla-central/source/dom/ canvas/test/mochitest.ini [DEFAULT] tags = canvas We notice there is also a canvas related test under dom/media, namely: https://dxr.mozilla.org/mozilla-central/source/dom/ media/test/mochitest.ini#541 Let's pretend it is already tagged with the 'media' tag, but that's ok, we can add a second tag no problem: [test_video_to_canvas.html] tags = media,canvas Repeat above for any other tests or manifests scattered in the tree that are related to canvas. Now we can run all mochitest-plain tests with: ./mach mochitest-plain --tag canvas You can also run the union of two tags by specifying --tag more than once (though the intersection of two tags is not supported): ./mach mochitest-plain --tag canvas --tag media So far the xpcshell (./mach xpcshell-test --tag name) and marionette (./mach marionette-test --tag name) commands are also supported. Reftest is not supported as it has its own special manifest format. Applying tags to tests will not affect automation or other people's tags. So each organization or team should feel free to use tags in whatever creative ways they see fit. Eventually, we'll start using tags as a foundation for some more advanced features and analysis. For example, we may implement a way to run all tests with a given tag across multiple different suites. If you have any questions or things aren't working, please let me know! Cheers, Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org mailto: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
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 norm, and running a specific test harness directly will become the edge case. There is some work around this specifically slotted in our Q2 goals. -Andrew On 31/03/15 12:52 PM, Nick Fitzgerald wrote: 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 tagged with foobar yet? Do I have to do `./mach xpcshell-test --tag foobar` and `./mach mochitest-whatever --tag foobar` separately? Anyways, this looks like a very cool capability. Looking forward to using it! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 collaboration with the Dev Tools team and have seen very promising results. Is that a model we can continue to follow or modify to suit? --Jet [1] https://bugzilla.mozilla.org/show_bug.cgi?id=998245 On Tue, Mar 31, 2015 at 1:07 PM, J. Ryan Stinnett jry...@gmail.com wrote: 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 for a feature are discussed early on in a bug that interested parties can follow while the platform feature is being implemented By working with the platform team as features are developed (instead of afterwards), we can discuss any debugging and instrumentation APIs our tools may need, give feedback as we start to build tools, etc. We're hoping this will help us to release tools closer to the time frame that the platform features are available. Tools for new features should increase adoption of those features, as they make it easier for web developers to explore and understand them. The DevTools team has recently discussed[1] this, and we thought becoming more integrated in the platform Intent to Implement process would be a good thing to do. Specifically, we'd like to have a DevTools line in the intent to implement template[2] which would link to a bug on building tools for the feature for further discussion. Thoughts? (Replies to dev-platform.) [1]: https://groups.google.com/forum/#!topic/mozilla.dev.developer-tools/fZOxb3t0Npk/discussion [2]: https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement - Ryan ___ 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: 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-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 point I instrumented NS_Alloc(=nsMemory::Alloc), PR_Malloc, malloc and new, and filed several bugs on the mismatches I found, which means that Gecko 2 wasn't too bad in this respect.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
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 tan...@cs.stanford.edu wrote: Having followed the Intent to implement emails for a while, and noticing that there was already an email template for it on wikimo: https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement I went ahead and wrote up a page about this practice, along with links to Blink/MS equivalents: https://wiki.mozilla.org/Intent_to_implement Hopefully others find this useful. Feedback and as usual, direct edits/contribution to the page welcome and encouraged. Thanks, Tantek ___ 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
PSA: nsFrameList now supports range-based for loop
I've landed bug 1143513
https://bugzilla.mozilla.org/show_bug.cgi?id=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 iterator landed (bug 1127044
https://bugzilla.mozilla.org/show_bug.cgi?id=1127044) before, if you need
to reversely iterate the frame list, the Reversed function is also usable
here:
for (nsIFrame* frame : Reversed(mFrames)) { }
- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
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 write wiki-pages in such a future-defensive way. I'll also add a note about any questions about intent to ... should go to dev-platform to provide direction should anything actually go out of date and someone is potentially confused. Thanks, Tantek On Tue, Mar 31, 2015 at 3:10 PM, Jonas Sicking jo...@sicking.cc wrote: 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 tan...@cs.stanford.edu wrote: Having followed the Intent to implement emails for a while, and noticing that there was already an email template for it on wikimo: https://wiki.mozilla.org/WebAPI/ExposureGuidelines#Intent_to_Implement I went ahead and wrote up a page about this practice, along with links to Blink/MS equivalents: https://wiki.mozilla.org/Intent_to_implement Hopefully others find this useful. Feedback and as usual, direct edits/contribution to the page welcome and encouraged. Thanks, Tantek ___ 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: 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 graphic ways to visualize it, but that's the way I usually scrub my way back through restyles etc. I think Chris might want to follow the history of a particular line, that is usually what we use flame for. I find |git gui blame file| very useful. Just to clarify what I meant by visually scrub through blame history, here is a video demo of Perforce's GUI: https://youtu.be/r1Zk5IaHZBQ?t=1m4s chris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
