Re: Shutting off leak tests?
On Monday, July 15, 2013 3:09:05 PM UTC-7, Kyle Huey wrote: FWIW now that we have AWSY and we don't really care about shutdown leaks specifically I don't think these tests are very useful to memshrink anymore. AWSY is not a replacement for shutdown-leak testing. It's limited to code exercised by TP5. Small leaks are masked by normal variation in memory use. Fuzzing with partial* leak checks frequently catches regressions missed by AWSY. MemShrink does care about these bugs. I imagine the same would be true for full** leak checks if Firefox passed enough of its own tests to be fuzzable. https://bugzil.la/ALL+reporter:jruderman+kw:mlk * trace-refcnt ** trace-malloc, LSan, or valgrind (which has modes for distinguishing still-reachable memory from totally leaked memory) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
i2space provides Best travel services on Travel Portal India
Travel Portal India – i2space.com is a leading online travel portal in India. We provide Travel portal Development to travel consultation, searching for trip plans, seat layout, providing customized tour packages, booking tickets, etc. For more details please visit our website http://www.i2space.com/onlinetravelportal.html or contact us at 9052266440 / 9704536531 Contact Person: Bhargava Mobile no. 9052266440 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using C++0x auto
On Tue, Jul 16, 2013 at 04:17:50PM +0900, Mike Hommey wrote: On Sat, Jul 13, 2013 at 01:15:31PM -0700, Kyle Huey wrote: We've dropped support for versions of MSVC prior to 2010, and we're requiring at least GCC 4.4. According to [0] that means we should be able to use *auto*. Anybody know any reasons why we can't start using it? Filed bug 894242. (double 42!) This almost stuck, but B2G desktop builds are, guess what, using gcc 4.4, and a bug was already on file to upgrade that (bug 770625). Hopefully this will go forward now that there are patches. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutting off leak tests?
On 7/17/2013 2:05 AM, Jesse Ruderman wrote: AWSY is not a replacement for shutdown-leak testing. It's limited to code exercised by TP5. Small leaks are masked by normal variation in memory use. Note, though, that we still run almost all of our test suites on debug builds with leak checking enabled, so we catch shutdown leaks in all the Mochitest variants, reftest and crashtest. The actual leak test is much simpler, it just loads a few web pages and quits. The only valuable thing we're losing from shutting this off is tracemalloc coverage, which we don't have elsewhere. I don't have any evidence to show that anyone has actually looked at the tracemalloc data or done anything useful with it in recent history, though. Leaks discovered by tracemalloc don't make the test fail, so we're not measuring much there. -Ted ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Three RDFa-related W3C Proposed (Edited) Recommendations
I've only quickly glanced at those, and I haven't followed those discussions at all, I have to admit. Are there any practical consequences for gecko/firefox? It doesn't look like it would, in particular when looking at the reference implementations being all on top of html platforms. Axel On 7/17/13 1:12 AM, L. David Baron wrote: The W3C has released three RDFA-related documents, one proposed recommendation: HTML+RDFa 1.1: http://www.w3.org/TR/2013/PR-html-rdfa-20130625/ and two proposed edited recommendations (which contain only editorial changes): RDFa 1.1 Core: http://www.w3.org/TR/2013/PER-rdfa-core-20130625/ XHTML+RDFa 1.1 http://www.w3.org/TR/2013/PER-xhtml-rdfa-20130625/ There's a call for review to W3C member companies (of which Mozilla is one) open until Tuesday, July 23 (one week from today). 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.) There was one formal objection earlier in the process, whose history is documented in http://lists.w3.org/Archives/Public/public-rdfa-wg/2013Jan/0057.html -David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Three RDFa-related W3C Proposed (Edited) Recommendations
On 7/16/2013 7:12 PM, L. David Baron wrote: The W3C has released three RDFA-related documents, one proposed recommendation: HTML+RDFa 1.1: http://www.w3.org/TR/2013/PR-html-rdfa-20130625/ 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.) Reading through the spec, it appears that it doesn't substantively change HTML parsing behavior unless HTML+RDFa document conformance is required. As far as I know, we do not intend to implement this specification and therefore have no reason to comment on it. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposal: requiring build peer review for Makefile.in changes
Traditionally, it's been very difficult for the build peers to keep on top of changes in the build config because changes are occurring on bug components we don't follow, are touching files all over the tree, and because build peers aren't always asked for review. The potential for sneaking things past build peer review has resulted in a number of self-inflicted wounds, the Fennec build rules probably being the best example (the dependencies are all wrong and no-op builds take ~16s when they should take 1 or 2s). This history contributed to us implementing a more strict sandbox in moz.build files: take away as many footguns as possible and there will be less self-inflicted wounds. Unfortunately, the moz.build conversion isn't finished and it will drag on for a while. There will still be Makefile.in in the tree and that leaves the door open for new badness. I would like to reinforce the existing policy: *if you are changing a Makefile.in, please ask a build peer for review unless the change is just adding or removing to an existing list.* For the most part, people have been abiding by this policy. However, things are still creeping through. Unfortunately, some of them wouldn't get r+ from a build peer. Since new Makefile.in badness makes people's lives harder (especially when it makes the build slower), I would like to propose a more strict policy around Makefile.in changes: *if a non-list change in a Makefile.in isn't reviewed by a build peer, it doesn't land or gets backed out.* This could potentially be enforced with repository push hooks. I /think/ this proposal is supported by our module governance system since Makefile.in are the purview of the build config module. But I wanted to run the proposal by people to make sure it is generally well-received and there aren't any major concerns. Gregory ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal: requiring build peer review for Makefile.in changes
The flip side of this, of course, is that build peers need to ensure that they are not the long pole in reviews. But I presume you guys are prepared to turn around these additional reviews quickly, otherwise you wouldn't have asked for the extra load. On Wed, Jul 17, 2013 at 5:00 PM, Gregory Szorc g...@mozilla.com wrote: Traditionally, it's been very difficult for the build peers to keep on top of changes in the build config because changes are occurring on bug components we don't follow, are touching files all over the tree, and because build peers aren't always asked for review. The potential for sneaking things past build peer review has resulted in a number of self-inflicted wounds, the Fennec build rules probably being the best example (the dependencies are all wrong and no-op builds take ~16s when they should take 1 or 2s). This history contributed to us implementing a more strict sandbox in moz.build files: take away as many footguns as possible and there will be less self-inflicted wounds. Unfortunately, the moz.build conversion isn't finished and it will drag on for a while. There will still be Makefile.in in the tree and that leaves the door open for new badness. I would like to reinforce the existing policy: *if you are changing a Makefile.in, please ask a build peer for review unless the change is just adding or removing to an existing list.* For the most part, people have been abiding by this policy. However, things are still creeping through. Unfortunately, some of them wouldn't get r+ from a build peer. Since new Makefile.in badness makes people's lives harder (especially when it makes the build slower), I would like to propose a more strict policy around Makefile.in changes: *if a non-list change in a Makefile.in isn't reviewed by a build peer, it doesn't land or gets backed out.* This could potentially be enforced with repository push hooks. I /think/ this proposal is supported by our module governance system since Makefile.in are the purview of the build config module. But I wanted to run the proposal by people to make sure it is generally well-received and there aren't any major concerns. Gregory ___ 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
Reminder: in-tree mozconfigs are not for developers
Hi, As it seems there is a trend towards using in-tree mozconfigs for local developer builds, I think a reminder is in order: In-tree mozconfigs are for buildbot consumption. For Firefox desktop builds, a mozconfig should be unnecessary for most people, except if their compiler is not at a standard location. If that doesn't work for you, try running ./mach bootstrap at the root of the mozilla source tree. If that still doesn't build after that, please try asking on the #build irc channel or file a bug in the Core::Build Config component. For Firefox for Android builds, a mozconfig is necessary, but it only needs to contain the following: ac_add_options --enable-application=mobile/android ac_add_options --target=arm-linux-androideabi ac_add_options --with-android-ndk=/path/to/ndk ac_add_options --with-android-sdk=/path/to/sdk (the target varies for x86 android builds, and the addition of ac_add_options --with-arch=armv6 is required for armv6 builds) If the mozconfig above doesn't work for you, double check the instructions on https://wiki.mozilla.org/Mobile/Fennec/Android#Building_Fennec specifically, that you have all the build dependencies installed (eventually, this should make it into mach bootstrap, see bug 844838), and if that still doesn't work, please try asking on the #build irc channel or file a bug in the Core::Build Config component. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reminder: in-tree mozconfigs are not for developers
On Thu, Jul 18, 2013 at 10:51:10AM +0900, Mike Hommey wrote: Hi, As it seems there is a trend towards using in-tree mozconfigs for local developer builds, I think a reminder is in order: In-tree mozconfigs are for buildbot consumption. For Firefox desktop builds, a mozconfig should be unnecessary for most people, except if their compiler is not at a standard location. If that doesn't work for you, try running ./mach bootstrap at the root of the mozilla source tree. If that still doesn't build after that, please try asking on the #build irc channel or file a bug in the Core::Build Config component. For Firefox for Android builds, a mozconfig is necessary, but it only needs to contain the following: ac_add_options --enable-application=mobile/android ac_add_options --target=arm-linux-androideabi ac_add_options --with-android-ndk=/path/to/ndk ac_add_options --with-android-sdk=/path/to/sdk (the target varies for x86 android builds, and the addition of ac_add_options --with-arch=armv6 is required for armv6 builds) If the mozconfig above doesn't work for you, double check the instructions on https://wiki.mozilla.org/Mobile/Fennec/Android#Building_Fennec specifically, that you have all the build dependencies installed (eventually, this should make it into mach bootstrap, see bug 844838), and if that still doesn't work, please try asking on the #build irc channel or file a bug in the Core::Build Config component. As Boris noted on irc, there is room for flexibility. You may require ac_add_options --enable-debug, and you may want to use ac_add_options --with-ccache. There are a few other options you can use in a mozconfig, But the bottom-line is minimalistic mozconfigs should be enough for everyone, and in-tree mozconfigs should be left alone. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reminder: in-tree mozconfigs are not for developers
On Wed, Jul 17, 2013 at 6:51 PM, Mike Hommey m...@glandium.org wrote: Hi, As it seems there is a trend towards using in-tree mozconfigs for local developer builds, I think a reminder is in order: In-tree mozconfigs are for buildbot consumption. For Firefox desktop builds, a mozconfig should be unnecessary for most people, except if their compiler is not at a standard location. Did you mean should not be here? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Reminder: in-tree mozconfigs are not for developers
On Wed, Jul 17, 2013 at 10:29:01PM -0700, Dave Townsend wrote: On Wed, Jul 17, 2013 at 6:51 PM, Mike Hommey m...@glandium.org wrote: Hi, As it seems there is a trend towards using in-tree mozconfigs for local developer builds, I think a reminder is in order: In-tree mozconfigs are for buildbot consumption. For Firefox desktop builds, a mozconfig should be unnecessary for most people, except if their compiler is not at a standard location. Did you mean should not be here? should be unnecessary, or should not be necessary. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
