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 wrote:
>
>
>
> Original message
> Subject:RE: RegExp Flags
> From:Allen Wirfs-Brock
> To:zenpars...@gmail.com
> Cc:
>
>
> It's supposed to be
Original message
Subject:RE: RegExp Flags
From:Allen Wirfs-Brock
To:zenpars...@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 ma
I think SM behavior is right to the spec.
According to 7.8.5,
> the error must be treated as an early error (Clause 16)
And early error should be reported before evaluation of the Program
(section 16)
> An early error is an error that can be detected and reported prior to the
> evaluation of a
SM and v8 exhibit different behavior when evaluating the following:
false ? /abc/ii : 0;
In v8, no syntax error is thrown, presumably because regular expression
flags are only validated when a RegExp object is created. In SM, a syntax
error is thrown because flag validation is performed by the s
On Sun, Mar 31, 2013 at 1:42 PM, Kevin Gadd 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 pr
Hi Rick, thanks for the clarifications. With the example as written, no
later uses of x (even inside a direct eval or closure that captures x
and might be called after the gc()!) then I agree with Mark -- should
not must.
/be
Hudson, Rick wrote:
Didn’t mean to imply that one is required to
Didn't mean to imply that one is required to use an optimization. I just wanted
to make it clear that one could.
-Rick
From: Oliver Hunt [mailto:oli...@apple.com]
Sent: Monday, April 01, 2013 6:18 PM
To: Hudson, Rick
Cc: Brendan Eich; Marius Gundersen; es-discuss discussion
Subject: Re:
On Apr 1, 2013, at 3:12 PM, "Hudson, Rick" wrote:
> If the compiler can prove x does not escape the block and it is not used
> again then it is dead and the compiler is free to reuse the stack slot
> holding the last reference.
>
> So I am arguing that x = null; is not required to kill x.
>
On Mon, Apr 1, 2013 at 3:12 PM, Hudson, Rick wrote:
> If the compiler can prove x does not escape the block and it is not used
> again then it is dead and the compiler is free to reuse the stack slot
> holding the last reference.
>
> So I am arguing that x = null; is not required to kill x.
>
> I
If the compiler can prove x does not escape the block and it is not used again
then it is dead and the compiler is free to reuse the stack slot holding the
last reference.
So I am arguing that x = null; is not required to kill x.
If we agree on that then I think we agree that someWeakRef.get();
On Mon, Apr 1, 2013 at 2:56 PM, Brendan Eich wrote:
> Hudson, Rick wrote:
>
>>
>> This brings up another interesting point. Do WeakRefs change a compiler’s
>> liveness analysis?
>>
>>
> Yes, of course.
>
>
> This could complicate some apparently useful optimizations.
>>
>> {
>>
>> var x = new So
Hudson, Rick wrote:
This brings up another interesting point. Do WeakRefs change a
compiler’s liveness analysis?
Yes, of course.
This could complicate some apparently useful optimizations.
{
var x = new Something();
someWeakRef.set(x);
// Is x dead? (yes) Is x required to contribute t
In that case it would be alive unless you destroyed the local variable 'x',
but in some environments the compiler is free to treat it as dead. I
believe in .NET the variable 'x' is only alive up until its last reference,
so the variable would become dead immediately after the construction of the
we
This brings up another interesting point. Do WeakRefs change a compiler's
liveness analysis? This could complicate some apparently useful optimizations.
{
var x = new Something();
someWeakRef.set(x);
// Is x dead? (yes) Is x required to contribute to the root set? (I hope
not.)
g
Marius Gundersen wrote:
This is why I suggested, in the other thread, a system for weak event
listeners. This would not be a problem if the only allowed argument to
a weak reference is a function. An iterable weak set of functions
would not have this problem, would solve the suggested usecases
> There are numerous problems with weak references and primitives, mostly
revolving around the ability to regenerate a primitive, e.g.
> The issue about non-object WeakMap keys was about semantics only, not
implementation safety bugs. If I can put "42" in a WeakMap, it can never be
removed, since I
Marius Gundersen wrote:
This seems to be more a problem with the garbage collector than with
weak references. If I understood it correctly, any double value can
look like a pointer,
No, that's not the issue in this (sub-)thread. Oliver was just
recollecting thoughts about a position he took i
There are numerous problems with weak references and primitives, mostly
revolving around the ability to regenerate a primitive, e.g.
someWeakRef.set("foo")
gc()
var something = "foo"
someWeakRef.get() // null or "foo"?
vs.
someWeakRef.set("foo")
var something = "foo"
This seems to be more a problem with the garbage collector than with weak
references. If I understood it correctly, any double value can look like a
pointer, and the garbage collector will check what it is pointing at. To me
this seems like a source for memory leaks. This problem exists even withou
Right.
David, I thought I had you convinced at:
http://www.mail-archive.com/es-discuss@mozilla.org/msg21480.html
/be
Sam Tobin-Hochstadt wrote:
On Mon, Apr 1, 2013 at 8:34 AM, David Bruant wrote:
Le 27/03/2013 00:22, Kevin Gadd a écrit :
OK, it seems like Weak References are now being dis
On 04/01/2013 09:41 AM, Brandon Benvie wrote:
> That is, the error that will be thrown from Object.preventExtensions is only
> specified as a TypeError; different engines can (and often do) have different
> error messages, and different localizations will also have different
> messages. This is
On 3/31/2013 4:38 PM, David Bruant wrote:
Le 31/03/2013 21:17, Jeff Walden a écrit :
On 03/31/2013 11:02 AM, David Bruant wrote:
From the developer perspective, this doesn't really add anything
since it's already possible to throw from within the trap (and
that's probably more explicit and cl
Le 01/04/2013 17:22, Tom Van Cutsem a écrit :
Hi David,
The messages you cite discuss the return value of the oddball
"unknownPrivateSymbol" trap.
I assumed the comments applied to true/false protocols in general, but
I'm interested if there is disagreement on that point.
For the preventExte
Hi David,
The messages you cite discuss the return value of the oddball
"unknownPrivateSymbol" trap.
For the preventExtensions trap I see no reason to be inconsistent with the
"set" and "defineProperty" traps.
Also, Reflect.preventExtensions (and Reflect.set, Reflect.defineProperty)
will make th
On Mon, Apr 1, 2013 at 8:34 AM, David Bruant wrote:
> Le 27/03/2013 00:22, Kevin Gadd a écrit :
>
>> OK, it seems like Weak References are now being discussed without the
>> context of previous discussions of weak references, which is a little
>> annoying. Non-contrived real-world use cases that r
Le 27/03/2013 00:22, Kevin Gadd a écrit :
OK, it seems like Weak References are now being discussed without the
context of previous discussions of weak references, which is a little
annoying. Non-contrived real-world use cases that require Weak
References (or a primitive with similar capabiliti
26 matches
Mail list logo
