Re: Are StaticAuto/RefPtr good?
On Sun, Aug 3, 2014 at 10:18 PM, Kyle Huey m...@kylehuey.com wrote: Static*Ptrs are there to avoid static constructors and destructors so they can't clear themselves at shutdown. That means that they behave quite differently than regular smart pointers. Am I the only one who is bothered by this? To use them correctly, is it the case that you need to do one of the following? - null them at some point, or - call ClearOnShutdown() on them at some point. The comments in StaticPtr.h don't make this clear. And ClearOnShutdown.h is a separate file, and ClearOnShutdown() isn't mentioned in StaticPtr.h. So I think they're useful -- being able to avoid static constructors is important. But the documentation on how to use them could be much clearer. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: I want to implement a ListBox that contains one million(1,000,000) custom vbox, how to speed it up.
I've seen the postbox's tree implementation, it's re-implemented the tree.xml bindings so that we can generate RichTreeRow(The row is a complicated vobx/hbox) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Error while setting up development version of Firefox
Hey, I was trying to to setup the development version of Firefox and was facing some problem. When i run the command wget https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py python bootstrap.py while executing the command sudo add-apt-repository ppa:mercurial-ppa/releases it gives error Cannot add PPA: 'ppa:mercurial-ppa/releases'. Please check that the PPA name or format is correct. and this leads to a traceback. Could you please help me to fix this problem. I am working on Ubuntu 14.04 LTS Operating System. Thanking in anticipation, Regards, Agrim Khanna, ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switching Jetpack to use the runtests.py automation
I've done a little investigation into marionette and I've found a few issues with it: Firstly it doesn't look like running marionette directly or through mach allows developers to select individual directories or test files to run, rather it is a one-shot affair. This is very inconvenient for development. Secondly marionette doesn't seem to be built to scale to many test types. It uses regular expressions on filenames to determine the test type, as it happens the Jetpack tests do use a different form to the existing marionette tests so it's not out of the question but still makes me wary of adding a new test type. Thirdly I can't run marionette tests locally, they consistently fail quite badly. These problems make marionette a less than desirable option for use as a base for our test harness right now so I plan to get my work to make mochitests run jetpack tests completed this week and submit it for review. If Marionette becomes a better choice in the future a lot of the work I'm doing right now carries over, it will be simpler to switch from mochitest to marionette than it is switching to mochitest. On Tue, Jul 15, 2014 at 10:56 PM, Henrik Skupin hsku...@mozilla.com wrote: Gregory Szorc wrote on 07/15/2014 09:04 PM: On 7/15/14, 11:49 AM, Dave Townsend wrote: Since forever Jetpack tests in the Firefox trees have been run using our custom python CFX tool which is based on a fork of an ancient version of mozrunner. This causes us a number of problems. Keeping up with tree visibility rules is hard. Some features from newer versions of mozrunner like crash stack handling aren't available and our attempts to update to the newer mozbase have been blocked on trying to get some of our forked code accepted. It also makes it hard for Mozilla other developers to run our tests as CFX has a very different syntax to the other test suites. We've started investigating switching away from CFX and instead using the python automation that the mochitests use. This would work somewhat similarly to browser-chrome tests, runtests.py will startup Firefox and overlay some XUL and JS on the main window from where we can run the existing JS parts of the Jetpack test suites. There are many benefits here. The runtests.py code is well used and known to be resilient. It supports things like screenshots on failures and crash stacks that Jetpack tests don't currently handle. We'll use manifest files like the other test suites so disabling tests per platform will be easy. Excellent mach integration will make running individual tests simple. It also makes it possible to use commonjs style tests elsewhere in the tree. Release engineering should find managing the Jetpack tests a lot easier as they behave just like other mochitests. My initial experiment last week shows that this will work. The first part of our tests (package tests) is running and passing on my local machine and I expect to have the add-on tests working this week. I wanted to give everyone a heads up about this work to give you all a chance to ask questions or raise objections. The changes to runtests and the build system are minimal, just adding support for new manifest types really but I will be needing reviews for those. We'll also have to make the buildbot changes to switch over to use these new tests but I expect that to be pretty straightforward. Was Marionette considered? From what little I know (jgriffin and others can correct me), Marionette seems like the logical base for this test suite. Adding the tools mailing list, so that members of the A-team are aware of this thread, and can answer appropriately. -- Henrik Skupin Senior Test Engineer Mozilla Corporation ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement/ship: Support for msApplication-TileImage/Color
On Sun, 03 Aug 2014 14:37:40 -0700, Florian Bender wrote: Am Freitag, 1. August 2014 18:11:23 UTC+2 schrieb Wesley Johnston: Link to standard: There is no public standard in place for these meta-tags and none in progress either. Have you seen https://github.com/whatwg/meta-theme-color ? Indeed, and we have support for the theme-color meta in b2g through the mozbrowser api. Fabrice ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to support apple-touch-icon with Browser API
On Mon, 04 Aug 2014 10:42:49 +0100, Gervase Markham wrote: On 28/07/14 17:12, Dale Harvey wrote: We specifically chose a User Agent to something compatible with our Android release to get more compatible websites, despite the standard way would be to not do browser sniffing. I'm not quite sure what you mean here. Who is we in that sentence? The Content HTTP Headers team did a load of analysis and decided that the UA for Firefox OS should not contain Android. Has that changed for some or all of Firefox OS without us knowing? No, we still don't send Android on b2g. Fabrice ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement/ship: Support for msApplication-TileImage/Color
I have never seen this! Seems like something we could use. i.e. we would still need a logo designed to be shown against the site color. - Wes - Original Message - From: Fabrice Desré fabr...@mozilla.com To: dev-platform@lists.mozilla.org Sent: Monday, August 4, 2014 11:14:26 AM Subject: Re: Intent to implement/ship: Support for msApplication-TileImage/Color On Sun, 03 Aug 2014 14:37:40 -0700, Florian Bender wrote: Am Freitag, 1. August 2014 18:11:23 UTC+2 schrieb Wesley Johnston: Link to standard: There is no public standard in place for these meta-tags and none in progress either. Have you seen https://github.com/whatwg/meta-theme-color ? Indeed, and we have support for the theme-color meta in b2g through the mozbrowser api. Fabrice ___ 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: fine-grained filtering of bugmail
yes, that's how it should behave. - Original Message - From: Gavin Sharp ga...@gavinsharp.com To: Byron Jones g...@mozilla.com Cc: dev-platform dev-platform@lists.mozilla.org Sent: Saturday, 19 July, 2014 3:54:37 AM Subject: Re: fine-grained filtering of bugmail I added the following filters to my account: Any Any Iteration Any Exclude Any Any Points Any Exclude My expected behavior is: - if someone modifies the Points field - bugmail filtered - if someone modifies the Points field and the Iteration field - bugmail filtered - if someone modifies the Points field and adds a comment - bugmail allowed Am I understanding how these work correctly? Gavin On Sun, Jul 13, 2014 at 11:13 PM, Byron Jones g...@mozilla.com wrote: are you tired of receiving notifications from bugzilla that you simply don't care about? you can now tell bugzilla to stop clogging up your inbox with those pesky emails via bugmail filtering. are you only interested in seeing new bugs and bug status changes in some components you are watching? set up a filter! or perhaps you only want to be informed about qa related changes on bug where you are the assignee? set up a filter! see http://globau.wordpress.com/2014/07/10/using-bugmail-filtering-to-exclude-notifications-you-dont-want/ for more details. -- byron jones - :glob - bugzilla.mozilla.org team - ___ 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: What's does the following message means?
I am create a clear XUL runner application, that's the Error Console log Anyway, it's a message, The following message I received from a clear XUL applicatoin, for the third one, I have solution, but for the first one and second one, It's looks like a unneeded message, Could not read chrome manifest 'file:///C:/CI-Cor/ks/bolt/bolt-sdk/xulrunner-sdk/bin/chrome.manifest'. because it have omni.ja Could not read chrome manifest 'file:///C:/CI-Cor/ks/bolt/bolt-sdk/xulrunner-sdk/bin/chrome.manifest'. While creating services from category 'profile-after-change', service for entry 'InterAppCommService', contract ID '@ mozilla.org/inter-app-communication-service;1' does not implement nsIObserver. Timestamp: 2014/7/25 22:48:07 Warning: TypeError: anonymous function does not always return a value Source File: resource://gre/modules/osfile/osfile_shared_front.jsm Line: 551 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: I want to implement a ListBox that contains one million(1,000,000) custom vbox, how to speed it up.
Thanks a lot, i am not so sure if this support for custom vbox hobx. Because it's content are really reach. 2014年8月1日 下午9:03于 Paul Rouget p...@mozilla.com写道： Yonggang Luo wrote: The vbox's content comes from a large database. Is there any standard way to implement it A xul listbox? You probably want to use a treeview. It's designed for such use cases. https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/Custom_Tree_Views -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to deploy: plugin timeout A/B test experiment, bug 1018200
Chad, I'm looking for your approval to use 5% of the beta population for this experiment. Apologies for any delay my PTO caused. This is enthusiastically approved. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Deprecating localstore.rdf
Localstore.rdf will soon be replaced with a json store (see Bug 559505). I am currently planning to leave the localstore.rdf implementation as it is and issue a warning when a client tries to access to it. This is needed as some add-ons seem still to rely on it. We could use some Telemetry probes to see effectively how many add-ons are still using the rdf store once the patch lands. Are there any objections or remarks to the deprecation of localstore.rdf? Roberto ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement/ship: Support for msApplication-TileImage/Color
Am Montag, 4. August 2014 20:39:34 UTC+2 schrieb Wesley Johnston: I have never seen this! Seems like something we could use. i.e. we would still need a logo designed to be shown against the site color. There is link[rel=icon] with sizes attribute (support for multiple sizes ongoing, don't have a bug, though, sorry!). There is also talk about supporting link[rel=apple-touch-icon], esp. for B2G. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deprecating localstore.rdf
On 7/22/2014 8:47 AM, Roberto Agostino Vitillo wrote: Localstore.rdf will soon be replaced with a json store (see Bug 559505). I am currently planning to leave the localstore.rdf implementation as it is and issue a warning when a client tries to access to it. This is needed as some add-ons seem still to rely on it. We could use some Telemetry probes to see effectively how many add-ons are still using the rdf store once the patch lands. Are there any objections or remarks to the deprecation of localstore.rdf? This does involve a one-time import of localstore data into the new format, correct? I'm happy that we are doing this. I *believe* that this may be the last client of the RDF code in Firefox, which may allow us to remove RDF from Firefox in a future release. Do you already have an addon validation warning about addons using localstore? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement/ship: Support for msApplication-TileImage/Color
Yeah. icons with sizes haven't been widely adopted. We've been advocating (for a few years) to try and improve that. Even if we have one, there is a good chance that icon will not be designed well to sit against the sites color. For instance, the Twitter icon is basically invisible if you put it on a blue background (we already pull the blue background out from the icon in places and lighten/darken it before we show the icon in front). We could use masking tricks if the icon has an alpha channel and a well defined silhouette, but its better if the site can provide something for this purpose rather than us cobbling together multiple sources. - Original Message - From: Florian Bender florian.ben...@quantumedia.de To: dev-platform@lists.mozilla.org Sent: Monday, August 4, 2014 12:52:36 PM Subject: Re: Intent to implement/ship: Support for msApplication-TileImage/Color Am Montag, 4. August 2014 20:39:34 UTC+2 schrieb Wesley Johnston: I have never seen this! Seems like something we could use. i.e. we would still need a logo designed to be shown against the site color. There is link[rel=icon] with sizes attribute (support for multiple sizes ongoing, don't have a bug, though, sorry!). There is also talk about supporting link[rel=apple-touch-icon], esp. for B2G. ___ 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: Deprecating localstore.rdf
This is certainly a big one, but https://bugzilla.mozilla.org/showdependencytree.cgi?id=833098maxdepth=1hide_resolved=1 suggests we will still need to worry about mimeTypes.rdf and install.rdf/update.rdf, unfortunately... Gavin On Mon, Aug 4, 2014 at 12:55 PM, Benjamin Smedberg benja...@smedbergs.us wrote: On 7/22/2014 8:47 AM, Roberto Agostino Vitillo wrote: Localstore.rdf will soon be replaced with a json store (see Bug 559505). I am currently planning to leave the localstore.rdf implementation as it is and issue a warning when a client tries to access to it. This is needed as some add-ons seem still to rely on it. We could use some Telemetry probes to see effectively how many add-ons are still using the rdf store once the patch lands. Are there any objections or remarks to the deprecation of localstore.rdf? This does involve a one-time import of localstore data into the new format, correct? I'm happy that we are doing this. I *believe* that this may be the last client of the RDF code in Firefox, which may allow us to remove RDF from Firefox in a future release. Do you already have an addon validation warning about addons using localstore? --BDS ___ 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: Deprecating localstore.rdf
How many of these, if any, are used on b2g? - Kyle On Mon, Aug 4, 2014 at 2:06 PM, Gavin Sharp ga...@gavinsharp.com wrote: This is certainly a big one, but https://bugzilla.mozilla.org/showdependencytree.cgi?id=833098maxdepth=1hide_resolved=1 suggests we will still need to worry about mimeTypes.rdf and install.rdf/update.rdf, unfortunately... Gavin On Mon, Aug 4, 2014 at 12:55 PM, Benjamin Smedberg benja...@smedbergs.us wrote: On 7/22/2014 8:47 AM, Roberto Agostino Vitillo wrote: Localstore.rdf will soon be replaced with a json store (see Bug 559505). I am currently planning to leave the localstore.rdf implementation as it is and issue a warning when a client tries to access to it. This is needed as some add-ons seem still to rely on it. We could use some Telemetry probes to see effectively how many add-ons are still using the rdf store once the patch lands. Are there any objections or remarks to the deprecation of localstore.rdf? This does involve a one-time import of localstore data into the new format, correct? I'm happy that we are doing this. I *believe* that this may be the last client of the RDF code in Firefox, which may allow us to remove RDF from Firefox in a future release. Do you already have an addon validation warning about addons using localstore? --BDS ___ 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deprecating localstore.rdf
On 8/4/2014 5:06 PM, Gavin Sharp wrote: This is certainly a big one, but https://bugzilla.mozilla.org/showdependencytree.cgi?id=833098maxdepth=1hide_resolved=1 suggests we will still need to worry about mimeTypes.rdf and install.rdf/update.rdf, unfortunately... ok. mimeTypes.rdf is read/write and so we'd need to replace it. install/update.rdf are read-only and so we could use the simple JS shim library pretty easily. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MemShrink Meeting - Tuesday, 5 August 2014 at 4:00pm PDT
The next MemShrink meeting will be brought to you by the gray color #2d2d2d and not by gradient bitmaps: https://bugzilla.mozilla.org/show_bug.cgi?id=1039631 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, 5 August, 4:00 PM PDT * http://arewemeetingyet.com/Los%20Angeles/2014-08-05/16: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
Tree Closure Stats - July 2014
Hi Everyone, (cross posted to dev-platform) Below is the stats for Tree Closures for the main trees that the sheriffs manage. Please feel free to let me know if you have any questions._ Mozilla-Inbound _ 2014-07 checkin-compilation: 1 day, 1:19:41 checkin-test: 1 day, 2:44:14 infra: 1 day, 12:59:37 no reason: 0:00:10 total: 3 days, 17:03:42_ __Mozilla-Central_ 2014-07 checkin-test: 2:26:46 infra: 1 day, 10:34:31 no reason: 0:14:02 total: 1 day, 13:15:19 _Fx-Team _2014-07 checkin-compilation: 1:06:28 checkin-test: 13:45:54 infra: 1 day, 14:58:00 other: 0:46:07 total: 2 days, 6:36:29_ _ _B2G-Inbound_ 2014-07 checkin-compilation: 1:14:08 checkin-test: 2:54:52 infra: 1 day, 5:29:23 no reason: 0:15:34 total: 1 day, 9:53:57 If you would like to see how this compares to previous months please see http://futurama.theautomatedtester.co.uk/ David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are StaticAuto/RefPtr good?
On Mon, Aug 04, 2014 at 11:33:55AM -0700, Kyle Huey wrote: On Sun, Aug 3, 2014 at 11:01 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Sun, Aug 3, 2014 at 10:18 PM, Kyle Huey m...@kylehuey.com wrote: Static*Ptrs are there to avoid static constructors and destructors so they can't clear themselves at shutdown. That means that they behave quite differently than regular smart pointers. Am I the only one who is bothered by this? To use them correctly, is it the case that you need to do one of the following? - null them at some point, or - call ClearOnShutdown() on them at some point. The comments in StaticPtr.h don't make this clear. And ClearOnShutdown.h is a separate file, and ClearOnShutdown() isn't mentioned in StaticPtr.h. So I think they're useful -- being able to avoid static constructors is important. But the documentation on how to use them could be much clearer. Nick Yes, that's correct. You have to clear them somehow before the process exits or we leak. Which, besides accounting, is not really a problem, since the process is exiting anyways. It can be a problem if desctructor code is actively doing import stuff like persisting state. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are StaticAuto/RefPtr good?
On Mon, Aug 04, 2014 at 03:42:07PM -0700, Kyle Huey wrote: On Mon, Aug 4, 2014 at 3:09 PM, Mike Hommey m...@glandium.org wrote: On Mon, Aug 04, 2014 at 11:33:55AM -0700, Kyle Huey wrote: On Sun, Aug 3, 2014 at 11:01 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Sun, Aug 3, 2014 at 10:18 PM, Kyle Huey m...@kylehuey.com wrote: Static*Ptrs are there to avoid static constructors and destructors so they can't clear themselves at shutdown. That means that they behave quite differently than regular smart pointers. Am I the only one who is bothered by this? To use them correctly, is it the case that you need to do one of the following? - null them at some point, or - call ClearOnShutdown() on them at some point. The comments in StaticPtr.h don't make this clear. And ClearOnShutdown.h is a separate file, and ClearOnShutdown() isn't mentioned in StaticPtr.h. So I think they're useful -- being able to avoid static constructors is important. But the documentation on how to use them could be much clearer. Nick Yes, that's correct. You have to clear them somehow before the process exits or we leak. Which, besides accounting, is not really a problem, since the process is exiting anyways. It can be a problem if desctructor code is actively doing import stuff like persisting state. Mike That accounting is useful though. We need to fix the leaks that don't matter in order to catch the ones that do, so that the latter don't get lost in the noise of the former. That accounting is useful on debug builds. Arguably, debug builds don't have to care about avoiding static initializers. So we could add a destructor to Static*Ptrs on debug builds that: - sends a error that ClearOnShutdown was not called on them or - clears them to clear the leak or - both (replacing the error with a warning) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are StaticAuto/RefPtr good?
On Mon, Aug 4, 2014 at 4:06 PM, Mike Hommey m...@glandium.org wrote: On Mon, Aug 04, 2014 at 03:42:07PM -0700, Kyle Huey wrote: On Mon, Aug 4, 2014 at 3:09 PM, Mike Hommey m...@glandium.org wrote: On Mon, Aug 04, 2014 at 11:33:55AM -0700, Kyle Huey wrote: On Sun, Aug 3, 2014 at 11:01 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Sun, Aug 3, 2014 at 10:18 PM, Kyle Huey m...@kylehuey.com wrote: Static*Ptrs are there to avoid static constructors and destructors so they can't clear themselves at shutdown. That means that they behave quite differently than regular smart pointers. Am I the only one who is bothered by this? To use them correctly, is it the case that you need to do one of the following? - null them at some point, or - call ClearOnShutdown() on them at some point. The comments in StaticPtr.h don't make this clear. And ClearOnShutdown.h is a separate file, and ClearOnShutdown() isn't mentioned in StaticPtr.h. So I think they're useful -- being able to avoid static constructors is important. But the documentation on how to use them could be much clearer. Nick Yes, that's correct. You have to clear them somehow before the process exits or we leak. Which, besides accounting, is not really a problem, since the process is exiting anyways. It can be a problem if desctructor code is actively doing import stuff like persisting state. Mike That accounting is useful though. We need to fix the leaks that don't matter in order to catch the ones that do, so that the latter don't get lost in the noise of the former. That accounting is useful on debug builds. Arguably, debug builds don't have to care about avoiding static initializers. So we could add a destructor to Static*Ptrs on debug builds that: - sends a error that ClearOnShutdown was not called on them or - clears them to clear the leak or - both (replacing the error with a warning) Mike Yeah, we could do that. But turning on leak checking does the same thing as (a) so (b) is the only useful code change to make. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are StaticAuto/RefPtr good?
On Mon, Aug 04, 2014 at 04:09:26PM -0700, Kyle Huey wrote: On Mon, Aug 4, 2014 at 4:06 PM, Mike Hommey m...@glandium.org wrote: On Mon, Aug 04, 2014 at 03:42:07PM -0700, Kyle Huey wrote: On Mon, Aug 4, 2014 at 3:09 PM, Mike Hommey m...@glandium.org wrote: On Mon, Aug 04, 2014 at 11:33:55AM -0700, Kyle Huey wrote: On Sun, Aug 3, 2014 at 11:01 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: On Sun, Aug 3, 2014 at 10:18 PM, Kyle Huey m...@kylehuey.com wrote: Static*Ptrs are there to avoid static constructors and destructors so they can't clear themselves at shutdown. That means that they behave quite differently than regular smart pointers. Am I the only one who is bothered by this? To use them correctly, is it the case that you need to do one of the following? - null them at some point, or - call ClearOnShutdown() on them at some point. The comments in StaticPtr.h don't make this clear. And ClearOnShutdown.h is a separate file, and ClearOnShutdown() isn't mentioned in StaticPtr.h. So I think they're useful -- being able to avoid static constructors is important. But the documentation on how to use them could be much clearer. Nick Yes, that's correct. You have to clear them somehow before the process exits or we leak. Which, besides accounting, is not really a problem, since the process is exiting anyways. It can be a problem if desctructor code is actively doing import stuff like persisting state. Mike That accounting is useful though. We need to fix the leaks that don't matter in order to catch the ones that do, so that the latter don't get lost in the noise of the former. That accounting is useful on debug builds. Arguably, debug builds don't have to care about avoiding static initializers. So we could add a destructor to Static*Ptrs on debug builds that: - sends a error that ClearOnShutdown was not called on them or - clears them to clear the leak or - both (replacing the error with a warning) Mike Yeah, we could do that. But turning on leak checking does the same thing as (a) so (b) is the only useful code change to make. Well, it only does (a) indirectly. That is, it's not obvious. An explicit warning about what's missing would be more useful. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Switching Jetpack to use the runtests.py automation
On 8/4/14, 10:39 AM, Dave Townsend wrote: I've done a little investigation into marionette and I've found a few issues with it: Firstly it doesn't look like running marionette directly or through mach allows developers to select individual directories or test files to run, rather it is a one-shot affair. This is very inconvenient for development. Secondly marionette doesn't seem to be built to scale to many test types. It uses regular expressions on filenames to determine the test type, as it happens the Jetpack tests do use a different form to the existing marionette tests so it's not out of the question but still makes me wary of adding a new test type. Thirdly I can't run marionette tests locally, they consistently fail quite badly. These problems make marionette a less than desirable option for use as a base for our test harness right now so I plan to get my work to make mochitests run jetpack tests completed this week and submit it for review. If Marionette becomes a better choice in the future a lot of the work I'm doing right now carries over, it will be simpler to switch from mochitest to marionette than it is switching to mochitest. The issues listed seem fixable. I would rather we spend energy improving Marionette than piling yet more things on top of mochitest's haphazard base. The various automation failures in the past few weeks should be reason enough to avoid mochitest and go with a better-engineered and tested solution (marionette). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Error while setting up development version of Firefox
I just installed a fresh version of Ubuntu Server 14.04.1 and bootstrap.py works great for me. The bootstrap script is verifying you have Mercurial 3.0+ installed and falling back to installing from the PPA if not. You can always install Mercurial 3.0+ manually to bypass the PPA. http://mercurial.selenic.com/release/mercurial-3.1.tar.gz + `python setup.py install PREFIX=/path/to/prefix` is what I do (just put /path/to/prefix/bin in your PATH and you'll be set). On 8/4/14, 7:22 AM, agrim khanna wrote: Hey, I was trying to to setup the development version of Firefox and was facing some problem. When i run the command wget https://hg.mozilla.org/mozilla-central/raw-file/default/python/mozboot/bin/bootstrap.py python bootstrap.py while executing the command sudo add-apt-repository ppa:mercurial-ppa/releases it gives error Cannot add PPA: 'ppa:mercurial-ppa/releases'. Please check that the PPA name or format is correct. and this leads to a traceback. Could you please help me to fix this problem. I am working on Ubuntu 14.04 LTS Operating System. Thanking in anticipation, Regards, Agrim Khanna, ___ 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
How to customize the style of system scrollbar?
I am willing to replace the style of scrollbar with my own styles. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
