Re: preventExtensions trap and its true/false protocol
2013/4/1 Jeff Walden jwalden...@mit.edu Note that this could also be construed as a feature, in certain cases. The dead object proxy Mozilla has, previously mentioned here (can't find a link), has all its traps throw an error with a message saying Dead object. If the trap returns true/false, it's no longer possible for preventExtensions to say that the object in question is dead, not just can't be made non-extensible. The true/false return protocol doesn't prevent exceptions to be thrown from the trap. It's perfectly fine for the dead object proxy's preventExtensions trap to throw an object is dead exception. In fact, that's precisely what would happen if one would call preventExtensions on a revoked revocable proxy. Cheers, Tom ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: RegExp Flags
Should this be added to test-262? It'd be cool if test-262 took pull requests :). From: es-discuss-boun...@mozilla.org [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Yusuke SUZUKI Sent: Monday, April 1, 2013 22:44 To: Allen Wirfs-Brock Cc: es-discuss@mozilla.org Subject: Re: RegExp Flags I've already reported this issue :) https://code.google.com/p/v8/issues/detail?id=896 On Tue, Apr 2, 2013 at 2:33 PM, Allen Wirfs-Brock al...@wirfs-brock.commailto:al...@wirfs-brock.com wrote: Original message Subject:RE: RegExp Flags From:Allen Wirfs-Brock al...@wirfs-brock.commailto:al...@wirfs-brock.com To:zenpars...@gmail.commailto:to%3azenpars...@gmail.com Cc: It's supposed to be an early syntax error. See last sentence of http://www.ecma-international.org/ecma-262/5.1/#sec-7.8.5 ___ es-discuss mailing list es-discuss@mozilla.orgmailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Add intersections and unions to Set
+1 Additionally I propose to give more JS friendly method names: Intersection as `and`: set1and2 = set1.and(set2); Union as `or`: set1or2 = set1.or(set2); Complement as `not`: set1butNot2 = set1.not(set2); Peter Michaux wrote: On Mon, Mar 4, 2013 at 10:56 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Mar 4, 2013 at 10:08 AM, al...@instantbird.org wrote: It would be useful to be able to form the intersection and the union of two Sets. These are natural operations that are currently not part of the API (http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets). Similar methods would make sense for Map, but one would have to think about what to do in the case where the key but not the value matches. An intersection is equivalent to a particular filter, so an alternative might be to add a method like Array.filter to Sets instead. (I filed bug 847355 for this and was told this mailing list was the right place for this suggestion.) Yes please, and also minus (remove from set A all elements it shares with set B). All three of these are fairly vital for a lot of code using sets. I agree that these methods would be useful. They are common set operations and they do seem missing from the Set draft spec. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss - Mariusz Nowak https://github.com/medikoo -- View this message in context: http://old.nabble.com/Add-intersections-and-unions-to-Set-tp35134737p35243086.html Sent from the Mozilla - ECMAScript 4 discussion mailing list archive at Nabble.com. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Object Literal Extensions
Is there any collected reference to what's been accepted from Object
Literal Extensions [1]? There's definitely out of date stuff on there
and I'm not sure what things have been formally accepted (with
consensus) for ES6, which are generally assumed to be accepted for ES6,
and which are definitely not going to be for ES6. For example, object
literal property shorthands (method) seem like something that's
generally accepted to be in ES6 (people often use it in example code
here on es-discuss) but I can't find a reference to where it was
actually agreed upon.
Another related thing that's not at that page but is related is
shorthand object initializers, like `var a = 5, b = 10, x = { a, b }`
which I only see mentioned under the issues in [2]. This seems like an
easy feature for ES6 but I can't find any formal discussion of it.
The reason I ask is because I don't see bugs related to implementing any
of these features for either V8 or SpiderMonkey which leaves me
wondering what is intended to be in ES6.
[1] http://wiki.ecmascript.org/doku.php?id=harmony:object_literals
[2] http://wiki.ecmascript.org/doku.php?id=harmony:destructuring
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object Literal Extensions
It's all in the specification draft.
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-11.1.5
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-13.3
In general, read the spec. draft not the wiki pages which are neither complete,
accurate, or normative.
allen
On Apr 2, 2013, at 10:21 AM, Brandon Benvie wrote:
Is there any collected reference to what's been accepted from Object Literal
Extensions [1]? There's definitely out of date stuff on there and I'm not
sure what things have been formally accepted (with consensus) for ES6, which
are generally assumed to be accepted for ES6, and which are definitely not
going to be for ES6. For example, object literal property shorthands (method)
seem like something that's generally accepted to be in ES6 (people often use
it in example code here on es-discuss) but I can't find a reference to where
it was actually agreed upon.
Another related thing that's not at that page but is related is shorthand
object initializers, like `var a = 5, b = 10, x = { a, b }` which I only see
mentioned under the issues in [2]. This seems like an easy feature for ES6
but I can't find any formal discussion of it.
The reason I ask is because I don't see bugs related to implementing any of
these features for either V8 or SpiderMonkey which leaves me wondering what
is intended to be in ES6.
[1] http://wiki.ecmascript.org/doku.php?id=harmony:object_literals
[2] http://wiki.ecmascript.org/doku.php?id=harmony:destructuring
___
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: Object Literal Extensions
On 4/2/2013 10:40 AM, Allen Wirfs-Brock wrote: It's all in the specification draft. http://people.mozilla.org/~jorendorff/es6-draft.html#sec-11.1.5 http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-11.1.5 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-13.3 http://people.mozilla.org/%7Ejorendorff/es6-draft.html#sec-13.3 In general, read the spec. draft not the wiki pages which are neither complete, accurate, or normative. allen I don't know how i missed this. Nevermind me. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: endianness
On 4/1/2013 10:24 PM, Kenneth Russell wrote: On Sun, Mar 31, 2013 at 1:42 PM, Kevin Gadd kevin.g...@gmail.com wrote: One could also argue that people using typed arrays to alias and munge individual values should be using DataView instead. If it performs poorly, that can hopefully be addressed in the JS runtimes (the way it's specified doesn't seem to prevent it from being efficient). Agreed. DataView's methods are all simple and should be easy to optimize. Because they include a conditional byte swap, they can't run quite as fast as the typed arrays' accessors -- but they shouldn't need to. Side note: in theory they could run extremely fast, as long as the endianness parameter was a constant. Since you generally know the format of the data coming over the network, it should be except in rare cases. The implementation knows the native endianness and can just choose the right load/store variant when generating JIT code for the call. However, they can also read from unaligned offsets, and so that will slow things down a bit. Either way -- they could be much faster than they are now. - Vlad ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: RegExp Flags
It;s moved and morphed:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-11.1.8
Got it - thanks!
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: endianness
Le 02/04/2013 04:24, Kenneth Russell a écrit : Agreed. DataView's methods are all simple and should be easy to optimize. Because they include a conditional byte swap, they can't run quite as fast as the typed arrays' accessors -- but they shouldn't need to. DataView was designed to support file and network I/O, where throughput is limited by the disk or network connection. The typed array views were designed for in-memory assembly of data to be submitted to the graphics card, sound card, etc., and must run as fast as possible. When you are streaming things, what's the correct use of DataViews? ie : you are supposed to create each time you want to read some bytes a DataView (which can be optimized or whatever, but still with some costs)? Maybe it's outside of the scope of this discussion, I have already provided examples, I still suspect that I am using it wrongly or that ArrayBuffers are more adapted to webgl (ie static buffer manipulation) than network streaming (ie dynamic buffer manipulation). Probably I am wrong but really would like to know then what's the correct use. Regards, -- jCore Email : avi...@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web :www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: endianness
On Tue, Apr 2, 2013 at 3:03 PM, Aymeric Vitte vitteayme...@gmail.com wrote: Le 02/04/2013 04:24, Kenneth Russell a écrit : Agreed. DataView's methods are all simple and should be easy to optimize. Because they include a conditional byte swap, they can't run quite as fast as the typed arrays' accessors -- but they shouldn't need to. DataView was designed to support file and network I/O, where throughput is limited by the disk or network connection. The typed array views were designed for in-memory assembly of data to be submitted to the graphics card, sound card, etc., and must run as fast as possible. When you are streaming things, what's the correct use of DataViews? ie : you are supposed to create each time you want to read some bytes a DataView (which can be optimized or whatever, but still with some costs)? Maybe it's outside of the scope of this discussion, I have already provided examples, I still suspect that I am using it wrongly or that ArrayBuffers are more adapted to webgl (ie static buffer manipulation) than network streaming (ie dynamic buffer manipulation). Probably I am wrong but really would like to know then what's the correct use. If I understand your question, then the correct use of DataView is: upon receiving an ArrayBuffer, create a DataView referring to it. When iterating down the contents of the ArrayBuffer, continue to use the same DataView instance, just incrementing the offset. In abstract-tls/lib/abstract-tls.js there are some operations which create a new DataView just to read or write a single element; this isn't the correct usage. http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ may be a useful reference. If you're handling streaming data then presumably you're receiving multiple ArrayBuffers, one after the other. You should create one DataView per buffer. The only challenge is properly handling the boundary from one buffer to the next, if the boundary is within an element like a uint16 or uint32. -Ken ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: endianness
Is there a reason why DataView wasn't specified as static methods that take an ArrayBuffer in the first place? That would solve the problem of figuring out when/how often to create DataView instances, and eliminate the garbage created by using DataViews. On Tue, Apr 2, 2013 at 3:23 PM, Kenneth Russell k...@google.com wrote: On Tue, Apr 2, 2013 at 3:03 PM, Aymeric Vitte vitteayme...@gmail.com wrote: Le 02/04/2013 04:24, Kenneth Russell a écrit : Agreed. DataView's methods are all simple and should be easy to optimize. Because they include a conditional byte swap, they can't run quite as fast as the typed arrays' accessors -- but they shouldn't need to. DataView was designed to support file and network I/O, where throughput is limited by the disk or network connection. The typed array views were designed for in-memory assembly of data to be submitted to the graphics card, sound card, etc., and must run as fast as possible. When you are streaming things, what's the correct use of DataViews? ie : you are supposed to create each time you want to read some bytes a DataView (which can be optimized or whatever, but still with some costs)? Maybe it's outside of the scope of this discussion, I have already provided examples, I still suspect that I am using it wrongly or that ArrayBuffers are more adapted to webgl (ie static buffer manipulation) than network streaming (ie dynamic buffer manipulation). Probably I am wrong but really would like to know then what's the correct use. If I understand your question, then the correct use of DataView is: upon receiving an ArrayBuffer, create a DataView referring to it. When iterating down the contents of the ArrayBuffer, continue to use the same DataView instance, just incrementing the offset. In abstract-tls/lib/abstract-tls.js there are some operations which create a new DataView just to read or write a single element; this isn't the correct usage. http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ may be a useful reference. If you're handling streaming data then presumably you're receiving multiple ArrayBuffers, one after the other. You should create one DataView per buffer. The only challenge is properly handling the boundary from one buffer to the next, if the boundary is within an element like a uint16 or uint32. -Ken -- -kg ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: preventExtensions trap and its true/false protocol
On 04/02/2013 12:13 AM, Tom Van Cutsem wrote: The true/false return protocol doesn't prevent exceptions to be thrown from the trap. It's perfectly fine for the dead object proxy's preventExtensions trap to throw an object is dead exception. In fact, that's precisely what would happen if one would call preventExtensions on a revoked revocable proxy. Ah, yes, that's exactly right. Never mind! Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: endianness
Yes: API consistency. An ArrayBuffer is opaque; to work with the data it contains, instantiate a view. On Tue, Apr 2, 2013 at 3:36 PM, Kevin Gadd kevin.g...@gmail.com wrote: Is there a reason why DataView wasn't specified as static methods that take an ArrayBuffer in the first place? That would solve the problem of figuring out when/how often to create DataView instances, and eliminate the garbage created by using DataViews. On Tue, Apr 2, 2013 at 3:23 PM, Kenneth Russell k...@google.com wrote: On Tue, Apr 2, 2013 at 3:03 PM, Aymeric Vitte vitteayme...@gmail.com wrote: Le 02/04/2013 04:24, Kenneth Russell a écrit : Agreed. DataView's methods are all simple and should be easy to optimize. Because they include a conditional byte swap, they can't run quite as fast as the typed arrays' accessors -- but they shouldn't need to. DataView was designed to support file and network I/O, where throughput is limited by the disk or network connection. The typed array views were designed for in-memory assembly of data to be submitted to the graphics card, sound card, etc., and must run as fast as possible. When you are streaming things, what's the correct use of DataViews? ie : you are supposed to create each time you want to read some bytes a DataView (which can be optimized or whatever, but still with some costs)? Maybe it's outside of the scope of this discussion, I have already provided examples, I still suspect that I am using it wrongly or that ArrayBuffers are more adapted to webgl (ie static buffer manipulation) than network streaming (ie dynamic buffer manipulation). Probably I am wrong but really would like to know then what's the correct use. If I understand your question, then the correct use of DataView is: upon receiving an ArrayBuffer, create a DataView referring to it. When iterating down the contents of the ArrayBuffer, continue to use the same DataView instance, just incrementing the offset. In abstract-tls/lib/abstract-tls.js there are some operations which create a new DataView just to read or write a single element; this isn't the correct usage. http://www.html5rocks.com/en/tutorials/webgl/typed_arrays/ may be a useful reference. If you're handling streaming data then presumably you're receiving multiple ArrayBuffers, one after the other. You should create one DataView per buffer. The only challenge is properly handling the boundary from one buffer to the next, if the boundary is within an element like a uint16 or uint32. -Ken -- -kg ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
On 4/1/13 at 5:40 AM, sa...@ccs.neu.edu (Sam Tobin-Hochstadt) wrote: Using `.dispose()` is manual management of the allocation and deallocation of object. Manual memory management is fundamentally non-modular -- you can't encapsulate it in a library, and it requires describing memory management behavior in all your function specifications, the way that C libraries do. It's certainly possible to write large, complex apps in C. But that's not evidence that we should bring those practices to JS. There are a bunch of different reasons for wanting to dispose an object in memory. With the malloc/free system from C, you usually dispose objects to recover their backing memory for future use. The C version is not memory safe. If you are paying for the memory, you may be willing to break things to be able to stop paying. There may be some other reasons for causing an object to stop working and as a side effect recover most of its memory. A proxy can provide this service for JS, along with a number of other techniques all of which will be memory safe. For short-lived programs, you can ignore memory disposal if the system running them will free the memory when they exit. This technique is memory safe and even works with mismanagement of references in a garbage collected systems. Having a system which supports just exiting and recovering memory is valuable for ad-hoc programming environments. It might also be valuable for ads running in long-lived web pages. Possibly some of the safe JS execution environments provide this service for the programs they mediate. Memory safety is one really good reason to choose JS over C. Cheers - Bill --- Bill Frantz| The only thing we have to | Periwinkle (408)356-8506 | fear is fear itself. - FDR | 16345 Englewood Ave www.pwpconsult.com | Inaugural address, 3/4/1933 | Los Gatos, CA 95032 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Weak event listener
An important distinction here - and one I think Bill and Brendan and others have gotten at some, and I've been trying to get at - is that weak references (and similar concepts, like weak maps and weak event listeners) unfortunately encompass a set of different problems and end up being used to solve some (or all) of them in different contexts. Resource management in the traditional 'memory and handles' sense is one of these contexts. History has, at this point, pretty much proven that you don't need a garbage collector to manage resources, but it has also pretty much proven that having one really helps. JS's garbage collector is a real win for ease of use (and safety, as Bill points out) in this area, but in practice JS rarely actually manipulates raw memory or handles to the extent that weak references are sorely needed. In cases where WRs are sorely needed, as well, the payoff is often significant enough to justify just going through and manually filling your code with calls to .dispose(). I've certainly done it dozens of times, and with enough discipline and process even big teams with junior programmers can manage it. The context that motivates me to beg and plead for WRs, though, is a different one: Architecture and 'state management', so to speak, where the liveness of an object has real, semantic meaning beyond whether the memory that holds it has been freed and whether the object is reachable. The example I gave of an application with 'modes' is one of the best examples of this I've run into in my career, because it was a huge problem that kept tripping us up as we maintained and extended the application - being able to say at any point whether a mode needed to be alive, and whether its associated resources and event listeners needed to be alive, was a really big challenge. In some situations we solved this with explicit disposal, but in other situations we *absolutely* needed Weak References to keep things sane, and going through and manually breaking cycles and removing event listeners and nulling parent references simply would not have been scalable. Even our best programmers wouldn't have been able to do it consistently. A core part of the problem here is that the distinction between an 'important' reference - one that must keep an object alive - and an 'incidental' reference, that only need exist as long as it target does - is really hard (for me, at least) to convey through design/comments and enforce manually with code. Having the aid of the type system and the runtime here is a huge boon. This is why the 'build your own malloc'/'build your own collector'/'do manual refcounting' solutions feel like a poor choice to me. Those solutions do a great job of solving resource management problems, because you can apply the cold unfeeling gaze of computer science to your software and eventually become confident that you will not have any resource management problems. The huge number of developers out there who intrinsically trust the garbage collector is great evidence of this. But when it comes to solving state/lifetime management problems, and being able to easily write code that you feel confident about in those contexts, solutions like manual refcounting or writing your own collector feel really inadequate. I've never come across a codebase that leaned upon solutions like that where you could feel true confidence; I've personally run into addref/release bugs in battle-tested codebases like Python and I've probably introduced my own more than a few times. I hope this makes it clearer why I want WeakRefs in particular, and perhaps it makes it easier to understand what an alternative solution might look like. Maybe the alternative solution is sugar for doing light-weight scoped addref/release, like Python's 'with' statement, or some other simple mechanism where people can at least confidently build their own solutions with the aid of the runtime, I'm not really sure. There are certainly vast millions of lines of C++ out there more or less leaning on such constructs, and those apps seem to work! On Tue, Apr 2, 2013 at 9:26 PM, Bill Frantz fra...@pwpconsult.com wrote: On 4/1/13 at 5:40 AM, sa...@ccs.neu.edu (Sam Tobin-Hochstadt) wrote: Using `.dispose()` is manual management of the allocation and deallocation of object. Manual memory management is fundamentally non-modular -- you can't encapsulate it in a library, and it requires describing memory management behavior in all your function specifications, the way that C libraries do. It's certainly possible to write large, complex apps in C. But that's not evidence that we should bring those practices to JS. There are a bunch of different reasons for wanting to dispose an object in memory. With the malloc/free system from C, you usually dispose objects to recover their backing memory for future use. The C version is not memory safe. If you are paying for the memory, you may be willing to break things to be able to stop
