[v8-users] Intent to implement: ES6 `String.fromCodePoint` and `String.prototype.codePointAt`

# TC39 acceptance Norbert Lindenberg fleshed out a proposal that defined these methods back in May 2012: . Since then, the document received multiple rounds of feedback through the es-discuss list and during TC39

[v8-users] Re: Intent to implement: ES6 `String.fromCodePoint` and `String.prototype.codePointAt`

On 24 Sep 2013, at 12:17, Mathias Bynens wrote: > There’s also a discussion on whether JavaScript should allow lone surrogates > in strings or not: > http://esdiscuss.org/topic/code-points-vs-unicode-scalar-values But > historically, this is what JavaScript has always done, and c

Re: [v8-users] Intent to implement: ES6 `String.fromCodePoint` and `String.prototype.codePointAt`

Does https://code.google.com/p/v8/issues/detail?id=2840#c3 mean that the patch is now accepted? -- -- 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 unsu

Re: [v8-users] Intent to implement: ES6 `String.fromCodePoint` and `String.prototype.codePointAt`

Support for these methods just landed in Firefox/SpiderMonkey: http://hg.mozilla.org/integration/mozilla-inbound/rev/2411714cd058 Note: the new methods aren’t hidden behind an optional flag. It is time to reconsider this for v8, and take another look at the patch? https://codereview.appspot.com

Re: [v8-users] Intent to implement: ES6 `String.fromCodePoint` and `String.prototype.codePointAt`

For the record, Firefox 29 just shipped with support `String.fromCodePoint` and `String.prototype.codePointAt` by default (not behind a flag). It is time to reconsider this for V8, and take another look at the patch? https://codereview.appspot.com/13816046 -- -- v8-users mailing list v8-users

Re: [v8-users] Interested in helping develop

Hey Isiah, I recommend you check out the code. Parts of V8 are written in JavaScript, indeed — take a look at src/*.js for some examples. Here’s how you can submit a patch for the optimization you proposed: https://github.com/v8/v8/wiki/Proposing-a-Patch#how-to-contribute-to-the-v8-project Regar

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

On 13 Jun 2014, at 07:26, Isiah Meadows wrote: >// fat arrow function not implemented in any JS engine AFAIK >var x = [1, 2, 3, 4, 5]; >x = x.map((i) => i*i); Firefox/Spidermonkey already supports the fat arrow syntax. > I don't know, though, if array comprehensions allow for void r

[v8-users] Re: [blink-dev] Intent to ship: ES6 numeric literal syntax

On Thu, Oct 2, 2014 at 1:10 PM, John Mellor wrote: > Will V8 simultaneously drop support for the legacy 0377 syntax for octal > numbers? Or does this mean both will be supported? The octal literal syntax is part of Annex B, which browsers are required to implement for Web compatibility. -- --

Re: [v8-users] Re: [blink-dev] Intent to ship: ES6 numeric literal syntax

On Fri, Oct 3, 2014 at 5:09 AM, Trevor Norris wrote: > Though for people to transition to using ES6 numeric literals they > realistically need to be removed from behind the flag? > > Support LegacyOctalIntegerLiteral forever if you'd like, but that doesn't > mean numeric literals can't be taken ou

Re: [v8-users] WILL BE DEPRECATED SOON V8 github repo

On Thu, Oct 23, 2014 at 1:23 PM, Ben Noordhuis wrote: > On Thu, Oct 23, 2014 at 12:56 PM, C. Ken wrote: >> what is actually mean of "WILL BE DEPRECATED SOON" say on v8 github repo >> https://github.com/v8/v8 > > Scroll down, it's on the page. :-) V8 is moving to git, that's why > the svn->git m

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

Relevant CL: https://codereview.chromium.org/761913002/ -- -- 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 receivin

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

On Thu, Nov 27, 2014 at 12:52 PM, Philip Jägenstedt wrote: > 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 sen

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

On Thu, Nov 27, 2014 at 1:06 PM, Philip Jägenstedt wrote: > On Thu, Nov 27, 2014 at 12:54 PM, Mathias Bynens wrote: >> On Thu, Nov 27, 2014 at 12:52 PM, Philip Jägenstedt >> wrote: >>> It sure sounds like 'contains' would be less likely to cause trouble, >

Re: [v8-users] `make quickcheck` runs 32-bit tests when I'm on a 64-bit OS

On Sat, Dec 13, 2014 at 5:22 AM, Isiah Meadows wrote: > I'm not set up for cross-compilation, so I get all kinds of errors in > building for IA32. But, when I run `make quickcheck`, it starts > building/testing for IA32 instead of my native architecture x86_64. How can > I fix this? Note that `ma

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

Contact emails yang...@chromium.org, little...@chromium.org, erikco...@chromium.org, math...@chromium.org Spec https://github.com/tc39/proposal-regexp-lookbehind (stage 3 proposal) Summary Lookarounds are zero-width assertions that match a string without consuming anything. ECMAScript has look

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

Contact emails yang...@chromium.org, math...@chromium.org Spec https://github.com/tc39/proposal-regexp-unicode-property-escapes (stage 3 proposal) Summary The Unicode Standard assigns various properties and property values to every symbol. For example, to get the set of symbols that are used e

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

Contact emails math...@chromium.org Spec https://github.com/tc39/proposal-string-left-right-trim Summary Until now, String.prototype.{trimLeft,trimRight} were non-standard language extensions, required for Web compatibility. The Stage 3 proposal at https://github.com/tc39/proposal-string-left-right

[v8-users] Intent to ship: JSON ⊂ ECMAScript

*Contact emailsmath...@chromium.org Spechttps://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 subse

[v8-users] Intent to ship: Array.prototype.{flat,flatMap}

*Contact emailsmath...@chromium.org , bmeu...@chromium.org Spechttps://tc39.github.io/proposal-flatMap/ SummaryA Stage 3 proposal introduces two new array methods.Array.prototype.flat flattens arrays recursively up to the specified depth, which defaults t

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

For future reference: this landed <https://chromium.googlesource.com/v8/v8.git/+/473a6f5b03651fde33fd7b3228a7dc4e38e24914> in V8 v6.2.103 and should thus be available in Chrome 62. On Mon, Jul 31, 2017 at 2:42 PM, Adam Klein wrote: > LGTM! > > On Sun, Jul 30, 2017 at 7:18 AM,

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

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

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

Note that since this is a V8/JS feature, this post is just an FYI to blink-dev — no signoff from Blink API owners is required. On Thu, Nov 9, 2017 at 10:29 PM, Mathias Bynens wrote: > Contact emails > > yang...@chromium.org, math...@chromium.org > > Spec > > https://git

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

For future reference: this landed in V8 v6.4.49 and should thus be available in Chrome 64. On Wed, Oct 18, 2017 at 7:09 PM, 'Sathya Gunasekaran' via blink-dev < blink-...@chromium.org> wrote: > LGTM2 > > On W

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

; 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

Re: [v8-users] How to build a fixed version of V8 and its dependencies.

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

Re: [v8-users] Bug in v8/src/parsing/scanner?

On Fri, Dec 15, 2017 at 4:44 PM, J Decker wrote: > The code below comes from ScanString() > I noticed that if the scanner encounters a '\' before a c0 > kMaxAscii > HandleLeadSurrogate() (0xd800+0xdc00 surrogate handling) is no longer done. > > I tried to make a test file that had such things, bu

Re: [v8-users] Intent to Ship: Array.prototype.values

Third time’s the charm! 🤞 On Wed, Jan 31, 2018 at 4:07 PM, Sathya Gunasekaran wrote: > Contact Emails: > gsat...@chromium.org > > Spec: > https://tc39.github.io/ecma262/#sec-array.prototype.values > > Summary: > The values() method returns a new Array Iterator object that contains the > values f

Re: [v8-users] --print-code does not work

Tracking issue for the removal of --print-code: https://bugs.chromium.org/p/v8/issues/detail?id=7437 On Fri, Feb 9, 2018 at 11:22 PM, Jakob Kummerow wrote: > If --print-opt-code prints nothing, then probably your function isn't > getting optimized. Try calling it more often. > > --print-code is

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

2: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: >>> >>&g

[v8-users] Re: [blink-dev] Intent to ship: JSON ⊂ ECMAScript

PhistucK* > > On Fri, Feb 16, 2018 at 2:15 PM, Mathias Bynens > wrote: > >> >> >> >> >> >> >> >> >> >> *Contact emailsmath...@chromium.org >> Spechttps://github.com/tc39/proposal-json-superset >> <https://g

Re: [v8-users] Re: [blink-dev] Intent to ship: JSON ⊂ ECMAScript

ot;). >> > 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 >> wrote: &

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

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

Re: [v8-users] Re: [blink-dev] Intent to ship: Array.prototype.{flat,flatMap}

For future reference: this landed <https://chromium.googlesource.com/v8/v8/+/dd78d603591663dd9abd64d1ed64caab7edfc966%5E%21/> in V8 v6.9.* and should thus be available in Chrome 69. On Tue, May 29, 2018 at 4:22 PM Sathya Gunasekaran wrote: > LGTM > On Wed, May 23, 2018 at 11:2

Re: [v8-users] Is it possible to access the AST of the v8 engine, for a given JavaScript code?

Grab a debug build (not a release build!) and run d8 --print-ast foo.js. On Thu, Jul 5, 2018 at 2:39 PM czczcheng wrote: > I want to analysis the javascript code and modify it in some cases. > > -- > -- > v8-users mailing list > v8-users@googlegroups.com > http://groups.google.com/group/v8-users

Re: [v8-users] base64 encode/decode in v8

`btoa` (and `atob`) are indeed browser-specific APIs; they’re not part of ECMAScript and not implemented in V8. You could use a JavaScript implementation. https://github.com/mathiasbynens/base64 matches the browser APIs `btoa` and `atob` as closely as possible. On Mon, Aug 20, 2018 at 8:26 PM Gau

[v8-users] Intent to Ship: globalThis

Contact emails math...@chromium.org Spec https://tc39.github.io/proposal-global/ Summary A Stage 3 proposal introduces globalThis, enabling a universal mechanism to access the global object even in strict functions or modules, regardless of the platform. Motivation It is difficult to write p

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

LGTM3 On Tue, Sep 25, 2018 at 10:46 AM Adam Klein wrote: > 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 S

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

LGTM On Fri, Sep 28, 2018 at 9:26 AM Maya Lekova wrote: > > > > > > > > > > > *Contact emailsmslek...@chromium.org > Explainerhttps://docs.google.com/document/d/1kL08cz4lR6gO5b2FATNK3QAfS8t-6K6kdk88U-n8tug/edit?usp=sharing >

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

Contact emails math...@chromium.org Spec https://github.com/tc39/proposal-well-formed-stringify Summary A Stage 3 proposal changes JSON.stringify to prevent it from returning ill-formed Unicode strings. Motivation RFC 8259 section 8.1 require

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

LGTM On Wed, Oct 17, 2018 at 9:47 AM Sathya Gunasekaran wrote: > Contact Emails: > gsat...@chromium.org > > Spec: > https://github.com/tc39/proposal-class-fields > https://tc39.github.io/proposal-static-class-features/ > > The linked proposal includes private fields, but this intent to ship > is

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

With the upcoming (but separate) private fields proposal, the example evolves from: class IncreasingCounter { _count = 0; get value() { return this._count; } increment() { this._count++; } } ...into: class IncreasingCounter { #count = 0; get value() { return this.#cou

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

LGTM2 On Thu, Nov 8, 2018 at 2:44 AM Sathya Gunasekaran wrote: > LGTM > > On Thu, Nov 8, 2018 at 12:20 AM Frank Tang wrote: > >> Spec >> >> https://tc39.github.io/proposal-intl-list-format >> >> Summary >> >> A Stage 3 proposal that introduces a new formatter under Intl. >> >> Intl.ListFormat

Re: [v8-users] runing v8

https://v8.dev/docs/embed is a good place to get started. On Thu, Dec 6, 2018 at 11:01 PM Idris AIT MOULAY wrote: > hi every body there some one here that can help to understand v8 code > source, and try to run it, there is any doc or reference that may help me > to understand v8 code source. >

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

LGTM∞ On Fri, Dec 14, 2018 at 7:37 AM Jakob Gruber wrote: > LGTM3 > > On Fri, Dec 14, 2018 at 1:57 AM Adam Klein wrote: > >> 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 email

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

LGTM On Wed, Feb 20, 2019 at 8:58 PM Sathya Gunasekaran wrote: > Contact Emails > > gsat...@chromium.org > > > Spec > > https://github.com/tc39/proposal-class-fields > > > Summary (taken from our WebFu article > ) > > > > This priva

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

efer to the `x` field above, which you can accomplish with `#y = !this.x`. > >> On Wed, Feb 20, 2019 at 5:14 PM Adam Klein wrote: >> >>> LGTM!! >>> >>> On Wed, Feb 20, 2019 at 12:20 PM 'Mathias Bynens' via blink-dev < >>> bl

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

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

Re: [v8-users] How to use Chrome Dev Tools to debug a script in d8

Does the documentation help? https://v8.dev/docs/inspector On Mon, Apr 8, 2019 at 1:23 PM DaManuell wrote: > I successfully built d8.exe from sources > > I made a simple JavaScrit file called test.js: > > function test( obj ) { > return obj.prop + obj.prop; > } > > I ran d8.exe with the comman

Re: [v8-users] Re: Does 'eval' has the same performance as an explicit Script->Compile->Run pipeline?

The document you linked to is outdated. It was based on Crankshaft which hasn't been used since V8 v5.9. See the first two lines: *All this is wrong in TurboFan. (Node 8+)* *Please do not take anything written here as performance advice, this is here for historical reasons.* On Sun, Apr 14, 2019

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

LGTM On Wed, Apr 24, 2019 at 6:01 AM 'Benedikt Meurer' via v8-dev < v8-...@googlegroups.com> wrote: > LGTM! > > On Wed, Apr 24, 2019, 02:05 Adam Klein wrote: > >> LGTM! >> >> On Tue, Apr 23, 2019 at 4:19 PM Sathya Gunasekaran >> wrote: >> >>> Contact Emails: >>> gsat...@chromium.org >>> >>> Spe

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

Non-API owner LGTM. Optimize all the things! On Thu, Apr 25, 2019 at 8:47 PM Adam Klein wrote: > 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

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

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/

Re: [v8-users] Intent to Implement: "numberingSystem" option for Intl.NumberFormat / "calendar" and "numberingSystem" option for Intl.DateTimeFormat

LGTM *From: *Frank Tang *Date: *Tue, May 14, 2019 at 5:33 PM *To: *blink-dev, v8-users, , Adam Klein, Sathya Gunasekaran, Jakob Kummerow, Nebojša Ćirić Contact emails ft...@chromium.org,js...@chromium.org Explainer > https://github.com/tc39/ecma402/pull/175 Design docs/spec Specification: > http

[v8-users] Re: [blink-dev] Intent to Remove: 'getThis' and 'getFunction' from the CallSite API

Non-Blink owner LGTM. As Simon points out, Error.prepareStackTrace is non-standard, and so I'm in favor of removing as much from it as we can. On Tue, Jul 2, 2019 at 6:15 PM 'Simon Zünd' via blink-dev < blink-...@chromium.org> wrote: > Contact emails szu...@chromium.org Summary A callback install

Re: [v8-users] V8 Regex Optimizations

We recently posted an article detailing some recent improvements: https://v8.dev/blog/regexp-tier-up On Wed, Oct 23, 2019 at 5:12 PM Joel Scarfone wrote: > Hi! > > I'm looking for details on how v8's regular expression optimizations work > under the covers, and if there might be something to imp