[v8-users] Re: [blink-dev] Re: [v8-dev] Re: Intent to Implement: Intl.DisplayNames API Proposal
Thank you for your thoughts, all. I filed an issue with HTML - https://github.com/whatwg/html/issues/4630 ☆*PhistucK* On Wed, May 15, 2019 at 10:52 PM Shane Carr wrote: > Hi PhistucK, > > Thanks for the feedback! Adding HTML for Intl features would be out of > scope for this feature. We already have JavaScript-based i18n features > like Intl.NumberFormat, Intl.DateFormat, etc., and Intl.DisplayNames is > being implemented in the same fashion. > > You may be interested in discussions such as: > > https://github.com/tc39/ecma402/issues/92 > > You can also open a new thread on the ECMA 402 repo. > > Shane > > On Wed, May 15, 2019 at 9:48 AM Frank Tang wrote: > >> Sorry, I am not quite sure what you mean. It seems to me a suggestion of >> proposing additional standard in HTML spec. Do you mind to raise the issue >> in https://github.com/tc39/proposal-intl-displaynames/issues with more >> information so other members in ECMA402 subcommittee can help me to take >> action to talk to the related parties? >> >> Thanks >> >> On Mon, May 13, 2019 at 10:41 PM PhistucK wrote: >> >>> 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 internationalize
Re: [v8-users] gc and threading
Thanks! > While I understand that this is tempting, please be aware that only one thread may be active in one Isolate at any given time. I was hoping that there could be multiple threads that had "read-only" access to an Isolate's heap - I was looking through how ValueSerializer works and now I understand there's no such thing as "read-only" given the getter/setter functions. However, wondering if this would be possible for simple objects (key/value) and bail for more complex ones. Any other suggestions for how that work can be parallelized, is it even possible? (this is custom serialization, not JSON) On Wednesday, May 15, 2019 at 11:34:11 AM UTC-7, Jakob Kummerow wrote: > > I'm trying to improve some serialization code in NodeJS and was wondering >> if this could be achieved by going down to the native code and using >> multiple threads to parallelize the serialization of multiple objects. For >> example, imagine we need to serialize 1K objects to JSON/OtherFormat - >> split into 4 x 250 batches and use 4 (non-main) threads to serialize the >> objects, then gather the results and return. >> > > While I understand that this is tempting, please be aware that only one > thread may be active in one Isolate at any given time. Lifting this > restriction would require huge effort, and/or only apply in limited > circumstances (e.g., when an object has a custom toJSON function, you > would have to bail out somehow, because such a function could cause > arbitrary modifications to any other object). > > >> However, I'm having a bit of a hard time understanding a few concepts: >> >> 1. when does the GC kick in for an Isolate? my understanding is that *any >> *V8 code executed in an Isolate can trigger GC for that Isolate - is >> this correct? >> > > Any *allocation* on the managed heap can trigger GC. Of course, when you > don't know what code you're calling (e.g., a user-provided function), then > you have to assume that it might allocate. We use DisallowHeapAllocation > scopes to guard sections where we are sure that no allocation (and hence no > GC) can happen. > > 2. when GC triggers, what happens to pointers that might have been >> extracted from Handle *and* the Handle is still in scope? >> >> HandleScope scope(isolate); >> Handle foo = ... >> Object* fooPtr = *foo; >> someCallThatTriggersGC() >> // is fooPtr still valid??? >> > > Raw pointers will become stale, no matter where they came from. So in this > example, fooPtr will be invalid; foo will still be valid (that's the > point of having Handles). > > -- -- 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/183feb94-a4c4-44e6-b881-02d40fa9bd8b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [v8-users] gc and threading
> > I'm trying to improve some serialization code in NodeJS and was wondering > if this could be achieved by going down to the native code and using > multiple threads to parallelize the serialization of multiple objects. For > example, imagine we need to serialize 1K objects to JSON/OtherFormat - > split into 4 x 250 batches and use 4 (non-main) threads to serialize the > objects, then gather the results and return. > While I understand that this is tempting, please be aware that only one thread may be active in one Isolate at any given time. Lifting this restriction would require huge effort, and/or only apply in limited circumstances (e.g., when an object has a custom toJSON function, you would have to bail out somehow, because such a function could cause arbitrary modifications to any other object). > However, I'm having a bit of a hard time understanding a few concepts: > > 1. when does the GC kick in for an Isolate? my understanding is that *any > *V8 code executed in an Isolate can trigger GC for that Isolate - is > this correct? > Any *allocation* on the managed heap can trigger GC. Of course, when you don't know what code you're calling (e.g., a user-provided function), then you have to assume that it might allocate. We use DisallowHeapAllocation scopes to guard sections where we are sure that no allocation (and hence no GC) can happen. 2. when GC triggers, what happens to pointers that might have been > extracted from Handle *and* the Handle is still in scope? > > HandleScope scope(isolate); > Handle foo = ... > Object* fooPtr = *foo; > someCallThatTriggersGC() > // is fooPtr still valid??? > Raw pointers will become stale, no matter where they came from. So in this example, fooPtr will be invalid; foo will still be valid (that's the point of having Handles). -- -- 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/CAKSzg3TQRFkgXD1GMGDEAYJS3RSuBW_L-AqpLq2CPc16D30O%2BA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[v8-users] gc and threading
I'm trying to improve some serialization code in NodeJS and was wondering if this could be achieved by going down to the native code and using multiple threads to parallelize the serialization of multiple objects. For example, imagine we need to serialize 1K objects to JSON/OtherFormat - split into 4 x 250 batches and use 4 (non-main) threads to serialize the objects, then gather the results and return. However, I'm having a bit of a hard time understanding a few concepts: 1. when does the GC kick in for an Isolate? my understanding is that *any *V8 code executed in an Isolate can trigger GC for that Isolate - is this correct? 2. when GC triggers, what happens to pointers that might have been extracted from Handle *and* the Handle is still in scope? HandleScope scope(isolate); Handle foo = ... Object* fooPtr = *foo; someCallThatTriggersGC() // is fooPtr still valid??? -- -- 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/5d85892d-d7ca-4cda-a7c2-9551fc301cfb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[v8-users] Re: [blink-dev] Re: [v8-dev] Re: Intent to Implement: Intl.DisplayNames API Proposal
Sorry, I am not quite sure what you mean. It seems to me a suggestion of proposing additional standard in HTML spec. Do you mind to raise the issue in https://github.com/tc39/proposal-intl-displaynames/issues with more information so other members in ECMA402 subcommittee can help me to take action to talk to the related parties? Thanks On Mon, May 13, 2019 at 10:41 PM PhistucK wrote: > 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 >
