[v8-users] Re: [blink-dev] Re: [v8-dev] Re: Intent to Implement: Intl.DisplayNames API Proposal

2019-05-13 Thread PhistucK 
I wonder whether this should be accompanied by an HTML equivalent
declarative way of displaying those strings, otherwise the HTML strings
might be left blank or JavaScript will be required for filling up what
could sometimes be simple forms that were simply internationalized.
Pseudo-code example -

 State/province:
 



☆*PhistucK*


On Tue, May 14, 2019 at 5:03 AM Frank Tang  wrote:

>
>
> On Mon, May 13, 2019 at 6:56 PM 'Frank Tang (譚永鋒)' via v8-dev <
> v8-...@googlegroups.com> wrote:
>
>>
>>
>> *From: *Mathias Bynens 
>> *Date: *Mon, 13 May 2019 at 18:08
>> *To: *Frank Tang
>> *Cc: *v8-users, blink-dev, Adam Klein, Frank Yung-Fong Tang, Sathya
>> Gunasekaran, Nebojša Ćirić, , Jungshik Shin,
>> Shane Carr
>>
>> Can the doc at https://goo.gl/im9wy4 be made public please?
>>>
>>
>> It always is.
>>
>
> sorry it was not. I got confused since I shared with my other account. It
> is now.
>
>>
>>
>>>
>>> Usually we only implement features at stage 3. What’s the motivation for
>>> implementing this particular API earlier? (Not saying I’m opposed to it.)
>>>
>>
>> Since I am the champion of the proposal itself, having a prototype
>> implementation help me to figure out some tricky issues in the
>> specification level. In specific, tricky issues about speed, memory and
>> size that might be avoid if I specify differently. Sometime these thing
>> won't be obvious until implementation. Of course, we can wait till stage 3
>> then implement it, and then if we find out tricky issues which will
>> increase binary size or cause latency problem, we will have to go back to
>> request to change the specification.
>>
>>
>>
>>> *From: *Frank Tang 
>>> *Date: *Mon, May 13, 2019 at 9:43 PM
>>> *To: *v8-users, blink-dev, Adam Klein, Frank Yung-Fong Tang, Sathya
>>> Gunasekaran, Mathias Bynens, Nebojša Ćirić, ,
>>> Jungshik Shin, Shane Carr
>>>
>>> Title: Intent to Implement: Intl.DisplayNames API Proposal



 Contact emails

 ft...@chromium.com



 Explainer

 https://github.com/tc39/proposal-intl-displaynames

 https://tc39.github.io/proposal-intl-displaynames/


 Design doc/Spec

 Engineering Plan https://goo.gl/im9wy4


 Summary

 Provides a new API to get localized names of language, region, script,
 currency codes of international standard as well as commonly used names of
 date fields and symbols.


 Motivation

 Main motivation for Intl.DisplayNames project was to enable developers
 to get translation of language, region or script display names on the
 client. Translation of languages, regions or script display names requires
 large amount of data to transmit on the network, which is already available
 in most browsers. These display name translations also carry steep data
 size penalty for developers. This API will allow web developers to shrink
 the size of their HTML and/ or ECMAScript code without the need to include
 the human readable form of display names and therefore reduce the download
 size to decrease latency. Also, this API will reduce the localization cost
 for the web developers. Our goal is to expose this data through Intl API
 for use in e.g. language, region and script pickers, etc.


 Benefit

-

Reduce download size of apps and therefore improve latency.
-

Easy for users to build internationalized language, region or
script selection UI components (drop down menu or other kinds).
-

Reduce translation cost for developers.
-

Consistent translation of language, region and script display name
on the web.


 Risks

 Interoperability and Compatibility

 This is a new API. It is currently under TC39 Stage 1 and we plan to
 propose to advance it to Stage 2 in June 2019.


 Ergonomics


 Activation

 Web developers could use the API immediately upon our shipment.


 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.


 Link to entry on the feature dashboard 

 https://www.chromestatus.com/feature/4965112605573120


 Requesting approval to ship?

 “No”. The feature is behind a runtime flag harmony_intl_display_names and
 I will later send an Intent to Ship
 
 email when I am ready to

[v8-users] Re: [v8-dev] Re: Intent to Implement: Intl.DisplayNames API Proposal

2019-05-13 Thread Frank Tang 
On Mon, May 13, 2019 at 6:56 PM 'Frank Tang (譚永鋒)' via v8-dev <
v8-...@googlegroups.com> wrote:

>
>
> *From: *Mathias Bynens 
> *Date: *Mon, 13 May 2019 at 18:08
> *To: *Frank Tang
> *Cc: *v8-users, blink-dev, Adam Klein, Frank Yung-Fong Tang, Sathya
> Gunasekaran, Nebojša Ćirić, , Jungshik Shin,
> Shane Carr
>
> Can the doc at https://goo.gl/im9wy4 be made public please?
>>
>
> It always is.
>

sorry it was not. I got confused since I shared with my other account. It
is now.

>
>
>>
>> Usually we only implement features at stage 3. What’s the motivation for
>> implementing this particular API earlier? (Not saying I’m opposed to it.)
>>
>
> Since I am the champion of the proposal itself, having a prototype
> implementation help me to figure out some tricky issues in the
> specification level. In specific, tricky issues about speed, memory and
> size that might be avoid if I specify differently. Sometime these thing
> won't be obvious until implementation. Of course, we can wait till stage 3
> then implement it, and then if we find out tricky issues which will
> increase binary size or cause latency problem, we will have to go back to
> request to change the specification.
>
>
>
>> *From: *Frank Tang 
>> *Date: *Mon, May 13, 2019 at 9:43 PM
>> *To: *v8-users, blink-dev, Adam Klein, Frank Yung-Fong Tang, Sathya
>> Gunasekaran, Mathias Bynens, Nebojša Ćirić, ,
>> Jungshik Shin, Shane Carr
>>
>> Title: Intent to Implement: Intl.DisplayNames API Proposal
>>>
>>>
>>>
>>> Contact emails
>>>
>>> ft...@chromium.com
>>>
>>>
>>>
>>> Explainer
>>>
>>> https://github.com/tc39/proposal-intl-displaynames
>>>
>>> https://tc39.github.io/proposal-intl-displaynames/
>>>
>>>
>>> Design doc/Spec
>>>
>>> Engineering Plan https://goo.gl/im9wy4
>>>
>>>
>>> Summary
>>>
>>> Provides a new API to get localized names of language, region, script,
>>> currency codes of international standard as well as commonly used names of
>>> date fields and symbols.
>>>
>>>
>>> Motivation
>>>
>>> Main motivation for Intl.DisplayNames project was to enable developers
>>> to get translation of language, region or script display names on the
>>> client. Translation of languages, regions or script display names requires
>>> large amount of data to transmit on the network, which is already available
>>> in most browsers. These display name translations also carry steep data
>>> size penalty for developers. This API will allow web developers to shrink
>>> the size of their HTML and/ or ECMAScript code without the need to include
>>> the human readable form of display names and therefore reduce the download
>>> size to decrease latency. Also, this API will reduce the localization cost
>>> for the web developers. Our goal is to expose this data through Intl API
>>> for use in e.g. language, region and script pickers, etc.
>>>
>>>
>>> Benefit
>>>
>>>-
>>>
>>>Reduce download size of apps and therefore improve latency.
>>>-
>>>
>>>Easy for users to build internationalized language, region or script
>>>selection UI components (drop down menu or other kinds).
>>>-
>>>
>>>Reduce translation cost for developers.
>>>-
>>>
>>>Consistent translation of language, region and script display name
>>>on the web.
>>>
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility
>>>
>>> This is a new API. It is currently under TC39 Stage 1 and we plan to
>>> propose to advance it to Stage 2 in June 2019.
>>>
>>>
>>> Ergonomics
>>>
>>>
>>> Activation
>>>
>>> Web developers could use the API immediately upon our shipment.
>>>
>>>
>>> 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.
>>>
>>>
>>> Link to entry on the feature dashboard 
>>>
>>> https://www.chromestatus.com/feature/4965112605573120
>>>
>>>
>>> Requesting approval to ship?
>>>
>>> “No”. The feature is behind a runtime flag harmony_intl_display_names and
>>> I will later send an Intent to Ship
>>> 
>>> email when I am ready to enable by default.
>>>
>>
>
> --
> Frank Yung-Fong Tang
> 譚永鋒 / 
> Sr. Software Engineer
>
> --
> --
> 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.
> To view this discussion on the web visit
>

[v8-users] Re: Intent to Implement: Intl.DisplayNames API Proposal

2019-05-13 Thread 'Mathias Bynens' via v8-users 
Can the doc at https://goo.gl/im9wy4 be made public please?

Usually we only implement features at stage 3. What’s the motivation for
implementing this particular API earlier? (Not saying I’m opposed to it.)

*From: *Frank Tang 
*Date: *Mon, May 13, 2019 at 9:43 PM
*To: *v8-users, blink-dev, Adam Klein, Frank Yung-Fong Tang, Sathya
Gunasekaran, Mathias Bynens, Nebojša Ćirić, ,
Jungshik Shin, Shane Carr

Title: Intent to Implement: Intl.DisplayNames API Proposal
>
>
>
> Contact emails
>
> ft...@chromium.com
>
>
>
> Explainer
>
> https://github.com/tc39/proposal-intl-displaynames
>
> https://tc39.github.io/proposal-intl-displaynames/
>
>
> Design doc/Spec
>
> Engineering Plan https://goo.gl/im9wy4
>
>
> Summary
>
> Provides a new API to get localized names of language, region, script,
> currency codes of international standard as well as commonly used names of
> date fields and symbols.
>
>
> Motivation
>
> Main motivation for Intl.DisplayNames project was to enable developers to
> get translation of language, region or script display names on the client.
> Translation of languages, regions or script display names requires large
> amount of data to transmit on the network, which is already available in
> most browsers. These display name translations also carry steep data size
> penalty for developers. This API will allow web developers to shrink the
> size of their HTML and/ or ECMAScript code without the need to include the
> human readable form of display names and therefore reduce the download size
> to decrease latency. Also, this API will reduce the localization cost for
> the web developers. Our goal is to expose this data through Intl API for
> use in e.g. language, region and script pickers, etc.
>
>
> Benefit
>
>-
>
>Reduce download size of apps and therefore improve latency.
>-
>
>Easy for users to build internationalized language, region or script
>selection UI components (drop down menu or other kinds).
>-
>
>Reduce translation cost for developers.
>-
>
>Consistent translation of language, region and script display name on
>the web.
>
>
> Risks
>
> Interoperability and Compatibility
>
> This is a new API. It is currently under TC39 Stage 1 and we plan to
> propose to advance it to Stage 2 in June 2019.
>
>
> Ergonomics
>
>
> Activation
>
> Web developers could use the API immediately upon our shipment.
>
>
> 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.
>
>
> Link to entry on the feature dashboard 
>
> https://www.chromestatus.com/feature/4965112605573120
>
>
> Requesting approval to ship?
>
> “No”. The feature is behind a runtime flag harmony_intl_display_names 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CADizRgY2QWvOY2xzu1_1CJWGVSk1w6jcuDV790ZwixQx8vMGcg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Intent to Implement: Intl.DisplayNames API Proposal

2019-05-13 Thread Frank Tang 
Title: Intent to Implement: Intl.DisplayNames API Proposal



Contact emails

ft...@chromium.com



Explainer

https://github.com/tc39/proposal-intl-displaynames

https://tc39.github.io/proposal-intl-displaynames/


Design doc/Spec

Engineering Plan https://goo.gl/im9wy4


Summary

Provides a new API to get localized names of language, region, script,
currency codes of international standard as well as commonly used names of
date fields and symbols.


Motivation

Main motivation for Intl.DisplayNames project was to enable developers to
get translation of language, region or script display names on the client.
Translation of languages, regions or script display names requires large
amount of data to transmit on the network, which is already available in
most browsers. These display name translations also carry steep data size
penalty for developers. This API will allow web developers to shrink the
size of their HTML and/ or ECMAScript code without the need to include the
human readable form of display names and therefore reduce the download size
to decrease latency. Also, this API will reduce the localization cost for
the web developers. Our goal is to expose this data through Intl API for
use in e.g. language, region and script pickers, etc.


Benefit

   -

   Reduce download size of apps and therefore improve latency.
   -

   Easy for users to build internationalized language, region or script
   selection UI components (drop down menu or other kinds).
   -

   Reduce translation cost for developers.
   -

   Consistent translation of language, region and script display name on
   the web.


Risks

Interoperability and Compatibility

This is a new API. It is currently under TC39 Stage 1 and we plan to
propose to advance it to Stage 2 in June 2019.


Ergonomics


Activation

Web developers could use the API immediately upon our shipment.


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.


Link to entry on the feature dashboard 

https://www.chromestatus.com/feature/4965112605573120


Requesting approval to ship?

“No”. The feature is behind a runtime flag harmony_intl_display_names 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CAOcELL-oXxvg5OgbukD54YfT9h0QcURtbTXnM7XSrzxDz3tPYA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Wanting to understand V8 WorkerThread(s)

2019-05-13 Thread Joel Scarfone 
Hi All! I have a very simple program as follows that just creates an 
isolate, then sleeps:

#include 
#include 
#include 

#include 
#include 

using v8::Isolate;

int main() {

   std::unique_ptr platform = 
v8::platform::NewDefaultPlatform();
   v8::V8::InitializePlatform(platform.get());
   v8::V8::Initialize();

   v8::Isolate::CreateParams create_params;
   create_params.array_buffer_allocator = 
v8::ArrayBuffer::Allocator::NewDefaultAllocator();
   Isolate* isolate = v8::Isolate::New(create_params);


   printf("Sleeping...\n");
   usleep(1000 * 1000 * 100);
   printf("Done\n");
   return 0;
}

When i run this program, i can then check the number of threads the process 
has created with ps -T -p , and i see that on my 8 core 
machine, v8 creates 7 extra threads all named "V8 WorkerThread", and on my 
16 core machine i get 8 instances of this "V8 WorkerThread" created. 

I am looking to understand what determines the number of extra threads v8 
spawns and what the purpose of these threads are. Thanks in advance!

Joel

-- 
-- 
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/acda7808-6ff7-4201-93fe-75052243d29d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

2019-05-13 Thread Frank Tang 
to: blink-api-owners-disc...@chromium.org



On Thu, May 9, 2019 at 8:22 PM Frank Tang  wrote:

> Intend to ship for Chrome m76
>
>
> Title: Intent to Ship: 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)
>
>
> Spec
>
>
> https://rawgit.com/fabalbon/proposal-intl-DateTimeFormat-formatRange/master/out/
>
> Design Doc https://goo.gl/PGUQ1d
> Why the tag review process is being skipped: JavaScript features do not
> need to go through a TAG review, as they already get significant scrutiny
> as part of the TC39 staging process
> .
>
>
>
> Summary
>
> Add two new functions to Intl.DateTimeFormat.prototype - formateRange and
> formatRangeToParts to formate the range of two dates in a given locale.
>
>
> Link to “Intent to Implement” blink-dev discussion
>
>
> https://groups.google.com/a/chromium.org/forum/?fromgroups#!searchin/blink-dev/DateTimeFormat%7Csort:date/blink-dev/WTAjjcXaraA/osqw0lCpBAAJ
>
>
>
> Is this feature supported on all six Blink platforms (Windows, Mac, Linux,
> Chrome OS, Android, and Android WebView)?
>
> Yes
>
>
> Demo link
>
> https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange
>
>
> Debuggability
>
> Nothing special.
>
>
>
> Risks
>
> Interoperability and Compatibility
>
> This is a new API which agreed in TC39 meeting as a Stage 3 proposal.
> Engineer from Firefox team is supporting this proposal and the development
> is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1496584
>
>
> 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.
>
>
>
> Is this feature fully tested by web-platform-tests
> ?
> Link to test suite results from wpt.fyi.
>
>
> Tests under tc39/test262 will includes many tests to test this API.
>
> test/intl402/DateTimeFormat/prototype/formatRange
> 
> and
>
> test/intl402/DateTimeFormat/prototype/formatRangeToParts
> 
>
>
> Testing Status (since the feature is currently behind a flag, the
> breakage, which does not include the flag turning on is high. Once shipped,
> with the flag turn on by default, the passing rate will turn to 100%)
> https://test262.report/browse/intl402/DateTimeFormat/prototype/formatRange
>
> https://test262.report/browse/intl402/DateTimeFormat/prototype/formatRangeToParts
>
> Entry on the feature dashboard 
> https://www.chromestatus.com/feature/5077134515109888
>

-- 
-- 
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/CAOcELL8YQJXzJ_g%2BFKskAsFmGjWExziQ0%2Btp1STn%2BQ9zMbabrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[v8-users] Re: The V8 JS language launch process is deprecated, use Blink Intents instead

2019-05-13 Thread Michael Hablich 
FYI, there were some small changes around the TAG review requirements:

"For smaller JavaScript or WebAssembly features, a TAG review is not
required, as TC39 and the Wasm CG already provide significant technical
oversight. If the feature is large or cross-cutting (e.g., requires changes
to other Web Platform APIs or modifications to Chromium), TAG review is
recommended."

The docs were updated accordingly.

Cheers,
Michael

*From: *Michael Hablich 
*Date: *Thu, Apr 25, 2019 at 4:22 PM
*To: *Michael Hablich Hablich
*Cc: *Adam Klein, , 

Hi folks,
> as of now, please do not use the old V8 JS language launch process for
> launching new JS features. *Please use the Blink intent process instead,
> if you want to develop WebAssembly and JavaScript language features*.
> More information and details can be found here
> .
>
> *Why this change? *
> The old V8 JS language launch process was created in a world before the
> revisited Blink intent process. Nowadays, besides JavaScript also
> WebAssembly is supported by V8. As a lot of WebAssembly-focused features
> are not only implemented in V8 but also in Chromium, V8's own Feature
> Launch Process was not adequate enough. Thus, for WebAssembly features the
> Blink-intent process is already used. In order to remove process complexity
> (and ambiguity) V8 is deprecating its own Feature Launch Process and fully
> adopt Blink-intent for JS features too.
>
> *Does this affect non-language features?*
> No, only features that change the Web Platform API need to follow Blink
> intents.
>
> If you have any questions, please feel free to get in touch with me.
>
> Cheers,
> Michael
>

-- 
-- 
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/CAF2MX8gzXUELc5gd7o4D7BUxy%3DZ9nRzb_NBmdauVrW2bGpqxxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.