lgtm
On Thu, Jun 18, 2015 at 1:23 AM, Daniel Ehrenberg little...@chromium.org
wrote:
We intend to ship new functions and methods, added in ES2015, for
Arrays and TypedArrays unflagged. These functions have been gradually
in progress behind the --harmony_arrays flag, with the first functions
LGTM
On Fri, Feb 27, 2015 at 6:20 PM, 'Erik Arvidsson' via blink-dev
blink-...@chromium.org wrote:
[blink-dev: FYI]
Computed property names allows an expression to compute the name of a
property, both in classes and object literals.
let object = {
[40 + 2]: 'meaning?'
};
The main
SGTMx2
On Fri, Feb 27, 2015 at 5:12 PM, 'Andreas Rossberg' via v8-users
v8-users@googlegroups.com wrote:
Sounds good to me.
On 27 February 2015 at 15:56, Caitlin Potter caitpotte...@gmail.com
wrote:
*Contact emails*
caitpotte...@gmail.com,
*Spec*
Reflect.apply()
[blink-dev: FYI]
We have updated our staged implementation of ES6 classes to match the
recent changes in ES6 spec draft.
We are happy to report that these changes enabled us to implement the spec
in its entirety (almost; see limitations below), most critically including
subclassing of built-ins
A few weeks ago, yet in 2014, we have announced shipping ES6 classes in V8
[1].
Our implementation was mostly following current ES6 draft specification.
However, as discussed on the intent-to-ship thread [1], we have found
several aspects of the specification problematic, namely subclassing of
On Tue, Dec 16, 2014 at 10:56 AM, Dmitry Lomov dslo...@chromium.org wrote:
It is my understanding (I might be incorrect) that IE implements Option 2
in preview release.
I stand corrected - Brian Terlson (cc'd) informed me that IE does not
currently implement subclassing exotic objects (ES6
On Mon, Dec 15, 2014 at 10:22 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Mon, Dec 15, 2014 at 3:15 PM, Dmitry Lomov dslo...@chromium.org
wrote:
- At this time we do not support subclassing built-ins and DOM objects
If you don't ship this part, isn't there quite a big risk that we
On Tue, Dec 16, 2014 at 11:07 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/16/14, 1:56 AM, Dmitry Lomov wrote:
the problem with this option is that between entry to the constructor
and call to super(...) `this` is necessarily an exotic ImageData in some
sort of semi-initialized state
On Tue, Dec 16, 2014 at 6:08 PM, al...@wirfs-brock.com wrote:
On Tuesday, December 16, 2014 2:50:40 AM UTC-8, Dmitry Lomov wrote:
...
Is there a concrete plan for proposing something else, or is the
concrete plan to simply never allow subclassing of builtins? Because
that's the one
On Tue, Dec 16, 2014 at 7:04 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 16, 2014, at 9:19 AM, Domenic Denicola wrote:
From: blink-...@chromium.org [mailto:blink-...@chromium.org] On Behalf
Of al...@wirfs-brock.com
Let me turn this around on you. What in the current draft
On Tue, Dec 16, 2014 at 9:02 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Dec 16, 2014, at 11:25 AM, Dmitry Lomov wrote:
On Tue, Dec 16, 2014 at 7:04 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
The V8 concern seems to be about hypothetical that aren't actually
On Tue, Dec 16, 2014 at 9:59 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Dec 16, 2014 at 9:43 PM, Dmitry Lomov dslo...@chromium.org
wrote:
True for plain ES6 classes. Less true for bulitins implementation-wise
(fair
amount of work and possible bug farm, for quite diminishing
[blink-dev: FYI]
Classes syntax are part of ES6. The spec in Editor's draft is stable.
IE has classes in preview release [1]. No other browser currently ships
classes (Mozilla bug [2]).
V8 implementation of classes is up-to-date with the latest ES6 spec modulo
the limitations noted below.
On Mon, Dec 15, 2014 at 7:35 PM, Elliott Sprehn espr...@chromium.org
wrote:
On Mon, Dec 15, 2014 at 6:15 AM, Dmitry Lomov dslo...@chromium.org
wrote:
[blink-dev: FYI]
Classes syntax are part of ES6. The spec in Editor's draft is stable.
IE has classes in preview release [1]. No other
[blink-dev: FYI]
Lexical declarations ('let' and 'const') are part of ES6. The spec for them
in Editor's draft is stable.
The are available in IE11 [1]. Firefox plans to ship them in 35 (Jan 2015)
[2].
Lexical declarations has been available in V8 under --harmony-scoping flag
for quite some
On Sun, Dec 7, 2014 at 5:39 PM, ad...@chromium.org wrote:
Thanks Dmitry. I like the enhanced level of control the feature-shipping
process now exposes. One piece of feedback: in about:flags the labelling
for #disable-javascript-harmony-shipping is *Disable latest stable
JavaScript features.*
We are refining the procedure for shipping new Javascript features in V8,
and, subsequently, in Chrome.
1. After the Javascript feature is shipped (following our process [1]), we
will keep maintaining its enabled by default '--harmony-feature' flag, so
that the feature can be turned off at
[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
to evangelize enabling this flag among the power users,
so that we hear about any breakage early.
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
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
On Thu, Nov 27, 2014 at 11:44 AM, Jochen Eisinger joc...@chromium.org
wrote:
On Thu Nov 27 2014 at 11:39:17 AM 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
:39 AM, 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
On Thu, Nov 27, 2014 at 12:54 PM, Mathias Bynens mathi...@opera.com wrote:
On Thu, Nov 27, 2014 at 12:52 PM, Philip Jägenstedt phil...@opera.com
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
, 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
I guess we parse something resembling ES6 modules sums it up quite
accurately.
(Some people just can't not take no for an answer, it seems ;)))
Really, it is very much a work in (postponed) progress. We will pick it up
at some point, but at the immediate moment we are focusing on classes and
few
LGTM to implement non-tagged template literals, tagged template literals
pend spec issue resolution.
On Tue, Nov 4, 2014 at 1:33 PM, 'Andreas Rossberg' via v8-users
v8-users@googlegroups.com wrote:
On 4 November 2014 12:53, Dmitry Lomov dslo...@chromium.org wrote:
On Tue, Nov 4, 2014 at 12
LGTM
On Sun, Oct 19, 2014 at 3:24 AM, Caitlin Potter caitpotte...@gmail.com
wrote:
The well-known Symbol.toStringTag and its related changes in
Object.prototype.toString --- is a stable API introduced in ECMA-262 6th
edition draft from September 27, 2012, and has apparently not changed since
It has been more than a year since we have published V8 launch process.
Today we are making some adjustments to it based on our experience
throughout a year and some changes in TC39 (ECMAScript standards committee)
procedure.
See the v2 of the document at
On Fri, Sep 12, 2014 at 11:38 PM, Flying Jester foolkingcr...@gmail.com
wrote:
Since V8 does not know how the memory backing an ArrayBuffer has been
allocated in this case, there is now good way for V8 to free it.
This doesn't make sense.
A part of v8::ArrayBuffer::Allocator is a Free
?
On Thursday, September 18, 2014 11:00:10 AM UTC-8, Dmitry Lomov wrote:
On Fri, Sep 12, 2014 at 11:38 PM, Flying Jester foolki...@gmail.com
wrote:
Since V8 does not know how the memory backing an ArrayBuffer has been
allocated in this case, there is now good way for V8 to free
freed, that is not the library's fault.
I wish it weren't :) API design is not a blame game, and this is the point
of our disagreement, of course.
On Thursday, September 18, 2014 12:34:39 PM UTC-8, Dmitry Lomov wrote:
On Thu, Sep 18, 2014 at 9:20 PM, Flying Jester foolki...@gmail.com
It's ready when it's ready. We don't do deadlines here (usually).
On Fri, Aug 22, 2014 at 4:18 PM, iradche...@appgeo.com wrote:
Any idea on an estimated completion time for this?
On Friday, August 15, 2014 4:46:39 AM UTC-4, Dmitry Lomov wrote:
Implement ES6 classes including:
- class
Hi Trevor,
Since V8 does not know how the memory backing an ArrayBuffer has been
allocated in this case, there is now good way for V8 to free it.
Just like previously with external indexed data, the way to do it is to
use a weak persistent handle for the ArrayBuffer to get a notification when
Hard to say without more information. Debug it?
On Tue, Apr 22, 2014 at 6:25 PM, Nozik nozi...@gmail.com wrote:
Thanks Dmitry, but the problem happens even when I'm not calling Enter
before acquiring the lock.
Any other ideas?
Thanks.
On Tuesday, April 22, 2014 6:15:50 PM UTC+3, Dmitry
You should always enter isolates _after_ you acquired a lock on it, not
before.
You do not need to use Enter directly: Isolate::Scope is RIAA-style wrapper
around Isolate::Enter/Exit.
HTH,
Dmitry
On Tue, Apr 22, 2014 at 4:50 PM, Nozik nozi...@gmail.com wrote:
Hi all,
I've upgraded an old V8
Eventually, when they are ready.
On Mar 25, 2014 11:49 PM, Jonathan Ong jonathanrichard...@gmail.com
wrote:
any chance of unflagging ES6 generators as well?
On Monday, March 17, 2014 8:47:22 AM UTC-7, Andreas Rossberg wrote:
We intend to soon ship both ES6 promises and weak collections
LGTM to ship.
On Mon, Mar 17, 2014 at 4:47 PM, Andreas Rossberg rossb...@google.comwrote:
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
How exactly do you run V8? Do you run d8?
Dmitry
On Mon, Mar 10, 2014 at 10:15 AM, Albert Zeyer alb...@googlemail.comwrote:
Hi,
I get this error when I try to run some JS code ([this](
http://pastebin.com/XesBSstJ) + [this](http://pastebin.com/0VawRb16))
with V8 (tried master from two
://stackoverflow.com/questions/22294854/v8-fatal-error-
checkv8arraybufferallocator-null-failed
On Monday, March 10, 2014 10:17:23 AM UTC+1, Dmitry Lomov wrote:
How exactly do you run V8? Do you run d8?
Dmitry
On Mon, Mar 10, 2014 at 10:15 AM, Albert Zeyer alb...@googlemail.comwrote:
Hi,
I get
.
It looks like a V8 issue...
On Monday, March 10, 2014 10:25:12 AM UTC+1, Dmitry Lomov wrote:
Ah, thought so. Read docs on v8::ArrayBuffer::Allocator.
(look at Shell::Main in d8.cc for an example)
HTH,
Dmitry
On Mon, Mar 10, 2014 at 10:20 AM, Albert Zeyer alb...@googlemail.comwrote
On Fri, Jan 31, 2014 at 11:38 AM, Sara Abdelhameed
saraabdelhameed1...@gmail.com wrote:
so, if I want to make very simple example such as having two threads that
each one run different script and don't depend on each other, and I want
them to be in parallel, so I must use two isolate, for
Note that ArrayBuffer API is experimental and we might change it in the
future. The below reflects what we ship currently.
On Mon, Dec 9, 2013 at 4:56 AM, Roman Shtylman shtyl...@gmail.com wrote:
A few things are unclear to me after trying to use the ArrayBuffer api
from v8 3.23.10
The
Some quick replies inline.
On Tue, Nov 19, 2013 at 1:10 AM, Trevor Norris trev.nor...@gmail.comwrote:
On Thursday, November 14, 2013 5:28:58 AM UTC-8, Dmitry Lomov wrote:
Is it still true in the latest releases (3.20 and up)? I am curious as to
what is the bottleneck here.
I remember
On Tue, Nov 19, 2013 at 9:00 PM, Trevor Norris trev.nor...@gmail.comwrote:
On Tuesday, November 19, 2013 2:04:45 AM UTC-8, Dmitry Lomov wrote:
Here is the change: https://code.google.com/p/v8/source/detail?r=15205
Instead of weak handles, I taught our GC to free array buffer backing
store
On Fri, Nov 15, 2013 at 1:13 PM, Ben Noordhuis i...@bnoordhuis.nl wrote:
On Thu, Nov 14, 2013 at 2:28 PM, Dmitry Lomov dslo...@chromium.org
wrote:
Thanks a lot for your yelling :)
My general remark here is if you implement your own Buffer classes and
not
doing what the rest
d8 implementation of ArrayBuffers and friends has been
pretty terrible w.r.t. allocation speed, but it is already improving and
will improve further.
On Wed, Nov 13, 2013 at 12:08 AM, Trevor Norris trev.nor...@gmail.comwrote:
On Tuesday, November 12, 2013 12:08:28 AM UTC-8, Dmitry Lomov wrote
As you probably know, over the course of the last several months, V8
switched to an in-house implementations of ArrayBuffer, typed arrays and
DataView. These implementations feature faster allocation, better garbage
collection performance and a potential to become even faster in the future
with
On Tue, Nov 12, 2013 at 10:15 AM, Ben Noordhuis i...@bnoordhuis.nl wrote:
On Tue, Nov 12, 2013 at 9:08 AM, Dmitry Lomov dslo...@chromium.org
wrote:
As you probably know, over the course of the last several months, V8
switched to an in-house implementations of ArrayBuffer, typed arrays
+v8-users
Implementing under the flag LGTM.
Low-risk and good to have implementation feedback for the committee.
Dmitry
On Wed, Oct 16, 2013 at 12:01 PM, Yang Guo yang...@google.com wrote:
Hi,
I would like to implement some of the new Math.* functions proposed in the
ES6 draft in V8
If promises become a part of V8, we of course expect them to be quite
usable on server-side too (node.js is our customer after all)
On Sun, Oct 6, 2013 at 1:05 PM, Petka Antonov petka.anto...@gmail.comwrote:
The benchmark is emulating a server side workflow. I don't imagine there
is anything
Implementing behind the flag LGTM.
There is clear consensus among TC39 members, browser vendors and web
platform champions that Promises are an important addition to ECMAScript.
At a Sept TC39 meeting, promises has been put on a fast track to ES6 - the
next release of ECMAScript spec. Also,
ArrayBuffer.isView(obj) is a static function that returns boolean
indicating whether the passed argument is an ArrayBufferView. For ES6, this
means either a DataView or one of typed arrays. In spec terms, this is
equivalent to argument having a [[ViewedArrayBuffe]] internal data property.
I
Mathias,
we appreciate your effort in implementing this, and are thankful to you for
following our launch process and coming up with a good intent-to-implement
e-mail, supported by reasoned argument and conformance tests. (Yours is
our first intent-to-implement e-mail under the new process and I
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
On Jul 13, 2013 11:33 AM, Arseniy Pavlenko h0x...@gmail.com wrote:
How to correctly kill the V8 and run it again?
Generally, you cannot re-initialize v8 after v8::V8::Dispose().
Depending on what you are trying to achieve, perhaps you can use
v8::Isolate (that can be created and disposes at
On Sat, Jul 13, 2013 at 9:45 PM, Dmitry Lomov dslo...@chromium.org wrote:
On Jul 13, 2013 11:33 AM, Arseniy Pavlenko h0x...@gmail.com wrote:
How to correctly kill the V8 and run it again?
Generally, you cannot re-initialize v8 after v8::V8::Dispose().
Depending on what you are trying
I think you are missing a handle scope:
void* fp = new std::functionvoid(void)(
[=]()
{
v::Locker locker(gIsolate);
v8::Isolate::Scope scope(gIsolate);
v8::HandleScope handle_scope(gIsolate);
std::vectorchar data = Download(url);
v::Handlev::Value arg =
Well you should really create a locker *before* you create a HandleScope.
On Jun 7, 2013 6:47 PM, papi nokan...@gmail.com wrote:
Also, did you make sure that _all_ the code - including the code on main
thread - that you execute in gIsolate is protected by v8::Locker?
Hmm, i get my problem.
, papi nokan...@gmail.com wrote:
On Friday, June 7, 2013 7:51:34 PM UTC+3, Dmitry Lomov wrote:
Well you should really create a locker *before* you create a HandleScope.
On Jun 7, 2013 6:47 PM, papi noka...@gmail.com wrote:
Also, did you make sure that _all_ the code - including the code
On Tue, Apr 30, 2013 at 9:08 AM, Sarim Khan sarim2...@gmail.com wrote:
Hi,
I have library implemented in javascript. I use that library in c++ apps.
So what i do now, is to use v8, create a context, then read the js files,
and run the js codes inside the context. Then find the js function in
mksnapshot --help
On Tue, Apr 30, 2013 at 10:20 AM, Sarim Khan sarim2...@gmail.com wrote:
Hi,
Thank you very much. using global.sarim = sarim works :)
About this --extra-code flag, how to add this ? Any reference would be
great.
On Tuesday, April 30, 2013 1:49:28 PM UTC+6, Dmitry Lomov
v8::Script::Run should be protected by a locker. V8 generally cannot
execute scripts operating on the same heap in parallel.
If you want to execute scripts in parallel, take a look at v8::Isolate
class and related comments.
On Mon, Apr 29, 2013 at 2:01 PM, Then tneuho...@gmail.com wrote:
Hi,
No. Isolates are completely isolated instances of V8, including separate
heaps.
Generally, by design Javascript lacks facilities for shared-memory
multithreaded programming.
Kind regards,
Dmitry
On Mon, Apr 8, 2013 at 2:55 PM, Laszlo Szakony laszlo.szak...@certec.atwrote:
OK. I will use
v8::Primitive is immutable and not assignable. Since V8 uses a garbage
collector, your program should not generally have v8::Values (including
v8::Primitives) in variables, it should use v8::Handles for maintaining
references to V8 objects.
What is a purpose of your Convert method? What are you
Your stored value is ok, it is the signature of your Convert method that is
wrong.
It should really work on v8::Handlev8::Primitive:
bool MyClass::Convert(v8::Handlev8::Primitive oValue) {
oValue = m_Value;
}
As a rule, use v8::Handle instead of a reference or a pointer to v8::Value
Hope
Have you taken a look at WebCL? (http://www.khronos.org/webcl/) If I
understand correctly what you want to do, WebCL is precisely it.
Apparently there is a project underway to bring this to webkit and chromium
(https://code.google.com/p/webcl/).
Hope this helps,
Dmitry
On Wed, Apr 3, 2013 at
66 matches
Mail list logo
