Re: Deprecating localstore.rdf
On 8/4/14 9:55 PM, Benjamin Smedberg 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 How much of XUL templates with RDF do we support still? Never kept track of templates to start with :-/ Axel ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deprecating localstore.rdf
On Monday, August 4, 2014 8:55:35 PM UTC+1, Benjamin Smedberg wrote: This does involve a one-time import of localstore data into the new format, correct? 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? What do you mean exactly by addon validation warning? In an earlier version of the patch there was a warning for any user of the old localstore API but Neil suggested to remove it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Deprecating localstore.rdf
On 8/5/2014 9:14 AM, rviti...@mozilla.com wrote: What do you mean exactly by addon validation warning? I mean an rule in the AMO automated checking/validation system: normally they are simple grep rules to detect that an addon is using an obsolete interface or code pattern. This will warn on new addon uploads; it's also used sometime near release to warn addon authors about potentially breaking changes. Talk to Jorge about the details of getting this kind of rule added to the validator. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Introducing mozilla::UniquePtr and mozilla::MakeUnique for |new T| and |new T[]| resources
If this obsoletes some of mfbt/Scoped.h, can you remove/document this? Thanks, David On 01/08/14 01:24, Jeff Walden wrote: Hey all, mfbt recently picked up mozilla::UniquePtrT or T[], a smart pointer for objects created using |new| or |new[]|. UniquePtr will automatically |delete| or |delete[]| its pointer when it's destroyed. (You can also define custom deletion policies if you want.) -- 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: Telemetry alerts for histograms
The dashboard of the alerting system is available at http://vitillo.github.io/cerberus/dashboard/. If you want to be notified when the distribution of your histogram changes significantly, please add your e-mail address to Histograms.json as documented in https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Adding_a_new_Telemetry_probe. Thanks, Roberto ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Introducing mozilla::UniquePtr and mozilla::MakeUnique for |new T| and |new T[]| resources
On 08/05/2014 07:02 AM, David Rajchenbach-Teller wrote: If this obsoletes some of mfbt/Scoped.h, can you remove/document this? I already replaced the file-description comment with /* DEPRECATED: Use UniquePtr.h instead. */ and repeated the same thing at the very start of class-level documentation. Not sure what else there is to do on this front. I suppose I could remove *all* the documentation and leave *only* deprecation notices, but it seems slightly better to keep it until the remaining users have been removed. (ScopedDeleteArray has already been removed, for starters.) Jeff ___ 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 Mon, Aug 4, 2014 at 6:21 PM, Gregory Szorc g...@mozilla.com wrote: 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). Who is going to do that work? I have patches that vastly improve the testing situation for jetpack tests by allowing other developers run them more easily, making them easier for releng to manage and most importantly making them meet tbpl visibility requirements. They involve tiny changes to the mochitest harness code. We're already hidden by default on tinderbox and are hitting problems because of it, I'd rather go ahead and finish up this work than wait for some future time when marionette can be upgraded to meet our requirements. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Chromium Security Team's Q2 status report
The Chromium Security Team shared some interesting information about their recent work on fuzzing tools, new sandboxing, Win64, and SSL: https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/ASLmY69v4Hk cp ___ 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
If this only involves tiny changes to mochitest and it's ready, I'd go ahead and do that. I am interested in seeing what your requirements are, though, and figuring out if we could meet them later with a better architected solution, whether it's Marionette or something else. Mochitest is kind of a monster, and the more we hack on corner cases the more fragile and unmaintainable it becomes. Jonathan On 8/5/2014 9:20 AM, Dave Townsend wrote: On Mon, Aug 4, 2014 at 6:21 PM, Gregory Szorc g...@mozilla.com wrote: 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). Who is going to do that work? I have patches that vastly improve the testing situation for jetpack tests by allowing other developers run them more easily, making them easier for releng to manage and most importantly making them meet tbpl visibility requirements. They involve tiny changes to the mochitest harness code. We're already hidden by default on tinderbox and are hitting problems because of it, I'd rather go ahead and finish up this work than wait for some future time when marionette can be upgraded to meet our requirements. ___ tools mailing list to...@lists.mozilla.org https://lists.mozilla.org/listinfo/tools ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Telemetry alerts for histograms
On 5/08/2014 17:07, rviti...@mozilla.com wrote: The dashboard of the alerting system is available at http://vitillo.github.io/cerberus/dashboard/. If you want to be notified when the distribution of your histogram changes significantly, please add your e-mail address to Histograms.json as documented in https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Adding_a_new_Telemetry_probe. I have wished years for this. Thank you. -- GCP ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Telemetry alerts for histograms
This looks really great! How many alerts is this thing going to generate? Could you have a mailing list that just gets all of the telemetry alerts email and then people could subscribe to it if they wanted? (Technically, I suppose I could make a mailing list myself and land a patch to subscribe the list to every one of these...) I'm not sure I really want to have my email address distributed with every copy of the Firefox source code. :) Andrew - Original Message - We, as in the performance team, are currently working on an automatic alerting system for Telemetry's data. At the moment we can detect sensible changes in the distributions of the collected histograms and we would like to notify the authors of the histograms with an e-mail. The e-mail will include the name of the histogram, the date of the regression and a plot that shows two histograms: the reference and the regression distribution. The regression histogram shows the distribution of the histogram taken the day it changed, while the reference histogram shows how the distribution should look like based on the previous days. In the future the e-mail will include a link to Telemetry's dashboard which will likely show some more information. Since using 'hg blame' or a similar approach to pinpoint the author of the histogram doesn't always yield the right match (see Bug 1037494), we are likely going to ask the interested authors to manually add their e-mail address to toolkit/components/telemetry/Histograms.json. The question to the histogram authors now is if receiving alerts through e-mails is OK or they would prefer something else. Note that a great deal of care has been taken to ensure that there the number of false positives is very close to 0, i.e. if you receive an alert then the distribution has clearly changed and the effect size is big enough that it can be considered more than significant. So don't expect your mailbox to be flooded with useless alerts. Roberto ___ 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
Shutdown leak checking on b2g mochitests
I have landed support for shutdown leak checking in mochitests on b2g in bug 1038943. This is currently on b2g-inbound, making its way to mozilla-central. b2g is not leak free, so the threshold value is currently set to 5200 bytes. As we fix leaks that number will be lowered, eventually to 0. If you add new leaks that push us over the threshold mochitests will turn orange and we'll back your patches out. This is primarily relevant to people who write B2G or Android specific C++ code. Note that Android mochitests don't have leak checking either, so the B2G tests are what will catch leaks in Android specific code. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Shutdown leak checking on b2g mochitests
On Tue, Aug 5, 2014 at 3:26 PM, Kyle Huey m...@kylehuey.com wrote: I have landed support for shutdown leak checking in mochitests on b2g in bug 1038943. This is currently on b2g-inbound, making its way to mozilla-central. b2g is not leak free, so the threshold value is currently set to 5200 bytes. As we fix leaks that number will be lowered, eventually to 0. If you add new leaks that push us over the threshold mochitests will turn orange and we'll back your patches out. This is primarily relevant to people who write B2G or Android specific C++ code. Note that Android mochitests don't have leak checking either, so the B2G tests are what will catch leaks in Android specific code. - Kyle It's also worth noting that this is currently only checking for leaks in the parent b2g process. Leak checking in content processes will come later. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Are StaticAuto/RefPtr good?
On 2014-08-04, 7:09 PM, 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. Not only that, but it also makes our code correct. There is nothing to guarantee that one of those destrcutors we're skipping right now would not have observable side effects passed shutdown. So until somone comes up with an idea on how to enforce that, we should clear these on all builds. Please make it so. :-) Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
