Re: Firefox 55.* in Windows/Ubuntu - every day CPU 100%/Hangs Up. Please to do something!

2017-09-07 Thread Enrico Weigelt, metux IT consult 

On 06.09.2017 09:45, Alexey Zvyagin wrote:


In both OSes i regulary and every day i see the situation when after few work time (may be even 
after 1-5 minutes) of Firefox i see the CPU 100% of Firefox and the Firefox hangs up after... Only 
one way i have for repairing of this: "killall -HUP firefox" command at Ubuntu and 
"End Task" in Windows.


No idea whether it's related - I'm regularily observing similar
problems in older version (eg. 49) - but in my case it comes back
again (sometimes takes several minutes). The problem increases with
the numeber of tabs and seems to happen especially while loading.
A hard case is ebay, maybe because it loads lots of extra urls.

Similar problems w/ TB - busy w/ 100% load for several minutes
and then comes back. (a long existing problem w/ TB). There's a theory
that this could be related to JS GC, but we don't have an good idea
for deeper analysis yet - maybe somebody here has a hint ?


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

Re: Coding style: Placement of binary operators when breaking a long line

2017-09-07 Thread Martin Thomson 
On Fri, Sep 8, 2017 at 1:08 AM, Ehsan Akhgari  wrote:
> The great majority of code changing is quite expected for any project
> switching to clang-format, since as it turns out automated tools are much
> better at doing this grunt work than humans are.  The reason projects choose
> to switch to using clang-format is increasing developer productivity by
> allowing editor/IDE integration for formatting the code as you're editing
> it, ensuring the code formatting remains consistent over time without
> needing to spend invaluable engineering time on it, and being able to stop
> debating whitespace issues and moving on to focus on more productive
> discussions.  ;-)

I am 100% behind this idea.  NSS is already there and it's so nice.

One question, because it hurts me every day now, which version of
clang-format will we use?  NSS actually has checks in CI that will
fail if you submit unformatted code (it gives you a nice patch you can
download and apply to fix the problem even), so we're very particular
about this.  However, my local version of clang-format is more recent.
There are small differences in its handling of certain constructs.
It's been screwing up my pre-commit hook for a while now (I just
haven't gotten around to fixing it just yet).

e.g.,

3.9
-  CheckAcks(client_filters_, 0, {0,  // SH
- 0x0002ULL,  // EE
- 0x00020002ULL}  // CT2
4.0
+  CheckAcks(client_filters_, 0,
+{0,  // SH
+ 0x0002ULL,  // EE
+ 0x00020002ULL}  // CT2

Have we had the version discussion yet?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

2017-09-07 Thread Martin Thomson 
On Fri, Sep 8, 2017 at 5:32 AM, Tom Ritter  wrote:
> On Thu, Sep 7, 2017 at 1:09 PM, Shubhie Panicker via dev-platform
>  wrote:
>> Curious - are there concerns with implementing Client Hints in general?
>
> Yes. But the fingerprinting team (specifically, I'm not sure what
> other teams have done) haven't investigated Client Hints yet to see
> what we may wish to obscure. =)

I reviewed some changes to the spec, and am of the opinion that there
are problems with Client Hints in this area:  see
https://github.com/httpwg/http-extensions/pull/373#pullrequestreview-54009185

That's not a proper review of the sort that Tom is talking about, but
the issues are suggestive of problems.  As with here, the biggest
concern I have is over the amount of control a UA has when it comes to
how this is used.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style question: Meaningless argument names in declarations

2017-09-07 Thread Xidorn Quan 
On Fri, Sep 8, 2017, at 01:16 AM, Emilio Cobos Álvarez wrote:
> This is very context dependent, I'd never omit a name in a function that
> takes (Element& aParent, Element& aChild), but it seems reasonable to
> omit it in the case where there's no better name, like (InsertionKind
> aInsertionKind) or (Element& aElement).

I don't agree with having code style more context dependent.

My concern is that, people don't familiar with the code style enough
would easily get confused by the mixed situation. Context-dependent code
style also means we would not be able to create lint for this kind of
code, and we may have more dispute during review process, which would
make things less productive.

We currently write things like "(Element& aElement)" which seems to be
redundant, but if you see lots of "(Element&)", you may start thinking
that "(Element&, Element&)" is also okay, and argue with reviewer that
you are seeing this kind of naming elsewhere.

I can see that these names aren't very helpful, and the wish to make
code more concise, but I don't think it's worth given that it may
confuse new readers and writers (in addition to confusing existing
contributors who have got used to the current style).

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

Re: OS/2 still supported ?

2017-09-07 Thread Daniel Veditz 
​On Tue, Jul 25, 2017 at 1:04 AM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:

> On 25.07.2017 02:04, Kris Maglione wrote:
>
> The only remaining in-tree references to the XP_OS2 macros are in NSPR
>> and NSS, which are technically separate projects, and have their own
>> sets of supported platforms.
>>
>
> In esr52 there's a bit more:
>

​The ESR branches accept a limited number of stability and security fixes
only. There aren't enough people testing to risk unnecessary patches. The
users of those branches are doing so explicitly for stability reasons and
don't want 'em.

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

Re: Device Memory header and JS API

2017-09-07 Thread Daniel Veditz 
On Thu, Sep 7, 2017 at 11:28 AM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:

> Optimally, the browser should tell nothing about the client - web
> content should written in a way that it works independent from the
> actual client. At least that's how the web originally was designed.
>

​Without some kind of signal everyone gets the least-common-denominator
version of a site (and even then older equipment or phones may result in a
poor experience) or sites will try to guess based on user-agent. Privacy
minded folks can spoof their user agent, sure, but nothing says we can't
create ways to spoof the client-hint responses (allow them to be turned
off).

For images and things maybe CSS could specify some media queries that loads
different resources based on local factors like amount of memory or network
speed, but then that's leaking the same information just in a different way.

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

Re: Device Memory header and JS API

2017-09-07 Thread Fabrice Desre 

On 09/07/2017 11:09 AM, Shubhie Panicker via dev-platform wrote:

Thanks for the comments.

<< The low end is extremely small buckets, and the high end isn't even
fleshed out but I'm certain that's becomes small buckets too >16GB too.
<< (Obviously this doesn't take into account mobile, and I couldn't find
any reports on distribution of android devices by RAM.)
Mobile and Android devices are key use-cases here and low end bucket is
expected to grow significantly, especially due to efforts like Android Go



For very low memory devices, the total memory is not the best signal 
unfortunately. I'm not gonna give precise numbers or names for obvious 
reaons (Shubbie, you can get them from your colleagues) but for instance 
the memory used by modems varies greatly from one SoC vendor to the 
other. The variation may not me so significant to user space when your 
total memory is a few GB, but it really is on devices like those 
targeted by Android Go.
So you will report something that doesn't help a JS lib to build an 
opinionated signal - you should rather report the available memory 
available to web sites, which is a wonderful fingerprinting signal...


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

Changes to how we localize Firefox - one repository to rule a hundred repositories

2017-09-07 Thread Axel Hecht 

Hi,

tl;dr: We'll be using a single French, German, Slovenian localization 
across all of mozilla-central, -beta, -release, -esr-*, starting with 
57. This change will ride the trains.


We call it "cross channel localization", or x-channel in short.

How does that work?

We're creating an artificial repository containing the strings from 
mozilla-central and comm-central. This will expand to contain also the 
strings on -beta, -release, etc, as the change rides the trains. This 
will be one repository, with a single head. See 
https://hg.mozilla.org/users/axel_mozilla.com/en-US for a current draft.


We'll use our existing workflows to create localizations for that 
repository, and those will be hosted in 
https://hg.mozilla.org/l10n-central/.


We'll use those repositories to just build as usual, from m-c, m-b, etc.

Developer impact:

We'll need string IDs to be unique across channels. But that's really 
it. We'll help with a test running in automation checking that, see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1353680.


Benefits for Firefox:

We'll be shipping localizations quicker. We'll be shipping fixes to 
localizations quicker. We'll be dealing with string problems in a 
straight forward way.


Overall, we're expecting localizers to be more involved, and more 
frequently involved, and to generally increase product quality by 
removing obstacles and confusing bits and pieces of where to fix a thing 
and how to make that fix stick.


Are we done yet?

No, there's going to be a number of things we'll need to improve after 
the initial landing. For one, we want to run the tool that creates the 
repository in automation. I'll run it at home for a while to tell the 
difference between problems in my code and your code.
The other interesting bit is going to be to deal with closed heads and 
debugparents as part of merge days. But that has 6 weeks time, as the 
next couple of merges are only forks for x-channel for now.


Timeline:

We've been talking to various stakeholders in the Firefox team, to our 
VCS friends, to localizers for quite some time. Firefox 57 is a force in 
actually landing this, to deliver on our quality expecations. But also 
to deal with the slightly different merge plans that Sylvestre announced 
earlier today. Actually shipping x-channel with 57 is the only really 
sane and polite way to deal with that plan.


The tracking bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1353655.

Happy to answer questions

Axel

PS: a hundred repositories to rule them all? Yeah, we're moving from 3-4 
for each of our ~100 localizations to one for each. We intend to 
continue to ship a different version per locale and Firefox product 
going forward, and that's just easier to digest with independent 
repositories per locale.

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

Re: Device Memory header and JS API

2017-09-07 Thread Tom Ritter 
On Thu, Sep 7, 2017 at 1:09 PM, Shubhie Panicker via dev-platform
 wrote:
> Curious - are there concerns with implementing Client Hints in general?

Yes. But the fingerprinting team (specifically, I'm not sure what
other teams have done) haven't investigated Client Hints yet to see
what we may wish to obscure. =)

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

Re: Coding style question: Meaningless argument names in declarations

2017-09-07 Thread Ehsan Akhgari 

On 09/07/2017 11:16 AM, Emilio Cobos Álvarez wrote:


On 09/07/2017 04:01 PM, Andrew McCreight wrote:

I don't know if it rises to the level of something that should be in the
style guide, but I find the names very useful as a form of lightweight
documentation. Sure, if you are naming your Foo arguments aFoo the names
aren't useful, but for many widely used types like JSObject* and bool
knowing whether the argument is the global or something else is very useful.

Sure, wasn't intending to suggest that we should say "no named arguments
in declarations".

This is very context dependent, I'd never omit a name in a function that
takes (Element& aParent, Element& aChild), but it seems reasonable to
omit it in the case where there's no better name, like (InsertionKind
aInsertionKind) or (Element& aElement).

My question is mostly if this is something people find acceptable.
In some code I have seen people omit the name of arguments to document 
that the callee will ignore the argument passed by the caller, such as 
. 
I think this is probably an area where we want to leave things to 
people's judgment.

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

Re: Device Memory header and JS API

2017-09-07 Thread Shubhie Panicker via dev-platform 
Thanks for the comments.

<< The low end is extremely small buckets, and the high end isn't even
fleshed out but I'm certain that's becomes small buckets too >16GB too.
<< (Obviously this doesn't take into account mobile, and I couldn't find
any reports on distribution of android devices by RAM.)
Mobile and Android devices are key use-cases here and low end bucket is
expected to grow significantly, especially due to efforts like Android Go

.

<< Is there any reason it can't just report that: 'Low Memory' or 'Not Low
Memory'.
In an ideal world we would surface Device Class as "low, medium, high"
etc. However
the browser is not in the best position to make an accurate call that works
for everyone and is future proof, see this section

for why we don't want to provide an opinionated signal and instead choose
to provide a low-level un-opinionated signal.
JS libraries or frameworks will build opinionated signal on top of this, we
don't think the web platform is the right place for this.
That said, the tradeoff is that is that total memory is a fingerprinting
vector.

<< Of course if we implemented client hints we could simply send less
information, like 0.5, 1, and 2. Maybe 4 if some sites really would send
resources large enough to where that is an issue. And I guess Firefox for
Android claims to be able to run on a 384Mb device so maybe 0.25 is a
useful value as well.
We could consider updating to closest, single most significant bit, to
reduce the buckets.
Of course FF could surface a subset (or overlapping set), but being able to
standardize on a common set would be great.

Curious - are there concerns with implementing Client Hints in general?


On Wed, Sep 6, 2017 at 12:58 PM, Andrew Overholt 
wrote:

> On Wed, Sep 6, 2017 at 2:53 PM, Daniel Veditz  wrote:
>
>> I do not know what are plans are about Client Hints in general, whether we
>> intend to or when, and obviously that's a prerequisite.
>>
>
> Client Hints is https://bugzilla.mozilla.org/show_bug.cgi?id=935216, FWIW.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Memory header and JS API

2017-09-07 Thread Enrico Weigelt, metux IT consult 

On 05.09.2017 19:13, Shubhie Panicker via dev-platform wrote:

Hi,

Boris expressed privacy concern with the API and suggested starting a > thread here to get some concrete feedback. We would love to get this> 
feedback and are open to updating the header and API as it would be 
great> to get FF behind this API.

I fully agree. There're already too many similar security problems.
(maybe it's different between countries/cultures, but over here in
Germany we *do* care about privacy.)

Optimally, the browser should tell nothing about the client - web
content should written in a way that it works independent from the
actual client. At least that's how the web originally was designed.

I'd also question the practical usecase. For example, video hosters
already have settings for video quality - which, btw has only small
relation to available memory (bottlenecks are bandwidth and cpu or
vpu power). Adding such an Header/API here just risks web coders
taking even more silly assumptions and adding even more bad code.

Also serving a "light version" of sites like Facebook or Google
Analytics (like mentioned in the google maillist) doesn't seem to be an
good use case to me, too:

#1: Facebook delivers really, really bad code. No idea how they do it,
but typing something sometimes takes several seconds per char. Scrolling
sometimes takes minutes, etc, etc (w/ multiple tabs that even goes up
exponentially) - in Chrome as well as FB. It's just beyond repair.

In contrast, VK just flashes. Quick and simple (like Google once was)
Ergo: when VK provides quite the same functionality w/o any performance
problems (and actually, that isn't such a big deal at all), then FB
is just doing it terribly wrong. I really wonder why such a big company
doesn't get their tech in order.

Well, if FB would honor such an header and serve a really light version
(I have my doubts), then I'd vote for hard-coding 128MB

#2: Google Analytics shouldn't be supported at all - they already far
too invasive (if it wouldn't open pandorra's box, I'd even vote for a
law for blocking them on ISP core routers) - I've blocked them on
my routers.

OTOH, I do see a valid case for *users* (not the computer on its own)
deciding on certain content preferences - on a per-site basis.

But that wouldn't be memory (*ideally*, normal user processes shouldn't
even care how much memory is in a box - let the kernel handle that),
instead things like max. video resolution, sound quality (I'm personally
fine w/ mono, as I only have one operating ear ;-)), etc. Such a setting
should be easily switchable any time (eg. I'm often listening to radio
shows @yt and switch to lowest resolution to save cpu cycles).

BTW: video playback can be much more efficient when using VPUs
(hw-codecs) - especially for embedded/mobile devices. But the 
hw-configuration, and therefore optimal pipeline is pretty device

specific, so it has to be configurable. The best option IMHO would
be using gst and let the user/operator specify the actual pipeline.


--mtx

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

Re: Firefox and clang-cl

2017-09-07 Thread Ehsan Akhgari 

On 09/07/2017 10:12 AM, Ben Kelly wrote:

On Thu, Sep 7, 2017 at 10:09 AM, Nathan Froyd  wrote:


On Thu, Sep 7, 2017 at 10:04 AM, Ben Kelly  wrote:

On Mon, Aug 14, 2017 at 10:44 AM, Tristan Bourvon 
wrote:


Here's the RFC of the overflow builtins:
http://clang-developers.42468.n3.nabble.com/RFC-Introduce-
overflow-builtins-td3838320.html
Along with the tracking issue: https://bugs.llvm.org/show_

bug.cgi?id=12290

And the patch:
https://github.com/llvm-mirror/clang/commit/

98d1ec1e99625176626b0bcd44cef7

df6e89b289

There's also another patch that was added on top of this one which adds
more overflow builtins:
https://github.com/llvm-mirror/clang/commit/

c41c63fbf84cc904580e733d1123d3

b03bb5584c

It seems clear that this optimization could bring big performance
improvements on hot functions. It could also reduce binary size
substantially (we're talking about 14->5 instructions in their case).


Do we have a bug filed to investigate these overflow builtins?  Should we
file one?

There is bug 1356936 for mozilla::CheckedInt; I don't know how many
saturating-style arithmetic implementations we have in the tree, or
whether similar bugs exist for those.


I guess my impression was this would be something we would want the jit to
emit in its bytecode.  But maybe I don't fully understand.


These are LLVM/gcc builtins, which allow the C++ compiler code generator 
to understand that a high-level operation like 
 
is actually just checking whether an addition overflows, so that it can 
generate efficient machine code based on that.  For example, on x86 you 
can use the overflow bit alongside instructions such as JO (jump on 
overflow) or JNO (jump on not overflow) to do these checks more 
efficiently, but without the builtins the compiler won't be able to 
decipher what the IsAddValid function is trying to do and would instead 
generate more inefficient code that does bit manipulation.


If our JIT code emits overflow checks, it can directly emit the more 
efficient machine code as it has an assembler and it doesn't need to 
rely on C++ compiler intrinsics like this.


Hope this helps!

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

Re: Coding style question: Meaningless argument names in declarations

2017-09-07 Thread Emilio Cobos Álvarez 


On 09/07/2017 04:01 PM, Andrew McCreight wrote:
> I don't know if it rises to the level of something that should be in the
> style guide, but I find the names very useful as a form of lightweight
> documentation. Sure, if you are naming your Foo arguments aFoo the names
> aren't useful, but for many widely used types like JSObject* and bool
> knowing whether the argument is the global or something else is very useful.

Sure, wasn't intending to suggest that we should say "no named arguments
in declarations".

This is very context dependent, I'd never omit a name in a function that
takes (Element& aParent, Element& aChild), but it seems reasonable to
omit it in the case where there's no better name, like (InsertionKind
aInsertionKind) or (Element& aElement).

My question is mostly if this is something people find acceptable.

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

Re: Coding style: Placement of binary operators when breaking a long line

2017-09-07 Thread Ehsan Akhgari 

On 09/07/2017 07:23 AM, Jean-Yves Avenard wrote:

On Thu, Sep 7, 2017 at 3:03 AM, Eric Rahm  wrote:

As I said, I was hoping to avoid rehashing this point, but the general
consensus from the last rather contentious post [1] was that changing from
the prevalent style of the codebase for primarily aesthetic reasons was
hard to justify (points about readability were made on both sides). Nick
pointed out that our code base very clearly tilts to the operators on the
end of the line style [2].


Seeing that the plan is after 57, to run clang-format on the entire
codebase (with the exclusions of 3rd party code).
Do we really need to care on what the current code mainly use?


Yes, we do.  The clang-format configuration we use has for the most part 
been derived from the current Coding Style and the prevalent patterns 
existing in our code base.  Where possible we have been modifying 
clang-format according to our needs.  We have indeed upstreamed the 
Mozilla style to clang-format for this very reason: 
.


Post the switch to using clang-format tree-wide, our Coding Style for 
matters that clang-format can automate (such as whitespace formatting 
issues) will be simplified to "run clang-format".  :-)



I don't think it matters, seeing that no matter what, the great
majority of the code will change, as nothing is following the current
coding style to the letter (with the exception of the majority of
dom/media)
The great majority of code changing is quite expected for any project 
switching to clang-format, since as it turns out automated tools are 
much better at doing this grunt work than humans are.  The reason 
projects choose to switch to using clang-format is increasing developer 
productivity by allowing editor/IDE integration for formatting the code 
as you're editing it, ensuring the code formatting remains consistent 
over time without needing to spend invaluable engineering time on it, 
and being able to stop debating whitespace issues and moving on to focus 
on more productive discussions.  ;-)


Still, picking styles that are not completely different with your 
existing code matters in the sense of reducing the pain of going through 
the blames when delving through the history of old code.  To give you an 
extreme example, if we were hypothetically to pick tabs as indentation 
characters in lieu of spaces, that would basically guarantee touching 
almost every line of our code no matter what, whereas the current 
massive restyle of the code doesn't go anywhere close to being as 
drastic of a change.

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

Re: Coding style: Placement of binary operators when breaking a long line

2017-09-07 Thread Ehsan Akhgari 

On 09/07/2017 04:17 AM, Mike Hommey wrote:

On Thu, Sep 07, 2017 at 12:47:51AM -0700, Chris Peterson wrote:

On 2017-09-06 8:06 PM, Ehsan Akhgari wrote:

The interesting points to consider is the data that Nick alluded to in
the previous discussion about the existing prevalent style.

Also, the point you up about the pragmatic aspect of the need to be able
to use automated tools in order to manage our Coding Style is right on.
As things stand, the only viable option of such a tool that I'm aware of
is clang-format, and given the standing situation with regards to what
formatting options we can make that tool support in this case, I think
the pragmatic decision is to pick *one* option here for the placement of
operators across line breaks: either at the end of long lines or in the
beginning of the next line.

The combination of the above points makes me prefer adopting the
proposal to treat all operators like && and ||.

There are only a couple hundred instances of boolean operators after a line
break in mozilla-central C++ code. I know this search is inexact, but it
shows the (small) scale of this usage compared to the proposed
before-line-break style.

https://searchfox.org/mozilla-central/search?q=%5E%5Cs%2B(%3E%7C%3E%3D%7C%3C%7C%3C%3D%7C%3D%3D%7C!%3D)%5Cs%2B(%5Cw%7C%5C()=true=true=.c

Note that there seems to be about the same number of boolean operators
before a line break (if you ignore the ones from generated code)

https://searchfox.org/mozilla-central/search?q=%5Cs(%3E%7C%3E%3D%7C%3C%7C%3C%3D%7C%3D%3D%7C!%3D)%5Cs*%24=true=true=.c
Not really.  Searchfox caps the regex results at 1000.  Local grep is 
much more suitable for this kind of analysis.  On local inbound I have:


$ git grep '\s(>|>=|<|<=|==|!=)\s*$' -- '*.c*' | wc -l
2794
$ git grep '^\s+(>|>=|<|<=|==|!=)\s+(\w|\()' -- '*.c*' | wc -l
419

This of course doesn't include all operators that matter here but the 
trend is pretty clear.

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

Re: Re: Firefox and clang-cl

2017-09-07 Thread Ben Kelly 
On Thu, Sep 7, 2017 at 10:09 AM, Nathan Froyd  wrote:

> On Thu, Sep 7, 2017 at 10:04 AM, Ben Kelly  wrote:
> > On Mon, Aug 14, 2017 at 10:44 AM, Tristan Bourvon 
> > wrote:
> >
> >> Here's the RFC of the overflow builtins:
> >> http://clang-developers.42468.n3.nabble.com/RFC-Introduce-
> >> overflow-builtins-td3838320.html
> >> Along with the tracking issue: https://bugs.llvm.org/show_
> bug.cgi?id=12290
> >> And the patch:
> >> https://github.com/llvm-mirror/clang/commit/
> 98d1ec1e99625176626b0bcd44cef7
> >> df6e89b289
> >>
> >> There's also another patch that was added on top of this one which adds
> >> more overflow builtins:
> >> https://github.com/llvm-mirror/clang/commit/
> c41c63fbf84cc904580e733d1123d3
> >> b03bb5584c
> >>
> >> It seems clear that this optimization could bring big performance
> >> improvements on hot functions. It could also reduce binary size
> >> substantially (we're talking about 14->5 instructions in their case).
> >>
> >
> > Do we have a bug filed to investigate these overflow builtins?  Should we
> > file one?
>
> There is bug 1356936 for mozilla::CheckedInt; I don't know how many
> saturating-style arithmetic implementations we have in the tree, or
> whether similar bugs exist for those.
>

I guess my impression was this would be something we would want the jit to
emit in its bytecode.  But maybe I don't fully understand.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Re: Firefox and clang-cl

2017-09-07 Thread Nathan Froyd 
On Thu, Sep 7, 2017 at 10:04 AM, Ben Kelly  wrote:
> On Mon, Aug 14, 2017 at 10:44 AM, Tristan Bourvon 
> wrote:
>
>> Here's the RFC of the overflow builtins:
>> http://clang-developers.42468.n3.nabble.com/RFC-Introduce-
>> overflow-builtins-td3838320.html
>> Along with the tracking issue: https://bugs.llvm.org/show_bug.cgi?id=12290
>> And the patch:
>> https://github.com/llvm-mirror/clang/commit/98d1ec1e99625176626b0bcd44cef7
>> df6e89b289
>>
>> There's also another patch that was added on top of this one which adds
>> more overflow builtins:
>> https://github.com/llvm-mirror/clang/commit/c41c63fbf84cc904580e733d1123d3
>> b03bb5584c
>>
>> It seems clear that this optimization could bring big performance
>> improvements on hot functions. It could also reduce binary size
>> substantially (we're talking about 14->5 instructions in their case).
>>
>
> Do we have a bug filed to investigate these overflow builtins?  Should we
> file one?

There is bug 1356936 for mozilla::CheckedInt; I don't know how many
saturating-style arithmetic implementations we have in the tree, or
whether similar bugs exist for those.

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

Re: Re: Firefox and clang-cl

2017-09-07 Thread Ben Kelly 
On Mon, Aug 14, 2017 at 10:44 AM, Tristan Bourvon 
wrote:

> Here's the RFC of the overflow builtins:
> http://clang-developers.42468.n3.nabble.com/RFC-Introduce-
> overflow-builtins-td3838320.html
> Along with the tracking issue: https://bugs.llvm.org/show_bug.cgi?id=12290
> And the patch:
> https://github.com/llvm-mirror/clang/commit/98d1ec1e99625176626b0bcd44cef7
> df6e89b289
>
> There's also another patch that was added on top of this one which adds
> more overflow builtins:
> https://github.com/llvm-mirror/clang/commit/c41c63fbf84cc904580e733d1123d3
> b03bb5584c
>
> It seems clear that this optimization could bring big performance
> improvements on hot functions. It could also reduce binary size
> substantially (we're talking about 14->5 instructions in their case).
>

Do we have a bug filed to investigate these overflow builtins?  Should we
file one?

Even if we can't use them on all platforms yet, it might be a nice win on
mac where we lack other optimizations like PGO right now.

Thanks.

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

Re: Coding style question: Meaningless argument names in declarations

2017-09-07 Thread Andrew McCreight 
On Thu, Sep 7, 2017 at 5:07 AM, Emilio Cobos Álvarez 
wrote:

> Hi,
>
> I have a coding style question which I don't see addressed in the coding
> style page.
>
> Given there have been a few threads lately on coding style, I guess I
> should just ask.
>
> We have a lot of meaningless argument names in function declarations, like:
>
>   void DoFoo(Element& aElement);
>
> Or:
>
>   enum class Operation {
>  // ..
>   };
>
>   void DoBar(Operation aOperation);
>
> I personally think those argument names are mostly noise (the type gives
> you the same information), and C++ allows omitting them.
>
> That would make the signature more concise, like:
>
>   void DoBar(Operation);
>
> Which is helpful specially in long signatures.
>
> I don't see anything mentioned in the style guide about this, should it be?
>

I don't know if it rises to the level of something that should be in the
style guide, but I find the names very useful as a form of lightweight
documentation. Sure, if you are naming your Foo arguments aFoo the names
aren't useful, but for many widely used types like JSObject* and bool
knowing whether the argument is the global or something else is very useful.


>  -- Emilio
> ___
> 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

57 beta cycle: 57beta/devedition published earlier + soft freeze

2017-09-07 Thread Sylvestre Ledru 
Hello,

tldr: we are going to do a first merge of m-c => m-b and use the
devedition population one week earlier to push 57.0b1 & 57.0b2.

In order to maximize beta testing, we are going to take advantage of the
fact that we have a different set of users with the developer edition
(which is, since the completion of the dawn project, based on mozilla-beta).
September 14th, we will merge mozilla-central => mozilla-beta and
mozilla-beta => mozilla-release. September 19th, we will push to the
devedition population the first beta of 57. Later, we will be pushing a
second beta to this channel.
In parallel, to minimize the impact on the developer, mozilla-central
will remain 57.0a1 and will be merged to mozilla-beta transparently.
Nightly will become 58.0a1 on September 21th.
The regular beta population will remain on 56 and will be provided
updates to the RC builds.

The milestones are detailed in this Google doc:
https://docs.google.com/document/d/1jeypuqBqEyIh-4qxXT0UnE2aVjetN7uVD8W7L7TbWKg/edit

In parallel, as the soft freeze demonstrated its value during previous
cycles, we are going to use this again during the 57 nightly cycle. From
September 18th, we will ask you to land only bug fixes, stability or
important performance fixes. New development not planned for 57 should
land once mozilla-central will become 58 (September 21th).

Thanks,
Sylvestre

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

Re: Stylo now the default configuration for mozilla-central

2017-09-07 Thread doubleagent03 
On Tuesday, September 5, 2017 at 3:11:18 PM UTC-5, J. Ryan Stinnett wrote:
> Assuming bug 1330412 sticks, Stylo will be the default configuration for
> mozilla-central for all platforms except Android.  Thanks to everyone
> involved with Stylo that helped us reach this stage!
> 
> Nightly users should not notice much change, since there was already an
> active experiment that enabled Stylo for most of the Nightly population.
> 
> To ensure the old style system remains functional as a fallback,
> separate "Stylo
> disabled" test platforms have been added. We will also have a small subset
> of the population using the old style system via experiments.
> 
> As always, if you encounter any issues that could be Stylo related, you can
> check Stylo status in about:support.  Please file a bug[1] in Core :: CSS
> Parsing and Computation with "Stylo: " in the subject, or stop by #servo on
> IRC.
> 
> [1]:
> https://bugzilla.mozilla.org/enter_bug.cgi?component=CSS%20Parsing%20and%20Computation=Core_desc=Stylo%3A%20
> 
> - Ryan

Great news!

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

Re: Coding style question: Meaningless argument names in declarations

2017-09-07 Thread Jean-Yves Avenard 
not answering your question yet, but...

On Thu, Sep 7, 2017 at 2:07 PM, Emilio Cobos Álvarez  wrote:
>
>   enum class Operation {
>  // ..
>   };


that should be:
enum class Operation
{
  // ...
};

https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Control_Structures

simply because only control structure follows the K style of having
the brace at the end.
Just like class and function definition, enum aren't control
structure, as such "left brace goes by itself on the second line and
without extra indentation, in general for C++."

>
>   void DoBar(Operation aOperation);
>
> I personally think those argument names are mostly noise (the type gives
> you the same information), and C++ allows omitting them.
>
> That would make the signature more concise, like:
>
>   void DoBar(Operation);
>
> Which is helpful specially in long signatures.
>
> I don't see anything mentioned in the style guide about this, should it be?

When I don't see anything specific in the style guide, I look at the
long example provided there:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Classes

argument names are always provided in all those examples. As such, I
assume they are to always be there.

It would also not be very consistent for all the functions that take
POD, where there it is definitely required to make your code
consistent.

My $0.02.

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

Coding style question: Meaningless argument names in declarations

2017-09-07 Thread Emilio Cobos Álvarez 
Hi,

I have a coding style question which I don't see addressed in the coding
style page.

Given there have been a few threads lately on coding style, I guess I
should just ask.

We have a lot of meaningless argument names in function declarations, like:

  void DoFoo(Element& aElement);

Or:

  enum class Operation {
 // ..
  };

  void DoBar(Operation aOperation);

I personally think those argument names are mostly noise (the type gives
you the same information), and C++ allows omitting them.

That would make the signature more concise, like:

  void DoBar(Operation);

Which is helpful specially in long signatures.

I don't see anything mentioned in the style guide about this, should it be?

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

Re: Coding style: Placement of binary operators when breaking a long line

2017-09-07 Thread Jean-Yves Avenard 
On Thu, Sep 7, 2017 at 3:03 AM, Eric Rahm  wrote:
> As I said, I was hoping to avoid rehashing this point, but the general
> consensus from the last rather contentious post [1] was that changing from
> the prevalent style of the codebase for primarily aesthetic reasons was
> hard to justify (points about readability were made on both sides). Nick
> pointed out that our code base very clearly tilts to the operators on the
> end of the line style [2].


Seeing that the plan is after 57, to run clang-format on the entire
codebase (with the exclusions of 3rd party code).
Do we really need to care on what the current code mainly use?

I don't think it matters, seeing that no matter what, the great
majority of the code will change, as nothing is following the current
coding style to the letter (with the exception of the majority of
dom/media)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style: Placement of binary operators when breaking a long line

2017-09-07 Thread Mike Hommey 
On Thu, Sep 07, 2017 at 12:47:51AM -0700, Chris Peterson wrote:
> On 2017-09-06 8:06 PM, Ehsan Akhgari wrote:
> > The interesting points to consider is the data that Nick alluded to in
> > the previous discussion about the existing prevalent style.
> > 
> > Also, the point you up about the pragmatic aspect of the need to be able
> > to use automated tools in order to manage our Coding Style is right on.
> > As things stand, the only viable option of such a tool that I'm aware of
> > is clang-format, and given the standing situation with regards to what
> > formatting options we can make that tool support in this case, I think
> > the pragmatic decision is to pick *one* option here for the placement of
> > operators across line breaks: either at the end of long lines or in the
> > beginning of the next line.
> > 
> > The combination of the above points makes me prefer adopting the
> > proposal to treat all operators like && and ||.
> 
> There are only a couple hundred instances of boolean operators after a line
> break in mozilla-central C++ code. I know this search is inexact, but it
> shows the (small) scale of this usage compared to the proposed
> before-line-break style.
> 
> https://searchfox.org/mozilla-central/search?q=%5E%5Cs%2B(%3E%7C%3E%3D%7C%3C%7C%3C%3D%7C%3D%3D%7C!%3D)%5Cs%2B(%5Cw%7C%5C()=true=true=.c

Note that there seems to be about the same number of boolean operators
before a line break (if you ignore the ones from generated code)

https://searchfox.org/mozilla-central/search?q=%5Cs(%3E%7C%3E%3D%7C%3C%7C%3C%3D%7C%3D%3D%7C!%3D)%5Cs*%24=true=true=.c

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

Intent to ship: Use Songti TC and Songti SC as default font for zh locales

2017-09-07 Thread Tim Guan-tin Chien 
Songti TC/SC are new Chinese serif fonts since OS X Mavericks.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1350766

Other vendors:

Chrome and Safari have already use it in their release version.

Extimated target release:

The above bug will ship it to early Beta 57 population and Nightly 57.
If it goes well we should ship this in Release 58.


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

Re: Coding style: Placement of binary operators when breaking a long line

2017-09-07 Thread Chris Peterson 

On 2017-09-06 8:06 PM, Ehsan Akhgari wrote:
The interesting points to consider is the data that Nick alluded to in 
the previous discussion about the existing prevalent style.


Also, the point you up about the pragmatic aspect of the need to be able 
to use automated tools in order to manage our Coding Style is right on. 
As things stand, the only viable option of such a tool that I'm aware of 
is clang-format, and given the standing situation with regards to what 
formatting options we can make that tool support in this case, I think 
the pragmatic decision is to pick *one* option here for the placement of 
operators across line breaks: either at the end of long lines or in the 
beginning of the next line.


The combination of the above points makes me prefer adopting the 
proposal to treat all operators like && and ||.


There are only a couple hundred instances of boolean operators after a 
line break in mozilla-central C++ code. I know this search is inexact, 
but it shows the (small) scale of this usage compared to the proposed 
before-line-break style.


https://searchfox.org/mozilla-central/search?q=%5E%5Cs%2B(%3E%7C%3E%3D%7C%3C%7C%3C%3D%7C%3D%3D%7C!%3D)%5Cs%2B(%5Cw%7C%5C()=true=true=.c
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Kris Maglione and Andrew McCreight are now XPConnect Peers

2017-09-07 Thread Gabor Krizsanits 
Totally deserved. Congrats to both of you!

Gabor

On Thu, Sep 7, 2017 at 1:47 AM, Bobby Holley  wrote:

> XPConnect is not exactly a fun module. When I took the reins from mrbkap
> 4.5 years ago, Peter wiped a tear from his eye and said "Congratulations,
> Blake."
>
> Still, it's at the heart of Gecko, and needs ongoing attention from deep
> hackers. With the old hands busy with other things recently, Kris and
> Andrew have stepped up and done a lot of the heavy lifting, especially
> around Quantum Flow.
>
> Andrew became a peer in May, and Kris become a peer a few minutes ago.
> Please be sure to congratulate me and offer your condolences to Kris and
> Andrew. ;-)
>
> bholley
> ___
> 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