Re: MOZ_RAII has landed on inbound
I've updated it with some information about MOZ_RAII. On Mon, Sep 14, 2015 at 3:02 PM, Aaron Klotz wrote: > Can you please update > https://developer.mozilla.org/en-US/docs/Using_RAII_classes_in_Mozilla > with this information? > > Thanks, > > Aaron > > > On 9/12/2015 3:06 PM, Michael Layzell wrote: > >> Hey everyone, >> >> Bug 1201190 (https://bugzilla.mozilla.org/show_bug.cgi?id=1201190) just >> landed on inbound, which means that we now have access to the new >> annotation MOZ_RAII. This is a static-analysis annotation, intended to be >> placed on RAII guards. It will cause the static analysis to cause >> compilation to fail if the class is allocated anywhere other than in an >> automatic variable - this includes temporaries, unlike MOZ_STACK_CLASS, >> which also allows allocating the type in a temporary. >> >> This new analysis fills the role of the much more verbose MOZ_GUARD_OBJECT >> annotations, which perform runtime analysis to prevent temporary >> allocations. Unfortunately, as we currently only run static analysis on >> Linux and Mac OS X, you should still use MOZ_GUARD_OBJECT (In addition to >> MOZ_RAII - which is more likely to catch errors, as it checks at build >> time >> and is more thorough) if the class might be used from windows-specific >> code. >> >> To mark a class as MOZ_RAII, simply `#include "mfbt/Attributes.h"`, and >> then change the class declaration to `class MOZ_RAII FooGuard`. >> >> If you're adding any new RAII guards, please use MOZ_RAII! Thanks :D >> ___ >> 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
Alternative to Bonsai?
The Bonsai server +infra is gone. Is there an alternative? Is there a mercurial repository that has a unified history of mozilla-central plus cvs history? Bonus if it also includes comm-central. Phil -- Philip Chee , http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Alternative to Bonsai?
On 2015-09-15 11:08 AM, Philip Chee wrote: > The Bonsai server +infra is gone. Is there an alternative? > > Is there a mercurial repository that has a unified history of > mozilla-central plus cvs history? Bonus if it also includes comm-central. > > Phil > I'm pretty sure https://github.com/mozilla/gecko-dev has full history. Eg: I see that https://github.com/mozilla/gecko-dev/blob/master/LICENSE has an initial commit in 1998. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Alternative to Bonsai?
On 9/15/2015 10:11 AM, Ben Hearsum wrote: On 2015-09-15 11:08 AM, Philip Chee wrote: The Bonsai server +infra is gone. Is there an alternative? Is there a mercurial repository that has a unified history of mozilla-central plus cvs history? Bonus if it also includes comm-central. Phil I'm pretty sure https://github.com/mozilla/gecko-dev has full history. Eg: I see that https://github.com/mozilla/gecko-dev/blob/master/LICENSE has an initial commit in 1998. There is no git or mercurial repository that contains the full history of mozilla CVS. Slightly unsurprising, since the full history of mozilla CVS actually breaks most conversion tools. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Alternative to Bonsai?
On 9/15/15 5:14 PM, Joshua Cranmer 🐧 wrote: > On 9/15/2015 10:11 AM, Ben Hearsum wrote: >> On 2015-09-15 11:08 AM, Philip Chee wrote: >>> The Bonsai server +infra is gone. Is there an alternative? >>> >>> Is there a mercurial repository that has a unified history of >>> mozilla-central plus cvs history? Bonus if it also includes >>> comm-central. >>> >>> Phil >>> >> I'm pretty sure https://github.com/mozilla/gecko-dev has full history. >> Eg: I see that https://github.com/mozilla/gecko-dev/blob/master/LICENSE >> has an initial commit in 1998. > > There is no git or mercurial repository that contains the full history > of mozilla CVS. Slightly unsurprising, since the full history of mozilla > CVS actually breaks most conversion tools. > Here is one shot at it, it has served me quite well: https://github.com/ehsan/mozilla-cvs-history Philipp ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is there any events before loading a URL to a docshell.
Mike Conley wrote: From the passed in nsIWebProgress[1], you should be able to get at the nsIDOMWindow, and from there, I *think* you can get to the nsIDocShell by QI'ing the nsIWebProgress to an nsIInterfaceRequestor and then GetInterface'ing nsIDocShell. I haven't tried this, but I'm reasonably certain it will work. You could probably just QI the nsIWebProgress to nsIDocShell directly. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Alternative to Bonsai?
On 9/15/15 11:11 AM, Ben Hearsum wrote: I'm pretty sure https://github.com/mozilla/gecko-dev has full history. Though note that it doesn't have working blame for a lot of files in our source tree (and especially the ones you'd _want_ to get blame for, in my experience), so it's of pretty limited use if you're trying to do the sorts of things you used to be able to do with bonsai. I believe gps is working on standing up a web front end for the CVS repo blame to replace bonsai... -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Alternative to Bonsai?
Joshua Cranmer 🐧 wrote: There is no git or mercurial repository that contains the full history of mozilla CVS. Slightly unsurprising, since the full history of mozilla CVS actually breaks most conversion tools. Even "CVS moved" files throw them a loop, I tried looking for blame for some code recently and got unstuck because of this. -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Alternative to Bonsai?
On 9/15/2015 10:53 AM, Boris Zbarsky wrote: On 9/15/15 11:11 AM, Ben Hearsum wrote: I'm pretty sure https://github.com/mozilla/gecko-dev has full history. Though note that it doesn't have working blame for a lot of files in our source tree (and especially the ones you'd _want_ to get blame for, in my experience), so it's of pretty limited use if you're trying to do the sorts of things you used to be able to do with bonsai. I believe gps is working on standing up a web front end for the CVS repo blame to replace bonsai... FWIW, I did try to import something using what appears to be the best quality CVS exporter (cvs-fast-export), only to run into a problem that we apparently landed some files on CVS branches that got merged into mainline, which causes the generated revision graph to be cyclic (which, as the author to said project confessed, was both known and extremely hard to fix). Well, and I had to bump several "maximum repository complexity" defines :-) . -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Alternative to Bonsai?
On 09/15/2015 06:53 PM, Boris Zbarsky wrote: On 9/15/15 11:11 AM, Ben Hearsum wrote: I'm pretty sure https://github.com/mozilla/gecko-dev has full history. Though note that it doesn't have working blame for a lot of files in our source tree (and especially the ones you'd _want_ to get blame for, in my experience), so it's of pretty limited use if you're trying to do the sorts of things you used to be able to do with bonsai. I believe gps is working on standing up a web front end for the CVS repo blame to replace bonsai... I guess that is unofficially http://52.25.115.98/viewvc/main/ -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Alternative to Bonsai?
On Tue, Sep 15, 2015 at 8:08 AM, Philip Chee wrote:
> The Bonsai server +infra is gone. Is there an alternative?
>
> Is there a mercurial repository that has a unified history of
> mozilla-central plus cvs history? Bonus if it also includes comm-central.
>
https://hg.mozilla.org/users/gszorc_mozilla.com/gecko-full is a Mercurial
repo with CVS history. More info at
http://gregoryszorc.com/blog/2015/05/18/firefox-mercurial-repository-with-cvs-history/.
Yes, it hasn't been updating. If I had infinite time I would stand this up
as something more permanent.
You may find bug 1200362 and the link in comment #1 useful. I still need to
make a more permanent home for it. Hopefully this ties people over until I
have time.
People did some wonky things with the CVS repository back in the day. e.g.
people would SSH into the server and manually edit files inside the repo
*without* using CVS commands. hwine and people such as dbaron who were
around in the early days of Mozilla can tell you more. The takeaway is that
no conversion of the CVS repository to {Mercurial, Git, ... } will have
perfect history. In theory, we could have someone spend a few months
pouring over the repository and hand crafting a more proper conversion. I
doubt that will ever happen.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
easily getting allocation stacks for leaking objects
Hi all, For some intermittent leaks, it's not at all clear where the leaked objects are coming from, especially for objects that are widely used across the codebase. Bug 1196430 added the ability for our leak checking mechanism to track allocation stacks of objects and to print said stacks for leaked objects at the end of a test run. The wiki page for BloatView has been updated with a description of how to use this capability: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/BloatView#Bloat_Statistics_on_Tinderbox If you are facing a particular pernicious intermittent leak, please consider doing some try runs with --setenv=XPCOM_MEM_LOG_CLASSES=FOO added to aid in understanding where the leak starts. Also, please feel free to file bugs on how leak checking could be improved to provide more information for investigating these kind of bugs. Thanks, -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: recording use counters for web features
On Mon, Aug 31, 2015 at 1:11 PM, Josh Matthews wrote: > Servo is particularly interested in getting usage data for just about > every DOM API that exists in Gecko. We'd like to use this to inform our > priorities for implementing missing features in Servo. Is this a realistic > request? If not, what about instrumenting all SVG APIs to figure out if > there's a subset that would give us maximum compatibility? How much of a > burden will these requests be on developers and users? That'd be a lot of extra use counters! I think you'd have to file a bug and/or ask folks on the DOM team how much of a performance hit they're willing to take by recording use counters for everything. Instrumenting all the SVG APIs sounds sort of reasonable to me... I'm not sure how to interpret "How much of a burden will these requests be on developers and users?" If you're asking about performance penalties, then yes, there is a performance penalty associated with them... Thanks, -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: recording use counters for web features
On Mon, Aug 24, 2015 at 8:40 PM, Karl Dubost wrote: > Is there a plan for a step by step guide on how to > > 1. implement a new counter > I plan on writing some documentation for https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Adding_a_new_Telemetry_probe very soon. > 2. access the data once the counter is in place 3. make sense of the stats once it has ran for a while > Yes. We're still tweaking the way use counters are recorded, which will have a bearing on how you access them and make sense of them. I'm hoping to write a custom dashboard that takes the raw histogram data and it in a more meaningful way (e.g. % of documents that use a given feature, rather than counts of use/don't use). Thanks, -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: easily getting allocation stacks for leaking objects
This looks super useful - thanks Nathan! Tooling like this is critical to helping us get to the bottom of intermittent nastiness. On Tue, Sep 15, 2015 at 1:32 PM, Nathan Froyd wrote: > Hi all, > > For some intermittent leaks, it's not at all clear where the leaked objects > are coming from, especially for objects that are widely used across the > codebase. Bug 1196430 added the ability for our leak checking mechanism to > track allocation stacks of objects and to print said stacks for leaked > objects at the end of a test run. > > The wiki page for BloatView has been updated with a description of how to > use this capability: > > https://developer.mozilla.org/en-US/docs/Mozilla/Performance/BloatView#Bloat_Statistics_on_Tinderbox > > If you are facing a particular pernicious intermittent leak, please > consider doing some try runs with --setenv=XPCOM_MEM_LOG_CLASSES=FOO added > to aid in understanding where the leak starts. Also, please feel free to > file bugs on how leak checking could be improved to provide more > information for investigating these kind of bugs. > > Thanks, > -Nathan > ___ > 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
git-bz-moz and Bugzilla 2 factor authentication
Apparently Bugzilla 2fa breaks the weird cookie authentication method that git-bz-moz and bzexport use. I think I've read that this is a bugzilla bug, but in the meanwhile I've been working on making git-bz-moz use the Bugzilla backend of bexport, which is less hacky and supports using API keys for authentication. Setting up an API key is extremely easy. If you want to try it out, it is available from my github repo here: https://github.com/amccreight/git-bz-moz/tree/RestAPI git bz edit and git bz push don't work, but the rest should, so please file issues at https://github.com/mozilla/git-bz-moz or email me if you notice them. (Oh, I think setting reviewer flags for Firefox product bugs doesn't work, is a known issue.) The patches are still a little hacky and probably don't cache as much as they should. Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: git-bz-moz and Bugzilla 2 factor authentication
Oh, and another thing I meant to mention that seems underused: if you are using git-bz-moz, the |git apply| command is pretty handy. You can do |git apply 12345| where 12345 is a bug number, and it will prompt you for each non-obsolete patch attachment and apply it if you want it. Andrew On Tue, Sep 15, 2015 at 2:37 PM, Andrew McCreight wrote: > Apparently Bugzilla 2fa breaks the weird cookie authentication method that > git-bz-moz and bzexport use. I think I've read that this is a bugzilla bug, > but in the meanwhile I've been working on making git-bz-moz use the > Bugzilla backend of bexport, which is less hacky and supports using API > keys for authentication. Setting up an API key is extremely easy. > > If you want to try it out, it is available from my github repo here: > https://github.com/amccreight/git-bz-moz/tree/RestAPI > > git bz edit and git bz push don't work, but the rest should, so please > file issues at https://github.com/mozilla/git-bz-moz or email me if you > notice them. (Oh, I think setting reviewer flags for Firefox product bugs > doesn't work, is a known issue.) The patches are still a little hacky and > probably don't cache as much as they should. > > Andrew > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: git-bz-moz and Bugzilla 2 factor authentication
Sorry, the command is actually |git bz apply 12345| as you probably figured out. Andrew On Tue, Sep 15, 2015 at 2:40 PM, Andrew McCreight wrote: > Oh, and another thing I meant to mention that seems underused: if you are > using git-bz-moz, the |git apply| command is pretty handy. You can do |git > apply 12345| where 12345 is a bug number, and it will prompt you for each > non-obsolete patch attachment and apply it if you want it. > > Andrew > > On Tue, Sep 15, 2015 at 2:37 PM, Andrew McCreight > wrote: > >> Apparently Bugzilla 2fa breaks the weird cookie authentication method >> that git-bz-moz and bzexport use. I think I've read that this is a bugzilla >> bug, but in the meanwhile I've been working on making git-bz-moz use the >> Bugzilla backend of bexport, which is less hacky and supports using API >> keys for authentication. Setting up an API key is extremely easy. >> >> If you want to try it out, it is available from my github repo here: >> https://github.com/amccreight/git-bz-moz/tree/RestAPI >> >> git bz edit and git bz push don't work, but the rest should, so please >> file issues at https://github.com/mozilla/git-bz-moz or email me if you >> notice them. (Oh, I think setting reviewer flags for Firefox product bugs >> doesn't work, is a known issue.) The patches are still a little hacky and >> probably don't cache as much as they should. >> >> Andrew >> > > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
|hg bzexport| and Bugzilla two-factor authentication
The Mercurial extensions to interact with Bugzilla -- bzexport and the like --
have been updated to handle 2fa details. No need to add API key support
yourself, or use some sketchy dude's user-repo fix for the issue! ;-) (As at
least three people have considered, two people have actually done, tho only one
ended up landed upstream.)
Just run |./mach mercurial-setup| to pick up the new version with API key
support. Then add:
[bugzilla]
username = your-bugzilla-email-addr...@example.com
apikey = 0123456789ABCDEF0123456789ABCDEF01234567
to your ~/.hgrc, where the hex number is a Bugzilla API key generated on the
relevant Bugzilla prefs page, and pushes should work again.
("Mercurial had it first...")
Jeff
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: |hg bzexport| and Bugzilla two-factor authentication
And as of a few seconds ago `mach mercurial-setup` (on just inbound so far)
will guide you through defining an API key. It will also purge your hgrc of
the legacy auth credentials, which won't work with 2FA.
Bug 1200461 if there are any issues.
On Tue, Sep 15, 2015 at 2:52 PM, Jeff Walden wrote:
> The Mercurial extensions to interact with Bugzilla -- bzexport and the
> like -- have been updated to handle 2fa details. No need to add API key
> support yourself, or use some sketchy dude's user-repo fix for the issue!
> ;-) (As at least three people have considered, two people have actually
> done, tho only one ended up landed upstream.)
>
> Just run |./mach mercurial-setup| to pick up the new version with API key
> support. Then add:
>
> [bugzilla]
> username = your-bugzilla-email-addr...@example.com
> apikey = 0123456789ABCDEF0123456789ABCDEF01234567
>
> to your ~/.hgrc, where the hex number is a Bugzilla API key generated on
> the relevant Bugzilla prefs page, and pushes should work again.
>
> ("Mercurial had it first...")
>
> Jeff
> ___
> 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
Intent to ship: Subresource Integrity (SRI)
On 30/12/14 09:40 PM, Francois Marier wrote: > Summary: Allow web authors to add integrity checks to sub-resources. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=992096 > > Spec: http://www.w3.org/TR/SRI/ > > Platforms: all > > Estimated or target release: Q1 of 2015 > > Preference behind which this will be implemented: > security.subResourceIntegrity.enable This landed pref'ed off on Nightly in August. I intend to pref it on in Firefox 43. We pass all of the W3C web-platform tests, the spec is almost finalized and Chrome has already shipped this pref'ed ON (Chrome 45). Francois ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Alternative to Bonsai?
On 15/09/2015 23:53, Boris Zbarsky wrote: > On 9/15/15 11:11 AM, Ben Hearsum wrote: >> I'm pretty sure https://github.com/mozilla/gecko-dev has full history. Thanks to everyone for your suggestions. > Though note that it doesn't have working blame for a lot of files in our > source tree (and especially the ones you'd _want_ to get blame for, in > my experience), so it's of pretty limited use if you're trying to do the > sorts of things you used to be able to do with bonsai. > > I believe gps is working on standing up a web front end for the CVS repo > blame to replace bonsai... But we don't have a working CVS repository any more right? Phil (is confused) -- Philip Chee , http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
