Right, given that stack is nonstandard, it's up to the implementation how
it works. There's a "should"-level requirement that it work the same way
between Error and DOMException, in a vague sense. So either implementation
strategy would work.
That said I think putting in on the prototype makes a
On 2015/08/17 at 16:47:26, mstarzinger wrote:
https://codereview.chromium.org/1289603002/diff/170001/src/snapshot/natives.h
File src/snapshot/natives.h (right):
https://codereview.chromium.org/1289603002/diff/170001/src/snapshot/natives.h#newcode9
src/snapshot/natives.h:9: #include
Thanks all for the help. The external snapshot change this morning made
fixing
the build error hairier than I expected, and
https://codereview.chromium.org/1298003004 in chromium needs to land first
to
make the gn build pass, but we should be good to go after that happens.
On 2015/08/14 at 19:28:17, commit-bot wrote:
Try jobs failed on following builders:
v8_linux64_avx2_rel on tryserver.v8 (JOB_FAILED,
http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_avx2_rel/builds/3287)
v8_linux_rel on tryserver.v8 (JOB_FAILED,
On 2015/08/13 at 12:35:31, yangguo wrote:
LGTM, but it would be very nice if we had a test case for experimental
extras
as well.
Test added. Looks like it won't let me run tryjobs until the previous patch
lands though.
https://codereview.chromium.org/1284413002/
--
--
v8-dev mailing list
On 2015/08/13 at 12:28:24, yangguo wrote:
LGTM, just a bunch of suggestions.
All suggestions implemented, including removing the loop(s) in api.cc (which
indeed seem to be useless). Would appreciate a second review given the
changes.
https://codereview.chromium.org/1289603002/
--
--
Reviewers: adamk, rossberg,
Description:
Ship --harmony_array_includes
Intent to ship:
https://groups.google.com/d/msg/v8-users/-a8_8cb6FRI/trjyB5bACQAJ
BUG=v8:3575
R=ad...@chromium.org, rossb...@chromium.org
LOG=Y
Please review this at https://codereview.chromium.org/1295543003/
Base URL:
Reviewers: Yang,
Description:
Put V8 extras into the snapshot
Previously, all extras were experimental and left out of the snapshot.
This
patch moves them to the snapshot, so now all extras are non-experimental. A
future patch will re-introduce experimental extras as part of the linked
A couple areas I wasn't as sure about:
https://codereview.chromium.org/1289603002/diff/40001/src/bootstrapper.cc
File src/bootstrapper.cc (right):
https://codereview.chromium.org/1289603002/diff/40001/src/bootstrapper.cc#newcode2611
src/bootstrapper.cc:2611: if (context_type == THIN_CONTEXT) {
On 2015/08/11 at 21:22:13, adamk wrote:
lgtm if this passes tests, I thought we might run more tests with
--harmony on
but that seems to be only test262 (are there no test262 tests for
A.p.includes?)
Not yet; I'll poke Brian about what his policies are for test262 and stages
and
such.
On 2015/08/11 at 20:51:13, caitpotter88 wrote:
On 2015/08/11 20:45:19, adamk wrote:
Looks like webkit/fast/js/Object-getOwnPropertyNames is failing (you can
reproduce locally by explicitly running the webkit tests:
tools/run-tests.py webkit
Reviewers: adamk, Dan Ehrenberg,
Description:
Add includes method to typed arrays
R=little...@chromium.org, ad...@chromium.org
BUG=v8:3575
LOG=Y
Please review this at https://codereview.chromium.org/1283703004/
Base URL: https://chromium.googlesource.com/v8/v8.git@master
Affected files
Reviewers: adamk, rossberg,
Message:
Intent to ship: https://groups.google.com/forum/#!topic/v8-users/-a8_8cb6FRI
Description:
Ship --harmony-array-includes
BUG=v8:3575
R=ad...@chromium.org, rossb...@chromium.org
LOG=Y
Please review this at https://codereview.chromium.org/1283963002/
Base
On 2015/08/11 at 18:51:40, adamk wrote:
Didn't realize this wasn't staged yet. Can you make this a staging CL
instead
to give us at least a little coverage at that level before moving to
shipped?
Done.
https://codereview.chromium.org/1283963002/
--
--
v8-dev mailing list
Reviewers: jochen, Yang,
Message:
Technically a breaking change... in an API nobody is using, hopefully?
Description:
Rename extras exports to extras binding
R=yang...@chromium.org, joc...@chromium.org
BUG=507133
LOG=Y
Please review this at https://codereview.chromium.org/1275683002/
Base
The reason we switched to argparse is because optparse doesn't allow
nargs=*
options (see
https://github.com/v8/v8-git-mirror/commit/8a89a4a5ceeb58303cd9bc2d3e8d362742d59c96).
However, as of
https://github.com/v8/v8-git-mirror/commit/c93aff4ac63ad9ffb6318e750335208de32b7902
we no longer need
On 2015/06/11 at 11:42:04, yangguo wrote:
We may want to consider renaming exports. I do not know what a good name
would
be though.
I will update the design doc with this new pattern.
https://codereview.chromium.org/1182443002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
On 2015/06/11 at 17:59:58, domenic wrote:
On 2015/06/11 at 11:42:04, yangguo wrote:
We may want to consider renaming exports. I do not know what a good name
would be though.
I will update the design doc with this new pattern.
Design doc updated.
https://docs.google.com/document/d/1AT5
lgtm
https://codereview.chromium.org/1169853007/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups v8-dev group.
To unsubscribe from this group and stop receiving emails from
On 2015/06/09 at 16:25:46, domenic wrote:
lgtm
... except the gn build is failing because of newline in string constant.
So,
not lgtm I guess. Sorry for spam.
https://codereview.chromium.org/1169853007/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8
https://codereview.chromium.org/1169853007/diff/1/BUILD.gn
File BUILD.gn (right):
https://codereview.chromium.org/1169853007/diff/1/BUILD.gn#newcode318
BUILD.gn:318: src/messages.h,
On 2015/06/09 at 16:16:22, arv wrote:
I don't think js2c_extras depends on this but I'm not really sure?
Yeah
lgtm
LGTM
https://codereview.chromium.org/1140333003/diff/60001/include/v8.h
File include/v8.h (right):
https://codereview.chromium.org/1140333003/diff/60001/include/v8.h#newcode6377
include/v8.h:6377: * If there are no extra native scripts, return an
emtpy handle.
Is this line still
https://codereview.chromium.org/1140333003/diff/40001/src/bootstrapper.cc
File src/bootstrapper.cc (right):
https://codereview.chromium.org/1140333003/diff/40001/src/bootstrapper.cc#newcode1472
src/bootstrapper.cc:1472: return CompileNative(isolate, name,
source_code, arraysize(args), args);
I
https://codereview.chromium.org/1140333003/diff/40001/include/v8.h
File include/v8.h (right):
https://codereview.chromium.org/1140333003/diff/40001/include/v8.h#newcode6379
include/v8.h:6379: MaybeLocalObject GetExtrasExportsObject();
FYI I wasn't sure whether to use MaybeLocal or Local.
On 2015/05/18 at 18:30:56, yangguo wrote:
The latter is not implemented yet, and I'm not entirely sure whether extra
exports and api exports should be the same object. It would be simpler if
they
are, but the api exports can die after the extra scripts have been executed,
where as the extra
Reviewers: jochen, Yang,
Description:
Add the concept of a V8 extras exports object
Exposed to the extras as %GetExtrasExportsObject(), on which they can
put things that should be accessible from C++. Exposed to C++ through
the V8 API as v8::Context::GetExtrasExportsObject().
Adding a test (in
Reviewers: jochen, Yang,
Description:
Re-land: Make V8 extras a separate type of native
Instead of making them an extra option that gets passed in and compiled
at the end of the natives file for a given run of js2c, we now make them a
separate run of js2c with a separate natives file output.
Updated to put the exports object on the builtins object instead of using a
%GetExtrasExportsObject() function.
Can't quite figure out how to exclude the extras-test.js from release
builds.
Apparently gyp does not allow changing variable values between release and
debug!?
Reviewers: jochen, Yang,
Message:
Created Revert of Make V8 extras a separate type of native
Description:
Revert of Make V8 extras a separate type of native (patchset #4 id:60001 of
https://codereview.chromium.org/1129743003/)
Reason for revert:
A revert of this CL (patchset #4 id:60001) has been created in
https://codereview.chromium.org/1131903002/ by dome...@chromium.org.
The reason for reverting is:
https://build.chromium.org/p/client.v8/builders/V8-Blink%20Linux%2064%20%28dbg%29/builds/2745.
Reviewers: jochen,
Description:
Fix the build with snapshot=external
R=joc...@chromium.org
BUG=
Please review this at https://codereview.chromium.org/1137473002/
Base URL: https://chromium.googlesource.com/v8/v8.git@master
Affected files (+2, -2 lines):
M src/startup-data-util.cc
Index:
Reviewers: jochen, Yang,
Message:
On 2015/05/06 at 13:09:42, jochen wrote:
can you also update the BUILD.gn file?
BUILD.gn updated; build problems fixed (hopefully) by introducing a dummy
file.
Description:
Make V8 extras a separate type of native
Instead of making them an extra option
On 2015/05/06 at 13:59:54, yangguo wrote:
The non build system part look good. I'll give the other parts another
look.
https://codereview.chromium.org/1129743003/diff/20001/tools/js2c.py
File tools/js2c.py (right):
On 2015/05/01 at 14:09:30, arv wrote:
Europe is on vacation today.
I'm looking at the spec for this and I feel like there are few parts
missing
here
- The spec covers the case where the type changes, as in:
UInt32Array.prototype.slice.call(int32ArrayInstance, start, end)
- I don't
On 2015/04/29 at 15:05:02, arv wrote:
Can this be tested?
Not easily ... right now none of the built-ins use `class`. The only
strategy
that comes to mind in that case is to run a separate v8 build with extra
built-ins (possible these days through the v8_extra_library_files gyp
variable)
Fixed to use dummy `function Test262Error() {}`s in the relevant tests;
thanks
arv!
https://codereview.chromium.org/771863002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups
Forgot to rebase!
https://codereview.chromium.org/771863002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups v8-dev group.
To unsubscribe from this group and stop receiving
https://codereview.chromium.org/600723005/diff/1/src/promise.js
File src/promise.js (right):
https://codereview.chromium.org/600723005/diff/1/src/promise.js#newcode212
src/promise.js:212: SET_PRIVATE(promise, promiseHasHandler, true);
This doesn't seem correct. The promise doesn't have any
:
https://codereview.chromium.org/600723005/diff/1/src/promise.js
File src/promise.js (right):
https://codereview.chromium.org/600723005/diff/1/src/promise.js#newcode212
src/promise.js:212: SET_PRIVATE(promise, promiseHasHandler, true);
On 2014/09/30 10:30:42, domenic wrote:
This doesn't seem
From: yang...@google.com [mailto:yang...@google.com] On Behalf Of Yang Guo
var p = new Promise(function(resolve) { resolve() });
p.then(function() { return Promise.reject(foo); });
I'll change the CL to call the callback twice then.
Right, this is a good example. In this case I'd expect
To my mind the next steps are as follows:
- Continue discussion of flags and such on the intent to implement thread
(https://groups.google.com/forum/#!topic/v8-dev/Th-67YERn1I)
- Add a way to commit test262 tests to V8 that are not merged into the
official
test262 test suite yet. I envision
https://codereview.chromium.org/579973002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups v8-dev group.
To unsubscribe from this group and stop receiving emails from it, send
As this is a new unapproved feature, this needs intent-to-implement mail.
Will send
I guess this is the first time when somebody add test262 tests first and
patch
later, but I think we still want some tests in our tree (under
test/mjsunit/harmony)
I would really like us to break out of the
https://codereview.chromium.org/579973002/diff/1/src/harmony-array.js
File src/harmony-array.js (right):
https://codereview.chromium.org/579973002/diff/1/src/harmony-array.js#newcode129
src/harmony-array.js:129: function ArrayContains(searchElement /*,
fromIndex */) { // length == 1
On
be in ES7 until it has advanced to stage 4, which
requires two unflagged shipping implementations, so an --es7 flag might be
a bit of a misnomer.)
On Thursday, September 18, 2014 8:37:13 AM UTC-7, Domenic Denicola wrote:
Array.prototype.contains is specced at
https://github.com/domenic
On 2014/09/18 15:34:54, Dmitry Lomov (chromium) wrote:
That is worthwhile (and I think that would be great in ideal world) but it
suffers from a couple of issues:
1. Currently, we do not run test262 tests on dev machines during
development,
relying on mjsunit for smoke testing (we run
100644
--- a/src/harmony-array.js
+++ b/src/harmony-array.js
@@ -123,6 +123,45 @@ function ArrayFill(value /* [, start [, end ] ] */) {
// length == 1
return array;
}
+// Proposed for ES7
+// https://github.com/domenic/Array.prototype.contains/
+// 3fb531d074eddf5d23e0a46b57ea48932e1fac69
On 2014/09/18 01:16:23, domenic wrote:
On tests: test262 tests still need to be merged
(https://github.com/tc39/test262/pull/95) but once they are I can update
the CL
to include the new test262 SHA. The tests are pretty comprehensive and all
passing locally. But I was hoping to get the code
This is my first CL; feedback much appreciated. I don't even know if I'm
supposed to be pressing this Publish+Mail Comments button, but some slide
deck
told me to.
https://codereview.chromium.org/579973002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
49 matches
Mail list logo
