Re: Changes to JS components/JSMs
On Tue, Oct 30, 2012 at 8:02 PM, Blair McBride bmcbr...@mozilla.com wrote: Does this break the usage of the BackstagePass object? (the thing that Cu.import() returns). Not if the pref isn't set. If the pref is set I suspect it still returns an object with the relevant properties, but that object is no longer a BackstagePass. I haven't verified that though. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changes to JS components/JSMs
On Thu, Nov 1, 2012 at 10:00 AM, Kyle Huey m...@kylehuey.com wrote: Not if the pref isn't set. If the pref is set I suspect it still returns an object with the relevant properties, but that object is no longer a BackstagePass. I haven't verified that though. Will that break http://mxr.mozilla.org/mozilla-central/source/toolkit/addon-sdk/loader.js#11 or http://mxr.mozilla.org/mozilla-central/source/toolkit/addon-sdk/promise/core.js#10 ? Looks like the patch didn't update them... Gavin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for reorganizing test directories
At the last Tuesday meeting I foolishly agreed :-) to take charge of following up on this discussion and seeing if we can come to a decision. So, here goes: First, I want to try to pour some gasoline on the dying embers and suggest that perhaps we should totally rearrange everything. As a developer user of our testing systems, I always found it incredibly irritating that there were test directories sprinkled throughout the tree that got copied to the build dirs as part of the build process, with no clear mapping between the build path of the test, the source path of the test, and the path you had to pass to mochitests to actually run the test. I would prefer something like this: |-- tests/ |-- browser-chrome/ |-- topic1 (omit this level if there would be only one) |-- topic2 |-- [...] |-- chrome/ |-- crashtests/ |-- marionette/ |-- mochitests/ |-- reftests/ |-- xpcshell |-- [..]/ That way, when working with a given testing harness, you know where to find all the files for it (source, metadata, and tests), and can easily figure out how to work with specific tests and directories. This is approximately what SpiderMonkey uses, and it seems to be approximately what Chromium and WebKit use. This does seem to be about the transpose of what you asked for Henrik, but it makes sense to me, so I'm curious what you think. Dave ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PGO: another test + PGO topcrashes
I'm still thinking about PGO: 1. I did another test. I wanted to know the effect on games, so I played BananaBread and eyeballed modal fps. (If anyone knows of a more accurate way to measure fps in the game, let me know.) I got: opt 38 pgo 41 Similar magnitude to other domains. Super-unscientific test, though. 2. PGO-related topcrashes The reason I started studying PGO was that PGO-related topcrashes are really vexing for developers, and I wanted to be sure dealing with all that vexation was actually paying off. It seems that it is, but now I want to ask, can it vex less? The lifecycle of a PGO-related topcrash seems to be something like this: 1. Someone changes the code base in a way that exposes a bug in the PGO compiler system. 2. A topcrash gets noticed. 3. Developers look at the topcrash and conclude it is a PGO bug. 4. Developers patch code around the crash point by turning off optimizations locally, or randomly frobulating the code. 5. The topcrash goes away. I assume that some time after that: 6. Someone changes the code base in a way so that that site no longer triggers the compiler bug. The random change or deoptimization changes. What I'm getting at is that it seems like we are adding permanent gunk to the code base that only temporarily fixes problems. I can't be sure that's what's happening, but it seems plausible. Anyway, I am fairly sure we are currently playing whack-a-mole. (a) How about building Windows with a newer version of MSVC, say 2012? (What version are we using now, anyway? The build instructions page says 2010 is official, but a tbpl log showed Visual Studio 9.0 on the path.) Maybe they have fixed bugs in PGO. (b) Failing that, how about not fixing PGO bugs unless they are reproducible, on a trial basis? If my lifecycle theory is correct, then the total crash rate would stay roughly constant. And I assume that if the crash rate doesn't actually go up, that's OK. If it does, and especially if that can be shown to be due to an increasing number due to outstanding PGO bugs, that would show that we do benefit from fixing them. Dave ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PGO: another test + PGO topcrashes
On Fri, Nov 2, 2012 at 2:19 PM, Dave Mandelin dmande...@gmail.com wrote: (b) Failing that, how about not fixing PGO bugs unless they are reproducible, on a trial basis? If my lifecycle theory is correct, then the total crash rate would stay roughly constant. And I assume that if the crash rate doesn't actually go up, that's OK. If it does, and especially if that can be shown to be due to an increasing number due to outstanding PGO bugs, that would show that we do benefit from fixing them. Seems to me a good start would be to make a number of builds from regularly spaced points in the past, backing out all PGO fixes in all those builds, and examining the code to see if each PGO bug was present. Perhaps you could improve the results by weighting each bug according to its measured topcrash rate while it was present. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PGO: another test + PGO topcrashes
On 2012-11-01 9:19 PM, Dave Mandelin wrote: (a) How about building Windows with a newer version of MSVC, say 2012? (What version are we using now, anyway? The build instructions page says 2010 is official, but a tbpl log showed Visual Studio 9.0 on the path.) Maybe they have fixed bugs in PGO. We use 2010. We cannot use 2012 yet because its dynamically linked runtime libraries don't support Windows XP, which may come in a future update. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for reorganizing test directories
On Thursday, November 1, 2012 6:33:39 PM UTC-7, therealbr...@gmail.com wrote: On Thursday, November 1, 2012 5:47:57 PM UTC-7, Dave Mandelin wrote: At the last Tuesday meeting I foolishly agreed :-) to take charge of following up on this discussion and seeing if we can come to a decision. So, here goes: ... I would prefer something like this: |-- tests/ |-- browser-chrome/ |-- topic1 (omit this level if there would be only one) |-- topic2 |-- [...] |-- chrome/ |-- crashtests/ |-- marionette/ |-- mochitests/ |-- reftests/ |-- xpcshell |-- [..]/ ... This is approximately what SpiderMonkey uses, and it seems to be approximately what Chromium and WebKit use. How about js/src/tests and other *tests subdirectories? Do they get moved out to a remote top-level, where SpiderMonkey-only embedders will miss them? The tyranny of hierarchy never ends. Either we have subsidiarity for js and other modules, or not. If Gecko is one big module -- ok, I get it. But you need a principle for giving js its own tests while hoisting all others. It looks like V8 keeps JS tests in a separate directory, but JSC has them in common with WebKit, presumably since V8 promotes itself as an embeddable component while JSC I believe does not. I don't think it would affect SpiderMonkey development much to move the tests to a new home. They are designed to be independent of the source code and the path to the program being tested. So I wouldn't mind. Even for independent distribution purposes, it makes more sense to me to collect files into new places to prepare a distro than to do so as part of the per-compile testing process. This seems small potatoes either way, BTW. I've been through both approaches. Neither is obviously winning. Sure, it's not some grand thing. I just like things to be nicely organized. And I really did find mochitest paths a hassle and a (small) tax on development effort. Dave ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for reorganizing test directories
On Fri, Nov 2, 2012 at 2:53 PM, Dave Mandelin dmande...@gmail.com wrote: Sure, it's not some grand thing. I just like things to be nicely organized. And I really did find mochitest paths a hassle and a (small) tax on development effort. You could keep tests near the code and still have a predictable algorithm for mapping test paths. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for reorganizing test directories
On Thu, Nov 1, 2012 at 6:33 PM, therealbrendane...@gmail.com wrote: The tyranny of hierarchy never ends. Either we have subsidiarity for js and other modules, or not. If Gecko is one big module -- ok, I get it. But you need a principle for giving js its own tests while hoisting all others. Every component that can be distributed (built?) by itself gets its own tests/ directory? Are there others apart from Gecko and SpiderMonkey? Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
