Re: Feedback needed on proposal to add a web primitive for queuing microtasks

I also think that this makes sense. Can we already start thinking about countermeasures, though? It looks to me that catching a long-running/infinite microtask loop is much easier to detect and interrupt than a long-running sequential loop. However, if we wish to pause a page with such a microtask

Re: Feedback needed on proposal to add a web primitive for queuing microtasks

Well, if khuey ever got into splitting the event loop, we might be able to make progress on other tasks, but as far as I can see, detect and throw is probably the best option. On Thu, Jan 14, 2016 at 8:44 PM, David Rajchenbach-Teller wrote: > I also think that this makes sense. Can we already sta

Re: Feedback needed on proposal to add a web primitive for queuing microtasks

On Thu, Jan 14, 2016 at 10:44 AM, David Rajchenbach-Teller wrote: > I also think that this makes sense. Can we already start thinking about > countermeasures, though? Whatever we do for while(true) we should reuse here. There's no observable difference to the user. (And as stated this can already

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

On 04/01/2016 20:13, 罗勇刚(Yonggang Luo) wrote: > On Mon, Jan 4, 2016 at 7:22 PM, Bobby Holley wrote: > >> If you're forking mozilla-central, that shouldn't be a problem, right? >> > I am asking for some help, seeking for problems when I was trying to > implement XPCOM connect with js-ctypes. > S

SharedArrayBuffer and Atomics will ride the trains behind a pref

Until now the new SharedArrayBuffer constructor and the new Atomics global object [1] have been enabled on Nightly only. Starting with Firefox 46, those bindings will still be enabled by default on Nightly but they will also be available on Aurora, DevEd, Beta, and Release by flipping the value of

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

Hi, I saw the lightning talk you gave in Orlando in this topic. I was wondering if you considered implementing Transactional Memory for SharedArrayBuffer. JS seems like the perfect environment for TM. Are there reasons for 'only' providing atomic ops? Just asking out of curiosity... Best regards

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

On Thu, Jan 14, 2016 at 2:49 PM, Thomas Zimmermann wrote: > Hi, > > I saw the lightning talk you gave in Orlando in this topic. I was > wondering if you considered implementing Transactional Memory for > SharedArrayBuffer. ​I have not (or, not in earnest). ​ > JS seems like the perfect enviro

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

Thanks! Am 14.01.2016 um 15:08 schrieb Lars Hansen: > On Thu, Jan 14, 2016 at 2:49 PM, Thomas Zimmermann > wrote: > >> Hi, >> >> I saw the lightning talk you gave in Orlando in this topic. I was >> wondering if you considered implementing Transactional Memory for >> SharedArrayBuffer. > > ​I have

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

For additional rationale, you might be interested to read: https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/ On Thu, Jan 14, 2016 at 8:11 AM, Thomas Zimmermann wrote: > Thanks! > > Am 14.01.2016 um 15:08 schrieb Lars Hansen: >> On Thu, Jan 14, 2016 at 2:49 PM, Tho

Re: I was trying to implement the XPConnect with JS-Ctypes, is that would be a good idea?

It's seems they are all dead. 在 2016/1/14 20:02, Philip Chee 写道: On 04/01/2016 20:13, 罗勇刚(Yonggang Luo) wrote: On Mon, Jan 4, 2016 at 7:22 PM, Bobby Holley wrote: If you're forking mozilla-central, that shouldn't be a problem, right? I am asking for some help, seeking for

ESLint checks are now running on the nightly trees on checkin

Just a heads up, a full ESLint check of the tree is now being run on every checkin to mozilla-central or the other integration branches. The check is also available on tryserver [1], you can run it locally with "mach eslint" or why not make life easy and install the mercurial extension [2]. Not ma

Re: ESLint checks are now running on the nightly trees on checkin

This is great, big thanks to everyone involved. -dave On Thursday, January 14, 2016, Dave Townsend wrote: > Just a heads up, a full ESLint check of the tree is now being run on > every checkin to mozilla-central or the other integration branches. > The check is also available on tryserver [1],

Re: ESLint checks are now running on the nightly trees on checkin

On 14/01/16 12:24 PM, Dave Townsend wrote: All hail the mighty releng folks who have made it so ridiculously easy to prototype and deploy new taskcluster tests! I just want to emphasize the significance here. A developer unaffiliated with either releng or the ateam and with only minimal support

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

Hi Lars, So if I understand correctly, this will still remain disabled by default on all branches. However it will now be possible to test out on all branches by flipping a pref? If so that sounds great to me. / Jonas On Thu, Jan 14, 2016 at 5:16 AM, Lars Hansen wrote: > Until now the new Shar

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

Yes, disabled by default on all branches, enabled by default on Nightly. (It's also supported on ARM, so it should be possible to test it on Android, again by flipping the pref.) --lars On Thu, Jan 14, 2016 at 9:14 PM, Jonas Sicking wrote: > Hi Lars, > > So if I understand correctly, this will

Re: Feedback needed on proposal to add a web primitive for queuing microtasks

On 1/14/16 4:44 AM, David Rajchenbach-Teller wrote: However, if we wish to pause a page with such a microtask loop to display some UX, trigger a breakpoint or even to leave some CPU to other pages in the same process, is there anything specific we need to do to guarantee that no network/user inpu

Re: Feedback needed on proposal to add a web primitive for queuing microtasks

On 1/14/16 6:27 AM, Anne van Kesteren wrote: Whatever we do for while(true) we should reuse here. There's no observable difference to the user. (And as stated this can already happen with promises and mutation observers.) I dunno what the situation is right now with mutation observers, but for

Re: C++ Core Guidelines

On Wed, Jan 13, 2016 at 12:53 AM, Ehsan Akhgari wrote: > I'll investigate integrating gsl-lite into m-c. Thank you. On Mon, Jan 11, 2016 at 10:03 PM, Brian Smith wrote: > mozilla::pkix::Input/Reader will never throw an exception or abort the > process; instead it always returns an explicit succ

Re: SharedArrayBuffer and Atomics will ride the trains behind a pref

Sounds good to me too. What's blocking us from enabling by default? Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm o

Dominator tree memory analysis now in Nightly

Hi folks! Dominator trees give you fine-grained insight into memory retention. In a graph rooted by some node R, a node A is said to dominate B iff every path to B starting from R passes through A. In the context of a heap graph, another way to say this would be that A is retaining B: if the garb

Intent to implement and ship: WebKitCSSMatrix

*Summary*: WebKitCSSMatrix has been available for years in WebKit based browsers and has seen widespread usage on the web. This feature is currently available in Chrome, Safari and Edge. Mike Taylor has been working on standardizing the feature and it is being implemented in Gecko to improve web co

FYI - Autophone down for maintenance

Autophone is going down this afternoon for several hours while the devices are being switched to new hosts. bc ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-

Re: Dominator tree memory analysis now in Nightly

Thanks Nick. >From your screenshot, there are a lot of instances of "objects > Array", "objects > Object", etc. Is the a way to display the variable name used for those objects? Also, what is the plan for making tools like the Memory view appear in a default install? In other words, without havin

Re: Dominator tree memory analysis now in Nightly

Reply inline below. On Thu, Jan 14, 2016 at 2:49 PM, Jared Wein wrote: > From your screenshot, there are a lot of instances of "objects > Array", > "objects > Object", etc. Is the a way to display the variable name used for > those objects? > ​The node might not be in a JS variable (eg​ is a C+

Re: Dominator tree memory analysis now in Nightly

On Fri, Jan 15, 2016 at 12:01 PM, Nick Fitzgerald wrote: > Console, debugger, performance: these panels are ​a clear "always show" to > me. The web audio tool is very niche and so I don't think it would make > sense to show it by default. The memory tool falls in between in my mind. > I'm open to

Re: Dominator tree memory analysis now in Nightly

> On Jan 14, 2016, at 3:01 PM, Nick Fitzgerald wrote: > Also, what is the plan for making tools like the Memory view appear in a > default install? In other words, without having to go to the Settings. I > worry that users may not know to click on the Settings and just think that > other brows

Re: Intent to implement and ship: WebKitCSSMatrix

Ship it! On Thu, Jan 14, 2016 at 2:06 PM, William Chen wrote: > *Summary*: WebKitCSSMatrix has been available for years in WebKit based > browsers and has seen widespread usage on the web. This feature is > currently available in Chrome, Safari and Edge. Mike Taylor has been > working on standard

Re: Intent to implement and ship: WebKitCSSMatrix

On Thursday 2016-01-14 14:06 -0800, William Chen wrote: > *Summary*: WebKitCSSMatrix has been available for years in WebKit based > browsers and has seen widespread usage on the web. This feature is > currently available in Chrome, Safari and Edge. Mike Taylor has been > working on standardizing th

Intent to Implement/Ship: document.elementsFromPoint

*Summary*: We don't currently support documents.elementsFromPoint, while IE and Chrome do (I'm not sure if Opera and Safari have gotten around to it yet). It's making important things like IRCCloud angry. There's also an elementsFromRect, but I think I may wait on that since it doesn't even have a