See comments inline. 2012/9/10 Norbert Lindenberg <[email protected]>
> Hi Nebojša, > > Thanks for the information - this is really valuable data! > > My comments are embedded below. Some of them are based on my own two > partial implementations: > > 1) The prototype/reference implementation that I've been maintaining for > quite a while parallel to the spec prose, and which is loaded as a normal > JavaScript library. > > 2) A port thereof into the new environment for self-hosted JavaScript > within SpiderMonkey. > > The first one doesn't connect to a full internationalization library at > all, and the connection for the second is still under construction, so some > tests fail for this reason. In addition, I have a failure because > SpiderMonkey bug 598996 prevents me from making the length of the array > returned by supportedLocalesOf non-writable. Other failures are a subset of > the ones you're discussing. > > Thanks, > Norbert > > > On Sep 7, 2012, at 14:31 , Nebojša Ćirić wrote: > > > I am making my implementation conform to the spec/tests as much as > possible. It's currently passing (P) 106, failing (F) 6 and expecting (EF) > 25 to fail. > > What's the difference between "failing" and "expecting to fail"? > It's just annotation for myself, to tell me that I expect test x.y.z.js to fail because of external issue (e.g. ICU bug, change in spec, something was not implemented). The failing tests are either my bugs, or I didn't investigate them deeper. You can treat all (FE and F) of them as failing tests. > > > 3/25 EF are ICU problems, or ISO vs CLDR data differences. Bugs > submitted, waiting for update. > > Can you provide bug IDs? > # ICU bug http://bugs.icu-project.org/trac/ticket/9547 'data/test/suite/intl402/ch11/11.3/11.3.2_TRP.js': 'FAIL', # ICU bug http://bugs.icu-project.org/trac/ticket/9265 'data/test/suite/intl402/ch09/9.2/9.2.5_11_g_ii_2.js': 'FAIL' I don't have actual bug ID for ISO - CLDR issue (the fraction digits for currencies). I'll talk to Mark about it. > > 8/25 EF are from not implementing the i18n support for localeCompare and > similar functions (yet). > > Looking forward to more info on this once you get there. > > As soon as we ratify the spec :). > > 6/25 EF are from not being able to detect if the function was called as > constructor. V8 has a way of detecting that in C++ but there is no way to > do it in JavaScript alone - which I need. Any pointers? > > Do you mean detecting in order to throw a TypeError when someone uses a > non-constructor with new, or do you mean for purposes of differing behavior > within an actual constructor? I see problems only with the first one in my > prototype library. In the self-hosted environment in SpiderMonkey, there's > no problem at all, because self-hosted functions by default are not > constructors, and I have to call a special intrinsic %_MakeConstructible to > register a function as a constructor. > Yes, it's related to the TypeError requirement. The way I did it was like this: JS code: v8Intl { ... function internalFormat(formatter, x) { ... return native function NativeJSFormatter(formatter, Number(x)); } ... } NativeJSFormatter is V8 C++ method and it can detect if it was called as constructor or not. But by the time I call it it's already too late. It's interesting that requirement like this is in ES spec, but they don't provide a way to check/enforce it. > I suspect that other ECMAScript functions implemented in JavaScript in V8 > don't meet this ES5 clause 15 requirement either. > > > 6/25 EF are from not being able to delete prototype property from a > function. Any pointers? > > This is a problem in SpiderMonkey as well: > https://bugzilla.mozilla.org/show_bug.cgi?id=784300 > > As above, I suspect that other ECMAScript functions implemented in > JavaScript in V8 don't meet this ES5 clause 15 requirement either. > > > 2/25 EF are from hour12 field being requested from resolvedOptions() in > absence of hour field. Norbert said he would update this requirement in > spec/tests. > > The spec change is in the September 4 draft, and I just updated the tests > as well. > Thanks, both tests are passing now. > > 1/6 F is from failing on de-DD locale test. I think we should remove > this test case (does spec say anything about deprecated locales support?). > > 6.2.3 CanonicalizeLanguageTag refers to RFC 5646 section 4.5, and step 3 > of that section says "Subtags are replaced by their 'Preferred-Value', if > there is one." The entry for region DD in the IANA Language Subtag Registry > has Preferred-Value DE. > http://tools.ietf.org/html/rfc5646#section-4.5 > http://www.iana.org/assignments/language-subtag-registry/ > > I could file an ICU bug for this one. I'll take a look. > > 2/6 F are from 1x.3_a.js tests, where 0 property of Array.prototype is > tainted. I don't know how to guard against this. Any pointers? > > You mean 9.2.1_2.js and 9.2.6_2.js? The spec here refers to the List > specification type, and I implemented List objects using Array methods that > you have to grab before anybody can replace them. > Methods are fine, but what do you do with '0' property. You can't grab all indices in range to protect override. > > > 3/6 F are from invoking Constructor.prototype.format/compare directly. > I'll have to find a way to deal with these 3. > > What's the problem you're seeing? > > I have to check why: Object.defineProperty(Intl.Collator, 'prototype', new Intl.Collator()) doesn't provide expected result for me. Debugging time. -- Nebojša Ćirić
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
