On Jun 7, 2011, at 4:22 PM, Darin Adler wrote:
I think the “make some things non-const” part of this would be the first part
to put up for review and land.
To expand on Darin's remark in two different ways:
1) We definitely have consensus to fix the broken non-logically-const accessors
by
Hi,
In line with our efforts towards CSS_Regions/CSS_Exclusions support in
WebKit, we intend to configure a slave build bot. We have a Mac Snow
Leopard machine dedicated to this purpose. At this point, we need a
username and a password to progress further.
How can we obtain them?
The build bot
itisravi wrote:
Hello all,
Referring to
https://lists.webkit.org/pipermail/webkit-help/2011-June/002150.html this
,
I'm trying to cross compile webkit 1.4 (gtk port) for ARM with NEON flags
enabled for the SVG lighting filters.Though both -mfpu=neon and
-mfloat-abi=softfp flags are
On Jun 7, 2011, at 11:51 PM, Mihnea-Vlad Ovidenie wrote:
Hi,
In line with our efforts towards CSS_Regions/CSS_Exclusions support in
WebKit, we intend to configure a slave build bot. We have a Mac Snow
Leopard machine dedicated to this purpose. At this point, we need a
username and a
Hi all,
As of this morning, build.webkit.org master reports the number of failures,
flaky tests, and new passes (aka unexpected passes) on test bots that run
new-run-webkit-tests. I encourage you to take a look at Chromium Mac
Release
Hi webkit-dev,
I wanted to let you know that Ojan and I plan to add flexbox layout support
to WebCore. WebCore already supports an older flexbox implementation
(display: box), but the new spec is designed to be easier for developers to
understand and more powerful. The old flexbox will still
Can't we just define ENABLE_FLEXBOX on one or more of the commonly
used ports and use the regular bots?
Adam
On Wed, Jun 8, 2011 at 10:57 AM, Tony Chang t...@chromium.org wrote:
Hi webkit-dev,
I wanted to let you know that Ojan and I plan to add flexbox layout support
to WebCore. WebCore
I don't think we want to ship this until we have a reasonably feature
complete implementation of the spec and that we're convinced the spec is
stable. I expect that in implementing this we'll find areas of the spec that
need reworking, but at this point it's mainly blocked on implementation
New features should be tested incrementally as they are developed.
That means running them on build.webkit.org. The decision to ship a
feature is separate.
Adam
On Wed, Jun 8, 2011 at 11:33 AM, Ojan Vafai o...@chromium.org wrote:
I don't think we want to ship this until we have a reasonably
Is it possible for this feature to be enabled at runtime?
On Jun 8, 2011 11:38 AM, Adam Barth aba...@webkit.org wrote:
New features should be tested incrementally as they are developed.
That means running them on build.webkit.org. The decision to ship a
feature is separate.
Adam
On Wed,
Maybe, it would involve disabling CSS parser rules at runtime. I don't
think we have any code that currently tries to do this.
On Wed, Jun 8, 2011 at 11:41 AM, Darin Fisher da...@chromium.org wrote:
Is it possible for this feature to be enabled at runtime?
On Jun 8, 2011 11:38 AM, Adam Barth
On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com wrote:
1) We definitely have consensus to fix the broken non-logically-const
accessors by making them non-const; consensus on also adding const accessors
is less clear.
There are a surprising number of places that actually do
Kind of. We could make the functionality only work at runtime, but adding
the properties to the CSS parser would be difficult to make runtime
configurable. So, the CSS properties would parse correctly but do nothing.
That's especially problematic for properties like display that would then
get an
On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote:
On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com wrote:
1) We definitely have consensus to fix the broken non-logically-const
accessors by making them non-const; consensus on also adding const accessors
is less clear.
On Wed, Jun 8, 2011 at 11:51 AM, Darin Adler da...@apple.com wrote:
On Jun 8, 2011, at 11:48 AM, Peter Kasting wrote:
On Tue, Jun 7, 2011 at 11:18 PM, Maciej Stachowiak m...@apple.com
wrote:
1) We definitely have consensus to fix the broken non-logically-const
accessors by making them
On Jun 8, 2011, at 11:56 AM, Peter Kasting wrote:
What I thought Maciej was saying was that we should remove const on all the
existing accessors, in both categories, which sounded different than what you
were saying (which I read as remove const on the accessors in the first
category).
It seems like the simplest thing is to have an ENABLE macro that's
turned on and to use the normal bots. If you're really worried about
folks shipping the feature half-done by accident, you can use a goofy
name like -webkit-goofybox (or whatever) and rename it to the final
name when you're ready.
On Wed, Jun 8, 2011 at 11:59 AM, Darin Adler da...@apple.com wrote:
On Jun 8, 2011, at 11:56 AM, Peter Kasting wrote:
I'm perfectly happy removing const from accessors in the first
category. I can post a change that does that before going any further.
Yes, I believe that’s what both Maciej
I noticed that the commit-queue is a lot zippier now. Thanks!
Nico
On Wed, Jun 8, 2011 at 1:57 PM, Adam Barth aba...@webkit.org wrote:
Update: The new commit-queue nodes run about 6x faster than the old
nodes (wow). We're now fully switched over and have re-allocated the
Mac Minis to the
Re-sending w/o the attached file.
On Wed, Jun 8, 2011 at 3:31 PM, Eric Seidel e...@webkit.org wrote:
I used Safari's built-in Page Load Test mechanism to test the page.
I created a flickr.pltsuite and placed it in
/Applications/Safari.app/Contents/Resources/flickr.pltsuite with the
contents:
If you're super worried about folks shipping the feature before it's
ready, then that approach can make sense. I'm not sure how well it
scales, but we can worry about that problem when we have N such
configurations.
Adam
On Wed, Jun 8, 2011 at 3:19 PM, Tony Chang t...@chromium.org wrote:
I
If you are interested in optimization suggestions inside WebKit, I'm
happy to have a lengthy discussion with you over #webkit.
We've talked about moving the HTML5 parser off into its own thread,
which may be a win on some pages.
WebCore's memory usage is way too high (which also affects execution
It seems like it doesn't scale very well to have to stand-up new buildbots
for each
new feature. At least in the Chromium port, it is possible for the Chromium
repo
to override ENABLE_ flags so that only DRT gets built with a prototype
feature,
making it easy to test a prototype feature using
On Wed, Jun 8, 2011 at 4:20 PM, Darin Fisher da...@chromium.org wrote:
It seems like it doesn't scale very well to have to stand-up new buildbots
for each
new feature. At least in the Chromium port, it is possible for the
Chromium repo
to override ENABLE_ flags so that only DRT gets built
On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org wrote:
Oh, okay. Why do we have override_features.gypi then?
We don't, Adam tried to remove it earlier this week and was foiled by some
weird complex failure. We should get rid of it ASAP.
Regardless, it seems like we could
On Wed, Jun 8, 2011 at 4:59 PM, James Robinson jam...@google.com wrote:
On Wed, Jun 8, 2011 at 4:55 PM, Darin Fisher da...@chromium.org wrote:
Oh, okay. Why do we have override_features.gypi then?
We don't, Adam tried to remove it earlier this week and was foiled by some
weird complex
Are you referring to the additional cost of maintaining different test
expectations between the two configs? Agreed, that would suck.
So, how painful would it be to add runtime enablement support for new CSS
features?
On Jun 8, 2011 5:16 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, Jun
No, but I hadn't even thought of that ;)
Mostly I was thinking of the pain of developers having to keep track
of which configuration was which, testing in both configurations, etc.
-- Dirk
On Wed, Jun 8, 2011 at 5:24 PM, Darin Fisher da...@chromium.org wrote:
Are you referring to the
The difference between runtime and compile time enabling seems like a red
herring. The issue is more which configurations to test where and to ship
where, not how to do the configuring.
Adam
On Jun 8, 2011 5:25 PM, Darin Fisher da...@chromium.org wrote:
Are you referring to the additional cost
[If you don't care about JSC or V8 bindings you can safely ignore
this.]
TL;DR I want to change the JavaScript bindings to put EventTarget on
the prototype chain so it is easier to work with event targets from
JavaScript. What do you think?
Here is the prototype chain for a button today:
OK, but it is very nice to ship what you test (i.e., avoid the need to
create a separate build of WebCore for testing). Continuous integration is
also nice (i.e., no branches).
Marrying those constraints leads to runtime enabling features. This is
precisely the recipe Chromium uses to great
+1 for runtime configuration.
Keeping code runnable is nice, and hard if it's disabled on many
developers' working copies.
We don't need to use traditional flag-holder like Settings class
and can use simple global-ish variables instead,
because We don't need to configure it per-Page basis.
I
32 matches
Mail list logo
