Re: [v8-users] Serialization Side Effects

On Tue, Aug 4, 2020 at 1:32 PM Adrienne Walker wrote: > On Thu, Jul 30, 2020 at 9:57 PM Ben Noordhuis wrote: > >> On Thu, Jul 30, 2020 at 8:21 PM Adrienne Walker >> wrote: >> > Is there any way to know from a v8::Value whether serializing it will >> have side effects (at all or on particular pr

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

Thanks to the API owners for LGTMs. Due to the Chrome release pause, though, I'd suggest that Frank work with Shu on the right next steps here in V8; it's likely not appropriate to flip this flag until releases are unpaused. On Tue, Mar 24, 2020 at 10:01 AM Mike West wrote: > LGTM3. > > -mike >

[v8-users] Re: [blink-dev] Intent to Implement: Top Level Await

On Thu, Aug 8, 2019 at 4:38 AM Yoav Weiss wrote: > > > On Wed, Aug 7, 2019 at 8:39 PM Joshua Litt > wrote: > >> Contact emails joshual...@chromium.org Explainer >> https://github.com/tc39/proposal-top-level-await Design docs/spec >> Specification: https://tc39.es/proposal-top-level-await/ >> htt

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

On Fri, Jun 21, 2019 at 12:09 AM Yoav Weiss wrote: > > > On Wed, Jun 19, 2019 at 9:07 PM Adam Klein wrote: > >> Hi Yoav, >> >> We don't have existing metrics that would help here, and I honestly don't >> even know what we would track for th

Re: [v8-users] Repeated module evaluation.

le() again to get another Module object; I believe this should hit the in-memory cache and be very fast, and should let you go back through the Instantiate/Evaluate cycle in C2. > On Wednesday, June 19, 2019 at 5:21:43 PM UTC-4, Adam Klein wrote: >> >> When you say "local

Re: [v8-users] Repeated module evaluation.

ocs/Web/JavaScript/Reference/Statements/import#Import_a_module_for_its_side_effects_only). > And since side effects can be local to the evaluation context, it should be > possible to evaluate a module in multiple contexts. > > Opinions? > > On Wednesday, February 20, 2019 at 2:54:26 PM UT

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

Hi Yoav, We don't have existing metrics that would help here, and I honestly don't even know what we would track for this specific issue (detecting that a certain exception came from eval, for example, isn't something we currently track). Bug reports are how we tend to track issues like this. And

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

y that is > fully consistent with other options in that schema. > > Shane > > On Thu, May 23, 2019 at 6:43 PM Frank Tang (譚永鋒) wrote: > >> >> >> On Thu, 23 May 2019 at 01:31, Adam Klein wrote: >> >>> On Thu, May 23, 2019 at 1:11 AM Frank Tang wrote:

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

On Thu, May 23, 2019 at 1:11 AM Frank Tang wrote: > Contact emails ft...@chromium.org,js...@chromium.org Explainer > https://github.com/tc39/ecma402/pull/346 > I'd like to better-understand the ECMA 402 process around small additions like this (and your other email about "quarter"). Will this be

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

(+ftang) On Wed, May 8, 2019 at 11:27 AM Adam Klein wrote: > Happy to see this moving forward! A note, below, on the (new-to-V8) intent > process. > > On Mon, May 6, 2019 at 10:48 AM Frank Tang wrote: > >> cc v8-users@ >> >> On Fri, May 3, 2019 at 7:58 PM Frank

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

Happy to see this moving forward! A note, below, on the (new-to-V8) intent process. On Mon, May 6, 2019 at 10:48 AM Frank Tang wrote: > cc v8-users@ > > On Fri, May 3, 2019 at 7:58 PM Frank Tang wrote: > >> opps. forgot to include the blink-dev@ in the To field. >> >> On Fri, May 3, 2019 at 7:5

[v8-users] Re: [blink-dev] Intent to Ship: Promise.{all, race, allSettled} optimization

Non-API owner LGTM, as this is a very low-risk change. Its only expected impact will be a performance improvement/simplification. And a reminder to API owners to look at this, since we've just switched V8/JS features over to using the Blink Intent process. On Thu, Apr 25, 2019 at 11:44 AM Sathya

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

LGTM! On Tue, Apr 23, 2019 at 4:19 PM Sathya Gunasekaran wrote: > Contact Emails: > gsat...@chromium.org > > Spec: > https://tc39.github.io/proposal-promise-allSettled/ > > Summary: > Promise.allSettled returns a promise that is fulfilled with an array > of promise state snapshots, but only afte

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

LGTM2 On Thu, Apr 18, 2019 at 4:21 PM Sathya Gunasekaran wrote: > LGTM > > On Thu, Apr 18, 2019 at 4:02 PM Frank Tang wrote: > >> *Intend to Ship: Locale sensitive BigInt.prototype.toLocaleString & allow >> Intl.NumberFormat format/formatToParts to take BigInt* >> >> >> Spec >> >> https://githu

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

LGTM! +blink-dev FYI On Tue, Apr 9, 2019 at 2:40 PM Ben Smith wrote: > Contact emails > > bi...@chromium.org > > Spec > > https://github.com/WebAssembly/bulk-memory-operations > > Summary > > The WebAssembly Bulk memory proposal adds 7 new instructions for > manipulating memory and tables in bu

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

Mar 28, 2019 at 12:01 PM 'Sathya Gunasekaran' via blink-dev < >> blink-...@chromium.org> wrote: >> >>> On Thu, Mar 15, 2018 at 2:25 PM Adam Klein wrote: >>> > >>> > There's a possible conflict between this feature and another proposal

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

LGTM! On Tue, Mar 12, 2019 at 5:31 PM Ben Smith wrote: > Contact emails > > bi...@chromium.org > > Spec > > https://github.com/WebAssembly/nontrapping-float-to-int-conversions >

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

LGTM!! On Wed, Feb 20, 2019 at 12:20 PM 'Mathias Bynens' via blink-dev < blink-...@chromium.org> wrote: > LGTM > > On Wed, Feb 20, 2019 at 8:58 PM Sathya Gunasekaran > wrote: > >> Contact Emails >> >> gsat...@chromium.org >> >> >> Spec >> >> https://github.com/tc39/proposal-class-fields >> >> >>

Re: [v8-users] Repeated module evaluation.

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

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

LGTM to ship, one note inline On Tue, Feb 19, 2019 at 9:59 PM Frank Tang (譚永鋒) wrote: > Spec > > https://tc39.github.io/proposal-intl-locale/ > > Summary > > A Stage 3 proposal that introduces a new standard built-in property of the > Intl object, which allows the following: > >- > >Pars

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

LGTM2 On Thu, Dec 13, 2018 at 3:27 PM Sathya Gunasekaran wrote: > LGTM > On Thu, Dec 13, 2018 at 2:01 PM Peter Wong > wrote: > > > > Contact emails > > peter.wm.w...@gmail.com > > jgru...@chromium.org > > yang...@chromium.org > > > > math...@chromium.org > > > > > > Spec > > https://github.com/

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

de, the isolate is forcibly terminated > and then the control is back to v8? > > I'm not intimately familiar with the details here. Yang or Toon, perhaps you have more insight? > > > On Fri, Nov 9, 2018 at 5:30 AM Adam Klein wrote: > >> Adding a couple more V

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

Adding a couple more V8 folks who may have thoughts. On Thu, Nov 8, 2018 at 1:59 AM Kentaro Hara wrote: > On Thu, Nov 8, 2018 at 1:10 AM Yuki Shiino > wrote: > >> +adamk, cbruni to get more attention from V8 team. This needs V8 team's >> support. >> >> Actually, I intended haraken's (a3) at my

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

LGTM3 On Thu, Nov 8, 2018 at 9:16 AM 'Mathias Bynens' via blink-dev < blink-...@chromium.org> wrote: > LGTM2 > > On Thu, Nov 8, 2018 at 2:44 AM Sathya Gunasekaran > wrote: > >> LGTM >> >> On Thu, Nov 8, 2018 at 12:20 AM Frank Tang wrote: >> >>> Spec >>> >>> https://tc39.github.io/proposal-intl-

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

LGTM. I'm super-excited about this shipping! On Wed, Oct 17, 2018 at 9:47 AM Sathya Gunasekaran wrote: > Contact Emails: > gsat...@chromium.org > > Spec: > https://github.com/tc39/proposal-class-fields > https://tc39.github.io/proposal-static-class-features/ > > The linked proposal includes priv

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

LGTM On Wed, Oct 3, 2018 at 8:09 AM 'Mathias Bynens' via v8-users < v8-users@googlegroups.com> wrote: > Contact emails > > math...@chromium.org > > Spec > > https://github.com/tc39/proposal-well-formed-stringify > > Summary > > A Stage 3 proposal changes JSON.stringify to prevent it from returnin

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

LGTM2 On Fri, Sep 28, 2018 at 9:39 AM 'Mathias Bynens' via v8-users < v8-users@googlegroups.com> wrote: > LGTM > > On Fri, Sep 28, 2018 at 9:26 AM Maya Lekova wrote: > >> >> >> >> >> >> >> >> >> >> >> *Contact emailsmslek...@chromium.org >> Explainerhttps://docs.google.com/document/d/1kL08cz4lR6

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

LGTM2 On Tue, Sep 25, 2018 at 2:35 AM Sathya Gunasekaran wrote: > LGTM > > On Mon, Sep 24, 2018 at 5:35 PM Frank Tang wrote: > >> Spec >> >> https://tc39.github.io/proposal-intl-relative-time/ >> >> Summary >> >> A Stage 3 proposal that introduces a new formatter under Intl. >> >> Intl.Relative

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

This LGTM, based on the stage at TC39. It'd be nice if we knew more about other browser plans, given the history here. Do you know if Firefox has plans to try again with this name anytime soon? On Thu, Aug 30, 2018 at 1:24 AM 'Mathias Bynens' via v8-users < v8-users@googlegroups.com> wrote: > Co

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

ing 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

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

ld you be interested in adding such a counter? > Also, Node does not have to use V8 anymore, just saying. ;) > > ☆*PhistucK* > > > On Thu, Jul 26, 2018 at 7:59 PM Adam Klein wrote: > >> +Jungshik and Dan, who I believe worked on this feature in V8 originally. >> I&#

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

+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 chang

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

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

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

LGTM for V8! On Fri, Mar 2, 2018 at 11:25 AM, Jakob Kummerow wrote: > Note that this is a v8/JavaScript feature, so this post is just an FYI for > blink-dev — no signoff from Blink API owners is required. > > > *Contact emails* > > jkumme...@chromium.org, n...@chromium.org > > > *Explainer* > >

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

LGTM3! On Fri, Feb 9, 2018 at 12:52 PM, Sathya Gunasekaran wrote: > LGTM > > On Fri, Feb 9, 2018 at 8:36 AM, Benedikt Meurer > wrote: > >> LGTM >> >> >> Mathias Bynens schrieb am Fr., 9. Feb. 2018, >> 16:36: >> >>> Contact emails math...@chromium.org Spec https://github.com/tc39/propos >>> al-

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

There's been discussion of doing that, but nothing official has changed (yet). +hablich, as I believe this is on his plate at the moment. On Fri, Jan 26, 2018 at 12:37 AM, Jochen Eisinger wrote: > I thought V8 wanted to use the blink process nowadays? > > On Thu, Jan 18, 2018 at

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

LGTM! Note that this is a v8/JavaScript feature, so this is just an FYI for blink-dev at the moment. On Thu, Jan 18, 2018 at 12:19 PM, Sathya Gunasekaran wrote: > Contact Emails: > gsat...@chromium.org > bak...@gmail.com > > Spec: > https://tc39.github.io/proposal-optional-catch-binding/ > > Su

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

LGTM (for v8 signoff purposes). On Thu, Nov 9, 2017 at 1:38 PM, 'Mathias Bynens' via blink-dev < blink-...@chromium.org> wrote: > Note that since this is a V8/JS feature, this post is just an FYI to > blink-dev — no signoff from Blink API owners is required. > > On Thu, Nov 9, 2017 at 10:29 PM, M

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

LGTM! On Wed, Oct 18, 2017 at 12:16 AM, Jakob Gruber wrote: > Contact emails > jgru...@chromium.org > > Spec > https://github.com/tc39/proposal-regexp-named-groups > > Summary > Named captures for ECMAScript regular expressions allow developers to > create and refer to named capture groups. > >

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

;>> > >>> On Sun, Sep 10, 2017 at 7:16 PM, Daniel Ehrenberg > >>> wrote: > >>> > ECMA 402 (Intl) tracks its proposals separately. You can see it > listed > >>> > as Stage 3 at https://github.com/tc39/ecma402/ . There is a full > >>>

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

lar, Mozilla has been pushing these proposals for some time, > and has been held back by lack of buy-in from other browser vendors. > > Dan > > On Mon, Sep 11, 2017 at 11:32 PM, Adam Klein wrote: > > I have the same question here as my latest question on the PluralRules >

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

LGTM! On Tue, Sep 12, 2017 at 9:48 AM, Caitlin Potter wrote: > *Contact Emails* > > ca...@chromium.org > > *Spec* > > https://tc39.github.io/proposal-async-iteration/ > > *Summary* > > Async Generators and the new Async Iteration protocol provide tools for > implementing and consuming data sourc

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

I have the same question here as my latest question on the PluralRules thread: any idea why Firefox isn't shipping this (yet), given they have it implemented? On Sun, Sep 10, 2017 at 2:03 PM, Josh Wolfe wrote: > # Contact emails > > jwo...@igalia.com > little...@chromium.org > > # Spec > > https

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

402 (Intl) tracks its proposals separately. You can see it listed > > as Stage 3 at https://github.com/tc39/ecma402/ . There is a full > > implementation in Firefox behind a flag. I'd say this spec is pretty > > stable. > > > > Dan > > > > On Fri,

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

What's the stability state of the spec? I don't see it on https://github.com/tc39/proposals On Fri, Sep 8, 2017 at 9:41 AM, Josh Wolfe wrote: > # Contact emails > > jwo...@igalia.com > little...@chromium.org > > # Spec > > https://rawgit.com/caridy/intl-plural-rules-spec/master/index.html > > #

[v8-users] Re: [blink-dev] Intent to Ship: Promise.prototype.finally

LGTM! On Thu, Sep 7, 2017 at 11:04 AM, Sathya Gunasekaran wrote: > Contact Emails: > gsat...@chromium.org > > Spec: > https://tc39.github.io/proposal-promise-finally/ > > Summary: > This finally method is used for registering a callback to be invoked > when a promise is settled (either fulfilled

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

LGTM! On Sun, Jul 30, 2017 at 7:18 AM, Mathias Bynens wrote: > Contact emails > > yang...@chromium.org, little...@chromium.org, erikco...@chromium.org, > math...@chromium.org > > Spec > > https://github.com/tc39/proposal-regexp-lookbehind (stage 3 proposal) > > Summary > > Lookarounds are zero-w

[v8-users] Re: [blink-dev] Intent to ship: RegExp `dotAll` mode / `s` flag

This LGTM to ship. Note that since this is a V8/JS feature, it's just an FYI to blink-dev; it doesn't need signoff from Blink API owners. On Thu, Jul 27, 2017 at 3:29 AM, Mathias Bynens wrote: > Contact emails > > jgru...@chromium.org, math...@chromium.org > > Spec > > https://github.com/tc39/pr

[v8-users] Re: [blink-dev] Intent to ship: allowing invalid escape sequences in tagged template literals

LGTM! On Fri, Jul 14, 2017 at 12:03 PM, no spoon wrote: > Contact email: bak...@gmail.com > > Spec: https://tc39.github.io/proposal-template-literal-revision/ > > This feature is stage 4 and will be included in the 2018 edition of > ECMA-262. > > Summary: ES6 template literals forbid certain esc

Re: [blink-dev] Re: [v8-users] Re: Intent to Implement: JavaScript module import()

Good news: this is already part of the spec (and this implementation). For module scripts (loaded either via

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

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

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

On Wed, Jun 21, 2017 at 9:44 AM, PhistucK wrote: > Has anyone run the full test262 test suite within a module scope, just to > make sure all of the ordinary features work there the same? > (I understand that from a point of view of an implementor, this might seem > unnecessary, because it is the

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

On Wed, Jun 21, 2017 at 8:25 AM, Domenic Denicola wrote: > From: blink-...@chromium.org [mailto:blink-...@chromium.org] On Behalf Of > PhistucK > > > What about test-262 (web-platform-tests are not supposed to test > ECMAScript features) for modules?​ > > This is not an ECMAScript feature; this i

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

Thanks, LGTM to ship! On Thu, Apr 20, 2017 at 12:38 PM, Sathya Gunasekaran wrote: > On Thu, Apr 20, 2017 at 12:31 PM, Adam Klein wrote: > > Are there test262 tests for this feature (do we pass them?)? > > > > Yes. The tests were added here -- > https://github.com

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

Are there test262 tests for this feature (do we pass them?)? On Thu, Apr 20, 2017 at 12:27 PM, Sathya Gunasekaran wrote: > Contact Emails: > gsat...@chromium.org > > Spec: > https://tc39.github.io/proposal-object-rest-spread/ > > Summary: > ECMAScript 6 introduced rest elements for array destruc

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

LGTM On Fri, Jan 13, 2017 at 1:55 PM, jwolfe wrote: > Summary: > > Allow a trailing comma in function parameter declarations and > function call parameters. Example: > > function f(a, b,) { > return a + b; > } > let g = (a, b,) => a + b; > f(1, 2,) + g(3, 4,); > > The purpose of this feature i

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

Hi Owen, I meant to respond to your email to blink-dev last month, but the holidays conspired to keep me from giving a reasonable status update there. The short story is that there is work well underway to get modules working in Chromium; we have a prototype patch that now needs to be split into p

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

LGTM2 On Fri, Dec 16, 2016 at 3:38 PM, 'Daniel Ehrenberg' via v8-users < v8-users@googlegroups.com> wrote: > LGTM > > On Fri, Dec 16, 2016 at 3:00 PM, Jungshik Shin (신정식, 申政湜) > wrote: > > Cross-posting to v8-dev@ > > > > Contact emails > > js...@chromium.org > > Spec > > > > https://github.com/

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

LGTM! On Tue, Sep 20, 2016 at 2:19 PM, 'Daniel Ehrenberg' via blink-dev < blink-...@chromium.org> wrote: > Contact emails > > *little...@chromium.org * > > Spec > > Async Functions, Stage 4 at TC39 > > > Summary > Async functions make it easy to wri

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

LGTM Please do make a Chromestatus entry. On Tue, Aug 16, 2016 at 10:10 AM, wrote: > Intl.getCanonicalLocales [1] is a part of ECMAScript 2016 > Internationalization API > > Specification. It exposes an existing internal method to canonicalize the > > locale list and returns the result in an ar

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

+bcc blink-dev This lgtm to ship! A few questions/comments below. On Thu, Jul 28, 2016 at 12:03 PM, Caitlin Potter wrote: > Object.getOwnPropertyDescriptors() has been implemented in V8 since > February 2016, and enabled by the "Experimental Javascript Features" flag > in Chrome since March. Th

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

The assertOptimized approach seems like a good balance to me of: 1. Avoiding duplicating the assertion helpers and 2. Avoiding broadening d8's runtime environment Then the only other requirement is that the usage of assertAsync (or whatever it's called) in tests isn't affected by the concerns abo

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

lgtm2 On Wed, May 11, 2016 at 10:58 AM, Jochen Eisinger wrote: > lgtm1 > > Daniel Ehrenberg schrieb am Mi., 11. Mai 2016, > 19:55: > >> Primary eng email >> little...@chromium.org >> >> *Summary* >> Remove most of V8's additional methods and properties in ECMA 402 (Intl), >> namely v8Parse, res

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

LGTM to ship, given the stage 4 state of the spec and our compat with the test262 tests. On Tue, May 3, 2016 at 10:26 AM, Caitlin Potter wrote: > I was mistaken, the FireFox bug was just a symptom of a well known Symbol > not being present yet in FireFox. > > So, there are no known compat/intero

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

LGTM2 On Fri, Apr 15, 2016 at 6:52 AM, Caitlin Potter wrote: > [FYI +blink-dev] > > Contact emails > ca...@igalia.com > > Spec > Feature has been merged into ECMA262 specification [1] > > Summary > Introduces arithmetic operators `**` and `**=`, which behaves as though > Math.pow() were called,

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

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

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

, Jan 8, 2016 at 11:09 AM, Adam Klein 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 othe

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

9:43 AM, Adam Klein 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

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

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

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

t; 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 pr

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

[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 know

Re: [v8-users] How to advance an iterator.

You're missing a function call: myIterable[Symbol.iterator]().next() // note parens after the closing bracket This follows the spec-internal method GetIterator: http://tc39.github.io/ecma262/#sec-getiterator On Tue, Nov 3, 2015 at 5:45 PM, Jane Chen wrote: > 4.6.88. Just tried it in v8 shell

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

[bcc blink-dev FYI] I'm happy to see this shipped, as it's been implemented for quite awhile and the API is about as stable as you could get. On Tue, Aug 11, 2015 at 11:03 AM, Domenic Denicola wrote: > The Array.prototype.includes proposal [1] is on track for ES2016 and is > currently in stage

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

The 'new.target' meta-property[1] is part of ECMAScript 2015. It provides access to the constructor function which was invoked by 'new' (if a construct call is underway) or undefined otherwise. Firefox plans to ship it in version 41 [2]. This is the last piece of the ES'15 class semantics to ship

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

7;re > using them without one. > > On Thursday, April 9, 2015 at 7:36:43 PM UTC+2, Adam Klein wrote: >> >> Interesting. I agree it's "nice to have" in a debugging sort of way, both >> for embedders and v8 itself (no weird crashes due to people forgett

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

nstead of hoping that the right one is > entered is nice to have, it was a handy way to change the return type. > > On Thu, Apr 9, 2015 at 6:25 PM Adam Klein wrote: > >> On Fri, Feb 27, 2015 at 2:43 AM, Michael Hablich >> wrote: >> >>> Hey v8-users, >>

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

On Fri, Feb 27, 2015 at 2:43 AM, Michael Hablich wrote: > Hey v8-users, > > we're making big changes to the api (again). We've found that our api makes > it extremely difficult to write exception safe code. > > *Reference issue* > https://code.google.com/p/v8/issues/detail?id=3929 > > *Further d

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

Makes sense, thanks. On Mon, Dec 8, 2014 at 1:12 PM, 'Andreas Rossberg' via v8-users < v8-users@googlegroups.com> wrote: > On 8 December 2014 at 20:53, Adam Klein wrote: > > Subject says it all. I was surprised not to find a DCHECK in > > Heap::AllocateHeapNumber

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

Subject says it all. I was surprised not to find a DCHECK in Heap::AllocateHeapNumber asserting this is the case, and wondered why. - Adam -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to t

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

8-users@googlegroups.com> wrote: > >> Map & Set are both part of ES6 [1], [2]. >> >> They are shipping in Firefox since version 13 [3] and Internet Explorer >> 11 [4]. They are also turned on by default for nightly WebKit/JSC. >> >> Adam Klein recently

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

t; > They are shipping in Firefox since version 13 [3] and Internet Explorer 11 > [4]. They are also turned on by default for nightly WebKit/JSC. > > Adam Klein recently re-implemented the backing hash table used by both Map > and Set to use an ordered hash table, which is a require

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

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

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

etc). I'm implementing the profiler > but it will take a bit more time to land it. > > > > On Tue, Jun 11, 2013 at 6:15 PM, Jochen Eisinger > wrote: >> >> +kentaro for some profiling insights >> >> >> On Tue, Jun 11, 2013 at 7:24 AM, Adam Klein

[v8-users] Profiling v8 inside chromium/content_shell

I'm trying to profile the v8 execution of a web app using Chromium's content_shell with some success. But I'm also getting some odd results. I'm using a commandline like: content_shell --no-sandbox --js-flags='--prof --noprof-lazy --log-timer-events' http://localhost:8000/mypage And then processi