Re: Proposal for reorganizing test directories
On 11/02/2012 01:47 AM, Dave Mandelin wrote: 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. This, at least, is easily solved: even today, you can run ./mach mochitest-plain foo/bar/test_baz.html and never again care about what happens in the build dir. (Yes, mach doesn't yet accept all options the python harness itself supports; patches welcome.) 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 seems to suggest moving tests as far away from the code they test as possible; I don't think that's a sensible thing to do. If I'm working on, say content/html/content/src/nsHTMLInputElement.cpp, the most relevant tests are easily found in content/html/content/test/forms/. I don't see what benefit it would bring to put them further away. HTH Ms2ger ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: PGO: another test + PGO topcrashes
On 11/1/2012 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. As Ehsan mentioned, we're blocked on switching to 2012 until they sort out XP support, but that should be in SP1 (which is usually a safe release to wait for anyway). I'd support switching to 2012SP1 when it is released. Microsoft has been pretty good about fixing compiler bugs when we submit them with test cases. It can be hard to get a useful reproducible testcase out of a PGO compiler bug, but we should probably try harder to do so so we have a chance of removing these workarounds in the future. -Ted ___ 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:24 AM, Gavin Sharp ga...@gavinsharp.com wrote: 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... It would if we turned this on for a product that uses Jetpack, but we don't currently have plans to do that. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for reorganizing test directories
On 2012-11-01 8:47 PM, Dave Mandelin wrote: |-- tests/ |-- browser-chrome/ |-- topic1 (omit this level if there would be only one) |-- topic2 |-- [...] |-- chrome/ |-- crashtests/ |-- marionette/ |-- mochitests/ |-- reftests/ |-- xpcshell |-- [..]/ I think the reason that this is a problem in the eyes of some people is that some of our test frameworks don't use manifests (for example, mochitests) and rely on make rules. If we fixed that problem, those who are interested in seeing all of the tests in the same directory can write their own tools to create whatever directory structure they need. But the benefits of moving the tests in the tree are questionable for people who work on specific areas of the code base, which I believe is the majority of Gecko hackers. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Changes to JS components/JSMs
On 11/2/12 4:42 PM, Kyle Huey wrote: On Thu, Nov 1, 2012 at 10:24 AM, Gavin Sharp ga...@gavinsharp.com wrote: 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... It would if we turned this on for a product that uses Jetpack, but we don't currently have plans to do that. We actually have some code that imports these without using Jetpack, including OS.File (although OS.File doesn't work on Gonk, though). Cheers, David -- 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: Changes to JS components/JSMs
Right - the linked modules are not jetpack-only code - they're part of core gecko code now, and the plan is to land even more of them, so we need to keep them working somehow. Gavin On 2012-11-02, at 9:33 AM, David Rajchenbach-Teller dtel...@mozilla.com wrote: On 11/2/12 4:42 PM, Kyle Huey wrote: On Thu, Nov 1, 2012 at 10:24 AM, Gavin Sharp ga...@gavinsharp.com wrote: 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... It would if we turned this on for a product that uses Jetpack, but we don't currently have plans to do that. We actually have some code that imports these without using Jetpack, including OS.File (although OS.File doesn't work on Gonk, though). Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Downtime of the git mirror tomorrow
Hi all, The building where the machine hosting the git mirror updater is located is going under a power maintenance tomorrow, Nov 3, from 8am - 4pm eastern time. Therefore, the git mirror may not get updated in that period. Once the power comes back up, the service should resume. Apologies in advance for this downtime. Please let me know if you have any questions. Cheers, -- Ehsan http://ehsanakhgari.org/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for reorganizing test directories
On Tuesday, October 30, 2012 7:26:34 AM UTC-7, Henrik Skupin wrote: As nearly all of you agreed on a flat folder structure makes a lot of sense if only one type of test is present. I second that, and we shouldn't make use of a 'tests' subfolder in such a case. But it would be fantastic if we could agree on a reasonable naming schema. Something we would propose is to use a folder name which matches the test framework. Mostly we are doing it already but are affected by small differences like 'mochitest' vs. 'mochitests'. The right usage would be 'mochitest' and it would apply to the other frameworks too. I didn't see anyone disagree with this, at least, just Karl's note that we might need separate names for the harness implementation and the test directories. What do people think? Is this OK? I would imagine that taking Karl's comment into account, it is, and if no one speaks up now, I would think you could just start submitting patches. Further if more tests are getting created which span multiple test frameworks, we should introduce the proposed 'tests' sub folder so all the tests can be kept together. Existing tests would have to be moved under tests, e.g. 'tests/mochitest' and 'tests/crashtest'. As far as I have seen we are doing that already in a couple of components. I don't understand this piece very well. Do people understand this well enough to agree or disagree with it, and to do it if it's wanted? Dave ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposal for reorganizing test directories
On 11/2/12 1:08 AM, Ms2ger wrote: On 11/02/2012 01:47 AM, Dave Mandelin wrote: 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. This, at least, is easily solved: even today, you can run ./mach mochitest-plain foo/bar/test_baz.html and never again care about what happens in the build dir. (Yes, mach doesn't yet accept all options the python harness itself supports; patches welcome.) What Ms2ger said ;) One of my primary goals of mach is to make common developer tasks (like running tests) as brain dead simple as possible. It's not quite there yet (patches welcome). From a friendliness perspective, the upside of running things through mach is much, much higher than having random make targets relying on arcane environment variables, etc. As an experiment, identify the pieces of information required to run a test through make targets. Now, compare that to running a test through mach. Mach requires a lot less contextual knowledge and makes it much easier for new Project contributors. I also have a corollary goal of marginalizing the importance of working inside the object directory. Currently, we find ourselves doing a lot of work inside the object directory because, well, we need to. I tend to view the object directory as a cache of the output of the build process. And, caches are not something you typically have visibility into. I'd rather have tools that run from the source directory and reach into the object directory for me. This eases the burden on developers because it doesn't require us to have intimate knowledge about the object directory. It also fosters inevitable refactorings because treating the object directory as a black box means you can change the contents inside at will as long as you don't break the interfaces into it (like mach). As they say, all problems can be solved with a level of indirection ;) Now, a black box object directory is a utopian future. Will we ever truly get there? Probably not. But, I'll continue to work on tools like mach and encourage people to work purely in the source directory because it's (typically) easier and makes my life as a build peer trying to push through major build system refactorings much, much easier. Going back to tests, once we have rewritten the core of the build system to define things through mozbuild files instead of Makefile.in (bug 784841), we'll have a much saner way of discovering test files and defining metadata associated with them. This opens a whole lot of options for test running, including the ability to specify the path to a test file and have it just run. Perhaps I should schedule a brown bag to give a better overview of all the goals and tasks underway... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Using anonymous namespace vs 'static'
I see an increasing number of patches using anonymous namespaces instead of 'static'. This is debugger unfriendly: setting a breakpoint in gdb for 'foo' in an anonymous namespace requires the following syntax: b (anonymous namespace)::foo (If there's a less verbose way of doing this, please let me know.) Do we have some good reason for preferring anonymous namespaces? Yes, I understand that there are certain cases (making types anonymous; certain template arguments) where 'static' is less powerful: http://www.comeaucomputing.com/techtalk/#nostatic But on balance the debugger inconvenience doesn't make them worth it for the common case IMO. Thoughts? Jason -- The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++. - Richard P. Gabriel, Worse is Better ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Using anonymous namespace vs 'static'
On Sat, Nov 3, 2012 at 6:59 AM, Jason Duell jduell.mcb...@gmail.com wrote:
I see an increasing number of patches using anonymous namespaces instead of
'static'. This is debugger unfriendly
It also obfuscates the visibility of the identifier, because the
|namespace {| is often far from the identifier. This is particularly
a problem when reading patches -- you have to consult the original
file to really understand what's going on.
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Gfx meeting Monday 2:30 US/Pacific
Hello, The Graphics meeting will take place this Monday at 2:30 PM US/Pacific time. That could be Tuesday in your timezone. Please first add your agenda items there: https://wiki.mozilla.org/Platform/GFX/2012-November-5 * Not every Monday at 2:30 PM Pacific Time * +1 650 903 0800 x92 Conf# 99366 * +1 416 848 3114 x92 Conf# 99366 * +1 800 707 2533 (pin 369) Conf# 99366 (toll free, Skype) * Video (Vidyo) link: https://v.mozilla.com/flex.html?roomdirect.htmlkey=vu1FKlkBlT29 * Vidyo room 9366 (if you have LDAP and can log in at https://v.mozilla.com) See you, Benoit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
