Patchset 10 (id:??) landed as
https://crrev.com/4fe08abde6045f09eacb7a9bc350be235671cea9
Cr-Commit-Position: refs/heads/master@{#29899}
https://codereview.chromium.org/1245623005/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this messa
Committed patchset #10 (id:21)
https://codereview.chromium.org/1245623005/
--
--
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 an
CQ is trying da patch. Follow status at
https://chromium-cq-status.appspot.com/patch-status/1245623005/21
View timeline at
https://chromium-cq-status.appspot.com/patch-timeline/1245623005/21
https://codereview.chromium.org/1245623005/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
On 2015/07/28 19:52:39, Michael Achenbach wrote:
On 2015/07/28 16:14:06, Jakob wrote:
> Yes, I like this approach much better. LGTM.
>
> What's up with the v8_linux_rel bot? Looks like it doesn't have
test262-es6.
Worse, that's another bug that requires fixing. There's a some problem in
test
On 2015/07/28 16:14:06, Jakob wrote:
Yes, I like this approach much better. LGTM.
What's up with the v8_linux_rel bot? Looks like it doesn't have
test262-es6.
Worse, that's another bug that requires fixing. There's a some problem in
test262-es6's testcfg and python throws an error on load.
Yes, I like this approach much better. LGTM.
What's up with the v8_linux_rel bot? Looks like it doesn't have test262-es6.
https://codereview.chromium.org/1245623005/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because yo
PTAL. I'm back to dictionaries and implemented your suggestion of filtering
names first and letting the test suite turn the names into flags by a custom
method. The generator class stayed to capture the state and the
precomputation
in there.
My measurements show that the dictionary lookups are
Wouldn't the following design simplify things:
- let each test suite provide a default list of named variants (just the
names,
not the corresponding flag lists)
- let the command-line args filter those default variants as needed
- let each test case, by means of the status file, further filter t
This feels like a *lot* of complexity. Dynamically selected callables that
return callables that return iterables? At the very least, I'd like some
more
descriptive naming, to make it easier to understand what's going on, see
comments below.
Wouldn't the following design simplify things:
- let
