Nice script indeed, and it would be very nice to somehow be able to flag that module for production/performance reason where slower engines in slower hardware are not penalized much if the native implementation is not in place.
Something that acts almost transparently, if that makes sense at all. Cheers On Sun, Nov 17, 2013 at 2:59 PM, Till Schneidereit < [email protected]> wrote: > Oh, of course: I completely forgot about that. Thanks for the link! > > > > On Sun, Nov 17, 2013 at 10:42 PM, Dmitry Lomov <[email protected]> wrote: > >> Typed Objects polyfill lives here: https://github.com/dherman/structs.js >> Dave and I work on it, current status is pretty close to strawman minus >> handles and cursors (which are a bit controversial at this point and as far >> as I understand are not is Firefox implementation). >> The polyfill includes a bunch of tests; I haven't yet run it on Mozilla >> tests - will get to it soon hopefully. >> >> I welcome and will be happy to review polyfill patches. >> >> Dmitry >> >> >> On Sun, Nov 17, 2013 at 2:04 PM, Till Schneidereit < >> [email protected]> wrote: >> >>> On Sun, Nov 17, 2013 at 10:23 AM, K. Gadd <[email protected]> wrote: >>> >>>> Are there any known-good polyfills for the current draft Typed Objects >>>> / Binary Data spec? >>>> >>> >>> I want this, too, and will start working on it soon-ish if nobody else >>> does or already did. >>> >>> >>>> Presently, JSIL has a set of primitives that roughly correspond with a >>>> big chunk of the draft specification. I'm interested in seeing whether they >>>> can work atop ES6 typed objects, which means either adapting it to sit on >>>> top of an existing polyfill, or turning my primitives into a polyfill for >>>> the draft spec. If it's useful I might be able to find time for the latter >>>> - would having a polyfill like that be useful (assuming a good one doesn't >>>> already exist)? >>>> >>>> Having an efficient equivalent to the spec in JS VMs is pretty >>>> important for JSIL to ever be able to deliver emscripten-level performance >>>> (a single emscripten-style fake heap is not an option because .NET relies >>>> on garbage collection). If a polyfill (even a partial one) could help move >>>> the process along for the spec, that'd be great. If what the process >>>> actually needs is some sort of feedback, maybe I could offer that instead. >>>> The status of the spec is unclear to me :) >>>> >>> >>> The strawman at [1] is fairly close to what's going to end up in the >>> spec, content-wise. Additionally, the implementation in SpiderMonkey is >>> pretty complete by now, and there are lots of tests[2]. I don't know what >>> the timing for integrating Typed Objects into the spec proper is, cc'ing >>> Niko for that. >>> >>> >>> cheers, >>> till >>> >>> >>> [1]: http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects >>> [2]: >>> http://mxr.mozilla.org/mozilla-central/source/js/src/tests/ecma_6/TypedObject/ >>> >>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> >> -- >> Google Germany GmbH >> *Dienerstr. 12, 80331 München., DE * >> > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
