Hi,
Dirk Pranke írta:
I believe most if not all of the ports have started using either
TestExpectations files or a combination of TestExpectations files
(except for the Apple Win port).
Can we explicitly switch to the TestExpectations files at this point
and drop support for Skipped files on
Hey all,
I'm currently trying to patch (Qt-)WebKit in order to build it for QNX. Now
I'm running into an issue which I wonder how to address properly. Most *.cpp
files start with the following lines in WebKit:
// file foo.cpp:
#include config.h
#include foo.h
Now, this might trigger the
On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote:
Hi,
Dirk Pranke írta:
I believe most if not all of the ports have started using either
TestExpectations files or a combination of TestExpectations files
(except for the Apple Win port).
Can we explicitly switch to the TestExpectations files at
Hi,
I'm trying to combine all the web inspector resources CSS, JS HTML into as
few files as possible. I know that there are scripts in
Source/WebCore/inspector but I'm not sure which ones should be used and some
don't contain usage information.
Also there's both combine-front-end.py and
Sources/WTF/config.h already disables it:
// this breaks compilation of QFontDatabase, at least, so turn it off
for now
// Also generates errors on wx on Windows and QNX, because these functions
// are used from wx and QNX headers.
#if !PLATFORM(QT) !PLATFORM(WX) !OS(QNX)
#include
[From chromium.org]
We throw away closure compiler output and use compilation step for type
checking only.
The best way to learn what files you should combine and bundle is via
looking at WebCore.gyp(i) and WebKit.gyp(i). You basically need what is
listed in inspector.html (these you can
We're already using a homegrown script that does what you mention in
PlatformBlackBerry.cmake lines 194-214 but wanted to switch to something that
was maintained by the community.
I'll look at the gyp/gypi files for more info.
Thanks,
Konrad
Sent from my BlackBerry on the Rogers Wireless
We don't consider front-end deployment a part of WebCore's
responsibilities. But I do see where you are coming from. We could extract
relevant gyp sub-project or maintain a separate python script that would
deploy front-end. Or you could contribute one yourself!
Regards
Pavel
On Jun 8, 2012 1:13
On Jun 8, 2012, at 4:38 AM, Balazs Kelemen kbal...@webkit.org wrote:
On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote:
Hi,
Dirk Pranke írta:
I believe most if not all of the ports have started using either
TestExpectations files or a combination of TestExpectations files
(except for the
On 06/08/2012 05:21 PM, Filip Pizlo wrote:
On Jun 8, 2012, at 4:38 AM, Balazs Kelemenkbal...@webkit.org wrote:
On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote:
Hi,
Dirk Pranke írta:
I believe most if not all of the ports have started using either
TestExpectations files or a combination of
On Jun 8, 2012, at 9:16 AM, Balazs Kelemen wrote:
On 06/08/2012 05:21 PM, Filip Pizlo wrote:
On Jun 8, 2012, at 4:38 AM, Balazs Kelemenkbal...@webkit.org wrote:
On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote:
Hi,
Dirk Pranke írta:
I believe most if not all of the ports have started
On Fri, Jun 8, 2012 at 12:46 AM, Osztrogonac Csaba o...@inf.u-szeged.huwrote:
Hi,
Dirk Pranke írta:
I believe most if not all of the ports have started using either
TestExpectations files or a combination of TestExpectations files
(except for the Apple Win port).
Can we explicitly
On Fri, Jun 8, 2012 at 9:25 AM, Filip Pizlo fpi...@apple.com wrote:
On Jun 8, 2012, at 9:16 AM, Balazs Kelemen wrote:
On 06/08/2012 05:21 PM, Filip Pizlo wrote:
On Jun 8, 2012, at 4:38 AM, Balazs Kelemenkbal...@webkit.org wrote:
On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote:
Hi,
Hi,
I don't see why it would make sense to keep two parallel tools for this
once all the workflow bugs people have are addressed.
The reason is easy. In the past when people tried to add new features to
NRWT, they were not allowed to because the feature is not useful for NRWT
devs. Eventually
On Fri, Jun 8, 2012 at 10:14 AM, Zoltan Herczeg zherc...@webkit.org wrote:
Hi,
I don't see why it would make sense to keep two parallel tools for this
once all the workflow bugs people have are addressed.
The reason is easy. In the past when people tried to add new features to
NRWT, they
On Jun 8, 2012, at 9:52 AM, Ojan Vafai wrote:
On Fri, Jun 8, 2012 at 9:25 AM, Filip Pizlo fpi...@apple.com wrote:
On Jun 8, 2012, at 9:16 AM, Balazs Kelemen wrote:
On 06/08/2012 05:21 PM, Filip Pizlo wrote:
On Jun 8, 2012, at 4:38 AM, Balazs Kelemenkbal...@webkit.org wrote:
On
Speaking of differences between NRWT and ORWT, ORWT doesn't limit to n
failures by default. NRWT limits to 500 by default. It looks like all the
bots pass in --exit-after-n-failures=500. Any objection to making NRWT
match ORWT here? I don't think having this limit is useful/necessary for
local
On Fri, Jun 8, 2012 at 12:05 PM, Ojan Vafai o...@chromium.org wrote:
We'll still default --exit-after-n-crashes-or-timeouts to 20. That seems
more useful to me since you'd rarely hit this case locally and want to
continue running tests.
We should also increase this number. Non-chromium bots
On Fri, Jun 8, 2012 at 12:08 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jun 8, 2012 at 12:05 PM, Ojan Vafai o...@chromium.org wrote:
We'll still default --exit-after-n-crashes-or-timeouts to 20. That seems
more useful to me since you'd rarely hit this case locally and want to
continue
Hi Ossy,
Thanks for your reply ...
On Fri, Jun 8, 2012 at 12:46 AM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote:
Hi,
Dirk Pranke írta:
I believe most if not all of the ports have started using either
TestExpectations files or a combination of TestExpectations files
(except for the Apple
Hey,
I've implemented initial support for running layout tests using chromium's
content_shell instead of test_shell as the current DRT implementation does.
It's still a very experimental, but might already be interesting for some
of you to try.
The main advantage is that content_shell includes
On Fri, Jun 8, 2012 at 8:21 AM, Filip Pizlo fpi...@apple.com wrote:
On Jun 8, 2012, at 4:38 AM, Balazs Kelemen kbal...@webkit.org wrote:
On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote:
Hi,
Dirk Pranke írta:
I believe most if not all of the ports have started using either
TestExpectations
On Fri, Jun 8, 2012 at 10:14 AM, Zoltan Herczeg zherc...@webkit.org wrote:
Hi,
I don't see why it would make sense to keep two parallel tools for this
once all the workflow bugs people have are addressed.
The reason is easy. In the past when people tried to add new features to
NRWT, they
On Jun 8, 2012, at 12:19 PM, Dirk Pranke wrote:
On Fri, Jun 8, 2012 at 8:21 AM, Filip Pizlo fpi...@apple.com wrote:
On Jun 8, 2012, at 4:38 AM, Balazs Kelemen kbal...@webkit.org wrote:
On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote:
Hi,
Dirk Pranke írta:
I believe most if not all of
I'm all for getting rid of ORWT. I've observed some wrong code paths there
that are probably not even used anymore. It makes more difficult to hack on
a code which almost nobody uses and whose part of it is wrong and
misleading.
NRWT is not that easy thought, but I see the unittests as an
On Fri, Jun 8, 2012 at 12:12 PM, Ojan Vafai o...@chromium.org wrote:
On Fri, Jun 8, 2012 at 12:08 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jun 8, 2012 at 12:05 PM, Ojan Vafai o...@chromium.org wrote:
We'll still default --exit-after-n-crashes-or-timeouts to 20. That seems
more
On Fri, Jun 8, 2012 at 10:56 AM, Filip Pizlo fpi...@apple.com wrote:
It's a lot harder to dive into, a lot more cumbersome to improve, and not
any easier to maintain.
I definitely agree that NRWT is more complicated than it seems like it
should be; it got contorted as we added all the
I have no objection either to increasing the defaults for either of
these numbers or making it possible to have different defaults per
port.
Do you want to suggest different defaults? Should we use ORWT's
(infinite failures and infinite crashes by default)?
-- Dirk
On Fri, Jun 8, 2012 at 12:31
On Fri, Jun 8, 2012 at 12:18 PM, Jochen Eisinger joc...@chromium.orgwrote:
I've implemented initial support for running layout tests using chromium's
content_shell instead of test_shell as the current DRT implementation does.
It's still a very experimental, but might already be interesting for
On Fri, Jun 8, 2012 at 12:37 PM, Dirk Pranke dpra...@chromium.org wrote:
I have no objection either to increasing the defaults for either of
these numbers or making it possible to have different defaults per
port.
Do you want to suggest different defaults? Should we use ORWT's
(infinite
On Fri, Jun 8, 2012 at 12:44 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jun 8, 2012 at 12:37 PM, Dirk Pranke dpra...@chromium.org wrote:
I have no objection either to increasing the defaults for either of
these numbers or making it possible to have different defaults per
port.
Do you
On Jun 8, 2012, at 12:31 PM, Dirk Pranke wrote:
On Fri, Jun 8, 2012 at 10:56 AM, Filip Pizlo fpi...@apple.com wrote:
It's a lot harder to dive into, a lot more cumbersome to improve, and not
any easier to maintain.
I definitely agree that NRWT is more complicated than it seems like it
On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jun 8, 2012 at 12:18 PM, Jochen Eisinger joc...@chromium.orgwrote:
I've implemented initial support for running layout tests using
chromium's content_shell instead of test_shell as the current DRT
implementation
On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger joc...@chromium.orgwrote:
On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa rn...@webkit.org wrote:
Per my other thread about sharing IDLs between DumpRenderTree and
WebKitTestRunner, I would like to see us sharing IDL with WebKitTestRunner
instead
On Fri, Jun 8, 2012 at 12:23 PM, Filip Pizlo fpi...@apple.com wrote:
On Jun 8, 2012, at 12:19 PM, Dirk Pranke wrote:
On Fri, Jun 8, 2012 at 8:21 AM, Filip Pizlo fpi...@apple.com wrote:
On Jun 8, 2012, at 4:38 AM, Balazs Kelemen kbal...@webkit.org wrote:
On 06/08/2012 09:46 AM, Osztrogonac
On Fri, Jun 8, 2012 at 12:50 PM, Filip Pizlo fpi...@apple.com wrote:
On Jun 8, 2012, at 12:31 PM, Dirk Pranke wrote:
On Fri, Jun 8, 2012 at 10:56 AM, Filip Pizlo fpi...@apple.com wrote:
It's a lot harder to dive into, a lot more cumbersome to improve, and
not
any easier to maintain.
On Jun 8, 2012, at 1:04 PM, Ryosuke Niwa wrote:
On Fri, Jun 8, 2012 at 12:50 PM, Filip Pizlo fpi...@apple.com wrote:
On Jun 8, 2012, at 12:31 PM, Dirk Pranke wrote:
On Fri, Jun 8, 2012 at 10:56 AM, Filip Pizlo fpi...@apple.com wrote:
It's a lot harder to dive into, a lot more cumbersome
On Fri, Jun 8, 2012 at 9:55 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger joc...@chromium.orgwrote:
On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa rn...@webkit.org wrote:
Per my other thread about sharing IDLs between DumpRenderTree and
On Fri, Jun 8, 2012 at 1:06 PM, Filip Pizlo fpi...@apple.com wrote:
On Jun 8, 2012, at 1:04 PM, Ryosuke Niwa wrote:
I agree that we've accumulated way too many unit tests in webkitpy and
some of our unit test code is hideous but I think it's quite unrealistic
not to have any unit tests.
On Fri, Jun 8, 2012 at 1:09 PM, Jochen Eisinger joc...@chromium.org wrote:
On Fri, Jun 8, 2012 at 9:55 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger joc...@chromium.orgwrote:
On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jun 8, 2012 at 12:50 PM, Filip Pizlo fpi...@apple.com wrote:
On Jun 8, 2012, at 12:31 PM, Dirk Pranke wrote:
On Fri, Jun 8, 2012 at 10:56 AM, Filip Pizlo fpi...@apple.com wrote:
It's a lot harder to dive into, a lot more cumbersome to improve, and not
any easier to maintain.
I
Hi webkit-dev,
*If you work on web-facing features, or run into another bug which does,
please consider adding the WebExposed keyword to it.*
Many of you will be familiar with my WebKit updates, which are now also
being published on the WebKit blog. Writing these involves reading every
On Fri, Jun 8, 2012 at 1:16 PM, Ryosuke Niwa rn...@webkit.org wrote:
I don't think that's true from my experience working on webkitpy so far. The
root of problem is that we support way too many configurations platforms,
and Chromium port has had a completely different test runner program
On Fri, Jun 8, 2012 at 1:27 PM, Dirk Pranke dpra...@chromium.org wrote:
Most of these abstractions were either added to make testing easier
(and faster since we didn't have to write to a real filesystem)
That sounds like a bad idea.
- Ryosuke
___
On Fri, Jun 8, 2012 at 1:41 PM, Ojan Vafai o...@chromium.org wrote:
On Fri, Jun 8, 2012 at 1:37 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jun 8, 2012 at 1:27 PM, Dirk Pranke dpra...@chromium.org wrote:
Most of these abstractions were either added to make testing easier
(and faster
On Fri, Jun 8, 2012 at 1:38 PM, Ojan Vafai o...@chromium.org wrote:
On Fri, Jun 8, 2012 at 12:46 PM, Dirk Pranke dpra...@chromium.org wrote:
On Fri, Jun 8, 2012 at 12:44 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Fri, Jun 8, 2012 at 12:37 PM, Dirk Pranke dpra...@chromium.org
wrote:
I
Hi Dirk,
At any rate, I believe we are definitely open to adding new features;
feel free to suggest them or work on them!
I am happy to hear that.
https://bugs.webkit.org/show_bug.cgi?id=88680
This is definitely a right step! And it looks like still a lot of things
to do before NRWT reach
Hi,
In the discussion to rename FAIL to DIFF, the consensus appeared that we
should get rid of it altogether in the favor of more specific test failure
expectations. I've done that in http://trac.webkit.org/changeset/119892 and
http://trac.webkit.org/changeset/119889 for all but GTK+ ports.
48 matches
Mail list logo
