Re: Have you run 'mach bootstrap' lately?

2017-05-12 Thread Ehsan Akhgari 

On 05/12/2017 06:59 PM, Dustin Mitchell wrote:

Yep, this caused problems in automation (we ended up setting
I_PREFER_A_SUBOPTIMAL_MERCURIAL_EXPERIENCE_THANK_YOu or whatever the
env var was).  I agree that a quick warn-and-continue would be fine.

Especially for git users.  ;-)

Speaking of nagging that can be off putting, I have to admit I almost 
never run mach bootstrap because it forces me make a decision about how 
I want mercurial to be updated which I don't use.  The only times I run 
mach bootstrap are on fresh installs of OSes and past that, I stick to 
manually updating my tools when things that depend on them break.



Dustin

2017-05-12 15:23 GMT-04:00 Eric Rahm :

Didn't it somehow cause builds to fail? A gentle reminder is probably fine.
TBH I'd be fine if it auto-updated but maybe I'm in the minority.

On Fri, May 12, 2017 at 11:34 AM, Ted Mielczarek  wrote:


On Fri, May 12, 2017, at 10:45 AM, Sylvestre Ledru wrote:

Would it be possible to add a check like:
"You haven't updated your local configuration since XX days, please
consider running
mach bootstrap ?"

We've had mach produce nag messages like that in the past and they have
been universally disliked, FWIW.

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

___
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

W3C Charter Advance Notice: Web Platform (recharter) & Service Workers WGs

2017-05-12 Thread L. David Baron 
The W3C gave advance notice that 2 new charters are under
development:

  https://lists.w3.org/Archives/Public/public-new-work/2017May/0006.html
  (which contains brief descriptions of what has changed)

  Web Platform Working Group
  http://w3c.github.io/charter-html/webplat-wg.html
  https://github.com/w3c/charter-html/

  Service Workers Working Group
  http://w3c.github.io/charter-drafts/sw-charter.html
  https://github.com/w3c/charter-drafts/

Comments on these charters can be made in their respective github
repositories, or, if necessary, I can make comments that should be
made as statements "from Mozilla" on the Advisory Committee mailing
list.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


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

Re: Have you run 'mach bootstrap' lately?

2017-05-12 Thread Dustin Mitchell 
Yep, this caused problems in automation (we ended up setting
I_PREFER_A_SUBOPTIMAL_MERCURIAL_EXPERIENCE_THANK_YOu or whatever the
env var was).  I agree that a quick warn-and-continue would be fine.

Dustin

2017-05-12 15:23 GMT-04:00 Eric Rahm :
> Didn't it somehow cause builds to fail? A gentle reminder is probably fine.
> TBH I'd be fine if it auto-updated but maybe I'm in the minority.
>
> On Fri, May 12, 2017 at 11:34 AM, Ted Mielczarek  wrote:
>
>> On Fri, May 12, 2017, at 10:45 AM, Sylvestre Ledru wrote:
>> > Would it be possible to add a check like:
>> > "You haven't updated your local configuration since XX days, please
>> > consider running
>> > mach bootstrap ?"
>>
>> We've had mach produce nag messages like that in the past and they have
>> been universally disliked, FWIW.
>>
>> -Ted
>> ___
>> 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
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Have you run 'mach bootstrap' lately?

2017-05-12 Thread Gregory Szorc 
On Fri, May 12, 2017 at 2:37 PM, Aaron Klotz  wrote:

> On 5/12/2017 8:29 AM, Ryan VanderMeulen wrote:
>
>> And while we're on that topic, I'll also remind people once again that
>> for Windows MozillaBuild users, you can keep your copy of Mercurial up to
>> date via pip! Simply run |pip install -U mercurial| and you'll have the
>> latest version available - no need to wait for an updated MozillaBuild
>> release.
>>
>>
> Isn't that something that mach bootstrap should be doing?
>

Yes. A patch is in Ryan's review queue to do this.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Have you run 'mach bootstrap' lately?

2017-05-12 Thread Aaron Klotz 

On 5/12/2017 8:29 AM, Ryan VanderMeulen wrote:
And while we're on that topic, I'll also remind people once again that 
for Windows MozillaBuild users, you can keep your copy of Mercurial up 
to date via pip! Simply run |pip install -U mercurial| and you'll have 
the latest version available - no need to wait for an updated 
MozillaBuild release.




Isn't that something that mach bootstrap should be doing?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Ship throttling of tracking timeouts

2017-05-12 Thread Eric Shepherd (Sheppy) 
Thank you for the details. I’ve added dev-doc-needed on the bug and added a 
link to this thread so the writer can find the information here quickly.

Eric Shepherd
Senior Technical Writer
Mozilla Developer Network 
Blog: https://www.bitstampede.com/
Twitter: https://twitter.com/sheppy

> On May 11, 2017, at 11:32 PM, Bill McCloskey  wrote:
> 
> (I hope everything I've said is correct. I've been following the change but
> I had nothing to do with the code.)

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

Re: Fwd: Changes to code review tools and processes

2017-05-12 Thread Randell Jesup 
>This was posted on mozilla.tools yesterday but doesn't seem to have made it
>to dev.platform. It is likely to be of interest to many people on this
>list. Note the comment "If you have questions or concerns beyond those
>addressed below, please
>use the mozilla.tools group and/or #phabricator on IRC and Slack to raise
>them. " in the message

I tried cross-posting my mozilla.tools response to here, but it appears
to not work.  I had extensive comments in mozilla.tools about a number
of issues; I strongly advise anyone even slightly interested go there
and read them.  Most important were issues around who trialed it,
security bug/patch access, control of data, archiving, ability to look
at old patches as more than a raw diff, and where review comments live.
(And more).  (Mark responded, and I followed up with more comments)

They do plan to put up a Wiki page on all this soon.

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Have you run 'mach bootstrap' lately?

2017-05-12 Thread Eric Rahm 
Didn't it somehow cause builds to fail? A gentle reminder is probably fine.
TBH I'd be fine if it auto-updated but maybe I'm in the minority.

On Fri, May 12, 2017 at 11:34 AM, Ted Mielczarek  wrote:

> On Fri, May 12, 2017, at 10:45 AM, Sylvestre Ledru wrote:
> > Would it be possible to add a check like:
> > "You haven't updated your local configuration since XX days, please
> > consider running
> > mach bootstrap ?"
>
> We've had mach produce nag messages like that in the past and they have
> been universally disliked, FWIW.
>
> -Ted
> ___
> 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: Have you run 'mach bootstrap' lately?

2017-05-12 Thread Botond Ballo 
On Fri, May 12, 2017 at 3:00 PM, Andrew McCreight
 wrote:
> On Fri, May 12, 2017 at 11:34 AM, Ted Mielczarek  wrote:
>
>> On Fri, May 12, 2017, at 10:45 AM, Sylvestre Ledru wrote:
>> > Would it be possible to add a check like:
>> > "You haven't updated your local configuration since XX days, please
>> > consider running
>> > mach bootstrap ?"
>>
>> We've had mach produce nag messages like that in the past and they have
>> been universally disliked, FWIW.
>>
>
> Obviously it has less users, but moz-git-tools has a similar thing and I
> find it handy and nobody has complained about it, AFAIK.
> https://lists.mozilla.org/listinfo/dev-platform

Also, the previous nag message actually prevented you from proceeding
to |mach build| unless you employed an obscure bypass. I think that's
what people were most annoyed about, and would look upon an optional
reminder more favourably.

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

Re: Have you run 'mach bootstrap' lately?

2017-05-12 Thread Andrew McCreight 
On Fri, May 12, 2017 at 11:34 AM, Ted Mielczarek  wrote:

> On Fri, May 12, 2017, at 10:45 AM, Sylvestre Ledru wrote:
> > Would it be possible to add a check like:
> > "You haven't updated your local configuration since XX days, please
> > consider running
> > mach bootstrap ?"
>
> We've had mach produce nag messages like that in the past and they have
> been universally disliked, FWIW.
>

Obviously it has less users, but moz-git-tools has a similar thing and I
find it handy and nobody has complained about it, AFAIK.

Andrew


> -Ted
> ___
> 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: Have you run 'mach bootstrap' lately?

2017-05-12 Thread Ted Mielczarek 
On Fri, May 12, 2017, at 10:45 AM, Sylvestre Ledru wrote:
> Would it be possible to add a check like:
> "You haven't updated your local configuration since XX days, please
> consider running
> mach bootstrap ?"

We've had mach produce nag messages like that in the past and they have
been universally disliked, FWIW.

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

Fwd: Changes to code review tools and processes

2017-05-12 Thread Andrew McCreight 
This was posted on mozilla.tools yesterday but doesn't seem to have made it
to dev.platform. It is likely to be of interest to many people on this
list. Note the comment "If you have questions or concerns beyond those
addressed below, please
use the mozilla.tools group and/or #phabricator on IRC and Slack to raise
them. " in the message

Andrew


-- Forwarded message --
Subject: Fwd: Changes to code review tools and processes

On Thursday, May 11, 2017 at 1:46:49 PM UTC-7, mc...@mozilla.com wrote:
>
> tl;dr Splinter and MozReview will be fully replaced by Differential,
> Phabricator’s code-review tool, in Q3.
>
>
> Why the change?
>
> Code review is a critical part of the Firefox engineering process but
> hasn’t changed much since Mozilla’s early days. Our home-developed
> tools have worked well for us but are increasingly dependent upon
> scarce resources to maintain, build and customize. Using our own tool,
> something that isn’t used by other organizations, also makes
> onboarding new people, staff and volunteers much more time-consuming
> than it needs to be.
>
> As with our decision to move forward with Project Dawn, this change is
> an investment we need to make now (so we get the benefits as soon as
> possible) to ensure the long-term health of Firefox. We are confident
> the short-term/immediate costs incurred—standing up a new tool, having
> to shift expectations and refactor workflows—will be more than paid
> back with surplus time and energy available for process automation
> (and later, with faster onboarding).
>
> If you have questions or concerns beyond those addressed below, please
> use the mozilla.tools group and/or #phabricator on IRC and Slack to
> raise them.
>
>
> ~ Laura Thomson & Mark Côté
>
> ===
> FAQs
>
> * Why did we choose Differential?
>
> Differential, originally developed at Facebook and currently used by
> many organizations, both open- and closed-source, has been trialled by
> several teams at Mozilla over the last few months. Although no code
> review tool is perfect, we believe it addresses several of the
> deficiencies in Review Board and is better suited to the Firefox
> engineering process. It is also an opportunity to decouple our
> automation pieces in order to focus on them after Differential’s
> launch, where we believe we will have a greater impact to Firefox
> development.
>
> * What will go out in the initial launch?
>
> 1. Deployment of a central Differential (code review) installation,
> supported by CloudOps, along with supporting tools like Diffusion
> (repository browser) and Herald (event-driven notifications). We will
> continue to use our Bugzilla instance, bugzilla.mozilla.org (aka BMO),
> for issue tracking for the foreseeable future.
>
> 2. Lightweight integration of Differential with BMO. This will include:
> - Authentication/identity.
> - Links from Differential revisions to BMO bugs.
> - Mirroring approvals (only) of Differential revisions back to BMO
> bugs as r+s on stub attachments, for record-keeping purposes. Aside
> from this, the code-review process will occur only in Differential to
> avoid fragmenting the discussion.
> - Security-group mapping to support reviews of security and otherwise
> confidential patches as seamlessly as possible.
> - Integration with and improvements to the Autoland service, which is
> currently used for around 50% of commits to mozilla-central and an
> integral part of the Quantum Stylo project.
>
> * What will happen to Splinter and MozReview?
>
> After a short trial period, MozReview will be shut down, and Splinter
> will be turned off for the main Firefox products on BMO: Core,
> Firefox, and Toolkit. Contribution guides and documentation will be
> updated to refer to Phabricator for code-change submissions. The exact
> archival procedures are will be figured out soon.
>
> * Will I be able to request customizations in Differential?
>
> We plan to limit customizations, but not to zero. We’re making this
> change (to using a third-party tool) to reduce the support burden on
> internal teams. The fewer customizations we make the more that
> happens. Any customizations will generally use Phabricator’s Conduit
> API; extensions will be limited to changes that are not possible to
> implement via the API. We have no intention of forking any Phabricator
> tools.
>
> * How will I get patches/commits up for review?
>
> We intend to keep the general Phabricator workflow, including use of
> the Arcanist command-line tool, although we will likely provide easy
> installation and some abstraction via mach and MozillaBuild.
>
> * Where will the flags for feedback/review/ui-review be?
>
> We’re going with the review flow built into Differential, which does
> not support multiple types of flags as Bugzilla’s attachment-flag
> system does. However, the actions that a reviewer can perform in
> Differential are more straightforward: rather than setting “r+” or
> “r-”, Differential’s options include “resign as

Re: Have you run 'mach bootstrap' lately?

2017-05-12 Thread Geoffrey Brown 
I'm not sure. I always just answer the prompts and am happy with that.

There is a --settings option, which sounds like it might be helpful, but I
don't have any experience with that.

 - Geoff

On Fri, May 12, 2017 at 9:00 AM, Ethan Glasser-Camp <
eglasserc...@mozilla.com> wrote:

> Is there a way to run it without having to reanswer the configuration
> questions?
>
> Ethan
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Quantum Flow Engineering Newsletter #9

2017-05-12 Thread Ehsan Akhgari 

On 05/12/2017 12:29 PM, Tom Ritter wrote:

On Fri, May 12, 2017 at 1:27 AM, Ehsan Akhgari  wrote:

I realized we haven't had a performance mini-story for a while -- I sort of
dropped the ball on that.  Running over this bug made me want to talk about
a pretty well known sort of slowness in C++ code, virtual functions.  The
cost of virtual functions comes from several different aspects, firstly they
effectively prevent the compiler from doing inlining the function which
enables a host of compiler optimizations, essentially by enabling the
compiler to see more of the code and optimize more effectively based on
that.  But then there is the runtime cost of the function, which mostly
comes from the indirect call.  The majority of the performance penalty here
on modern hardware is due to branch midpredictions when different
implementations of a virtual function get called at a call site.  You should
remember that on modern desktop processors, the cost of a branch
misprediction can be around 15-20 cycles (depending on the processor) so if
what your function does is very trivial and it has many overrides that can
be called in hot code chances are that you are spending a considerable
amount of time waiting for the instruction cache misses on the calls to the
virtual function in question.  Of course, finding which virtual functions in
your program are these expensive ones requires profiling the workloads you
care about improving, but always keep an eye for this problem as
unfortunately the object-oriented programming model in C++ really encourages
writing code like this.  This is the kind of issue that a native profiler is
probably more suitable for discovering, for example if you are using a
simple native sampling profiler these issues typically show up as a long
amount of time being spent on the first instruction of the virtual function
being called (which is typically an inexpensive instruction otherwise.)

This reminded me of
https://bugzilla.mozilla.org/show_bug.cgi?id=1332680 (and
https://bugzilla.mozilla.org/show_bug.cgi?id=1332682 )

Adding -Wsuggest-final-types and -Wsuggest-final-methods and looking
at the output seems pretty low-effort to find a lot of more
opportunities for this. (Unless I'm misunderstanding things).

Plus, it benefits security!
Yes, this is indeed a good point.  Even though this will really only 
have a measurable impact on performance if the functions are called in 
hot code, it seems like a shame to not listen to the compiler when it 
tells you I could make your code faster if you added this keyword in a 
bunch of places.  :-)

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

Re: Quantum Flow Engineering Newsletter #9

2017-05-12 Thread Tom Ritter 
On Fri, May 12, 2017 at 1:27 AM, Ehsan Akhgari  wrote:
> I realized we haven't had a performance mini-story for a while -- I sort of
> dropped the ball on that.  Running over this bug made me want to talk about
> a pretty well known sort of slowness in C++ code, virtual functions.  The
> cost of virtual functions comes from several different aspects, firstly they
> effectively prevent the compiler from doing inlining the function which
> enables a host of compiler optimizations, essentially by enabling the
> compiler to see more of the code and optimize more effectively based on
> that.  But then there is the runtime cost of the function, which mostly
> comes from the indirect call.  The majority of the performance penalty here
> on modern hardware is due to branch midpredictions when different
> implementations of a virtual function get called at a call site.  You should
> remember that on modern desktop processors, the cost of a branch
> misprediction can be around 15-20 cycles (depending on the processor) so if
> what your function does is very trivial and it has many overrides that can
> be called in hot code chances are that you are spending a considerable
> amount of time waiting for the instruction cache misses on the calls to the
> virtual function in question.  Of course, finding which virtual functions in
> your program are these expensive ones requires profiling the workloads you
> care about improving, but always keep an eye for this problem as
> unfortunately the object-oriented programming model in C++ really encourages
> writing code like this.  This is the kind of issue that a native profiler is
> probably more suitable for discovering, for example if you are using a
> simple native sampling profiler these issues typically show up as a long
> amount of time being spent on the first instruction of the virtual function
> being called (which is typically an inexpensive instruction otherwise.)

This reminded me of
https://bugzilla.mozilla.org/show_bug.cgi?id=1332680 (and
https://bugzilla.mozilla.org/show_bug.cgi?id=1332682 )

Adding -Wsuggest-final-types and -Wsuggest-final-methods and looking
at the output seems pretty low-effort to find a lot of more
opportunities for this. (Unless I'm misunderstanding things).

Plus, it benefits security!

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

Re: Have you run 'mach bootstrap' lately?

2017-05-12 Thread Geoffrey Brown 
Good idea - I filed bug 1364480.

On Fri, May 12, 2017 at 8:45 AM, Sylvestre Ledru  wrote:

>
>
> Le 12/05/2017 à 05:08, Geoffrey Brown a écrit :
> > If you set up your build environment with 'mach bootstrap' but haven't
> run
> > it recently, consider taking a few minutes now to run it again. Running
> > 'mach bootstrap' from time to time will keep your environment up to date
> > and (more-or-less) in sync with your colleagues'.
> >
> > This seems to be especially important for Android test environments: The
> > Android SDK and associated tools are always being updated and if you
> don't
> > stay up to date, there's a good chance something will eventually break.
> >
> Would it be possible to add a check like:
> "You haven't updated your local configuration since XX days, please
> consider running
> mach bootstrap ?"
>
> Thanks,
> Sylvestre
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Have you run 'mach bootstrap' lately?

2017-05-12 Thread Ethan Glasser-Camp 
Is there a way to run it without having to reanswer the configuration
questions?

Ethan

On Thu, May 11, 2017 at 11:08 PM, Geoffrey Brown  wrote:

> If you set up your build environment with 'mach bootstrap' but haven't run
> it recently, consider taking a few minutes now to run it again. Running
> 'mach bootstrap' from time to time will keep your environment up to date
> and (more-or-less) in sync with your colleagues'.
>
> This seems to be especially important for Android test environments: The
> Android SDK and associated tools are always being updated and if you don't
> stay up to date, there's a good chance something will eventually break.
> ___
> 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: Have you run 'mach bootstrap' lately?

2017-05-12 Thread Sylvestre Ledru 


Le 12/05/2017 à 05:08, Geoffrey Brown a écrit :
> If you set up your build environment with 'mach bootstrap' but haven't run
> it recently, consider taking a few minutes now to run it again. Running
> 'mach bootstrap' from time to time will keep your environment up to date
> and (more-or-less) in sync with your colleagues'.
>
> This seems to be especially important for Android test environments: The
> Android SDK and associated tools are always being updated and if you don't
> stay up to date, there's a good chance something will eventually break.
>
Would it be possible to add a check like:
"You haven't updated your local configuration since XX days, please
consider running
mach bootstrap ?"

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

Re: Have you run 'mach bootstrap' lately?

2017-05-12 Thread Ryan VanderMeulen 

On 5/11/17 11:08 PM, Geoffrey Brown wrote:

If you set up your build environment with 'mach bootstrap' but haven't run
it recently, consider taking a few minutes now to run it again. Running
'mach bootstrap' from time to time will keep your environment up to date
and (more-or-less) in sync with your colleagues'.

This seems to be especially important for Android test environments: The
Android SDK and associated tools are always being updated and if you don't
stay up to date, there's a good chance something will eventually break.



As a quick follow-on to that, running |./mach mercurial-setup 
--update-only| from time to time is also a good idea. It'll keep your 
clone of the version-control-tools repo up to date, which will in turn 
ensure that the various Mercurial extensions we use stay up to date.


And while we're on that topic, I'll also remind people once again that 
for Windows MozillaBuild users, you can keep your copy of Mercurial up 
to date via pip! Simply run |pip install -U mercurial| and you'll have 
the latest version available - no need to wait for an updated 
MozillaBuild release.


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

Re: new configure option: --enable-debug-rust

2017-05-12 Thread Nathan Froyd 
On Thu, May 11, 2017 at 5:15 PM, Jeff Muizelaar  wrote:
> On Fri, Apr 14, 2017 at 10:46 AM, Nathan Froyd  wrote:
>> With these options, you get a browser that runs quickly (i.e. no DEBUG
>> assertions in C++ code), but still lets you debug the Rust code you
>> might be working on, ideally with faster compile times than you might
>> get otherwise.  --enable-debug implies --enable-debug-rust, of course.
>
> From my reading of config/rules.mk and experience it looks like
> --enable-rust-debug does not disable optimizations in Rust code. With
> opt-level=1 Rust still doesn't have a great debugging experience (the
> compiler mostly seems to think things are optimized out).

I think your reading is correct.  Please file a bug in Core :: Build Config.

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

Re: Is Big5 form submission fast enough?

2017-05-12 Thread Mike Hommey 
On Fri, May 12, 2017 at 09:28:50AM +0800, Kan-Ru Chen wrote:
> On Thu, May 11, 2017, at 01:43 PM, Henri Sivonen wrote:
> > In Firefox 43, I rewrote our Big5 support and, among other things, I
> > optimized the *encoder* for footprint rather than speed on the theory
> > that users won't notice anyway since the encoder run is followed by a
> > dominating wait for the network when submitting a form.
> > 
> > Since then, I've learned that the relative slowness of the Big5
> > encoder is greater than I had anticipated. Still, I haven't seen
> > anyone complaining, but I don't know if anyone who finds it too slow
> > knows how to attribute the complaint.
> > 
> > I'd like to hear from someone who uses a Web site/app that involves
> > submitting a textarea of Traditional Chinese text in Big5 if the form
> > submission performance seems normal (doesn't feel particularly slow)
> > on low-performance hardware, like an Android phone. (In the phone
> > case, I mean the amount of text you'd feel OK to input on a phone at
> > one time.)
> > 
> > If UTF-8 is so widely deployed that no one in the Taipei office needs
> > to submit forms in Big5 anymore, that would be good to know, too.
> 
> I don't feel that I see a lot of Big5 websites out there. It's hard for
> me to even find one to test.
> 
> > Context:
> > I need to decide if I should make Big5 encode faster or if I should
> > trade off speed for smaller footprint for the legacy Simplified
> > Chinese and Japanese *encoders*, too.
> 
> I think Shift_JIS are still widely used. But this is just my experience
> and guessing.

I'd tend to confirm that. Relatively recent governmental sites are still
using it, such as http://www.e-tax.nta.go.jp/ (which is for tax returns)

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

IDNA processing

2017-05-12 Thread Anne van Kesteren 
If this is better suited elsewhere, such as dev-tech-network, please
let me know.

For about five years I've been trying to figure out the IDNA algorithm
that a) browsers follow and b) browsers want to follow, but I've not
had much luck thus far getting folks to reply. E.g.,
https://lists.w3.org/Archives/Public/www-archive/2017Feb/0006.html
went largely unaddressed.

One big difference between http://www.unicode.org/reports/tr46/ and
browsers is how ASCII is handled. Per UTS #46 ASCII is handled the
same as non-ASCII. However, in browsers ASCII takes a "fast path" and
skips the ToASCII algorithm. YouTube now depends on that (it has CDN
domains with hyphens in the third and fourth position, as reported at,
e.g., https://github.com/nodejs/node/issues/12965).

A question I've had is whether we should standardize the fast path or
try to get consistent handling. I've also raised this with the Unicode
folks at 
https://docs.google.com/document/d/11PEww2N0PbXyPhbsCdW_PjD3BNgZMy5XHUv02SSXNqY/edit
and elsewhere and it seems an upcoming draft adds another flag to the
UTS #36 ToASCII algorithms to ignore hyphen requirements.

However, hyphens are not the only requirement that might influence how
a pure ASCII domain is handled and therefore it's unclear it actually
solves the problem, especially if browsers continue to ignore it.

Since I haven't gotten much cooperation my plan is to just standardize
what browsers do (in https://url.spec.whatwg.org/ which ends up
invoking UTS #46 ToASCII) and go from there, especially as not doing
what browsers do tends to break other ecosystems, but I thought I'd
raise this here as a final attempt to get some input.


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

Re: Intent to Ship throttling of tracking timeouts

2017-05-12 Thread Ehsan Akhgari 
On Thu, May 11, 2017 at 11:32 PM, Bill McCloskey 
wrote:

> On Thu, May 11, 2017 at 8:12 PM, Boris Zbarsky  wrote:
>
> > On 5/11/17 10:30 PM, Eric Shepherd (Sheppy) wrote:
> >
> >> So part of private browsing and not a developer-facing feature, then?
> >>
> >
> > No, as I understand this is being applied across the board, not just in
> > private browsing, and not just if tracking protection is generally
> enabled.
>
>
> Correct, this change will apply everywhere. Normally, when a script calls
> setTimeout, we enforce a minimum value on the timeout time. For foreground
> tabs this is 4ms and for background tabs it's 1000ms. The change being
> discussed will also factor in whether the script calling setTimeout is a
> tracking script (which is defined as a

Quantum Flow Engineering Newsletter #9

2017-05-12 Thread Ehsan Akhgari 
Hi everyone,

It's been 10 weeks since I have started writing these newsletters (the
number in the title isn't an off by one error, there was a one week hiatus
due to a work week!).  We still have quite a bit of work ahead of us, but
we have also accomplished a good amount.  Finding a good metric for
progress is hard, but we live and breathe in Bugzilla, so we use a bug-based
burn-down chart
.
As you can see, we are starting to see a decrease in the number of open
bugs, and this is as we are actively adding tens of new bugs to the pool in
the weekly triage meetings.

The other thing that this burn-down chart shows is that we need help!  Very
recently Kan-Ru came up with the great idea of creating the
qf-bugs-upforgrabs
 tracker
bug.  These are reasonably self-contained bugs that require less specific
domain knowledge and can be worked on by anyone in a reasonable time
frame.  Please consider taking a look at the dependency list of that bug to
see if something interests you! (The similarity of this tacker bug to
photon-perf-upforgrabs
 isn't
an accident!)

On the telemetry hang reports data collection, the new data from hangs of
128ms or longer have been coming in, but there have been some wrinkles in
actually receiving this data, and also in receiving the hang data
correlated to user interactivity
.  Michael Layzell
has been tirelessly at work on the BHR backend to make it suit our needs,
and has been discovering the edges of computation limits in order to
symbolicate the BHR reports on people.mozilla.org (now moved to AWS
!).

I realized we haven't had a performance mini-story for a while -- I sort of
dropped the ball on that.  Running over this bug
 made me want to talk
about a pretty well known sort of slowness in C++ code, virtual functions.
The cost of virtual functions comes from several different aspects, firstly
they effectively prevent the compiler from doing inlining the function
which enables a host of compiler optimizations, essentially by enabling the
compiler to see more of the code and optimize more effectively based on
that.  But then there is the runtime cost of the function, which mostly
comes from the indirect call.  The majority of the performance penalty here
on modern hardware is due to branch midpredictions when different
implementations of a virtual function get called at a call site.  You
should remember that on modern 
desktop  processors
, the cost of a branch misprediction
can be around 15-20 cycles (depending on the processor) so if what your
function does is very trivial and it has many overrides that can be called
in hot code chances are that you are spending a considerable amount of time
waiting for the instruction cache misses on the calls to the virtual
function in question.  Of course, finding which virtual functions in your
program are these expensive ones requires profiling the workloads you care
about improving, but always keep an eye for this problem as unfortunately
the object-oriented programming model in C++ really encourages writing code
like this.  This is the kind of issue that a native profiler is probably
more suitable for discovering, for example if you are using a simple native
sampling profiler these issues typically show up as a long amount of time
being spent on the first instruction of the virtual function being called
(which is typically an inexpensive instruction otherwise.)

Now it's time to acknowledge the work of all of you who have helped in
improving the performance of the browser in the last week.  As always, I
hope I'm not forgetting anyone:


   -

   Doug Thayer ported the Gecko Profiler add-on to be a WebExtension
   !  One
   important impact of this work is that this makes it possible to profile
   Firefox using this add-on without incurring the performance impact of
   having an extension using the add-on SDK installed.
   -

   Kris Maglione added support for pre-loading scripts during startup on a
   background thread .
   This helps improve startup performance for the parent process.
   -

   David Anderson made us composite asynchronously on Windows when resizing
   a widget .  This
   can reduce main thread jank for example when opening a window.  He also made
   PLayerTransaction’s constructor async
    removing a