Re: Modules vs Scripts
>> Is the value of `src` a module ID or a path? How about when packages are >> used (for bundling)? Is there a way to combine module IDs and packages? > > For the most part the answer to these kinds of questions is that we support > "all of the above," but I'd like to wait just a little bit longer before > getting into details. Right now we've been focusing on providing a complete > base (reflective) layer via the Loader API, which is what will be in > ECMA-262; the rest is an HTML spec. (We are thinking through what pieces are > necessary for the tag to ensure we haven't missed anything in the > Loader API.) I'm focused on getting ES6 out the door, but the next step after > that is to start fleshing out the spec. That makes sense. So, for starters, I’m guessing one will set up the module loader via a
Re: Typed Objects / Binary Data Polyfills
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 < t...@tillschneidereit.net> wrote: > Oh, of course: I completely forgot about that. Thanks for the link! > > > > On Sun, Nov 17, 2013 at 10:42 PM, Dmitry Lomov 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 < >> t...@tillschneidereit.net> wrote: >> >>> On Sun, Nov 17, 2013 at 10:23 AM, K. Gadd 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 >>> es-discuss@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> >> -- >> Google Germany GmbH >> *Dienerstr. 12, 80331 München., DE * >> > > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Typed Objects / Binary Data Polyfills
Oh, of course: I completely forgot about that. Thanks for the link! On Sun, Nov 17, 2013 at 10:42 PM, Dmitry Lomov 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 < > t...@tillschneidereit.net> wrote: > >> On Sun, Nov 17, 2013 at 10:23 AM, K. Gadd 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 >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Google Germany GmbH > *Dienerstr. 12, 80331 München., DE * > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
On Nov 17, 2013, at 11:59 AM, Axel Rauschmayer wrote: > On Nov 17, 2013, at 6:14 , David Herman wrote: > >>> Does this imply ? >> >> Works either way, inline or external. (Requiring src="" is one of the >> reasons why
Re: Typed Objects / Binary Data Polyfills
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 < t...@tillschneidereit.net> wrote: > On Sun, Nov 17, 2013 at 10:23 AM, K. Gadd 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 > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Google Germany GmbH *Dienerstr. 12, 80331 München., DE * ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Modules vs Scripts
On Nov 17, 2013, at 6:14 , David Herman wrote: >> Does this imply ? > > Works either way, inline or external. (Requiring src="" is one of the reasons > why
Re: Typed Objects / Binary Data Polyfills
Since the strawman is close to the final spec, questions/nitpicks: I noticed the current spec explicitly provides no control over element alignment/padding. Are there specific reasons behind that? It dramatically reduces the value of typed objects for doing file I/O (aside from the endianness problem, which actually doesn't matter in many of those cases), and it means they can't be used to provide direct compatibility with C struct layouts in specific cases - for example, filling vertex buffers. I understand that there is no desire to provide the *full* feature set available in C (fixed-size arrays, variable-size structs, etc.) but alignment/padding control is used quite a bit. DataView has significant performance issues (some due to immature v8/spidermonkey implementations, some due to the design) that make it unsuitable for most of these use cases, even if it's the 'right' way to handle endianness (disputable). The handwaving that WebGL implementations can 'just introspect' in these cases seems shortsighted considering the reality of WebGL: hundreds of shipped libraries and apps using current WebGL cannot be guaranteed to keep doing the right thing when interacting with typed arrays. If a typed array full of Typed Objects can still be treated like an array full of bytes or float32s, that allows existing WebGL code to keep working, as long as you ensure the layout of the objects is correct. That means people can start incrementally adding uses of Typed Objects to their code right away - and it means they can introduce them based on a polyfill of Typed Objects instead of waiting for the browser to implement *both* Typed Objects and new WebGL support for Typed Objects. My primitives have control over alignment/padding and it doesn't seem to be that hard to implement (in JS, that is) - are there things that make this hard to provide from inside a VM? Being able to add extra padding, at least, would be pretty useful even if alignment has to remain locked to whatever the requirements are. I see reference types are exposed (string, object, any) - the way this actually works needs to be clearly stated. Is it storing a GC pointer into the buffer? Are there safety concerns if it's overwritten, or loaded from a json blob or something else like that? How big are string/object/any in the internal representation? Does their size depend on whether the running browser is 32-bit or 64-bit? I'd be open to collaborating on a polyfill of Typed Objects once it's clear how they actually work. We can repurpose JSIL's existing implementation and modify it to get the semantics in the spec. On Sun, Nov 17, 2013 at 5:04 AM, Till Schneidereit < t...@tillschneidereit.net> wrote: > On Sun, Nov 17, 2013 at 10:23 AM, K. Gadd 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Typed Objects / Binary Data Polyfills
On Sun, Nov 17, 2013 at 10:23 AM, K. Gadd 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Typed Objects / Binary Data Polyfills
Are there any known-good polyfills for the current draft Typed Objects / Binary Data spec? 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 :) -kg ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
