Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

On 11/22/19 12:44 PM, #!/JoePea wrote: And (maybe unfortunately) for many people that amounts to being equivalent to "window". It _is_ equivalent to "window". The thing is, "window" returns a WindowProxy, not a Window... -Boris ___ es-discuss

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

On 11/21/19 5:21 PM, #!/JoePea wrote: They were duly marked invalid, because the problem was with the expectations, not the behavior... It's a design bug. Well, sure, if we're talking about the fact that there is no clear separation in the web platform's exposed objects between "a

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

On 11/16/19 12:52 PM, #!/JoePea wrote: That's the thing: the only people that may get confused are Ecmascript and JS-Engine experts who know the internals very intimately. No, it's just people who have functions return values they do not expect. and for those people that could possibly get

Re: function invocation with just commas for explicit undefined optional arguments in the middle

On 11/1/19 5:10 AM, Cyril Auburtin wrote: yes true, it's even more annoying with eslint, you have to configure it with https://eslint.org/docs/rules/no-unused-vars#argsignorepattern for example That's talking about function _declarations_, whereas the original proposal in this thread is

Re: Modify Promise.all() to accept an Object as a parameter

On 10/12/19 12:52 AM, Jacob Bloom wrote: const responses = await Promise.all(requests); As opposed to: const responses = await Primise.all(requests.values()); which works right now? -Boris ___ es-discuss mailing list es-discuss@mozilla.org

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

On 10/7/19 1:56 PM, #!/JoePea wrote: Who's going to write code like that anyways? In the general form of "function from a navigated-away-from document runs because it's called by some script from outside the document", I've seen this come up a number of times in web browser bug reports.

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

On 10/7/19 1:29 AM, #!/JoePea wrote: I've never written any sort of code that can prove or verify any of what you all are talking about. Mind showing code samples? Did you not see https://mail.mozilla.org/pipermail/es-discuss/2019-October/053033.html ? -Boris

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

On 10/6/19 2:58 PM, Raul-Sebastian Mihăilă wrote: Also let's not forget that the WindowProxy behavior contradicts the JS object model in that the non-configurable 'something' own property of the window proxy is removed. There is a proposal for addressing that. Firefox has been shipping it

Re: Why globalThis instead of something intuitive like globalObject, systemGlobal, or globalEntity?

On 10/4/19 2:39 PM, #!/JoePea wrote: but the global `this` you captured still has the same identity as the new reference. Interesting, I never knew that. Do you have a code sample to show how to detect or prove that? Sure. The following code logs "true, 5, 5, 5, 5, true, undefined,

Re: Bind function without thisArg

On 1/14/19 9:47 AM, Andrea Giammarchi wrote: rather because of the bloat it produces once transpiled: Hold on. The transpiling is necessary because of lack of what features in implementations? And what is the set of implementations that will lack those features but support bindArgs?

Re: Expectations around line ending behavior for U+2028 and U+2029

On 10/29/18 2:04 PM, Logan Smyth wrote: This means that the expectation, from the standpoint of Unicode spec, is that all existing parsers and tooling for all languages would also be updated to have line numbering that include U+2028/29 There is also the somewhat widespread opinion that

Re: Promise finally

On 2/23/18 9:30 AM, Michael Luder-Rosefield wrote: Whenever you chain a promise with a then/finally, you're basically letting the runtime look at the callbacks at some arbitrary point in the future, no? Not if the promise is already known to be resolved. In that case, the exact behavior of

Re: Native Tensor support

On 1/27/18 9:53 PM, Isiah Meadows wrote: 4. For style elements and ref-accessible elements, you could still execute the changes in set slices, splitting on nodes/callbacks that require awareness of past effects. (This could just be a flag.) However, these are exceedingly rare. This is not

Re: Native Tensor support

On 1/27/18 1:42 PM, Isiah Meadows wrote: That is true, but script elements generated via the DOM are not inline script elements Just to make sure we're on the same page: var script = document.createElement("script"); script.textContent = 'console.log("script running")';

Re: Performance of frozen vs non-frozen objects

On 12/26/17 9:07 AM, Mark Miller wrote: I tried https://jsperf.com/freeze-vs-seal-vs-normal/3 and https://jsperf.com/freeze-vs-seal-vs-normal/28 on Chrome, FF, and Safari. I don't know why the bar charts are not updating. I am traveling and do not currently have access to a

Re: Monkey patching constructors in builtin class hierarchies?

On 10/24/17 2:03 PM, /#!/JoePea wrote: I was trying to patch `Element` because there's also `SVGElement` For what it's worth, looks like for the moment custom elements has given up on the idea of custom non-HTML elements... -Boris ___ es-discuss

Re: Monkey patching constructors in builtin class hierarchies?

On 10/24/17 12:50 PM, /#!/JoePea wrote: Is it possible to monkey-patch an intermediate constructor of a built-in subclass? Right now, no. For example, suppose I want all `Element` instances in a web app to have new instance properties, is there a way to monkey-patch the Element constructor

Re: Math.minmax

On 10/2/17 7:10 AM, Xavier Stouder wrote: Don't know what Boris mean when he talks about recreation bits Fwiw, it looks like the code at https://esbench.com/bench/595c1b1899634800a03488b9 does not have the array recreation bits (function whatever(...args)) that earlier benchmarks for this

Re: Make comma at the end of line optional

On 9/13/17 1:55 PM, Naveen Chawla wrote: `x` `[y]` would be invalid syntax, right? Wrong. What am I missing? This is exactly why automatic X insertion with complicated rules is a bad idea for all values of X. ;) -Boris ___ es-discuss mailing

Re: Make comma at the end of line optional

On 9/13/17 9:57 AM, Naveen Chawla wrote: By this behaviour (a modification to the initial "complete statement produces comma" version of this proposal), everything would work perfectly, no? If by "perfectly" you mean "have hard-to-predict somewhat nonlocal behavior that makes any code

Re: Make comma at the end of line optional

On 9/13/17 9:05 AM, Naveen Chawla wrote: Can someone remind me of the problem doing it this way, if any? You mean apart from all the existing footguns ASI has? -Boris ___ es-discuss mailing list es-discuss@mozilla.org

Re: FW: Removal of language features

On 7/27/17 2:02 AM, Michael Kriegel wrote: 4. At a fixed date (e.g. 24 Months after X) all browsers must stop supporting the feature How do you plan to enforce this? Please note that the people representing browsers in this committee may not (and afaict generally do not) make ship/no-ship

Re: JavaScript Versioning

On 7/23/17 1:19 AM, Alexander Craggs wrote: I also feel that it is *impossible* for vendors to add such changes to make error messages more useful because in the JavaScript syntax specified ten years ago "await" didn't exist and it would just be an unexpected string. Just to be clear, the

Re: JavaScript Versioning

On 7/23/17 12:30 AM, Alexander Craggs wrote: Say we create such versioning, it would allow us to improve the language so much more than we're currently able to, we'd no longer have to stick with useless error messages for forgetting `async`: ```js < function u() { let x = await "hi" } Uncaught

Re: Math.minmax

On 7/4/17 9:34 PM, Jordan Harband wrote: The results I get range from a 2x improvement for 2 numbers, to a 3x improvement for 1000 numbers Again, did you test without the array destructuring and recreation bits? I expect those dominate here, just like in the jsbench benchmarks posted

Re: Math.minmax

On 6/29/17 1:49 AM, T.J. Crowder wrote: I was going to make that very point, backed by a jsPerf, but the jsPerf doesn't back it up: https://jsperf.com/two-calls-vs-one-returning-array It says the minmax is faster on a 10-entry array (it reports the separate calls as 46-48% slower on V8 and

Re: Are thrown errors in a try block considered to be handled even if there's no catch block?

On 6/23/17 12:39 PM, Boris Zbarsky wrote: The rest of what you see is because the console API and the internal error reporting use slightly different mechanisms for notifying about new messages: I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1375899 to hopefully align these more, fwiw

Re: Are thrown errors in a try block considered to be handled even if there's no catch block?

On 6/23/17 7:01 AM, T.J. Crowder wrote: On Firefox, I get ``` 1 2; cancelling dispatch complete then uncaught exception: 1 uncaught exception: 2 ``` ...where the traces point to the `dispatchEvent` line. So it seems to store them up and then report them. I should note that if you add this to

Re: Math.sincos(x)?

On 6/22/17 2:13 PM, Алексей wrote: function sincos (a) { const sin = Math.sin(a) const cos = (1 - sin**2)**0.5 This will completely fail for a near pi/2. It will return zero instead of the correct small but nonzero value it should be returning. -Boris

Re: Math.sincos(x)?

On 6/22/17 2:02 PM, Robert Poor wrote: However, most implementations for cos(theta) actually generate sin(theta) as a "byproduct" (and vice-versa). At first glance, the v8 implementation of cos typically uses a Taylor series and does not compute sin. And the SpiderMonkey implementation of

Re: Help wanted: Membrane proxies + Object.freeze() == paradox

On 5/23/17 3:44 AM, Alex Vincent wrote: 3. I create matching "membrane" proxies for wetB and wet_b named dryB and dry_b, Shouldn't you also have a proxy for webB.prototype (called dryproto, let's say)? Otherwise your "wet" and "dry" object graphs are actually a single kind of weird

Re: A WeakMap where values (not keys) are weak references?

On 3/21/17 2:15 AM, /#!/JoePea wrote: I'd like to have something like a WeakMap where the keys can be primitives and the values are weakly-held Objects It might be worth searching the archives: this has been proposed multiple times and discussed at quite some length. If there isn't an

bugs.ecmascript.org has an expired certificate

"The certificate expired on May 25, 2016 at 8:00 AM. The current time is March 21, 2017 at 10:10 AM." is what my browser tells me. I know issue tracking has moved to github, but there are still links pointing into the bugs.ecmascript.org tracker in various places, and finding the

Re: Which engine is right about with statement and Symbol.unscopables?

On 2/20/17 10:00 AM, Michał Wadas wrote: http://stackoverflow.com/questions/40595389/why-does-browser-get-symbol-unscopables-twice Which implementation is bugged? Can someone familiar specification details fill bug in proper engine? var a, b, flag = true with (a = { x: 7 }) with (b =

Re: getOwnPropertyDescriptor side effects

On 1/21/17 1:14 AM, Jordan Harband wrote: In that case I would be delighted if you filed this as an issue on the repo. I would be delighted to do it, if it had not been filed back in November, including the comments about how your description of the Firefox behavior doesn't match the actual

Re: getOwnPropertyDescriptor side effects

On 1/20/17 2:26 PM, Jordan Harband wrote: Also note that for changing existing behavior to be "web incompatible", all the browsers have to *agree* on it That may or may not be true. But in any case, this proposal specifies behavior that disagrees with all browsers, who agree with each other.

Re: getOwnPropertyDescriptor side effects

On 1/19/17 12:24 PM, Isiah Meadows wrote: 1. What does Firefox do with the getter on non-errors? Oh, I didn't make that clear, did I? On a non-error in the getter, we have an Error object or Error.prototype (which appeared somewhere on our receiver's proto chain). Those objects all have,

Re: getOwnPropertyDescriptor side effects

On 1/19/17 2:33 AM, Jordan Harband wrote: The beginnings of the Error Stacks proposal is now up at https://github.com/ljharb/proposal-error-stacks I can't speak for other browsers, but the description of the Firefox behavior in that proposal does not look correct. Here's what I understand

Re: getOwnPropertyDescriptor side effects

On 1/11/17 8:55 PM, Isiah Meadows wrote: I was expecting the error to throw on invoking the getter. Calling `Object.getOwnPropertyDescriptor` should *never* do that (spec invariant). There is no getter, from the JS point of view. It's a value property. That's the whole point of this

Re: getOwnPropertyDescriptor side effects

On 1/11/17 3:12 PM, Isiah Meadows wrote: Okay. The error stack being constructed that early is odd, though. I'm not sure I follow. The error stack in SpiderMonkey and V8 (and JavaScriptCore too, afaict) is captured at the point when the Error object is created. The captured thing is

Re: getOwnPropertyDescriptor side effects

On 1/11/17 6:43 AM, Isiah Meadows wrote: Not if it's (likely) throwing from the `new Error`. It's not. The "stack" property in V8 quacks like a value property for the most part, but the first access to it invokes some code that does the (lazy) stack string construction. That process

Re: getOwnPropertyDescriptor side effects

On 1/10/17 2:54 PM, Michał Wadas wrote: Internal slots correspond to internal state that is associated with objects and used by various ECMAScript specification algorithms. *Internal slots are not object properties* and they are not inherited. OK, so having an internal slot for the value of

Re: getOwnPropertyDescriptor side effects

On 1/10/17 2:31 PM, Michał Wadas wrote: Implementations are allowed to extend objects. Otherwise presence of global/console/// would violate spec... http://www.ecma-international.org/ecma-262/6.0/#sec-global-object explicitly says that the global object may have additional properties, so

Re: getOwnPropertyDescriptor side effects

On 1/10/17 2:10 PM, Raul-Sebastian Mihăilă wrote: Do you mean that an implementation is allowed to return an exotic object from the Error constructor? No, I'm saying some implementations do that, because they want to implement a non-standard "stack" property and the only way to get

Re: getOwnPropertyDescriptor side effects

On 1/10/17 1:56 AM, Raul-Sebastian Mihăilă wrote: Even if the `stack` property is non-standard, getting its property descriptor must follow the same general rules for ordinary objects. Not if its (non-standard) implementation makes the object itself non-ordinary (again, non-standard)...

Re: Accesssing ES6 class constructor function

On 1/5/17 2:21 PM, James Treworgy wrote: function createInstance(Cotr, args /* array */) { function F() { // this is dynamic in reality but simple example of injecting something... this.logger = new Logger(); var instance = Cotr.apply(this, args) So the thing is...

Re: Proxy

On 12/14/16 8:47 PM, Uther Pendragon wrote: Perhaps it's a bit late... but I'd like to discuss the proxy object. Notably: why no way to define a hook for when a property is called as a function. See thread at . I think I understand

Re: Destructuring object outside of var declaration

On 11/15/16 1:57 PM, Claude Pache wrote: My guess is that Thaddee Tyl was confused by a Chrome DevTools feature, as in: I considered that, but I actually got consistent results both in Chrome's console and in a webpage... -Boris ___ es-discuss

Re: Destructuring object outside of var declaration

On 11/13/16 1:28 PM, Thaddee Tyl wrote: var foo, bar; {foo, bar} = {foo: 2, bar: 3}; is a "SyntaxError: expected expression, got '='" in Firefox, and *it works in Google Chrome*. I get "Uncaught SyntaxError: Unexpected token =" in Chrome "56.0.2914.3 dev" and in Chrome "54.0.2840.9"

Re: Proposal of Multithread JavaScript

On 11/4/16 3:16 AM, doodad-js Admin wrote: Using threads and shared objects, IPC and serialization/deserialization of objects will no longer be required. Just so we're clear, what _will_ be required, in the VM, is locking around property access and a GC that can deal with multiple threads,

Re: Conditional object properties

On 11/2/16 9:04 AM, kdex wrote: I'd imagine that from an engine point of view, this means that fewer object shapes land in memory, at least for v8. I'm pretty sure it means nothing of the sort in SpiderMonkey (in terms of memory usage, not in terms of object shapes that flow through

Re: Standardize ES Worker

On 10/31/16 8:42 AM, Isiah Meadows wrote: When the worker has finished loading, so you can send and receive messages OK, what about a worker that when it loads just starts and infinite loop and starts sending you messages (but obviously never expects any messages from you, since it's in an

Re: change behavior of Array.prototype.push?

On 10/29/16 6:15 PM, Jordan Harband wrote: Please do file this Firefox bug ASAP, so they can correct it. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1313891 -Boris ___ es-discuss mailing list es-discuss@mozilla.org

Re: Standardize ES Worker

On 10/27/16 6:18 PM, Isiah Meadows wrote: 1. Add a new `import.fork(script): Promise` method-like expression that loads the worker and resolves when done/rejects if it couldn't for some reason. What does "done" mean in this case? - `worker.send(message, sharedBuffers?)` - Send a message

Re: Standardize ES Worker

On 10/27/16 1:47 PM, Michał Wadas wrote: It's already handled by current specification as structured clone algorithm. Sort of. Not all things can be structured cloned. A fetch Response, for example, can't be, and that's what the example being discussed was using... -Boris

Re: Standardize ES Worker

On 10/27/16 10:02 AM, Frankie Bagnardi wrote: It doesn't really need to clone anything, you just create a promise on each side, on top of the normal events. And how is the resolution value transferred over? This is the cloning step! -Boris ___

Re: Standardize ES Worker

On 10/27/16 9:48 AM, Michał Wadas wrote: Currently we put emphasis on request-response model - we request something from function (returning Promise/taking callback) and we wait for single return value. Workers are different beasts - they can emit messages on their own and don't have to emit ANY

Re: Intl currency formatting and minimum significant digits

On 10/22/16 12:52 AM, Zach Lym wrote: I recently ran into a discrepancy between Chrome and Firefox's implementation of Intl's currency formatting mechanism and the official spec. I didn't want the output to have any significant digits so I used the following: new Intl.NumberFormat('en-US',

Re: Code smell? Iterator prototype has iterator method that returns "this"

On 7/25/16 11:19 AM, John Lenz wrote: Can anyone provide any historical context on why this method was added to the "iterator"? The idea is that you can do this: for (var something of myarray.entries()) and similar for other iterator-returning methods. The way for-of works is that it

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

On 7/13/16 10:59 AM, Michael Kriegel wrote: So what does gc do to determine, whether an object still has hard references pointing towards it? The GC may be conservative, not be precise. That is, it may not collect some stuff that actually could be collected because the GC thinks there are

Re: Feature-Request: allow to iterate over WeakSet / WeakMap

On 7/13/16 10:18 AM, Michael Kriegel wrote: But shouldn't it be predictable, whether there are still "non-weak" references to an object? Maybe. The GC may include a machine stack scanner to root things referenced on the stack, which can give false positives depending on what integers happen

Re: Has there been any discussions around standardizing socket or file io usage?

On 6/17/16 10:35 AM, David Bruant wrote: Specifically, even if there was a standard why would Node or browser makers implement it given they already have an API for the job and lots of code is already written on top of these APIs? The other issue, of course, is that Node and browsers have very

Re: Oddly accepted RegExps

On 6/3/16 4:20 AM, Isiah Meadows wrote: These three RegExps don't appear valid, even after reading the Annex B, but they do behave consistently in both Chrome and Firefox. Note that Chrome and Firefox use the same regexp implementation, so them agreeing on how a regexp is handled means a lot

Re: extending an ES6 class using ES5 syntax?

On 5/14/16 3:11 AM, Andrea Giammarchi wrote: 1. why is that? Why does mutating the proto after an object has been exposed to script end up deoptimizing things? Because it invalidates assumptions JITs otherwise make. So the options are to make the proto-hasn't-been-mutated case slower by

Re: extending an ES6 class using ES5 syntax?

On 5/13/16 9:04 PM, Domenic Denicola wrote: Object.setPrototypeOf(obj, new.target.prototype); // or B.prototype, but if you derive from B you'll have to do this dance again This is highly undesirable because it will deoptimize in implementations in practice. That said, can't the right

Re: Error-Type Specific try/catch Blocks

On 5/13/16 11:06 AM, Joseph Groseclose wrote: I sent this proposal via http://www.ecma-international.org/memento/contribute_TC39_Royalty_Free_Task_Group.php# yesterday evening. Sharing it here now: https://github.com/benderTheCrime/error-type-specific-catch-proposal I'd like to understand the

Re: Better way to maintain this reference on event listener functions

On 5/9/16 12:37 PM, Mark Kennedy wrote: and also REMOVING the event listeners manually. I think this is the key part. What is the precise use case for removing here? I think that affects how this would best be designed. The obvious case is when you want to remove the listener at the point

Re: Is `undefined` garabage collectable?

On 5/4/16 5:03 PM, Steve Fink wrote: The only v8 shell I have lying around is too old (3.14.5.10) to have Set, so I can't tell you what it would do. I have v8 "4.8.0 (candidate)" (meaning whatever rev I checked out), and it does 1163 minor ("Scavenge") GCs on your testcase. It also does 1163

Re: Proposal: Switch position of delay and callback in signature of `setTimeout()`

On 4/25/16 1:35 PM, Adrian Sieber wrote: Everytime I use `setTimeout()`, I wonder why the the arguments are in the wrong order. Usually the callback functions comes last, but in 'setTimeout' it's exactly the other way round. First, this is the wrong list: setTimeout is defined by

Re: Promises, async functions, and requestAnimationFrame, together.

On 4/23/16 4:09 AM, Salvador de la Puente González wrote: AFAIK, that should execute `drawSomething()` once per frame. Given a frame is each time the animatinFrame() promise resolves. What's not obvious to me is whether it will execute it before the actual paint for the frame (i.e. before or

Re: {}+{} incosistency

On 4/13/16 12:08 PM, Boris Zbarsky wrote: It sounds like all the actual JS engines involved get all of this right; the only difference is whether evaluation in the browser's console happens in an expression context or in a statement context. And in particular, it seems like most browsers

Re: {}+{} incosistency

On 4/13/16 12:04 PM, Allen Wirfs-Brock wrote: The V8 result is correct In an expression context. It sounds like all the actual JS engines involved get all of this right; the only difference is whether evaluation in the browser's console happens in an expression context or in a statement

Re: Is there a way to run test262 in a browser (and especially in web workers)?

On 3/17/16 11:42 AM, Leo Balter wrote: The current website needs an update. If it makes less painful to run the tests on a shell, you can try https://github.com/bterlson/eshost I'm specifically looking for a harness that will run the tests in a web worker, so I'm not sure that this helps

Is there a way to run test262 in a browser (and especially in web workers)?

It looks like there used to be a http://ie.microsoft.com/testdrive/HTML5/WebWorkerTest262/Default.html but it's gone. There also used to be a http://test262.ecmascript.org/ (linked from various places on the ecmascript.org wiki) but that's gone too. Does anyone know whether this test is

Re: GC/Compile requests, with 3D engine demonstration

On 3/13/16 10:43 PM, Brian Barnes wrote: 1. Potential mis-use of API could make things slower 2. People assuming things could freeze behavior 3. People will assume behavior outside of the spec 4. What does GC mean? People will assume everything. I think #1 there is a mechanism of #2, in that

Re: GC/Compile requests, with 3D engine demonstration

On 3/13/16 5:30 PM, Brian Barnes wrote: “Perfect is the enemy of the good.” This is true, but... I’m asking for a specific, useful function, not the perfect solution to my problem. The problem is that the function you're asking for can be really really bad in some situations. So if we

Re: GC/Compile requests, with 3D engine demonstration

On 3/13/16 4:06 PM, Brian Barnes wrote: The second part was a hint to tell the engine to always take the most aggressive route with optimization By which I assume you mean still running in the lower interpreter/JIT levels until you have gathered sufficient profiling information, but not

Re: GC/Compile requests, with 3D engine demonstration

On 3/13/16 6:27 AM, Florian Bösch wrote: JS'es stop-the-world mark for however long it takes approach to GC'ing is very troublesome. That's certainly not the way SpiderMonkey's GC is meant to work (it's an incremental GC with a per-slice time budget)... Adding some more flexible ways to

Re: GC/Compile requests, with 3D engine demonstration

On 3/12/16 10:52 PM, Brian Barnes wrote: What I'm trying to say is that it may well not, if it just called JS_GC and if the problem to be solved is pauses on the order of several tens to hundreds of milliseconds due to memory collection activity… Time is not my concern. I’m trading time now

Re: GC/Compile requests, with 3D engine demonstration

On 3/12/16 10:22 PM, Brian Barnes wrote: We’re closing in on something! This could have been clearer on my end; I am looking at only javascript objects. My code, for instance, interacts only though a webgl context; it never creates any nodes or does anything outside of javascript. But it

Re: GC/Compile requests, with 3D engine demonstration

On 3/12/16 9:52 PM, Brian Barnes wrote: This is key: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Memory_Management When the mozilla docs refer to GC, they refer to mark-and-sweep objects created by the user’s code. User code creates lots of objects in Firefox whose memory

Re: GC/Compile requests, with 3D engine demonstration

On 3/12/16 9:11 PM, Brian Barnes wrote: The contract would be, if the engine is GC (which is likely, as I pointed out without compiling or additions to the language), then do as much clean up as possible. What does that mean, exactly? In the case of SpiderMonkey+Gecko, should that run the

Re: GC/Compile requests, with 3D engine demonstration

On 3/12/16 8:08 PM, Brian Barnes wrote: As for being a de-optimization hazard, that’s certain a problem, but we shouldn’t disallow the usage of something because programmers are bad. It's not a matter of badness or goodness. It's a matter of programmer expectations not matching the actual

Re: Error stack strawman

On 2/24/16 6:59 PM, Steve Fink wrote: (Or at least, that's my understanding of what is going on. I'm not sure if that stuff is used for Error.stack yet.) It is. See https://bugzilla.mozilla.org/show_bug.cgi?id=1038238 -Boris ___ es-discuss mailing

Re: Error stack strawman

On 2/24/16 5:35 PM, Boris Zbarsky wrote: Clearly this Just Works with a value property, across all browsers at that point, so we made it work with the accessor too. Oh, and we made it work the way [Replaceable] stuff on window works: the setter defines a value property on the object which

Re: Error stack strawman

On 2/24/16 4:30 PM, Mark S. Miller wrote: [1] For some reason the FF stack accessor has both getter and setter. I don't see any reason for a setter. We ran into code "in the wild" (more precisely, within our own test suite infrastructure, but we have no reason to believe this would not

Re: es7 proposal/polyfill?: base Map/WeakMap off Proxy + Weak References

On 2/19/16 3:50 PM, Coroutines wrote: Side discussion: Why does Javascript have this limitation? - what I view as a limitation? You'd think this could be supported without breaking older JS.. I don't see how it could. I'll bet $50 someone out there is using obj[location] for example.

Re: Weak Reference proposal

On 2/17/16 8:30 AM, Joris van der Wel wrote: XMLHttpRequest, fetch, WebSocket, etc would even require a something similar to a phantom reference (like in java) so that we can close the connection when the object is no longer strongly or weakly referenced. None of these allow closing the

Re: Garbage collection in generators

On 2/17/16 3:59 AM, Benjamin Gruenbaum wrote: Garbage collection can and does in fact manage resources in JavaScript host environments right now. For example, an XMLHttpRequest /may /abort the underlying HTTP request if the XMLHttpObject is not referenced anywhere and gets garbage collected.

Re: Any reason why __proto__ is not a well known symbol?

On 2/16/16 12:01 PM, Coroutines wrote: I hope ES7 makes breaking changes all over the place Do you also hope ES7 never ships in any web browsers? Just checking, Boris ___ es-discuss mailing list es-discuss@mozilla.org

Re: Error stack strawman

On 2/10/16 4:52 AM, Jonathan Kingston wrote: @Boris does the main difficulties hinge on document.domain? Main difficulties with what? -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Error stack strawman

On 2/10/16 9:47 PM, Jonathan Kingston wrote: Could the trace output just finish early at these origin boundaries The problem is that some browsers don't have origin boundaries at all in places where others do. -Boris ___ es-discuss mailing list

Re: Error stack strawman

On 2/10/16 7:12 PM, Jonathan Kingston wrote: Is implementing stack traces cross browser mostly difficult because of the use of document.domain or are there other issues blocking? Ah, you mean in terms of interop? I expect document.domain and built-ins to be the main thing that browsers will

Re: Error stack strawman

On 1/25/16 1:55 PM, Gary Guo wrote: I believe a lot of additional work needs to be done for this proposal to make it works across realm. Consider the invocation chain: alpha, alpha0 (in realm A) beta, beta0 (in realm B) alpha -> alpha0 -> beta -> beta0 -> alpha ->alpha0 -> beta -> beta0 ->

Re: Error stack strawman

On 1/22/16 4:51 PM, Terry Stanley wrote: Breaking on console.log: FF debugger showed single turn call stack Chrome debugger with Async selected showed deep stack Console output: FF showed deep stack (as expected) Chrome showed single turn Seems like people are incrementally

Re: Error stack strawman

On 1/20/16 10:10 AM, Mark S. Miller wrote: I think the useful thing to do is to standardize the extended Causeway stack trace format: This format doesn't have an obvious way to represent "async stacks" [1], short of hacks with the "functionName" or the "source", right? Gecko right now

Re: Could String internalize an ArrayBuffer?

On 12/5/15 8:44 AM, Coroutines wrote: What I want is to be able to view a String through a typed array without duplicating the memory/contents of that string. The big problem with this is that the actual in-memory representations of strings and arraybuffers can be quite different in

Re: Javascript Code Churn Rate?

On 11/10/15 7:41 AM, Ethan Resnick wrote: And how long until they could remove support for the rest of the language altogether? This makes the fundamental assumption that it's OK to break old things just because they're old. To the extent that the web is used for applications, this is

Re: resolve()/reject() on Promise subclasses and @@species

On 11/4/15 10:29 PM, C. Scott Ananian wrote: Again, the reasoning at the time was that `Promise.all(x)` could be considered sugar for `Promise.resolve(x).all()` in ES7, and so `Promise.all` was "really" an instance method after all. OK, but note that the behavior of the two is different (or at

Re: resolve()/reject() on Promise subclasses and @@species

On 11/4/15 9:36 PM, Domenic Denicola wrote: But it seems that ES15 decided to only use @@species for instance methods Except it also uses it for Promise.all and Promise.race. -Boris ___ es-discuss mailing list es-discuss@mozilla.org

  1   2   3   4   5   >