Re: [JS-internals] Improving Date.parse

2016-06-11 Thread David Bruant
Hi, Thanks a lot for working on this! Sharing a piece of cross-browser inconsistency that has affected me working on a real application in the past https://bugs.chromium.org/p/v8/issues/detail?id=3936 David Le 08/06/2016 23:28, Morgan Reece a écrit : Hi all, Date.parse has been breaking cr

Re: [JS-internals] Standardized assertion methods

2014-06-02 Thread David Bruant
Le 02/06/2014 14:23, Boris Zbarsky a écrit : On 6/2/14, 7:49 AM, Mike de Boer wrote: all the test suites/ runners we have end up using the same assertion methods. Note that the ones you listed don't match the ones the W3C testharness uses, so all the tests imported from that won't match the o

Re: [JS-internals] Usage of JS 1.8 features in Mozilla projects

2014-03-31 Thread David Bruant
Le 29/03/2014 20:16, Till Schneidereit a écrit : On Sat, Mar 29, 2014 at 3:05 PM, Chris Peterson wrote: On 3/29/14, 11:38 AM, Till Schneidereit wrote: Just stumbled upon this: https://groups.google.com/forum/#!topic/mozilla.dev.gaia/Il3DiRpIZ0U In this particular case, the right conclusions

Re: [JS-internals] Raw notes from meeting on Spidermonkey embedding

2014-03-25 Thread David Bruant
Le 25/03/2014 21:41, Steve Fink a écrit : Sort of a mangled transcript of the embedding meeting at the 2014 Toronto JS work week. Users - AMO for linting etc. This might be better served by eslint moving forward https://github.com/eslint/eslint/ - Gecko - GNOME Shell - MongoDB was, b

Re: [JS-internals] Changes to the Promise ES6 spec

2014-02-18 Thread David Bruant
Le 18/02/2014 16:02, Boris Zbarsky a écrit : On 2/17/14 4:27 PM, David Bruant wrote: That said, it'd be excellent if Blink and Moz completed the current test suite (Promise/A+) Mozilla did, until we just removed cast(). Or at least we passed the test suite at http://domenic.me/aplus-

Re: [JS-internals] Changes to the Promise ES6 spec

2014-02-17 Thread David Bruant
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 shipp

Re: [JS-internals] Taint analysis in SpiderMonkey

2014-02-03 Thread David Bruant
Le 03/02/2014 12:06, Stéphanie Ouillon a écrit : With attachments Attachements don't go through mailing-lists. At least, I didn't find one in your email. Post in a gist or github pages or dropbox or things like that. David On 02/03/2014 11:08 AM, Stéphanie Ouillon wrote: Hello, Ivan forw

Re: [JS-internals] Basic loop optimization q from twitter

2014-01-21 Thread David Bruant
Le 21/01/2014 00:05, Nicholas Nethercote a écrit : On Mon, Jan 20, 2014 at 1:03 PM, hv1989 wrote: Just that measuring an empty loop is kinda pointless. For anyone with a twitter account: "Microbenchmarks suck!" easily fits into 140 chars. It's being worked on https://twitter.com/ubench_sphinx

Re: [JS-internals] My Christmas wishlist for the Devtools

2013-12-21 Thread David Bruant
Le 20/12/2013 17:07, Nicolas B. Pierron a écrit : On 12/20/2013 06:24 AM, Julien Wajsberg wrote: So here is my wishlist (please cope with any inacuraccies I could make): * have diagnostics about what happens within the JS engine: + when and why objects are handled as Hashmap instead of Struct

Re: [JS-internals] WeakRefs and weak event listeners

2013-12-17 Thread David Bruant
Le 17/12/2013 16:36, Till Schneidereit a écrit : On Tue, Dec 17, 2013 at 4:16 PM, Andrew McCreight wrote: Of course, these kinds of cache references would need to be different than other weak references, at both the language level (if you want regular weak references, then these cachey referenc

Re: [JS-internals] Membranes vs Contracts vs Identity

2013-12-06 Thread David Bruant
Le 05/12/2013 18:49, Sam Tobin-Hochstadt a écrit : [please please please try quoting a little less] (yes sorry about that. Thunderbird hides quotes, so I tend to forget. I'll be careful) Contracts mediate the interaction between different components. So to "add contracts to a program", a prog

Re: [JS-internals] Membranes vs Contracts vs Identity

2013-12-05 Thread David Bruant
Le 04/12/2013 15:52, Peter Thiemann a écrit : On 12/03/13 23:32, Mark Miller wrote: On Tue, Dec 3, 2013 at 2:06 PM, Peter Thiemann > wrote: On 03.12.2013, at 22:09, Mark Miller mailto:erig...@gmail.com>> wrote: -- From

Re: [JS-internals] WeakRefs and weak event listeners

2013-12-03 Thread David Bruant
Le 02/12/2013 23:44, Andrew McCreight a écrit : As far as I understand it, weak references are useful to avoid leaks when you don't know (1) who is referring to you From what I understand of Object Capabilities, in memory-safe languages, someone has a reference to an object only if one of these

Re: [JS-internals] Weak references

2013-11-03 Thread David Bruant
Le 03/11/2013 11:29, Bobby Holley a écrit : The problem with weak references is that they put the GC in the driver's seat, which makes it very hard to avoid revealing GC secrets to the client. Instead, I propose that we let the client code drive, and see how far we get with hueyfix-style tools.

Re: [JS-internals] Weak references

2013-11-03 Thread David Bruant
Le 03/11/2013 12:49, Jorge Chamorro a écrit : When would be the right time to free(something)? What would `something` be after the call to free(), null? What if `something` isn't the only reference to the thing? I don't think Bobby was suggesting the addition of a free function or operator. Th

Re: [JS-internals] Weak references

2013-11-02 Thread David Bruant
Le 02/11/2013 20:41, Brendan Eich a écrit : At JSConf.eu, John McCutchan of Google and a colleague who works on gmail gave a good talk on GC, showing off Chrome's memory profiling tool. Article version and longer talk at http://www.html5rocks.com/en/tutorials/memory/effectivemanagement/ They s

Re: [JS-internals] Weak references

2013-11-02 Thread David Bruant
Le 01/11/2013 23:17, Jason Orendorff a écrit : On 11/1/13 1:52 PM, David Bruant wrote: In any case, I've stopped being against weakrefs after a message by Mark Miller[...] I am now going to try to convince you that you shouldn't have been convinced by this use case. :) You can tr

Re: [JS-internals] Weak references

2013-11-02 Thread David Bruant
Le 01/11/2013 21:13, Andrew McCreight a écrit : - Original Message - Why so? function f(e){} (function(){ var iframe = document.getElementByTagName('iframe')[0]; iframe.addEventListener('someEvent', f); })() In this case, f doesn't hold a referenc

Re: [JS-internals] Weak references

2013-11-01 Thread David Bruant
Le 01/11/2013 19:34, Andrew McCreight a écrit : 3. Finally, though I'm generally opposed to weak references, as they are complex to implement, I do understand that there's a need for them. When working on the leaks in bug 893012, to fix some of the individual leaks, like bug 894147, we had to

Re: [JS-internals] Weak references

2013-11-01 Thread David Bruant
[sorry for previous early send error] Hi, Le 01/11/2013 16:26, Jason Orendorff a écrit : This proposal is before TC39 for inclusion in the next ECMAScript spec edition following ES6: http://wiki.ecmascript.org/doku.php?id=strawman:weak_references Mozilla GC hackers are opposed, for reasons

Re: [JS-internals] Weak references

2013-11-01 Thread David Bruant
Hi, Le 01/11/2013 17:42, Bobby Holley a écrit : From the proposal: Note that makeWeakRef is not safe for general access since it grants access to the non-determinism inherent in observing garbage collection. What does that mean? That they don't expect this to be exposed to the web? In tha

Re: [JS-internals] Differences between Parser API and Esprima harmony

2013-09-06 Thread David Bruant
Le 06/09/2013 18:32, Luke Wagner a écrit : This brings up a related question: what is the proposed future of the builtin Reflect.parse now that we have pure-JS alternatives like Esprima? On the 'keep' side, I've found jsreflect to be simple, well-written, and easy to maintain. Also, there seem

Re: [JS-internals] Taint analysis in SpiderMonkey

2013-08-12 Thread David Bruant
Le 13/08/2013 00:52, Jim Blandy a écrit : On 08/12/2013 03:41 PM, Jim Blandy wrote: We might be able to do it with a Debugger source-rewriting hook, like the one Marc Feeley implemented. (That's all but ready to land; I need to take care of that before it bit-rots.) What I can't see how to

[JS-internals] Conformance testing of "the" JavaScript engine(s?)

2013-08-11 Thread David Bruant
Hi, In advance, I apologize if my question is naive or stupid but I couldn't find the answer simply (or figure out why it would be a wriong question). There are "official" conformance tests [1] and "SpiderMonkey" also has its own form of conformance and regression tests. I quote "SpiderMonkey

Re: [JS-internals] Dogfood via node in our build scripts?

2013-07-29 Thread David Bruant
Le 29/07/2013 19:43, Brendan Eich a écrit : BTW destructuring plus array return should be optimized to erase the allocation and use the stack instead. E.g., function pair(a, b) { return [a, b]; } let [x, y] = pair(z, w); should not allocate a fresh array in pair. Anyone know whether there'

Re: [JS-internals] Dogfood via node in our build scripts?

2013-07-28 Thread David Bruant
Le 28/07/2013 08:53, Steve Fink a écrit : On Fri 26 Jul 2013 12:29:10 PM PDT, Brendan Eich wrote: Steve Fink wrote: (2) writing JS still feels clunky in comparison to writing Python, What's missing in your experience? That question deserves a proper response, but it's tough remembering the is

Re: [JS-internals] Tracelogging revived

2013-07-19 Thread David Bruant
Hmm... HOLY SHIT THIS IS AWESOME !!! 2013/7/19 > I also created a python script to get some meaningful information out of > it. Nice graphs ;). But actually much more info can get out of it. It's > that file I used to profile octane and find problems in it. The python > script that create nice

[JS-internals] Retiring JavaScript versions

2013-05-01 Thread David Bruant
Hi, I've been thinking about Dave Herman's comment one the generator bug [1] for a couple of days. Specifically: "The explicit versioning is Mozilla-specific, and is basically a failed experiment; the overwhelming majority of the web doesn't use it. The HTML5 zeitgeist and the "One JavaScript"

Re: [JS-internals] Self-hosting the ES5 object model

2013-01-30 Thread David Bruant
write I am thankful to Mathias Bynens and John-David Dalton for benchmark.js which made easy to see how I could compare performance-wise. Le 30/01/2013 21:46, David Bruant a écrit : Hi, This idea comes out of the realization that the entire ES5 object model (property descriptors, [[Extensible

[JS-internals] Self-hosting the ES5 object model

2013-01-30 Thread David Bruant
Hi, This idea comes out of the realization that the entire ES5 object model (property descriptors, [[Extensible]]) can be implemented on top of POJSO and proxies. What I call POJSO (plain old js object) is an object which interface is reduced to get/set/has/delete/keys and with a prototype wh

Re: [JS-internals] Naming conventions in self-hosted JavaScript

2012-12-11 Thread David Bruant
Le 11/12/2012 16:10, Till Schneidereit a écrit : b) Should the names of macros indicate how they're implemented or should they just look like other functions? Just a quick explanation for this: the script that embeds self-hosted JS invokes a Python script, builtins/macros.py, that replaces some

Re: [JS-internals] Naming conventions in self-hosted JavaScript

2012-12-11 Thread David Bruant
Le 11/12/2012 04:02, Norbert Lindenberg a écrit : Till, Jeff, and I had some discussion about naming conventions for self-hosted JavaScript - would be good to get input from others. I tossed in a few more cases that I've come across. a) Should we follow established JavaScript conventions and a

Re: [JS-internals] SpiderMonkey version numbers

2012-09-11 Thread David Bruant
Le 11/09/2012 16:04, Tom Schuster a écrit : It's very hard to tell which version of SpierMonkey supports which feature, because we never really change that number. The last JSVERSION is 1.8 and the last jsapi version is 1.8.something. We should either start describing stuff on MDN in terms of the

Re: [JS-internals] Proposal to improve the JS Team for new people and the community

2012-07-30 Thread David Bruant
Le 30/07/2012 12:02, Till Schneidereit a écrit : After some discussion on IRC, Eddy and I have started an Etherpad to collect things we might want to do to improve our docs: https://etherpad.mozilla.org/sm-doc I made one thing the first entry in that list as I think it could be a big imrovement: