Fair enough.
Like I said. We have a lot of work to do here and your test is a good
microbenchmark that we should beat.
On Jun 25, 2015 6:33 PM, codesite-noreply via v8-dev
v8-dev@googlegroups.com wrote:
Comment #2 on issue 4246 by kpdecker: Computed Property Names up to 25x
slower than ES5
+1
Non own private is not useful. (We could always add it back if we ever
needed it.)
On Mon, Jun 15, 2015 at 8:54 AM, verwa...@chromium.org wrote:
+1, anything else doesn't seem to make sense
https://codereview.chromium.org/1182303004/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
On Jun 15, 2015 11:14 AM, little...@chromium.org wrote:
https://codereview.chromium.org/1181903003/diff/80001/src/typedarray.js
File src/typedarray.js (right):
https://codereview.chromium.org/1181903003/diff/80001/src/typedarray.js#newcode138
src/typedarray.js:138: var newIterable =
Agreed. I think I even filed a bug about this a while ago.
On Jun 12, 2015 09:34, codesite-noreply via v8-dev
v8-dev@googlegroups.com wrote:
Updates:
Status: WorkingAsIntended
Comment #1 on issue 4181 by rossb...@chromium.org: Direct eval() call in
constructor throws
Also, computed property names?
On May 21, 2015 9:09 AM, a...@chromium.org wrote:
LGTM
https://codereview.chromium.org/1145213005/diff/1/test/mjsunit/strong/literals.js
File test/mjsunit/strong/literals.js (right):
On May 14, 2015 9:18 AM, erik.co...@gmail.com wrote:
Surely it always caused a map transition. How else can you add the hidden
property?
Yeah. I realized that too. I agree that this is much cleaner.
The change was to make an already existing test pass, but I can add
another.
I'm not too concerned about compat. Adding another object to the
prototype doesn't change the interface. It will break code that does
hasOwnProperty but I don't think it is common for these things.
On Fri, May 8, 2015 at 4:07 PM, ad...@chromium.org wrote:
lgtm % arv's comments
On 2015/05/08
You are reading the spec correctly. It might be good to get the prototype
chain right before we invest too much time in more typed array methods.
On May 6, 2015 7:29 PM, ad...@chromium.org wrote:
I have a high-level question: it looks like harmony-typedarray.js currently
creates many versions
Sorry. I think I might have given you the wrong impression. It is fine to
land incremental improvements. Just keep in mind that these functions need
to be polymorphic over all typed arrays.
On May 6, 2015 22:22, caitpotte...@gmail.com wrote:
On 2015/05/07 02:19:44, dehrenberg wrote:
FWIW v3
Oh, Reitveld O.o
On Wed, May 6, 2015 at 11:39 AM, a...@chromium.org wrote:
Andy, it looks like your CL is sticking around... I'll update this later
today.
https://codereview.chromium.org/1092503003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
OK. I'll see if I can figure it out. The error log was useless (surprise).
On Fri, Apr 24, 2015 at 11:40 AM, ad...@chromium.org wrote:
I'd prefer the original patch's approach (flattening the string in C++) and
just
fixing the GCMole problem. This use of %FlattenString is not intuitive (and
I've been following along... and it seems like this is getting pretty
messy. How are we going to spec this? I still want to know how we plan
for this to work with mutually recursive modules?
On Tue, Apr 21, 2015 at 9:33 AM, rossb...@chromium.org wrote:
PS: Might also try to store the link to
Oh. That seems Sumpter to fix.
On Mar 31, 2015 7:37 PM, Caitlin Potter caitpotte...@gmail.com wrote:
It’s because the address isn’t in AUTHORS
On Mar 31, 2015, at 7:33 PM, a...@chromium.org wrote:
On 2015/03/31 23:27:04, I haz the power (commit-bot) wrote:
Try jobs failed on following
Simpler!
On Mar 31, 2015 7:40 PM, Erik Arvidsson a...@chromium.org wrote:
Oh. That seems Sumpter to fix.
On Mar 31, 2015 7:37 PM, Caitlin Potter caitpotte...@gmail.com wrote:
It’s because the address isn’t in AUTHORS
On Mar 31, 2015, at 7:33 PM, a...@chromium.org wrote:
On 2015/03/31
I thought the idea was to remove arguments and caller from all
strict functions?
On Tue, Mar 24, 2015 at 12:35 PM, caitpotte...@gmail.com wrote:
On 2015/03/24 11:30:50, arv wrote:
It is not clear why we need 4 new maps? Can you list the different cases
of
functions and how their maps
Lets not reuse strong mode. Those might change for other reasons.
On Tue, Mar 24, 2015 at 12:36 PM, caitpotte...@gmail.com wrote:
On 2015/03/24 11:35:02, caitp wrote:
On 2015/03/24 11:30:50, arv wrote:
It is not clear why we need 4 new maps? Can you list the different cases
of
functions
Still in transit.
Can you add tests for Array.is array and concat too?
On a higher level I think we should probably always pass original
constructor but lets talk about that tomorrow.
On Mar 2, 2015 3:43 PM, dslo...@chromium.org wrote:
Reviewers: *arv, *mvstanton, rossberg,
Message:
PTAL
Staging only for now. We'll let it bake for a few weeks.
--
--
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
Toon. Can you take a look?
On Feb 17, 2015 8:26 PM, ad...@chromium.org wrote:
This is looking good to me, but I definitely think that Toon should take a
look
at this. In particular, that big if clause is getting ugly, and the switch
to
passing DEFINE_PROPERTY in from SetElementWithReceiver
need displayName.
On Thu, Feb 12, 2015 at 7:09 PM, Erik Arvidsson a...@google.com wrote:
On Feb 12, 2015 11:00 AM, Yury Semikhatsky yu...@chromium.org wrote:
Is Function.name going to writable in ES6? MDN says that the property is
read-only.
http://people.mozilla.org/~jorendorff/es6
change the value.
On Thu, Feb 12, 2015 at 6:53 PM, Erik Arvidsson a...@google.com wrote:
With ES6 and writable function name property the motivation for this is
as low as ever.
Maybe we should just work on implementing ES6 logic for function name
instead?
On Feb 12, 2015 9:59 AM
With ES6 and writable function name property the motivation for this is as
low as ever.
Maybe we should just work on implementing ES6 logic for function name
instead?
On Feb 12, 2015 9:59 AM, kozyatins...@chromium.org wrote:
Our stack getter is lazy, isn't it? I suppose if user want to receive
I didn't think of that. I think that might be cleaner.
On Jan 23, 2015 7:18 PM, ad...@chromium.org wrote:
https://codereview.chromium.org/873823003/diff/60001/src/preparser.h
File src/preparser.h (right):
https://codereview.chromium.org/873823003/diff/60001/src/
preparser.h#newcode3003
Regarding extra tests.
How about an object that has getters for all the flags and then assert that
these are called in the right order? Also, do the same thing with the
getters returning objects with valueOf to ensure that the valueOf is called
before the next getter is invoked.
On Sat, Dec 13,
You are right. valueOf is not called here. I was initially thinking of
toString and then realized that these are all booleans and did not think it
through.
On Sat, Dec 13, 2014 at 12:06 PM, Mathias Bynens mathi...@opera.com wrote:
On Sat, Dec 13, 2014 at 5:16 PM, Erik Arvidsson
The test case came from me trying to produce a repro. At that time it
wasn't clear why the file size mattered.
On Dec 11, 2014 9:08 AM, dslo...@chromium.org wrote:
On 2014/12/11 14:04:46, caitp wrote:
On 2014/12/11 14:01:17, marja wrote:
Also --harmony-regexp. In that case a global variable is defined from C++
On Thu, Dec 11, 2014 at 9:38 AM, caitpotte...@gmail.com wrote:
On 2014/12/11 14:31:47, rossberg wrote:
I'm sorry about that. There seem to be some assumptions about builtins
being
immutable somewhere in V8, although I
On Mon, Dec 1, 2014 at 10:37 AM, dslo...@chromium.org wrote:
I'll address other comments in a separate CL.
On 2014/12/01 15:14:07, arv wrote:
I thought the design we agreed upon was to allow statements and
expressions
that
did not reference `this`?
I can change this to work in that
The important part is that two call sites that have the same structure have
the same identity.
Here is an example where using the call site object as a key in cache
allows optimizations in Traceur:
https://github.com/google/traceur-compiler/blob/master/src/codegeneration/PlaceholderParser.js#L103
@googlegroups.com wrote:
On 7 November 2014 15:52, Erik Arvidsson a...@chromium.org wrote:
The important part is that two call sites that have the same structure
have
the same identity.
Yes, but wouldn't it be more adequate to key on the structural information?
/Andreas
Here is an example where using
We should really have this discussion outside this CL.
1. For non tagged template literals, we should do the desugaring in the
parser. That way we need no code gen for it.
2. Is complicated because the CallSite object has to be the same every time
the template literal is executed.
There are two forms.
1. __proto__ as an accessor on Object.prototype is added in v8natives.js
2. __proto__ in an object literal is handled by the compiler, making sure
that we set the [[Prototype]] of the new born object. We generate code for
this in FullCodeGenerator::VisitObjectLiteral
On Mon
On Sat, Oct 18, 2014 at 2:30 PM, Dmitry Lomov dslo...@chromium.org wrote:
On Sat, Oct 18, 2014 at 7:56 PM, Erik Arvidsson a...@chromium.org wrote:
I don't think an access check is needed. The function and prototype are
both new objects created by the class definition evaluation.
I see, you
I don't think an access check is needed. The function and prototype are
both new objects created by the class definition evaluation.
On Oct 18, 2014 5:05 AM, dslo...@chromium.org wrote:
https://codereview.chromium.org/639123009/diff/1/src/ia32/
full-codegen-ia32.cc
File
Is this worth it? It makes all the other cases slower. Is a single element
string common enough that this extra branch is needed?
On Sep 25, 2014 8:52 PM, fmea...@chromium.org wrote:
Reviewers: Yang,
Message:
PTAL.
Description:
Add a fast case for one-element string arrays in ArrayJoin
You can use --expose-builtins-as=...
(On phone now so I can't check the exact name)
On Aug 15, 2014 7:07 PM, dslo...@chromium.org wrote:
On 2014/08/15 23:02:41, arv wrote:
https://codereview.chromium.org/475423003/diff/20001/test/
mjsunit/harmony/toMethod.js
File
This is actually going to be OK in release mode. The function that gets
called takes Object and already handles Name correctly.
On Aug 12, 2014 7:39 PM, ad...@chromium.org wrote:
lgtm; seems like we might want to cherry-pick this whole thing into
whatever
ends up being M38
On Fri, Aug 8, 2014 at 8:29 AM, dp...@igalia.com wrote:
Let's take the spec of Array.prototype.map for example. The spec describes
the
following steps:
* Let mappedValue be the result of calling the Call internal method of
callbackfn with T as thisArgument and a List containing kValue,
Thanks.
On Wed, Aug 6, 2014 at 11:15 AM, rossb...@chromium.org wrote:
I'll land this.
https://codereview.chromium.org/384963002/
--
--
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
Thanks. Updating the code to use you new code.
On Fri, Jul 25, 2014 at 2:52 PM, verwa...@chromium.org wrote:
https://codereview.chromium.org/384963002/diff/21/src/contexts.cc
File src/contexts.cc (right):
https://codereview.chromium.org/384963002/diff/21/src/
On Wed, Jul 23, 2014 at 8:08 AM, verwa...@chromium.org wrote:
My comment below is based on a short explanation of the problem by
rossberg. Let
me know if some things are still unclear.
Overall: Please don't work around bugs (wasn't really a bug until
unscopable
since it wasn't observable
with unscopable.
hth,
Toon
On Wed, Jul 23, 2014 at 4:12 PM, Erik Arvidsson a...@chromium.org wrote:
On Wed, Jul 23, 2014 at 8:08 AM, verwa...@chromium.org wrote:
My comment below is based on a short explanation of the problem by
rossberg. Let
me know if some things are still unclear
Do you mind if I bundle these up into one CL? (I'll update the description)
On Wed, Jul 23, 2014 at 11:10 AM, verwa...@chromium.org wrote:
lgtm
https://codereview.chromium.org/410923003/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---You
Thanks for the smooth landing.
On Wed, Jun 25, 2014 at 7:27 PM, da...@chromium.org wrote:
I like this a lot. LGTM, I will land this for you. Thanks for the patch.
https://codereview.chromium.org/355663002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
On Thu, Jun 26, 2014 at 11:51 AM, rossb...@chromium.org wrote:
I agree that implementing it as a data property would be rather painful. I
think
it's fine to do this as an accessor for the time being. We can try to
lobby for
making that legal in the spec, although I kind of doubt that will be
Could we use a hidden prototype for arguments objects?
On Wed, Jun 25, 2014 at 12:16 PM, wi...@igalia.com wrote:
On 2014/06/25 15:55:05, arv wrote:
src/array-iterator.js:152: get: ArgumentsIteratorGetter,
It is not clear to me why this cannot be a data property?
It would be a per-object
On Tue, Jun 24, 2014 at 12:54 PM, da...@chromium.org wrote:
Ah. I think I know what's going on.
This only tests Map.prototype.forEach which does not need any iterator
result object or any array holding the entry.
The code on master creates an iterator result object and an entry array.
The
On Mon, Jun 23, 2014 at 6:04 PM, da...@chromium.org wrote:
On 2014/06/23 21:00:04, arv wrote:
On 2014/06/23 at 20:47:27, danno wrote:
On 2014/06/23 19:51:52, Michael Starzinger wrote:
Handing off to either Andreas or Danno.
https://codereview.chromium.org/329253004/diff/90001/src/
Map-Collections(Score): 82252
Map-Collections(Score): 81031
So, even with those 3 extra runtime calls it is much faster.
On Mon, Jun 23, 2014 at 6:11 PM, Erik Arvidsson a...@chromium.org wrote:
On Mon, Jun 23, 2014 at 6:04 PM, da...@chromium.org wrote:
On 2014/06/23 21:00:04, arv wrote
Just to make it clear. I'm not an owner so please wait for Andreas to look
at this too.
On Jun 17, 2014 11:41 AM, a...@chromium.org wrote:
LGTM
https://codereview.chromium.org/336403002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You
ulan@ Yes. I can disable and then update the tests.
On Tue, Jun 17, 2014 at 12:10 PM, u...@chromium.org wrote:
On 2014/06/17 07:23:41, marja wrote:
Committed patchset #4 manually as r21868 (tree was closed).
Today's roll with this CL breaks inspector console tests:
Thanks. No rush.
On Fri, Jun 13, 2014 at 10:55 AM, ma...@chromium.org wrote:
Oh and I'll land this CL next week, since it's Friday after-work-a-clock
here.
https://codereview.chromium.org/329413002/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
Thanks.
Traveling and TC39 this week but I think I'll have time tomorrow to update
this.
Normally a typo like this would be caught by a unit test. In this case the
unit test framework is deficient. I'll update it to add an arguments length
check in another CL.
On Jun 2, 2014 7:53 AM,
I think the second issue might be related to changes in GetProperty API. It
used to be a global function and now it is a static of Object (with
different type signature).
I've created a new CL and I'm running it on the try servers now.
On Tue, Apr 15, 2014 at 9:06 PM, ad...@chromium.org wrote:
On Tue, Apr 15, 2014 at 9:21 AM, rossb...@chromium.org wrote:
On 2014/04/15 13:05:23, arv wrote:
How are the callables in DOM represented? We use
ObjectTemplate::SetCallAsFunctionHandler for these
https://code.google.com/p/chromium/codesearch#search/q=
OK. I see that you fixed the `new Promise` - `new $Promise` there. I'll
close this CL.
On Wed, Mar 26, 2014 at 1:19 PM, rossb...@chromium.org wrote:
On 2014/03/26 16:56:25, arv wrote:
PTAL
Hi Arv, this is already subsumed by the ship promises CL that I had to
roll-back and couldn't
Using key === 0 will work. I didn't think of that. Thanks.
On Jan 27, 2014 11:35 PM, svenpa...@chromium.org wrote:
Quick DBC...
https://codereview.chromium.org/147143003/diff/30001/src/collection.js
File src/collection.js (right):
https://codereview.chromium.org/147143003/diff/30001/src/
they?
On Mon, Jan 20, 2014 at 5:18 PM, Erik Arvidsson a...@chromium.org wrote:
I think we have checked in an expectation with FAIL in it already. Let me
look at it in detail tomorrow.
On Mon, Jan 20, 2014 at 3:51 PM, Dmitry Lomov dslo...@chromium.orgwrote:
It feels that there is more
The test expectation needs a rebase. I'll add the test to test expectations
so we can land this. Once the V8 roll is complete I'll have to update the
test.
Today is a holiday in US so I'll do that tomorrow. I'll keep you informed.
On Mon, Jan 20, 2014 at 6:01 AM, dslo...@chromium.org wrote:
getSortedOwnPropertyNames(Boolean) should be length,name,prototype. Was
arguments,caller,length,name,prototype.
Or am I missing something?
On Mon, Jan 20, 2014 at 6:04 PM, Erik Arvidsson a...@chromium.org wrote:
The test expectation needs a rebase. I'll add the test to test
expectations so we can
Let me look at it after the holidays. Sorry for wasting your time.
On Fri, Dec 20, 2013 at 7:16 AM, rossb...@chromium.org wrote:
Hm, I get plenty of assertion failures when running the test suite on a
debug
build...
https://codereview.chromium.org/108083005/
--
erik
--
--
v8-dev
I'm with Andreas on this. It seems more consistent to allow an empty list.
Sure, it doesn't do anything but neither does array.push().
On Wed, Sep 11, 2013 at 9:24 AM, Rafael Weinstein rafa...@google.comwrote:
The main motivation is that it is an error. Nothing can be observed if the
On Wed, Aug 14, 2013 at 11:13 AM, verwa...@chromium.org wrote:
What I mean is that you can't break when you go past the length. You
actually
have to go to a slow path when you read past the length, that does the
entire
in-check; and loops until the index surpasses the preloaded length value.
HasElements is 21% faster than existing code and it still passes all tests.
I'll provide a new CL that only does that.
On Tue, Aug 13, 2013 at 12:05 PM, Vyacheslav Egorov vego...@chromium.orgwrote:
s/%HasElement(i, array)/%HasElement(array, i)/
Vyacheslav Egorov
On Tue, Aug 13, 2013 at
, Erik Arvidsson a...@chromium.org wrote:
HasElements is 21% faster than existing code and it still passes all
tests.
I'll provide a new CL that only does that.
On Tue, Aug 13, 2013 at 12:05 PM, Vyacheslav Egorov
vego...@chromium.org wrote:
s/%HasElement(i, array)/%HasElement(array, i
JS accessors make %HasFastPackedElements false. I need to verify what
happens with C++ interceptors.
On Tue, Aug 13, 2013 at 4:47 PM, verwa...@chromium.org wrote:
Dbc
Lame.
We have a bug in reduce/reduceRight then because we use this pattern which
is observable.
Maybe %HasFastPackedElements is fine after all since that will be false if
we have a getter. Need to test a bit more.
On Fri, Aug 9, 2013 at 11:40 AM, ad...@chromium.org wrote:
On 2013/08/09
This was agreed at the latest face to face meeting. Shipping the current
behavior, even under an experimental flag, is future hostile.
On Thu, Aug 1, 2013 at 12:17 PM, da...@chromium.org wrote:
NOT lgtm. Why the change for an experimental feature that we don't make any
promises about? This is
a lot to reduce peoples
immediate concerns.
On Thu, Aug 1, 2013 at 12:24 PM, Erik Arvidsson a...@chromium.org wrote:
This was agreed at the latest face to face meeting. Shipping the current
behavior, even under an experimental flag, is future hostile.
On Thu, Aug 1, 2013 at 12:17 PM, da
v8-natives.js has more efficient functions for this.
On Nov 14, 2012 5:26 PM, rafa...@chromium.org wrote:
Reviewers: rossberg, adamk, arv,
Description:
Use [[DefineOwnProperty]] to create properties of changeRecord in
NotifierPrototype.notify rather than [[Put]]
Note: The test here
On Thu, Oct 4, 2012 at 7:52 PM, c...@chromium.org wrote:
3. I couldn't save reference to the XXX.prototype.(compare|format).
Those are getters and I couldn't find a way to get to it without
executing it, which then fails.
You should be able to do Object.getOwnPropertyDescriptor to get the
(Correctly check for native error objects.)
Yang
On Fri, May 18, 2012 at 7:56 PM, Erik Arvidsson a...@chromium.org wrote:
On Fri, May 18, 2012 at 10:28 AM, Yang Guo yang...@chromium.org wrote:
We do have a testing framework with the cctests with which we can test
things from the C++ side
On Fri, May 18, 2012 at 10:28 AM, Yang Guo yang...@chromium.org wrote:
We do have a testing framework with the cctests with which we can test
things from the C++ side. Maybe we can mimick the bindings code there.
This does not need binding code to be tested. Here is a pseudo test.
function
73 matches
Mail list logo
