Re: Scope of XML parser rewrite?

On Fri, May 26, 2017 at 1:18 AM, Eric Rahm wrote: > Limiting to modifying nsScanner might be an option, but probably not > changing all callers that use the nsAString interface. I guess we can just > UTF-16 => UTF-8 those and file a bunch of follow ups? Yeah. The main follow-up would be https://b

Re: Improving visibility of compiler warnings

On 5/25/17 6:11 PM, Eric Rahm wrote: I think we disable it for local builds because we don't control what versions of tools folks use. So clang vFOO might spit out errors we don't see in clang vBAR and it would be a huge pain if those failed locally even though they'd be fine in automation. It

Re: Race Cache With Network experiment on Nightly

>I think you were looking at the docs for opt-in Shield studies Ah, right you are :) OK, I've filed a bug for the pref study: https://bugzilla.mozilla.org/show_bug.cgi?id=1367951 Thanks! Jason On Thu, May 25, 2017 at 2:27 PM, Matthew Grimes wrote: > I think you were looking at the docs f

Re: Improving visibility of compiler warnings

On 05/25/2017 02:14 PM, Gregory Szorc wrote: On Thu, May 25, 2017 at 5:31 AM, Ehsan Akhgari mailto:ehsan.akhg...@gmail.com>> wrote: What was the motivation behind this change? Was there a complaint from a significant number of developers about it being difficult fixing compiler war

Re: Improving visibility of compiler warnings

On Thu, May 25, 2017 at 4:11 PM, Eric Rahm wrote: > I think we disable it for local builds because we don't control what > versions of tools folks use. So clang vFOO might spit out errors we don't > see in clang vBAR and it would be a huge pain if those failed locally even > though they'd be fine

Re: Improving visibility of compiler warnings

On Friday, May 26, 2017 at 11:08:09 AM UTC+12, Andrew McCreight wrote: > On Thu, May 25, 2017 at 4:03 PM, wrote: > > > On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote: > > > On 2017-05-25 5:31 AM, Ehsan Akhgari wrote: > > > > On 05/19/2017 02:44 PM, Gregory Szorc wrote: > > > >

Re: Improving visibility of compiler warnings

I think we disable it for local builds because we don't control what versions of tools folks use. So clang vFOO might spit out errors we don't see in clang vBAR and it would be a huge pain if those failed locally even though they'd be fine in automation. -e On Thu, May 25, 2017 at 4:07 PM, Andrew

Re: Improving visibility of compiler warnings

On Thu, May 25, 2017 at 4:03 PM, wrote: > On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote: > > On 2017-05-25 5:31 AM, Ehsan Akhgari wrote: > > > On 05/19/2017 02:44 PM, Gregory Szorc wrote: > > >> `mach build` attempts to parse compiler warnings to a persisted > > >> "database.

Re: Improving visibility of compiler warnings

On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote: > On 2017-05-25 5:31 AM, Ehsan Akhgari wrote: > > On 05/19/2017 02:44 PM, Gregory Szorc wrote: > >> `mach build` attempts to parse compiler warnings to a persisted > >> "database." > >> You can view a list of compiler warnings post

e10s-multi going to Release

Hey all, We've been running a series of e10s-multi experiments on the Beta branch for a while now while watching memory use numbers, crash rates, and other release criteria. After some positive returns from the first round of testing we started talking about maybe releasing e10s-multi in Firefox 5

Re: Scope of XML parser rewrite?

Thanks Henri, I think we can find a middle ground so as to avoid a ton of scope creep but leave the door open to a better iterative solution. See notes inline. -e On Wed, May 24, 2017 at 11:18 PM, Henri Sivonen wrote: > On Wed, May 24, 2017 at 10:11 AM, Henri Sivonen > wrote: > >> Our current

Re: Race Cache With Network experiment on Nightly

I think you were looking at the docs for opt-in Shield studies (experiments deployed as add-ons), not for pref flipping experiments. Due to the nature of some of the opt-in studies we run they require a different approval process. Pref flipping is available for all users, it is not opt-in. The proc

Re: Race Cache With Network experiment on Nightly

I'm worried we're going from too little process here to too much (at least for this bug). Opening a meta-bug + 4 sub-bugs and doing a legal review, etc., is a lot of overhead to test some network plumbing that is not going to be especially noticeable to users. Also, we expect that this code will

Re: Intent to unship: -moz-placeholder pseudo-element and pseudo-class

On 5/25/17 5:48 AM, Ku(顧思捷)CJ wrote: > Mike, do we get any complaint about not supporting webkit placeholder > alias? Nah, not that I'm aware of. I was just looking through GitHub search results and finding some stuff that only includes webkit-input-placeholder:

Re: Mozilla Charset Detectors

On Tuesday, May 23, 2017 at 7:47:12 PM UTC+3, Joshua Cranmer 🐧 wrote: > On 5/23/17 2:58 AM, Gabriel Sandor wrote: > > Hello Henri, > > > > I was afraid this might be the case, so the library really is deprecated. > > > > The project i'm working on implies multi-lingual environment, users, and > > f

Re: Improving visibility of compiler warnings

On Thu, May 25, 2017 at 08:31:24AM -0400, Ehsan Akhgari wrote: What was the motivation behind this change? Was there a complaint from a significant number of developers about it being difficult fixing compiler warnings grepping for things like "warning:" or using ./mach warnings-list? Was the

Re: Race Cache With Network experiment on Nightly

Hey folks. I run the Shield team. Pref flipping experiments ARE available on Nightly and will be available in all channels (including Release) at some point in Firefox 54. Since the process is still relatively new, I've been hacking on some how to docs: https://docs.google.com/document/d/16bp

Re: Improving visibility of compiler warnings

On 2017-05-25 5:31 AM, Ehsan Akhgari wrote: On 05/19/2017 02:44 PM, Gregory Szorc wrote: `mach build` attempts to parse compiler warnings to a persisted "database." You can view a list of compiler warnings post build by running `mach warnings-list`. The intent behind this feature was to make it

more setTimeout() changes incoming

Hi all, I want to give everyone a heads-up that I'm hoping to push some setTimeout() changes to inbound in the next day or two: https://bugzilla.mozilla.org/show_bug.cgi?id=1363829 The main result people should be aware of is that setTimeout() will be more accurate and precise after this lands [

Re: Improving visibility of compiler warnings

I'd like to second Ehsan's point, but also expand upon it into a more general observation. As it becomes progressively more difficult to build Firefox without mach, it becomes increasingly important that mach respect people's workflows. For those of us who were comfortable with make and the behavi

Re: Improving visibility of compiler warnings

On 5/25/17 8:31 AM, Ehsan Akhgari wrote: This currently only serves to make it more difficult to find compiler errors when they occur. Fwiw (and not to distract from your main point), https://bugzilla.mozilla.org/show_bug.cgi?id=1367405 just got fixed so we should no longer get the warning sp

Re: Improving visibility of compiler warnings

On 05/19/2017 02:44 PM, Gregory Szorc wrote: `mach build` attempts to parse compiler warnings to a persisted "database." You can view a list of compiler warnings post build by running `mach warnings-list`. The intent behind this feature was to make it easier to find and fix compiler warnings. Aft

Re: Intent to unship: -moz-placeholder pseudo-element and pseudo-class

ok, I see your point. I also saw some usage of moz-placeholder in add-on repository as well, and Boris pointed out it might too early to remove it, so I should pending this task. Mike, do we get any complaint about not supporting webkit placeholder alias? On Thu, May 25, 2017 at 4:10 AM, Mike Tay