Re: C++ method definition comments

2019-01-29 Thread Karl Tomlinson 
Ehsan Akhgari writes:

> On Mon, Jan 28, 2019 at 2:58 PM Jeff Gilbert  wrote:
>
>> I would much rather revert to:
>> /*static*/ void
>> Foo::Bar()
>>
>> The Foo::Bar is the most relevant part of that whole expression, which
>> makes it nice to keep up against the start of the line.
>>
>
> The clang-format option which allows formatting the way you are suggesting,
> AlwaysBreakAfterDefinitionReturnType, is deprecated, and is likely to be
> removed from a future version of clang-format, so there is no sustainable
> way for us to adopt this suggestion.

Where there's a will there's often a way. e.g.

/*static*/ void  //(clang-format line-break)
Foo::Bar() {

I do like being able to see function names in diff output, but I'm
not so keen on having to put //cflb at the beginning of every
function.  This feels too much like working against the decision
to follow Google style.

With so much code using Google style, I guess there must be tools
to show useful information in diff output, or at least there will
be soon...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ method definition comments

2019-01-29 Thread Karl Tomlinson 
Ehsan Akhgari writes:

> On Mon, Jan 28, 2019 at 6:27 PM Ryan Hunt  wrote:
>
>> [...]
>>
>> So for converting from C-style to C++-style, that would be:
>>
>> /* static */ void Foo::Bar() {
>>  ...
>> }
>>
>> // static
>> void Foo::Bar() {
>>  ...
>> }
>>
>> [...]
>>
>> My one concern would be the presence of other C++-style
>> comments before the method definition. For example [1].
>
> [...]  How about detecting those cases and inserting a newline
> between the comments on the line before, for extra clarity?
>
>> [...]
>>
>> [1]
>> https://hg.mozilla.org/mozilla-central/file/e4b9b1084292/layout/generic/nsFrame.cpp#l1023
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Monday, January 28, 2019 12:51 PM, Ehsan Akhgari <
>> ehsan.akhg...@gmail.com> wrote:
>>
>> [...]
>>
>> The path to least resistance for addressing this problem may be to convert
>> these into C++-style comments and therefore moving them into their own
>> lines.  Would you be OK with that?

I haven't noticed clang-format enforcing its own opinions on
comments when they already follow Google style.

In my experiments clang-format is accepting this:

// Make this Foo Bar.
/* static */
void Foo::Bar() {
 ...
}

The /* */ style comment provides a clear separation from any other
comment on the previous line, without the need for an extra
blank-line.  "don't use blank lines when you don't have to."
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: 64-bits Windows build are now the default on 64-bits Windows

2019-01-29 Thread Mike Hommey 
On Tue, Jan 29, 2019 at 07:59:29AM +0900, Mike Hommey wrote:
> Hi,
> 
> As of bug 1522354, now on autoland, hopefully merged in a few hours,
> the default build you get on a 64-bits Windows machine will be 64-bits,
> instead of 32-bits like it had been forever.
> 
> If you do wish to do a 32-bits build on a 64-bits Windows machine, you
> can add:
> 
> ```
> ac_add_options --target=i686
> ```
> 
> to your mozconfig, and that will do it.

Actually, that, as well as --target=aarch64, announced in
https://groups.google.com/d/msg/mozilla.dev.platform/F8VOvJHP1T0/tXJ7ldeVDAAJ

is likely broken at the moment. Thankfully, that will be fixed with bug
1523540.

Cheers,

Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ method definition comments

2019-01-29 Thread gsquelart 
On Wednesday, January 30, 2019 at 9:57:02 AM UTC+11, Ehsan Akhgari wrote:
> On Mon, Jan 28, 2019 at 7:10 PM  wrote:
> 
> > Just a thought: Would it be worth considering a blank macro, e.g.:
> > static void foo();
> > DECLARED_STATIC void foo() {...}
> >
> > On top of not being confused with other comments around, it could be
> > clang-checked so it's never wrong. (And maybe eventually enforced, like
> > MOZ_IMPLICIT is.)
> >
> 
> Yeah, that could be a future alternative, but it would require someone to
> do the hard work of implementing the required static analysis and landing
> it.  I think Ryan's proposal will probably simplify that process somewhat
> by making it possible to mass-replace a bunch of "// static" comments with
> "DECLARED_STATIC" or some such, but I don't want to hold the good solution
> here for a perfect solution in the future.  I would personally be OK for
> these two to happen incrementally.
> 
> Would you mind filing a bug for this please?
> 
> Thanks,
> Ehsan

Thank you Ehsan. Yes, a phased approach would definitely be the way to go.
https://bugzilla.mozilla.org/show_bug.cgi?id=1523793

I realize now that this doesn't help at all with the issue of valuable 
horizontal real-estate! Sorry for the tangent.

One (partly tongue-in-cheek) solution to make the important function name more 
prominent is to use trailing return types:
`auto Foo::Bar() -> void {`
Note that this is more easily greppable when searching for function names.
And it looks more like Rust.

To help with spacing, the `DECLARED_...` macros could be placed at the end (if 
possible?) :
`void Foo::Bar() DECLARED_STATIC {`
`auto Foo::Bar() -> void DECLARED_STATIC {`
But this feels uglier to me.

Cheers,
Gerald

> > On Tuesday, January 29, 2019 at 10:27:17 AM UTC+11, Ryan Hunt wrote:
> > > Yeah, personally I have found them be useful and don't have an issue
> > with keeping
> > > them. I just wasn't sure if that was a common experience.
> > >
> > > So for converting from C-style to C++-style, that would be:
> > >
> > > /* static */ void Foo::Bar() {
> > >  ...
> > > }
> > >
> > > // static
> > > void Foo::Bar() {
> > >  ...
> > > }
> > >
> > > I think that would be good. My one concern would be the presence of
> > other C++-style
> > > comments before the method definition. For example [1].
> > >
> > > Ideally documentation like that should go in the header by the method
> > declaration, but I
> > > have no idea if we consistently do that.
> > >
> > > [1]
> > https://hg.mozilla.org/mozilla-central/file/e4b9b1084292/layout/generic/nsFrame.cpp#l1023
> > >
> > > Thanks,
> > > Ryan
> > >
> > > ‐‐‐ Original Message ‐‐‐
> > > On Monday, January 28, 2019 12:51 PM, Ehsan Akhgari 
> > wrote:
> > >
> > > > This is indeed one of the cases where the reformat has made things
> > worse.  I think as a couple of people have already said, we'll find that
> > some people do find these annotations useful, even if they're not always
> > consistently present.
> > > >
> > > > The path to least resistance for addressing this problem may be to
> > convert these into C++-style comments and therefore moving them into their
> > own lines.  Would you be OK with that?
> > > >
> > > > Thanks,
> > > > Ehsan
> > > >
> > > > On Fri, Jan 25, 2019 at 11:49 PM Ryan Hunt  wrote:
> > > >
> > > >> Hi all,
> > > >>
> > > >> Quick C++ style question.
> > > >>
> > > >> A common pattern in Gecko is for method definitions to have a comment
> > with the
> > > >> 'static' or 'virtual' qualification.
> > > >>
> > > >> Before the reformat, the comment would be on it's own separate line
> > [1]. Now
> > > >> it's on the main line of the definition [2].
> > > >>
> > > >> For example:
> > > >>
> > > >> /* static */ void
> > > >> Foo::Bar() {
> > > >>   ...
> > > >> }
> > > >>
> > > >> vs.
> > > >>
> > > >> /* static */ void Foo::Bar() {
> > > >>   ...
> > > >> }
> > > >>
> > > >> Personally I think this now takes too much horizontal space from the
> > main
> > > >> definition, and would prefer it to be either on its own line or just
> > removed.
> > > >>
> > > >> Does anyone have an opinion on whether we still want these comments?
> > And if so
> > > >> whether it makes sense to move them back to their own line.
> > > >>
> > > >> (My ulterior motive is that sublime text's indexer started failing to
> > find
> > > >>  these definitions after the reformat, but that should be fixed
> > regardless)
> > > >>
> > > >> If you're interested in what removing these would entail, I wrote a
> > regex to
> > > >> make the change [3].
> > > >>
> > > >> Thanks,
> > > >> Ryan
> > > >>
> > > >> [1]
> > https://hg.mozilla.org/mozilla-central/file/0348d472115d/layout/generic/nsFrame.cpp#l1759
> > > >> [2]
> > https://hg.mozilla.org/mozilla-central/file/e4b9b1084292/layout/generic/nsFrame.cpp#l1756
> > > >> [3]
> > https://hg.mozilla.org/try/rev/31ab3e466b6f15dcdbb1aee47edabc7c358b86f2
> > > >>
> > > >
> > > > --
> > > > Ehsan
> >
> 
> 
> -- 
> Ehsan

Re: C++ method definition comments

2019-01-29 Thread Ehsan Akhgari 
On Mon, Jan 28, 2019 at 7:10 PM  wrote:

> Just a thought: Would it be worth considering a blank macro, e.g.:
> static void foo();
> DECLARED_STATIC void foo() {...}
>
> On top of not being confused with other comments around, it could be
> clang-checked so it's never wrong. (And maybe eventually enforced, like
> MOZ_IMPLICIT is.)
>

Yeah, that could be a future alternative, but it would require someone to
do the hard work of implementing the required static analysis and landing
it.  I think Ryan's proposal will probably simplify that process somewhat
by making it possible to mass-replace a bunch of "// static" comments with
"DECLARED_STATIC" or some such, but I don't want to hold the good solution
here for a perfect solution in the future.  I would personally be OK for
these two to happen incrementally.

Would you mind filing a bug for this please?

Thanks,
Ehsan


> Cheers,
> Gerald
>
> On Tuesday, January 29, 2019 at 10:27:17 AM UTC+11, Ryan Hunt wrote:
> > Yeah, personally I have found them be useful and don't have an issue
> with keeping
> > them. I just wasn't sure if that was a common experience.
> >
> > So for converting from C-style to C++-style, that would be:
> >
> > /* static */ void Foo::Bar() {
> >  ...
> > }
> >
> > // static
> > void Foo::Bar() {
> >  ...
> > }
> >
> > I think that would be good. My one concern would be the presence of
> other C++-style
> > comments before the method definition. For example [1].
> >
> > Ideally documentation like that should go in the header by the method
> declaration, but I
> > have no idea if we consistently do that.
> >
> > [1]
> https://hg.mozilla.org/mozilla-central/file/e4b9b1084292/layout/generic/nsFrame.cpp#l1023
> >
> > Thanks,
> > Ryan
> >
> > ‐‐‐ Original Message ‐‐‐
> > On Monday, January 28, 2019 12:51 PM, Ehsan Akhgari 
> wrote:
> >
> > > This is indeed one of the cases where the reformat has made things
> worse.  I think as a couple of people have already said, we'll find that
> some people do find these annotations useful, even if they're not always
> consistently present.
> > >
> > > The path to least resistance for addressing this problem may be to
> convert these into C++-style comments and therefore moving them into their
> own lines.  Would you be OK with that?
> > >
> > > Thanks,
> > > Ehsan
> > >
> > > On Fri, Jan 25, 2019 at 11:49 PM Ryan Hunt  wrote:
> > >
> > >> Hi all,
> > >>
> > >> Quick C++ style question.
> > >>
> > >> A common pattern in Gecko is for method definitions to have a comment
> with the
> > >> 'static' or 'virtual' qualification.
> > >>
> > >> Before the reformat, the comment would be on it's own separate line
> [1]. Now
> > >> it's on the main line of the definition [2].
> > >>
> > >> For example:
> > >>
> > >> /* static */ void
> > >> Foo::Bar() {
> > >>   ...
> > >> }
> > >>
> > >> vs.
> > >>
> > >> /* static */ void Foo::Bar() {
> > >>   ...
> > >> }
> > >>
> > >> Personally I think this now takes too much horizontal space from the
> main
> > >> definition, and would prefer it to be either on its own line or just
> removed.
> > >>
> > >> Does anyone have an opinion on whether we still want these comments?
> And if so
> > >> whether it makes sense to move them back to their own line.
> > >>
> > >> (My ulterior motive is that sublime text's indexer started failing to
> find
> > >>  these definitions after the reformat, but that should be fixed
> regardless)
> > >>
> > >> If you're interested in what removing these would entail, I wrote a
> regex to
> > >> make the change [3].
> > >>
> > >> Thanks,
> > >> Ryan
> > >>
> > >> [1]
> https://hg.mozilla.org/mozilla-central/file/0348d472115d/layout/generic/nsFrame.cpp#l1759
> > >> [2]
> https://hg.mozilla.org/mozilla-central/file/e4b9b1084292/layout/generic/nsFrame.cpp#l1756
> > >> [3]
> https://hg.mozilla.org/try/rev/31ab3e466b6f15dcdbb1aee47edabc7c358b86f2
> > >>
> > >
> > > --
> > > Ehsan
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ method definition comments

2019-01-29 Thread Ehsan Akhgari 
On Mon, Jan 28, 2019 at 2:58 PM Jeff Gilbert  wrote:

> I would much rather revert to:
> /*static*/ void
> Foo::Bar()
>
> The Foo::Bar is the most relevant part of that whole expression, which
> makes it nice to keep up against the start of the line.
>

The clang-format option which allows formatting the way you are suggesting,
AlwaysBreakAfterDefinitionReturnType, is deprecated, and is likely to be
removed from a future version of clang-format, so there is no sustainable
way for us to adopt this suggestion.


> In a clang-format world, we should feel more free to make such
> deviations from Google Style, since it's all handled for us.
>
> On Mon, Jan 28, 2019 at 10:52 AM Ehsan Akhgari 
> wrote:
>
>
> > This is indeed one of the cases where the reformat has made things worse.
> > I think as a couple of people have already said, we'll find that some
> > people do find these annotations useful, even if they're not always
> > consistently present.
> >
> > The path to least resistance for addressing this problem may be to
> convert
> > these into C++-style comments and therefore moving them into their own
> > lines.  Would you be OK with that?
> >
> > Thanks,
> > Ehsan
> >
> > On Fri, Jan 25, 2019 at 11:49 PM Ryan Hunt  wrote:
> >
> > > Hi all,
> > >
> > > Quick C++ style question.
> > >
> > > A common pattern in Gecko is for method definitions to have a comment
> with
> > > the
> > > 'static' or 'virtual' qualification.
> > >
> > > Before the reformat, the comment would be on it's own separate line
> [1].
> > > Now
> > > it's on the main line of the definition [2].
> > >
> > > For example:
> > >
> > > /* static */ void
> > > Foo::Bar() {
> > >   ...
> > > }
> > >
> > > vs.
> > >
> > > /* static */ void Foo::Bar() {
> > >   ...
> > > }
> > >
> > > Personally I think this now takes too much horizontal space from the
> main
> > > definition, and would prefer it to be either on its own line or just
> > > removed.
> > >
> > > Does anyone have an opinion on whether we still want these comments?
> And
> > > if so
> > > whether it makes sense to move them back to their own line.
> > >
> > > (My ulterior motive is that sublime text's indexer started failing to
> find
> > >  these definitions after the reformat, but that should be fixed
> regardless)
> > >
> > > If you're interested in what removing these would entail, I wrote a
> regex
> > > to
> > > make the change [3].
> > >
> > > Thanks,
> > > Ryan
> > >
> > > [1]
> > >
> https://hg.mozilla.org/mozilla-central/file/0348d472115d/layout/generic/nsFrame.cpp#l1759
> > > [2]
> > >
> https://hg.mozilla.org/mozilla-central/file/e4b9b1084292/layout/generic/nsFrame.cpp#l1756
> > > [3]
> > >
> https://hg.mozilla.org/try/rev/31ab3e466b6f15dcdbb1aee47edabc7c358b86f2
> > >
> > > ___
> > > dev-platform mailing list
> > > dev-platform@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-platform
> > >
> >
> >
> > --
> > Ehsan
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>


-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: C++ method definition comments

2019-01-29 Thread Ehsan Akhgari 
On Mon, Jan 28, 2019 at 6:27 PM Ryan Hunt  wrote:

> Yeah, personally I have found them be useful and don't have an issue with
> keeping
> them. I just wasn't sure if that was a common experience.
>
> So for converting from C-style to C++-style, that would be:
>
> /* static */ void Foo::Bar() {
>  ...
> }
>
> // static
> void Foo::Bar() {
>  ...
> }
>
>
>
> I think that would be good.
>

Great!


> My one concern would be the presence of other C++-style
> comments before the method definition. For example [1].
>

That's nothing that a bit of regex wizardry can't take care of.  :-)  How
about detecting those cases and inserting a newline between the comments on
the line before, for extra clarity?


> Ideally documentation like that should go in the header by the method
> declaration, but I
> have no idea if we consistently do that.
>
> [1]
> https://hg.mozilla.org/mozilla-central/file/e4b9b1084292/layout/generic/nsFrame.cpp#l1023
>
> Thanks,
> Ryan
>
> ‐‐‐ Original Message ‐‐‐
> On Monday, January 28, 2019 12:51 PM, Ehsan Akhgari <
> ehsan.akhg...@gmail.com> wrote:
>
> This is indeed one of the cases where the reformat has made things worse.
> I think as a couple of people have already said, we'll find that some
> people do find these annotations useful, even if they're not always
> consistently present.
>
> The path to least resistance for addressing this problem may be to convert
> these into C++-style comments and therefore moving them into their own
> lines.  Would you be OK with that?
>
> Thanks,
> Ehsan
>
> On Fri, Jan 25, 2019 at 11:49 PM Ryan Hunt  wrote:
>
>> Hi all,
>>
>> Quick C++ style question.
>>
>> A common pattern in Gecko is for method definitions to have a comment
>> with the
>> 'static' or 'virtual' qualification.
>>
>> Before the reformat, the comment would be on it's own separate line [1].
>> Now
>> it's on the main line of the definition [2].
>>
>> For example:
>>
>> /* static */ void
>> Foo::Bar() {
>>   ...
>> }
>>
>> vs.
>>
>> /* static */ void Foo::Bar() {
>>   ...
>> }
>>
>> Personally I think this now takes too much horizontal space from the main
>> definition, and would prefer it to be either on its own line or just
>> removed.
>>
>> Does anyone have an opinion on whether we still want these comments? And
>> if so
>> whether it makes sense to move them back to their own line.
>>
>> (My ulterior motive is that sublime text's indexer started failing to find
>>  these definitions after the reformat, but that should be fixed
>> regardless)
>>
>> If you're interested in what removing these would entail, I wrote a regex
>> to
>> make the change [3].
>>
>> Thanks,
>> Ryan
>>
>> [1]
>> https://hg.mozilla.org/mozilla-central/file/0348d472115d/layout/generic/nsFrame.cpp#l1759
>> [2]
>> https://hg.mozilla.org/mozilla-central/file/e4b9b1084292/layout/generic/nsFrame.cpp#l1756
>> [3]
>> https://hg.mozilla.org/try/rev/31ab3e466b6f15dcdbb1aee47edabc7c358b86f2
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
> --
> Ehsan
>
>
>

-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Process Priority Manager enabled on Nightly for Windows (only)

2019-01-29 Thread Mike Conley 
Hi itielandrh,

Is tab warming taken into account, so that when hovering a background tab,
> its process priority will go back to normal?
>

Yes, this was addressed in this bug
 by dthayer.

Love seeing your work Mike!
>

I'm glad this excites you! Thankfully, I wasn't working alone on this
effort - the Process Priority Manager is a component that we salvaged and
cleaned up from the B2G effort, so the B2G folk laid the groundwork.
dthayer did a bunch of the preparation work to get the feature working on
Windows and ready to test on Nightly. I just so happened to be the one to
flip the bits here right at the end. So thanks to everybody who's gotten us
here. :)

-Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Process Priority Manager enabled on Nightly for Windows (only)

2019-01-29 Thread itielandrh 
I was looking forward to this, thanks!
Is tab warming taken into account, so that when hovering a background tab, its 
process priority will go back to normal?

Love seeing your work Mike!



בתאריך יום שלישי, 29 בינואר 2019 בשעה 20:33:41 UTC+2, מאת Mike Conley:
> (cross-posted to dev-platform and firefox-dev)
> 
> Hi folks,
> 
> Just a heads up that in bug 1476981
> , I just autolanded a
> patch that, when hopefully merged, will enable the Process Priority Manager
> for Firefox Desktop on Nightly on Windows.
> 
> The Process Priority Manager lowers the OS-level process priority for any
> content processes that host *only* background tabs. As soon as one tab in a
> content process is brought to the foreground, the priority is brought back
> to the normal level.
> 
> This should allow foreground tabs to get more CPU cycles dedicated to them,
> which we hope will let users get more things done more quickly in those
> foreground tabs.
> 
> The pref is holding on Nightly to help us shake out bugs. If you notice
> any, bug 1522879  is
> the right metabug to block.
> 
> If you have questions or concerns, please respond to this thread on
> dev-platform (to centralize the conversation).
> 
> Thanks!
> 
> -Mike

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Process Priority Manager enabled on Nightly for Windows (only)

2019-01-29 Thread Mike Conley 
Hey Yoric,

Do we have any idea whether this has an impact on energy use?
>

I think it's plausible, but I don't think we have a super great way to
measure that out in automation or with Telemetry (we might be able to use
things like the Intel Power Gadget to measure locally).

The original intent, however, was not to improve battery life (although
that'd be a pleasant side-effect!), but rather to improve responsiveness
and page load time (the theory being that processes hosting only background
content tabs can't steal as many cycles from foreground tabs).
Responsiveness and page load time is what I'm hoping to pay attention to -
although if people see battery usage improvements, that's great too. :)

-Mike

On Tue, 29 Jan 2019 at 13:49, David Teller  wrote:

> This sounds like a very good thing to have!
>
> Do we have any idea whether this has an impact on energy use?
>
> On 29/01/2019 19:32, Mike Conley wrote:
> > (cross-posted to dev-platform and firefox-dev)
> >
> > Hi folks,
> >
> > Just a heads up that in bug 1476981
> > , I just
> > autolanded a patch that, when hopefully merged, will enable the Process
> > Priority Manager for Firefox Desktop on Nightly on Windows.
> >
> > The Process Priority Manager lowers the OS-level process priority for
> > any content processes that host /only/ background tabs. As soon as one
> > tab in a content process is brought to the foreground, the priority is
> > brought back to the normal level.
> >
> > This should allow foreground tabs to get more CPU cycles dedicated to
> > them, which we hope will let users get more things done more quickly in
> > those foreground tabs.
> >
> > The pref is holding on Nightly to help us shake out bugs. If you notice
> > any, bug 1522879 
> > is the right metabug to block.
> >
> > If you have questions or concerns, please respond to this thread on
> > dev-platform (to centralize the conversation).
> >
> > Thanks!
> >
> > -Mike
> >
> >
> > ___
> > firefox-dev mailing list
> > firefox-...@mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
> >
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Process Priority Manager enabled on Nightly for Windows (only)

2019-01-29 Thread Mike Conley 
(cross-posted to dev-platform and firefox-dev)

Hi folks,

Just a heads up that in bug 1476981
, I just autolanded a
patch that, when hopefully merged, will enable the Process Priority Manager
for Firefox Desktop on Nightly on Windows.

The Process Priority Manager lowers the OS-level process priority for any
content processes that host *only* background tabs. As soon as one tab in a
content process is brought to the foreground, the priority is brought back
to the normal level.

This should allow foreground tabs to get more CPU cycles dedicated to them,
which we hope will let users get more things done more quickly in those
foreground tabs.

The pref is holding on Nightly to help us shake out bugs. If you notice
any, bug 1522879  is
the right metabug to block.

If you have questions or concerns, please respond to this thread on
dev-platform (to centralize the conversation).

Thanks!

-Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does mozilla allow modification of Strings

2019-01-29 Thread Boris Zbarsky 

On 1/29/19 4:37 AM, Nanday Dan wrote:

I added the variable to FakeString.  But still application crashes.


Sure, unless you also fixed the Rust interop issue.

-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does mozilla allow modification of Strings

2019-01-29 Thread Nanday Dan 
On Tuesday, January 29, 2019 at 12:22:08 AM UTC+5:30, Kris Maglione wrote:
> >Is it possible to add an  extra variable to mozilla string(nsTStringRepr).
> >
> >
> >I added a bool variable to nsTStringRepr class in  Xpcom/Strings/
> 
> As something of a side note, the general way to do this is to 
> add a new data or class flag, and store it in one of the 
> existing fields:
>

I think storing in existing fields will break the actual usage/functioning of 
those fields and it will make  more complex.  So I felt like adding a new flag 
will not affect normal functioning of it.

 
> https://searchfox.org/mozilla-central/rev/5c8ea961d04767db723a0a15e3a8f7fbca154129/xpcom/string/nsTStringRepr.h#300-301
> 
> Changing the size or layout of the string class is more or less 
> guaranteed to cause problems. Aside from affecting the size and 
> padding of thousands of classes, the strings API is some of the 
> oldest code in Gecko, and there is almost certainly some subtle 
> code which makes assumptions about its layout, and will break if 
> it changes. The Rust bindings are one such example (as you saw), 
> but there are almost certainly others as well.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does mozilla allow modification of Strings

2019-01-29 Thread Nanday Dan 
On Monday, January 28, 2019 at 9:09:05 PM UTC+5:30, Boris Zbarsky wrote:
> On 1/28/19 10:30 AM, Nanday Dan wrote:
> > Sorry, I forgot to mention that I commented those lines too.
> 
> If you comment those lines, you will likely end up with code reading 
> random values for your boolean at best and crashing at worst (if you 
> added the boolean at the end; if not, it's just all going to be bad). 
> You need to make sure that the layout of FakeString exactly matches the 
> layout of nsString, probably by adding the same boolean to FakeString.
> 
> -Boris

I added the variable to FakeString.  But still application crashes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform