Re: [RFC] We deserve better than runtime warnings
I wasn't aware that we could whitelist an individual NS_ASSERTION. How do we do that? On 20/11/14 17:24, Boris Zbarsky wrote: This sounds lovely. Note that in C++ for some of our test suites we already have this with NS_ASSERTION and for all test suites we have it with MOZ_ASSERT. Assuming, of course, that the test suite is run in debug builds... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] We deserve better than runtime warnings
I believe that we can provide something less fragile than that. On 20/11/14 17:56, Boris Zbarsky wrote: Ah, we can't. We can whitelist the number of assertions in a mochitest (or a number range if the number is not quite stable), but not the text of the assertion. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] We deserve better than runtime warnings
On 20/11/14 17:56, Boris Zbarsky wrote: Ah, we can't. We can whitelist the number of assertions in a mochitest (or a number range if the number is not quite stable), but not the text of the assertion. On Thursday 2014-11-20 18:05 +0100, David Rajchenbach-Teller wrote: I believe that we can provide something less fragile than that. It's not all that fragile, since most tests don't have known assertions, so in that vast majority of tests, we have test coverage of regressions of assertion counts. This covers reftests, crashtests, and all mochitests except for mochitest-browser-chrome (bug 847275 covers doing it there). (We should probably make an attempt to go through the tests that have assertion count ranges including 0, since nothing catches when those assertions are fixed, and we're missing the test coverage there.) -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
How to use Components.utils.import('resource://gre/modules/commonjs/toolkit/loader.js'); to getting require?
I want to use require in normal XPCOM components. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] We deserve better than runtime warnings
L. David Baron writes: On 20/11/14 17:56, Boris Zbarsky wrote: Ah, we can't. We can whitelist the number of assertions in a mochitest (or a number range if the number is not quite stable), but not the text of the assertion. On Thursday 2014-11-20 18:05 +0100, David Rajchenbach-Teller wrote: I believe that we can provide something less fragile than that. It's not all that fragile, since most tests don't have known assertions, so in that vast majority of tests, we have test coverage of regressions of assertion counts. This covers reftests, crashtests, and all mochitests except for mochitest-browser-chrome (bug 847275 covers doing it there). runcppunittests.py, runxpcshelltests.py, and rungtests.py use XPCOM_DEBUG_BREAK=stack-and-abort so we should have coverage there too. When web-platform-tests run with debug builds, we can do the same there because known crashes can be annotated in those tests. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: [RFC] We deserve better than runtime warnings
There is a priority list of best to worst something like this: 1. Types 2. Compile time assertions 3. Unit tests 4. Fatal run time assertions 5. Non-fatal runtime assertions 6. Documentation This is the order in which you are most likely to quickly find a problem. Obviously 1 and 2 don't apply to Javascript although static analysis could be the equivalent. Anthony On 21/11/14 05:51, David Rajchenbach-Teller wrote: I wasn't aware that we could whitelist an individual NS_ASSERTION. How do we do that? On 20/11/14 17:24, Boris Zbarsky wrote: This sounds lovely. Note that in C++ for some of our test suites we already have this with NS_ASSERTION and for all test suites we have it with MOZ_ASSERT. Assuming, of course, that the test suite is run in debug builds... -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
W3C Proposed Recommendation: Indexed DB
W3C recently published the following proposed recommendation (the stage before W3C's final stage, Recommendation): http://www.w3.org/TR/IndexedDB/ Indexed Database API There's a call for review to W3C member companies (of which Mozilla is one) open until December 18. If there are comments you think Mozilla should send as part of the review, or if you think Mozilla should voice support or opposition to the specification, please say so in this thread. (I'd note, however, that there have been many previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) Given that Mozilla implements this and uses it extensively (e.g., in Firefox OS), I intend to vote in favor without comments unless I hear otherwise. -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
What's the difference do_CreateInstance do_GetService
I am looking for docs about this ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: What's the difference do_CreateInstance do_GetService
On 11/21/14, 1:17 AM, Yonggang Luo wrote: I am looking for docs about this do_CreateInstance returns a new object every time. do_GetService creates one object and caches it, then keeps returning the cached object. In practice, for any given class you'd only use one or the other, depending on whether the class is meant to be a singleton or not. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
