Re: windows build anti-virus exclusion list?

On 2017-03-17 12:06 AM, Ben Kelly wrote: On Fri, Mar 17, 2017 at 12:05 AM, Ben Kelly > wrote: On Thu, Mar 16, 2017 at 11:40 PM, Michael Hoye mailto:mh...@mozilla.com>> wrote: Depending on your AV, if you don't exempt mozilla-central some of our t

Re: windows build anti-virus exclusion list?

On Fri, Mar 17, 2017 at 12:05 AM, Ben Kelly wrote: > On Thu, Mar 16, 2017 at 11:40 PM, Michael Hoye wrote: > > Depending on your AV, if you don't exempt mozilla-central some of our >> tests will get quarantined and you won't be able to build at all. >> > > I guess I was hoping someone familiar w

Re: windows build anti-virus exclusion list?

On Thu, Mar 16, 2017 at 11:40 PM, Michael Hoye wrote: > Depending on your AV, if you don't exempt mozilla-central some of our > tests will get quarantined and you won't be able to build at all. > I guess I was hoping someone familiar with our build might know the answer. :-) In any case, I mana

Re: windows build anti-virus exclusion list?

Depending on your AV, if you don't exempt mozilla-central some of our tests will get quarantined and you won't be able to build at all. - mhoye On Mar 16, 2017 20:34, "Ben Kelly" wrote: On Thu, Mar 16, 2017 at 11:26 PM, Ben Kelly wrote: > - mozilla-build install dir > - visual studio ins

Re: windows build anti-virus exclusion list?

Try using Sysinternals Process Monitor to see what files MsMpEng.exe is reading. On Fri, Mar 17, 2017, at 04:26 PM, Ben Kelly wrote: > Hi all, > > I'm trying to configure my new windows build machine and noticed that > builds were still somewhat slow. I did: > > 1) Put it in high performance po

Re: windows build anti-virus exclusion list?

On Thu, Mar 16, 2017 at 11:26 PM, Ben Kelly wrote: > - mozilla-build install dir > - visual studio install dir > - /users/bkelly/appdada/local/temp > - /users/bkelly (because temp dir was not enough) > FWIW, adding all these extra exclusions dropped my build time from ~22 minutes to ~14

windows build anti-virus exclusion list?

Hi all, I'm trying to configure my new windows build machine and noticed that builds were still somewhat slow. I did: 1) Put it in high performance power profile 2) Made sure my mozilla-central dir was not being indexed for search 3) Excluded my mozilla-central directory from windows defender W

Re: Switching to async/await from Task.jsm/yield

On Thu, Mar 16, 2017 at 09:08:24PM -0400, Michael Layzell wrote: Can we pass async functions everywhere where we use `add_task` in tests already? If we can't, is there a tracking bug for converting all of the test systems to support it? Yes, add_task accepts any function which returns a promise

Re: Switching to async/await from Task.jsm/yield

I mostly use tasks when writing tests, so I mostly have questions about how it's use in that situation will be affected. Can we pass async functions everywhere where we use `add_task` in tests already? If we can't, is there a tracking bug for converting all of the test systems to support it? Can y

Re: Switching to async/await from Task.jsm/yield

Sounds like a good change to make from the discussion so far. If there are issues with stack traces, I would assume having more of our code base using async / await is a good way to apply pressure for stack trace improvements (if needed) that will benefit everyone. - Ryan On Thu, Mar 16, 2017 at

Re: Switching to async/await from Task.jsm/yield

On Thu, Mar 16, 2017 at 05:39:06PM -0500, J. Ryan Stinnett wrote: For modules that have already converted, is there any performance change (good or bad) between async / await vs. Task? I haven't noticed any differences either way, but I also haven't done any explicit profiling. There's definit

Re: Switching to async/await from Task.jsm/yield

For modules that have already converted, is there any performance change (good or bad) between async / await vs. Task? - Ryan On Thu, Mar 16, 2017 at 5:33 PM, Kris Maglione wrote: > On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote: > >> Writing code in standard JS is always better

Re: Switching to async/await from Task.jsm/yield

On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote: Writing code in standard JS is always better for the web, makes it easier to onboard new engineers and allows for better support in developer tools. So I'd like to propose that we switch to the standard way of writing these functions

Switching to async/await from Task.jsm/yield

For a long time now we've been writing JS code that waits for promises using Task.jsm and generator functions. Recently though the JS team added support for the JS standard way of doing this, async/await: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function W

FYI: git-cinnabar and a "Intermittent IndexError: tuple index out of range" error

If you are seeing this error when you try to do |git mozreview push|, update your version-control-tools. Then you'll see a different error. Work related to that is being looked at in https://bugzilla.mozilla.org/show_bug.cgi?id=1338530 Andrew ___ dev-pla

Re: Quantum Flow Engineering Newsletter #2

On Thu, Mar 16, 2017 at 4:27 PM, Kris Maglione wrote: > On Thu, Mar 16, 2017 at 11:07:19AM -0400, Ehsan Akhgari wrote: > >> This is why a while ago we decided to disallow the addition of new >> synchronous IPC messages by default (bug 1336919) to avoid programmers >> adding more issues of this na

Re: Heads Up: /storage upgraded from version 1.0 to 2.0

It would be useful to know if most of those users are just downgrading the previous version (N-1 for release, N-7 for ESR), and how quickly they return to a current release (assuming they do!). This would help inform to what degree we need to support (and test!) the myriad combinations of upgrade-

Re: Quantum Flow Engineering Newsletter #2

On Thu, Mar 16, 2017 at 11:07:19AM -0400, Ehsan Akhgari wrote: This is why a while ago we decided to disallow the addition of new synchronous IPC messages by default (bug 1336919) to avoid programmers adding more issues of this nature to the code base. Are there any plans to do something simil

Re: Quantum Flow Engineering Newsletter #2

On Thu, Mar 16, 2017 at 11:07 AM, Ehsan Akhgari wrote: > > Now, on to the credits section. I’d like to take a moment to recognize > the work of the following individuals who have helped with various aspects > of the Quantum Flow project. Thank you very much for your help this past > week! (Apo

Re: Editing vendored crates

On 27/02/17 19:47, Simon Sapin wrote: On 27/02/17 19:30, Henri Sivonen wrote: On Mon, Feb 27, 2017 at 8:00 PM, Bobby Holley wrote: FWIW, |cargo tree| is a very helpful tool to figure out who's pulling in a crate. Thanks, but what I'm trying to figure out isn't whose pulling it in (the style

Re: Heads Up: /storage upgraded from version 1.0 to 2.0

I apologize for the delays in bug 1246615. It fell off my radar with a series of trips. I've set up a meeting tomorrow to at least identify who is responsible for this decision, because it's not exactly me. I analyzed some data in the bug which I'll repeat here. Here is an analysis of the patterns

Re: Tracking bug for removals after XPCOM extensions are no more?

On 3/15/2017 3:51 PM, Benjamin Smedberg wrote: after Firefox 57 when Webextensions are the only extensions, if our product no longer needs some functionality (and it's "API"), let's remove it. Quickly and ruthlessly. We need to actively work to maintain less code. I'm struggling to have a big p

Re: Tracking bug for removals after XPCOM extensions are no more?

On Thu, Mar 16, 2017 at 11:23 AM, R Kent James wrote: > On 3/15/2017 3:51 PM, Benjamin Smedberg wrote: > >> after Firefox 57 when >> Webextensions are the only extensions, if our product no longer needs some >> functionality (and it's "API"), let's remove it. Quickly and ruthlessly. >> We >> need

Re: Tracking bug for removals after XPCOM extensions are no more?

On Wed, Mar 15, 2017 at 11:35:10PM +0200, Henri Sivonen wrote: What's the current outlook on letting chrome JS read ArrayBuffers as opposed to JS strings where the high 8 bits are zero and the low 8 bits are the byte values from XPCOM streams? (Or letting chrome JS access things that are currentl

Re: Will script implementations of nsIOutputStream be prohibited once XPCOM extensions are no more?

On 16.03.17 09:08, Boris Zbarsky wrote: We should try marking nsIOutputStream builtinclass on trunk right now. As far as I can tell, this should just work. No adverse effects on Thunderbird, I hope: https://dxr.mozilla.org/comm-central/search?q=nsIOutputStream&redirect=false As far as I can

Re: Tracking bug for removals after XPCOM extensions are no more?

On 3/13/17 11:36 AM, Steve Fink wrote: There's a whitelist of "safe" things that we assume will never be overridden. But now I can remove everything that treats nsISupports specially. Things can still be implemented in chrome JS via XPCWrappedJS, right? Assuming the analysis will consider all

Quantum Flow Engineering Newsletter #2

Hi everyone, This past week was another busy week chasing down performance issues in Firefox. We managed to knock out a few issues, get closer to close out a couple of really high impact ones, and are making good progress on starting to get performance data from telemetry which will hopefully all

Re: Tracking bug for removals after XPCOM extensions are no more?

On Thu, Mar 16, 2017 at 7:34 AM, Boris Zbarsky wrote: > On 3/15/17 5:35 PM, Henri Sivonen wrote: >> >> What's the current outlook on letting chrome JS read ArrayBuffers as >> opposed to JS strings where the high 8 bits are zero and the low 8 >> bits are the byte values from XPCOM streams? > > > I

Re: Intent to ship: IntersectionObserver API

> > 1) Is there devtools support for this (e.g. to be able to see what > intersection observers are registered where)? If not, are there at least > bugs tracking it? I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1347849 for this. MutationObserver would be a good one to add support for to

Re: Will script implementations of nsIOutputStream be prohibited once XPCOM extensions are no more?

On 3/16/17 3:35 AM, Henri Sivonen wrote: Do we need to keep caring about https://bugzilla.mozilla.org/show_bug.cgi?id=170416 once XPCOM extensions are no more? A first glance, no. We should try marking nsIOutputStream builtinclass on trunk right now. As far as I can tell, this should just wor

Re: Intent to ship: IntersectionObserver API

On Wed, Mar 15, 2017 at 7:38 PM, Boris Zbarsky wrote: > On 3/15/17 1:32 PM, Tobias Schneider wrote: >> 2.3) Platform tests are in the process of being upstreamed by Google ( >> https://github.com/w3c/web-platform-tests/pull/4384). > > That seems to be in limbo for well over a month now. jgraham j

Will script implementations of nsIOutputStream be prohibited once XPCOM extensions are no more?

Do we need to keep caring about https://bugzilla.mozilla.org/show_bug.cgi?id=170416 once XPCOM extensions are no more? -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.