Re: Question about [[Enumerate]] and property decision timing

Thank you so much. On Mon, Aug 10, 2015 at 8:18 AM, Allen Wirfs-Brock wrote: > > On Aug 9, 2015, at 2:34 PM, Yusuke SUZUKI wrote: > > Hi forks, > > Recently, we implemented Reflect.enumerate in WebKit JSC. > At that time, the question is raised "When are the enumer

Question about [[Enumerate]] and property decision timing

dded properties are not guaranteed to be processed in the active enumeration."? And is the creation of the iterator by calling [[Enumerate]] included in "active enumeration"? [1]: https://bugs.webkit.org/show_bug.cgi?id=147677 Best regards, Yusuke Suzuki _

Re: PropertyDefinitionEvaluation for static MethodDefinition

On Wed, Jul 22, 2015 at 10:06 AM, Allen Wirfs-Brock wrote: > > On Jul 22, 2015, at 9:38 AM, Yusuke SUZUKI wrote: > > Hi forks, > > Seeing the ES6 specification, I've found that PropertyDefinitionEvaluation > for static MethodDefinition is missing. > > For example

PropertyDefinitionEvaluation for static MethodDefinition

t]] (functionKind becomes "Method"). Best Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Template site objects and WeakMap

> > It turns out the spec is fine < > https://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap.prototype.set> > step 5 says > > If Type > > (*key*) is not Object, throw a *TypeError* exception. > >

Re: Template site objects and WeakMap

On Thu, Jun 18, 2015 at 1:18 AM, Mark S. Miller wrote: > [+Allen] > > Can registered Symbols be used as keys in WeakMaps? If so, we have a fatal > unauthorized communications channel that we need to fix in the spec asap! > > > Why do registered Symbols appear? (oops, maybe I missed some context..

Re: Template site objects and WeakMap

application in other memory safe languages including those > yet to be invented. You have added another tool to our toolbox. You have > deepened our understanding of what is possible. > > > > > On Tue, Jun 16, 2015 at 10:45 PM, Yusuke SUZUKI > wrote: > >> On Wed, Ju

Re: Template site objects and WeakMap

On Wed, Jun 17, 2015 at 2:29 PM, Yusuke SUZUKI wrote: > Thanks. And sorry for the late reply. > > On Wed, Jun 17, 2015 at 11:31 AM, Mark S. Miller > wrote: > >> Hi Yusuke, I am not sure I understood your message. Could you show some >> example code that would observ

Re: Template site objects and WeakMap

] is implemented as WeakMap. var siteObject = tag`hello`; map.set(siteObject, true); // To avoid the previously described situation, WeakMap specially handles the siteObject. It is now refereneced strongly by the WeakMap. gc(); var siteObject = tag`hello`; m

Template site objects and WeakMap

d please point it if I misunderstood) Best Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: String.prototype.search has a breaking change from ES5

Thank you. I've filed it here[1] [1]: https://bugs.ecmascript.org/show_bug.cgi?id=4327 Best Regards, Yusuke Suzuki On Mon, Apr 20, 2015 at 3:45 AM, Allen Wirfs-Brock wrote: > > On Apr 18, 2015, at 12:46 PM, Yusuke SUZUKI wrote: > > Hi forks, > > Seeing ES6 String.prot

String.prototype.search has a breaking change from ES5

n to the 21.1.3.15 step 3 (because null is not undefined). And then reaching step 3.a, Let searcher be GetMethod(regexp, @@search). Then TypeError is thrown by GetV's ToObject. Is it intentional behavior? Best Regards, Yusuke Suzuki ___ es-discuss

Re: Performance of iterator .next() as specified

ltin JS objects. But if possible, I think it is preferable to change the spec to improve performance of iteration for user provided iterators. [1]: https://bugs.webkit.org/show_bug.cgi?id=141351 Best regards, Yusuke Suzuki On Sun, Feb 15, 2015 at 8:07 PM, Katelyn Gadd wrote: > I'

Re: Re: is PropertyName updated?

Oops, sorry, I've missed PropertyName : *BindingElement*. So when using computed property name as PropertyName, shorthanded style cannot be used. Thank you ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

is PropertyName updated?

Hi forks. Seeing the latest rev 27 draft, PropertyName is defined in the 12.2.5, PropertyName[Yield,GeneratorParameter] : LiteralPropertyName [+GeneratorParameter] ComputedPropertyName [~GeneratorParameter] ComputedPropertyName[?Yield] And BindingProperty in the ObjectBindingPattern

Re: PutValue – correctly implemented by engines?

JavaScriptCore implements it correctly. --- Regards, Yusuke Suzuki On Sat, Nov 23, 2013 at 6:24 PM, Axel Rauschmayer wrote: > (Hopefully not too off-topic for es-discuss.) > > Are JavaScript engines correctly implementing the operation PutValue [1]? > > I’d expect the followin

Re: Are Promises and Microtasks introduced into ES6?

On Fri, Oct 4, 2013 at 3:39 AM, Brendan Eich wrote: > Yusuke SUZUKI wrote: > >> Make sense. So microtasks won't be introduced yet, but Promises and >> asynchronous execution semantics (enough for Promises) are introduced into >> ES6. Is it correct? >> > &g

Re: Are Promises and Microtasks introduced into ES6?

Thu, Oct 3, 2013 at 11:43 PM, Alex Russell wrote: > > Only that a suitable hook is needed that embedders can implement. Luckily > that's simple WRT existing semantics (we are oblivious to future turns at > the language level) and doesn't demand that we import the event loop itself > into the langu

Are Promises and Microtasks introduced into ES6?

tasks and the event loop. But I can't find details of the event loop consensus. Is there any consensus about event loop abstraction in ES6? Thanks, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

"\08" is ill formed in ECMA262

s ill formed StringLiteral. But engines in the wild, V8, SpiderMonkey, JSC accepts this form and recognize it as "\x008". To bridege the gap, I think it is better to introduce this form to the spec officially. --- Regards, Yusuke Suzuki ___

Re: Why is concise body for method definition dropped?

right > call, still. Of course, the expression body "x+x[symbol]:42" does have a later syntax > error, on the ":" -- but that is confusing. > Also it could be with computed property names combined with concise > methods t

Why is concise body for method definition dropped?

12-05-23 But I couldn't find why it is dropped. Probably I missed the discussion. So I'd appreciate it if you would inform me about it. --- Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: A new ES6 spec. draft has been posted

, 1253, 1117 > > Allen > > _______ > es-discuss mailing list > 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: RegExp Flags

t; 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.org > https://mail.moz

Re: RegExp Flags

seems to lean toward the v8 interpretation. Thoughts? > > { Kevin } > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > > -- Regards, Yusuke Suzuki _

Re: Identifying ECMAScript identifiers

rg < ecmascr...@lindenbergsoftware.com> wrote: > > On Mar 8, 2013, at 2:35 , Yusuke SUZUKI wrote: > > > In Esprima and Acorn, because of performance issue, their identifier > identification functions require a code point as number, not string[2][3]. > > So I suggest accepting a code point

Re: Identifying ECMAScript identifiers

;> 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 > > -- Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: GetValue of DataView doesn't guarantee target in range

; Allen > > > > > On Jan 3, 2013, at 5:49 AM, Yusuke Suzuki wrote: > > Hello all, > > According to rev13 draft section 15.13.7.4 step 4, > > 4. If totalOffset ≥ byteLength, throw a RangeError exception. > > > But this doesn't guarantee target in

GetValue of DataView doesn't guarantee target in range

lling GetValue(0, false, Uint32), and then totalOffset is 0 and byteLength is 1, so a RangeError exception isn't thrown. But because Uint32 requires 4 bytes, this access is out of range. I think we should check (totalOffset + ElementSize) > byteLength, right? -- Regards,

Re: Number.isNaN

. So "Number.isNaN(Object(NaN))" will return "true". > > Luke > > [0] http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts > > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mai

Re: [[Call]] pass through result completion to callee

t normal completions yield undefined and > not empty. > > Letting Return completions escape from functions was needed when we were > considering supporting block lambdas but isn't need now. > > Allen > > > > > > On Dec 3, 2012, at 11:23 PM, Yusuke Suzuki wrote: >

[[Call]] pass through result completion to callee

value = test(); // value is empty... -- Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: How to count the number of symbols in a string?

gt; > poo.getCodePoints() > [ 0x1F4A9 ] > > poo.getCodePoints().length > 1 > > Has anything like this been considered/discussed here yet? > _______ > es-discuss mailing list > 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

Leap second clarification

blog post http://uupaa.hatenablog.com/entry/2012/07/02/113201 ) I think it is better to describe it as NOTE or standardize this behavior. [1] Thu Dec 31 23:59:60 GMT 1998 [2] 2012-07-01T08:59:60Z -- Regards, Yusuke Suzuki ___ es-discuss mailing li

Re: Mootools and String.prototype.contains

Hello, I've found the issue in mootools-core [1]. [1] https://github.com/mootools/mootools-core/issues/2402 Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

> > Mark S. Miller wrote: Security aside, given maximin >> >> class Foo >> >> what do you suggest Foo.prototype be? >> > I suggest adding @@toStringTag:"Foo" property to Foo.prototype when `class Foo` is executed. ___ es-discuss mailing list es-disc

Re: Must built-in prototypes also be valid instances? (Was: Why DataView.prototype object's [[Class]] is "Object"?)

o new style prototype, constructor of them to new style like a Map constructor, and Class check(such as [[Class]] is "DataView") to internal property check(such as object.[[HasProperty]]("DataView")) ? Probably because at least ArrayBuffer has no internal specialized method, I

Why DataView.prototype object's [[Class]] is "Object"?

I've pass through ES6 rev10 draft and found that DataView.prototype object [[Class]] isn't "DataView". Why is it? I think allowing DataView(null, 0, 0) and using it as DataView.prototype is better. -- Regards, Yusuke Suzuki ___ es-

Re: Why TypeArray instead of TypedArray?

Ah, thanks. I've got it :) On Sun, Sep 30, 2012 at 4:36 AM, Rick Waldron wrote: > > > On Sat, Sep 29, 2012 at 12:32 PM, Yusuke Suzuki wrote: > >> Hello all, >> >> In rev10 draft, TypeArray is described. >> But why TypeArray instead of TypedArray? I

Why TypeArray instead of TypedArray?

tring, Array, Object, Function]. Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: a new ES6 spec. draft dis available

Thanks, I've filed them. https://bugs.ecmascript.org/show_bug.cgi?id=664 https://bugs.ecmascript.org/show_bug.cgi?id=665 https://bugs.ecmascript.org/show_bug.cgi?id=666 Regards, Yusuke Suzuki On Fri, Sep 28, 2012 at 10:05 AM, Rick Waldron wrote: > > > On Thu, Sep 27, 2012 at 3

Re: a new ES6 spec. draft dis available

And I've found typo in Map implementation. 15.14.1.1 MapInitialization, step 6, `internal method` should be `internal property` Regards, Yusuke Suzuki On Fri, Sep 28, 2012 at 5:15 AM, Allen Wirfs-Brock wrote: > As usual, at > http://wiki.ecmascript.org/doku.php?id=harmony:specifica

Re: a new ES6 spec. draft dis available

Great! ES6 rev10 draft is very interesting, so I'm now reading this changes... And I've found typo in draft section 11.1.10, 11.1 StaticSemantics, , `IsValidSimpleAssignmentTarge` should be `IsValidSimpleAssignmentTarget` Regards, Yusuke Suzuki On Fri, Sep 28, 2012 at 5:15 AM, Allen W

Re: Array comprehension syntax

Related issues are here. https://bugzilla.mozilla.org/show_bug.cgi?id=791343 https://bugzilla.mozilla.org/show_bug.cgi?id=791348 https://bugzilla.mozilla.org/show_bug.cgi?id=791352 Regards, Yusuke Suzuki On Sun, Sep 23, 2012 at 1:24 AM, Brendan Eich wrote: > Jason Orendorff wrote: >

Re: Possible inconsistencies in the 5th edition

Hello Sukyoung, 3) Arguments Object It is filed at https://bugs.ecmascript.org/show_bug.cgi?id=440 ;) https://mail.mozilla.org/pipermail/es-discuss/2012-July/023888.html Regards, Yusuke Suzuki On Thu, Sep 13, 2012 at 8:47 PM, Sukyoung Ryu wrote: > Hi, > > We found possible inconsist

Re: Annex A of 5th Edition

) On Thu, Aug 30, 2012 at 4:57 PM, Yusuke Suzuki wrote: > Hello Joseph > > A.3 >> UnaryExpression: >> As written, it is suggested that the following is legal (which seems >> illegal): >> 5; >> ++typeof++5; > > > I think it shoud raise Referenc

Re: Annex A of 5th Edition

gnment Operators http://people.mozilla.org/~jorendorff/es6-draft.html#sec-11.13 Static Semantics: Early Errors Because example expression isn't Identifier, ArrayPattern or ObjectPattern, so early Syntax Error should be raised. If I missed something, please point out. Regards, Yusuke Suzuki On Thu, Aug 3

Re: Creation of the `arguments` object

containing the same sequence of characters as in > the Identifier. Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: base value of super reference doesn't indicate prototype object of the super class

ng an alternative SMTP server solved this, so I use it. Thanks for your advice. Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Base value of super reference doesn't indicates prototype object of super class

limit exceeded error is thrown. So I suggest that using baseValue.[[Prototype]] for base of super reference. If I missed something, I would appreciate it if you would inform me. Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozill

base value of super reference doesn't indicate prototype object of the super class

;) is executed recursively and max recursion limit exceeded error is thrown. So I suggest that using baseValue.[[Prototype]] for base of super reference. If I missed something, I would appreciate it if you would inform me. Regards, Yusuke Suzuki ___ es-d

base value of super reference indicates the prototype of the current derived class

;) is executed recursively and max recursion limit exceeded error is thrown. So I suggest that using baseValue.[[Prototype]] for base of super reference. If I missed something, I would appreciate it if you would inform me. Regards, Yusuke Suzuki ___ es-d

base value of super reference indicates the prototype object of the current derived class

o es-discuss(without reply) is basically blocked... What should I do to pass the filter? Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

base value of super reference is prototype object of the current class

is thrown. So I suggest that using baseValue.[[Prototype]] for base of super reference. If I missed something, I would appreciate it if you would inform me. P.S. This is 4th mail I sent because 3 mails are blocked 12 hours ago. Sorry if 3 duplicate mails are delivered after this

base value of super reference is prototype object of derived class

rown. So I suggest that using baseValue.[[Prototype]] for base of super reference. If I missed something, I would appreciate it if you would inform me. P.S. This is 3rd mail I sent because 2 mails are blocked 12 hours ago. Sorry if 2 duplicate mails are delivered after this

base value of super reference doesn't indicate prototype object of the super class

from my gmail address (utatane@gmail.com <mailto:utatane@gmail.com>), but all mails were blocked (I tried to send it 10 times), so I cannot send it to es-discuss from gmail. I send this mail from an alternative smtp server. I would like to know how to pass the filter of es

Re: Is Global Environment Regard one of the Object Environment Record?

On Fri, Jun 29, 2012 at 2:46 AM, Allen Wirfs-Brock wrote: > The specification of the Global Env. Record is obviously incomplete in the > current draft and there are some global scope design issues that remain to > be resolved. Hopefully, at the July TC39 meeting. > I'm looking forward to seeing

Is Global Environment Regard one of the Object Environment Record?

rBinding is not defined in the current draft. Is it spec issue? Or only not defined yet? Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Some Array methods don't consider array holes and length

e any other cases like these that you have identified? As long as I know, all cases have been already reported. For example, old Array.from spec had the same problem. But in the latest draft, [[Put]] 'length' is inserted, so this issue doesn't occur. https://gist.githu

Some Array methods don't consider array holes and length

s Array. P.S. Sorry for duplicate mails, they're reflected lately, so I thought they are filtered. Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Arguments instantiation by destructuring assignment has no effect on current draft

ion with it, or delaying internal method override phase of ao. Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Arguments instantiation by destructuring assignment has no effect on June 15 draft

I suggest creating JS Array from argumentsList and performing Binding Initialisation with it, or delaying internal method override phase of ao. Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

[[Writable]] is specified in defining getter / setter

esc, [[Writable]] property is specified. But because they are getter and setter, we should not specify [[Writable]] property, is it right? If it is a issue, I'll file this to bugs.ecmascript.org. Regards, Yusuke Suzuki ___ es-discuss mailing list es

Re: ArrayCreate should use the default [[DefineOwnProperty]] internal method instead of Array's

Thanks for your reply. I filed this issue to bugs.ecmascript.org https://bugs.ecmascript.org/show_bug.cgi?id=415 Regards, Yusuke Suzuki On Sun, Jun 24, 2012 at 11:59 PM, Allen Wirfs-Brock wrote: > this also should be reported to bugs.ecmascript.org > > This is a very good catch.

Re: Arguments instantiation has no effect on June 15 draft

Thanks for your clarification! I filed this issue to bugs.ecmascript.org https://bugs.ecmascript.org/show_bug.cgi?id=414 Regards, Yusuke Suzuki On Sun, Jun 24, 2012 at 11:50 PM, Allen Wirfs-Brock wrote: > Yes, please file a bug report at bugs.ecmascript.org > > As you suggest, the

ArrayCreate should use the default [[DefineOwnProperty]] internal method instead of Array's

hod (8.12.9) on A with arguments "length", Property Desciptor {[[Value]]: length, [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: false}, and false. Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Arguments instantiation has no effect on June 15 draft

with it, or delaying internal method override phase of ao. Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: [[Get]] and GetValue can return Reference Type

Thanks, I filed this issue at https://bugs.ecmascript.org/show_bug.cgi?id=387 Regards, Yusuke Suzuki On Thu, Jun 14, 2012 at 12:47 AM, Allen Wirfs-Brock wrote: > could you file this as a bug at bugs.ecmascript.org > > I want to make sure it isn't forgotten if nobody else respo

[[Get]] and GetValue can return Reference Type

don't consider that [[Call]] result is Reference and this feature makes big performance-regression, personally I think 3 is better. Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Duplicate parameter names in non-strict function cause assertion failure in InitializeBinding

Thanks for your reply. So I've filed the issue in https://bugs.ecmascript.org/show_bug.cgi?id=368 Regards, Yusuke Suzuki On Mon, May 28, 2012 at 1:54 PM, Allen Wirfs-Brock wrote: > Yes, that is an issue. There are some others relating to formal parameter > initialization. Basica

Duplicate parameter names in non-strict function cause assertion failure in InitializeBinding

gt; and undefined as the arguments. If I missed something, please point out. Regards, Yusuke Suzuki ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Clarification of [[Prototype]] of Intl.Collator.prototype

Thanks for your quick reply! Later, I'll file these test262 bugs to bugs.ecmascript.org. PS. Sorry, I forgot to add es-discuss to CC. Regards, Yusuke Suzuki On Fri, May 25, 2012 at 2:51 AM, Norbert Lindenberg < ecmascr...@norbertlindenberg.com> wrote: > Suzuki-san, > > Tha

Clarification of [[Prototype]] of Intl.Collator.prototype

issue to bugs.ecmascript.org. So, to make it clear, I suggest adding description about [[Prototype]] of Intl.Collator.protoype like ES5 Array.prototype in section 15.4.4, like The value of the [[Prototype]] internal property of the Intl.Collator > prototype object is the standard built-in O

Re: RegExp source property?

Previously, I reported this issue to JSC, sent patch and accepted :-) https://bugs.webkit.org/show_bug.cgi?id=71572 On Fri, Mar 2, 2012 at 3:03 AM, Erik Arvidsson wrote: > I should have read 15.10.4.1 as well. It clearly states that the > source property needs to be escaped. > > This means that a

Re: `ExponentPart` after `HexIntegerLiteral`

Hello, 0xFFe2 is valid HexIntegerLiteral, because 'e' and '2' is one of the hex digit. So I think it is OK. 0xFFe2 // 65506 0xFFe3 // 65507 Thanks. On Sat, Feb 25, 2012 at 10:40 PM, Mathias Bynens wrote: > The spec grammar for `HexIntegerLiteral` is as follows: > http://es5.github.com/x7.html

Re: new ECMA262 5.1 engine

2011 at 6:03 AM, Lasse Reichstein < reichsteinatw...@gmail.com> wrote: > On Sat, Oct 22, 2011 at 5:30 PM, Yusuke Suzuki wrote: > >> BTW, I thought that the example in >> http://wiki.ecmascript.org/doku.php?id=strawman:match_web_reality_spec >> exec(/(?=a)+/, "

Re: new ECMA262 5.1 engine

011 at 5:04 AM, Allen Wirfs-Brock wrote: > > On Oct 20, 2011, at 10:17 PM, Yusuke Suzuki wrote: > > > And, I tried to implement RegExp.prototype.compile, but ES5 and ES3 > not defined its standard behavior and I thought compile method is > changing RegExp#source / #global /

Re: new ECMA262 5.1 engine

ascript.org/doku.php?id=test262:command If you find bugs, I would appreciate it if you would report it. Thanks. On Fri, Oct 21, 2011 at 3:54 AM, Juriy Zaytsev wrote: > How does it fair on test262? http://test262.ecmascript.org/ > -- > kangax > > On Wed, Oct 19, 2011 at 6:26 AM, Yusuke

new ECMA262 5.1 engine

Hello. I wrote new ECMA262 5.1 full support engine "iv / lv5" in C++. This is highly inspired from JSC, V8 and SpiderMonkey. (especially JSC) https://github.com/Constellation/iv This aims at most precise engine to ECMA262 5.1 specification. (like the great engine,) I read ECMA262 and wanted pre

Re: Array.prototype.concat result length (ES5.1)

I also reported it to es5-discuss https://mail.mozilla.org/pipermail/es5-discuss/2010-December/003851.html, and got " This is a bug in the spec." I think [[Put]]("length", {[[Value]]: n}, true) step should be inserted to the end of this(like, pop, push method), is it correct? On Thu, Jul 14, 2011