Building mozilla-central with clang + icecream

[zbraniecki]

I tried to build m-c today with clang 5.0 and icecream using the following 
mozconfig:


```
mk_add_options MOZ_MAKE_FLAGS="-j$(icecc-jobs)"

mk_add_options 'export CCACHE_PREFIX=icecc'
mk_add_options "export RUSTC_WRAPPER=sccache" 

export CC=clang
export CXX=clang++

ac_add_options --with-ccache

```

The result is an error during config:

```
 0:02.58 checking the target C compiler version... 5.0.0
 0:05.91 checking the target C compiler works... no
 0:05.91 DEBUG: Creating `/tmp/conftest.oIC8nq.c` with content:
 0:05.91 DEBUG: |
 0:05.91 DEBUG: | int
 0:05.91 DEBUG: | main(void)
 0:05.91 DEBUG: | {
 0:05.91 DEBUG: |
 0:05.91 DEBUG: |   ;
 0:05.91 DEBUG: |   return 0;
 0:05.91 DEBUG: | }
 0:05.91 DEBUG: Executing: `/usr/bin/ccache /usr/bin/clang -std=gnu99 -c 
/tmp/conftest.oIC8nq.c`
 0:05.91 DEBUG: The command returned non-zero exit status 127.
 0:05.91 DEBUG: Its error output was:
 0:05.91 DEBUG: | usr/bin/clang: error while loading shared libraries: 
libLLVM-5.0.so: cannot open shared object file: No such file or directory
 0:05.91 DEBUG: | ICECC[8371] 17:45:53: Compiled on 10.251.24.73
 0:05.91 ERROR: Failed compiling a simple C source with the target C compiler
 0:05.94 *** Fix above errors and then restart with\
 0:05.94"/usr/bin/make -f client.mk build"
 0:05.94 make[2]: *** [/projects/mozilla-unified/client.mk:2
```

I know I can build using gcc+icecream or using clang without icecream, but does 
anyone know how to combine clang and icecream to make it work?

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

On the merits and demerits of ECC for desktop use (was: More ThinkStation P710 Nvidia tips)

[Kris Maglione]

This thread has gone way off the rails. Can you please take it 
somewhere else? It's pretty wildly off topic for this list at 
this point.


Thanks.

On Mon, Nov 06, 2017 at 04:56:18PM -0800, Jeff Gilbert wrote:

My understanding of current policy is that ECC is not required. (and
not even an option with MacBook Pros) Given the volume of development
that happens unhindered on our developers' many, many non-ECC
machines, I believe the burden of proof-of-burden is on the pro-ECC
argument to show that it's likely to be a worthwhile investment for
our use-cases.

As for evidence for lack of ECC being a non-issue, I call to witness
the vast majority of Firefox development, most applicably that portion
done in the last ten years, and especially all MacOS development
excluding the very few Mac Pros we have.

If we've given developers ECC machines already when non-ECC was an
option, absent a positive request for ECC from the developer, I would
consider this to have been a minor mistake.

On Mon, Nov 6, 2017 at 3:03 PM, Gabriele Svelto  wrote:

On 06/11/2017 22:44, Jeff Gilbert wrote:

Price matters, since every dollar we spend chasing ECC would be a
dollar we can't allocate towards perf improvements, hardware refresh
rate, or simply more machines for any build clusters we may want.


And every day our developers or IT staff waste chasing apparently random
issues is a waste of both money and time.


The paper linked above addresses massive compute clusters, which seems
to have limited implications for our use-cases.


The clusters are 6000 and 8500 nodes respectively, quite small by
today's standards. How many developers do we have? Hundreds for sure, it
could be a thousand looking at our current headcount so we're in the
same ballpark.


Nearly every machine we do development on does not currently use ECC.
I don't see why that should change now.


Not true. The current Xeon E5-based ThinkStation P710 available from
Service Now has ECC memory and so did the previous models in the last
five years. Having a workstation available w/o ECC would actually be a
step backwards.


To me, ECC for desktop compute
workloads crosses the line into jumping at shadows, since "restart
your machine slightly more often than otherwise" is not onerous.

Do you have data to prove that this is not an issue?

 Gabriele

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

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

[Jeff Gilbert]

My understanding of current policy is that ECC is not required. (and
not even an option with MacBook Pros) Given the volume of development
that happens unhindered on our developers' many, many non-ECC
machines, I believe the burden of proof-of-burden is on the pro-ECC
argument to show that it's likely to be a worthwhile investment for
our use-cases.

As for evidence for lack of ECC being a non-issue, I call to witness
the vast majority of Firefox development, most applicably that portion
done in the last ten years, and especially all MacOS development
excluding the very few Mac Pros we have.

If we've given developers ECC machines already when non-ECC was an
option, absent a positive request for ECC from the developer, I would
consider this to have been a minor mistake.

On Mon, Nov 6, 2017 at 3:03 PM, Gabriele Svelto  wrote:
> On 06/11/2017 22:44, Jeff Gilbert wrote:
>> Price matters, since every dollar we spend chasing ECC would be a
>> dollar we can't allocate towards perf improvements, hardware refresh
>> rate, or simply more machines for any build clusters we may want.
>
> And every day our developers or IT staff waste chasing apparently random
> issues is a waste of both money and time.
>
>> The paper linked above addresses massive compute clusters, which seems
>> to have limited implications for our use-cases.
>
> The clusters are 6000 and 8500 nodes respectively, quite small by
> today's standards. How many developers do we have? Hundreds for sure, it
> could be a thousand looking at our current headcount so we're in the
> same ballpark.
>
>> Nearly every machine we do development on does not currently use ECC.
>> I don't see why that should change now.
>
> Not true. The current Xeon E5-based ThinkStation P710 available from
> Service Now has ECC memory and so did the previous models in the last
> five years. Having a workstation available w/o ECC would actually be a
> step backwards.
>
>> To me, ECC for desktop compute
>> workloads crosses the line into jumping at shadows, since "restart
>> your machine slightly more often than otherwise" is not onerous.
> Do you have data to prove that this is not an issue?
>
>  Gabriele
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

[Gabriele Svelto]

On 06/11/2017 22:44, Jeff Gilbert wrote:
> Price matters, since every dollar we spend chasing ECC would be a
> dollar we can't allocate towards perf improvements, hardware refresh
> rate, or simply more machines for any build clusters we may want.

And every day our developers or IT staff waste chasing apparently random
issues is a waste of both money and time.

> The paper linked above addresses massive compute clusters, which seems
> to have limited implications for our use-cases.

The clusters are 6000 and 8500 nodes respectively, quite small by
today's standards. How many developers do we have? Hundreds for sure, it
could be a thousand looking at our current headcount so we're in the
same ballpark.

> Nearly every machine we do development on does not currently use ECC.
> I don't see why that should change now.

Not true. The current Xeon E5-based ThinkStation P710 available from
Service Now has ECC memory and so did the previous models in the last
five years. Having a workstation available w/o ECC would actually be a
step backwards.

> To me, ECC for desktop compute
> workloads crosses the line into jumping at shadows, since "restart
> your machine slightly more often than otherwise" is not onerous.
Do you have data to prove that this is not an issue?

 Gabriele



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Nightly Start Time and Daylight Savings

[Jörg Knobloch]

On 06/11/2017 18:46, Justin Wood wrote:

Now with Taskcluster the start time is anchored in UTC so doesn't move
along with Daylight Savings, currently anchoring at 10am and 10pm UTC.


Is that connected to merge times? Should the merges into M-C be done 
just before those two times?


Right now it's 10:40 PM UTC and no merge yet to be seen.

Jörg.

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

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

[Jeff Gilbert]

Price matters, since every dollar we spend chasing ECC would be a
dollar we can't allocate towards perf improvements, hardware refresh
rate, or simply more machines for any build clusters we may want.

The paper linked above addresses massive compute clusters, which seems
to have limited implications for our use-cases.

Nearly every machine we do development on does not currently use ECC.
I don't see why that should change now. To me, ECC for desktop compute
workloads crosses the line into jumping at shadows, since "restart
your machine slightly more often than otherwise" is not onerous.

On Mon, Nov 6, 2017 at 9:19 AM, Gregory Szorc  wrote:
>
>
>> On Nov 6, 2017, at 05:19, Gabriele Svelto  wrote:
>>
>>> On 04/11/2017 01:10, Jeff Gilbert wrote:
>>> Clock speed and core count matter much more than ECC. I wouldn't chase
>>> ECC support for general dev machines.
>>
>> The Xeon-W SKUs I posted in the previous thread all had identical or
>> higher clock speeds than equivalent Core i9 SKUs and ECC support with
>> the sole exception of the i9-7980XE which has slightly higher (100MHz)
>> peak turbo clock than the Xeon W-2195.
>>
>> There is IMHO no performance-related reason to skimp on ECC support
>> especially for machines that will sport a significant amount of memory.
>>
>> Importance of ECC memory is IMHO underestimated mostly because it's not
>> common and thus users do not realize they may be hitting memory errors
>> more frequently than they realize. My main workstation is now 5 years
>> old and has accumulated 24 memory errors; that may not seem much but if
>> it happens at a bad time, or in a bad place, they can ruin your day or
>> permanently corrupt your data.
>>
>> As another example of ECC importance my laptop (obviously) doesn't have
>> ECC support and two years ago had a single bit that went bad in the
>> second DIMM. The issue manifested itself as internal compiler errors
>> while building Fennec. The first time I just pulled again from central
>> thinking it was a fluke, the second I updated the build dependencies
>> which I hadn't done in a while thinking that an old GCC might have been
>> the cause. It was not until the third day with a failure that I realized
>> what was happening. A 2-hours long memory test showed me the second DIMM
>> was bad so I removed it, ordered a new one and went on to check my
>> machine. I had to purge my compilation cache because garbage had
>> accumulated in there, run an hg verify on my repo as well as verifying
>> all the installed packages for errors. Since I didn't have access to my
>> main workstation at the time I had wasted 3 days chasing the issue and
>> my workflow was slowed down by a cold compilation cache and a gimped
>> machine (until I could replace the DIMM).
>>
>> This is not common, but it's not rare either and we now have hundreds of
>> developers within Mozilla so people are going to run into issues that
>> can be easily prevented by having ECC memory.
>>
>> That being said ECC memory also makes machines less susceptible to
>> Rowhammer-like attacks and makes them detectable while they are happening.
>>
>> For a more in-depth reading on the matter I suggest reading "Memory
>> Errors in Modern Systems - The Good, The Bad, and The Ugly" [1] in which
>> the authors analyze memory errors on live systems over two years and
>> argue that SEC-DED ECC (the type of protection you usually get on
>> workstations) is often insufficient and even chipkill ECC (now common on
>> most servers) is not enough to catch all errors happening during real
>> world use.
>>
>> Gabriele
>>
>> [1] https://www.cs.virginia.edu/~gurumurthi/papers/asplos15.pdf
>>
>
> The Xeon-W’s are basically the i9’s (both Skylake-X) with support for ECC, 
> more vPRO, and AMT. The Xeon-W’s lack Turbo 3.0 (preferred core). However, 
> Turbo 2.0 apparently reaches the same MHz, so I don’t think it matters much. 
> There are some other differences with regards to PCIe lanes, chipset, etc.
>
> Another big difference is price. The Xeon’s cost a lot more.
>
> For building Firefox, the i9’s and Xeon-W are probably very similar (and is 
> something we should test). It likely comes down to whether you want to pay a 
> premium for ECC and other Xeon-W features. I’m not in a position to answer 
> that.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

talos + performance tooling update + elective session to meet us in person

[jmaher]

I haven't posted in a while, but I wanted to let everyone know what is new with 
Talos and Performance Sheriffing.

I have a few blog posts outlining more details- in total we have 1127 different 
perf metrics we track per commit and for Firefox 55, 56, and 57 >=50 
regressions files/release [1]

Most of this work is done by Ionut [2] who started as a full time Performance 
Sheriff and Tool hacker earlier this year.

also in the last 6 months we have added or significantly edited 10+ Talos tests 
[3] along with many updates for new measurements to collect or methods to run 
tests.

Going forward we have plans for some upcoming work:
1) new hardware by end of Q1 (linux/windows - testing linux hardware this 
week).  This will be new machines in a new datacenter with Intel graphics cards
2) more changes in tests and updated benchmarks 
3) cleaning up and sheriffing AWFY alerts (we have a lot, we just ignore them)
4) a pass at making running and debugging Firefox easier within Talos
5) some proposals and prototypes of making AWFY easier to maintain and run via 
Try (custom hardware test coverage)
6) revisiting webextensions, heavy profiles, mitmproxy tools, tp6 pageset and 
actions, and checking in on collecting the hero element.

And as a bonus, we have an elective session at the upcoming Mozilla All Hands 
in Austin regarding hacking on Talos which is a great time to come and learn 
about what tools exist, how to add a new test, ask those nagging questions 
about why things are named funny or how to interpret results.

Thanks to many people who have contributed to improving our performance tests 
and tooling over the last 6 months.


[1] 
https://elvis314.wordpress.com/2017/11/01/keeping-an-eye-on-performance-alerts/
[2] 
https://elvis314.wordpress.com/2017/10/18/a-formal-introduction-to-ionut-goldan-mozillas-new-performance-sheriff-and-tool-hacker/
[3]
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Nightly Start Time and Daylight Savings

[Chris Peterson]

On 2017-11-06 9:46 AM, Justin Wood wrote:

Now with Taskcluster the start time is anchored in UTC so doesn't move
along with Daylight Savings, currently anchoring at 10am and 10pm UTC.


How long do the Nightly builds typically take? If the builds are started 
at 10am and 10pm UTC (2am and 5pm PST), when will the updates be live?

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

Nightly Start Time and Daylight Savings

[Justin Wood]

Hey Everyone,

I was alerted to a confusion about when Nightlies Start since the US
Daylight Savings change this past weekend.

Previously [on buildbot] Nightlies would start at 3am Pacific Time.

Now with Taskcluster the start time is anchored in UTC so doesn't move
along with Daylight Savings, currently anchoring at 10am and 10pm UTC.

This has some implication for when you may expect to see new nightlies
available in your own local timezone.

Thank You,
~Justin Wood (Callek)
Release Engineering
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

[Gregory Szorc]

> On Nov 6, 2017, at 05:19, Gabriele Svelto  wrote:
> 
>> On 04/11/2017 01:10, Jeff Gilbert wrote:
>> Clock speed and core count matter much more than ECC. I wouldn't chase
>> ECC support for general dev machines.
> 
> The Xeon-W SKUs I posted in the previous thread all had identical or
> higher clock speeds than equivalent Core i9 SKUs and ECC support with
> the sole exception of the i9-7980XE which has slightly higher (100MHz)
> peak turbo clock than the Xeon W-2195.
> 
> There is IMHO no performance-related reason to skimp on ECC support
> especially for machines that will sport a significant amount of memory.
> 
> Importance of ECC memory is IMHO underestimated mostly because it's not
> common and thus users do not realize they may be hitting memory errors
> more frequently than they realize. My main workstation is now 5 years
> old and has accumulated 24 memory errors; that may not seem much but if
> it happens at a bad time, or in a bad place, they can ruin your day or
> permanently corrupt your data.
> 
> As another example of ECC importance my laptop (obviously) doesn't have
> ECC support and two years ago had a single bit that went bad in the
> second DIMM. The issue manifested itself as internal compiler errors
> while building Fennec. The first time I just pulled again from central
> thinking it was a fluke, the second I updated the build dependencies
> which I hadn't done in a while thinking that an old GCC might have been
> the cause. It was not until the third day with a failure that I realized
> what was happening. A 2-hours long memory test showed me the second DIMM
> was bad so I removed it, ordered a new one and went on to check my
> machine. I had to purge my compilation cache because garbage had
> accumulated in there, run an hg verify on my repo as well as verifying
> all the installed packages for errors. Since I didn't have access to my
> main workstation at the time I had wasted 3 days chasing the issue and
> my workflow was slowed down by a cold compilation cache and a gimped
> machine (until I could replace the DIMM).
> 
> This is not common, but it's not rare either and we now have hundreds of
> developers within Mozilla so people are going to run into issues that
> can be easily prevented by having ECC memory.
> 
> That being said ECC memory also makes machines less susceptible to
> Rowhammer-like attacks and makes them detectable while they are happening.
> 
> For a more in-depth reading on the matter I suggest reading "Memory
> Errors in Modern Systems - The Good, The Bad, and The Ugly" [1] in which
> the authors analyze memory errors on live systems over two years and
> argue that SEC-DED ECC (the type of protection you usually get on
> workstations) is often insufficient and even chipkill ECC (now common on
> most servers) is not enough to catch all errors happening during real
> world use.
> 
> Gabriele
> 
> [1] https://www.cs.virginia.edu/~gurumurthi/papers/asplos15.pdf
> 

The Xeon-W’s are basically the i9’s (both Skylake-X) with support for ECC, more 
vPRO, and AMT. The Xeon-W’s lack Turbo 3.0 (preferred core). However, Turbo 2.0 
apparently reaches the same MHz, so I don’t think it matters much. There are 
some other differences with regards to PCIe lanes, chipset, etc.

Another big difference is price. The Xeon’s cost a lot more.

For building Firefox, the i9’s and Xeon-W are probably very similar (and is 
something we should test). It likely comes down to whether you want to pay a 
premium for ECC and other Xeon-W features. I’m not in a position to answer that.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Website memory leaks

[Nick Fitzgerald]

On Mon, Nov 6, 2017 at 1:53 AM, David Teller  wrote:

> I wanted to add something like that to about:performance, but at the
> time, my impression was that we did not have sufficient platform data on
> where allocations come from to provide something convincing.
>

​The SpiderMonkey Debugger API has hooks to capture the JS stack with some
probability for each JS object allocation:
https://developer.mozilla.org/en-US/docs/Tools/Debugger-API/Debugger.Memory#Allocation_Site_Tracking

The probability allows you to dial up or down the overhead vs amount of
data trade off.

The API was designed in such a way that it doesn't disable ion compilation
when enabled. It's not somethign we' want on all the time for everyone, but
should have low enough overhead that we could turn it on in something like
about:performance.

Would be great to expand that API to observe JS string allocations as
well.​​ C++ allocations could be useful too, but there are a lot more open
questions there.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Any intent to implement the W3C generic sensor API in Firefox?

[Jonathan Kingston]

> Does this API avoid the problems described in
https://groups.google.com/forum/#!topic/mozilla.dev.platform/45XApRxACaM ?

Which specific issues?
The API in the specification is promise ready by using the permissions API,
is behind a permission prompt and requires a secure context.

My understanding is that there hasn't been a rework of the orientation
specification in regards to the Generic Sensor API but there has for
Ambient Light.

We could trial this for Ambient Light perhaps, given that we want to remove
the other implementation?


On Thu, Nov 2, 2017 at 5:14 PM, Boris Zbarsky  wrote:

> On 11/2/17 12:54 PM, hoehn6...@gmail.com wrote:
>
>> note: Chrome 63 does support it in it early version already
>>
>
> I should note that this is slightly misleading.  According to
> https://groups.google.com/a/chromium.org/forum/?utm_medium=
> email&utm_source=footer#!msg/blink-dev/2zPZt3watBk/M4qcI8wlBwAJ Chrome is
> doing an experiment, in which they will support this API in versions 63-65
> only, as an origin trial, after which the experiment will end.
>
> If someone likes to see a code snipped how it can be used with google's
>> cardboard to detect the magnetic "button", I provided something at
>> https://stackoverflow.com/questions/40270350/detect-google-
>> cardboard-magnetic-button-click-in-javascript
>>
>
> Right, as this post notes it's disabled by default unless you force-enable
> it or participate in the origin trial.  I'm not sure why your mail was
> worded to make it sound like Chrome 63 shipped actual support
>
>
> -Boris
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Pulsebot in #developers

[Nicolas B. Pierron]

I second Kris on the fact that the main reason I go to #developer is because 
of the reviewer / author ping that I get.


I am still looking into patches which are submitted when I am mentioned as a 
reviewer, in case someone is pushing code without applying nits, or with 
additional un-reviewed modifications.


As of today, I mostly used #developers as a hub to be redirected to the 
right channels, such as #bugzilla, #ateam, #necko, …  So the large volume of 
pulsebot messages has never been something I really cared for.


Is #developers supposed to be used differently?

On 11/04/2017 07:38 PM, Kris Maglione wrote:
For what it's worth, I quite like having pulsebot in #developers. I'll admit 
the channel feels different since pulsebot started reporting there. But I've 
also seen a lot of discussions started based on some commit it reported. And 
a lot of the time, I only even think to check #developers when I get a 
highlight from a commit I landed or reviewed, and then stumble on some 
interesting topic.


That said, pre-pulsebot, #developers was not exactly easy to follow either. 
There tended to be (and still tend to be, really) several unrelated 
discussions going on at the same time (several of which involved the same 
person or people) that were hard to follow unless you were part of them from 
the start. These days, more of that discussion tends to happen in 
area-specific channels like #content, #jsapi, #fx-team, ... where it's 
easier to follow.


On Sat, Nov 04, 2017 at 12:44:32PM +0100, Philipp Kewisch wrote:

Hey Folks,

I'm a big fan of having development discussions in the open, and in the
past #developers has been the prime place to do that. Even if the
benefit may not be apparent vs. having a private discussion or using a
closed channel, I think this is one of many ways to increase interest
within the community. Back when I got started with Mozilla as a
volunteer, I enjoyed reading discussions in #developers because they
allowed me to peek into things that Mozilla developers were working on,
and at times got me interested in the code that was being talked about.

One thing that has recently "gotten in the way" of this is pulsebot. I
acknowledge the usefulness of getting notifications on checkin, but it
does add a lot of noise to #developers. Questions asked or discussions
quickly fade away when pulsebot sends another dozen messages due to
checkins and merges. How much exactly becomes apparent when you visit
https://mozilla.logbot.info/developers/stats : pulsebot has said more
than twice as much as anyone else.

Of course you could say, why don't I just ignore pulsebot? The point is
that only few will actually do so. My impression over time is that less
of the questions I have asked are being answered, and my suspicion is
that in part, people qualified to answer will just not see it in
scrollback between all the pulsebot messages.

Long story short, can we move pulsebot to a separate channel so that
people can opt-in to, and encourage people to discuss their Gecko
development topics in #developers again?

Philip



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

Re: Pulsebot in #developers

[David Major]

I use #developers for two things:

1. I prefer to keep my discussions in smaller topic channels, but for my
sanity I also try to keep my channel list small. There is a large set of
people whom I ping roughly once a month and can't be bothered matching
channels with. #developers is my "lowest common denominator" for talking to
those people.

2. To cast the widest possible net for immediate help with some sudden
roadblock or unfamiliar tool etc.

I don't really care whether pulsebot gets moved, but it won't change my use
of #developers.


On Mon, Nov 6, 2017 at 8:13 AM, Gijs Kruitbosch 
wrote:

> On 06/11/2017 12:49, Philipp Kewisch wrote:
>
>> If there is a better place to ask ad-hoc questions about Gecko, I am
>> happy to go there (and we should make sure the channel is promoted in
>> our docs).
>>
>
> I think different teams have ended up with different IRC channels, as Kris
> said. Frontend Firefox stuff tends to go in #fx-team, and #content, #jsapi
> and similar channels each cater to their own "niche", so to speak.
>
> I can see how less usage of IRC can lead to the situation we have now.
>> As long as there is an (open) replacement that is more accepted nowadays
>> I think this is fine, but aside from that I think we should find a way
>> to promote discussing Firefox and Platform issues in the open again.
>>
>
> I am not aware of people discussing Firefox or Platform *engineering*
> issues in other places, open or otherwise. I am aware of incidental
> non-engineering folks using Slack for bugreporting (unsurprisingly, a lot
> of those questions get answered with "file a bug in bugzilla"), but it
> seems to me that's not what you're talking about...
>
> ~ Gijs
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

[Gabriele Svelto]

On 04/11/2017 01:10, Jeff Gilbert wrote:
> Clock speed and core count matter much more than ECC. I wouldn't chase
> ECC support for general dev machines.

The Xeon-W SKUs I posted in the previous thread all had identical or
higher clock speeds than equivalent Core i9 SKUs and ECC support with
the sole exception of the i9-7980XE which has slightly higher (100MHz)
peak turbo clock than the Xeon W-2195.

There is IMHO no performance-related reason to skimp on ECC support
especially for machines that will sport a significant amount of memory.

Importance of ECC memory is IMHO underestimated mostly because it's not
common and thus users do not realize they may be hitting memory errors
more frequently than they realize. My main workstation is now 5 years
old and has accumulated 24 memory errors; that may not seem much but if
it happens at a bad time, or in a bad place, they can ruin your day or
permanently corrupt your data.

As another example of ECC importance my laptop (obviously) doesn't have
ECC support and two years ago had a single bit that went bad in the
second DIMM. The issue manifested itself as internal compiler errors
while building Fennec. The first time I just pulled again from central
thinking it was a fluke, the second I updated the build dependencies
which I hadn't done in a while thinking that an old GCC might have been
the cause. It was not until the third day with a failure that I realized
what was happening. A 2-hours long memory test showed me the second DIMM
was bad so I removed it, ordered a new one and went on to check my
machine. I had to purge my compilation cache because garbage had
accumulated in there, run an hg verify on my repo as well as verifying
all the installed packages for errors. Since I didn't have access to my
main workstation at the time I had wasted 3 days chasing the issue and
my workflow was slowed down by a cold compilation cache and a gimped
machine (until I could replace the DIMM).

This is not common, but it's not rare either and we now have hundreds of
developers within Mozilla so people are going to run into issues that
can be easily prevented by having ECC memory.

That being said ECC memory also makes machines less susceptible to
Rowhammer-like attacks and makes them detectable while they are happening.

For a more in-depth reading on the matter I suggest reading "Memory
Errors in Modern Systems - The Good, The Bad, and The Ugly" [1] in which
the authors analyze memory errors on live systems over two years and
argue that SEC-DED ECC (the type of protection you usually get on
workstations) is often insufficient and even chipkill ECC (now common on
most servers) is not enough to catch all errors happening during real
world use.

 Gabriele

[1] https://www.cs.virginia.edu/~gurumurthi/papers/asplos15.pdf



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Pulsebot in #developers

[Gijs Kruitbosch]

On 06/11/2017 12:49, Philipp Kewisch wrote:

If there is a better place to ask ad-hoc questions about Gecko, I am
happy to go there (and we should make sure the channel is promoted in
our docs).


I think different teams have ended up with different IRC channels, as 
Kris said. Frontend Firefox stuff tends to go in #fx-team, and #content, 
#jsapi and similar channels each cater to their own "niche", so to speak.



I can see how less usage of IRC can lead to the situation we have now.
As long as there is an (open) replacement that is more accepted nowadays
I think this is fine, but aside from that I think we should find a way
to promote discussing Firefox and Platform issues in the open again.


I am not aware of people discussing Firefox or Platform *engineering* 
issues in other places, open or otherwise. I am aware of incidental 
non-engineering folks using Slack for bugreporting (unsurprisingly, a 
lot of those questions get answered with "file a bug in bugzilla"), but 
it seems to me that's not what you're talking about...


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

Re: Pulsebot in #developers

[Philipp Kewisch]

On 11/5/17 12:55 PM, Mike Hommey wrote:
> So it seems to me the core problem is not as much "there's too much noise"
> as "people are not posting on #developers anymore". One could think
> there's correlation, but I think the reality is simply that less people
> use irc.

Thanks for the stats and history Mike, very interesting! I was aware
that before, firebot took care of those messages, but indeed it didn't
seem to bother back then because there was enough other discussion


For me, #developers has always been the chat based version of
m.d.platform. Certainly not the place for newcomers to ask introductory
question, but the place to ask gecko platform questions for people that
have previous experience. On https://wiki.mozilla.org/IRC it is
described as "General Firefox and Gecko development discussion".

If there is a better place to ask ad-hoc questions about Gecko, I am
happy to go there (and we should make sure the channel is promoted in
our docs).

I can see how less usage of IRC can lead to the situation we have now.
As long as there is an (open) replacement that is more accepted nowadays
I think this is fine, but aside from that I think we should find a way
to promote discussing Firefox and Platform issues in the open again.

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

Re: Website memory leaks

[David Teller]

As a user, I would definitely love to have this.

I wanted to add something like that to about:performance, but at the
time, my impression was that we did not have sufficient platform data on
where allocations come from to provide something convincing.

Cheers,
 David

On 02/11/17 15:34, Randell Jesup wrote:
> [Note: I'm a tab-hoarder - but that doesn't really cause this problem]
> 
> tl;dr: we should look at something (roughly) like the existing "page is
> making your browser slow" dialog for website leaks.
> 
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: October 30th to November 3rd

[Cornel Ionce]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *October 30 - November 3* (week 44).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
none

*BETA CHANNEL
*

*
*
ID  Summary Product Component   Is a regression 
Assigned to
1413159 
Download panel glitches after removing a downloaded file
Firefox
Downloads Panel
TBD NOBODY
1413233 
	The navigation bar buttons/search suggestion panel are moved to the 
left side if Firefox is resized to the minimum width

Firefox
Address Bar
	YES 
 
	NOBODY

1412832 
	No favicon displayed for baidu.com after adding the engine in Search 
bar panel

Firefox
Search
	YES 
 
	Marco Bonardo 


**

*
NIGHTLY CHANNEL**
*


ID  Summary Product Component   Is a regression 
Assigned to
1413859 
On Nightly builds video is not working when using Facebook video calls
Core
WebRTC
	YES 
 
	NOBODY

1413904
   Intermittent connection issue on talky.io
CoreWebRTC: Audio/Video
TBD NOBODY
1414336 
	[Pointer Events] The main menu from calacademy.org is unresponsive if 
Pointer Events is preffed on

CoreDOM: Events
TBD Ming-Chou Shih 


*ESR CHANNEL*
none


Regards,
Cornel (:cornel_ionce)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Pulsebot in #developers

[Mike Hommey]

Hi,

As the owner of the mentioned bot, I feel I need to jump in, not because
I want to defend any position (I pretty much don't care whether pulsebot
sends its messages to #developers or somewhere else), but just to
mention some facts.

Pulsebot did its first post to #developers on May 30, 2014, but really
only started reporting checkins 4 days later.

Before that, check-ins were reported by firebot, and it had been doing
that for as long as my irc logs go, which is September of 2010.

Now, looking at the history of firebot and pulsebot messages, it seems
there's been an increase over time, but it started before pulsebot (it
could be related to the limit above which only one line is sent for
a push with multiple commits, I haven't looked into more detail).
https://docs.google.com/spreadsheets/d/e/2PACX-1vRNTVhBVEr3Vu6bFaaeHRvY6BaTwuSYrHAa33fZSZda6XzeSw4Jp1l6kIYyNV4c4yOuPnKhQuH6gmz7/pubhtml?gid=534714054&single=true

BTW, you'll see in the stats you linked to that the third place goes to
firebot, which hasn't posted much since june 2014.

So, practically speaking, not much has changed in the recent past as far
as commits are concerned.

What *did* change, however, if I didn't screw up my grepping, is the
number of total messages on the channel:
https://docs.google.com/spreadsheets/d/e/2PACX-1vRNTVhBVEr3Vu6bFaaeHRvY6BaTwuSYrHAa33fZSZda6XzeSw4Jp1l6kIYyNV4c4yOuPnKhQuH6gmz7/pubhtml?gid=819219011&single=true

Consequently, the percentage of messages due to commits is very much
larger.

So it seems to me the core problem is not as much "there's too much noise"
as "people are not posting on #developers anymore". One could think
there's correlation, but I think the reality is simply that less people
use irc.

Mike

On Sat, Nov 04, 2017 at 12:44:32PM +0100, Philipp Kewisch wrote:
> Hey Folks,
> 
> I'm a big fan of having development discussions in the open, and in the
> past #developers has been the prime place to do that. Even if the
> benefit may not be apparent vs. having a private discussion or using a
> closed channel, I think this is one of many ways to increase interest
> within the community. Back when I got started with Mozilla as a
> volunteer, I enjoyed reading discussions in #developers because they
> allowed me to peek into things that Mozilla developers were working on,
> and at times got me interested in the code that was being talked about.
> 
> One thing that has recently "gotten in the way" of this is pulsebot. I
> acknowledge the usefulness of getting notifications on checkin, but it
> does add a lot of noise to #developers. Questions asked or discussions
> quickly fade away when pulsebot sends another dozen messages due to
> checkins and merges. How much exactly becomes apparent when you visit
> https://mozilla.logbot.info/developers/stats : pulsebot has said more
> than twice as much as anyone else.
> 
> Of course you could say, why don't I just ignore pulsebot? The point is
> that only few will actually do so. My impression over time is that less
> of the questions I have asked are being answered, and my suspicion is
> that in part, people qualified to answer will just not see it in
> scrollback between all the pulsebot messages.
> 
> Long story short, can we move pulsebot to a separate channel so that
> people can opt-in to, and encourage people to discuss their Gecko
> development topics in #developers again?
> 
> Philip
> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Pulsebot in #developers

[Gijs Kruitbosch]

On 06/11/2017 00:23, zbranie...@mozilla.com wrote:

but please, be careful because #developers is also the most natural channel for 
any newcomers to go to in order to ask entry level questions about our codebase.


No, that should be (and is and has been for a considerable amount of 
time, IME), #introduction .


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

Re: More ThinkStation P710 Nvidia tips (was Re: Faster gecko builds with IceCC on Mac and Linux)

[Henri Sivonen]

Thank you for including an AMD card among the ones to be tested.

- -

The Radeon RX 460 mentioned earlier in this thread arrived. There was
again enough weirdness that I think it's worth sharing in case it
saves time for someone else:

Initially, for multiple rounds of booting with different cable
configurations, the Lenovo UEFI consistenly displayed nothing if a
cable with a powered-on screen was plugged into the DisplayPort
connector on the RX 460. To see the boot password prompt or anything
else displayed by the Lenovo UEFI, I needed to connect a screen to the
DVI port and *not* have a powered-on screen connected to DisplayPort.
However, Lenovo UEFI started displaying on a DisplayPort-connected
screen (with or without DVI also connected) after one time I had had a
powered-on screen connected to DVI and a powered-off screen connected
to DisplayPort at the start of the boot and I turned on the
DisplayPort screen while the DVI screen was displaying the UEFI
password prompt. However, during that same boot, I happened to not to
have a keyboard connected, because it was connected via the screen
that was powered off, and this caused an UEFI error, so I don't know
which of the DisplayPort device powering on during the UEFI phase or
UEFI going through an error phase due to missing keyboard jolted it to
use the DisplayPort screen properly subsequently. Weird.

On the Linux side, the original Ubuntu 16.04 kernel (4.4) supported
only a low resolution fallback mode. Rolling the hardware enablement
stack forward (to 4.10 series kernel using the incantation given at
https://wiki.ubuntu.com/Kernel/LTSEnablementStack ) fixed this and
resulted in Firefox reporting WebGL2 and all. The fix for
https://bugzilla.kernel.org/show_bug.cgi?id=191281 hasn't propagated
to Ubuntu 16.04's latest HWE stack, which looks distressing during
boot, but it seems harmless so far.

I got the 4 GB model, since it was available at roughly the same price
as the 2 GB model. It supports both screens I have available for
testing at their full resolution simultaneously (2560x1440 plugged
into DisplayPort and 1920x1200 plugged into DVI).

The card is significantly larger than the Quadro M2000. It takes the
space of two card slots (connects to one, but the heat sink and the
dual fans take the space of another slot). The fans don't appear to
make an audible difference compared to the Quadro M2000.

On Fri, Oct 27, 2017 at 6:19 PM, Sophana "Soap" Aik  wrote:
> Thank you Henri for the feedback.
>
> How about this, we can order some graphics cards and put them in the
> evaluation/test machine that is with Greg, to make sure it has good
> compatibility.
>
> We could do:
> Nvidia GTX 1060 3GB
> AMD Radeon RX570
>
> These two options will ensure it can drive multi displays.
>
> Other suggestions welcomed.
>
> Greg, is that something you think we should do?
>
> On Thu, Oct 26, 2017 at 11:33 PM, Henri Sivonen 
> wrote:
>>
>> On Fri, Oct 27, 2017 at 4:48 AM, Sophana "Soap" Aik 
>> wrote:
>> > Hello everyone, great feedback that I will keep in mind and continue to
>> > work
>> > with our vendors to find the best solution with. One of the cards that I
>> > was
>> > looking at is fairly cheap and can at least drive multi-displays (even
>> > 4K
>> > 60hz) was the Nvidia Quadro P600.
>>
>> Is that GPU known to be well-supported by Nouveau of Ubuntu 16.04 vintage?
>>
>> I don't want to deny a single-GPU multi-monitor setup to anyone for
>> whom that's the priority, but considering how much damage the Quadro
>> M2000 has done to my productivity (and from what I've heard from other
>> people on the DOM team, I gather I'm not the only one who has had
>> trouble with it), the four DisplayPort connectors on it look like very
>> bad economics.
>>
>> I suggest these two criteria be considered for developer workstations
>> in addition to build performance:
>>  1) The CPU is compatible with rr (at present, this means that the CPU
>> has to be from Intel and not from AMD)
>>  2) The GPU offered by default (again, I don't want to deny multiple
>> DisplayPort connectors on a single GPU to people who request them)
>> works well in OpenGL mode (i.e. without llvmpipe activating) without
>> freezes using the Open Source drivers included in Ubuntu LTS and
>> Fedora.
>>
>> On Fri, Oct 27, 2017 at 2:36 AM, Gregory Szorc  wrote:
>> > Host OS matters for finding UI bugs and issues with add-ons (since lots
>> > of
>> > add-on developers are also on Linux or MacOS).
>>
>> I think it's a bad tradeoff to trade off the productivity of
>> developers working on the cross-platform core of Firefox in order to
>> get them to report Windows-specific bugs. We have people in the
>> organization who aren't developing the cross-platform core and who are
>> running Windows anyway. I'd prefer the energy currently put into
>> getting developers of the cross-platform core to use Windows to be put
>> into getting the people who use Windows anyway to use Nightly. (It
>> saddens me to hear fear of Nightly f