Re: [v8-users] Serialization Side Effects

[Adam Klein]

On Tue, Aug 4, 2020 at 1:32 PM Adrienne Walker  wrote:

> On Thu, Jul 30, 2020 at 9:57 PM Ben Noordhuis  wrote:
>
>> On Thu, Jul 30, 2020 at 8:21 PM Adrienne Walker 
>> wrote:
>> > Is there any way to know from a v8::Value whether serializing it will
>> have side effects (at all or on particular properties)?
>>
>> Apart from checking whether it's primitive (v->IsNullOrUndefined() ||
>> v->IsBoolean() || ...), I believe the answer is 'no' . Non-primitive
>> values can have getters and getters execute arbitrary code.
>>
>> Checking for only simple properties recursively is an option but
>> probably not faster and you'll need to handle cycles and a ton of edge
>> cases (what if the property is a pending promise? what if it's a
>> WeakMap? etc.)
>>
>
> Can I use HasRealNamedProperty/GetRealNamedProperty to see if I can access
> those properties without side effects and then check if those values are
> primitive from there? I suspect that most indexeddb keys being provided
> here are primitive string values inside a single simple object, and so am I
> trying to figure out how to fast path this case.  Is there a way to tell if
> a property is one of these complicated edge cases that you mention?
>
>
>> The debugger has a "side-effect-free evaluate" mode but that operates
>> on functions, not values. You could use it to check getters for side
>> effects (and promises, and...) but the algorithm is conservative (can
>> report side effects when there are none) and runs in O(n) time
>> relative to the function's bytecode size.
>
>
> Given the potential performance issues there, this doesn't sound like a
> plausible approach.
>
> The only other thing we thought of was if there was some way to have some
> sort of observer as a part of serialization that could record the values
> without having to deserialize again to access.  I worry that this might be
> too invasive to v8's serialization though.
>

To the question of whether something might be "invasive to v8's
serialization", I think the history here is important: serialization used
to live in Blink, but was moved into V8 (by jbroman@, CCed) for performance
reasons. Given that the problem you're investigating is another performance
issue in serialization, making such an invasive change should at least be
on the table, I'd argue.

- Adam


> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/v8-users/CA%2B1_fV8rAhA8arck6C%2BXoQC%3DaMx1S_cARXGbymiG-%3DCHko3_5Q%40mail.gmail.com
> 
> .
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAEvLGcKNeUQi-Spsyv95vi64dmw%2BGk6DyVOzVQ2kMX64QLsumA%40mail.gmail.com.

[v8-users] Re: [blink-dev] Re: Intent to Ship: Add fractionalSecondDigits option to Intl.DateTimeFormat

[Adam Klein]

Thanks to the API owners for LGTMs. Due to the Chrome release pause,
though, I'd suggest that Frank work with Shu on the right next steps here
in V8; it's likely not appropriate to flip this flag until releases are
unpaused.

On Tue, Mar 24, 2020 at 10:01 AM Mike West  wrote:

> LGTM3.
>
> -mike
>
>
> On Tue, Mar 24, 2020 at 4:12 PM Chris Harrelson 
> wrote:
>
>> LGTM2
>>
>> On Tue, Mar 24, 2020 at 7:02 AM Daniel Bratell 
>> wrote:
>>
>>> Seems the automatic script failed to pick up this intent so it never
>>> ended up on the todo list for our weekly meetings. Sorry about that.
>>>
>>> Anyway, looking good. In stage3 if I understand things corrrectly which
>>> means that it has standards support, and with Mozilla's implementation
>>> there should be no major compatibility problems.
>>>
>>> LGTM1
>>>
>>> /Daniel
>>>
>>>
>>> On 2020-03-24 06:42, Frank Tang wrote:
>>>
>>> ping
>>>
>>> On Wed, Mar 18, 2020 at 3:05 PM Mounir Lamouri 
>>> wrote:
>>>
 non-owner LGTM based on the above. 2 out of the 3 ICU bugs were pointed
 by Mozilla in their bug tracker as a reason to not launch yet.

 -- Mounir

 On Wed, 18 Mar 2020 at 14:59, Frank Tang  wrote:

> It start from a user request and I put together this PR. Mozilla folks
> identified some bugs in the ICU library and we just fixed them and make it
> available recently. The PR is not merged because ECMA 402 will only merge
> this PR if one of the engine shipt it and since I draft the PR it will
> depend on this launch to unblock the merge.
>
> It was pending on the fix of the following 3 ICU bugs and they are now
> all fixed.
> https://unicode-org.atlassian.net/browse/ICU-20967
> https://unicode-org.atlassian.net/browse/ICU-20738 (assignee forget
> to mark it but will soon)
> https://unicode-org.atlassian.net/browse/ICU-20739
>
> These fix also make our v8 implementation pass some failed test in
> https://chromium-review.googlesource.com/c/chromium/src/+/2090002
> https://chromium-review.googlesource.com/c/v8/v8/+/2095394
>
> On Wed, Mar 18, 2020 at 12:32 PM Mounir Lamouri 
> wrote:
>
>> Mozilla seems to have this implemented but Nightly only so I think it
>> would be reasonable to have their position updated from "Public Support" 
>> to
>> "In Development". FWIW, it seems that Mozilla is keeping this in Nightly
>> because the spec wasn't stable but it was a while ago.
>>
>> I also think it would be reasonable to consider Web Developers to be
>> positive as this came from a user request
>>  that was initially on
>> Stack Overflow
>> 
>>  and
>> the same person said that solved their use case
>> .
>>
>> -- Mounir
>>
>> On Wed, 18 Mar 2020 at 11:56, Daniel Bratell 
>> wrote:
>>
>>> What is the current state of the spec change? It looks like the PR
>>> is still open and not much has happened since last autumn. Preferably 
>>> there
>>> should be an agreed upon spec before something is changes, or at the 
>>> very
>>> least, the spec change and the shipping should happen close to each 
>>> other.
>>>
>>> /Daniel
>>> On 2020-03-18 17:54, Frank Tang wrote:
>>>
>>> ping
>>>
>>> On Fri, Mar 13, 2020 at 12:50 PM Frank Tang 
>>> wrote:
>>>
 Contact emails ft...@chromium.org,js...@chromium.org Explainer
 http://shorturl.at/adiZ4 Spec
 https://github.com/tc39/ecma402/pull/347 TAG review No TAG review
 since the TC39 and ECMA402 will cover that. Summary Enhance the
 Intl.DateTimeFormat API by adding a “ fractionalSecondDigits” option to
 control the format of fractions of a second. Link to “Intent to
 Prototype” blink-dev discussion
 https://groups.google.com/a/chromium.org/forum/#!searchin/blink-dev/Intent$20to$20Implement$3A$20Add$20millisecondDigits$20option$20to$20Intl.DateTimeFormat%7Csort:date/blink-dev/WXd9nh03a1M/z7QeIMgrBgAJ
 Risks
 Interoperability and Compatibility low. *Firefox*: Public support (
 https://bugzilla.mozilla.org/show_bug.cgi?id=1568134) *Edge*: No
 public signals *Safari*: No public signals *Web developers*: No
 signals Ergonomics Part of the pre-existing ICU functionality w/o
 need of additional data. Activation Should be easy to use by using
 w/ pre-existing Intl.DateTimeFormat Security low
 Debuggability nothing special. Will this feature be supported on
 all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and
 Android WebView)? Yes Is this feature fully tested by
 web-platform-tests
 

[v8-users] Re: [blink-dev] Intent to Implement and Ship: Let all early errors be SyntaxErrors

[Adam Klein]

On Fri, Jun 21, 2019 at 12:09 AM Yoav Weiss  wrote:

>
>
> On Wed, Jun 19, 2019 at 9:07 PM Adam Klein  wrote:
>
>> Hi Yoav,
>>
>> We don't have existing metrics that would help here, and I honestly don't
>> even know what we would track for this specific issue (detecting that a
>> certain exception came from eval, for example, isn't something we currently
>> track).
>>
>> Bug reports are how we tend to track issues like this. And fwiw my
>> intuition matches Sathya & Ross's (that this is very unlikely to cause
>> problems in practice).
>>
>
> OK. Do you typically get those bug reports on Canary, Beta, or once the
> feature in question have hit stable?
> (This is more of a generic question: I don't think this particular feature
> should block on putting counters in place if this is how V8 typically
> rolls. I just want to better understand your workflow regarding
> deprecations and changes)
>

I don't think this has been tracked systematically (the number of bug
reports due to V8 web-exposed-API changes in the last couple years is
pretty small, probably ~5-10), but I'd say Stable is most common,
unfortunately.

Sathya has been working more actively in this area recently than I have,
and might have other thoughts.


>
>> On Mon, Jun 17, 2019 at 9:42 PM Yoav Weiss  wrote:
>>
>>> LGTM2
>>>
>>> Do we have metrics in place in case we got it wrong and sites do rely on
>>> eval's error types in weird and unexpected ways? Or we're relying on bug
>>> reports to alert us of that?
>>>
>>> On Tue, Jun 18, 2019 at 6:34 AM Chris Harrelson 
>>> wrote:
>>>
>>>> I see. Given that lack of interop, I do agree that probably sites are
>>>> not relying on the current behavior, and if they are then they are likely
>>>> not interoperable.
>>>>
>>>> LGTM1 to try.
>>>>
>>>> On Mon, Jun 17, 2019 at 3:02 PM Ross Kirsling 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jun 17, 2019, 11:42 Chris Harrelson 
>>>>> wrote:
>>>>>
>>>>>> Hi again,
>>>>>>
>>>>>> Sorry for the slow response.
>>>>>>
>>>>>> On Thu, Jun 6, 2019 at 7:17 AM Sathya Gunasekaran <
>>>>>> gsat...@chromium.org> wrote:
>>>>>>
>>>>>>>
>>>>>>> I don't expect to see code that special cases against ReferenceError
>>>>>>> in the wild especially for just early errors. I expect to see code
>>>>>>> that handles both ReferenceErrors and SyntaxErrors. Since we're not
>>>>>>> adding a new type of error, I wouldn't expect to see any breakage.
>>>>>>>
>>>>>>
>>>>>> Do you have any data to support this? Are there any use counters for
>>>>>> how often this situation might occur? e.g. what fraction of pages
>>>>>> trigger ReferenceErrors?
>>>>>> Also, have any other browsers shipped this change yet?
>>>>>>
>>>>>
>>>>> The concern here is purely around *early* ReferenceError. Since
>>>>> ReferenceError has been ambiguous between parse time and runtime, it would
>>>>> have been extremely difficult/fragile to use this information—as 
>>>>> mentioned,
>>>>> one would need to string-match on error messages. (I think folks are hung
>>>>> up on the phrase "observable concern", but I meant this to indicate that
>>>>> there's something non-cosmetic to be *gained*, not that there's worry 
>>>>> about
>>>>> breakage.)
>>>>>
>>>>> The new behavior shipped in Safari TP 83 three weeks ago, and it's
>>>>> important to note that the major engines were not previously in alignment
>>>>> anyway. V8 was conforming to spec, but JSC actually had *late*
>>>>> ReferenceError for all four cases and SM was split (`0++` and `0--` were
>>>>> early SyntaxError while `0 = 0` and `0 += 0` were early ReferenceError).
>>>>>
>>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/ms

Re: [v8-users] Repeated module evaluation.

[Adam Klein]

On Wed, Jun 19, 2019 at 9:27 PM ClearScript Developers <
clearscript...@gmail.com> wrote:

> "When you say "local to the evaluation context", what do you mean?"
>
> Suppose you have an isolate with two contexts, C1 and C2, and a module
> whose evaluation produces side effects. Once you've evaluated the module in
> C1, there's no way to apply its side effects to C2. You can import it into
> C2, but doing so doesn't replicate the side effects. You can use its
> exports in C2, but they won't work correctly if they rely on the side
> effects.
>
> "The current API is designed to allow one evaluation per v8::Context"
>
> But it doesn't do that. It allows one evaluation per isolate. Evaluating a
> module in one context breaks it for others.
>

What I'd recommend is to call CompileModule() again to get another Module
object; I believe this should hit the in-memory cache and be very fast, and
should let you go back through the Instantiate/Evaluate cycle in C2.


> On Wednesday, June 19, 2019 at 5:21:43 PM UTC-4, Adam Klein wrote:
>>
>> When you say "local to the evaluation context", what do you mean? Modules
>> can't have side-effects on the lexical top-level scope of the importing
>> module; they can only affect the broader "realm" (in ECMAScript spec
>> terms), the v8::Context (in V8 API terms) or the mutable global state (in
>> more common terms). The current API is designed to allow one evaluation per
>> v8::Context, since part of Instantiation
>> <https://cs.chromium.org/chromium/src/v8/include/v8.h?rcl=ab5fb228bcaf387cc72dfd93cdc62c1db4867ebf=1302>
>> is tying a v8::Module to a v8::Context. So if you instantatiate a module in
>> multiple context, multiple evaluations should still work.
>>
>> On Thu, Jun 13, 2019 at 7:12 AM ClearScript Developers <
>> clearsc...@gmail.com> wrote:
>>
>>> Sorry to revive this thread, but we're encountering the same issue.
>>>
>>> v8::Script is not a replacement for v8::Module; for one thing, scripts
>>> can't import modules :)
>>>
>>> In any case, V8's API seems deficient here. Modules can be imported
>>> specifically for their side effects. There's even unique syntax for that
>>> (see
>>> https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#Import_a_module_for_its_side_effects_only).
>>> And since side effects can be local to the evaluation context, it should be
>>> possible to evaluate a module in multiple contexts.
>>>
>>> Opinions?
>>>
>>> On Wednesday, February 20, 2019 at 2:54:26 PM UTC-5, Adam Klein wrote:
>>>>
>>>> Modules are designed (in the JavaScript spec) to only have their
>>>> top-level code run once. To  "re-use" a cached module, the expectation is
>>>> that other modules would use imports to access the exports of that module.
>>>> In particular, in your code snippet, you'd return the already-evaluated
>>>> module from the ResolveCallback passed to the module that wishes to import
>>>> from it.
>>>>
>>>> If what you want to do is compile some code and run it multiple times,
>>>> a v8::Script is probably want you want instead.
>>>>
>>>> On Tue, Feb 12, 2019 at 5:11 PM Jane Chen  wrote:
>>>>
>>>>> Embedding v8 6.7.
>>>>>
>>>>> I found the following test in test-modules.cc:
>>>>>
>>>>> CHECK(module->Evaluate(env.local())
>>>>>   .ToLocalChecked()
>>>>>   ->StrictEquals(v8_str("gaga")));
>>>>> CHECK_EQ(Module::kEvaluated, module->GetStatus());
>>>>>
>>>>> CHECK(module->Evaluate(env.local()).ToLocalChecked()->IsUndefined());
>>>>>
>>>>> and it is consistent with what I'm seeing.  Basically, evaluating an
>>>>> evaluated module returns undefined.  I don't get the rational for this
>>>>> behavior.  Once a module is evaluated, it is no good for evaluation?  Then
>>>>> how am I supposed to re-use a cached module?  Re-instantiating it doesn't
>>>>> seem to help.
>>>>>
>>>>> --
>>>>> --
>>>>> v8-users mailing list
>>>>> v8-u...@googlegroups.com
>>>>> http://groups.google.com/group/v8-users
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "v8-users" group.
>>>>

[v8-users] Re: [blink-dev] Intent to Implement and Ship: Let all early errors be SyntaxErrors

[Adam Klein]

Hi Yoav,

We don't have existing metrics that would help here, and I honestly don't
even know what we would track for this specific issue (detecting that a
certain exception came from eval, for example, isn't something we currently
track).

Bug reports are how we tend to track issues like this. And fwiw my
intuition matches Sathya & Ross's (that this is very unlikely to cause
problems in practice).

On Mon, Jun 17, 2019 at 9:42 PM Yoav Weiss  wrote:

> LGTM2
>
> Do we have metrics in place in case we got it wrong and sites do rely on
> eval's error types in weird and unexpected ways? Or we're relying on bug
> reports to alert us of that?
>
> On Tue, Jun 18, 2019 at 6:34 AM Chris Harrelson 
> wrote:
>
>> I see. Given that lack of interop, I do agree that probably sites are not
>> relying on the current behavior, and if they are then they are likely not
>> interoperable.
>>
>> LGTM1 to try.
>>
>> On Mon, Jun 17, 2019 at 3:02 PM Ross Kirsling 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jun 17, 2019, 11:42 Chris Harrelson  wrote:
>>>
 Hi again,

 Sorry for the slow response.

 On Thu, Jun 6, 2019 at 7:17 AM Sathya Gunasekaran 
 wrote:

>
> I don't expect to see code that special cases against ReferenceError
> in the wild especially for just early errors. I expect to see code
> that handles both ReferenceErrors and SyntaxErrors. Since we're not
> adding a new type of error, I wouldn't expect to see any breakage.
>

 Do you have any data to support this? Are there any use counters for
 how often this situation might occur? e.g. what fraction of pages
 trigger ReferenceErrors?
 Also, have any other browsers shipped this change yet?

>>>
>>> The concern here is purely around *early* ReferenceError. Since
>>> ReferenceError has been ambiguous between parse time and runtime, it would
>>> have been extremely difficult/fragile to use this information—as mentioned,
>>> one would need to string-match on error messages. (I think folks are hung
>>> up on the phrase "observable concern", but I meant this to indicate that
>>> there's something non-cosmetic to be *gained*, not that there's worry about
>>> breakage.)
>>>
>>> The new behavior shipped in Safari TP 83 three weeks ago, and it's
>>> important to note that the major engines were not previously in alignment
>>> anyway. V8 was conforming to spec, but JSC actually had *late*
>>> ReferenceError for all four cases and SM was split (`0++` and `0--` were
>>> early SyntaxError while `0 = 0` and `0 += 0` were early ReferenceError).
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEhQtWJoxxi3PwfutmSbZFJGyNkKpgD1OeMFDM6%3D2sA4bw%40mail.gmail.com
> 
> .
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAEvLGcKV93MirncPshaX9z29%3D5-0aBcecEOJ-Z%3D0zZE1%2BQb%3D7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [v8-dev] Re: Intent to Implement: Add dayPeriod option for Intl.DateTimeFormat

[Adam Klein]

Thanks for the background. For blink-dev's purposes, I'm less concerned
about the underlying spec process (if these seem small enough to the domain
experts, I'll mostly defer to them). But it would still be nice to have a
short "explainer" even for small changes like this; a PR or Github issue by
itself isn't well-formatted for understanding the current state, the use
case for the new feature, etc. Not sure where that would go; perhaps a gist
attached to the PR would be the easiest thing. How does something like that
sound to 402 folks?

On Fri, May 24, 2019 at 6:39 AM 'Shane Carr' via v8-dev <
v8-...@googlegroups.com> wrote:

> We have a history of PRs in ECMA 402 for "small" changes.  Here is a list:
>
>
> https://github.com/tc39/ecma402/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aclosed+Normative
>
> The PRs often involve changes to reflect web reality / ICU behavior.  We
> are discussing with the ECMA 402 editors on how we want to handle Frank's
> work, as a PR or as a staged proposal.  I am leaning toward PR because this
> is only extending an existing API schema (Intl.DateFormat) in a way that is
> fully consistent with other options in that schema.
>
> Shane
>
> On Thu, May 23, 2019 at 6:43 PM Frank Tang (譚永鋒)  wrote:
>
>>
>>
>> On Thu, 23 May 2019 at 01:31, Adam Klein  wrote:
>>
>>> On Thu, May 23, 2019 at 1:11 AM Frank Tang  wrote:
>>>
>>>> Contact emails ft...@chromium.org,js...@chromium.org Explainer
>>>> https://github.com/tc39/ecma402/pull/346
>>>>
>>>
>>> I'd like to better-understand the ECMA 402 process around small
>>> additions like this (and your other email about "quarter"). Will this
>>> become a formal proposal (and an attached issue,
>>> https://github.com/tc39/ecma402/issues/343) the extent of the
>>> specification process for this feature? Is there a "stage" process for
>>> these things?
>>>
>>
>> Thank about this point. I actually brought this issue up to ECMA402 chair
>> sffc@ about should I group them into one proposal or deal with them as
>> separated PR. And Shane also loop in Daniel about this. Shane is following
>> up this too. Some of the changes bigger this one, such as the BigInt /
>> Intl.NumberFormat  support went through as a PR and this is not really a
>> "big new feature" but rather some minor improvement on pre-existing API so
>> I try to follow the same track. There are several issues all independent
>> from each other and group them together into one proposal might create
>> unnecessary dependency (for example, the week of year and week of month has
>> CLDR/ ICU issues which will take a much longer time to address) and propose
>> each one of them as individual proposal (so there will be 4) seems too
>> much.
>>
>> Regards,
>> Frank
>>
>>>
>>>
>>>> Design docs/spec Specification:
>>>> https://github.com/tc39/ecma402/pull/346
>>>> https://github.com/tc39/ecma402/pull/346 TAG review No TAG review
>>>> needed since it is part of TC39 ECMA402 Summary Add dayPeriod option
>>>> to Intl.DateTimeFormat so the caller can format time such as "7 in the
>>>> morning", "11 in the morning", "12 noon", "1 in the afternoon", "6 in the
>>>> evening", "10 at night" (or in Chinese "清晨7時", "上午11時", "中午12時", "下午1時"
>>>> ,"下午6時" ,"晚上10時") Motivation It enhances the Intl.DateTimeFormat API
>>>> to match what the developer cal already do in C++ and Java by calling ICU
>>>> and ICU4J. Without this feature, developer need to either format the
>>>> quarter in the server or ship a set of day period pattern and hour to day
>>>> period mapping logic from the server to client to perform such task.
>>>> Risks
>>>> Interoperability and Compatibility low. *Firefox*: No public signals
>>>> *Edge*: No public signals *Safari*: No public signals *Web developers*:
>>>> No signals Ergonomics No increase of data. All required data already
>>>> build into ICU.
>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this
>>>> feature fully tested by web-platform-tests
>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>> ? Yes Tests will be added into test262 before we consider shipping it. Link
>>>> to entry on the Chro

[v8-users] Re: Intent to Implement: Add dayPeriod option for Intl.DateTimeFormat

[Adam Klein]

On Thu, May 23, 2019 at 1:11 AM Frank Tang  wrote:

> Contact emails ft...@chromium.org,js...@chromium.org Explainer
> https://github.com/tc39/ecma402/pull/346
>

I'd like to better-understand the ECMA 402 process around small additions
like this (and your other email about "quarter"). Will this become a formal
proposal (and an attached issue, https://github.com/tc39/ecma402/issues/343)
the extent of the specification process for this feature? Is there a
"stage" process for these things?


> Design docs/spec Specification: https://github.com/tc39/ecma402/pull/346
> https://github.com/tc39/ecma402/pull/346 TAG review No TAG review needed
> since it is part of TC39 ECMA402 Summary Add dayPeriod option to
> Intl.DateTimeFormat so the caller can format time such as "7 in the
> morning", "11 in the morning", "12 noon", "1 in the afternoon", "6 in the
> evening", "10 at night" (or in Chinese "清晨7時", "上午11時", "中午12時", "下午1時"
> ,"下午6時" ,"晚上10時") Motivation It enhances the Intl.DateTimeFormat API to
> match what the developer cal already do in C++ and Java by calling ICU and
> ICU4J. Without this feature, developer need to either format the quarter in
> the server or ship a set of day period pattern and hour to day period
> mapping logic from the server to client to perform such task. Risks
> Interoperability and Compatibility low. *Firefox*: No public signals
> *Edge*: No public signals *Safari*: No public signals *Web developers*:
> No signals Ergonomics No increase of data. All required data already
> build into ICU.
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature
> fully tested by web-platform-tests
> 
> ? Yes Tests will be added into test262 before we consider shipping it. Link
> to entry on the Chrome Platform Status
> https://www.chromestatus.com/features/6520669959356416
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAEvLGcJoZOD-B4Uyh%3D1m3a%3D0J%3DFdDVa7%2BaA6UqN%2BBdwHrW5X%2Bg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Re: Intent to Implement: Add formatRange / formatRangeToParts to DateTimeFormat

[Adam Klein]

(+ftang)

On Wed, May 8, 2019 at 11:27 AM Adam Klein  wrote:

> Happy to see this moving forward! A note, below, on the (new-to-V8) intent
> process.
>
> On Mon, May 6, 2019 at 10:48 AM Frank Tang  wrote:
>
>> cc v8-users@
>>
>> On Fri, May 3, 2019 at 7:58 PM Frank Tang  wrote:
>>
>>> opps. forgot to include the blink-dev@ in the To field.
>>>
>>> On Fri, May 3, 2019 at 7:51 PM Frank Tang  wrote:
>>>
>>>> Title: Intent to Implement: Add formatRange / formatRangeToParts to
>>>> DateTimeFormat
>>>>
>>>>
>>>> Contact emails
>>>>
>>>> ft...@chromium.com, fabal...@chromium.com
>>>>
>>>> Explainer
>>>>
>>>> https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange
>>>>
>>>>
>>>> https://rawgit.com/fabalbon/proposal-intl-DateTimeFormat-formatRange/master/out/
>>>>  (notice
>>>> the spec is already advanced into stage 3 in tc39 March 2019 meeting but
>>>> the latest version has not bump the version from 2 to 3 yet)
>>>>
>>>> Design doc/Spec
>>>>
>>>> https://goo.gl/PGUQ1d
>>>>
>>>> Summary
>>>>
>>>> Add two new functions to Intl.DateTimeFormat.prototype - formateRange
>>>> and formatRangeToParts to formate the range of two dates in a given locale.
>>>>
>>>> Motivation
>>>>
>>>> It's common for websites to display date intervals or date ranges to
>>>> show the span of an event, such as a hotel reservation, the billing period
>>>> of a service, or other similar uses. In order to implement this, websites
>>>> often use localization libraries, such as Google Closure, to format the
>>>> date range, or they may simply resort to formatting both dates
>>>> independently.
>>>>
>>>> If following the second alternative, web developers may encounter
>>>> problems such as repeating fields that are common between the two dates,
>>>> inappropriate order of the dates for the locale or using an incorrect
>>>> delimiter for the locale. This API provide locale sensitive formatting
>>>> avoid such problem.
>>>>
>>>> Risks
>>>>
>>>> Interoperability and Compatibility
>>>>
>>>> This is a new API so it should have no risk in term of interoperability
>>>> and compatibility.
>>>>
>>>
> Being a new API doesn't make something immune from interop or compat risk.
> Some things generally listed in this section are stage at TC39 and public
> statements or implementation status from other browser vendors. See
> https://sites.google.com/a/chromium.org/dev/blink?pli=1#TOC-Policy-for-shipping-and-removing-web-platform-API-features
>  for
> more details.
>
> Ergonomics
>>>>
>>>> The performance of constructing the Intl.DateTimeFormat could be slower
>>>> if we create the underline icu DateIntervalFormatter. To avoid such
>>>> performance issue we identified, currently we plan to lazy initialize the
>>>> required DateIntervalFormatter upon the first call to the formatRange
>>>> or formateRangeToParts and cache the value afterward. This approach avoid
>>>> such performance impact.
>>>>
>>>> Activation
>>>>
>>>> Web developers could use the API immediately upon our shipment, based
>>>> on the usage of previous well supported Intl.DateTimeFormat object.
>>>>
>>>> Debuggability
>>>>
>>>> Nothing special.
>>>>
>>>>
>>>> Will this feature be supported on all six Blink platforms (Windows,
>>>> Mac, Linux, Chrome OS, Android, and Android WebView)?
>>>>
>>>> Yes.
>>>>
>>>> Is this feature fully tested by web-platform-tests
>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>> ?
>>>>
>>>> Tests under tc39/test262 will includes many tests to test this API.
>>>>
>>>> test/intl402/DateTimeFormat/prototype/formatRange
>>>> <https://github.com/tc39/test262/tree/master/test/intl402/DateTimeFormat/prototype/formatRange>
>>>> and
>>>>
>>>> test/intl402/DateTimeFormat/prototype/formatRangeToParts
>>>> <https://github.com/tc39/test262/tree/master/test/intl402/DateTimeFormat/prototype/formatRangeToParts

Re: [v8-users] Re: Intent to Implement: Add formatRange / formatRangeToParts to DateTimeFormat

[Adam Klein]

Happy to see this moving forward! A note, below, on the (new-to-V8) intent
process.

On Mon, May 6, 2019 at 10:48 AM Frank Tang  wrote:

> cc v8-users@
>
> On Fri, May 3, 2019 at 7:58 PM Frank Tang  wrote:
>
>> opps. forgot to include the blink-dev@ in the To field.
>>
>> On Fri, May 3, 2019 at 7:51 PM Frank Tang  wrote:
>>
>>> Title: Intent to Implement: Add formatRange / formatRangeToParts to
>>> DateTimeFormat
>>>
>>>
>>> Contact emails
>>>
>>> ft...@chromium.com, fabal...@chromium.com
>>>
>>> Explainer
>>>
>>> https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange
>>>
>>>
>>> https://rawgit.com/fabalbon/proposal-intl-DateTimeFormat-formatRange/master/out/
>>>  (notice
>>> the spec is already advanced into stage 3 in tc39 March 2019 meeting but
>>> the latest version has not bump the version from 2 to 3 yet)
>>>
>>> Design doc/Spec
>>>
>>> https://goo.gl/PGUQ1d
>>>
>>> Summary
>>>
>>> Add two new functions to Intl.DateTimeFormat.prototype - formateRange
>>> and formatRangeToParts to formate the range of two dates in a given locale.
>>>
>>> Motivation
>>>
>>> It's common for websites to display date intervals or date ranges to
>>> show the span of an event, such as a hotel reservation, the billing period
>>> of a service, or other similar uses. In order to implement this, websites
>>> often use localization libraries, such as Google Closure, to format the
>>> date range, or they may simply resort to formatting both dates
>>> independently.
>>>
>>> If following the second alternative, web developers may encounter
>>> problems such as repeating fields that are common between the two dates,
>>> inappropriate order of the dates for the locale or using an incorrect
>>> delimiter for the locale. This API provide locale sensitive formatting
>>> avoid such problem.
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> This is a new API so it should have no risk in term of interoperability
>>> and compatibility.
>>>
>>
Being a new API doesn't make something immune from interop or compat risk.
Some things generally listed in this section are stage at TC39 and public
statements or implementation status from other browser vendors. See
https://sites.google.com/a/chromium.org/dev/blink?pli=1#TOC-Policy-for-shipping-and-removing-web-platform-API-features
for
more details.

Ergonomics
>>>
>>> The performance of constructing the Intl.DateTimeFormat could be slower
>>> if we create the underline icu DateIntervalFormatter. To avoid such
>>> performance issue we identified, currently we plan to lazy initialize the
>>> required DateIntervalFormatter upon the first call to the formatRange
>>> or formateRangeToParts and cache the value afterward. This approach avoid
>>> such performance impact.
>>>
>>> Activation
>>>
>>> Web developers could use the API immediately upon our shipment, based on
>>> the usage of previous well supported Intl.DateTimeFormat object.
>>>
>>> Debuggability
>>>
>>> Nothing special.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>>> Linux, Chrome OS, Android, and Android WebView)?
>>>
>>> Yes.
>>>
>>> Is this feature fully tested by web-platform-tests
>>> 
>>> ?
>>>
>>> Tests under tc39/test262 will includes many tests to test this API.
>>>
>>> test/intl402/DateTimeFormat/prototype/formatRange
>>> 
>>> and
>>>
>>> test/intl402/DateTimeFormat/prototype/formatRangeToParts
>>> 
>>>
>>>
>>>
>>> Link to entry on the feature dashboard 
>>>
>>> https://www.chromestatus.com/feature/5077134515109888
>>>
>>> Requesting approval to ship?
>>>
>>> “No”. The feature is behind a runtime flag harmony_intl_date_format_range
>>> and I will later send an Intent to Ship
>>> 
>>> email when I am ready to enable by default.
>>>
>> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

[v8-users] Re: [v8-dev] Intent to Ship: Promise.allSettled

[Adam Klein]

LGTM!

On Tue, Apr 23, 2019 at 4:19 PM Sathya Gunasekaran 
wrote:

> Contact Emails:
> gsat...@chromium.org
>
> Spec:
> https://tc39.github.io/proposal-promise-allSettled/
>
> Summary:
> Promise.allSettled returns a promise that is fulfilled with an array
> of promise state snapshots, but only after all the original promises
> have settled, i.e. become either fulfilled or rejected.
>
> Interoperability and compatibility risk:
> This stage 3 proposal introduces a new static method on the Promise
> constructor. There is very low compat risk.
>
> Firefox: In development
> Safari: No signals
> Edge: No signals
>
> Is this feature fully tested?
> Yes, this feature passes V8's own mjsunit tests as well as all the
> test262 tests.
>
> Tracking bug:
> https://bugs.chromium.org/p/v8/issues/detail?id=9060
>
> Link to entry on the Chrome Platform Status dashboard
> https://www.chromestatus.com/feature/5547381053456384
>
> Requesting approval to ship?
> Yes. Note that since this is a V8/JS feature, this post is just an FYI
> to blink-dev — no sign off from Blink API owners is required.
>
> --
> --
> v8-dev mailing list
> v8-...@googlegroups.com
> http://groups.google.com/group/v8-dev
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intend to Ship: Locale sensitive BigInt.prototype.toLocaleString & allow Intl.NumberFormat format/formatToParts to take BigInt

[Adam Klein]

LGTM2

On Thu, Apr 18, 2019 at 4:21 PM Sathya Gunasekaran 
wrote:

> LGTM
>
> On Thu, Apr 18, 2019 at 4:02 PM Frank Tang  wrote:
>
>> *Intend to Ship: Locale sensitive BigInt.prototype.toLocaleString & allow
>> Intl.NumberFormat format/formatToParts to take BigInt*
>>
>>
>> Spec
>>
>> https://github.com/tc39/ecma402/pull/236
>>
>>
>> Summary
>>
>> A Stage 3 Pull Request to change the ECMA402 that support locale
>> sensitive BigInt.prototype.toLocaleString to format the BigInt and also
>> allow Intl.NumberFormat.prototype.format and
>> Intl.NumberFormat.prototype.formatToParts to take BigInt as value.
>> Example
>>
>> BigInt(12345678901234567890).toLocaleString("de")
>> // "12.345.678.901.234.567.168"
>>
>> 12345678901234567890n.toLocaleString("en")
>>
>> // "12,345,678,901,234,567,168"
>>
>> 12345678901234567890n.toLocaleString("hi")
>>
>> // "1,23,45,67,89,01,23,45,67,168"
>>
>> 12345678901234567890n.toLocaleString("fa")
>>
>> // "۱۲٬۳۴۵٬۶۷۸٬۹۰۱٬۲۳۴٬۵۶۷٬۱۶۸"
>>
>> 12345678901234567890n.toLocaleString("fr")
>>
>> // "12 345 678 901 234 567 168"
>>
>> 12345678901234567890n.toLocaleString("th-Thai")
>>
>> // "12,345,678,901,234,567,168"
>>
>> 12345678901234567890n.toLocaleString("th-u-nu-Thai")
>>
>> // "๑๒,๓๔๕,๖๗๘,๙๐๑,๒๓๔,๕๖๗,๑๖๘"
>>
>> let nf = new Intl.NumberFormat("hi");
>>
>> nf.format(12345678901234567890n);
>>
>> // "1,23,45,67,89,01,23,45,67,168"
>>
>> nf.formatToParts(12345678901234567890n);
>>
>> // [{type: "integer", value: "1"},
>> //  {type: "group", value: ","},
>> //  {type: "integer", value: "23"},
>> //  {type: "group", value: ","}
>> //  {type: "integer", value: "45"},
>> //  {type: "group", value: ","},
>> //  {type: "integer", value: "67"},
>> //  {type: "group", value: ","},
>> //  {type: "integer", value: "89"},
>> //  {type: "group", value: ","},
>> //  {type: "integer", value: "01"},
>> //  {type: "group", value: ","},
>> //  {type: "integer", value: "23"},
>> //  {type: "group", value: ","},
>> //  {type: "integer", value: "45"},
>> //  {type: "group", value: ","},
>> //  {type: "integer", value: "67"},
>> //  {type: "group", value: ","},
>> //  {type: "integer", value: "890"}]
>>
>> Interoperability and compatibility risk
>>
>> The BigInt.prototype.toLocaleString was implemented as
>> BigInt.prototype.toString. This launch will make it return string
>> differently, based on the cultural conventions of the locale. Code
>> expecting the BigInt.prototype.toLocaleString behavior the same as
>> BigInt.prototype.toString will break but the chance is very low since the
>> ECMA262 specification already make it clear the toLocaleString is
>> delegating to the ECMA402 specification to specify. The
>> Intl.NumberFormat.prototype.format and formatToParts now take BigInt as
>> value instead of throwing exception.
>>
>>
>>
>>-
>>
>>Firefox:No public signals
>>-
>>
>>Edge: No public signals
>>-
>>
>>Safari:No public signals
>>-
>>
>>Web Developers:No signals
>>
>>
>> Is this feature fully tested?
>>
>> Yes; our implementation passes our own V8 tests for all the features as
>> well as tests under test262.
>>
>>-
>>
>>intl402/BigInt/prototype/toLocaleString
>>
>> 
>>-
>>
>>test/intl/bigint/
>>
>>
>>
>> Tracking bug
>>
>> https://crbug.com/v8/8699
>>
>>
>>
>> Design Doc:
>>
>> https://goo.gl/qpRwFo
>>
>>
>>
>> Link to entry on the Chrome Platform Status dashboard
>>
>> https://www.chromestatus.com/feature/5742274625404928
>>
>> Requesting approval to ship?
>>
>> Yes. Note that since this is a V8/JS feature, this post is just an FYI to
>> blink-dev — no signoff from Blink API owners is required.
>>
>>
>>
>>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to Ship: WebAssembly Bulk Memory operations

[Adam Klein]

LGTM!

+blink-dev FYI

On Tue, Apr 9, 2019 at 2:40 PM Ben Smith  wrote:

> Contact emails
>
> bi...@chromium.org
>
> Spec
>
> https://github.com/WebAssembly/bulk-memory-operations
>
> Summary
>
> The WebAssembly Bulk memory proposal adds 7 new instructions for
> manipulating memory and tables in bulk, similar to memcpy and memset.
>
> It also adds "passive" segments, which are defined statically but can be
> used at runtime to initialize memory or a table. This functionality is
> useful
>
> when implementing threads. It also provides a performance win for memcpy
> and memset operations.
>
>
> Interoperability and Compatibility risk
> This is a phase 3 WebAssembly proposal
> , which is generally when
> browsers implement and provide feedback. Since it's implemented in Chrome
> and Firefox and passes tests in both, it's unlikely to change at this point.
>
> Firefox: I
> 
> mplemented
> Safari: No signals
>
> Is this feature fully tested?
>
> Yes, tested in wasm cctests, for TurboFan and the wasm interpreter:
> https://cs.chromium.org/chromium/src/v8/test/cctest/wasm/test-run-wasm-bulk-memory.cc
>
> Also passes the wasm spec tests:
> https://github.com/WebAssembly/testsuite/tree/master/proposals/bulk-memory-operations
>
> (with two bugs to address:
> https://bugs.chromium.org/p/v8/issues/detail?id=8892,
> https://bugs.chromium.org/p/v8/issues/detail?id=9106)
>
>
> Tracking bug
>
> https://crbug.com/v8/7747
>
> Entry on the feature dashboard 
>
> https://www.chromestatus.com/feature/4590306448113664
>
> Requesting approval to ship?
>
> Yes.
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [blink-dev] Re: [v8-users] Intent to Ship: Numeric separators

[Adam Klein]

LGTM3

On Fri, Mar 29, 2019 at 5:37 PM Sam Goto  wrote:

> LGTM++!! Exciting!
>
> On Thu, Mar 28, 2019, 12:21 PM 'Mathias Bynens' via blink-dev <
> blink-...@chromium.org> wrote:
>
>> LGTM now that the conflict has been resolved!
>>
>> On Thu, Mar 28, 2019 at 12:01 PM 'Sathya Gunasekaran' via blink-dev <
>> blink-...@chromium.org> wrote:
>>
>>> On Thu, Mar 15, 2018 at 2:25 PM Adam Klein  wrote:
>>> >
>>> > There's a possible conflict between this feature and another proposal,
>>> Extended Numeric Literals. The issue,
>>> https://github.com/tc39/proposal-extended-numeric-literals/issues/7,
>>> should be addressed at next week's TC39 meeting, and I'd like to see it
>>> settled before shipping this in V8.
>>> >
>>>
>>> This issue has been resolved.
>>>
>>> > On Thu, Mar 15, 2018 at 5:02 PM, Sathya Gunasekaran <
>>> gsat...@chromium.org> wrote:
>>> >>
>>> >> Note that this is a v8/JavaScript feature, so this post is just an
>>> FYI for blink-dev — no sign-off from Blink API owners is required.
>>> >>
>>> >>
>>> >> Contact Emails:
>>> >> gsat...@chromium.org
>>> >> b...@b6n.ch
>>> >>
>>> >> Spec:
>>> >> https://tc39.github.io/proposal-numeric-separator/
>>> >>
>>> >> Summary:
>>> >> This feature enables developers to make their numeric literals more
>>> readable by creating a visual separation between groups of digits. Using
>>> underscores (_, U+005F) as separators helps improve readability for numeric
>>> literals, for ex: 1_000_000_000.
>>> >>
>>> >> Interoperability and Compatibility Risk:
>>> >> This is a Stage3 feature in the TC39 process. Previously this was a
>>> SyntaxError so there is no compat risk.
>>> >>
>>> >> Safari and Edge have not implemented this feature. This is under
>>> development in Firefox.
>>> >>
>>> >> V8 tests as well as test262 tests pass.
>>> >>
>>> >> Tracking bug:
>>> >> https://bugs.chromium.org/p/v8/issues/detail?id=7317
>>> >>
>>> >> Chromestatus entry:
>>> >> https://www.chromestatus.com/feature/5829906369871872
>>> >>
>>> >> --
>>> >> --
>>> >> v8-users mailing list
>>> >> v8-users@googlegroups.com
>>> >> http://groups.google.com/group/v8-users
>>> >> ---
>>> >> You received this message because you are subscribed to the Google
>>> Groups "v8-users" group.
>>> >> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to v8-users+unsubscr...@googlegroups.com.
>>> >> For more options, visit https://groups.google.com/d/optout.
>>> >
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> > To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEvLGcLP3jm-TDH9FkrwvtrYiz4%2BEGYvHAQRg5UP98PQHKuRXw%40mail.gmail.com
>>> .
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMd%2BM7yE0uhhY5SssaaKxF%2Bw-hY7ibSVd2fsbEPD3A6C%2BpLa1w%40mail.gmail.com
>>> .
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To view this discussion on the web visit
>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADizRgZ2zF%2B2oC_Rf5CQNbT6ueBFXeDpeWYC0SaawK0eM0h0fA%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADizRgZ2zF%2B2oC_Rf5CQNbT6ueBFXeDpeWYC0SaawK0eM0h0fA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Intent to Ship: WebAssembly non-trapping float-to-int conversions

[Adam Klein]

LGTM!

On Tue, Mar 12, 2019 at 5:31 PM Ben Smith  wrote:

> Contact emails
>
> bi...@chromium.org
>
> Spec
>
> https://github.com/WebAssembly/nontrapping-float-to-int-conversions
> 
>
> Summary
>
> WebAssembly shipped with trapping float-to-int conversions, which are
> difficult for tools to use correctly, because the behavior differs from
> native machines. This proposal provides new instructions that are
> non-trapping equivalents of the original conversions.
>
>
> Interoperability and Compatibility risk
> This is a phase 4 WebAssembly proposal
> , so the compatibility risk is
> low.
>
> Edge: Implemented 
> Firefox: Shipped
> 
> Safari: No signals
>
> Is this feature fully tested?
>
> Yes, tested in wasm cctests:
> https://cs.chromium.org/chromium/src/v8/test/cctest/wasm/test-run-wasm.cc?l=3165.
> Also passes spec tests:
> https://github.com/WebAssembly/nontrapping-float-to-int-conversions/blob/master/test/core/conversions.wast#L252
>
>
> Tracking bug
>
> *https://crbug.com/v8/7226 *
>
>
> Entry on the feature dashboard 
>
> https://www.chromestatus.com/feature/4611843511287808
>
>
> Requesting approval to ship?
>
> Yes. Note that since this is a V8/Wasm feature, this post is just an FYI
> to blink-dev — no sign off from Blink API owners is required.
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/72c6d3c4-2e9a-43e2-ab6a-946a2ba7ec68%40chromium.org
> 
> .
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Re: [v8-dev] Intent to ship: Private class fields

[Adam Klein]

LGTM!!

On Wed, Feb 20, 2019 at 12:20 PM 'Mathias Bynens' via blink-dev <
blink-...@chromium.org> wrote:

> LGTM
>
> On Wed, Feb 20, 2019 at 8:58 PM Sathya Gunasekaran 
> wrote:
>
>> Contact Emails
>>
>> gsat...@chromium.org
>>
>>
>> Spec
>>
>> https://github.com/tc39/proposal-class-fields
>>
>>
>> Summary (taken from our WebFu article
>> )
>>
>>
>>
>> This private fields proposal provides encapsulation: If you're using an
>> instance of a class, you cannot reference that class's private fields from
>> outside the class body. You can only reference private fields from within
>> the class that defines them.
>>
>>
>> The new private fields syntax is similar to public fields, except you
>> mark the field as being private by using #
>> .
>> You can think of the # as being part of the field name:
>>
>>
>> class IncreasingCounter {
>>
>>  #count = 0;
>>
>>  get value() {
>>
>>console.log('Getting the current value!');
>>
>>return this.#count;
>>
>>  }
>>
>>  increment() {
>>
>>this.#count++;
>>
>>  }
>>
>> }
>>
>>
>> Private fields are not accessible outside of the class body:
>>
>>
>> const counter = new IncreasingCounter();
>>
>> counter.#count;
>>
>> // → SyntaxError
>>
>> counter.#count = 42;
>>
>> // → SyntaxError
>>
>>
>> This intent to ship includes private static fields as well:
>>
>>
>> class ClassCounter {
>>
>>  static #count = 0;
>>
>>  static increment() {
>>
>>this.#count++;
>>
>>  }
>>
>> }
>>
>> ClassCounter.#count;
>>
>> // → SyntaxError
>>
>> ClassCounter.increment();
>>
>>
>>
>> Interoperability and compatibility risk
>>
>> This stage 3 proposal introduces new syntax that was previously a
>> SyntaxError. There’s very low web compat risk.
>>
>>
>> Firefox: In development
>> 
>>
>> Safari: In development 
>>
>> Edge: No signals
>>
>>
>> Is this feature fully tested?
>>
>>
>>
>> Yes, this feature passes V8’s own mjsunit/cctest tests as well as all the
>> Test262 tests.
>>
>>
>> Tracking bug
>>
>> v8:5368 
>>
>>
>>
>> Link to entry on the Chrome Platform Status dashboard
>>
>> https://www.chromestatus.com/feature/6035156464828416
>>
>>
>>
>> Requesting approval to ship?
>>
>> Yes. Note that since this is a V8/JS feature, this post is just an FYI to
>> blink-dev — no sign off from Blink API owners is required.
>>
>>
>>
>> --
>> --
>> v8-dev mailing list
>> v8-...@googlegroups.com
>> http://groups.google.com/group/v8-dev
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to v8-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADizRgaQiv2%3DmEtPOcprwkGg_KcxCfF7A%3DpPp6q-kCW%3DGN2Mtw%40mail.gmail.com
> 
> .
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Repeated module evaluation.

[Adam Klein]

Modules are designed (in the JavaScript spec) to only have their top-level
code run once. To  "re-use" a cached module, the expectation is that other
modules would use imports to access the exports of that module. In
particular, in your code snippet, you'd return the already-evaluated module
from the ResolveCallback passed to the module that wishes to import from it.

If what you want to do is compile some code and run it multiple times, a
v8::Script is probably want you want instead.

On Tue, Feb 12, 2019 at 5:11 PM Jane Chen  wrote:

> Embedding v8 6.7.
>
> I found the following test in test-modules.cc:
>
> CHECK(module->Evaluate(env.local())
>   .ToLocalChecked()
>   ->StrictEquals(v8_str("gaga")));
> CHECK_EQ(Module::kEvaluated, module->GetStatus());
> CHECK(module->Evaluate(env.local()).ToLocalChecked()->IsUndefined());
>
> and it is consistent with what I'm seeing.  Basically, evaluating an
> evaluated module returns undefined.  I don't get the rational for this
> behavior.  Once a module is evaluated, it is no good for evaluation?  Then
> how am I supposed to re-use a cached module?  Re-instantiating it doesn't
> seem to help.
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intent to ship: Intl.Locale

[Adam Klein]

LGTM to ship, one note inline

On Tue, Feb 19, 2019 at 9:59 PM Frank Tang (譚永鋒)  wrote:

> Spec
>
> https://tc39.github.io/proposal-intl-locale/
>
> Summary
>
> A Stage 3 proposal that introduces a new standard built-in property of the
> Intl object, which allows the following:
>
>-
>
>Parsing and manipulating the language, region and script of a locale
>-
>
>Reading or writing the Unicode extension tags in a locale
>-
>
>A serializable, standard format to store user locale preferences for
>use in Intl APIs rather than a combination of language and options bag.
>-
>
>For future proposals, a Locale class can be used for an interface to
>get at various kinds of locale data, including likely subtags, first day of
>the week, various display names, etc.
>-
>
>Allow Intl objects to take Intl.Locale object as item in the locales
>parameter in addition to the pre-existing string form.
>
> Example
>
> let loc = new Intl.Locale("pl-u-hc-h12", {
>
>  calendar: 'gregory'
>
> });
>
> console.log(loc.language); // "pl"
>
> console.log(loc.hourCycle); // "h12"
>
> console.log(loc.calendar); // "gregory"
>
> console.log(loc.toString()); // "pl-u-ca-gregory-hc-h12"
>
> // use Intl.Locale in Intl.DateTimeFormat constructor
>
> let df = new Intl.DateTimeFormat([loc, "pl"]);
>
> // Add likely subtags to the locale
>
> console.log(loc.maximize().toString()); //
> "pl-Latn-PL-u-ca-gregory-hc-h12"
>
> // Remove likely subtags from locale
>
> console.log((new Intl.Locale("zh-Hant-TW")).minimize().toString()) //
> "zh-TW"
>
> console.log((new Intl.Locale("zh-Hans-CN")).minimize().toString()) // "zh"
>
>
>
> Interoperability and compatibility risk
>
> The Intl.Locale is new and should have no risk to break pre-existing
> javascript code.
>
>-
>
>Firefox:In development
>
>-
>
>Edge:In development 
>-
>
>Safari:No public signals
>-
>
>Web Developers:No signals
>
>
> Is this feature fully tested?
>
> Yes; our implementation passes our own V8 tests as well as the Test262
> tests for all the features. To pass all the test262 tests, V8 is based on
> the latest ICU version 63 with 3 bug fixing patches (uloc1.patch
> ,
> uloc2.patch
> ,
> uloc3.patch
> ),
> which are part of the coming ICU 64 (schedule to be released on March 29,
> 2019) release.
>

Based on our previous conversation, it sounds like even with ICU 63 the
failures would only be in edge cases, i.e., very uncommon locales. Can you
confirm?


> Tracking bug
>
> https://crbug.com/v8/7684
>
>
>
> Link to entry on the Chrome Platform Status dashboard
>
> https://www.chromestatus.com/feature/4936310187884544
>
>
>
> Requesting approval to ship?
>
> Yes. Note that since this is a V8/JS feature, this post is just an FYI to
> blink-dev — no signoff from Blink API owners is required.
>
>
> --
> Frank Yung-Fong Tang
> 譚永鋒 / 
> Sr. Software Engineer
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Re: [v8-dev] Intent to Ship: RegExp @@matchAll / String.prototype.matchAll

[Adam Klein]

LGTM2

On Thu, Dec 13, 2018 at 3:27 PM Sathya Gunasekaran 
wrote:

> LGTM
> On Thu, Dec 13, 2018 at 2:01 PM Peter Wong 
> wrote:
> >
> > Contact emails
> > peter.wm.w...@gmail.com
> > jgru...@chromium.org
> > yang...@chromium.org
> >
> > math...@chromium.org
> >
> >
> > Spec
> > https://github.com/tc39/proposal-string-matchall/
> >
> > https://tc39.github.io/proposal-string-matchall/
> >
> >
> > Summary
> > String.prototype.matchAll behaves similarly to String.prototype.match,
> but returns a full regexp result object for each match in a global or
> sticky regexp.
> >
> > Motivation
> > This offers a simple way to iterate over matches when access to e.g.
> capture groups is needed.
> >
> > const string = 'Magic hex numbers: DEADBEEF CAFE 8BADF00D';
> > const regex = /\b[0-9a-fA-F]+\b/g;
> > for (const match of string.matchAll(regex)) {
> >  console.log(match);
> > }
> >
> > // Iteration 1:
> > [
> >  'DEADBEEF',
> >  index: 19,
> >  input: 'Magic hex numbers: DEADBEEF CAFE 8BADF00D'
> > ]
> >
> > // Iteration 2:
> > [
> >  'CAFE',
> >  index: 28,
> >  input: 'Magic hex numbers: DEADBEEF CAFE 8BADF00D'
> > ]
> >
> > // Iteration 3:
> > [
> >  '8BADF00D',
> >  index: 33,
> >  input: 'Magic hex numbers: DEADBEEF CAFE 8BADF00D'
> > ]
> >
> >
> > Interoperability risk
> > Firefox: In development -
> https://bugzilla.mozilla.org/show_bug.cgi?id=1435829
> > Edge: No public signals
> > Safari: No public signals -
> https://bugs.webkit.org/show_bug.cgi?id=186694
> > Web developers: Positive
> >
> > Compatibility risk
> > The spec has undergone a few updates and depending on whether other
> implementations have kept up, there is a possibility V8 could differ in
> behavior.  At the time of writing, V8 is current with all the latest spec
> updates and have contributed updates to the test262 test suite to minimize
> difference between other implementations.
> >
> >
> > V8 tests (mjsunit) as well as all test262 tests pass for this feature.
> >
> > Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux,
> > Chrome OS, Android, and Android WebView)?
> >
> > Yes
> >
> > Link to entry on the Chrome Platform Status
> > https://www.chromestatus.com/features/5520028858318848
> >
> > Requesting approval to ship?
> > Yes. Note that since this is a V8/JS feature, this post is just an FYI
> to blink-dev — no signoff from Blink API owners is required.
> >
> >
> > --
> > --
> > v8-dev mailing list
> > v8-...@googlegroups.com
> > http://groups.google.com/group/v8-dev
> > ---
> > You received this message because you are subscribed to the Google
> Groups "v8-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to v8-dev+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMd%2BM7zTAcnN5Aqwr1XdpBfd45Het_nOq2%3Deu6U_TvTRRDtVOQ%40mail.gmail.com
> .
>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: How to rescue issues caused by v8::Isolate termination

[Adam Klein]

On Thu, Nov 8, 2018 at 8:21 PM Yutaka Hirano  wrote:

> > As to the problem itself, I have a clarifying questions: doesn't Blink
> already have some choke point to determine whether it's "ok to call script
> now"? If so that'd be a more natural place to add this handling than
> TryCatch.
>
> No, there isn't such a point. To make matters worse, some call-sites don't
> check errors because they don't care.
>
> Sorry for the ignorance but I would like to know V8's policy on
> termination.
>
> 1. What happens if the isolate is forcibly terminated (from another
> thread) while running a script? Will an exception be thrown? Is a
> v8::TryCatch catches the exception?
> 2. What happens if we try to run a script when the isolate has already
> been terminated?
> 3. What happens if v8 calls blink code, the isolate is forcibly terminated
> and then the control is back to v8?
>
>
I'm not intimately familiar with the details here. Yang or Toon, perhaps
you have more insight?


>
>
> On Fri, Nov 9, 2018 at 5:30 AM Adam Klein  wrote:
>
>> Adding a couple more V8 folks who may have thoughts.
>>
>> On Thu, Nov 8, 2018 at 1:59 AM Kentaro Hara  wrote:
>>
>>> On Thu, Nov 8, 2018 at 1:10 AM Yuki Shiino 
>>> wrote:
>>>
>>>> +adamk, cbruni to get more attention from V8 team.  This needs V8
>>>> team's support.
>>>>
>>>> Actually, I intended haraken's (a3) at my proposal (a), but I'm afraid
>>>> that changing an existing API HasCaught() would break backward
>>>> compatibility.  So, I'm also proposing to add a new V8 API like
>>>> v8::TryCatch::HasPendingException or v8::TryCatch::HasCaughtOrTerminated or
>>>> whatever we call it.
>>>>
>>>> By the way, the example code is just an example.  Usually we don't have
>>>> two TryCatch blocks next to each other, and Blink is rethrowing the
>>>> exception in most cases.  I just forgot to write rethrow in the example.
>>>> That's not a point.  Let me revise the example.
>>>>
>>>> Main thread:
>>>> v8::Isolate* worker_isolate = ...;
>>>> worker_isolate->TerminateExecution();  // Terminates the worker
>>>> isolate.
>>>>
>>>> Worker thread (worker isolate):
>>>> Foo();  // The v8::Isolate terminates during execution of Foo.
>>>> Bar();
>>>>
>>>> where Foo and Bar are the followings.
>>>>
>>>> void Foo() {
>>>>   v8::TryCatch try_catch1(isolate);
>>>>   // Call V8 APIs.  The v8::Isolate gets terminated at this point.
>>>>   if (try_catch1.HasCaught()) {  // => true due to the termination
>>>> exception.
>>>> // Rethrow or report the error to global error handlers.
>>>> return;
>>>>   }
>>>> }
>>>>
>>>> void Bar() {
>>>>   v8::TryCatch try_catch2(isolate);
>>>>   // Call V8 APIs.  V8 APIs fail because the isolate is terminating.
>>>>   if (try_catch2.HasCaught()) {  // => false because no new
>>>> exception is thrown inside |try_catch2| scope.
>>>> // Rethrow or report the error to global error handlers.
>>>> return;
>>>>   }
>>>>   // Blink reaches here.  :(
>>>> }
>>>>
>>>
>>> Hmm, I'm a bit confused.
>>>
>>> If Foo() rethrows the exception, why does the worker thread continue
>>> execution and call Bar()? That will cause a problem even when the worker is
>>> not terminated (because the worker continues execution ignoring the thrown
>>> exception)...?
>>>
>>> Also I might want to understand how widely the problem is happening.
>>> First of all, it is not realistic to handle worker's sudden termination in
>>> 100% cases (unless we add checks to all V8 API calls in the Blink code
>>> base). So the best thing we can do is to insert the termination check to
>>> places that may call scripts (e.g., V8ScriptRunner, EventListener, Promise
>>> resolve / reject etc) and reduce the crash rate. We could introduce
>>> HasCaughtOrTerminated() if it helps to reduce the crash rate, but I want to
>>> make sure that assumption is correct. My intuition is that it will be more
>>> useful to identify places that may call scripts often and insert the
>>> termination checks if missing.
>>>
>>
>> I'd similarly like to understand how much this happens i

[v8-users] Re: How to rescue issues caused by v8::Isolate termination

[Adam Klein]

Adding a couple more V8 folks who may have thoughts.

On Thu, Nov 8, 2018 at 1:59 AM Kentaro Hara  wrote:

> On Thu, Nov 8, 2018 at 1:10 AM Yuki Shiino 
> wrote:
>
>> +adamk, cbruni to get more attention from V8 team.  This needs V8 team's
>> support.
>>
>> Actually, I intended haraken's (a3) at my proposal (a), but I'm afraid
>> that changing an existing API HasCaught() would break backward
>> compatibility.  So, I'm also proposing to add a new V8 API like
>> v8::TryCatch::HasPendingException or v8::TryCatch::HasCaughtOrTerminated or
>> whatever we call it.
>>
>> By the way, the example code is just an example.  Usually we don't have
>> two TryCatch blocks next to each other, and Blink is rethrowing the
>> exception in most cases.  I just forgot to write rethrow in the example.
>> That's not a point.  Let me revise the example.
>>
>> Main thread:
>> v8::Isolate* worker_isolate = ...;
>> worker_isolate->TerminateExecution();  // Terminates the worker
>> isolate.
>>
>> Worker thread (worker isolate):
>> Foo();  // The v8::Isolate terminates during execution of Foo.
>> Bar();
>>
>> where Foo and Bar are the followings.
>>
>> void Foo() {
>>   v8::TryCatch try_catch1(isolate);
>>   // Call V8 APIs.  The v8::Isolate gets terminated at this point.
>>   if (try_catch1.HasCaught()) {  // => true due to the termination
>> exception.
>> // Rethrow or report the error to global error handlers.
>> return;
>>   }
>> }
>>
>> void Bar() {
>>   v8::TryCatch try_catch2(isolate);
>>   // Call V8 APIs.  V8 APIs fail because the isolate is terminating.
>>   if (try_catch2.HasCaught()) {  // => false because no new exception
>> is thrown inside |try_catch2| scope.
>> // Rethrow or report the error to global error handlers.
>> return;
>>   }
>>   // Blink reaches here.  :(
>> }
>>
>
> Hmm, I'm a bit confused.
>
> If Foo() rethrows the exception, why does the worker thread continue
> execution and call Bar()? That will cause a problem even when the worker is
> not terminated (because the worker continues execution ignoring the thrown
> exception)...?
>
> Also I might want to understand how widely the problem is happening. First
> of all, it is not realistic to handle worker's sudden termination in 100%
> cases (unless we add checks to all V8 API calls in the Blink code base). So
> the best thing we can do is to insert the termination check to places that
> may call scripts (e.g., V8ScriptRunner, EventListener, Promise resolve /
> reject etc) and reduce the crash rate. We could introduce
> HasCaughtOrTerminated() if it helps to reduce the crash rate, but I want to
> make sure that assumption is correct. My intuition is that it will be more
> useful to identify places that may call scripts often and insert the
> termination checks if missing.
>

I'd similarly like to understand how much this happens in practice.


> A proposed solution looks like the following.
>>
>> v8::TryCatch try_catch(isolate);
>> // ...
>> if (try_catch.*HasCaughtOrTerminated*()) {
>>   v8::Local exception = try_catch.
>> *CaughtExceptionOrTerminationException*();
>>   // Do a job with |exception|.
>>   return;
>> }
>>
>> where HasCaughtOrTerminated returns true when the isolate is terminating
>> even if no exception is thrown inside the TryCatch scope, and
>> CaughtExceptionOrTerminationException returns a thrown exception if an
>> exception is thrown inside the TryCatch scope or the termination exception
>> if the isolate is terminating.
>>
>
As to the problem itself, I have a clarifying questions: doesn't Blink
already have some choke point to determine whether it's "ok to call script
now"? If so that'd be a more natural place to add this handling than
TryCatch.

- Adam


> Cheers,
>> Yuki Shiino
>>
>>
>> 2018年11月8日(木) 17:38 Kentaro Hara :
>>
>>> Thanks, I got it :)
>>>
>>> My proposal would be:
>>>
>>> (a3) Make HasCaught() return true when the isolate is terminated.
>>>
>>> I'm not sure if (a) or (a2) is a good idea because the fact that we
>>> didn't call ReThrow() means that we (intentionally) suppressed the
>>> exception. Thoughts?
>>>
>>>
>>>
>>>
>>> On Wed, Nov 7, 2018 at 9:51 PM Yuki Shiino 
>>> wrote:
>>>
 Are you assuming that the worker is terminated while it's calling
> DoSomethingElseWithV8()? If yes, why does HasCaught() not return true? If
> no, what's a problem of continuing execution?


 No, the worker is terminated while DoSomethingWithV8 (without "Else"),
 and Blink continues running more V8 code at DoSomethingElseWithV8.  Two
 pieces of code run consecutively.

 Worker thread (worker isolate):
 {
   v8::TryCatch try_catch(isolate);
   DoSomethingWithV8();  // The Isolate terminates here.
   if (try_catch.HasCaught()) {  // => true due to termination
 // Handle error or termination.
 return;
   }
 }

[v8-users] Re: [blink-dev] Re: [v8-dev] Re: Intent to ship: Intl.ListFormat

[Adam Klein]

LGTM3

On Thu, Nov 8, 2018 at 9:16 AM 'Mathias Bynens' via blink-dev <
blink-...@chromium.org> wrote:

> LGTM2
>
> On Thu, Nov 8, 2018 at 2:44 AM Sathya Gunasekaran 
> wrote:
>
>> LGTM
>>
>> On Thu, Nov 8, 2018 at 12:20 AM Frank Tang  wrote:
>>
>>> Spec
>>>
>>> https://tc39.github.io/proposal-intl-list-format
>>>
>>> Summary
>>>
>>> A Stage 3 proposal that introduces a new formatter under Intl.
>>>
>>> Intl.ListFormat  helps libraries and frameworks format a list in a
>>> localized fashion by providing internationalized messages using a customary
>>> local word or phrase when available. For example, calling its format()
>>> method with ["Alice", "Bob", "Charlie", "Delta"] would return the string
>>> "Alice, Bob, Charlie and Delta" in English.
>>> Example
>>>
>>> let lf = new ListFormat("en");
>>>
>>> lf.format(["Alice"]);
>>>
>>> // > "Alicce"
>>>
>>> lf.format(["Alice", "Bob"]);
>>>
>>> // > "Alice and Bob"
>>>
>>> lf.format(["Alice", "Bob", "Charlie"]);
>>>
>>> // > "Alice, Bob and Charlie"
>>>
>>> lf.format(["Alice", "Bob", "Charlie", "Delta"]);
>>>
>>> // > "Alice, Bob, Charlie and Delta"
>>>
>>> lf = new ListFormat("zh");
>>>
>>> lf.format(["譚永鋒"]);
>>>
>>> // > "譚永鋒"
>>>
>>> lf.format(["譚永鋒", "劉新宇"]);
>>>
>>> // > "譚永鋒和劉新宇"
>>>
>>> Interoperability and compatibility risk
>>>
>>> The Intl.ListFormat is new and should have no risk to break pre-existing
>>> javascript code.
>>>
>>>-
>>>
>>>Firefox:In development
>>>-
>>>
>>>Edge:No public signals
>>>-
>>>
>>>Safari:No public signals
>>>-
>>>
>>>Web Developers: No public signals
>>>
>>>
>>> Is this feature fully tested?
>>>
>>> Yes; our implementation passes our own V8 tests as well as the Test262
>>> tests for all the features.
>>>
>>> Tracking bug
>>>
>>> https://crbug.com/v8/7871
>>>
>>> Link to entry on the Chrome Platform Status dashboard
>>>
>>> https://www.chromestatus.com/features/4764538272481280
>>>
>>> Requesting approval to ship?
>>>
>>> Yes. Note that since this is a V8/JS feature, this post is just an FYI
>>> to blink-dev — no signoff from Blink API owners is required.
>>>
>>>
>>> --
>> --
>> v8-dev mailing list
>> v8-...@googlegroups.com
>> http://groups.google.com/group/v8-dev
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to v8-dev+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADizRgYSZ0q81co3mW60DypEJZ%2B0GMdM_yphJa4_YcWRfvx-ZQ%40mail.gmail.com
> 
> .
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Intent to Ship: Public class fields

[Adam Klein]

LGTM. I'm super-excited about this shipping!

On Wed, Oct 17, 2018 at 9:47 AM Sathya Gunasekaran 
wrote:

> Contact Emails:
> gsat...@chromium.org
>
> Spec:
> https://github.com/tc39/proposal-class-fields
> https://tc39.github.io/proposal-static-class-features/
>
> The linked proposal includes private fields, but this intent to ship
> is only for public instance and static fields, not private fields.
>
> Summary:
> Public class fields build upon the class syntax introduced in ES2015
> by allowing declaration of both instance and static public fields.
>
> The following ES2015 syntax:
>
> class IncreasingCounter {
>   constructor() {
> this._count = 0;
>   }
>   get value() {
> return this._count;
>   }
>   increment() {
> this._count++;
>   }
> }
>
> can now be rewritten as:
>
> class IncreasingCounter {
>   _count = 0;
>
>   get value() {
> return this._count;
>   }
>   increment() {
> this._count++;
>   }
> }
>
> Interoperability and compatibility risk:
> This syntax was previously a Syntax error, therefore there is very low
> web compat risk.
>
> There's one very minor spec non compliance in the current
> implementation around the class name during static field
> initialization (https://github.com/tc39/proposal-class-fields/issues/85)
> which needs to be discussed at the next TC39 meeting.
>
> Firefox: In development  (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1499448)
> Safari: In development (https://bugs.webkit.org/show_bug.cgi?id=174212)
> Edge: No signal
>
> Is this feature fully tested?
> V8 tests (mjsunit, cctest/test-parsing) as well as all test262 tests
> pass for this feature.
>
> Chromestatus entry:
> https://www.chromestatus.com/feature/6001727933251584
>
> Requesting approval to ship?
> Yes. Note that since this is a V8/JS feature, this post is just an FYI
> to blink-dev — no signoff from Blink API owners is required.
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMd%2BM7w_4-eJufKNB3gBzj2EsZUng0VD%3DmzbPmBr7q_-zn-yFw%40mail.gmail.com
> .
>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to ship: well-formed JSON.stringify

[Adam Klein]

LGTM

On Wed, Oct 3, 2018 at 8:09 AM 'Mathias Bynens' via v8-users <
v8-users@googlegroups.com> wrote:

> Contact emails
>
> math...@chromium.org
>
> Spec
>
> https://github.com/tc39/proposal-well-formed-stringify
>
> Summary
>
> A Stage 3 proposal changes JSON.stringify to prevent it from returning
> ill-formed Unicode strings.
>
> Motivation
>
> RFC 8259 section 8.1 
> requires JSON text exchanged outside the scope of a closed ecosystem to be
> encoded using UTF-8, but JSON.stringify
>  can return strings
> including code points that have no representation in UTF-8 (specifically,
> surrogate code points U+D800 through U+DFFF). And contrary to the
> description of JSON.stringify
> , such strings are
> not “in UTF-16” because “isolated UTF-16 code units in the range
> D800₁₆..DFFF₁₆ are ill-formed” per The Unicode Standard, Version 10.0.0,
> Section 3.4 
> at definition D91 and excluded from being “in UTF-16” per definition D89.
>
> However, returning such invalid Unicode strings is unnecessary, because
> JSON strings can include Unicode escape sequences.
>
> Interoperability and compatibility risk
>
> This change is backwards-compatible, under an assumption of consumer
> compliance with the JSON specification. User-visible effects are limited to
> the replacement of some rare single UTF-16 code units in JSON.stringify
> output with equivalent six-character escape sequences that can be
> represented both in UTF-16 and in UTF-8. Any consumer accepting the current
> ill-formed output is unaffected by this change (this is true in particular
> of ECMAScript JSON.parse). Any consumer rejecting the current ill-formed
> output will have a new opportunity to accept its well-formed
> representation, although such consumers may still reject input that
> specifies strings including Unicode code points that are not scalar values
> (e.g. because they only accept I-JSON
>  input), but those that accept it
> must have mechanisms for dealing with unpaired surrogates (as mentioned in
> the specification of JSON).
>
> This feature has a ready-to-land Firefox/SpiderMonkey implementation
> . There are
> tracking bugs for Edge/Chakra
>  and
> Safari/JavaScriptCore .
>
> Is this feature fully tested?
>
> Yes. In addition to V8’s own tests (
> v8/test/mjsunit/harmony/well-formed-json-stringify*.js and
> v8/test/cctest/test-strings*), Test262 includes tests
> 
> for this feature .
>
> Tracking bug
>
> https://bugs.chromium.org/p/v8/issues/detail?id=7782
>
> Link to entry on the Chrome Platform Status dashboard
>
> https://www.chromestatus.com/feature/5752304045129728
>
> Requesting approval to ship?
>
> Yes. Note that since this is a V8/JS feature, this post is just an FYI to
> blink-dev — no signoff from Blink API owners is required.
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Fwd: Intent to ship: Optimize await and AsyncFromSyncIterator

[Adam Klein]

LGTM2

On Fri, Sep 28, 2018 at 9:39 AM 'Mathias Bynens' via v8-users <
v8-users@googlegroups.com> wrote:

> LGTM
>
> On Fri, Sep 28, 2018 at 9:26 AM Maya Lekova  wrote:
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *Contact emailsmslek...@chromium.org
>> Explainerhttps://docs.google.com/document/d/1kL08cz4lR6gO5b2FATNK3QAfS8t-6K6kdk88U-n8tug/edit?usp=sharing
>> SpecThe
>> ECMAScript specification change reached consensus. Pull request:
>> https://github.com/tc39/ecma262/pull/1250
>> The tag review process is not
>> needed, TC39 consensus was reached instead.SummaryThe goal of this change
>> is to reduce the native “await” functionality to only take 1 tick on the
>> microtask queue instead of 3.Is this feature supported on all six Blink
>> platforms (Windows, Mac, Linux, Chrome OS, Android, and Android
>> WebView)?Yes.RisksInteroperability and CompatibilityEdge: ShippedFirefox:
>> No signalsSafari: No signalsWeb developers: Shouldn’t affect web
>> developers, as most of them transpile away async/await and Babel already
>> ships with the new behaviour.ActivationThe new behaviour won’t affect the
>> way async/await is being used.Is this feature fully tested by
>> web-platform-tests
>> ?Test262
>> tests are being implemented. We have related tests in the V8 repository in
>> test/inspector/debugger.Entry on the feature dashboard
>> Fits under
>> https://www.chromestatus.com/feature/5643236399906816
>> , as this is simply
>> an errata to the spec.*
>> ---
>> Best regards,
>> Maya
>>
>>
>> --
>> --
>> v8-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to v8-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Re: Intent to ship: Intl.RelativeTimeFormat

[Adam Klein]

LGTM2

On Tue, Sep 25, 2018 at 2:35 AM Sathya Gunasekaran 
wrote:

> LGTM
>
> On Mon, Sep 24, 2018 at 5:35 PM Frank Tang  wrote:
>
>> Spec
>>
>> https://tc39.github.io/proposal-intl-relative-time/
>>
>> Summary
>>
>> A Stage 3 proposal that introduces a new formatter under Intl.
>>
>> Intl.RelativeTimeFormat is a low level API to facilitate libraries and
>> frameworks to format relative time in a localized fashion by providing
>> internationalized messages for date and time fields, using customary word
>> or phrase when available.
>> Example
>>
>> let rtf = new Intl.RelativeTimeFormat("en");
>> // Format relative time using the day unit.rtf.format(-1, "day");// > 
>> "yesterday"
>> rtf.format(2.15, "day");// > "in 2.15 days"
>> rtf.format(100, "day");// > "in 100 days"
>> rtf.format(0, "day");// > "today"
>> rtf.format(-0, "day");// > "today"
>>
>> // Format relative time using the day unit.rtf.formatToParts(-1, "day");// > 
>> [{ type: "literal", value: "yesterday"}]
>> rtf.formatToParts(100, "day");// > [{ type: "literal", value: "in " }, { 
>> type: "integer", value: "100", unit: "day" }, { type: "literal", value: " 
>> days" }]
>>
>> Interoperability and compatibility risk
>>
>> The Intl.RelativeTimeFormat is new and should have no risk to break
>> pre-existing javascript code.
>>
>>- Firefox:In development
>>- Edge:No public signals
>>- Safari:No public signals
>>- Web Developers:Positive
>>
>>
>> Is this feature fully tested?
>>
>> Yes; our implementation passes our own V8 tests as well as the Test262
>> tests for all the features.
>>
>> Tracking bug
>>
>> https://crbug.com/v8/7869
>>
>> Link to entry on the Chrome Platform Status dashboard
>>
>> https://www.chromestatus.com/feature/4875177569550336
>>
>> Requesting approval to ship?
>>
>> Yes. Note that since this is a V8/JS feature, this post is just an FYI to
>> blink-dev — no signoff from Blink API owners is required.
>>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to Ship: globalThis

[Adam Klein]

This LGTM, based on the stage at TC39.

It'd be nice if we knew more about other browser plans, given the history
here. Do you know if Firefox has plans to try again with this name anytime
soon?

On Thu, Aug 30, 2018 at 1:24 AM 'Mathias Bynens' via v8-users <
v8-users@googlegroups.com> wrote:

> Contact emails
>
> math...@chromium.org
>
> Spec
>
> https://tc39.github.io/proposal-global/
>
> Summary
>
> A Stage 3 proposal introduces globalThis, enabling a universal mechanism
> to access the global object even in strict functions or modules, regardless
> of the platform.
>
> Motivation
>
> It is difficult to write portable ECMAScript code which accesses the
> global object. On the web, it is accessible as window or self or this or
> frames; on Node.js, it is global or this; among those, only this is
> available in a shell like V8's d8. In a standalone function call in
> sloppy mode, this works too, but it's undefined in modules or in strict
> mode within a function. In such contexts, the global object can still be
> accessed using Function('return this')(), but that form is incompatible
> with some CSP settings, such as within Chrome Apps.
>
> Interoperability and compatibility risk
>
> An earlier version of this proposal had a different name: global. Sadly,
> this name was found to be not Web-compatible when Firefox shipped it
> . After collaborating
> with other browsers vendors and looking at data on real-world use of
> JavaScript identifiers on the web, we believe the new name to be
> Web-compatible.
>
> Is this feature fully tested?
>
> Yes. In addition to V8's own tests (v8/test/mjsunit/harmony/global*.js),
> Test262 includes tests for this feature
> 
> .
>
> Tracking bug
>
> https://bugs.chromium.org/p/v8/issues/detail?id=5537
>
> Link to entry on the Chrome Platform Status dashboard
>
> https://www.chromestatus.com/feature/6571514765770752
>
> Requesting approval to ship?
>
> Yes. Note that since this is a V8/JS feature, this post is just an FYI to
> blink-dev — no signoff from Blink API owners is required.
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Intent to Implement and Ship: rename Intl.DateTimeFormat.prototype.formatToParts type "dayperiod" to "dayPeriod"

[Adam Klein]

Thanks, Jungshik. Based on this feedback I'm comfortable with making this
change without adding a usecounter.

On Fri, Aug 24, 2018 at 11:23 PM  wrote:

> Sorry for the delay as well as for the stupid typo I made in 'dayPeriod'.
> I've been ooo for a while and catching up with emails.
>
> On Tuesday, August 7, 2018 at 9:36:37 PM UTC-7, PhistucK wrote:
>>
>> Comments inline.
>>
>> ☆*PhistucK*
>>
>>
>> On Wed, Aug 8, 2018 at 3:29 AM Adam Klein  wrote:
>>
>>> Apologies for the delay, this got hidden from me due to some gmail
>>> filtering issues...comments inline.
>>>
>>> On Thu, Jul 26, 2018 at 2:14 PM PhistucK  wrote:
>>>
>>>> I misremembered formatToParts as a relatively recent feature, but now
>>>> I see that the intent I remembered was actually discussing NumberFormat.
>>>> DateTimeFormat did not seem to have an intent on blink-dev (but I see
>>>> that it did on v8-users).
>>>> https://www.chromestatus.com/features/6319456309477376 says it is
>>>> still behind a flag... Is the MDN article
>>>> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/formatToParts>
>>>> correct in stating that it was supported in Chrome 57 (and confusingly,
>>>> also behind the flag until Chrome 60)?
>>>>
>>>
>>> Indeed, Chrome 57 looks like the right release (from looking through v8
>>> commits). I've updated that on chromestatus. That is indeed awhile ago.
>>>
>>
>> Thank you.
>>
>
> Yeah. Chrome 57 contained it behind a flag and Chrome 60 began to have it
> by default.
>
>>
>>
>>
>>>
>>>
>>>> Shameless plug - probably a good opportunity to add it to my filtered
>>>> feed scraper and to my RSS reader -
>>>>
>>>> https://frequentfeedscraper.appspot.com/read?feed=v8users_filter=exact:intent
>>>>
>>>> Nevertheless, my intuition (more like a hunch, though) is that this
>>>> specific field is relatively little used, but I may be wrong (the fact that
>>>> my locale does not use it probably makes me biased).
>>>> From seeing all of the polyfills (which already use the standard
>>>> casing) on GitHub (the search yielded a lot of those), I presumed they are
>>>> also used by projects, which might mean those projects probably tested
>>>> their polyfilled implementation as well on Internet Explorer 11 or Safari
>>>> pre-11, so they would have probably seen the casing issue if they did
>>>> something with that particular field (Salesforce worked around it, for
>>>> example).
>>>> However, there is probably a lot of code that is Chrome only (:(), so...
>>>>
>>>
>>> Again, it'd be great to get Jungshik's input on this, since he was the
>>> one who implemented it.
>>>
>>
>> I agree, it would be great if you pinged Jungshik on Hangouts or
>> something and ask Jungshik to follow this thread...
>>
>
> There'd be no worry at all if there were NO Chrome-only-implementation.
>  My wild speculation (with no material basis to support)  is that those who
> write Chrome-only code is less likely to be aware of and to utilize
> EcmaScript Intl API. Alternatively, my hunch is that  those who use Intl
> API  (especially this relatively new API) are pretty likely to care about
> cross-browser compatibility and work around v8's typo (my typo) in this
> field.
>
> formatToParts API is mainly for controlling the style of individual parts
> separately. If the case of 'dayPeriod' is fixed in v8 and does not match
> Chrome-only-code's 'dayperiod' any more, locales using dayPeriod (AM/PM
> marker) would have a wrong style (font size, color, etc) in Chrome ToT, but
> the information will be still there.
>
> Given the above and the fact that a work-around (use case-insensitive
> match or check for both case-variants) is simple,  I'd say we go ahead with
> this change.  Adding a counter to measure the usage seems to be a bit too
> much.
>
> Jungshik
>
>
>>
>>
>>>
>>>
>>>> Is there an option to add a use counter to V8?
>>>> Is there an existing use counter for formatToParts altogether that I
>>>> may have missed (or maybe it is internal)?
>>>>
>>>
>>> It is possible to add use counters to V8. They need to be plumbed
>>> through the API, and then manually updated from V8, so it's more work to
>>> add than it is in Blink, but it's doable. Would you be inter

[v8-users] Re: [blink-dev] Intent to Implement and Ship: rename Intl.DateTimeFormat.prototype.formatToParts type "dayperiod" to "dayPeriod"

['Adam Klein' via v8-users]

Apologies for the delay, this got hidden from me due to some gmail
filtering issues...comments inline.

On Thu, Jul 26, 2018 at 2:14 PM PhistucK  wrote:

> I misremembered formatToParts as a relatively recent feature, but now I
> see that the intent I remembered was actually discussing NumberFormat.
> DateTimeFormat did not seem to have an intent on blink-dev (but I see
> that it did on v8-users).
> https://www.chromestatus.com/features/6319456309477376 says it is still
> behind a flag... Is the MDN article
> <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat/formatToParts>
> correct in stating that it was supported in Chrome 57 (and confusingly,
> also behind the flag until Chrome 60)?
>

Indeed, Chrome 57 looks like the right release (from looking through v8
commits). I've updated that on chromestatus. That is indeed awhile ago.


> Shameless plug - probably a good opportunity to add it to my filtered feed
> scraper and to my RSS reader -
>
> https://frequentfeedscraper.appspot.com/read?feed=v8users_filter=exact:intent
>
> Nevertheless, my intuition (more like a hunch, though) is that this
> specific field is relatively little used, but I may be wrong (the fact that
> my locale does not use it probably makes me biased).
> From seeing all of the polyfills (which already use the standard casing)
> on GitHub (the search yielded a lot of those), I presumed they are also
> used by projects, which might mean those projects probably tested their
> polyfilled implementation as well on Internet Explorer 11 or Safari pre-11,
> so they would have probably seen the casing issue if they did something
> with that particular field (Salesforce worked around it, for example).
> However, there is probably a lot of code that is Chrome only (:(), so...
>

Again, it'd be great to get Jungshik's input on this, since he was the one
who implemented it.


> Is there an option to add a use counter to V8?
> Is there an existing use counter for formatToParts altogether that I may
> have missed (or maybe it is internal)?
>

It is possible to add use counters to V8. They need to be plumbed through
the API, and then manually updated from V8, so it's more work to add than
it is in Blink, but it's doable. Would you be interested in adding such a
counter?


> Also, Node does not have to use V8 anymore, just saying. ;)
>
> ☆*PhistucK*
>
>
> On Thu, Jul 26, 2018 at 7:59 PM Adam Klein  wrote:
>
>> +Jungshik and Dan, who I believe worked on this feature in V8 originally.
>> I'm curious if they know how it happened that this ended up with the wrong
>> capitalization.
>>
>> I appreciate the outreach you've done to fix uses in the wild, but it
>> still scares me a little bit to make such a hard-breaking change,
>> especially for V8-only environments like Node. So I'd also like to get some
>> of your (or Jungshik or Dan's) intuition about how often this particular
>> field is accessed.
>>
>> On Fri, Jul 20, 2018 at 8:56 AM PhistucK  wrote:
>>
>>> (Probably an overkill, but here it goes)
>>>
>>>
>>> Contact emails
>>>
>>> phist...@gmail.com
>>>
>>> Explainer
>>>
>>> No explainer, a specification exists already.
>>>
>>> Spec
>>> https://tc39.github.io/ecma402/#sec-partitiondatetimepattern
>>>
>>> Summary
>>>
>>> This change corrects a non-compliant type value in the formatToParts
>>> implementation.
>>>
>>>
>>> > new Intl.DateTimeFormat("en-us", {hour12: true, hour:
>>> "numeric"}).formatToParts()
>>>
>>> [{"type": "hour", "value": "6"}, {"type": "literal", "value": " "},
>>> {"type": "day*p*eriod", "value": "PM"}]
>>>
>>>
>>> Will change to -
>>>
>>> [{"type": "hour", "value": "6"}, {"type": "literal", "value": " "},
>>> {"type": "day*P*eriod", "value": "PM"}]
>>>
>>>
>>> Motivation
>>>
>>> Compliance with the standards and other browsers and likely most of the
>>> code that is already out there.
>>>
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> Compatibility risk - small to medium at worst.
>>>
>>>
>>> Searched GitHub (not exhaustive, but some indication) for dayperiod 
>>> instances
>>> -
>>>

[v8-users] Re: [blink-dev] Intent to Implement and Ship: rename Intl.DateTimeFormat.prototype.formatToParts type "dayperiod" to "dayPeriod"

[Adam Klein]

+Jungshik and Dan, who I believe worked on this feature in V8 originally.
I'm curious if they know how it happened that this ended up with the wrong
capitalization.

I appreciate the outreach you've done to fix uses in the wild, but it still
scares me a little bit to make such a hard-breaking change, especially for
V8-only environments like Node. So I'd also like to get some of your (or
Jungshik or Dan's) intuition about how often this particular field is
accessed.

On Fri, Jul 20, 2018 at 8:56 AM PhistucK  wrote:

> (Probably an overkill, but here it goes)
>
>
> Contact emails
>
> phist...@gmail.com
>
> Explainer
>
> No explainer, a specification exists already.
>
> Spec
> https://tc39.github.io/ecma402/#sec-partitiondatetimepattern
>
> Summary
>
> This change corrects a non-compliant type value in the formatToParts
> implementation.
>
>
> > new Intl.DateTimeFormat("en-us", {hour12: true, hour:
> "numeric"}).formatToParts()
>
> [{"type": "hour", "value": "6"}, {"type": "literal", "value": " "},
> {"type": "day*p*eriod", "value": "PM"}]
>
>
> Will change to -
>
> [{"type": "hour", "value": "6"}, {"type": "literal", "value": " "},
> {"type": "day*P*eriod", "value": "PM"}]
>
>
> Motivation
>
> Compliance with the standards and other browsers and likely most of the
> code that is already out there.
>
>
> Risks
>
> Interoperability and Compatibility
>
> Compatibility risk - small to medium at worst.
>
>
> Searched GitHub (not exhaustive, but some indication) for dayperiod instances
> -
>
> https://github.com/search?l==1=formatToParts+dayperiod+language%3AJavaScript=Code
>
> The vast majority are polyfills that use dayPeriod already, or code that
> uses type.toLowerCase() to bridge over the differences.
>
>
> Sent pull requests to the few cases that were plain wrong -
> https://github.com/sensu/sensu-go/pull/1852
> https://github.com/brave/browser-laptop/pull/14790
> https://github.com/ray007/js-misc/pull/1
> https://github.com/OriginalNexus/venture/pull/1
> https://github.com/ua9msn/datetime/pull/9
>
>
> Interoperability risk - none.
>
>
> Edge: No signals
>
> Firefox: Shipped
>
> Safari: Shipped
>
> Web developers: No signals.
>
>
> Alternatives for web developers
>
> Either check for type === "dayPeriod" || type === "dayperiod", or 
> type.toLowerCase()
> === "dayperiod".
>
> Ergonomics
>
> Irrelevant.
>
> Activation
>
> Irrelevant.
>
> Debuggability
>
> Already debuggable.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes.
>
> Is this feature fully tested by web-platform-tests
> 
> ?
>
> Nope, but it is tested by test262, though not this case (which is
> apparently why the interoperability issue exists).
>
> *I submitted a test262 pull request to maintain interoperability -*
> *https://github.com/tc39/test262/pull/1645
> *
>
>
> Bug and proposed change list -
>
> https://crbug.com/865351
>
> https://chromium-review.googlesource.com/c/v8/v8/+/1145304
>
>
> Link to entry on the feature dashboard 
> https://www.chromestatus.com/features/5252265900244992
>
> Requesting approval to ship?
>
> Yes. I think so. Do you think a deprecation period is warranted? There is
> no (public?) use counter for formatToParts.
>
>
> ☆*PhistucK*
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2B1xEoNvCtuc4ocTw%3DtLmfHmT-z-cFTuiE6YS9Q_MdPqg%40mail.gmail.com
> 
> .
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to Ship: Numeric separators

[Adam Klein]

There's a possible conflict between this feature and another proposal, Extended
Numeric Literals
. The issue,
https://github.com/tc39/proposal-extended-numeric-literals/issues/7, should
be addressed at next week's TC39 meeting, and I'd like to see it settled
before shipping this in V8.

On Thu, Mar 15, 2018 at 5:02 PM, Sathya Gunasekaran 
wrote:

> Note that this is a v8/JavaScript feature, so this post is just an FYI for
> blink-dev — no sign-off from Blink API owners is required.
>
> Contact Emails:
> gsat...@chromium.org
> b...@b6n.ch
>
> Spec:
> https://tc39.github.io/proposal-numeric-separator/
>
> Summary:
> This feature enables developers to make their numeric literals more
> readable by creating a visual separation between groups of digits. Using
> underscores (_, U+005F) as separators helps improve readability for numeric
> literals, for ex: 1_000_000_000.
>
> Interoperability and Compatibility Risk:
> This is a Stage3 feature in the TC39 process. Previously this was a
> SyntaxError so there is no compat risk.
>
> Safari and Edge have not implemented this feature. This is under
> development in Firefox.
>
> V8 tests as well as test262 tests pass.
>
> Tracking bug:
> https://bugs.chromium.org/p/v8/issues/detail?id=7317
>
> Chromestatus entry:
> https://www.chromestatus.com/feature/5829906369871872
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to ship: BigInt, BigInt64Array, BigUint64Array

[Adam Klein]

LGTM for V8!

On Fri, Mar 2, 2018 at 11:25 AM, Jakob Kummerow 
wrote:

> Note that this is a v8/JavaScript feature, so this post is just an FYI for
> blink-dev — no signoff from Blink API owners is required.
>
>
> *Contact emails*
>
> jkumme...@chromium.org, n...@chromium.org
>
>
> *Explainer*
>
> https://github.com/tc39/proposal-bigint/blob/master/README.md
>
>
> *Spec*
>
> https://tc39.github.io/proposal-bigint
>
>
> *Summary*
>
> This proposal brings arbitrary-precision integers to JavaScript, along
> with new TypedArrays with signed and unsigned 64-bit integer elements.
>
>
> *Is this feature supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?*
>
> Yes.
>
>
> *Debuggability*
>
> As of this writing, DevTools support is being worked on. It will be
> available before shipping.
>
> All the usual DevTools features will work for code containing BigInts.
>
>
> *Interoperability risk*
>
> Edge: No public signals
>
> Firefox: In development: https://bugzilla.mozilla.org/
> show_bug.cgi?id=1366287
>
> Safari: In development: https://bugs.webkit.org/show_bug.cgi?id=179001
>
> Web developers: Positive, e.g. https://github.com/tc39/
> proposal-bigint/issues/53
>
>
> *Compatibility risk*
>
> BigInt literals were invalid syntax before.
>
> The "BigInt", "BigInt64Array", "BigUint64Array" constructors could clash
> with user-defined globals.
>
>
> *Activation risk*
>
> The semantics of the BigInt proposal are not polyfillable (it would
> require operator overloading).
>
>
> *Tests*
>
> test262 contains tests for BigInt, BigInt64Array, BigUintArray, which V8
> passes.
>
> V8 also has its own tests: https://chromium.googlesource.
> com/v8/v8/+/master/test/mjsunit/harmony/bigint
>
>
> *Tracking bug*
>
> crbug.com/v8/6791
>
>
> *Entry on the feature dashboard*
>
> https://www.chromestatus.com/features/5371603852460032
>
>
> *Requesting approval to ship?*
>
> Yes.
>
> We would like to ship BigInts on ToT in ~3 weeks, in time for Chrome 67.
>
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to ship: String.prototype.trimStart / String.prototype.trimEnd

[Adam Klein]

LGTM3!

On Fri, Feb 9, 2018 at 12:52 PM, Sathya Gunasekaran 
wrote:

> LGTM
>
> On Fri, Feb 9, 2018 at 8:36 AM, Benedikt Meurer 
> wrote:
>
>> LGTM
>>
>>
>> Mathias Bynens  schrieb am Fr., 9. Feb. 2018,
>> 16:36:
>>
>>> Contact emails math...@chromium.org Spec https://github.com/tc39/propos
>>> al-string-left-right-trim Summary Until now,
>>> String.prototype.{trimLeft,trimRight} were non-standard language
>>> extensions, required for Web compatibility. The Stage 3 proposal at
>>> https://github.com/tc39/proposal-string-left-right-trim standardizes
>>> this functionality as String.prototype.{trimStart,trimEnd}, and defines
>>> String.prototype.{trimLeft,trimRight} as aliases for backwards
>>> compatibility. Vendor signals Firefox: Public support Edge: Public
>>> support Safari: In development Web developers: Positive Compatibility
>>> risk
>>> There could be a compatibility risk, but that seems unlikely. We won’t
>>> know for sure until we try shipping it. Ongoing technical constraints
>>> None Will this feature be supported on all six Blink platforms
>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>>> Yes
>>> Tracking bug
>>> https://bugs.chromium.org/p/v8/issues/detail?id=6530 Link to entry on
>>> the Chrome Platform Status https://www.chromestatus.com/f
>>> eatures/479006651936 Requesting approval to ship? Yes
>>>
>>> Note that since this is a V8/JS feature, this post is just an FYI to
>>> blink-dev — no signoff from Blink API owners is required.
>>>
>>> --
>>> --
>>> v8-users mailing list
>>> v8-users@googlegroups.com
>>> http://groups.google.com/group/v8-users
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "v8-users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to v8-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>>
>>
>>
>> * •  *
>> *Benedikt Meurer** •  **Google Germany GmbH*
>> * •  *Erika-Mann-Str. 33
>> 
>> * •
>> *80636
>> Munich
>> 
>>
>>  •
>> 
>> bmeu...@google.com
>>
>>
>> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
>>
>> Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft:
>> Hamburg
>>
>> Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind,
>> leiten Sie diese bitte nicht weiter, informieren Sie den Absender und
>> löschen Sie die E-Mail und alle Anhänge. Vielen Dank. This e-mail is
>> confidential. If you are not the right addressee please do not forward it,
>> please inform the sender, and please erase this e-mail including any
>> attachments. Thanks.
>>
>> --
>> --
>> v8-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to v8-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [blink-dev] Re: [v8-users] Intent to Ship: Optional catch binding

[Adam Klein]

There's been discussion of doing that, but nothing official has changed
(yet). +hablich, as I believe this is on his plate at the moment.

On Fri, Jan 26, 2018 at 12:37 AM, Jochen Eisinger <joc...@chromium.org>
wrote:

> I thought V8 wanted to use the blink process nowadays?
>
> On Thu, Jan 18, 2018 at 10:32 PM Adam Klein <ad...@chromium.org> wrote:
>
>> LGTM!
>>
>> Note that this is a v8/JavaScript feature, so this is just an FYI for
>> blink-dev at the moment.
>>
>> On Thu, Jan 18, 2018 at 12:19 PM, Sathya Gunasekaran <
>> gsat...@chromium.org> wrote:
>>
>>> Contact Emails:
>>> gsat...@chromium.org
>>> bak...@gmail.com
>>>
>>> Spec:
>>> https://tc39.github.io/proposal-optional-catch-binding/
>>>
>>> Summary:
>>> This proposal allows developers to use try/catch without creating an
>>> unused binding.
>>>
>>> Interoperability and Compatibility Risk:
>>> This is a stage3 feature. Previously not having a binding was an error,
>>> so there's no compat risk.
>>>
>>> Firefox 58 Beta and Safari Tech Preview 37 ship this feature. Edge has
>>> not implemented this yet.
>>>
>>> V8 tests as well as test262 tests pass.
>>>
>>> Tracking bug:
>>> https://bugs.chromium.org/p/v8/issues/detail?id=6889
>>>
>>> Chromestatus entry:
>>> https://www.chromestatus.com/features/5810795665424384
>>>
>>> --
>>> --
>>> v8-users mailing list
>>> v8-users@googlegroups.com
>>> http://groups.google.com/group/v8-users
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "v8-users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to v8-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To view this discussion on the web visit https://groups.google.com/a/
>> chromium.org/d/msgid/blink-dev/CAEvLGcJL74s7xeQLU%
>> 2BMC3MCYoUnyKzSLGF5-Jhbo5%2BJj9i%2B3iQ%40mail.gmail.com
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEvLGcJL74s7xeQLU%2BMC3MCYoUnyKzSLGF5-Jhbo5%2BJj9i%2B3iQ%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to Ship: Optional catch binding

[Adam Klein]

LGTM!

Note that this is a v8/JavaScript feature, so this is just an FYI for
blink-dev at the moment.

On Thu, Jan 18, 2018 at 12:19 PM, Sathya Gunasekaran 
wrote:

> Contact Emails:
> gsat...@chromium.org
> bak...@gmail.com
>
> Spec:
> https://tc39.github.io/proposal-optional-catch-binding/
>
> Summary:
> This proposal allows developers to use try/catch without creating an
> unused binding.
>
> Interoperability and Compatibility Risk:
> This is a stage3 feature. Previously not having a binding was an error, so
> there's no compat risk.
>
> Firefox 58 Beta and Safari Tech Preview 37 ship this feature. Edge has not
> implemented this yet.
>
> V8 tests as well as test262 tests pass.
>
> Tracking bug:
> https://bugs.chromium.org/p/v8/issues/detail?id=6889
>
> Chromestatus entry:
> https://www.chromestatus.com/features/5810795665424384
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Re: Intent to ship: Unicode property escapes in regular expressions

[Adam Klein]

LGTM (for v8 signoff purposes).

On Thu, Nov 9, 2017 at 1:38 PM, 'Mathias Bynens' via blink-dev <
blink-...@chromium.org> wrote:

> Note that since this is a V8/JS feature, this post is just an FYI to
> blink-dev — no signoff from Blink API owners is required.
>
> On Thu, Nov 9, 2017 at 10:29 PM, Mathias Bynens 
> wrote:
>
>> Contact emails
>>
>> yang...@chromium.org, math...@chromium.org
>>
>> Spec
>>
>> https://github.com/tc39/proposal-regexp-unicode-property-escapes (stage
>> 3 proposal)
>>
>> Summary
>>
>> The Unicode Standard assigns various properties and property values to
>> every symbol. For example, to get the set of symbols that are used
>> exclusively in the Greek script, search the Unicode database for symbols
>> whose Script property is set to Greek.
>>
>> Unicode property escapes are a new type of escape sequence available in
>> regular expressions that have the u flag set. They enable querying the
>> Unicode database for certain properties and values.
>>
>> E.g. /\p{Script=Greek}/u.test('π') === true
>>
>> Link to “Intent to Implement” blink-dev discussion
>>
>> There was none.
>>
>> Is this feature supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, Android, and Android WebView)?
>>
>> Yes.
>>
>> Demo link
>>
>> None. The explainer in the proposal offers some examples.
>>
>> Interoperability and Compatibility Risk
>>
>> In regular expressions without the u flag, the pattern \p is an
>> (unnecessary) escape sequence for p. Patterns of the form \p{Letter}
>> might already be present in existing regular expressions without the u
>> flag, and therefore we cannot assign new meaning to such patterns without
>> breaking backwards compatibility.
>>
>> For this reason, ECMAScript 2015 made unnecessary escape sequences like
>> \p and \P throw an exception when the u flag is set. This enables us to
>> change the meaning of \p{…} and \P{…} in regular expressions with the u
>> flag without breaking backwards compatibility.
>>
>>
>>-
>>
>>Edge/Chakra: public support; tracking issue:
>>https://github.com/Microsoft/ChakraCore/issues/2969
>>
>>-
>>
>>Firefox/SpiderMonkey: public support; tracking issue:
>>https://bugzilla.mozilla.org/show_bug.cgi?id=1361876
>>
>>-
>>
>>Safari/JavaScriptCore: shipped in Safari Technical Preview 42;
>>tracking issue: https://bugs.webkit.org/show_bug.cgi?id=172069
>>-
>>
>>Web developers: positive signals
>>
>>
>> Is this feature fully tested?
>>
>> Yes. In addition to V8’s own tests (v8/test/mjsunit/harmony/regex
>> p-property-*.js), Test262 includes tests for this feature
>> 
>> .
>>
>> OWP launch tracking bug
>>
>> https://bugs.chromium.org/p/v8/issues/detail?id=4743
>>
>> Entry on the feature dashboard 
>>
>> https://www.chromestatus.com/features/6706900393525248
>>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To view this discussion on the web visit https://groups.google.com/a/
> chromium.org/d/msgid/blink-dev/CADizRgbnTY1wLi6ZrF4_w74-
> PyZSgZgUruJrP4Q6-O1i5t6aMg%40mail.gmail.com
> 
> .
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [blink-dev] Re: [v8-users] Intent to Ship: Intl.PluralRules

[Adam Klein]

Thanks, with that background this LGTM to ship.

On Tue, Sep 12, 2017 at 2:35 PM, Daniel Ehrenberg <little...@chromium.org>
wrote:

> I asked Zbigniew Braniecki about the status of
> Intl.NumberFormat.prototype.formatToParts and PluralRules, and he told
> me,
>
> > Both are ready and need to be exposed. We've been waiting for them to
> reach stage 4 to expose them to the Web
> > NumberFormat.formatToParts is behind the flag -
> http://searchfox.org/mozilla-central/source/js/src/builtin/Intl.cpp#1639
> > and PluralRules is exposed on mozIntl (which is our chrome-only API for
> UI internationalization that extends Intl API) -
> http://searchfox.org/mozilla-central/source/toolkit/
> components/mozintl/mozIntl.js#73
> > With you guys having land both I think we can expose them now. I'm happy
> to work on the patch next week :)
>
> In particular, Mozilla has been pushing these proposals for some time,
> and has been held back by lack of buy-in from other browser vendors.
>
> Dan
>
> On Tue, Sep 12, 2017 at 9:45 AM,  <m_k...@ga2.so-net.ne.jp> wrote:
> > This implementation is for SpiderMoneky shell only with
> addIntlExtras(Intl).
> > It isn't available on Gecko yet.
> >
> > -- Makoto Kato
> >
> > 2017年9月12日火曜日 6時30分27秒 UTC+9 Adam Klein:
> >>
> >> Thanks, from the spec-stabilization side this sounds fine to me.
> >>
> >> Given that we'd be first to ship, I wonder if you have any more
> background
> >> on the Firefox status: the intent lists it as "in development" there,
> but
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=1270146 has been closed,
> and
> >> says it's "Fixed in Firefox 53". But I'm running Firefox 55 locally and
> I
> >> don't see it shipped there.
> >>
> >> On Sun, Sep 10, 2017 at 10:17 AM, Daniel Ehrenberg <
> litt...@chromium.org>
> >> wrote:
> >>>
> >>> +blink-dev
> >>>
> >>> On Sun, Sep 10, 2017 at 7:16 PM, Daniel Ehrenberg
> >>> <litt...@chromium.org> wrote:
> >>> > ECMA 402 (Intl) tracks its proposals separately. You can see it
> listed
> >>> > as Stage 3 at https://github.com/tc39/ecma402/ . There is a full
> >>> > implementation in Firefox behind a flag. I'd say this spec is pretty
> >>> > stable.
> >>> >
> >>> > Dan
> >>> >
> >>> > On Fri, Sep 8, 2017 at 7:39 PM, Adam Klein <ad...@chromium.org>
> wrote:
> >>> >> What's the stability state of the spec? I don't see it on
> >>> >> https://github.com/tc39/proposals
> >>> >>
> >>> >> On Fri, Sep 8, 2017 at 9:41 AM, Josh Wolfe <jwo...@igalia.com>
> wrote:
> >>> >>>
> >>> >>> # Contact emails
> >>> >>>
> >>> >>> jwo...@igalia.com
> >>> >>> litt...@chromium.org
> >>>
> >>> >>>
> >>> >>> # Spec
> >>> >>>
> >>> >>> https://rawgit.com/caridy/intl-plural-rules-spec/master/index.html
> >>> >>>
> >>> >>> # Summary
> >>> >>>
> >>> >>> Intl.PluralRules is a new API which exposes language-dependent data
> >>> >>> on
> >>> >>> pluralization forms of numbers. Given a locale and a number,
> >>> >>> Intl.PluralRules outputs a category, which can then be used for
> >>> >>> selection of the pluralization form of surrounding text.
> >>> >>>
> >>> >>> # Motivation
> >>> >>>
> >>> >>> In English, 101st ends with "st" while 111th ends with "th". The
> >>> >>> algorithm
> >>> >>> for
> >>> >>> determining the proper ordinal suffix is non-trivial and locale
> >>> >>> specific.
> >>> >>> A
> >>> >>> proper international solution is implemented in ICU, and
> >>> >>> Intl.PluralRules
> >>> >>> exposes this solution to JavaScript developers.
> >>> >>>
> >>> >>> # Interoperability risk
> >>> >>>
> >>> >>> * Firefox: In development
> >>> >>> * Edge: No public signals
> >>> >>> * Safari: No public signals
> >>> >>> * Web developers: Positive
> >>&g

Re: [blink-dev] Re: [v8-users] Intent to Ship: Intl.NumberFormat.prototype.formatToParts

[Adam Klein]

Thanks, with that background this LGTM to ship.

On Tue, Sep 12, 2017 at 2:35 PM, Daniel Ehrenberg <little...@chromium.org>
wrote:

> I asked Zbigniew Braniecki about the status of
> Intl.NumberFormat.prototype.formatToParts and PluralRules, and he told
> me,
>
> > Both are ready and need to be exposed. We've been waiting for them to
> reach stage 4 to expose them to the Web
> > NumberFormat.formatToParts is behind the flag -
> http://searchfox.org/mozilla-central/source/js/src/builtin/Intl.cpp#1639
> > and PluralRules is exposed on mozIntl (which is our chrome-only API for
> UI internationalization that extends Intl API) -
> http://searchfox.org/mozilla-central/source/toolkit/
> components/mozintl/mozIntl.js#73
> > With you guys having land both I think we can expose them now. I'm happy
> to work on the patch next week :)
>
> In particular, Mozilla has been pushing these proposals for some time,
> and has been held back by lack of buy-in from other browser vendors.
>
> Dan
>
> On Mon, Sep 11, 2017 at 11:32 PM, Adam Klein <ad...@chromium.org> wrote:
> > I have the same question here as my latest question on the PluralRules
> > thread: any idea why Firefox isn't shipping this (yet), given they have
> it
> > implemented?
> >
> > On Sun, Sep 10, 2017 at 2:03 PM, Josh Wolfe <jwo...@igalia.com> wrote:
> >>
> >> # Contact emails
> >>
> >> jwo...@igalia.com
> >> little...@chromium.org
> >>
> >> # Spec
> >>
> >> https://github.com/tc39/ecma402/pull/79
> >>
> >> # Summary
> >>
> >> Intl.NumberFormat.prototype.formatToParts() is scheduled to be added to
> >> the
> >> EcmaScript Internationalization API specification (Ecma 402). It adds a
> >> method
> >> to format a number to a list of tokens and their types (e.g. minusSign,
> >> integer,
> >> decimal, fraction, currency, percentSign, etc). It is implemented and
> >> disabled
> >> by default by Firefox. v8 implemented it behind a flag. See also, the
> >> corresponding DateTimeFormat feature here:
> >> https://www.chromestatus.com/feature/6319456309477376
> >>
> >> # Motivation
> >>
> >> A web form may want to display a price like "$1,234.00" with the
> >> fractional
> >> part ".00" in superscript and in a different color. If you use
> >> Intl.NumberFormat.prototype.format(), you get a string, which you would
> >> then
> >> need to parse to find the fractional part. However, the decimal
> separator
> >> is
> >> locale dependent, so attempting to account for this variability somewhat
> >> defeats the purpose of the locale-independent NumberFormat API. The
> >> solution is
> >> to expose the individual parts of the formatted string with tags to
> >> identify
> >> each part's role in the overall representation.
> >>
> >> # Interoperability risk
> >>
> >> * Firefox: In development
> >> * Edge: No public signals
> >> * Safari: No public signals
> >> * Web developers: No signals
> >>
> >> # Compatibility risk
> >>
> >> Low compatibility risk, as this feature is exposed through a new method
> >> `Intl.NumberFormat.prototype.formatToParts`.
> >>
> >> # Ongoing technical constraints
> >>
> >> None
> >>
> >> # Will this feature be supported on all six Blink platforms (Windows,
> Mac,
> >> Linux, Chrome OS, Android, and Android WebView)?
> >>
> >> Yes
> >>
> >> # OWP launch tracking bug
> >>
> >> https://bugs.chromium.org/p/v8/issues/detail?id=5244
> >>
> >> # Link to entry on the Chrome Platform Status
> >>
> >> https://www.chromestatus.com/feature/5686840812109824
> >>
> >> --
> >> --
> >> v8-users mailing list
> >> v8-users@googlegroups.com
> >> http://groups.google.com/group/v8-users
> >> --- You received this message because you are subscribed to the Google
> >> Groups "v8-users" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to v8-users+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >
> >
> > --
> > --
> > v8-users mailing list
> > v8-users@googlegroups.com
> > http://groups.google.com/group/v8-users
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "v8-users" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to v8-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To view this discussion on the web visit https://groups.google.com/a/
> chromium.org/d/msgid/blink-dev/CAKtSNYMPZe0y3M0%2BFWi%3DOzZskMBaqLPro%
> 3DrnfubC7emyUzHqNw%40mail.gmail.com.
>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Intent to Ship: Async Iteration / Async Generators

[Adam Klein]

LGTM!

On Tue, Sep 12, 2017 at 9:48 AM, Caitlin Potter  wrote:

> *Contact Emails*
>
> ca...@chromium.org
>
> *Spec*
>
> https://tc39.github.io/proposal-async-iteration/
>
> *Summary*
>
> Async Generators and the new Async Iteration protocol provide tools for
> implementing and consuming data sources not synchronously available in
> their
> entirety. A common use-case is to wrap ReadableStreams for consumption via
> `for-await-of` loops (example: https://jakearchibald.com/2017/async-
> iterators-and-generators/).
>
> *Motivation*
>
> Promises and Streams are a part of the platform, both from the perspective
> of the world-wide-web,
> and from the perspective of Node.js. This feature provides a streamlined,
> readable interface for
> interacting with complex platform tools, and enables developers to more
> easily implement
> complex schemes which cannot run synchronously.
>
> *Interoperability risk*
>
> * Firefox: In development
> * Edge: Public support
> * Safari: In development
> * Web developers: No signals
>
> *Compatibility risk*
>
> Low compatibility risk. There is some risk due to Babel's shipment of an
> incorrect implementation of
> the standard, and the complexity of feature-testing. That said, the
> feature has been staged for several
> weeks now, and content creators most at risk of running into compatibility
> risks would have likely
> encountered them by now during this period.
>
> *Ongoing technical constraints*
>
> None (granted, more work is likely needed to reduce the overhead of the
> feature on low-end devices)
>
> *Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?*
>
> Yes
>
> *OWP launch tracking bug*
>
> 
> https://bugs.chromium.org/p/v8/issues/detail?id=5855
>
> *Link to entry on the Chrome Platform Status*
>
> https://www.chromestatus.com/feature/5727385018171392
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To view this discussion on the web visit https://groups.google.com/a/
> chromium.org/d/msgid/blink-dev/7DFC3057-2841-4B25-9568-
> FB896C162F20%40chromium.org
> 
> .
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to Ship: Intl.NumberFormat.prototype.formatToParts

[Adam Klein]

I have the same question here as my latest question on the PluralRules
thread: any idea why Firefox isn't shipping this (yet), given they have it
implemented?

On Sun, Sep 10, 2017 at 2:03 PM, Josh Wolfe  wrote:

> # Contact emails
>
> jwo...@igalia.com
> little...@chromium.org
>
> # Spec
>
> https://github.com/tc39/ecma402/pull/79
>
> # Summary
>
> Intl.NumberFormat.prototype.formatToParts() is scheduled to be added to
> the
> EcmaScript Internationalization API specification (Ecma 402). It adds a
> method
> to format a number to a list of tokens and their types (e.g. minusSign,
> integer,
> decimal, fraction, currency, percentSign, etc). It is implemented and
> disabled
> by default by Firefox. v8 implemented it behind a flag. See also, the
> corresponding DateTimeFormat feature here:
> https://www.chromestatus.com/feature/6319456309477376
>
> # Motivation
>
> A web form may want to display a price like "$1,234.00" with the fractional
> part ".00" in superscript and in a different color. If you use
> Intl.NumberFormat.prototype.format(), you get a string, which you would
> then
> need to parse to find the fractional part. However, the decimal separator
> is
> locale dependent, so attempting to account for this variability somewhat
> defeats the purpose of the locale-independent NumberFormat API. The
> solution is
> to expose the individual parts of the formatted string with tags to
> identify
> each part's role in the overall representation.
>
> # Interoperability risk
>
> * Firefox: In development
> * Edge: No public signals
> * Safari: No public signals
> * Web developers: No signals
>
> # Compatibility risk
>
> Low compatibility risk, as this feature is exposed through a new method
> `Intl.NumberFormat.prototype.formatToParts`.
>
> # Ongoing technical constraints
>
> None
>
> # Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
> # OWP launch tracking bug
>
> https://bugs.chromium.org/p/v8/issues/detail?id=5244
>
> # Link to entry on the Chrome Platform Status
>
> https://www.chromestatus.com/feature/5686840812109824
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> --- You received this message because you are subscribed to the Google
> Groups "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [blink-dev] Re: [v8-users] Intent to Ship: Intl.PluralRules

[Adam Klein]

Thanks, from the spec-stabilization side this sounds fine to me.

Given that we'd be first to ship, I wonder if you have any more background
on the Firefox status: the intent lists it as "in development" there, but
https://bugzilla.mozilla.org/show_bug.cgi?id=1270146 has been closed, and
says it's "Fixed in Firefox 53". But I'm running Firefox 55 locally and I
don't see it shipped there.

On Sun, Sep 10, 2017 at 10:17 AM, Daniel Ehrenberg <little...@chromium.org>
wrote:

> +blink-dev
>
> On Sun, Sep 10, 2017 at 7:16 PM, Daniel Ehrenberg
> <little...@chromium.org> wrote:
> > ECMA 402 (Intl) tracks its proposals separately. You can see it listed
> > as Stage 3 at https://github.com/tc39/ecma402/ . There is a full
> > implementation in Firefox behind a flag. I'd say this spec is pretty
> > stable.
> >
> > Dan
> >
> > On Fri, Sep 8, 2017 at 7:39 PM, Adam Klein <ad...@chromium.org> wrote:
> >> What's the stability state of the spec? I don't see it on
> >> https://github.com/tc39/proposals
> >>
> >> On Fri, Sep 8, 2017 at 9:41 AM, Josh Wolfe <jwo...@igalia.com> wrote:
> >>>
> >>> # Contact emails
> >>>
> >>> jwo...@igalia.com
> >>> little...@chromium.org
> >>>
> >>> # Spec
> >>>
> >>> https://rawgit.com/caridy/intl-plural-rules-spec/master/index.html
> >>>
> >>> # Summary
> >>>
> >>> Intl.PluralRules is a new API which exposes language-dependent data on
> >>> pluralization forms of numbers. Given a locale and a number,
> >>> Intl.PluralRules outputs a category, which can then be used for
> >>> selection of the pluralization form of surrounding text.
> >>>
> >>> # Motivation
> >>>
> >>> In English, 101st ends with "st" while 111th ends with "th". The
> algorithm
> >>> for
> >>> determining the proper ordinal suffix is non-trivial and locale
> specific.
> >>> A
> >>> proper international solution is implemented in ICU, and
> Intl.PluralRules
> >>> exposes this solution to JavaScript developers.
> >>>
> >>> # Interoperability risk
> >>>
> >>> * Firefox: In development
> >>> * Edge: No public signals
> >>> * Safari: No public signals
> >>> * Web developers: Positive
> >>>
> >>> # Compatibility risk
> >>>
> >>> Low compatibility risk, as this feature is exposed through a new field
> >>> `Intl.PluralRules`.
> >>>
> >>> # Ongoing technical constraints
> >>>
> >>> None
> >>>
> >>> # Will this feature be supported on all six Blink platforms (Windows,
> Mac,
> >>> Linux, Chrome OS, Android, and Android WebView)?
> >>>
> >>> Yes
> >>>
> >>> # OWP launch tracking bug
> >>>
> >>> https://bugs.chromium.org/p/v8/issues/detail?id=5601
> >>>
> >>> # Link to entry on the Chrome Platform Status
> >>>
> >>> https://www.chromestatus.com/features/5653874773852160
> >>>
> >>> --
> >>> --
> >>> v8-users mailing list
> >>> v8-users@googlegroups.com
> >>> http://groups.google.com/group/v8-users
> >>> --- You received this message because you are subscribed to the Google
> >>> Groups "v8-users" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an
> >>> email to v8-users+unsubscr...@googlegroups.com.
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> >> --
> >> --
> >> v8-users mailing list
> >> v8-users@googlegroups.com
> >> http://groups.google.com/group/v8-users
> >> ---
> >> You received this message because you are subscribed to the Google
> Groups
> >> "v8-users" group.
> >> To unsubscribe from this group and stop receiving emails from it, send
> an
> >> email to v8-users+unsubscr...@googlegroups.com.
> >> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To view this discussion on the web visit https://groups.google.com/a/
> chromium.org/d/msgid/blink-dev/CAKtSNYMCovuxGNfgbS427qVfA0Twm
> 5b%3DAnneMKEDaeDMPoJcxA%40mail.gmail.com.
>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to Ship: Intl.PluralRules

[Adam Klein]

What's the stability state of the spec? I don't see it on
https://github.com/tc39/proposals

On Fri, Sep 8, 2017 at 9:41 AM, Josh Wolfe  wrote:

> # Contact emails
>
> jwo...@igalia.com
> little...@chromium.org
>
> # Spec
>
> https://rawgit.com/caridy/intl-plural-rules-spec/master/index.html
>
> # Summary
>
> Intl.PluralRules is a new API which exposes language-dependent data on
> pluralization forms of numbers. Given a locale and a number,
> Intl.PluralRules outputs a category, which can then be used for
> selection of the pluralization form of surrounding text.
>
> # Motivation
>
> In English, 101st ends with "st" while 111th ends with "th". The algorithm
> for
> determining the proper ordinal suffix is non-trivial and locale specific. A
> proper international solution is implemented in ICU, and Intl.PluralRules
> exposes this solution to JavaScript developers.
>
> # Interoperability risk
>
> * Firefox: In development
> * Edge: No public signals
> * Safari: No public signals
> * Web developers: Positive
>
> # Compatibility risk
>
> Low compatibility risk, as this feature is exposed through a new field
> `Intl.PluralRules`.
>
> # Ongoing technical constraints
>
> None
>
> # Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, Android, and Android WebView)?
>
> Yes
>
> # OWP launch tracking bug
>
> https://bugs.chromium.org/p/v8/issues/detail?id=5601
>
> # Link to entry on the Chrome Platform Status
>
> https://www.chromestatus.com/features/5653874773852160
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> --- You received this message because you are subscribed to the Google
> Groups "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Intent to ship: RegExp lookbehind assertions

[Adam Klein]

LGTM!

On Sun, Jul 30, 2017 at 7:18 AM, Mathias Bynens 
wrote:

> Contact emails
>
> yang...@chromium.org, little...@chromium.org, erikco...@chromium.org,
> math...@chromium.org
>
> Spec
>
> https://github.com/tc39/proposal-regexp-lookbehind (stage 3 proposal)
>
> Summary
>
> Lookarounds are zero-width assertions that match a string without
> consuming anything. ECMAScript has lookahead assertions that does this in
> forward direction, but the language is missing a way to do this backward
> which the lookbehind assertions provide. With lookbehind assertions, one
> can make sure that a pattern is or isn’t preceded by another, e.g. matching
> a dollar amount without capturing the dollar sign.
>
> Link to “Intent to Implement” blink-dev discussion
>
> There was none. Note that since this is a V8/JS feature, this post is
> just an FYI to blink-dev — no signoff from Blink API owners is required.
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux,
> Chrome OS, Android, and Android WebView)?
>
> Yes.
>
> Demo link
>
> Examples can be found here:
>
>-
>
>https://mathiasbynens.be/notes/es-regexp-proposals#lookbehinds
>-
>
>https://developers.google.com/web/updates/2017/07/upcoming-
>regexp-features#lookbehind_assertions
>
> 
>
>
> Interoperability and Compatibility Risk
>
> Low; this feature gives behavior to something which was previously a
> syntax error.
>
> Edge/Chakra: public support; tracking issue: https://github.com/Microsoft/
> ChakraCore/issues/3448
>
> Firefox/SpiderMonkey: no signals; tracking issue:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1225665
>
> Safari/JavaScriptCore: no signals; tracking issue:
> https://bugs.webkit.org/show_bug.cgi?id=174931
>
> Web developers: positive signals
>
> Is this feature fully tested?
>
> Yes. In addition to V8’s own tests
> ,
> Test262 includes tests for this feature
> 
> .
>
> OWP launch tracking bug
>
> https://bugs.chromium.org/p/v8/issues/detail?id=4545
>
> Entry on the feature dashboard 
>
> https://www.chromestatus.com/feature/5668726032564224
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To view this discussion on the web visit https://groups.google.com/a/
> chromium.org/d/msgid/blink-dev/CAJYpFjCaYnJx-
> NCHzbHYRKceAPkdN1UaU0WwSanE8PKjNuCFKg%40mail.gmail.com
> 
> .
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Intent to Ship:

[Adam Klein]

There's infrastucture work to be done to let the test262 test harness run
tests as modules. Again, the test262 github is the right place to discuss
that issue.

As for the matter of this "missing" coverage: in their V8 implementation,
the code generated for modules simply isn't that different from the code
generated for other JS code. So while this might be a nice sanity check to
have in the fture, it's not something that I'd expect to actually provide
much more value in the "code coverage" sense.

On Wed, Jun 21, 2017 at 1:04 PM, PhistucK <phist...@gmail.com> wrote:

> Will it be a lot of effort to just run the tests and create a list of
> failures? I can go over a manageable part of them and see if something
> looks fishy.
>
>
> ☆*PhistucK*
>
> On Wed, Jun 21, 2017 at 9:07 PM, <n...@chromium.org> wrote:
>
>> I expect a significant number of tests will fail due to the different
>> semantics, thus it would take a lot of time to evaluate the results.
>>
>>
>> On Wednesday, June 21, 2017 at 7:49:29 PM UTC+2, PhistucK wrote:
>>>
>>> Since this (intent) is a big feature, I think it would be appropriate to
>>> run the entire suite in a module scope before it is shipped.
>>> Do you think it would take a lot of work to do that?
>>>
>>>
>>> ☆*PhistucK*
>>>
>>> On Wed, Jun 21, 2017 at 8:27 PM, Adam Klein <ad...@chromium.org> wrote:
>>>
>>>> On Wed, Jun 21, 2017 at 9:44 AM, PhistucK <phist...@gmail.com> wrote:
>>>>
>>>>> Has anyone run the full test262 test suite within a module scope, just
>>>>> to make sure all of the ordinary features work there the same?
>>>>> (I understand that from a point of view of an implementor, this might
>>>>> seem unnecessary, because it is the same engine, but who knows, it may
>>>>> uncover hidden peculiarities in the engine)
>>>>>
>>>>
>>>> I don't know if anyone has done such a thing, but test262 does already
>>>> include metadata that allows tests to be run in strict mode, sloppy
>>>> (non-strict) mode, or both; I could imagine it being extended to make it
>>>> easy for test runners to run tests as modules as well.
>>>> github.com/tc39/test262/issues would be the place to raise that
>>>> feature request.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>> To view this discussion on the web visit https://groups.google.com/a/ch
>> romium.org/d/msgid/blink-dev/a0cfab54-5c05-4c81-8a60-a73576
>> 2922ce%40chromium.org
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a0cfab54-5c05-4c81-8a60-a735762922ce%40chromium.org?utm_medium=email_source=footer>
>> .
>>
>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Intent to Ship:

[Adam Klein]

On Wed, Jun 21, 2017 at 9:44 AM, PhistucK  wrote:

> Has anyone run the full test262 test suite within a module scope, just to
> make sure all of the ordinary features work there the same?
> (I understand that from a point of view of an implementor, this might seem
> unnecessary, because it is the same engine, but who knows, it may uncover
> hidden peculiarities in the engine)
>

I don't know if anyone has done such a thing, but test262 does already
include metadata that allows tests to be run in strict mode, sloppy
(non-strict) mode, or both; I could imagine it being extended to make it
easy for test runners to run tests as modules as well.
github.com/tc39/test262/issues would be the place to raise that feature
request.

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Intent to Ship:

[Adam Klein]

On Wed, Jun 21, 2017 at 8:25 AM, Domenic Denicola  wrote:

> From: blink-...@chromium.org [mailto:blink-...@chromium.org] On Behalf Of
> PhistucK
>
> > What about test-262 (web-platform-tests are not supposed to test
> ECMAScript features) for modules?​
>
> This is not an ECMAScript feature; this is an intent-to-ship specifically
> for 

[v8-users] Re: [blink-dev] Intent to Ship: Object rest/spread properties

[Adam Klein]

Are there test262 tests for this feature (do we pass them?)?

On Thu, Apr 20, 2017 at 12:27 PM, Sathya Gunasekaran 
wrote:

> Contact Emails:
> gsat...@chromium.org
>
> Spec:
> https://tc39.github.io/proposal-object-rest-spread/
>
> Summary:
> ECMAScript 6 introduced rest elements for array destructuring
> assignment and spread elements for array literals. This proposal
> introduces analogous rest properties for object destructuring
> assignment and spread properties for object literals.
>
> Rest properties collect the remaining own enumerable property keys
> that are not already picked off by the destructuring pattern. Those
> keys and their values are copied onto a new object.
>
> Spread properties in object initializers copies own enumerable
> properties from a provided object onto the newly created object.
>
> Interoperability and Compatibility Risk:
> This is a stage 3 feature.
>
> This new language feature allows syntax that was previously a
> SyntaxError, so compatibility risk is low.
>
> Webkit has shipped this in Safari Tech Preview Release 27. Firefox and
> Edge have not implemented this yet.
>
> Tracking bug:
> https://bugs.chromium.org/p/v8/issues/detail?id=5549
>
> Chrome status entry:
> https://www.chromestatus.com/feature/5657004848709632
>
>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to ship: Trailing comma in JavaScript function parameter lists

[Adam Klein]

LGTM

On Fri, Jan 13, 2017 at 1:55 PM, jwolfe  wrote:

> Summary:
>
> Allow a trailing comma in function parameter declarations and
> function call parameters. Example:
>
> function f(a, b,) {
>   return a + b;
> }
> let g = (a, b,) => a + b;
> f(1, 2,) + g(3, 4,);
>
> The purpose of this feature is to better support writing each parameter on
> its own line:
>
> function f(
> longParameterName1, // documentation for parameter
> longParameterName2, // documentation for parameter
> longParameterName3, // documentation for parameter
>   ) {
> }
> f(
>   complicatedExpression(), // this is longParameterName1
>   complicatedExpression(), // this is longParameterName2
>   complicatedExpression(), // this is longParameterName3
> );
>
> Allowing the final comma is beneficial when editing the code. If you want
> to reorder the parameters, you needn't add and remove commas from some of
> the lines sometimes. If you want to add a new final parameter, you can
> simply add a line without modifying the previous line. This makes
> version-control diffs cleaner and also makes editing code less troublesome
> and error prone. Trailing commas are allowed in array and object literal
> syntax for the same reasons.
>
>
> Interoperability and Compatibility Risk:
>
> This new language feature allows syntax that was previously a SyntaxError,
> so compatibility risk is low.
>
> This feature is in the draft ES2017 spec.
>
> Firefox has implemented ( https://bugzilla.mozilla.
> org/show_bug.cgi?id=1303788 ) but not yet shipped this feature.
> Webkit has implemented ( https://bugs.webkit.org/show_bug.cgi?id=158020 )
> but not yet shipped this feature.
> Edge is shipping with this feature enabled ( https://kangax.github.io/
> compat-table/es2016plus/ ).
>
>
> Spec:
>
> https://tc39.github.io/proposal-trailing-function-commas/
>
>
> Tracking bug:
>
> https://bugs.chromium.org/p/v8/issues/detail?id=5051
>
>
> Entry on the feature dashboard ( https://www.chromestatus.com/features ):
>
> https://www.chromestatus.com/feature/5656834660630528
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Re: ES2015 module support?

[Adam Klein]

Hi Owen,

I meant to respond to your email to blink-dev last month, but the holidays
conspired to keep me from giving a reasonable status update there. The
short story is that there is work well underway to get modules working in
Chromium; we have a prototype patch that now needs to be split into pieces
for landing. Starring https://crbug.com/594639 is your best bet on keeping
track of this work in progress.

- Adam

On Mon, Jan 9, 2017 at 10:25 AM, Owen Densmore  wrote:

> Thanks! So the flag is not a chrome://flags but rather a browser startup
> flag? How would I start up a version of chrome or canary on a mac using
> this flag? Thanks!
>
>
> On Monday, January 9, 2017 at 3:52:11 AM UTC-7, Michael Hablich wrote:
>>
>> There is already a flag: --harmony-modules. As you can see in the
>> tracking bug, there is a lot of development work going on. The feature also
>> needs support in the embedders to work correctly, which was/is unspecified
>> currently.
>>
>> On Saturday, January 7, 2017 at 11:18:20 PM UTC+1, Owen Densmore wrote:
>>>
>>> Are we any closer at this point? I'm seeing devs give up and revert to
>>> prior chaos. Maybe a flag to enable something?
>>>
>> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Re: [v8-dev] Intent to ship Intl.DateTimeFormat.protoytpe.formatToParts

[Adam Klein]

LGTM2

On Fri, Dec 16, 2016 at 3:38 PM, 'Daniel Ehrenberg' via v8-users <
v8-users@googlegroups.com> wrote:

> LGTM
>
> On Fri, Dec 16, 2016 at 3:00 PM, Jungshik Shin (신정식, 申政湜)
>  wrote:
> > Cross-posting to v8-dev@
> >
> > Contact emails
> > js...@chromium.org
> > Spec
> >
> > https://github.com/tc39/ecma402/files/41759/formatToParts.pdf
> >
> > Summary
> >
> > Intl.DateTimeFormat.prototype.formatToParts() is scheduled to be added
> to
> > the EcmaScript Internationalization API specification (Ecma 402).
> > It adds a method to format date and time to a list of tokens and their
> type
> > (e.g. literal, day, year, month, hour, minute, era, etc).
> >>
> >> It's implemented and shipped by Firefox. v8 implemented it behind a
> flag.
> >
> >
> > Motivation
> >
> > Formatting different parts of a DateTime string in different styles (font
> > weight, size, color, etc) is not possible currently because
> DateTimeFormat
> > does not offer a way to access individual parts of formatted DateTime.
> This
> > API gives back a list of token types and their offsets making it
> possible to
> > style different parts differently in an i18n-aware manner. See
> > https://github.com/tc39/ecma402/issues/30
> > Interoperability risk
> >
> > Firefox: Shipped
> > Safari: No public signals
> > Web developers: No signals
> >>
> >> Edge: No public signals
> >
> >
> > spec discussion: https://github.com/tc39/ecma402/issues/30
> > polyfill:
> > https://github.com/andyearnshaw/Intl.js/blob/
> master/src/12.datetimeformat.js
> >
> > Compatibility risk
> > None. This is a new API.
> > Ongoing technical constraints
> >
> > None
> > Will this feature be supported on all six Blink platforms (Windows, Mac,
> > Linux,
> > Chrome OS, Android, and Android WebView)? Yes or no.
> > Yes
> > OWP launch tracking bug
> >
> >
> > https://bugs.chromium.org/p/v8/issues/detail?id=5244
> >
> > Link to entry on the Chrome Platform Status
> >
> > https://www.chromestatus.com/features/6319456309477376
> >
> > Requesting approval to ship?
> > Yes
> >
> > --
> > --
> > v8-dev mailing list
> > v8-...@googlegroups.com
> > http://groups.google.com/group/v8-dev
> > ---
> > You received this message because you are subscribed to the Google Groups
> > "v8-dev" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to v8-dev+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Intent to Ship: Async functions

[Adam Klein]

LGTM!

On Tue, Sep 20, 2016 at 2:19 PM, 'Daniel Ehrenberg' via blink-dev <
blink-...@chromium.org> wrote:

> Contact emails
>
> *little...@chromium.org *
>
> Spec
>
> Async Functions, Stage 4 at TC39
> 
>
> Summary
> Async functions make it easy to write code which needs to "block" on
> certain asynchronous events JavaScript.
>
> Link to “Intent to Implement” v8-users discussion
>
> Intent to implement async/await functions
> 
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux,
> Chrome OS, Android, and Android WebView)?
>
> Yes
>
> Interoperability and Compatibility Risk
>
> In development or shipped behind a flag in Edge, Safari and Firefox. All
> implementations are working towards full specification compliance. The
> syntax is backwards-compatible; contextual keywords are added which do not
> break existing JavaScript code
>
> OWP launch tracking bug
>
> *https://bugs.chromium.org/p/v8/issues/detail?id=4483
> *
>
>
> Entry on the feature dashboard 
> https://www.chromestatus.com/features/5643236399906816
>
> *Requesting approval to ship*
> Yes
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to ship Intl.getCanonicalLocales

[Adam Klein]

LGTM

Please do make a Chromestatus entry.

On Tue, Aug 16, 2016 at 10:10 AM,  wrote:

> Intl.getCanonicalLocales [1] is a part of ECMAScript 2016
> Internationalization API
>
> Specification. It exposes an existing internal method to canonicalize the
>
> locale list and returns the result in an array.
>
>
> Firefox shipped it in version 48 [2].
>
>
> This is a trivial change [3] and the performance impact should be minimal
> if any.
>
> (I'm fast-tracking this to ship because it's so trivial that implementing
> it
>
> behind a flag seems to be an overkill.)
>
>
> Owner: js...@chromium.org
>
> Chromestatus: Not created. Will make one if necessary.
>
>
> [1] http://www.ecma-international.org/ecma-402/3.0/#sec-intl.
> getcanonicallocales
>
> [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/
> Reference/Global_Objects/Intl/getCanonicalLocales
>
> [3] https://codereview.chromium.org/2239523002/
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to Ship: Object.getOwnPropertyDescriptors()

[Adam Klein]

+bcc blink-dev

This lgtm to ship! A few questions/comments below.

On Thu, Jul 28, 2016 at 12:03 PM, Caitlin Potter  wrote:

> Object.getOwnPropertyDescriptors() has been implemented in V8 since
> February 2016, and enabled by the "Experimental Javascript Features" flag
> in Chrome since March. The feature has been ratified and is in the
> specification at
> https://tc39.github.io/ecma262/#sec-object.getownpropertydescriptors.
>

Is it implemented or shipped in other engines?


> Performance-wise, I believe we outperform user-space implementations of
> this function in the common cases by a factor of 2 (measured
> quickly/naively at
> https://github.com/caitp/getOwnPropertyDescriptors-bench), possibly
> slightly slower for more exotic uses (but this has not been tested).
>
> The technical debt introduced by this feature is fairly limited, taking up
> a total of 36 lines of straightforward C++ code.
>
> There is no chromestatus entry, but one will be created if asked for. It's
> been implemented for several months without one, and it seems like the
> feature is being found without an entry.
>

Please do add one (which will answer my question).

> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] d8 needs a function similar to JSC's `drainMicrotasks()`

[Adam Klein]

The assertOptimized approach seems like a good balance to me of:

1. Avoiding duplicating the assertion helpers and
2. Avoiding broadening d8's runtime environment

Then the only other requirement is that the usage of assertAsync (or
whatever it's called) in tests isn't affected by the concerns about
breaking the operating model assumptions.

On Tue, May 17, 2016 at 10:11 AM, Jakob Kummerow 
wrote:

> I agree that silent nops are bad, and that's not what we have: The
> implementation is
>
>   try {
> OptimizationStatusImpl = new Function(
> "fun", "sync", "return %GetOptimizationStatus(fun, sync);");
>   } catch (e) {
> throw new Error("natives syntax not allowed");
>   }
>
> leading to:
>
> $ out/x64.release/d8 test/mjsunit/mjsunit.js -e "function f(){};
> assertUnoptimized(f);"
> test/mjsunit/mjsunit.js:436: Error: natives syntax not allowed
>
>
> throw new Error("natives syntax not allowed");
>
>
> ^
>
>
> Error: natives syntax not allowed
>
>
> at OptimizationStatus (test/mjsunit/mjsunit.js:436:15)
>
>
> at assertUnoptimized (test/mjsunit/mjsunit.js:444:16)
>
> The point is that mjsunit.js should still load without
> --allow-natives-syntax, so that not every test must specify that flag, only
> those tests that need to call %Natives.
>
> As I said, I don't know whether we need or should have any microtasks
> related helper(s) in mjsunit.js, I just wanted to point out that it's
> technically possible to use %Natives there.
>
> On Tue, May 17, 2016 at 6:29 PM, Michael Starzinger <
> mstarzin...@chromium.org> wrote:
>
>> On Tue, May 17, 2016 at 6:25 PM, Jakob Kummerow 
>> wrote:
>>
>>> On Tue, May 17, 2016 at 1:01 AM, Caitlin Potter 
>>> wrote:
>>>
 As part of the async functions runtime implementation, I had
 implemented a function in d8.cc which would call isolate->RunMicrotasks()
 --- but was talked down from doing this because of a worry that it might
 interfere with certain uses of d8 out in the wild.

 So, I went with using the existing %RunMicrotasks runtime function ---
 but of course this requires a flag to be present, so the mjsunit helpers
 which rely on this can't be present in mjsunit.js (which means either a lot
 of code duplication, or worse).

>>>
>>> Yes they can; grep for "%GetOptimizationStatus" in mjsunit.js.
>>>
>>
>> I would vote for not adding yet another function like assertOptimized to
>> mjsunit.js that tries to catch the "SyntaxError: Unexpected token %" an
>> turns into a nop when the --allow-natives-syntax flag is not passed. This
>> just hides the fact that the request (i.e. draining the microtask queue)
>> can just not be fulfilled without said flag.
>>
>>
>>>
>>> (I can't comment on functionality concerns around %RunMicrotasks -- if
>>> the approach is invalid in general, then the above point is obviously moot.)
>>>
>>>
 What I'd like to do is get a feel for just how dangerous something like
 `runMicrotasks()` in d8.cc, or if we could get away with adding it as a
 method of a `TestUtils` or `Utils` object instead. Something that would
 allow tests which rely on being able to drain the microtask queue (in order
 to execute quickly, predictably, and synchronously, while still verifying
 the correct async behaviours), without requiring a --allow-natives-syntax
 just to parse the script.

 I don't think there's a huge risk in adding these to d8.cc, and they
 aren't exposed in v8 itself (or Chromium) --- if you're a user of d8 and
 you think a global variable named "Utils", "TestUtils", "runMicrotasks", or
 whatever, would interfere with your uses of d8, I'd like to hear why and
 how.

 Hopefully, there's consensus that it's not dangerous to add such a
 method or object to d8's global object.

 --
 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users
 ---
 You received this message because you are subscribed to the Google
 Groups "v8-users" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to v8-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

>>>
>>> --
>>> --
>>> v8-users mailing list
>>> v8-users@googlegroups.com
>>> http://groups.google.com/group/v8-users
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "v8-users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to v8-users+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> --
>> v8-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-users" 

Re: [v8-users] Intent to Deprecate and Remove: Custom Intl methods and properties

[Adam Klein]

lgtm2

On Wed, May 11, 2016 at 10:58 AM, Jochen Eisinger 
wrote:

> lgtm1
>
> Daniel Ehrenberg  schrieb am Mi., 11. Mai 2016,
> 19:55:
>
>> Primary eng email
>> little...@chromium.org
>>
>> *Summary*
>> Remove most of V8's additional methods and properties in ECMA 402 (Intl),
>> namely v8Parse, resolved and pattern.
>>
>> V8 bug: https://bugs.chromium.org/p/v8/issues/detail?id=3785
>>
>> *Motivation*
>> These three properties are unsupported in other browsers, not
>> standardized, and most are unlikely to get on a standards track in the near
>> future.
>> - v8Parse calls out to ICU's locale-based date/number parsing
>> implementation. However, the consensus among internationalization experts
>> I've communicated with is that the natural language processing is more
>> involved than simply processing something by the locale, and is better
>> served by a userspace library.
>> - resolved exposes a certain view of an unprocessed, internal version of
>> resolvedOptions(). For example, the calendar name is based on an internal
>> ICU format, rather than the standardized version in ECMA 402 which
>> resolvedOptions() presents.
>> - pattern exposes the CLDR pattern corresponding to a
>> Number/DateTimeFormat. This may make sense to standardize in the future,
>> but currently, ECMA 402 does not reference CLDR and does not support this
>> property.
>>
>> Although v8BreakIterator is V8-only and not standardized, it is not to be
>> removed in this intent due to its higher usage rate.
>>
>> *Compatibility risk*
>> No other browser supports these custom properties, and no specification
>> specifies semantics. Any site which depended on them would only work in
>> Chrome.
>>
>> A quick search on GitHub shows that usages in libraries come with
>> fallback paths, likely present to support the other browsers which don't
>> have them.
>>
>> *Alternative implementation suggestion for web develoepers*
>> Use the standard resolvedOptions() instead of resolved.
>>
>> *Usage information from UseCounters*
>> UseCounters show that these features are only very rarely used on the
>> web. resolved is used in .0002-.0003% of document loads, and the others are
>> used less frequently.
>>
>> *Requesting approval to remove too?*
>> Yes.
>>
>> --
>> --
>> v8-users mailing list
>> v8-users@googlegroups.com
>> http://groups.google.com/group/v8-users
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "v8-users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to v8-users+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Re: Intent to Ship: Object.values() and Object.entries()

[Adam Klein]

LGTM to ship, given the stage 4 state of the spec and our compat with the
test262 tests.

On Tue, May 3, 2016 at 10:26 AM, Caitlin Potter 
wrote:

> I was mistaken, the FireFox bug was just a symptom of a well known Symbol
> not being present yet in FireFox.
>
> So, there are no known compat/interop concerns with FireFox.
>
> On Tuesday, 3 May 2016 12:48:33 UTC-4, PhistucK wrote:
>>
>> Thank you. :)
>>
>>
>> ☆*PhistucK*
>>
>> On Tue, May 3, 2016 at 7:45 PM, Caitlin Potter 
>> wrote:
>>
>>> V8 passes all of the relevant test262 tests included in the current
>>> test262 roll.
>>>
>>> Regarding interop, there's a bug in the current FireFox implementation
>>> (so they do not totally conform to the specification at this time), but I
>>> believe the feature is enabled in FF nightly only at the moment, and is not
>>> going to result in issues with real content on the web.** --- however I
>>> will file a bug shortly.
>>>
>>> **I may be wrong about the "unshipped" bit,
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1232639 looks like it
>>> shipped the feature to FF47, but that's still a ways off
>>>
>>>
>>>
>>> On Tuesday, 3 May 2016 12:33:28 UTC-4, PhistucK wrote:

 Are the implementations interoperable? Does V8 pass all of the relevant
 test262 tests?
 (By the way, I suggest adding these questions to the standard V8 intent
 template)


 ☆*PhistucK*

 On Tue, May 3, 2016 at 7:21 PM, Caitlin Potter 
 wrote:

> It's in v8-users, here's a copy :x
>
> Contact emails
> ca...@igalia.com
>
>
> Spec
> Stage 4 TC39 Proposal at
> http://tc39.github.io/proposal-object-values-entries/ [1]
>
> Summary
> Introduces methods like Object.keys() [2] which will produce an Array
> containing the values (or entry pairs, as in Array.prototype.entries()) of
> enumerable properties, in enumeration order.
>
> These are more or less analogous to the popular Lodash library methods
> _.values() [3] and _.toPairs() (now aliased as
> _.entries() [4].
>
> Have been implemented in V8 in early Q1 2016 [5], and staged in early
> Q2 2016 [6]
>
> Interoperability and Compatibility Risk
> Feature is late stage in the TC39 process, and will be incorporated
> into ECMA262 in the near future. It is currently implemented by several
> vendors:
> - Implemented in Mozilla FireFox [7]
> - Implemented in ChakraCore [8]
>
> OWP launch tracking bug
> See [9] for launch tracking bug
>
> Entry on the feature dashboard
> See [10] for feature dashboard entry
>
> [1] http://tc39.github.io/proposal-object-values-entries/
> [2] https://tc39.github.io/ecma262/#sec-object.keys
> [3] https://lodash.com/docs#values
> [4] https://lodash.com/docs#toPairs
> [5] https://crrev.com/677be73e767f93741204f07061f0216485086f99
> [6] https://crrev.com/008981cf12e9b9049cbd25b216e80fe45cd6e172
> [7] https://bugzilla.mozilla.org/show_bug.cgi?id=1208464
> [8]
> https://github.com/Microsoft/ChakraCore/commit/83c8a120ba568b90b520d0aa1528cd85dc31cf35
> [9] https://bugs.chromium.org/p/v8/issues/detail?id=4663
> [10] https://www.chromestatus.com/features/5710160244768768
>
>
> On Tuesday, 3 May 2016 12:19:18 UTC-4, PhistucK wrote:
>>
>> The post itself seems to be missing. :(
>>
>>
>> ☆*PhistucK*
>>
>> On Tue, May 3, 2016 at 7:13 PM, Caitlin Potter 
>> wrote:
>>
>>> +blink-dev

 --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to blink-dev+...@chromium.org.
>>>
>>
>> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org.
>

 --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+...@chromium.org.
>>>
>>
>>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to Ship: ECMAScript 2016 Exponentiation operator

[Adam Klein]

LGTM2

On Fri, Apr 15, 2016 at 6:52 AM, Caitlin Potter 
wrote:

> [FYI +blink-dev]
>
> Contact emails
> ca...@igalia.com
>
> Spec
> Feature has been merged into ECMA262 specification [1]
>
> Summary
> Introduces arithmetic operators `**` and `**=`, which behaves as though
> Math.pow() were called, using the lefthand-side as the base, and
> righthand-side as the exponent value.
>
> Implemented in V8 since M 51 
> [2],
> and has been enabled via the --harmony flag and experimental javascript
> features flag since roughly a week after implementing.
>
> At the moment, this feature is implemented in a very simple way, without
> introducing complexity to the compiler backends, with limited constant
> folding support.
>
> Interoperability and Compatibility Risk
> Feature is included in the feature set for ECMAScript 2016, and is
> implemented by several vendors.
> - Shipping in Microsoft Edge [3]
> - Implemented in Mozilla FireFox [4]
>
> OWP launch tracking bug
> See [5] for launch tracking bug
>
> Entry on the feature dashboard
> See [6] for feature dashboard entry
>
> [1] https://tc39.github.io/ecma262/#sec-exp-operator
> [2]
> https://chromium.googlesource.com/v8/v8/+/17c92fe6bb62e11a43ef8c77d26410407a9828b5
> [3]
> https://github.com/Microsoft/ChakraCore/commit/9d7e0e4b17bfa3a87c14da8e96cf96b65cb8dbdb
> [4]
> https://github.com/mozilla/gecko-dev/blob/f893a5d6de5044cd02e8e8cea5409a490f7adf62/js/src/jsversion.h#L40-L45
> [5] https://bugs.chromium.org/p/v8/issues/detail?id=3915
> [6] https://www.chromestatus.com/features/5461064690958336
>
> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to the Google Groups
> "v8-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to v8-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Re: Intent to Un-ship: Object.observe

[Adam Klein]

That's correct. The state of the world is:

M49: Deprecation message
M50: Removed

Of course M50 hasn't even been branched yet, so all I can guarantee for now
is that M49 has a deprecation message, but the intention is to continue
with removal in M50.

On Tue, Feb 23, 2016 at 8:28 AM, PhistucK <phist...@gmail.com> wrote:

> His message actually stated it will be removed, not deprecated, in Chrome
> 50.
>
>
> ☆*PhistucK*
>
> On Tue, Feb 23, 2016 at 5:41 PM, 'Joe Medley' via blink-dev <
> blink-...@chromium.org> wrote:
>
>> Adam,
>>
>> Just to clarify, it sounds like this isn't being deprecated in M49, but
>> in M50 instead?
>>
>> While we're on the subject, when are you hoping for removal?
>>
>> Joe Medley | Technical Writer, Chrome DevRel | jmed...@google.com |
>> 816-678-7195
>> *If an API's not documented it doesn't exist.*
>>
>> On Mon, Feb 22, 2016 at 11:21 AM, Adam Klein <ad...@chromium.org> wrote:
>>
>>> I've again disabled Object.observe (as promised by the deprecation
>>> message) in time for the M50 branch. The V8 roll
>>> https://chromium.googlesource.com/chromium/src/+/3f4c95f66bca contains
>>> the relevant V8 change, and versions of Chrome after 50.0.2656.0 no longer
>>> expose Object.observe.
>>>
>>> On Fri, Jan 8, 2016 at 11:09 AM, Adam Klein <ad...@chromium.org> wrote:
>>>
>>>> An update on Object.observe deprecation: it will still be on in v8 4.9
>>>> (Chromium M49), but with a deprecation message in the console.
>>>>
>>>> I still aim to un-ship it in future releases, and am working with the
>>>> Blink API owners and other interested parties to develop that plan.
>>>>
>>>> On Thu, Dec 10, 2015 at 9:43 AM, Adam Klein <ad...@chromium.org> wrote:
>>>>
>>>>> I have not looked at httparchive. Given that this feature was only
>>>>> shipped in Chrome, I wouldn't expect it to be used by sites on the open 
>>>>> web
>>>>> (without a compatibility library like observe-js).
>>>>>
>>>>> There's still the chance that we'll run into problems with
>>>>> Chrome-specific apps or extensions, and that's part of the reason I want 
>>>>> to
>>>>> start canarying ASAP.
>>>>>
>>>>> On Thu, Dec 10, 2015 at 9:36 AM, Chris Harrelson <
>>>>> chris...@chromium.org> wrote:
>>>>>
>>>>>> Hi Adam,
>>>>>>
>>>>>> Have you tried an httparchive or other search to see if this would
>>>>>> break a lot of sites?
>>>>>>
>>>>>> Chris
>>>>>>
>>>>>> On Wed, Dec 9, 2015 at 5:33 PM Adam Klein <ad...@chromium.org> wrote:
>>>>>>
>>>>>>> Until the code is gone, you can enable it in Chrome with:
>>>>>>>
>>>>>>> --js-flags=--harmony-object-observe
>>>>>>>
>>>>>>> On Wed, Dec 9, 2015 at 5:17 PM, <inian1...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Will there be a way to locally turn-on support for Object.observe?
>>>>>>>> I am using it for some analysis and would like to enable it on my 
>>>>>>>> version
>>>>>>>> of Chrome.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thursday, 10 December 2015 03:56:51 UTC+8, Adam Klein wrote:
>>>>>>>>>
>>>>>>>>> [bcc blink-dev]
>>>>>>>>>
>>>>>>>>> As previously announced at
>>>>>>>>> https://esdiscuss.org/topic/an-update-on-object-observe,
>>>>>>>>> Object.observe has been withdrawn as an ECMAScript proposal. Also as
>>>>>>>>> mentioned there, usage in Chrome is extremely low according to
>>>>>>>>> chromestatus.com (0.0171% as I write this). Furthermore, most
>>>>>>>>> known usage of Object.observe utilizes
>>>>>>>>> https://github.com/polymer/observe-js, which includes fallback
>>>>>>>>> support for non-Object.observe engines (which will soon be all of 
>>>>>>>>> them).
>>>>>>>>>
>>>>>>>>> I intend to flip the --harmony-object-observe flag to false in a
>>>>>>>>> change later today, with the aim of v8 version 4.9 branching without
>>>>>>>>> Object.observe support.
>>>>>>>>>
>>>>>>>>> - Adam
>>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> You received this message because you are subscribed to the Google
>>>>>>> Groups "blink-dev" group.
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to blink-dev+unsubscr...@chromium.org.
>>>>>>>
>>>>>>
>>>>>
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>>
>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Re: Intent to Un-ship: Object.observe

[Adam Klein]

I've again disabled Object.observe (as promised by the deprecation message)
in time for the M50 branch. The V8 roll
https://chromium.googlesource.com/chromium/src/+/3f4c95f66bca contains the
relevant V8 change, and versions of Chrome after 50.0.2656.0 no longer
expose Object.observe.

On Fri, Jan 8, 2016 at 11:09 AM, Adam Klein <ad...@chromium.org> wrote:

> An update on Object.observe deprecation: it will still be on in v8 4.9
> (Chromium M49), but with a deprecation message in the console.
>
> I still aim to un-ship it in future releases, and am working with the
> Blink API owners and other interested parties to develop that plan.
>
> On Thu, Dec 10, 2015 at 9:43 AM, Adam Klein <ad...@chromium.org> wrote:
>
>> I have not looked at httparchive. Given that this feature was only
>> shipped in Chrome, I wouldn't expect it to be used by sites on the open web
>> (without a compatibility library like observe-js).
>>
>> There's still the chance that we'll run into problems with
>> Chrome-specific apps or extensions, and that's part of the reason I want to
>> start canarying ASAP.
>>
>> On Thu, Dec 10, 2015 at 9:36 AM, Chris Harrelson <chris...@chromium.org>
>> wrote:
>>
>>> Hi Adam,
>>>
>>> Have you tried an httparchive or other search to see if this would break
>>> a lot of sites?
>>>
>>> Chris
>>>
>>> On Wed, Dec 9, 2015 at 5:33 PM Adam Klein <ad...@chromium.org> wrote:
>>>
>>>> Until the code is gone, you can enable it in Chrome with:
>>>>
>>>> --js-flags=--harmony-object-observe
>>>>
>>>> On Wed, Dec 9, 2015 at 5:17 PM, <inian1...@gmail.com> wrote:
>>>>
>>>>> Will there be a way to locally turn-on support for Object.observe? I
>>>>> am using it for some analysis and would like to enable it on my version of
>>>>> Chrome.
>>>>>
>>>>>
>>>>> On Thursday, 10 December 2015 03:56:51 UTC+8, Adam Klein wrote:
>>>>>>
>>>>>> [bcc blink-dev]
>>>>>>
>>>>>> As previously announced at
>>>>>> https://esdiscuss.org/topic/an-update-on-object-observe,
>>>>>> Object.observe has been withdrawn as an ECMAScript proposal. Also as
>>>>>> mentioned there, usage in Chrome is extremely low according to
>>>>>> chromestatus.com (0.0171% as I write this). Furthermore, most known
>>>>>> usage of Object.observe utilizes
>>>>>> https://github.com/polymer/observe-js, which includes fallback
>>>>>> support for non-Object.observe engines (which will soon be all of them).
>>>>>>
>>>>>> I intend to flip the --harmony-object-observe flag to false in a
>>>>>> change later today, with the aim of v8 version 4.9 branching without
>>>>>> Object.observe support.
>>>>>>
>>>>>> - Adam
>>>>>>
>>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "blink-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to blink-dev+unsubscr...@chromium.org.
>>>>
>>>
>>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: [blink-dev] Re: Intent to Un-ship: Object.observe

[Adam Klein]

I have not looked at httparchive. Given that this feature was only shipped
in Chrome, I wouldn't expect it to be used by sites on the open web
(without a compatibility library like observe-js).

There's still the chance that we'll run into problems with Chrome-specific
apps or extensions, and that's part of the reason I want to start canarying
ASAP.

On Thu, Dec 10, 2015 at 9:36 AM, Chris Harrelson <chris...@chromium.org>
wrote:

> Hi Adam,
>
> Have you tried an httparchive or other search to see if this would break a
> lot of sites?
>
> Chris
>
> On Wed, Dec 9, 2015 at 5:33 PM Adam Klein <ad...@chromium.org> wrote:
>
>> Until the code is gone, you can enable it in Chrome with:
>>
>> --js-flags=--harmony-object-observe
>>
>> On Wed, Dec 9, 2015 at 5:17 PM, <inian1...@gmail.com> wrote:
>>
>>> Will there be a way to locally turn-on support for Object.observe? I am
>>> using it for some analysis and would like to enable it on my version of
>>> Chrome.
>>>
>>>
>>> On Thursday, 10 December 2015 03:56:51 UTC+8, Adam Klein wrote:
>>>>
>>>> [bcc blink-dev]
>>>>
>>>> As previously announced at
>>>> https://esdiscuss.org/topic/an-update-on-object-observe,
>>>> Object.observe has been withdrawn as an ECMAScript proposal. Also as
>>>> mentioned there, usage in Chrome is extremely low according to
>>>> chromestatus.com (0.0171% as I write this). Furthermore, most known
>>>> usage of Object.observe utilizes https://github.com/polymer/observe-js,
>>>> which includes fallback support for non-Object.observe engines (which will
>>>> soon be all of them).
>>>>
>>>> I intend to flip the --harmony-object-observe flag to false in a change
>>>> later today, with the aim of v8 version 4.9 branching without
>>>> Object.observe support.
>>>>
>>>> - Adam
>>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "blink-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscr...@chromium.org.
>>
>

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to Un-ship: Object.observe

[Adam Klein]

[bcc blink-dev]

As previously announced at
https://esdiscuss.org/topic/an-update-on-object-observe, Object.observe has
been withdrawn as an ECMAScript proposal. Also as mentioned there, usage in
Chrome is extremely low according to chromestatus.com (0.0171% as I write
this). Furthermore, most known usage of Object.observe utilizes
https://github.com/polymer/observe-js, which includes fallback support for
non-Object.observe engines (which will soon be all of them).

I intend to flip the --harmony-object-observe flag to false in a change
later today, with the aim of v8 version 4.9 branching without
Object.observe support.

- Adam

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
"v8-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to ship: Array.prototype.includes

[Adam Klein]

[bcc blink-dev FYI]

I'm happy to see this shipped, as it's been implemented for quite awhile
and the API is about as stable as you could get.

On Tue, Aug 11, 2015 at 11:03 AM, Domenic Denicola d...@domenic.me wrote:

 The Array.prototype.includes proposal [1] is on track for ES2016 and is
 currently in stage 3 of the process, awaiting shipping implementations
 before it can advance to stage 4. It provides a nice way to test for
 membership in an array (including avoiding edge cases around NaN).

 Firefox already ships this in Nightly, and Safari already ships in the
 Safari 9 betas (although not including %TypedArray%.prototype.includes,
 last I checked).

 V8 issue: https://code.google.com/p/v8/issues/detail?id=3575
 Owner: dome...@chromium.org

 [1]: https://github.com/tc39/Array.prototype.includes

 --
 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users
 ---
 You received this message because you are subscribed to the Google Groups
 v8-users group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to v8-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
v8-users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to ship: ES'15 new.target

[Adam Klein]

The 'new.target' meta-property[1] is part of ECMAScript 2015. It provides
access to the constructor function which was invoked by 'new' (if a
construct call is underway) or undefined otherwise.

Firefox plans to ship it in version 41 [2].

This is the last piece of the ES'15 class semantics to ship in V8 and will
open up the ability for V8 to further improve its support for subclassing
builtins.

Owner: ad...@chromium.org
Chromestatus: https://www.chromestatus.com/feature/5210159227863040

[1]
http://www.ecma-international.org/ecma-262/6.0/#sec-meta-properties-runtime-semantics-evaluation
[2] https://developer.mozilla.org/en-US/Firefox/Releases/41#JavaScript

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
v8-users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] API changes upcoming to make writing exception safe code more easy

[Adam Klein]

Interesting. I agree it's nice to have in a debugging sort of way, both
for embedders and v8 itself (no weird crashes due to people forgetting to
enter a Context). But I wonder if we're now in a sort of inconsistent
state, where some APIs require entering a Context before calling and others
take this as an argument. Are we planning to move more of the API towards
_always_ passing a Context?

On Thu, Apr 9, 2015 at 10:06 AM, Jochen Eisinger joc...@chromium.org
wrote:

 In C++ you can't overload a method with just a different return type.
 Since making the context explicit instead of hoping that the right one is
 entered is nice to have, it was a handy way to change the return type.

 On Thu, Apr 9, 2015 at 6:25 PM Adam Klein ad...@chromium.org wrote:

 On Fri, Feb 27, 2015 at 2:43 AM, Michael Hablich habl...@chromium.org
 wrote:

 Hey v8-users,

 we're making big changes to the api (again).  We've found that our api makes
 it extremely difficult to write exception safe code.

 *Reference issue*
 https://code.google.com/p/v8/issues/detail?id=3929

 *Further description*
 Consider the following:

 LocalValue x = some_value;
 s = x.ToString();
 // in the current context, ToString might throw an exception, run out
 of stack space, whatever...
 // if that happens we just return an empty LocalString
 s-Anything() // Crash!

 There's too much implicit stuff happening here, and it's bad.  It's 
 especially
 bad if you use threads and rely on TerminateExecution(), which causes
 lots of v8 function to return empty handles unexpectedly.

 To fix this, we will begin adding functions whose signature makes it 
 impossible
 to make this mistake and we will deprecate and eventually remove all
 old functions.  The new functions will in general come in
 two flavours:

 functions like:
 LocalString ToString(Isolate*);

 will become:
 MaybeLocalString ToString(LocalContext);

 and functions like:
 double NumberValue();

 will become:
 Maybebool NumberValue(LocalContext);

 The Maybe values ensure at compilation time that the value returned is 
 checked
 by the embedder, and the explicit Context makes it clear that a context
 is actually required and that javascript may be executed in that
 context.


 I'm curious about this bit of the design: why was it decided to add an
 argument here rather than require a Context to be entered (via
 Context::Scope)?

 Rather late to the discussion, I know. Apologies

 - Adam


 *Timeline*
 We will add the new API parts gradually to the codebase. When this is
 finished there will be approx. 6 weeks of time where the old and the new
 API will exist side-by-side. This is a good time to make the adjustments in
 your embedding code. After this period the old API will get removed.

 We apologize in advance for any trouble this may cause, but we're positive
 that this change will reduce crash rates for practically all v8
 embedders.

 Cheers,
 Michael Hablich

 --
 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users
 ---
 You received this message because you are subscribed to the Google
 Groups v8-users group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to v8-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

  --
 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users
 ---
 You received this message because you are subscribed to the Google Groups
 v8-users group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to v8-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

  --
 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users
 ---
 You received this message because you are subscribed to the Google Groups
 v8-users group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to v8-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
v8-users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] API changes upcoming to make writing exception safe code more easy

[Adam Klein]

Excellent to hear, this sounds like an overall win (I say this as someone
who in my early V8 interactions often found myself surprised by the need of
a Context in cases I'd have guessed didn't need one).

On Thu, Apr 9, 2015 at 10:44 AM, Dan Carney dcar...@chromium.org wrote:

 I've already converted most of the functions to take a context that might
 use one internally.  Part of the change is to make explicit what v8 maybe
 should never have made implicit.  I've found a number of places when calls
 are made that require a context internally on some uncommon paths but we're
 using them without one.

 On Thursday, April 9, 2015 at 7:36:43 PM UTC+2, Adam Klein wrote:

 Interesting. I agree it's nice to have in a debugging sort of way, both
 for embedders and v8 itself (no weird crashes due to people forgetting to
 enter a Context). But I wonder if we're now in a sort of inconsistent
 state, where some APIs require entering a Context before calling and others
 take this as an argument. Are we planning to move more of the API towards
 _always_ passing a Context?

 On Thu, Apr 9, 2015 at 10:06 AM, Jochen Eisinger joc...@chromium.org
 wrote:

 In C++ you can't overload a method with just a different return type.
 Since making the context explicit instead of hoping that the right one is
 entered is nice to have, it was a handy way to change the return type.

 On Thu, Apr 9, 2015 at 6:25 PM Adam Klein ad...@chromium.org wrote:

 On Fri, Feb 27, 2015 at 2:43 AM, Michael Hablich hab...@chromium.org
 wrote:

 Hey v8-users,

 we're making big changes to the api (again).  We've found that our api 
 makes
 it extremely difficult to write exception safe code.

 *Reference issue*
 https://code.google.com/p/v8/issues/detail?id=3929

 *Further description*
 Consider the following:

 LocalValue x = some_value;
 s = x.ToString();
 // in the current context, ToString might throw an exception, run out
 of stack space, whatever...
 // if that happens we just return an empty LocalString
 s-Anything() // Crash!

 There's too much implicit stuff happening here, and it's bad.  It's 
 especially
 bad if you use threads and rely on TerminateExecution(), which causes
 lots of v8 function to return empty handles unexpectedly.

 To fix this, we will begin adding functions whose signature makes it 
 impossible
 to make this mistake and we will deprecate and eventually remove all
 old functions.  The new functions will in general come in
 two flavours:

 functions like:
 LocalString ToString(Isolate*);

 will become:
 MaybeLocalString ToString(LocalContext);

 and functions like:
 double NumberValue();

 will become:
 Maybebool NumberValue(LocalContext);

 The Maybe values ensure at compilation time that the value returned is 
 checked
 by the embedder, and the explicit Context makes it clear that a
 context is actually required and that javascript may be executed in that
 context.


 I'm curious about this bit of the design: why was it decided to add an
 argument here rather than require a Context to be entered (via
 Context::Scope)?

 Rather late to the discussion, I know. Apologies

 - Adam


 *Timeline*
 We will add the new API parts gradually to the codebase. When this is
 finished there will be approx. 6 weeks of time where the old and the new
 API will exist side-by-side. This is a good time to make the adjustments 
 in
 your embedding code. After this period the old API will get removed.

 We apologize in advance for any trouble this may cause, but we're positive
 that this change will reduce crash rates for practically all v8
 embedders.

 Cheers,
 Michael Hablich

 --
 --
 v8-users mailing list
 v8-u...@googlegroups.com
 http://groups.google.com/group/v8-users
 ---
 You received this message because you are subscribed to the Google
 Groups v8-users group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to v8-users+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

  --
 --
 v8-users mailing list
 v8-u...@googlegroups.com
 http://groups.google.com/group/v8-users
 ---
 You received this message because you are subscribed to the Google
 Groups v8-users group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to v8-users+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

  --
 --
 v8-users mailing list
 v8-u...@googlegroups.com
 http://groups.google.com/group/v8-users
 ---
 You received this message because you are subscribed to the Google
 Groups v8-users group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to v8-users+u...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


  --
 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users
 ---
 You received this message because you are subscribed to the Google Groups
 v8-users group.
 To unsubscribe from this group and stop receiving emails from

Re: [v8-users] API changes upcoming to make writing exception safe code more easy

[Adam Klein]

On Fri, Feb 27, 2015 at 2:43 AM, Michael Hablich habl...@chromium.org
wrote:

 Hey v8-users,

 we're making big changes to the api (again).  We've found that our api makes
 it extremely difficult to write exception safe code.

 *Reference issue*
 https://code.google.com/p/v8/issues/detail?id=3929

 *Further description*
 Consider the following:

 LocalValue x = some_value;
 s = x.ToString();
 // in the current context, ToString might throw an exception, run out
 of stack space, whatever...
 // if that happens we just return an empty LocalString
 s-Anything() // Crash!

 There's too much implicit stuff happening here, and it's bad.  It's especially
 bad if you use threads and rely on TerminateExecution(), which causes
 lots of v8 function to return empty handles unexpectedly.

 To fix this, we will begin adding functions whose signature makes it 
 impossible
 to make this mistake and we will deprecate and eventually remove all old
 functions.  The new functions will in general come in
 two flavours:

 functions like:
 LocalString ToString(Isolate*);

 will become:
 MaybeLocalString ToString(LocalContext);

 and functions like:
 double NumberValue();

 will become:
 Maybebool NumberValue(LocalContext);

 The Maybe values ensure at compilation time that the value returned is checked
 by the embedder, and the explicit Context makes it clear that a context
 is actually required and that javascript may be executed in that context.


I'm curious about this bit of the design: why was it decided to add an
argument here rather than require a Context to be entered (via
Context::Scope)?

Rather late to the discussion, I know. Apologies

- Adam


 *Timeline*
 We will add the new API parts gradually to the codebase. When this is
 finished there will be approx. 6 weeks of time where the old and the new
 API will exist side-by-side. This is a good time to make the adjustments in
 your embedding code. After this period the old API will get removed.

 We apologize in advance for any trouble this may cause, but we're positive
 that this change will reduce crash rates for practically all v8 embedders.

 Cheers,
 Michael Hablich

 --
 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users
 ---
 You received this message because you are subscribed to the Google Groups
 v8-users group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to v8-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
v8-users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Are valid Smis ever stored in a HeapNumber?

[Adam Klein]

Subject says it all. I was surprised not to find a DCHECK in
Heap::AllocateHeapNumber asserting this is the case, and wondered why.

- Adam

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
v8-users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Are valid Smis ever stored in a HeapNumber?

[Adam Klein]

Makes sense, thanks.

On Mon, Dec 8, 2014 at 1:12 PM, 'Andreas Rossberg' via v8-users 
v8-users@googlegroups.com wrote:

 On 8 December 2014 at 20:53, Adam Klein ad...@chromium.org wrote:
  Subject says it all. I was surprised not to find a DCHECK in
  Heap::AllocateHeapNumber asserting this is the case, and wondered why.

 You mean, do we normalise all numbers within smi range to smis? No,
 since that would require potentially expensive extra logic for all
 operators and intrinsic functions that could possibly return a number
 in smi range for some arguments.

 /Andreas

 --
 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users
 ---
 You received this message because you are subscribed to the Google Groups
 v8-users group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to v8-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
v8-users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: Intent to ship: ES6 Map Set

[Adam Klein]

First, an apology that I didn't update this thread earlier.

Yesterday, in https://code.google.com/p/v8/source/detail?r=22889, I enabled
Map and Set by default on bleeding_edge. These are complete
implementations, including the iterator-related features Erik mentioned in
his original message. This was done after getting approvals for shipping
from V8 owners Andreas Rossberg and Dmitry Lomov.

So consider this an notification of shipping a day late.

Cheers,
Adam


On Tue, May 6, 2014 at 12:22 PM, Erik Arvidsson a...@google.com wrote:

 Map  Set are both part of ES6 [1], [2].

 They are shipping in Firefox since version 13 [3] and Internet Explorer 11
 [4]. They are also turned on by default for nightly WebKit/JSC.

 Adam Klein recently re-implemented the backing hash table used by both Map
 and Set to use an ordered hash table, which is a requirement for
 deterministic insertion order iteration. With that we were able to add
 support for forEach which we saw as a must have for parity with Firefox and
 Internet Explorer.

 This is not a full implementation of Map and Set. Most notably it does not
 include @iterator, entries, values nor keys. This is also the lowest common
 denominator between IE and FF. We plan to send out further intent to ship
 emails before we ship the remaining features of Map and Set.

 Owners: ad...@chromium.org, a...@chromium.org

 [1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-map-objects
 [2] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-set-objects
 [3] https://developer.mozilla.org/en-US/Firefox/Releases/13
 [4] http://msdn.microsoft.com/en-us/library/ie/dn342892(v=vs.85).aspx



-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
v8-users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [v8-users] Intent to ship: ES6 Map Set

[Adam Klein]

On Wed, May 7, 2014 at 5:11 AM, Vyacheslav Egorov vego...@chromium.org
wrote:

 What are the performance characteristics and memory footprint one can
 expect from Map  Set?


 The implementation is based on the deterministic hash table described at
https://wiki.mozilla.org/User:Jorend/Deterministic_hash_tables.

I would like to point out that a lot of built-in features that V8 and other
 JS VMs implement (e.g. Array.prototype.forEach) are never used because they
 are perceived as slow (and they are actually slow for various reasons).

 Can we proactively avoid falling down the same hole with ES6 features?

 What about having ES6 features (micro)benchmark suite to drive performance
 of this features across all browsers implementing them?


I agree that it's important to keep an eye on performance when adding new
features, and we have done that here. There's a microbenchmark for Map/Set
running on our (currently internal) perf waterfall, and both Erik and
myself have spent some time tweaking the existing implementation with the
goal of speeding that up (e.g., Erik's
https://code.google.com/p/v8/source/detail?r=22027). Further optimization
work has been discussed, but there are some significant hurdles (for
example around the current implementation of the hash codes used for V8
objects).



 Vyacheslav Egorov


 On Tue, May 6, 2014 at 9:22 PM, 'Erik Arvidsson' via v8-users 
 v8-users@googlegroups.com wrote:

 Map  Set are both part of ES6 [1], [2].

 They are shipping in Firefox since version 13 [3] and Internet Explorer
 11 [4]. They are also turned on by default for nightly WebKit/JSC.

 Adam Klein recently re-implemented the backing hash table used by both
 Map and Set to use an ordered hash table, which is a requirement for
 deterministic insertion order iteration. With that we were able to add
 support for forEach which we saw as a must have for parity with Firefox and
 Internet Explorer.

 This is not a full implementation of Map and Set. Most notably it does
 not include @iterator, entries, values nor keys. This is also the lowest
 common denominator between IE and FF. We plan to send out further intent to
 ship emails before we ship the remaining features of Map and Set.

 Owners: ad...@chromium.org, a...@chromium.org

 [1] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-map-objects
 [2] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-set-objects
 [3] https://developer.mozilla.org/en-US/Firefox/Releases/13
 [4] http://msdn.microsoft.com/en-us/library/ie/dn342892(v=vs.85).aspx

  --
 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users
 ---
 You received this message because you are subscribed to the Google Groups
 v8-users group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to v8-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.




-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
v8-users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Why doesn't v8::TryCatch catch exceptions thrown from C++?

[Adam Klein]

The subject says it all. I'm trying to wrap some code that uses the V8 API
to throw exceptions (via v8::ThrowException()), and was expecting wrapping
those calls in a v8::TryCatch to do this for me. But it seems they bypass
my TryCatch (though with SetVerbose(true) they are at least reported to
me). Is there something I can do to make the TryCatch completely swallow an
exception?

Thanks,
Adam

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
v8-users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [v8-users] Profiling v8 inside chromium/content_shell

[Adam Klein]

On Tue, Jun 11, 2013 at 2:38 AM, Kentaro Hara hara...@chromium.org wrote:
 Also, I'm a bit surprised at the way the v8 DOM callbacks end up in
 the profile: those methods are usually trivial, with the real work
 being somewhere deep in the core of Blink. Is it expected that only
 the v8 entry point into Blink shows up when using the profiling tool?


 I've played around the V8 timeline tool, but it doesn't give us reasonable
 data about DOM. In the timeline tool, DOM details (e.g. style recalculation
 or layout) are not profiled. In addition, those heavy DOM operations can be
 counted as a V8 execution time, because the timeline tool doesn't hook entry
 points from JITted code (Only entry points from non-JITted code are hooked).
 Yang will know more.

Yang, can you explain this point a bit further? Does this mean that if
I see some DOM entry point taking, e.g., 10% of ticks I shouldn't
trust it at all? Or does it just mean that there's some stuff I'm
missing?

 I've discussed how to improve the V8 timeline tool for DOM, but we found
 that it might be hard to extend it in a straightforward manner for some
 reasons. Thus, we started implementing another profiler based on trace
 events which will give you coarse-grained view about what percentages of the
 main thread are changed on what (e.g. V8's GC, parsing, compiling, DOM
 attribute getters, style recalculation etc). I'm implementing the profiler
 but it will take a bit more time to land it.



 On Tue, Jun 11, 2013 at 6:15 PM, Jochen Eisinger joc...@chromium.org
 wrote:

 +kentaro for some profiling insights


 On Tue, Jun 11, 2013 at 7:24 AM, Adam Klein ad...@chromium.org wrote:

 I'm trying to profile the v8 execution of a web app using Chromium's
 content_shell with some success. But I'm also getting some odd
 results. I'm using a commandline like:

 content_shell --no-sandbox --js-flags='--prof --noprof-lazy
 --log-timer-events' http://localhost:8000/mypage

 And then processing the v8.log with

 v8/tools/linux-tick-processor v8.log

 The resulting profile has some quirks: none of the JavaScript
 portion of the profile lists more than 0.2% of the total ticks (even
 though there's 500ms of JS execution time as part of the app, as
 shown by both plot-timer-events and the Inspector's timeline). The C++
 stack, meanwhile, has several major points of interest. Most of the
 big ones are Blink C++ callbacks (e.g.,
 NodeV8Internal::dispatchEventMethodCallback), and __pthread_cond_wait
 shows up. But the top one is __write, usually taking 30% of the
 ticks.

 If I go down to the call stacks, I get a bunch of LazyCompile
 someMethod entries which terminate at __write, so it seems I'm still
 getting some idea of which JS is taking the time, but I'm rather
 surprised that __write is the endpoint (it's mostly DOM tree
 walking/manipulation). Is this expected?

 Also, I'm a bit surprised at the way the v8 DOM callbacks end up in
 the profile: those methods are usually trivial, with the real work
 being somewhere deep in the core of Blink. Is it expected that only
 the v8 entry point into Blink shows up when using the profiling tool?

 Any insights would be valuable.

 Thanks,
 Adam

 --
 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users
 ---
 You received this message because you are subscribed to the Google Groups
 v8-users group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to v8-users+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.






 --
 Kentaro Hara, Tokyo, Japan

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
v8-users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[v8-users] Profiling v8 inside chromium/content_shell

[Adam Klein]

I'm trying to profile the v8 execution of a web app using Chromium's
content_shell with some success. But I'm also getting some odd
results. I'm using a commandline like:

content_shell --no-sandbox --js-flags='--prof --noprof-lazy
--log-timer-events' http://localhost:8000/mypage

And then processing the v8.log with

v8/tools/linux-tick-processor v8.log

The resulting profile has some quirks: none of the JavaScript
portion of the profile lists more than 0.2% of the total ticks (even
though there's 500ms of JS execution time as part of the app, as
shown by both plot-timer-events and the Inspector's timeline). The C++
stack, meanwhile, has several major points of interest. Most of the
big ones are Blink C++ callbacks (e.g.,
NodeV8Internal::dispatchEventMethodCallback), and __pthread_cond_wait
shows up. But the top one is __write, usually taking 30% of the
ticks.

If I go down to the call stacks, I get a bunch of LazyCompile
someMethod entries which terminate at __write, so it seems I'm still
getting some idea of which JS is taking the time, but I'm rather
surprised that __write is the endpoint (it's mostly DOM tree
walking/manipulation). Is this expected?

Also, I'm a bit surprised at the way the v8 DOM callbacks end up in
the profile: those methods are usually trivial, with the real work
being somewhere deep in the core of Blink. Is it expected that only
the v8 entry point into Blink shows up when using the profiling tool?

Any insights would be valuable.

Thanks,
Adam

-- 
-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users
--- 
You received this message because you are subscribed to the Google Groups 
v8-users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to v8-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.