Re: [JS-internals] Replacing YARR
On Sat, Feb 15, 2014 at 3:36 AM, Chris Peterson cpeter...@mozilla.com wrote: Jan, any more news from the JSC developers about collaborating on Yarr? In your original mail starting this thread, you said that fixing Yarr ourselves or upstream would be hard without help from someone very familiar with Yarr. Are the JSC developers actively maintaining Yarr now? Do you feel they will commit new resources to fixing Yarr performance and crashes? AFAIK, this is not a priority for them. When we talked to them they were willing to discuss changes with us etc, but they had no plans to improve Yarr themselves. Sorry, I forgot to reply to your previous mail, I'll send you their contact info. Jan ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
[JS-internals] Changes to the Promise ES6 spec
Hi everyone, We are on track to ship our Promise implementation in Firefox 29. Blink has already shipped their implementation on the stable channel of Chrome and they are facing difficulties determining whether they should change what they have shipped based on the recent ES6 changes to the Promise API in TC39. I'm not very familiar with the TC39 processes, but is there any way for us to indicate to TC39 that we should avoid further changes to the API as the second engine is getting very close to shipping Promise? Please see this thread https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RNphv8dgJ0g for more context. Thanks! -- Ehsan http://ehsanakhgari.org/ ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
Re: [JS-internals] Changes to the Promise ES6 spec
Le 17/02/2014 21:56, Ehsan Akhgari a écrit : Hi everyone, We are on track to ship our Promise implementation in Firefox 29. Blink has already shipped their implementation on the stable channel of Chrome and they are facing difficulties determining whether they should change what they have shipped based on the recent ES6 changes to the Promise API in TC39. I'm not very familiar with the TC39 processes, but is there any way for us to indicate to TC39 that we should avoid further changes to the API as the second engine is getting very close to shipping Promise? Telling Brendan can work I guess :-) The topic came out in this (and maybe other) threads : https://mail.mozilla.org/pipermail/es-discuss/2014-January/035976.html I haven't read every single es-discuss email recently, but I have the feeling that TC39 is ok to standardize the current spec and not make changes at this point anymore. That said, it'd be excellent if Blink and Moz completed the current test suite (Promise/A+), or at least backport tests from one another to be sure they implement the same thing to the finest detail (and report spec issues if such a thing arise). David ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
Re: [JS-internals] Changes to the Promise ES6 spec
The problem is one V8 principal (among others in what I think is a clear minority) do not agree with the current consensus. The previous consensus was actually fractured, but no one worked through it and some amount of miscommunication, perhaps combined with expansive risk tolerance by some on the committee, and some off, led to things diverging. V8's implementation thus differs from ES6. The current ES6 consensus needs to be nailed down harder, but I think it will stick. That it isn't compositional won't stop this. Promises were a library de-facto standard from CommonJS and other ecosystems; the committee erred in trying to redesign them, the long email threads both before and after make this clear. SpiderMonkey still needs to nativize the DOM/XPCOM-based implementation, both to follow the spec (including subclassability) and to avoid dependencies on the DOM or XPCOM. /be David Bruant mailto:bruan...@gmail.com February 17, 2014 at 1:27 PM Telling Brendan can work I guess :-) The topic came out in this (and maybe other) threads : https://mail.mozilla.org/pipermail/es-discuss/2014-January/035976.html I haven't read every single es-discuss email recently, but I have the feeling that TC39 is ok to standardize the current spec and not make changes at this point anymore. That said, it'd be excellent if Blink and Moz completed the current test suite (Promise/A+), or at least backport tests from one another to be sure they implement the same thing to the finest detail (and report spec issues if such a thing arise). David ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals Ehsan Akhgari mailto:ehsan.akhg...@gmail.com February 17, 2014 at 12:56 PM Hi everyone, We are on track to ship our Promise implementation in Firefox 29. Blink has already shipped their implementation on the stable channel of Chrome and they are facing difficulties determining whether they should change what they have shipped based on the recent ES6 changes to the Promise API in TC39. I'm not very familiar with the TC39 processes, but is there any way for us to indicate to TC39 that we should avoid further changes to the API as the second engine is getting very close to shipping Promise? Please see this thread https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/RNphv8dgJ0g for more context. Thanks! -- Ehsan http://ehsanakhgari.org/ ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
Re: [JS-internals] Better memory reporting of objects and shapes
On 2/16/14, 11:18 PM, Nicholas Nethercote wrote: The memory reporting code runs without a |cx|, so in my experimental code I've just used obj-getClass()-name, and not treated proxies specially. Does this sound reasonable? I think this is the right thing. -j ___ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
