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

[PhistucK]

It is pending review, so not going to stage 3 just yet.

☆*PhistucK*


On Mon, Jan 6, 2020 at 8:07 PM Frank Tang  wrote:

>
>
> On Mon, Jan 6, 2020 at 10:05 AM Frank Tang  wrote:
>
>>
>>
>> On Sun, Jan 5, 2020 at 11:21 PM Yoav Weiss  wrote:
>>
>>>
>>>
>>> On Fri, Jan 3, 2020 at 7:49 PM Frank Tang  wrote:
>>>
>>>>
>>>>
>>>> On Thu, Jan 2, 2020 at 10:34 AM Frank Tang  wrote:
>>>>
>>>>> still need one more
>>>>>
>>>>> On Fri, Dec 27, 2019 at 12:12 PM Chris Harrelson <
>>>>> chris...@chromium.org> wrote:
>>>>>
>>>>>> LGTM2
>>>>>>
>>>>>> On Fri, Dec 27, 2019 at 12:01 PM Daniel Bratell 
>>>>>> wrote:
>>>>>>
>>>>>>> LGTM1
>>>>>>>
>>>>>>> /Daniel
>>>>>>>
>>>>>>>
>>>>>>> On 2019-12-26 23:03, Frank Tang wrote:
>>>>>>>
>>>>>>>
>>>>>>> Contact emails ft...@chromium.org,js...@chromium.org Explainer
>>>>>>> https://github.com/tc39/proposal-intl-displaynames Spec
>>>>>>> https://tc39.github.io/proposal-intl-displaynames/ TAG review A
>>>>>>> small JavaScript features, a TAG review is not required, as TC39 already
>>>>>>> provide significant technical oversight. 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. Link to “Intent to Prototype” blink-dev discussion
>>>>>>> https://mail.google.com/mail/u/0/#search/Intl.DisplayNames+Intent/KtbxLwgxBjLmZRWGMwZfjnVwNFvdndwvBq
>>>>>>> Risks
>>>>>>> Interoperability and Compatibility This is a new API. It is
>>>>>>> currently under TC39 Stage 3. *Firefox*: No public signals
>>>>>>>
>>>>>>> for mozilla , Zibi from mozilla were the original spec champion .
>> They filed tracking bug in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1557727
>>
>>> *Edge*: No public signals *Safari*: No public signals *Web developers*:
>>>>>>> No signals
>>>>>>>
>>>>>>> I'm assuming that at least some of the above supported the proposal
>>> in order for it to make it to stage 3...
>>>
>>
>> TC39 meeting not to propose to Stage 3
>>
>> https://github.com/tc39/notes/blob/master/meetings/2019-10/october-2.md#intldisplaynames
>>
>
> sorry. Typo. I mean to write " TC39 meeting note to..." not "TC39 meeting
> not to..." fat finger missed a 'e' before I sent the reply.
>
>>
>>
>>
>>
>>>
>>>> Ergonomics The implementation depend on pre-existing functions in
>>>>>>> already linked in ICU library During the prototype phrase we identify no
>>>>>>> small size increase impact since all the strings were already included 
>>>>>>> to
>>>>>>> support other Chrome functionality.
>>>>>>>
>>>>>>> The "Ergonomics" section refers to developer ergonomics of the
>>> feature itself and how web developers would use it, not to the ergonomics
>>> of Chromium engineers developing it.
>>>
>>
>>
>>
>>>
>>>
>>>> Activation Web developers could use the API immediately upon our
>>>>>>> shipment. Security Web developers could use the API immediately
>>>>>>> upon our shipment.
>>>>>>>
>>>>>>> The "Security" section refers to the security considerations of the
>>> feature, and whether we believe it puts users at risk. I believe the answer
>>> is no, but can you confirm?
>>>
>>
>> Agree. The answer is NO
>>
>>> Debuggability Nothing special. Will this feature be supported on all
>>>>>>> six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and 
>>>>>>> Android
>>>>>>> WebView)? Yes It will be supported on all platform. Is this feature
>>>>>>> fully tested by web-platform-tests
>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests

Re: [v8-users] Re: [blink-dev] Re: Intent to Implement: JavaScript Optional Chaining

[PhistucK]

Is this intentionally not an intent to implement and ship, by the way?

☆*PhistucK*


On Mon, Aug 12, 2019 at 7:32 PM 'Gabriel Giannattasio' via blink-dev <
blink-...@chromium.org> wrote:

> This is a great feature to add, looking forward to seeing it in production
> :)
>
> On Wed, Aug 7, 2019 at 12:11 AM PhistucK  wrote:
>
>> This is great, I am really looking forward to using this (disclaimer - I
>> also advocated
>> <https://discourse.wicg.io/t/the-get-member-if-not-null-or-undefined-else-bail/1858>
>> the feature a few years back).
>> It might ease code writing/reading almost as much as destructuring and
>> arrow functions.
>>
>> ☆*PhistucK*
>>
>>
>> On Wed, Aug 7, 2019 at 2:56 AM Boris Zbarsky  wrote:
>>
>>> On 8/6/19 5:55 PM, Gus Caplan wrote:
>>> > Firefox: Public support (
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1566143)
>>>
>>> For what it's worth, there are no signals from Mozilla in that bug
>>> report, as far as I can tell.
>>>
>>> -Boris
>>>
>>> --
>>> 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/81d281b9-4511-f409-b400-334622534d48%40mit.edu
>>> .
>>>
>> --
>> --
>> 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/CABc02_LpY0whmD5XKQGgV6ts9K6Ot8wxLyKKnZcr-LAy%2BMB0yw%40mail.gmail.com
>> <https://groups.google.com/d/msgid/v8-users/CABc02_LpY0whmD5XKQGgV6ts9K6Ot8wxLyKKnZcr-LAy%2BMB0yw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> - Gabriel
>
> --
> 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/CAJg_o_mszSfRzTpORuLKsggLuhZBs-LGzaKtRsKm-xVa1wVkig%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJg_o_mszSfRzTpORuLKsggLuhZBs-LGzaKtRsKm-xVa1wVkig%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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/v8-users/CABc02_JamoNUmG0nZD3TLOX-QD6FfQ5ZcqOVe4Zn6wZ3_TF3cg%40mail.gmail.com.

[v8-users] Re: [blink-dev] Re: Intent to Implement: JavaScript Optional Chaining

[PhistucK]

This is great, I am really looking forward to using this (disclaimer - I
also advocated
<https://discourse.wicg.io/t/the-get-member-if-not-null-or-undefined-else-bail/1858>
the feature a few years back).
It might ease code writing/reading almost as much as destructuring and
arrow functions.

☆*PhistucK*


On Wed, Aug 7, 2019 at 2:56 AM Boris Zbarsky  wrote:

> On 8/6/19 5:55 PM, Gus Caplan wrote:
> > Firefox: Public support (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1566143)
>
> For what it's worth, there are no signals from Mozilla in that bug
> report, as far as I can tell.
>
> -Boris
>
> --
> 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/81d281b9-4511-f409-b400-334622534d48%40mit.edu
> .
>

-- 
-- 
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/CABc02_LpY0whmD5XKQGgV6ts9K6Ot8wxLyKKnZcr-LAy%2BMB0yw%40mail.gmail.com.

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

[PhistucK]

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
>

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

[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
&g

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

[PhistucK]

Can you make the example clearer?
["...", index: 0, input: "..."] is unfamiliar, invalid syntax.

☆*PhistucK*


On Fri, Dec 14, 2018 at 2:19 AM 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.
>
> --
> 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/CAAKm-Q%2BuNU%3D%2BbSgu87THKGedRbf1OuCQSsJbmRgK5iPWAVO%2BDA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAKm-Q%2BuNU%3D%2BbSgu87THKGedRbf1OuCQSsJbmRgK5iPWAVO%2BDA%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: Public class fields

[PhistucK]

Are the specification and implementation compatible with the Babel based
implementation/interpretation of the feature? After all, previously
transpiled code could now be interpreted natively...
Unfortunately, this is also considered "Web compatibility".

☆*PhistucK*


On Wed, Oct 17, 2018 at 10: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 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%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.

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

[PhistucK]

Great catch goes to han.guokai@ which filed the original issue. :)

By the way, all of the pull requests were merged, so mostly accidentally
old code would be broken at this point (unless new cases were added since
then :().

I will work on the change list again soon.

☆*PhistucK*


On Thu, Sep 6, 2018 at 8:00 PM Daniel Ehrenberg 
wrote:

> I'm comfortable with this change as well. A relatively new API like this,
> which is implemented compliantly in another browser, seems likely to have
> relatively low compatibility risk. It will still be some time until these
> new Intl features gain uptake to replace JS libraries like Globalize that
> serve the same purpose. Great catch, PhistucK, and thanks for following up
> so thoroughly in this report.
>
> Dan
>
> On Tue, Aug 28, 2018 at 7:25 PM Adam Klein  wrote:
>
>> 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 speculatio

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

[PhistucK]

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.



>
>
>> 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...



>
>
>> 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?
>

It is probably much more than I bargained for (especially the delay until
we get results and usage can increase by the day). ;) But if you have a
change list I can follow for guidance, I might just do that (barring a
positive response from Jungshik).



>
>
>> 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", "v

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

[PhistucK]

Thoughts, anyone?

☆*PhistucK*


On Fri, Jul 27, 2018 at 12:13 AM 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)?
>
> 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...
>
>
> 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)?
>
>
> 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
>>> -
>>>
>>> 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

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

[PhistucK]

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)?

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...


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)?


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
>> -
>>
>> 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".
>>
>&

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

[PhistucK]

Yep, I know. No rush.

☆*PhistucK*


On Fri, Jul 20, 2018 at 9:24 PM Chris Harrelson 
wrote:

>
>
> On Fri, Jul 20, 2018 at 10:00 AM PhistucK  wrote:
>
>> Guess so, though I am personally not going through with the change if
>> there are any blink-dev reservations. ;)
>>
>
> Ok. You will need an LGTM from a v8 representative though. They will
> respond soon.
>
>
>>
>> ☆*PhistucK*
>>
>>
>> On Fri, Jul 20, 2018 at 7:55 PM Philip Jägenstedt 
>> wrote:
>>
>>> This is an FYI for blink-dev, right? Should I remove it from
>>> https://bit.ly/blinkintents?
>>>
>>> On Fri, Jul 20, 2018 at 5:56 PM 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
>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>> ?
>>>>
>>>> Nope, but it is tested by test262, though not this case (which is
>>>> apparently why the interoperability issue exists).
>>>>
>>>> *I submitt

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

[PhistucK]

Guess so, though I am personally not going through with the change if there
are any blink-dev reservations. ;)

☆*PhistucK*


On Fri, Jul 20, 2018 at 7:55 PM Philip Jägenstedt 
wrote:

> This is an FYI for blink-dev, right? Should I remove it from
> https://bit.ly/blinkintents?
>
> On Fri, Jul 20, 2018 at 5:56 PM 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
>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>> ?
>>
>> 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
>> <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/>
>> 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
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2B1xEoNvCtuc4ocTw%3DtLmfHmT-z-cFTuiE6YS9Q_MdPqg%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] Intent to Implement and Ship: rename Intl.DateTimeFormat.prototype.formatToParts type "dayperiod" to "dayPeriod"

[PhistucK]

(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
<https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
?

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
<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/>
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*

-- 
-- 
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: JSON ⊂ ECMAScript

[PhistucK]

I know.

Regarding "public support" - not "opposed" does not necessarily mean
"support" (it could be neutral). Transparency is important in
chromestatus.com (and in intent, I would argue).
Second, web developers are not part of the TC39 stages, so support or
reactions from them are not a given (not as far as "strongly positive").
I think it makes sense to add links for opinions that are not your own.

Just my two or three cents.


☆*PhistucK*

On Fri, Feb 16, 2018 at 3:07 PM, Mathias Bynens <m...@google.com> 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.
>
> For ECMAScript features like this one, if a browser vendor would be
> opposed to this proposal, they would block its advancement at TC39. Given
> that this proposal already made it to Stage 3 I would be surprised if
> vendors would suddenly change their mind now.
>
> On Fri, Feb 16, 2018 at 1:50 PM, PhistucK <phist...@gmail.com> wrote:
>
>> (At least on blink-dev)
>> "Interoperability risk" should have links for citing each vendor and web
>> developer support.
>>
>>
>> ☆*PhistucK*
>>
>> On Fri, Feb 16, 2018 at 2:15 PM, Mathias Bynens <math...@chromium.org>
>> wrote:
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *Contact emailsmath...@chromium.org
>>> <math...@chromium.org>Spechttps://github.com/tc39/proposal-json-superset
>>> <https://github.com/tc39/proposal-json-superset>SummaryA Stage 3 proposal
>>> makes ECMAScript a syntactic superset of JSON by allowing U+2028 and U+2029
>>> in string literals.MotivationECMAScript claims JSON as a subset in
>>> JSON.parse <https://tc39.github.io/ecma262/#sec-json.parse>, but (as has
>>> been well-documented) that is not true because JSON strings can contain
>>> unescaped U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR characters
>>> while ECMAScript strings cannot.These exceptions add unnecessary complexity
>>> to the specification and increase the cognitive burden on both implementers
>>> and users, allowing for the introduction of subtle bugs. Also, as a lesser
>>> but concrete corollary problem, certain source concatenation and
>>> construction tasks currently require additional steps to process valid JSON
>>> into valid ECMAScript before embedding it.Interoperability riskFirefox:
>>> Public supportEdge: Public supportSafari: Public supportWeb developers:
>>> Strongly positiveCompatibility riskThis change is backwards-compatible.
>>> User-visible effects will be limited to the elimination of SyntaxError
>>> completions when parsing strings that include unescaped LINE SEPARATOR or
>>> PARAGRAPH SEPARATOR characters, which in practice are uncommon.Is this
>>> feature fully tested?Yes; see
>>> v8/test/cctest/test-parsing/LineOrParagraphSeparator{AsLineTerminator,InStringLiteral,InStringLiteralHarmony}.Tracking
>>> bughttps://bugs.chromium.org/p/v8/issues/detail?id=7418
>>> <https://bugs.chromium.org/p/v8/issues/detail?id=7418>Link to entry on the
>>> Chrome Platform Status
>>> dashboardhttps://www.chromestatus.com/features/6102319234023424
>>> <https://www.chromestatus.com/features/6102319234023424>Requesting approval
>>> to ship?Yes*
>>>
>>> --
>>> 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/CAJYpFjDOzdTHBNJR0oheBPOtKCETJQ
>>> UxPqd3pYCz3DA8%3DGKRTg%40mail.gmail.com
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJYpFjDOzdTHBNJR0oheBPOtKCETJQUxPqd3pYCz3DA8%3DGKRTg%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: JSON ⊂ ECMAScript

[PhistucK]

(At least on blink-dev)
"Interoperability risk" should have links for citing each vendor and web
developer support.


☆*PhistucK*

On Fri, Feb 16, 2018 at 2:15 PM, Mathias Bynens <math...@chromium.org>
wrote:

>
>
>
>
>
>
>
>
>
> *Contact emailsmath...@chromium.org
> <math...@chromium.org>Spechttps://github.com/tc39/proposal-json-superset
> <https://github.com/tc39/proposal-json-superset>SummaryA Stage 3 proposal
> makes ECMAScript a syntactic superset of JSON by allowing U+2028 and U+2029
> in string literals.MotivationECMAScript claims JSON as a subset in
> JSON.parse <https://tc39.github.io/ecma262/#sec-json.parse>, but (as has
> been well-documented) that is not true because JSON strings can contain
> unescaped U+2028 LINE SEPARATOR and U+2029 PARAGRAPH SEPARATOR characters
> while ECMAScript strings cannot.These exceptions add unnecessary complexity
> to the specification and increase the cognitive burden on both implementers
> and users, allowing for the introduction of subtle bugs. Also, as a lesser
> but concrete corollary problem, certain source concatenation and
> construction tasks currently require additional steps to process valid JSON
> into valid ECMAScript before embedding it.Interoperability riskFirefox:
> Public supportEdge: Public supportSafari: Public supportWeb developers:
> Strongly positiveCompatibility riskThis change is backwards-compatible.
> User-visible effects will be limited to the elimination of SyntaxError
> completions when parsing strings that include unescaped LINE SEPARATOR or
> PARAGRAPH SEPARATOR characters, which in practice are uncommon.Is this
> feature fully tested?Yes; see
> v8/test/cctest/test-parsing/LineOrParagraphSeparator{AsLineTerminator,InStringLiteral,InStringLiteralHarmony}.Tracking
> bughttps://bugs.chromium.org/p/v8/issues/detail?id=7418
> <https://bugs.chromium.org/p/v8/issues/detail?id=7418>Link to entry on the
> Chrome Platform Status
> dashboardhttps://www.chromestatus.com/features/6102319234023424
> <https://www.chromestatus.com/features/6102319234023424>Requesting approval
> to ship?Yes*
>
> --
> 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/CAJYpFjDOzdTHBNJR0oheBPOtKCETJ
> QUxPqd3pYCz3DA8%3DGKRTg%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJYpFjDOzdTHBNJR0oheBPOtKCETJQUxPqd3pYCz3DA8%3DGKRTg%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:

[PhistucK]

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/
> chromium.org/d/msgid/blink-dev/a0cfab54-5c05-4c81-8a60-
> a735762922ce%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:

[PhistucK]

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.
>

-- 
-- 
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:

[PhistucK]

On Wed, Jun 21, 2017 at 6:25 PM, Domenic Denicola  wrote:

> 

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

[PhistucK]

Thank you! A few minor failures are not worrying, indeed. :)

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)


☆*PhistucK*

On Wed, Jun 21, 2017 at 6:54 PM, Adam Klein <ad...@chromium.org> wrote:

> On Wed, Jun 21, 2017 at 8:25 AM, Domenic Denicola <d...@domenic.me> 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:

[PhistucK]

Since there is no intent-to-ship-modules thread in V8 (and since this
intent brings module support into HTML as well as scripts and not just one
or the other), I think the test262 question is very much appropriate in
this thread (you may disagree, but I may, too ;)).


☆*PhistucK*

On Wed, Jun 21, 2017 at 6:25 PM, Domenic Denicola <d...@domenic.me> 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:

[PhistucK]

On Wed, Jun 21, 2017 at 4:44 AM, Kouhei Ueno <kou...@chromium.org> wrote:

> Is this feature fully tested by web-platform-tests
> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
> ?
>
> Yes
> <https://github.com/w3c/web-platform-tests/tree/master/html/semantics/scripting-1/the-script-element/module>.
> Extensive contributions to web platform tests have been contributed by
> Edge, WebKit, Blink, and V8 engineers during spec and implementation
> development.
>

What about test-262 (web-platform-tests are not supposed to test ECMAScript
features) for modules?​
Are all of the test-262 tests run on modules as well (at least those that
do not require sloppy mode features, because if I remember correctly,
modules always run in strict mode)?


​Also, how does this integrate with service workers? Is there a type or
something that signals that the fetch event is for a module fetch?



☆*PhistucK*

-- 
-- 
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: Trailing comma in JavaScript function parameter lists

[PhistucK]

On Fri, Jan 13, 2017 at 11:55 PM, jwolfe <jwo...@igalia.com> wrote:

> Edge is shipping with this feature enabled ( https://kangax.github.io/
> compat-table/es2016plus/ ).
>

​Actually, it is only shipping in preview builds of Windows 10 Creator's
Update. EdgeHTML 15 is not the current stable build​. So the situation is
the same as with WebKit and Gecko.

I really do not like this feature (why does C++ exclude this?)...
JavaScript is loose enough as it is, but this is not the place for such
feedback. :)



☆*PhistucK*

-- 
-- 
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] Breaking On Native Function Calls

[PhistucK]

Yes, I am. I already noticed it is blocking the Chromium issue.
Thank you!


☆*PhistucK*

On Thu, Oct 20, 2016 at 9:33 AM, Yang Guo <yang...@chromium.org> wrote:

> I guess you are looking for https://bugs.chromium.org/
> p/v8/issues/detail?id=178
>
> This is a long standing feature request that has not been addressed yet.
> I'll add it to our backlog.
>
> On Thursday, October 20, 2016 at 7:55:38 AM UTC+2, PhistucK wrote:
>>
>> File ​crbug.com/657697​ (and crbug.com/657700 for a related bug I found
>> as a result :(). But it is really a duplicate of crbug.com/49 (so I
>> closed mine). I guess it will not be in progress soon. :(
>>
>>
>> ☆*PhistucK*
>>
>> On Thu, Oct 20, 2016 at 8:19 AM, Jochen Eisinger <joc...@chromium.org>
>> wrote:
>>
>>> As far as I know that's not possible. Could you file a feature request
>>> for this (probably on crbug.com if you also want to cover DOM functions)
>>>
>>> On Wed, Oct 19, 2016 at 7:38 PM PhistucK <phis...@gmail.com> wrote:
>>>
>>>> I wanted to know whether there is a V8 (or Chrome) flag of some sort
>>>> that will let me add breakpoints on native function calls.
>>>> I do not mean C++ functions, I mean built in web platform (or
>>>> ECMAScript) functions.
>>>> My issue is that I click on a link and suddenly some code is apparently
>>>> calling document.location.replace("foo") or something and the page
>>>> redirects (maliciously). In order to find the calling code, I want to set a
>>>> breakpoint on calling document.location.replace, which is a native web
>>>> platform function, that is not writable (so I cannot override it with my
>>>> own function using Object.defineProperty, or use a proxy).
>>>> (The code is apparently elusive and obfuscated somewhat, so it is not
>>>> just a search and replace)
>>>> I tried using the Developer Tools API - debug(function), but it did not
>>>> break (even when I call it with setTimeout).
>>>>
>>>> A V8 flag (or a Chrome flag) that either lets me break on calling that
>>>> function, or that overrides the security feature that makes it
>>>> non-writable, or something like that, would let me see the code that calls
>>>> it and find the malicious way it does so.
>>>>
>>>> So, is there something like that?
>>>>
>>>> Thank you!
>>>>
>>>> --
>>>> --
>>>> 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 a topic in the
>>> Google Groups "v8-users" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>> pic/v8-users/j2CPHefGEmQ/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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 a topic in the
> Google Groups "v8-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/v8-users/j2CPHefGEmQ/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Breaking On Native Function Calls

[PhistucK]

Yeah, I wish. I do not have a strong machine yet. :(

I wanted to try an old version of Chromium (which does not have
[Unforgeable] yet), but my corporate proxy is blocking me from using the
site in question. I will try again when I am home.


☆*PhistucK*

On Thu, Oct 20, 2016 at 9:31 AM, Krzysztof Olczyk <kolc...@opera.com> wrote:

> If making your own build of Chromium for your investigation purposes makes
> sense to you,
> it should work for you to remove "Unforgeable" here:
> https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/frame/
> Window.idl?l=41
>
> Then, you could defineProperty window.location to your "proxy" object.
>
>
>
> --
> Best regards,
> *Krzysztof Olczyk*
> Software Developer & Architect
> TVSDK Core team
>
> Opera TV
> Pl. Teatralny 8, 50-051 Wroclaw, Poland
>
> On Thu, Oct 20, 2016 at 7:54 AM, PhistucK <phist...@gmail.com> wrote:
>
>> File ​crbug.com/657697​ (and crbug.com/657700 for a related bug I found
>> as a result :(). But it is really a duplicate of crbug.com/49 (so I
>> closed mine). I guess it will not be in progress soon. :(
>>
>>
>> ☆*PhistucK*
>>
>> On Thu, Oct 20, 2016 at 8:19 AM, Jochen Eisinger <joc...@chromium.org>
>> wrote:
>>
>>> As far as I know that's not possible. Could you file a feature request
>>> for this (probably on crbug.com if you also want to cover DOM functions)
>>>
>>> On Wed, Oct 19, 2016 at 7:38 PM PhistucK <phist...@gmail.com> wrote:
>>>
>>>> I wanted to know whether there is a V8 (or Chrome) flag of some sort
>>>> that will let me add breakpoints on native function calls.
>>>> I do not mean C++ functions, I mean built in web platform (or
>>>> ECMAScript) functions.
>>>> My issue is that I click on a link and suddenly some code is apparently
>>>> calling document.location.replace("foo") or something and the page
>>>> redirects (maliciously). In order to find the calling code, I want to set a
>>>> breakpoint on calling document.location.replace, which is a native web
>>>> platform function, that is not writable (so I cannot override it with my
>>>> own function using Object.defineProperty, or use a proxy).
>>>> (The code is apparently elusive and obfuscated somewhat, so it is not
>>>> just a search and replace)
>>>> I tried using the Developer Tools API - debug(function), but it did not
>>>> break (even when I call it with setTimeout).
>>>>
>>>> A V8 flag (or a Chrome flag) that either lets me break on calling that
>>>> function, or that overrides the security feature that makes it
>>>> non-writable, or something like that, would let me see the code that calls
>>>> it and find the malicious way it does so.
>>>>
>>>> So, is there something like that?
>>>>
>>>> Thank you!
>>>>
>>>> --
>>>> --
>>>> 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 a topic in the
>>> Google Groups "v8-users" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>>> pic/v8-users/j2CPHefGEmQ/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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 a topic in the
> Google Groups "v8-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/v8-users/j2CPHefGEmQ/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Breaking On Native Function Calls

[PhistucK]

File ​crbug.com/657697​ (and crbug.com/657700 for a related bug I found as
a result :(). But it is really a duplicate of crbug.com/49 (so I closed
mine). I guess it will not be in progress soon. :(


☆*PhistucK*

On Thu, Oct 20, 2016 at 8:19 AM, Jochen Eisinger <joc...@chromium.org>
wrote:

> As far as I know that's not possible. Could you file a feature request for
> this (probably on crbug.com if you also want to cover DOM functions)
>
> On Wed, Oct 19, 2016 at 7:38 PM PhistucK <phist...@gmail.com> wrote:
>
>> I wanted to know whether there is a V8 (or Chrome) flag of some sort that
>> will let me add breakpoints on native function calls.
>> I do not mean C++ functions, I mean built in web platform (or ECMAScript)
>> functions.
>> My issue is that I click on a link and suddenly some code is apparently
>> calling document.location.replace("foo") or something and the page
>> redirects (maliciously). In order to find the calling code, I want to set a
>> breakpoint on calling document.location.replace, which is a native web
>> platform function, that is not writable (so I cannot override it with my
>> own function using Object.defineProperty, or use a proxy).
>> (The code is apparently elusive and obfuscated somewhat, so it is not
>> just a search and replace)
>> I tried using the Developer Tools API - debug(function), but it did not
>> break (even when I call it with setTimeout).
>>
>> A V8 flag (or a Chrome flag) that either lets me break on calling that
>> function, or that overrides the security feature that makes it
>> non-writable, or something like that, would let me see the code that calls
>> it and find the malicious way it does so.
>>
>> So, is there something like that?
>>
>> Thank you!
>>
>> --
>> --
>> 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 a topic in the
> Google Groups "v8-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/v8-users/j2CPHefGEmQ/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Breaking On Native Function Calls

[PhistucK]

I wanted to know whether there is a V8 (or Chrome) flag of some sort that 
will let me add breakpoints on native function calls.
I do not mean C++ functions, I mean built in web platform (or ECMAScript) 
functions.
My issue is that I click on a link and suddenly some code is apparently 
calling document.location.replace("foo") or something and the page 
redirects (maliciously). In order to find the calling code, I want to set a 
breakpoint on calling document.location.replace, which is a native web 
platform function, that is not writable (so I cannot override it with my 
own function using Object.defineProperty, or use a proxy).
(The code is apparently elusive and obfuscated somewhat, so it is not just 
a search and replace)
I tried using the Developer Tools API - debug(function), but it did not 
break (even when I call it with setTimeout).

A V8 flag (or a Chrome flag) that either lets me break on calling that 
function, or that overrides the security feature that makes it 
non-writable, or something like that, would let me see the code that calls 
it and find the malicious way it does so.

So, is there something like that?

Thank you!

-- 
-- 
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: Disabling All Of The Optimizations

[PhistucK]

Yes, but I could not provide a reproduction case. :(
At least not without approvals from managers, I guess.

Do you happen to know when the next stable patch release is planned (that
includes the change)? I had to instruct the test teams to use
--js-flags="--no-crankshaft" for now, which is not ideal...


☆*PhistucK*

On Mon, Sep 26, 2016 at 9:42 AM, Jochen Eisinger <joc...@chromium.org>
wrote:

> Thanks for tracking this down. In general, if you're willing / able to
> provide a repro case, we're happy to investigate suchs bugs ourselves, so
> you don't have to go through the trouble of bisecting this..
>
> On Sun, Sep 25, 2016 at 6:06 PM PhistucK <phist...@gmail.com> wrote:
>
>> After bisecting, the bug started at -
>> https://chromium.googlesource.com/v8/v8/+log/c93d868f..d83c3f0e
>> The bug stopped at -
>> https://chromium.googlesource.com/v8/v8/+log/f9a47d47..a255aa83
>>
>> This leaves me with https://chromium.googlesource.com/v8/v8/+/
>> 4dab7b5a1d6722002d47d0be2481cb65602a2451, which resolves a for-in
>> optimization (Turbofan) bug
>> <https://bugs.chromium.org/p/chromium/issues/detail?id=647887> and
>> already merged to the 5.3 branch (but is not released to stable yet :().
>>
>> Though, I wonder, why did it not always occur? jQuery.isPlainObject is a
>> very hot function (at least in the code with which I am dealing here). Is
>> it possible that it is not always optimized?
>> (Also, that weird foo.hasOwnProperty(bar) === true versus 
>> Object.keys(foo).indexOf(bar)
>> === -1 contradiction...)
>>
>> Hopefully, another stable patch will be released soon, as it may affect
>> many jQuery versions, since that was the way to check whether an object is
>> a plain object until some time ago.
>>
>> I apologize to everyone, as I experienced the bug when it started but
>> dismissed it as a temporary canary issue that would resolve itself. Stupid
>> me. I hope I learned my lesson (probably not, though :( - I would have
>> reported it if it did not require days of investigations).
>>
>>
>> ☆*PhistucK*
>>
>> On Sat, Sep 24, 2016 at 1:45 PM, PhistucK <phist...@gmail.com> wrote:
>>
>>> Thank you! Unfortunately, for everyone, it is getting clearer and
>>> clearer that this is an optimization issue. The issue does not reproduce
>>> with the --no-crankshaft flag.
>>>
>>> The code is calling something like -
>>> jQuery.extend(/* deepCopy */ true, {string: 'something'}, {string,
>>> 'something', instance: someConstructedInstance})
>>> (Where someConstructedInstance is a an instance of an object based on an
>>> enhanced Backbone View Model, so it is not a plain object)
>>> And sometimes (it used to occasionally appear, it now appears most often
>>> than not), jQuery.isPlainObject returns true for the value of instance.
>>> That jQuery function finishes with the following statements
>>> <https://github.com/jquery/jquery/blob/d71f6a53927ad02d728503385d15539b73d21ac8/src/core.js#L472-L475>
>>>  -
>>> var key;
>>> for ( key in obj ) {}
>>>
>>> return key === undefined || core_hasOwn.call( obj, key );
>>> From my debugging, it sometimes fails the key === undefined
>>> <https://github.com/jquery/jquery/blob/d71f6a53927ad02d728503385d15539b73d21ac8/src/core.js#L475>
>>> check (if I add more logging code, it returns true - that does not make
>>> sense) and it sometimes fails the core_hasOwn.call( obj, key )
>>> <https://github.com/jquery/jquery/blob/d71f6a53927ad02d728503385d15539b73d21ac8/src/core.js#L475>
>>> check (which returns true for a key that is not an own property). When
>>> this happen, Object.keys(obj).indexOf(key) returns -1. I verified that
>>> the key is indeed not an own property.
>>> (I am using jQuery 1.9.1 and cannot update it, but the code has
>>> basically gone through simplification, not real bug fixes)
>>>
>>> I think it may have started since Chrome 52, I am not sure. It evidently
>>> possibly became much, much worse in Chrome 53 (Windows 7, Intel Core i5, 32
>>> bit).
>>>
>>> I should report it, but I cannot disclose the code (it is a
>>> several-megabyte package that includes - and uses in that stack - several
>>> libraries like Knockout, Backbone, Underscore and more). Can someone
>>> suggest how I can diagnose and debug this further (without a native code
>>> debugger) in order to help you understand the exact issue (without showing
>>> code :()?
>>>
>>>
>

Re: [v8-users] Re: Disabling All Of The Optimizations

[PhistucK]

After bisecting, the bug started at -
https://chromium.googlesource.com/v8/v8/+log/c93d868f..d83c3f0e
The bug stopped at -
https://chromium.googlesource.com/v8/v8/+log/f9a47d47..a255aa83

This leaves me with
https://chromium.googlesource.com/v8/v8/+/4dab7b5a1d6722002d47d0be2481cb65602a2451,
which resolves a for-in optimization (Turbofan) bug
<https://bugs.chromium.org/p/chromium/issues/detail?id=647887> and already
merged to the 5.3 branch (but is not released to stable yet :().

Though, I wonder, why did it not always occur? jQuery.isPlainObject is a
very hot function (at least in the code with which I am dealing here). Is
it possible that it is not always optimized?
(Also, that weird foo.hasOwnProperty(bar) === true versus
Object.keys(foo).indexOf(bar)
=== -1 contradiction...)

Hopefully, another stable patch will be released soon, as it may affect
many jQuery versions, since that was the way to check whether an object is
a plain object until some time ago.

I apologize to everyone, as I experienced the bug when it started but
dismissed it as a temporary canary issue that would resolve itself. Stupid
me. I hope I learned my lesson (probably not, though :( - I would have
reported it if it did not require days of investigations).


☆*PhistucK*

On Sat, Sep 24, 2016 at 1:45 PM, PhistucK <phist...@gmail.com> wrote:

> Thank you! Unfortunately, for everyone, it is getting clearer and clearer
> that this is an optimization issue. The issue does not reproduce with the
> --no-crankshaft flag.
>
> The code is calling something like -
> jQuery.extend(/* deepCopy */ true, {string: 'something'}, {string,
> 'something', instance: someConstructedInstance})
> (Where someConstructedInstance is a an instance of an object based on an
> enhanced Backbone View Model, so it is not a plain object)
> And sometimes (it used to occasionally appear, it now appears most often
> than not), jQuery.isPlainObject returns true for the value of instance.
> That jQuery function finishes with the following statements
> <https://github.com/jquery/jquery/blob/d71f6a53927ad02d728503385d15539b73d21ac8/src/core.js#L472-L475>
>  -
> var key;
> for ( key in obj ) {}
>
> return key === undefined || core_hasOwn.call( obj, key );
> From my debugging, it sometimes fails the key === undefined
> <https://github.com/jquery/jquery/blob/d71f6a53927ad02d728503385d15539b73d21ac8/src/core.js#L475>
> check (if I add more logging code, it returns true - that does not make
> sense) and it sometimes fails the core_hasOwn.call( obj, key )
> <https://github.com/jquery/jquery/blob/d71f6a53927ad02d728503385d15539b73d21ac8/src/core.js#L475>
> check (which returns true for a key that is not an own property). When
> this happen, Object.keys(obj).indexOf(key) returns -1. I verified that
> the key is indeed not an own property.
> (I am using jQuery 1.9.1 and cannot update it, but the code has basically
> gone through simplification, not real bug fixes)
>
> I think it may have started since Chrome 52, I am not sure. It evidently
> possibly became much, much worse in Chrome 53 (Windows 7, Intel Core i5, 32
> bit).
>
> I should report it, but I cannot disclose the code (it is a
> several-megabyte package that includes - and uses in that stack - several
> libraries like Knockout, Backbone, Underscore and more). Can someone
> suggest how I can diagnose and debug this further (without a native code
> debugger) in order to help you understand the exact issue (without showing
> code :()?
>
>
> ☆*PhistucK*
> On Tuesday, September 20, 2016 at 3:54:19 PM UTC+3, Michael Hablich wrote:
>
>> --no-crankshaft should do the trick. The name is misleading, it will also
>> disable TurboFan.
>>
>>
>> On Tuesday, September 20, 2016 at 1:51:51 PM UTC+2, PhistucK wrote:
>>>
>>> I have an issue where the code suddenly (since Chrome 53) gets caught up
>>> in a cyclic recursion until it exceeds the stack size limit.
>>>
>>> Since the code is the same, I want to try and rule out engine
>>> optimization issues. Is there a V8 flag for disabling all of the
>>> optimizations?
>>>
>>>
>>> ☆*PhistucK*
>>>
>> --
> --
> v8-users mailing list
> v8-users@googlegroups.com
> http://groups.google.com/group/v8-users
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "v8-users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/to
> pic/v8-users/V3J9CwEv468/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Disabling All Of The Optimizations

[PhistucK]

Thank you! Unfortunately, for everyone, it is getting clearer and clearer 
that this is an optimization issue. The issue does not reproduce with the 
--no-crankshaft flag.

The code is calling something like -
jQuery.extend(/* deepCopy */ true, {string: 'something'}, {string, 
'something', instance: someConstructedInstance})
(Where someConstructedInstance is a an instance of an object based on an 
enhanced Backbone View Model, so it is not a plain object)
And sometimes (it used to occasionally appear, it now appears most often 
than not), jQuery.isPlainObject returns true for the value of instance.
That jQuery function finishes with the following statements 
<https://github.com/jquery/jquery/blob/d71f6a53927ad02d728503385d15539b73d21ac8/src/core.js#L472-L475>
 - 
var key;
for ( key in obj ) {}

return key === undefined || core_hasOwn.call( obj, key );
>From my debugging, it sometimes fails the key === undefined 
<https://github.com/jquery/jquery/blob/d71f6a53927ad02d728503385d15539b73d21ac8/src/core.js#L475>
 
check (if I add more logging code, it returns true - that does not make 
sense) and it sometimes fails the core_hasOwn.call( obj, key ) 
<https://github.com/jquery/jquery/blob/d71f6a53927ad02d728503385d15539b73d21ac8/src/core.js#L475>
 
check (which returns true for a key that is not an own property). When this 
happen, Object.keys(obj).indexOf(key) returns -1. I verified that the key 
is indeed not an own property.
(I am using jQuery 1.9.1 and cannot update it, but the code has basically 
gone through simplification, not real bug fixes)

I think it may have started since Chrome 52, I am not sure. It evidently 
possibly became much, much worse in Chrome 53 (Windows 7, Intel Core i5, 32 
bit).

I should report it, but I cannot disclose the code (it is a 
several-megabyte package that includes - and uses in that stack - several 
libraries like Knockout, Backbone, Underscore and more). Can someone 
suggest how I can diagnose and debug this further (without a native code 
debugger) in order to help you understand the exact issue (without showing 
code :()?


☆*PhistucK*
On Tuesday, September 20, 2016 at 3:54:19 PM UTC+3, Michael Hablich wrote:

> --no-crankshaft should do the trick. The name is misleading, it will also 
> disable TurboFan.
>
> On Tuesday, September 20, 2016 at 1:51:51 PM UTC+2, PhistucK wrote:
>>
>> I have an issue where the code suddenly (since Chrome 53) gets caught up 
>> in a cyclic recursion until it exceeds the stack size limit.
>>
>> Since the code is the same, I want to try and rule out engine 
>> optimization issues. Is there a V8 flag for disabling all of the 
>> optimizations?
>>
>>
>> ☆*PhistucK*
>>
>

-- 
-- 
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] Disabling All Of The Optimizations

[PhistucK]

I have an issue where the code suddenly (since Chrome 53) gets caught up in
a cyclic recursion until it exceeds the stack size limit.

Since the code is the same, I want to try and rule out engine optimization
issues. Is there a V8 flag for disabling all of the optimizations?


☆*PhistucK*

-- 
-- 
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 implement async/await functions

[PhistucK]

So which one should be removed? Can you merge their content in a reasonable
way and remove one of them?


☆*PhistucK*

On Tue, May 31, 2016 at 1:29 AM, Caitlin Potter <caitpotte...@gmail.com>
wrote:

> LGTM1 (just kidding)
>
> Sorry for not getting the launch process ball rolling myself months ago,
> that probably should have happened.
>
> On Monday, 9 May 2016 17:11:05 UTC-4, Daniel Ehrenberg wrote:
>>
>> *Contact emails*
>> litt...@chromium.org
>>
>> *Spec*
>> https://tc39.github.io/ecmascript-asyncawait/
>>
>> *Summary*
>> Async functions make it easy to write code which needs to "block" on
>> certain asynchronous events JavaScript.
>>
>> *Motivation*
>> Async/await does this by providing a simpler and more ergonomic way to
>> use Promises. To block on a value, use the 'await' keyword. Async/await can
>> be implemented based on a desugaring to generators, as described in the
>> following design doc:
>> https://docs.google.com/document/d/1K38ct2dsxG_9OfmgErvFld4MPDC4Wkr8tPuqmSWu_3Y/edit?usp=sharing
>>
>> Interoperability Risk
>>
>> None; in development in Firefox, Edge and Safari. All implementations in
>> progress target correctness with respect to the specification.
>>
>>
>> *Compatibility Risk*
>>
>> The draft specification creates new contextual keywords, but these do not
>> change the behavior of any existing code and just allow new patterns which
>> would have previously been syntax errors. Therefore, the compatibility risk
>> should be minimal.
>>
>> *Ongoing technical constraints*
>> None
>>
>> *Tracking bug*
>> Dev bug: https://bugs.chromium.org/p/v8/issues/detail?id=4483
>>
>> *Link to entry on the Chrome Platform Status *
>> https://www.chromestatus.com/features/5643236399906816
>>
>> Requesting approval to ship?
>>
>> No
>>
> --
> 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 implement async/await functions

[PhistucK]

I love this.

By the way, why are there two ChromeStatus entries?
https://www.chromestatus.com/feature/5644533144485888 as well as
https://www.chromestatus.com/feature/5643236399906816?


☆*PhistucK*

On Thu, May 12, 2016 at 6:34 PM, <jrapod...@gmail.com> wrote:

> Super excited for this to land in V8, and then get integrated into
> NodeJS!  Any timeline on when this will be released?
>
> On Monday, May 9, 2016 at 3:11:05 PM UTC-6, Daniel Ehrenberg wrote:
>>
>> *Contact emails*
>> litt...@chromium.org
>>
>> *Spec*
>> https://tc39.github.io/ecmascript-asyncawait/
>>
>> *Summary*
>> Async functions make it easy to write code which needs to "block" on
>> certain asynchronous events JavaScript.
>>
>> *Motivation*
>> Async/await does this by providing a simpler and more ergonomic way to
>> use Promises. To block on a value, use the 'await' keyword. Async/await can
>> be implemented based on a desugaring to generators, as described in the
>> following design doc:
>> https://docs.google.com/document/d/1K38ct2dsxG_9OfmgErvFld4MPDC4Wkr8tPuqmSWu_3Y/edit?usp=sharing
>>
>> Interoperability Risk
>>
>> None; in development in Firefox, Edge and Safari. All implementations in
>> progress target correctness with respect to the specification.
>>
>>
>> *Compatibility Risk*
>>
>> The draft specification creates new contextual keywords, but these do not
>> change the behavior of any existing code and just allow new patterns which
>> would have previously been syntax errors. Therefore, the compatibility risk
>> should be minimal.
>>
>> *Ongoing technical constraints*
>> None
>>
>> *Tracking bug*
>> Dev bug: https://bugs.chromium.org/p/v8/issues/detail?id=4483
>>
>> *Link to entry on the Chrome Platform Status *
>> https://www.chromestatus.com/features/5643236399906816
>>
>> Requesting approval to ship?
>>
>> No
>>
> --
> 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: Passive Error Event

[PhistucK]

Of course listening to the event is implemented in Blink, but it uses V8
APIs in order to break at uncaught exceptions, so I wondered if activating
this makes the execution less performant.


☆*PhistucK*

On Fri, May 27, 2016 at 6:19 PM, Yang Guo <yang...@chromium.org> wrote:

> That doesnt sound like something in V8. The onerror listener is
> implemented by blink.
>
> Yang
>
> On Tue, May 24, 2016, 12:55 PhistucK <phist...@gmail.com> wrote:
>
>> Not throwing errors, but whether adding an event listener to the "error"
>> influences performance without even throwing errors. I just do not know...
>>
>>
>> ☆*PhistucK*
>>
>> On Tue, May 24, 2016 at 1:46 PM, Yang Guo <yang...@chromium.org> wrote:
>>
>>> Throwing errors typically are not and should not be on the critical path
>>> of any Javascript program. Therefore it makes no sense to add complexity to
>>> make this faster.
>>>
>>> Cheers,
>>>
>>> Yang
>>>
>>>
>>> On Thursday, May 19, 2016 at 8:03:55 PM UTC+2, PhistucK wrote:
>>>>
>>>> I am not really sure about how to test it, but I guess you know more
>>>> about it.
>>>>
>>>> Browsers support the "error" (window.onerror or
>>>> window.addEventListener("error", ...)) event, which, if you call
>>>> e.preventDefault() and the like, apparently catches the exception (I could
>>>> not get it to work for some reason when I tried in the console, though).
>>>>
>>>> I was thinking about the potential performance gains of adding
>>>> {passive: true} support for this event - can it simplify some checks and
>>>> yield (even) better performance when using the event? Will the V8 engine
>>>> benefit from that in some way (for example, fire it not immediately if it
>>>> knows there is more code to run at the moment, or something similar,
>>>> batching and so on)?
>>>>
>>>> Again, I do not know whether there is even any performance implication
>>>> to adding an "error" event listener, you probably know more.
>>>>
>>>> Just an idea.
>>>>
>>>>
>>>>
>>>> ☆*PhistucK*
>>>>
>>> --
>>> 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: Passive Error Event

[PhistucK]

Not throwing errors, but whether adding an event listener to the "error"
influences performance without even throwing errors. I just do not know...


☆*PhistucK*

On Tue, May 24, 2016 at 1:46 PM, Yang Guo <yang...@chromium.org> wrote:

> Throwing errors typically are not and should not be on the critical path
> of any Javascript program. Therefore it makes no sense to add complexity to
> make this faster.
>
> Cheers,
>
> Yang
>
>
> On Thursday, May 19, 2016 at 8:03:55 PM UTC+2, PhistucK wrote:
>>
>> I am not really sure about how to test it, but I guess you know more
>> about it.
>>
>> Browsers support the "error" (window.onerror or
>> window.addEventListener("error", ...)) event, which, if you call
>> e.preventDefault() and the like, apparently catches the exception (I could
>> not get it to work for some reason when I tried in the console, though).
>>
>> I was thinking about the potential performance gains of adding {passive:
>> true} support for this event - can it simplify some checks and yield (even)
>> better performance when using the event? Will the V8 engine benefit from
>> that in some way (for example, fire it not immediately if it knows there is
>> more code to run at the moment, or something similar, batching and so on)?
>>
>> Again, I do not know whether there is even any performance implication to
>> adding an "error" event listener, you probably know more.
>>
>> Just an idea.
>>
>>
>>
>> ☆*PhistucK*
>>
> --
> 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] Passive Error Event

[PhistucK]

I am not really sure about how to test it, but I guess you know more about
it.

Browsers support the "error" (window.onerror or
window.addEventListener("error", ...)) event, which, if you call
e.preventDefault() and the like, apparently catches the exception (I could
not get it to work for some reason when I tried in the console, though).

I was thinking about the potential performance gains of adding {passive:
true} support for this event - can it simplify some checks and yield (even)
better performance when using the event? Will the V8 engine benefit from
that in some way (for example, fire it not immediately if it knows there is
more code to run at the moment, or something similar, batching and so on)?

Again, I do not know whether there is even any performance implication to
adding an "error" event listener, you probably know more.

Just an idea.



☆*PhistucK*

-- 
-- 
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()

[PhistucK]

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 <caitpotte...@gmail.com>
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 <caitpo...@gmail.com>
>> 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+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 Ship: Object.values() and Object.entries()

[PhistucK]

The post itself seems to be missing. :(


☆*PhistucK*

On Tue, May 3, 2016 at 7:13 PM, Caitlin Potter <caitpotte...@gmail.com>
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+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

[PhistucK]

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] Blog Post Correction

[PhistucK]

(Added chromium-discuss as a BCC recipient and v8-users as a CC recipient)

I believe @@toStringTag was not shipped after all (see the comment by Seth
Thompson here <http://v8project.blogspot.co.il/2015/11/v8-release-48.html>),
can you update the blog post
<http://blog.chromium.org/2015/12/chrome-48-beta-present-to-cast-devices_91.html>
?

V8 people, please, holler if this is incorrect.

Thank you!

☆*PhistucK*

-- 
-- 
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: SIMD.js

[PhistucK]

Is this in development?


☆*PhistucK*

On Thu, May 7, 2015 at 3:00 AM, 'Bill Budge' via blink-dev <
blink-...@chromium.org> wrote:

> # Contact Info
> bbu...@chromium.org, bradnel...@chromium.org
>
> # TC39 acceptance
>
> SIMD.js is a proposal in ES7
> https://github.com/tc39/ecma262
>
> John Mccutchan’s Strawman proposal (polyfill is spec):
> https://github.com/johnmccutchan/ecmascript_simd
>
>
> # Interest from other vendors
>
> Mozilla has implemented this in Firefox:
> https://hacks.mozilla.org/2014/10/introducing-simd-js/
>
> https://blog.mozilla.org/javascript/2015/03/10/state-of-simd-js-performance-in-firefox/
>
> Microsoft has announced plans to implement SIMD.js in Chakra, their
> Javascript engine.
> Slides:  http://channel9.msdn.com/Events/Build/2015/2-763
> Video: http://video.ch9.ms/sessions/build/2015/2-763-LG.mp4
>
> SIMD.js discussion starts at minute 45:35 and demoed with Mandelbrot at
> time 49:00.
>
> # Technical considerations
>
> Implementing SIMD should have a small impact on code complexity in V8.
> There are lots of
> SIMD types and operations but they are very regular.
>
>
> # Implementation/testing
>
> Design Document to come.
>
> -Bill
>
> 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.

Re: [chromium-discuss] Re: [v8-users] No Garbage Collection For Hours

[PhistucK]

Windows 7.


☆*PhistucK*

On Wed, Oct 7, 2015 at 4:51 PM, Jochen Eisinger <joc...@chromium.org> wrote:

> depends a bit on the OS you run chromium on?
>
> On Mon, Oct 5, 2015 at 6:55 PM PhistucK <phist...@gmail.com> wrote:
>
>> Sure, but how do I get the output of the extension process? By enabling
>> logging?
>>
>>
>> ☆*PhistucK*
>>
>> On Mon, Oct 5, 2015 at 12:52 PM, Jochen Eisinger <joc...@chromium.org>
>> wrote:
>>
>>> it would be interesting to have the output of the extension process when
>>> running chromium with --js-flags="--trace-gc --trace-gc-nvp"
>>>
>>> Please file a bug with this information on crbug.com/new
>>>
>>> On Sat, Oct 3, 2015 at 5:49 PM PhistucK <phist...@gmail.com> wrote:
>>>
>>>> Sorry for the cross post, I wanted your opinion before I file an issue,
>>>> because I am not sure where to file it.
>>>>
>>>> I installed Outlook.com notifier
>>>> <https://chrome.google.com/webstore/detail/mkmomflkhdooajekmffpilpoenndjppk?utm_source=chrome-app-launcher-info-dialog>
>>>>  and
>>>> recently, I found out it was using a lot of memory.
>>>>
>>>> Looking into it, it uses YUI to fetch mail.live.com, YUI adds the
>>>> content to a DocumentFragment, the script looks for an element, gets its
>>>> content and that is it, every half a minute or so.
>>>>
>>>> Using the Developer Tools feature, I used the Profiler panel, took a
>>>> heap snapshot, switched to the Containment view and saw that GC
>>>> roots>Global handles uses over 300 MBs. It basically contains the string
>>>> content fetched from mail.live.com ever since Chrome was started.
>>>>
>>>> I then went to the TImeline panel and clicked on the trash can button
>>>> ("Collect garbage"), took another heap snapshot and it went back to about 1
>>>> MB.
>>>>
>>>> I think I noticed that when the available memory is low, it does
>>>> collect the garbage quickly, but it happened when I artificially created
>>>> 1000 large DocumentFragments, added them to an array and deleted the array.
>>>>
>>>> Should I file a V8 issue, or a Chromium issue?
>>>> I figure it is a V8 issue, but I want to make sure, since it does
>>>> involve extensions (a background page) and DOM operations.
>>>>
>>>>
>>>>
>>>> ☆*PhistucK*
>>>>
>>>> --
>>>> --
>>>> 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.
>>>>
>>> --
>>> --
>>> Chromium Discussion mailing list: chromium-disc...@chromium.org
>>> View archives, change email options, or unsubscribe:
>>> http://groups.google.com/a/chromium.org/group/chromium-discuss
>>>
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to chromium-discuss+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.

Re: [chromium-discuss] Re: [v8-users] No Garbage Collection For Hours

[PhistucK]

Sure, but how do I get the output of the extension process? By enabling
logging?


☆*PhistucK*

On Mon, Oct 5, 2015 at 12:52 PM, Jochen Eisinger <joc...@chromium.org>
wrote:

> it would be interesting to have the output of the extension process when
> running chromium with --js-flags="--trace-gc --trace-gc-nvp"
>
> Please file a bug with this information on crbug.com/new
>
> On Sat, Oct 3, 2015 at 5:49 PM PhistucK <phist...@gmail.com> wrote:
>
>> Sorry for the cross post, I wanted your opinion before I file an issue,
>> because I am not sure where to file it.
>>
>> I installed Outlook.com notifier
>> <https://chrome.google.com/webstore/detail/mkmomflkhdooajekmffpilpoenndjppk?utm_source=chrome-app-launcher-info-dialog>
>>  and
>> recently, I found out it was using a lot of memory.
>>
>> Looking into it, it uses YUI to fetch mail.live.com, YUI adds the
>> content to a DocumentFragment, the script looks for an element, gets its
>> content and that is it, every half a minute or so.
>>
>> Using the Developer Tools feature, I used the Profiler panel, took a heap
>> snapshot, switched to the Containment view and saw that GC roots>Global
>> handles uses over 300 MBs. It basically contains the string content fetched
>> from mail.live.com ever since Chrome was started.
>>
>> I then went to the TImeline panel and clicked on the trash can button
>> ("Collect garbage"), took another heap snapshot and it went back to about 1
>> MB.
>>
>> I think I noticed that when the available memory is low, it does collect
>> the garbage quickly, but it happened when I artificially created 1000 large
>> DocumentFragments, added them to an array and deleted the array.
>>
>> Should I file a V8 issue, or a Chromium issue?
>> I figure it is a V8 issue, but I want to make sure, since it does involve
>> extensions (a background page) and DOM operations.
>>
>>
>>
>> ☆*PhistucK*
>>
>> --
>> --
>> 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.
>>
> --
> --
> Chromium Discussion mailing list: chromium-disc...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-discuss
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromium-discuss+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] No Garbage Collection For Hours

[PhistucK]

Sorry for the cross post, I wanted your opinion before I file an issue,
because I am not sure where to file it.

I installed Outlook.com notifier
<https://chrome.google.com/webstore/detail/mkmomflkhdooajekmffpilpoenndjppk?utm_source=chrome-app-launcher-info-dialog>
and
recently, I found out it was using a lot of memory.

Looking into it, it uses YUI to fetch mail.live.com, YUI adds the content
to a DocumentFragment, the script looks for an element, gets its content
and that is it, every half a minute or so.

Using the Developer Tools feature, I used the Profiler panel, took a heap
snapshot, switched to the Containment view and saw that GC roots>Global
handles uses over 300 MBs. It basically contains the string content fetched
from mail.live.com ever since Chrome was started.

I then went to the TImeline panel and clicked on the trash can button
("Collect garbage"), took another heap snapshot and it went back to about 1
MB.

I think I noticed that when the available memory is low, it does collect
the garbage quickly, but it happened when I artificially created 1000 large
DocumentFragments, added them to an array and deleted the array.

Should I file a V8 issue, or a Chromium issue?
I figure it is a V8 issue, but I want to make sure, since it does involve
extensions (a background page) and DOM operations.



☆*PhistucK*

-- 
-- 
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: ES6 Template Literals

[PhistucK]

Oh, right. I get it now, thank you!


☆*PhistucK*

On Wed, Dec 17, 2014 at 9:15 PM, 'Erik Arvidsson' via blink-dev 
blink-...@chromium.org wrote:

 With String.raw `\n` you get \\n versus with `\n` you get \n.

 On Wed, Dec 17, 2014 at 2:12 PM, PhistucK phist...@gmail.com wrote:
  A bit off topic, but how is (from MDN) String.raw`bla\n${5+6}` any
 different
  from simply `bla\n${5+6}`?
  (MDN also shows  - console.log(`Fifteen is ${a + b} and not ${2 * a +
 b}.`);
  - without any String.raw or anything, so why would one need String.raw?)
 
  Or is the MDN example simply not so great and it is supposed to be
  String.raw(bla\n${5+6})?
 
 
  ☆PhistucK
 
  On Wed, Dec 17, 2014 at 7:31 PM, Joshua Bell jsb...@chromium.org
 wrote:
 
  Any caveats?
 
  Does this include the use of tags (i.e. tag`literal`;) ?
 
  Does this include String.raw()?
 
  (IMHO a subset w/o either of those is both useful and noncontroversial,
  I'm just curious if this Intent includes all the bells and whistles)
 
 
  On Wed, Dec 17, 2014 at 7:31 AM, Erik Arvidsson a...@chromium.org
 wrote:
 
  [blink-dev: FYI]
 
  Template Literals are part of ES6. The spec in the Editor's draft is
  stable [1].
 
  Firefox is shipping template literals since version 34 [2].
  IE has template literals in a preview release [3].
 
  Owners: a...@chromium.org, caitpotte...@gmail.com
 
  [1]
 
 https://people.mozilla.org/~jorendorff/es6-draft.html#sec-template-literals
  [2] https://developer.mozilla.org/en-US/Firefox/Releases/34
  [3] https://status.modern.ie/templatestringses6
 
  --
  --
  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.
 
  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.



 --
 erik

 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] Intent to ship: ES6 String functions

[PhistucK]

Can we add a console log (not a warning) for the canary/dev/beta run
(perhaps stable, too?) for a little while to aid developers with possible
breakages?
If String.prototype.includes is overridden, deleted or accessed (called or
gotten), the log would be printed.


☆*PhistucK*

On Thu, Nov 27, 2014 at 12:01 PM, Drew Wilson atwil...@chromium.org wrote:



 On Thu, Nov 27, 2014 at 10:35 AM, Dmitry Lomov dslo...@chromium.org
 wrote:



 On Thu, Nov 27, 2014 at 10:13 AM, Drew Wilson atwil...@chromium.org
 wrote:

 What impact do we expect on web compatibility from apps that may already
 be adding attributes named include, etc to their String objects?

 I think that adding attributes that Firefox is already shipping should
 be relatively safe, but I'm very leery about being the first browser to add
 new attributes. What can we do to avoid a repeat of
 http://crbug.com/409858? Do we have any stats for how often these
 attributes are already in use in web pages (tricky, since some apps are
 legitimately using them for polyfill purposes)?

 Correct, this is tricky. We do not have stats (and it is unclear how to
 get those stats).
 'contains' was renamed to 'includes' precisely to reduce possible web
 compat breakage.
 Unfortunately we will not know of any breakage until we ship this - it
 has been available under a flag for some time, but it looks like nobody
 tests with 'Experimental Javascript features' enabled.
 Therefore enabling it early on canary in Chrome 41 process is our best
 mitigation in this particular case.


 I'm not sure let's just launch this and see who complains is an
 acceptable path forward given that this specific approach was tried last
 release with Array.values and blew up in our face. Why do we think this
 time will be any different?

 Can we perhaps restrict this to canary + dev channel (and maybe the first
 beta cut), but hold off on shipping to Stable until we find a way to
 generate stats? Just making this change with no stats around conflicts
 would be like the blink team deprecating an API without first measuring how
 often it's used.



 Going forward, we have recently changed the definition of 'Experimental
 Javascript fetaures' in Chrome to mean 'enable staged features' (per our
 process https://developers.google.com/v8/launchprocess).
 This means that this flag really enables only those features that we
 consider quite mature, in particular they are expected to be stable and
 implementation of them must be complete.
 With that, we plan to evangelize enabling this flag among the power
 users, so that we hear about any breakage early.


 Can we set enable staged features for the Dev channel by default to
 increase usage? I don't actually think this will solve the problem since
 experience has shown us that not enough users run on that channel to catch
 all of the incompatibility issues, but at least it's a start.



 Dmitry




 On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org
 wrote:

 [FYI +blink-dev]

 ES6 extends String.prototype with several methods: repeat, startsWith,
 endsWith, includes, codePointAt) and adds String.fromCodePoint method.

 Firefox ships codePointAt and fromCodePoint since release 29 [1],
 startsWith and endsWith since release 17 [2], and repeat since release 24
 [3].

 'include' was previously named 'contains' and has been renamed at the
 last TC39 meeting. Firefox shipped 'contains' since release 17.

 These methods has been available under a flag for a while, and were
 staged in Chrome 40.

 [1] https://developer.mozilla.org/en-US/Firefox/Releases/29
 [2] https://developer.mozilla.org/en-US/Firefox/Releases/17
 [3] https://developer.mozilla.org/en-US/Firefox/Releases/24

 Owners: yang...@chromium.org, dslo...@chromium.org




  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.

Re: [v8-users] Re: [blink-dev] Intent to ship: ES6 String functions

[PhistucK]

This is to ease debugging, not to solve every single case. As much as
possible, log it. On a 'best available' case.


☆*PhistucK*

On Thu, Nov 27, 2014 at 1:14 PM, 'Andreas Rossberg' via blink-dev 
blink-...@chromium.org wrote:

 On 27 November 2014 at 11:39, Dmitry Lomov dslo...@chromium.org wrote:
  On Thu, Nov 27, 2014 at 11:01 AM, Drew Wilson atwil...@chromium.org
 wrote:
  On Thu, Nov 27, 2014 at 10:35 AM, Dmitry Lomov dslo...@chromium.org
  wrote:
  On Thu, Nov 27, 2014 at 10:13 AM, Drew Wilson atwil...@chromium.org
  wrote:
 
  What impact do we expect on web compatibility from apps that may
 already
  be adding attributes named include, etc to their String objects?
 
  I think that adding attributes that Firefox is already shipping should
  be relatively safe, but I'm very leery about being the first browser
 to add
  new attributes. What can we do to avoid a repeat of
 http://crbug.com/409858?
  Do we have any stats for how often these attributes are already in
 use in
  web pages (tricky, since some apps are legitimately using them for
 polyfill
  purposes)?
 
  Correct, this is tricky. We do not have stats (and it is unclear how to
  get those stats).
  'contains' was renamed to 'includes' precisely to reduce possible web
  compat breakage.
  Unfortunately we will not know of any breakage until we ship this - it
  has been available under a flag for some time, but it looks like nobody
  tests with 'Experimental Javascript features' enabled.
  Therefore enabling it early on canary in Chrome 41 process is our best
  mitigation in this particular case.
 
  I'm not sure let's just launch this and see who complains is an
  acceptable path forward given that this specific approach was tried last
  release with Array.values and blew up in our face. Why do we think this
 time
  will be any different?
 
  Can we perhaps restrict this to canary + dev channel (and maybe the
 first
  beta cut), but hold off on shipping to Stable until we find a way to
  generate stats?
 
  Shipping this now is de facto canary + dev.
  I do not know of a way to generate stats for this (unfortunately).

 What Dmitry said. Of course, if problems are discovered there, then we
 will roll back before the next beta. But if they aren't then we have
 no realistic way of knowing other than shipping it in beta. That's
 what beta is for, after all.

 The good news is that after the previous incident we changed our
 roll-out procedure such that unshipping a feature now consists of only
 swapping a macro invocation.

 It's also worth noting that we have shipped many other new features
 without any problems. Array.p.values was the only exception so far.


 On 27 November 2014 at 11:06, PhistucK phist...@gmail.com wrote:
  Can we add a console log (not a warning) for the canary/dev/beta run
  (perhaps stable, too?) for a little while to aid developers with possible
  breakages?
  If String.prototype.includes is overridden, deleted or accessed (called
 or
  gotten), the log would be printed.

 Unfortunately, I believe that is infeasible. As Dmitry already noted,
 it is not at all easy to diagnose the situation, even if you were
 willing to accept lots of false positives. JavaScript is far too
 dynamic (and generally broken beyond repair when it comes to
 robustness). Moreover, ES6 adds plenty of new methods across the
 board, and we wouldn't want to install a complicated mechanism like
 that for each and every one of them, even though a priori, there is no
 reason to believe that any one of them has less or more potential for
 breakage than A.p.includes has.

 /Andreas

 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] Intent to ship: ES6 String functions

[PhistucK]

This is very debateable, really. To me, it makes sense (and in my
experience, also exists) that contains makes more sense (as a shortcuts
for return this.indexOf(str) !== -1) than 'includes'.


☆*PhistucK*

On Thu, Nov 27, 2014 at 1:52 PM, Philip Jägenstedt phil...@opera.com
wrote:

 On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org
 wrote:

  'include' was previously named 'contains' and has been renamed at the
 last TC39 meeting. Firefox shipped 'contains' since release 17.

 It sure sounds like 'contains' would be less likely to cause trouble,
 and is also a slightly better name IMHO.

 Is Mozilla on board with renaming it? If they're not keen, I think
 following their lead with 'contains' makes more sense.

 Philip

 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] Intent to ship: ES6 String functions

[PhistucK]

*shortcut

My last message was probably confusing, so continuing it -
By that, I mean that it makes more sense for 'contains' to exists already
on the web, than for 'includes'.


☆*PhistucK*

On Thu, Nov 27, 2014 at 1:55 PM, PhistucK phist...@gmail.com wrote:

 This is very debateable, really. To me, it makes sense (and in my
 experience, also exists) that contains makes more sense (as a shortcuts
 for return this.indexOf(str) !== -1) than 'includes'.


 ☆*PhistucK*

 On Thu, Nov 27, 2014 at 1:52 PM, Philip Jägenstedt phil...@opera.com
 wrote:

 On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org
 wrote:

  'include' was previously named 'contains' and has been renamed at the
 last TC39 meeting. Firefox shipped 'contains' since release 17.

 It sure sounds like 'contains' would be less likely to cause trouble,
 and is also a slightly better name IMHO.

 Is Mozilla on board with renaming it? If they're not keen, I think
 following their lead with 'contains' makes more sense.

 Philip

 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] Intent to ship: ES6 String functions

[PhistucK]

*exist

'contains' is the obvious choice, 'includes' is not. This is what I mean.
While 'contains' is better named, 'includes' is less risky and therefore
should be chosen.

I am finally done, I think. Sorry for the triple post.


☆*PhistucK*

On Thu, Nov 27, 2014 at 1:57 PM, PhistucK phist...@gmail.com wrote:

 *shortcut

 My last message was probably confusing, so continuing it -
 By that, I mean that it makes more sense for 'contains' to exists already
 on the web, than for 'includes'.


 ☆*PhistucK*

 On Thu, Nov 27, 2014 at 1:55 PM, PhistucK phist...@gmail.com wrote:

 This is very debateable, really. To me, it makes sense (and in my
 experience, also exists) that contains makes more sense (as a shortcuts
 for return this.indexOf(str) !== -1) than 'includes'.


 ☆*PhistucK*

 On Thu, Nov 27, 2014 at 1:52 PM, Philip Jägenstedt phil...@opera.com
 wrote:

 On Thu, Nov 27, 2014 at 9:27 AM, Dmitry Lomov dslo...@chromium.org
 wrote:

  'include' was previously named 'contains' and has been renamed at the
 last TC39 meeting. Firefox shipped 'contains' since release 17.

 It sure sounds like 'contains' would be less likely to cause trouble,
 and is also a slightly better name IMHO.

 Is Mozilla on board with renaming it? If they're not keen, I think
 following their lead with 'contains' makes more sense.

 Philip

 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.

Re: [v8-users] Re: [blink-dev] Intent to ship: ES6 String functions

[PhistucK]

Then I guess I am also looking to help educate about new platform features.

I understand this use case is much less needed, though.


☆*PhistucK*

On Thu, Nov 27, 2014 at 9:52 PM, Dmitry Lomov dslo...@chromium.org wrote:



 On Thu, Nov 27, 2014 at 8:48 PM, PhistucK phist...@gmail.com wrote:

 Well, you got the wrong idea.
 I am looking to help developers, not to tell them something is
 necessarily wrong​.
 The expensive ones (like includes in obj) are not part of best
 available in my opinion.


 These are the ones that cause problems though (both in 'values' case and
 in Array.prototype.contains case).


 foo = obj.includes, obj.includes() and String.prototype.includes = foo
 are enough.


 These typically wouldn't cause problems (as in: won't break web sites)
 since all this likely overrides the ones we ship.

 The point is to note that this new, potentially controversial (its name
 only, of course) feature was introduced and that if you suddenly see
 issues, take a note that it was added, in case it applies to your case. If
 not, carry on.

 Logs such as these -
 String.prototype.includes was recently added to the platform and was
 overridden by this website. If you expect the standard variation of this
 method, perhaps polyfill it only when it does not exist.
 String.prototype.includes was recently added to the platform and used by
 this website. If you see issues, consider this as a possible culprit.


 ☆*PhistucK*

 On Thu, Nov 27, 2014 at 2:01 PM, Dmitry Lomov dslo...@chromium.org
 wrote:



 On Thu, Nov 27, 2014 at 12:37 PM, PhistucK phist...@gmail.com wrote:

 This is to ease debugging, not to solve every single case. As much as
 possible, log it. On a 'best available' case.


 Logging would be prohibitively expensive as well, and lead to too many
 false positives.
 We will have to log, for example, every time somebody does an
 'includes' in obj.



 ☆*PhistucK*

 On Thu, Nov 27, 2014 at 1:14 PM, 'Andreas Rossberg' via blink-dev 
 blink-...@chromium.org wrote:

 On 27 November 2014 at 11:39, Dmitry Lomov dslo...@chromium.org
 wrote:
  On Thu, Nov 27, 2014 at 11:01 AM, Drew Wilson atwil...@chromium.org
 wrote:
  On Thu, Nov 27, 2014 at 10:35 AM, Dmitry Lomov 
 dslo...@chromium.org
  wrote:
  On Thu, Nov 27, 2014 at 10:13 AM, Drew Wilson 
 atwil...@chromium.org
  wrote:
 
  What impact do we expect on web compatibility from apps that may
 already
  be adding attributes named include, etc to their String objects?
 
  I think that adding attributes that Firefox is already shipping
 should
  be relatively safe, but I'm very leery about being the first
 browser to add
  new attributes. What can we do to avoid a repeat of
 http://crbug.com/409858?
  Do we have any stats for how often these attributes are already
 in use in
  web pages (tricky, since some apps are legitimately using them
 for polyfill
  purposes)?
 
  Correct, this is tricky. We do not have stats (and it is unclear
 how to
  get those stats).
  'contains' was renamed to 'includes' precisely to reduce possible
 web
  compat breakage.
  Unfortunately we will not know of any breakage until we ship this
 - it
  has been available under a flag for some time, but it looks like
 nobody
  tests with 'Experimental Javascript features' enabled.
  Therefore enabling it early on canary in Chrome 41 process is our
 best
  mitigation in this particular case.
 
  I'm not sure let's just launch this and see who complains is an
  acceptable path forward given that this specific approach was tried
 last
  release with Array.values and blew up in our face. Why do we think
 this time
  will be any different?
 
  Can we perhaps restrict this to canary + dev channel (and maybe the
 first
  beta cut), but hold off on shipping to Stable until we find a way to
  generate stats?
 
  Shipping this now is de facto canary + dev.
  I do not know of a way to generate stats for this (unfortunately).

 What Dmitry said. Of course, if problems are discovered there, then we
 will roll back before the next beta. But if they aren't then we have
 no realistic way of knowing other than shipping it in beta. That's
 what beta is for, after all.

 The good news is that after the previous incident we changed our
 roll-out procedure such that unshipping a feature now consists of only
 swapping a macro invocation.

 It's also worth noting that we have shipped many other new features
 without any problems. Array.p.values was the only exception so far.


 On 27 November 2014 at 11:06, PhistucK phist...@gmail.com wrote:
  Can we add a console log (not a warning) for the canary/dev/beta run
  (perhaps stable, too?) for a little while to aid developers with
 possible
  breakages?
  If String.prototype.includes is overridden, deleted or accessed
 (called or
  gotten), the log would be printed.

 Unfortunately, I believe that is infeasible. As Dmitry already noted,
 it is not at all easy to diagnose the situation, even if you were
 willing to accept lots of false positives. JavaScript

[v8-users] Re: [blink-dev] Intent to ship: ES6 generator functions (V8)

[PhistucK]

Thank you for sharing! Exciting, I know a lot of developers have been
waiting for it. Hopefully Internet Explorer and Safari implements them soon
enough as well.

Do you intend to ship it with the referenced issues, or is the plan to fix
them before shipping (preferred, obviously)?


☆*PhistucK*

On Wed, Sep 17, 2014 at 1:39 PM, Andy Wingo wi...@igalia.com wrote:

 [FYI +blink-dev]

 ES6 defines a new language feature, generator functions [1].

 ES6 generator functions have been shipping in Firefox since version 26
 (December 2013) [2].  Although IE and Safari developers participated
 actively in the design of generator functions, and so we expect
 generator functions to be implemented by them, we don't know when.

 V8 has had generator functions since June 2013, under the
 --harmony-generators flag.  The specification has undegone minor changes
 since then, to which we have adapted.  To our knowledge, the V8
 implementation of generators is specification-compliant, with a few
 known bugs that will be fixed [3].  Work to nicely integrate generator
 objects with devtools is ongoing [4].

 Owners: wi...@igalia.com, rossb...@chromium.org

 [1]
 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator-function-definitions
 [2] https://developer.mozilla.org/en-US/Firefox/Releases/27#JavaScript
 [3] http://code.google.com/p/v8/issues/detail?id=3565
 [4] http://code.google.com/p/v8/issues/detail?id=3292

 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: Symbol Support

[PhistucK]

(Sorry for the delayed reply, I apparently opted out of getting e-mails to
threads I start. Weird)

Great, thank you!
I updated the article a bit with the compatibility data (for Opera as well)
and removed the false Symbol.prototype.name bit.


☆*PhistucK*




On Tuesday, August 12, 2014 11:30:37 PM UTC+3, Erik Arvidsson wrote:




 On Tue, Aug 12, 2014 at 4:03 PM, PhistucK phis...@gmail.com wrote:

 Can you share a bit more about the Symbol support in Chrome 38 onwards?
 I want to expand the compatibility data in MDN
 https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol
  a
 bit with the latest information.

 I understand that Symbols are supported. Symbol.iterator is supported
 and now Symbol.unscopables is also supported.
 What else?


 Those two are the only traps using symbols that have been implemented.


 Do Symbol.for and Symbol.keyFor do everything they should?


 Yes. These should work as expected. These are useful to synchronize
 Symbols across globals and we use these to ensure that an iterator from one
 frame is iterable in another frame.


 It also says Symbol.prototype.name http://symbol.prototype.name/ exists
 only in V8 - was it removed?


 It has been removed from the spec and from V8. You can still get the
 description by doing an explicit call to toString(). Implicit calls like +
 '' and String(sym) both fails.

 --
 erik



-- 
-- 
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] Symbol Support

[PhistucK]

Can you share a bit more about the Symbol support in Chrome 38 onwards?
I want to expand the compatibility data in MDN
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol
a bit with the latest information.

I understand that Symbols are supported. Symbol.iterator is supported and
now Symbol.unscopables is also supported.
What else?
Do Symbol.for and Symbol.keyFor do everything they should?
It also says Symbol.prototype.name exists only in V8 - was it removed?

Thank you!


☆*PhistucK*


On Thu, Aug 7, 2014 at 12:16 PM, Andy Wingo wi...@igalia.com wrote:

 For-of (for (x of iterable) {}) is a part of ES6 [1].

 For-of has been shipping in Firefox since version 27 (February 2014)
 [2].  IE and Safari developers have both shown willingness to implement
 this part of the new language standard.

 V8 has had for-of since June 2013, under the --harmony-iteration flag.
 It was recently changed to perform GetIterator [3] on the iterable, in
 conformance with the draft standard.

 At the same time, we are looking to ship standard @@iterator methods for
 arrays [4] and strings [5], so that one can iterate over arrays and
 strings natively:

   for (var x of [1,2,3]) console.log(x);

 These @@iterator implementations make use of the new ES6 symbol facility
 (also shipping in M38).

 V8's for-of implementation is complete with respect to the current draft
 standard, except for the late spec addition that causes for-of to shut
 down the iterator on early exit (via break or throw) [6].  We don't
 anticipate problems adding this functionality later, as it relies on the
 iterator having an optional close method, which no iterators have
 currently.

 Owners: wi...@igalia.com, rossb...@chromium.org

 [1]
 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-for-in-and-for-of-statements
 [2] https://developer.mozilla.org/en-US/Firefox/Releases/27#JavaScript
 [3] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-getiterator
 [4]
 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-string-iterator-objects
 [5]
 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array-iterator-objects
 [6] http://esdiscuss.org/notes/2014-06-05#closing-iterators

 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] Intent to ship: ES6 iteration (for-of)

[PhistucK]

Thank you for sharing the intent with blink-dev!

Does it mean that you also intend to ship @@iterator methods (unclear from
your post)?

How much of an effort is implementing the late specification addition? A
complete implementation is preferred. Can the lack of it be feature
detected quickly (throwing is not very nice to feature detect)?


☆*PhistucK*


On Thu, Aug 7, 2014 at 12:16 PM, Andy Wingo wi...@igalia.com wrote:

 For-of (for (x of iterable) {}) is a part of ES6 [1].

 For-of has been shipping in Firefox since version 27 (February 2014)
 [2].  IE and Safari developers have both shown willingness to implement
 this part of the new language standard.

 V8 has had for-of since June 2013, under the --harmony-iteration flag.
 It was recently changed to perform GetIterator [3] on the iterable, in
 conformance with the draft standard.

 At the same time, we are looking to ship standard @@iterator methods for
 arrays [4] and strings [5], so that one can iterate over arrays and
 strings natively:

   for (var x of [1,2,3]) console.log(x);

 These @@iterator implementations make use of the new ES6 symbol facility
 (also shipping in M38).

 V8's for-of implementation is complete with respect to the current draft
 standard, except for the late spec addition that causes for-of to shut
 down the iterator on early exit (via break or throw) [6].  We don't
 anticipate problems adding this functionality later, as it relies on the
 iterator having an optional close method, which no iterators have
 currently.

 Owners: wi...@igalia.com, rossb...@chromium.org

 [1]
 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-for-in-and-for-of-statements
 [2] https://developer.mozilla.org/en-US/Firefox/Releases/27#JavaScript
 [3] http://people.mozilla.org/~jorendorff/es6-draft.html#sec-getiterator
 [4]
 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-string-iterator-objects
 [5]
 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-array-iterator-objects
 [6] http://esdiscuss.org/notes/2014-06-05#closing-iterators

 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.

Re: [blink-dev] Fwd: [v8-users] Intent to ship ES6 promises weak collections

[PhistucK]

A small correction - Object.observe is not a shipping feature at the
moment. It may exist in Chrome 34 beta, but Chrome 33, which is the current
stable release, does not have it.

By the way, it would be nice to have all of the Chromium related (Blink,
V8, WebRTC and anything else that is built into Chromium) intent threads in
one place, instead of subscribing to many groups that publish intent
threads.
I guess this has caused Object.observe to be excluded from the latest Chromium
blog post about Chrome
34http://blog.chromium.org/2014/02/chrome-34-responsive-images-and_9316.html
.

For references, here is the missing intent thread for Object.observe -
https://groups.google.com/forum/#!searchin/v8-users/subject$3Aintent|sort:date/v8-users/aeSFJK1L5n4/zvC0E-2cXWUJ

And other V8 intent threads (mostly intents to implement.
ArrayBuffer.isView, Object.observe and this thread are the only intents to
ship) -
https://groups.google.com/forum/#!searchin/v8-users/subject$3Aintent%7Csort:date


☆*PhistucK*


On Thu, Mar 20, 2014 at 11:46 AM, Jochen Eisinger joc...@chromium.orgwrote:

 FYI - V8 promises will be enabled hopefully for M35. The v8 implementation
 was updated to reflect the Jan 30 changes.

 best
 -jochen

 -- Forwarded message --
 From: Andreas Rossberg rossb...@google.com
 Date: Mon, Mar 17, 2014 at 4:47 PM
 Subject: [v8-users] Intent to ship ES6 promises  weak collections
 To: v8-users@googlegroups.com v8-users@googlegroups.com


 We intend to soon ship both ES6 promises and weak collections
 unflagged in V8. Since the former depends on the latter, I'm combining
 both in this mail.


 PROMISES

 Promises have been accepted into ES6, and have hit the draft spec
 earlier this year [1]. They are already used in DOM APIs. Mozilla also
 plans to ship promises in FF25. The current implementation of promises
 in Chrome lives in Blink, a V8-side implementation has been done last
 fall.

 We intend to ship Chrome 35 with the V8 implementation replacing the
 Blink one, since it is more up-to-date wrt the latest spec changes,
 and (we believe) more efficient. That means that V8 will turn on
 promises by default (they are currently being moved to es-staging).

 Owners: rossb...@chromium.org, yhir...@chromium.org

 [1]
 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-promise-objects


 WEAK COLLECTIONS

 Weak maps and sets have been in the ES6 draft for a long time [2, 3],
 and our implementation has been stable for years. Moreover, it is
 (under internal APIs) already used in shipping features, such as
 Object.observe.

 Our self-hosted implementation of promises uses ES6 weak maps
 internally. Due to this dependency, we are moving both features to
 staging simultaneously, and intend to ship them together.

 Owner: mstarzin...@chromium.org

 [2]
 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakmap-objects
 [3]
 http://people.mozilla.org/~jorendorff/es6-draft.html#sec-weakset-objects

 --
 --
 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.

  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] V8 Launch Process and Guidelines

[PhistucK]

Not transparent quite yet - that link is not public and there is no
summary. ;)


☆*PhistucK*


On Mon, Sep 16, 2013 at 12:41 PM, Dmitry Lomov dslo...@chromium.org wrote:

 Following the lead of Blink in setting the web platform guidelines, we on
 the V8 team came up with a similar set of guidelines specific to V8. They
 are available at https://devsite.googleplex.com/v8/launchprocess.
 We hope this document will make our decision-making process even more open
 and transparent.

 Although we've given them some careful thought, we'll likely revise them
 over time based on our experiences and feedback from the community.

 With best regards,
 V8 team

 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/groups/opt_out.

[v8-users] Re: [chromium-dev] Re: [blink-dev] Re: V8 Launch Process and Guidelines

[PhistucK]

I am not talking about NaCl/PNaCl specifically, those were merely examples.
So this is most certainly relevant within this context. You turned it into
a NaCl/PNaCl oriented discussion. And frankly, it does not really matter if
it is standardized or not, it is not the issue at hand.
Chromium is the only project left that does not have any concrete and
transparent public guidelines with regards to what it exposes to the web
platform. It does not matter whether it takes a 'third party'
implementation and exposes it to the web platform, or implements something
on its own and exposes it. It exposes stuff to the web platform under non
transparent, non public guidelines.


☆*PhistucK*


On Mon, Sep 16, 2013 at 6:34 PM, Mike Frysinger vap...@chromium.org wrote:

 which isn't relevant.  if you want to talk about standardization of the
 NaCl/PNaCl projects, then you should start threads on the relevant
 NaCl/PNaCl mailing lists.
 -mike


 On Mon, Sep 16, 2013 at 11:32 AM, PhistucK phist...@gmail.com wrote:

 Right, but Chromium exposes them to the web platform, not Blink.


 ☆*PhistucK*


 On Mon, Sep 16, 2013 at 6:31 PM, Mike Frysinger vap...@chromium.orgwrote:

 NaCl/PNaCl are sep projects.  they would run their own guidelines
 independently of Chromium.
 -mike


 On Mon, Sep 16, 2013 at 11:28 AM, PhistucK phist...@gmail.com wrote:

 Yes, however, Chromium brings in PNaCl to the web platform. Chromium
 brings in VP8 with alpha support to the web platform. Chromium brings in
 VP9 support to the web platform.
 So while it is mostly a chrome around the web platform, it has its
 control as well, which is why those public service announcements (VP9)
 exist (mostly, but at least that). Announcements, though, not intents,
 which is a shame.


 ☆*PhistucK*


 On Mon, Sep 16, 2013 at 6:23 PM, Mike Frysinger vap...@chromium.orgwrote:

 Chromium isn't really part of the web platform.  it's the chrome
 around the web platform (i.e. Blink).
 -mike


 On Mon, Sep 16, 2013 at 11:18 AM, PhistucK phist...@gmail.com wrote:

 Only Chromium itself is left, right? :)


 ☆*PhistucK*


 On Mon, Sep 16, 2013 at 5:15 PM, Alex Komoroske 
 komoro...@chromium.org wrote:

 Thanks for sharing, Dmitry!

 Blink is just one of the sub-projects of Chromium that have
 web-developer facing features, and it's great to see other sub-projects
 like V8 thinking carefully about how to release new features on the open
 web.


 On Mon, Sep 16, 2013 at 5:27 AM, Dmitry Lomov 
 dslo...@chromium.orgwrote:

 Terribly sorry, the correct link is
 https://developers.google.com/v8/launchprocess

 Thanks,
 Dmitry
 On Sep 16, 2013 11:41 AM, Dmitry Lomov dslo...@chromium.org
 wrote:

 Following the lead of Blink in setting the web platform
 guidelines, we on the V8 team came up with a similar set of guidelines
 specific to V8. They are available at
 https://devsite.googleplex.com/v8/launchprocess.
 We hope this document will make our decision-making process even
 more open and transparent.

 Although we've given them some careful thought, we'll likely
 revise them over time based on our experiences and feedback from the
 community.

 With best regards,
 V8 team


  To unsubscribe from this group and stop receiving emails from it,
 send an email to blink-dev+unsubscr...@chromium.org.


  --
 --
 Chromium Developers mailing list: chromium-...@chromium.org
 View archives, change email options, or unsubscribe:
 http://groups.google.com/a/chromium.org/group/chromium-dev








-- 
-- 
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] Re: [chromium-dev] Re: [blink-dev] Re: V8 Launch Process and Guidelines

[PhistucK]

Yes, however, Chromium brings in PNaCl to the web platform. Chromium brings
in VP8 with alpha support to the web platform. Chromium brings in VP9
support to the web platform.
So while it is mostly a chrome around the web platform, it has its control
as well, which is why those public service announcements (VP9) exist
(mostly, but at least that). Announcements, though, not intents, which is a
shame.


☆*PhistucK*


On Mon, Sep 16, 2013 at 6:23 PM, Mike Frysinger vap...@chromium.org wrote:

 Chromium isn't really part of the web platform.  it's the chrome around
 the web platform (i.e. Blink).
 -mike


 On Mon, Sep 16, 2013 at 11:18 AM, PhistucK phist...@gmail.com wrote:

 Only Chromium itself is left, right? :)


 ☆*PhistucK*


 On Mon, Sep 16, 2013 at 5:15 PM, Alex Komoroske 
 komoro...@chromium.orgwrote:

 Thanks for sharing, Dmitry!

 Blink is just one of the sub-projects of Chromium that have
 web-developer facing features, and it's great to see other sub-projects
 like V8 thinking carefully about how to release new features on the open
 web.


 On Mon, Sep 16, 2013 at 5:27 AM, Dmitry Lomov dslo...@chromium.orgwrote:

 Terribly sorry, the correct link is
 https://developers.google.com/v8/launchprocess

 Thanks,
 Dmitry
 On Sep 16, 2013 11:41 AM, Dmitry Lomov dslo...@chromium.org wrote:

 Following the lead of Blink in setting the web platform guidelines, we
 on the V8 team came up with a similar set of guidelines specific to V8.
 They are available at https://devsite.googleplex.com/v8/launchprocess
 .
 We hope this document will make our decision-making process even more
 open and transparent.

 Although we've given them some careful thought, we'll likely revise
 them over time based on our experiences and feedback from the community.

 With best regards,
 V8 team


  To unsubscribe from this group and stop receiving emails from it, send
 an email to blink-dev+unsubscr...@chromium.org.


  --
 --
 Chromium Developers mailing list: chromium-...@chromium.org
 View archives, change email options, or unsubscribe:
 http://groups.google.com/a/chromium.org/group/chromium-dev




-- 
-- 
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] Parse\Runtime Issues

[PhistucK]

I have some questions and need some clarifications.

When I try this code -
!DOCTYPE HTML
html
script
var a = o;
var b = c;
if (a == o)
 if (b == b)
 {
  alert(a is o);
  alert(b is b);
 };
else
{
 alert(a is not o);
};
/script
/html

It shows -
Uncaught SyntaxError: Unexpected token else

Should that error be triggered? can you explain why?



Also, running it without that semicolon -
!DOCTYPE HTML
html
script
var a = o;
var b = c;
if (a == o)
 if (b == b)
 {
  alert(a is o);
  alert(b is b);
 }
else
{
 alert(a is not o);
};
/script
/html

Shows an alert - a is not o.
As far as I know, if and else count as two statements. If they are, the
else block is actually part of the first if statement.
Am I misinformed, or is it a bug?


Thank you for your time!

☆*PhistucK*

-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users

Re: [v8-users] Parse\Runtime Issues

[PhistucK]

I am trying it within Chromium.
I posted it to v8-users, because it is a JavaScript issue, rather than a
rendering issue.
The syntax error does not show up on Internet Explorer 8. It does, however,
show up on Internet Explorer 9 (one of the platform previews).


☆*PhistucK*



On Fri, Jan 28, 2011 at 14:17, Stephan Beal sgb...@googlemail.com wrote:

 On Fri, Jan 28, 2011 at 1:02 PM, PhistucK phist...@gmail.com wrote:

 !DOCTYPE HTML
 .../html
 It shows -
 Uncaught SyntaxError: Unexpected token else


  It _should_ be saying that the unknown token is the DOCTYPE tag, because
 v8 does not parse HTML.


 Also, running it without that semicolon -
 !DOCTYPE HTML


 Stop trying to feed HTML to v8, and the problem should go away. Feed it
 only the content of your script tag.

 - Shows an alert - a is not o.

 The you're not using v8 direcly - v8 has no built-in alert() method.

 Are you sure you don't mean Chromium instead of v8?

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/

  --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users


-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users

Re: [v8-users] Parse\Runtime Issues

[PhistucK]

Thank you for the very quick reply!

Got it, I think.. well, not entirely. Which is why I am asking regarding the
second code (without the semicolon) I posted in the original message.
Can you, please, clarify the behavior of the second code I posted?



☆*PhistucK*



On Fri, Jan 28, 2011 at 14:15, Lasse R.H. Nielsen l...@chromium.org wrote:

 The SyntaxError is correct. If you check other browsers, you will see that
 they give the same result.

 The problem here is the ';' after the then-branch of the second/inner if.

 An if-statement has the condition followed by exactly one statement (then
 then-branch), and then, optionally, the keyword else and another single
 statement (the else-branch). That single statement can be, and often is, a
 block statement.

 The block with the two alerts is the then-statment. The following ';' isn't
 part of that statement (block statements are not terminated by semicolons),
 so it must be another empty and unrelated statement. I.e., the
 then-statement was not followed by the else keyword, so the if-statement
 ends there. Ditto for the outer if statement.
 Then comes an else keyword that's not part of any if-statement, which is
 a syntax error.

 Best of luck
 /Lasse


 On Fri, Jan 28, 2011 at 13:02, PhistucK phist...@gmail.com wrote:

 I have some questions and need some clarifications.

 When I try this code -
 !DOCTYPE HTML
 html
 script
 var a = o;
 var b = c;
 if (a == o)
  if (b == b)
  {
   alert(a is o);
   alert(b is b);
  };
 else
 {
  alert(a is not o);
 };
 /script
 /html

 It shows -
 Uncaught SyntaxError: Unexpected token else

 Should that error be triggered? can you explain why?



 Also, running it without that semicolon -
 !DOCTYPE HTML
 html
 script
 var a = o;
 var b = c;
 if (a == o)
  if (b == b)
  {
   alert(a is o);
   alert(b is b);
  }
 else
 {
  alert(a is not o);
 };
 /script
 /html

 Shows an alert - a is not o.
 As far as I know, if and else count as two statements. If they are,
 the else block is actually part of the first if statement.
 Am I misinformed, or is it a bug?


 Thank you for your time!

 ☆*PhistucK*

 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users




 --
 Lasse R.H. Nielsen
 l...@google.com
 'Faith without judgement merely degrades the spirit divine'
 Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K -
 Denmark - CVR nr. 28 86 69 84

 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users

-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users

Re: [v8-users] Parse\Runtime Issues

[PhistucK]

I added HTML code because the syntax error does not occur on Internet
Explorer 8 (for example) and it is easier to test when you have the entire
code ready.

So you are basically saying that if and else do not count as two
statements, right?

I guess I am confused, because I recently found out you can actually run
this code without any error -
if (some_condition)
 some_function();
else
 some_other_function();

☆*PhistucK*



2011/1/28 Mikael Helbo Kjær m...@designtech.dk

 Hi there.



 This is not the usual thing to ask here (I’d go for some sort of Javascript
 forum in the future).



 I think you don’t need to include any sort of HTML here to get ppl to look
 at your JS.



 First problem:

 You have a ; after the end of your if block (I’ve marked it below), that
 ends the if else statement too early. Else cannot stand alone so to speak.



 Second problem: your blocks are not entirely right here. The parser can
 only follow the rules here. The if sentence either deals with the next
 statement (line) or block. Only if that line or block is directly followed
 by an else or else if can that be included. A corrected (untested assumption
 here) example could be (there is more than one way to do it):



 var a = “0”

 var b = “c”

 if (a == “0”)

 {

  if (b == “b”)

 {

 alert(“a is o”);

 alert(“b is b”);

 }

 }

 else

 {

 alert(“a is not o”);

 }



 /Mikael



 When I try this code -

 !DOCTYPE HTML

 html

 script

 var a = o;

 var b = c;

 if (a == o)

  if (b == b)

  {

   alert(a is o);

   alert(b is b);

  }; ß Problem here

 else

 {

  alert(a is not o);

 };

 /script

 /html



 It shows -

 Uncaught SyntaxError: Unexpected token else



 Should that error be triggered? can you explain why?







 Also, running it without that semicolon -

 !DOCTYPE HTML

 html

 script

 var a = o;

 var b = c;

 if (a == o)

  if (b == b)

  {

   alert(a is o);

   alert(b is b);

  }

 else

 {

  alert(a is not o);

 };

 /script

 /html



 Shows an alert - a is not o.

 As far as I know, if and else count as two statements. If they are, the
 else block is actually part of the first if statement.

 Am I misinformed, or is it a bug?



 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users


-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users

Re: [v8-users] Parse\Runtime Issues

[PhistucK]

This makes everything much clearer.
Thank you very much for your time.

☆*PhistucK*



On Fri, Jan 28, 2011 at 15:22, Lasse R.H. Nielsen l...@chromium.org wrote:

 If and else are not two statements. It's two different forms of the
 if-statement.

 The if statement is a compound statement, meaning that it can contain other
 statements as parts of itself. Those statements are either just the
 mandatory then-branch, or the then-branch and an else-branch. The
 if-statement still counts as one statement itself.

 The code:

   if (some_condition)
some_function();
   else
some_other_function();
 is an example of this. It has two branches, each being exactly one
 statement (in this case ExpressionStatements, which are an Expression
 followed by a semicolon). The presence of the else-branch is marked by the
 first statement being *immediately* followed by the keyword else and then
 the else-branch statement.

 A block statement is another compound statement. It can contain an
 arbitrary number of other statements. So,
   if (condition)
 { x = 2; y = 4; }
   else
 some_function();
 is also valid. The then-branch is a single statement, which is a statement
 block containing two other statements. It's traditionally written
  if (condition) {
x = 2;
y = 4;
  } else {
some_function();
  }
 but the {'s are not part of the if-statment syntax, but part of the
 block-statement syntax.

 With that in mind, you have code on the form:
   if (c1) if (c2) s1 else s2

 In this case, the else binds to the closest if, so it's equivalent to:
   if (c1) { if (c2) s1 else s2 }
 and not
   if (c1) { if (c2) s1 } else s2
 which is why you get a is not o.

 The syntax for if-statements comes from the C language (or possibly from
 the precursor B). It's not specific to JavaScript.

 Best of luck
 /Lasse

 On Fri, Jan 28, 2011 at 13:39, PhistucK phist...@gmail.com wrote:

 I added HTML code because the syntax error does not occur on Internet
 Explorer 8 (for example) and it is easier to test when you have the entire
 code ready.

 So you are basically saying that if and else do not count as two
 statements, right?

 I guess I am confused, because I recently found out you can actually run
 this code without any error -
 if (some_condition)
  some_function();
 else
  some_other_function();

 ☆*PhistucK*



 2011/1/28 Mikael Helbo Kjær m...@designtech.dk

 Hi there.



 This is not the usual thing to ask here (I’d go for some sort of
 Javascript forum in the future).



 I think you don’t need to include any sort of HTML here to get ppl to
 look at your JS.



 First problem:

 You have a ; after the end of your if block (I’ve marked it below), that
 ends the if else statement too early. Else cannot stand alone so to speak.



 Second problem: your blocks are not entirely right here. The parser can
 only follow the rules here. The if sentence either deals with the next
 statement (line) or block. Only if that line or block is directly followed
 by an else or else if can that be included. A corrected (untested assumption
 here) example could be (there is more than one way to do it):



 var a = “0”

 var b = “c”

 if (a == “0”)

 {

  if (b == “b”)

 {

 alert(“a is o”);

 alert(“b is b”);

 }

 }

 else

 {

 alert(“a is not o”);

 }



 /Mikael



 When I try this code -

 !DOCTYPE HTML

 html

 script

 var a = o;

 var b = c;

 if (a == o)

  if (b == b)

  {

   alert(a is o);

   alert(b is b);

  }; ß Problem here

 else

 {

  alert(a is not o);

 };

 /script

 /html



 It shows -

 Uncaught SyntaxError: Unexpected token else



 Should that error be triggered? can you explain why?







 Also, running it without that semicolon -

 !DOCTYPE HTML

 html

 script

 var a = o;

 var b = c;

 if (a == o)

  if (b == b)

  {

   alert(a is o);

   alert(b is b);

  }

 else

 {

  alert(a is not o);

 };

 /script

 /html



 Shows an alert - a is not o.

 As far as I know, if and else count as two statements. If they are,
 the else block is actually part of the first if statement.

 Am I misinformed, or is it a bug?



 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users


  --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users




 --
 Lasse R.H. Nielsen
 l...@google.com
 'Faith without judgement merely degrades the spirit divine'
 Google Denmark ApS - Frederiksborggade 20B, 1 sal - 1360 København K -
 Denmark - CVR nr. 28 86 69 84

 --
 v8-users mailing list
 v8-users@googlegroups.com
 http://groups.google.com/group/v8-users


-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users

[v8-users] Numeric Key Names In Objects Get Automatically Sorted In V8\Chrome

[PhistucK]

Try this example -
javascript:p = {928: f, 282: v}; for (x in p) alert(x);
Chrome will alert 282 and then 928 while all of the other browsers that
I have tested (FireFox 3.6, Internet Explorer 6\7\8) alerts 928 and then
282.

I have not tested Safari, or anything not on Windows.

Is this a bug?

Thank you.


☆*PhistucK*

-- 
v8-users mailing list
v8-users@googlegroups.com
http://groups.google.com/group/v8-users