Re: stable sort proposal

@Tab Atkins Jr., The only question is how much slower/more expensiver stable sorting is than unstable sorting, and whether that cost is sufficient to outweigh the usefulness of a stable sort. My own experiment shows, that QuickSort (unstable) is ~20% (or more) faster on "random" array of

Re: Async iteration

I would be super surprised if I could use `var` everywhere _except_ async iteration. So I'd say consistency triumphs. Same reason all the ES2015 features exist in non-strict mode. Also, you might want to look at the async/await pep for why Python has added async iteration in 3.5 > On 14 Mar

Re: stable sort proposal

On Mon, Mar 14, 2016 at 2:16 PM, Tab Atkins Jr. wrote: > On Fri, Mar 11, 2016 at 8:17 PM, Isiah Meadows > wrote: > > In my honest opinion, there's not much reason to just require the sort > to be > > stable. Some engines have done this in the past,

Re: Async iteration

On Mon, Mar 14, 2016 at 11:19 AM, Kevin Smith wrote: > Is there a summary of the motivation for "for-await" and "async iteration" >> in general? >> > > There's a short section at: > https://github.com/tc39/proposal-async-iteration#overview-and-motivation > Thanks > > >>

Re: Async iteration

> > Is there a summary of the motivation for "for-await" and "async iteration" > in general? > There's a short section at: https://github.com/tc39/proposal-async-iteration#overview-and-motivation > Has there any discussion in not supporting "var" in "for-await" > initializers? > Symmetry with

Re: stable sort proposal

On Fri, Mar 11, 2016 at 8:17 PM, Isiah Meadows wrote: > In my honest opinion, there's not much reason to just require the sort to be > stable. Some engines have done this in the past, and the spec technically > allows it. At this point, stable sorts are about as fast as

Async iteration

Two things: Is there a summary of the motivation for "for-await" and "async iteration" in general? Has there any discussion in not supporting "var" in "for-await" initializers? ___ es-discuss mailing list es-discuss@mozilla.org

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

> On Mar 14, 2016, at 12:28 PM, Steve Fink wrote: > > Well, "the most aggressive compilation" is undecidable in general, since you > can't predict the future to know if some future execution won't invalidate > this or that constraint. But sure, I think we're basically

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

> On Mar 14, 2016, at 12:52 PM, Steve Fink wrote: > > On 03/14/2016 06:35 AM, Brian Barnes wrote: >> The more we discuss this, the more I think this problem isn't solvable >> without something radical that makes Javascript more C like. Which, I think, >> is probably some of

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

On 03/14/2016 06:35 AM, Brian Barnes wrote: The more we discuss this, the more I think this problem isn't solvable without something radical that makes Javascript more C like. Which, I think, is probably some of the reason for asm.js. The problem: People want to create realtime games, VR,

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

On 03/13/2016 02:50 PM, Brian Barnes wrote: On Mar 13, 2016, at 5:22 PM, Steve Fink > wrote: This is a good time to bring up the other half of my original email because a number of other people have chimed in with their experiences with GC when

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

I think that's a good, workable solution, and would help with my specific problem. [>] Brian On 3/14/2016 10:43 AM, Boris Zbarsky wrote: 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

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

I think introducing such manual memory collection would be much harder than standardizing some kind of foreign function interface and just connecting JavaScript to language that is better at dealing with specific task (eg. WebAssembly). 2016-03-14 14:35 GMT+01:00 Brian Barnes

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

The more we discuss this, the more I think this problem isn't solvable without something radical that makes Javascript more C like. Which, I think, is probably some of the reason for asm.js. The problem: People want to create realtime games, VR, animations, without stutter. You can get away

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

On Sat, Mar 12, 2016 at 6:27 AM, Brian Barnes wrote: > Request 1: Add a System module, and one call I need System.gc(); I do not think this is wise to make such calls, at least not the same way they are implemented in the shell. Currently the shells have a global gc