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. Howeve
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 O
Hi webkit-dev,
DOM MutationObservers (see meta bug
https://bugs.webkit.org/show_bug.cgi?id=68729) have been shipping as
WebKitMutationObserver in Chromium since earlier this year. The
feature is fully specced as part of DOM4
(http://www.w3.org/TR/domcore/#mutation-observers) and is implemented
in
On Fri, Jun 8, 2012 at 1:38 PM, Ojan Vafai wrote:
> On Fri, Jun 8, 2012 at 12:46 PM, Dirk Pranke wrote:
>
>> On Fri, Jun 8, 2012 at 12:44 PM, Ryosuke Niwa wrote:
>> > On Fri, Jun 8, 2012 at 12:37 PM, Dirk Pranke
>> wrote:
>> >>
>> >> I have no objection either to increasing the defaults for ei
On Fri, Jun 8, 2012 at 12:50 PM, Filip Pizlo wrote:
> On Jun 8, 2012, at 12:31 PM, Dirk Pranke wrote:
>
> > On Fri, Jun 8, 2012 at 10:56 AM, Filip Pizlo wrote:
> >>
> >> It's a lot harder to dive into, a lot more cumbersome to improve, and
> not
> >> any easier to maintain.
> >>
> >
> > I defini
On Fri, Jun 8, 2012 at 1:41 PM, Ojan Vafai wrote:
> On Fri, Jun 8, 2012 at 1:37 PM, Ryosuke Niwa wrote:
>
>> On Fri, Jun 8, 2012 at 1:27 PM, Dirk Pranke wrote:
>>>
>>> Most of these abstractions were either added to make testing easier
>>> (and faster since we didn't have to write to a real fil
On Fri, Jun 8, 2012 at 1:37 PM, Ryosuke Niwa wrote:
> On Fri, Jun 8, 2012 at 1:27 PM, Dirk Pranke 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.
>
FWIW, I tho
On Fri, Jun 8, 2012 at 12:46 PM, Dirk Pranke wrote:
> On Fri, Jun 8, 2012 at 12:44 PM, Ryosuke Niwa wrote:
> > On Fri, Jun 8, 2012 at 12:37 PM, Dirk Pranke
> wrote:
> >>
> >> I have no objection either to increasing the defaults for either of
> >> these numbers or making it possible to have dif
On Fri, Jun 8, 2012 at 1:27 PM, Dirk Pranke 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
___
webkit-dev mailing
On Fri, Jun 8, 2012 at 1:16 PM, Ryosuke Niwa 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 called
> test_shel
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 12:50 PM, Filip Pizlo wrote:
> On Jun 8, 2012, at 12:31 PM, Dirk Pranke wrote:
>
>> On Fri, Jun 8, 2012 at 10:56 AM, Filip Pizlo wrote:
>>>
>>> It's a lot harder to dive into, a lot more cumbersome to improve, and not
>>> any easier to maintain.
>>>
>>
>> I definitely agree
On Fri, Jun 8, 2012 at 1:09 PM, Jochen Eisinger wrote:
> On Fri, Jun 8, 2012 at 9:55 PM, Ryosuke Niwa wrote:
>
>> On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger wrote:
>>
>>> On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa wrote:
>>>
Per my other thread about sharing IDLs between DumpRende
On Fri, Jun 8, 2012 at 1:06 PM, Filip Pizlo 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. We've had many
On Fri, Jun 8, 2012 at 9:55 PM, Ryosuke Niwa wrote:
> On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger wrote:
>
>> On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa wrote:
>>
>>> Per my other thread about sharing IDLs between DumpRenderTree and
>>> WebKitTestRunner, I would like to see us sharing ID
On Jun 8, 2012, at 1:04 PM, Ryosuke Niwa wrote:
> On Fri, Jun 8, 2012 at 12:50 PM, Filip Pizlo wrote:
> On Jun 8, 2012, at 12:31 PM, Dirk Pranke wrote:
> > On Fri, Jun 8, 2012 at 10:56 AM, Filip Pizlo wrote:
> >>
> >> It's a lot harder to dive into, a lot more cumbersome to improve, and not
>
On Fri, Jun 8, 2012 at 12:50 PM, Filip Pizlo wrote:
> On Jun 8, 2012, at 12:31 PM, Dirk Pranke wrote:
> > On Fri, Jun 8, 2012 at 10:56 AM, Filip Pizlo wrote:
> >>
> >> It's a lot harder to dive into, a lot more cumbersome to improve, and
> not
> >> any easier to maintain.
> >>
> >
> > I definit
On Fri, Jun 8, 2012 at 12:23 PM, Filip Pizlo wrote:
>
> On Jun 8, 2012, at 12:19 PM, Dirk Pranke wrote:
>
>> On Fri, Jun 8, 2012 at 8:21 AM, Filip Pizlo wrote:
>>>
>>> On Jun 8, 2012, at 4:38 AM, Balazs Kelemen wrote:
>>>
On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote:
> Hi,
>
On Fri, Jun 8, 2012 at 12:51 PM, Jochen Eisinger wrote:
> On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa wrote:
>
>> Per my other thread about sharing IDLs between DumpRenderTree and
>> WebKitTestRunner, I would like to see us sharing IDL with WebKitTestRunner
>> instead of adding yet another bindi
On Fri, Jun 8, 2012 at 9:41 PM, Ryosuke Niwa wrote:
> On Fri, Jun 8, 2012 at 12:18 PM, Jochen Eisinger wrote:
>
>> 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 experim
On Jun 8, 2012, at 12:31 PM, Dirk Pranke wrote:
> On Fri, Jun 8, 2012 at 10:56 AM, Filip Pizlo 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
> shoul
On Fri, Jun 8, 2012 at 12:44 PM, Ryosuke Niwa wrote:
> On Fri, Jun 8, 2012 at 12:37 PM, Dirk Pranke 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 differen
On Fri, Jun 8, 2012 at 12:37 PM, Dirk Pranke 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 failures and infin
On Fri, Jun 8, 2012 at 12:18 PM, Jochen Eisinger wrote:
>
> 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 t
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 P
On Fri, Jun 8, 2012 at 10:56 AM, Filip Pizlo 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 features we needed t
On Fri, Jun 8, 2012 at 12:12 PM, Ojan Vafai wrote:
> On Fri, Jun 8, 2012 at 12:08 PM, Ryosuke Niwa wrote:
>
>> On Fri, Jun 8, 2012 at 12:05 PM, Ojan Vafai 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 ca
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 improvem
On Jun 8, 2012, at 12:19 PM, Dirk Pranke wrote:
> On Fri, Jun 8, 2012 at 8:21 AM, Filip Pizlo wrote:
>>
>> On Jun 8, 2012, at 4:38 AM, Balazs Kelemen wrote:
>>
>>> On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote:
Hi,
Dirk Pranke írta:
> I believe most if not all of the por
On Fri, Jun 8, 2012 at 10:14 AM, Zoltan Herczeg 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 were not allo
On Fri, Jun 8, 2012 at 8:21 AM, Filip Pizlo wrote:
>
> On Jun 8, 2012, at 4:38 AM, Balazs Kelemen 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 c
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 ch
Hi Ossy,
Thanks for your reply ...
On Fri, Jun 8, 2012 at 12: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).
On Fri, Jun 8, 2012 at 12:08 PM, Ryosuke Niwa wrote:
> On Fri, Jun 8, 2012 at 12:05 PM, Ojan Vafai 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
On Fri, Jun 8, 2012 at 12:05 PM, Ojan Vafai 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 hit this limi
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 deve
On Jun 8, 2012, at 9:52 AM, Ojan Vafai wrote:
> On Fri, Jun 8, 2012 at 9:25 AM, Filip Pizlo 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 Kelemen wrote:
> >>
> >>> On 06/08/2012 09:46 AM, O
On Fri, Jun 8, 2012 at 10:14 AM, Zoltan Herczeg 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 were not a
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 9:25 AM, Filip Pizlo 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 Kelemen wrote:
> >>
> >>> On 06/08/2012 09:46 AM, Osztrogonac Csaba wrote:
> Hi,
>
> Di
On Fri, Jun 8, 2012 at 12: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
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 Kelemen 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 sta
On 06/08/2012 05:21 PM, Filip Pizlo wrote:
On Jun 8, 2012, at 4:38 AM, Balazs Kelemen 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 fi
On Jun 8, 2012, at 4:38 AM, Balazs Kelemen 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 Appl
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 P
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 Networ
[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 concaten
Sources/WTF/config.h already disables it:
// this breaks compilation of , 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
#endif
I don't thi
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 combi
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 t
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 in
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 th
52 matches
Mail list logo
