On Thu, Jan 22, 2015 at 1:56 PM, Darin Adler wrote:
> > On Jan 22, 2015, at 12:58 PM, Dirk Pranke wrote:
> >
> > Of course, Chromium was more willing to incur the cost of keeping all of
> the pixel tests up to date when trivial things changed the output
>
> Th
On Thu, Jan 22, 2015 at 11:48 AM, Alexey Proskuryakov wrote:
>
> 22 янв. 2015 г., в 11:30, Simon Fraser
> написал(а):
>
> > This happens when the expected and actual images are very close, but not
> identical. ImageDiff has some built-in rounding that effectively acts as a
> small tolerance, so
iOS was the only one I was aware of that was left.
-- Dirk
On Mon, Jul 28, 2014 at 12:25 PM, David Farler wrote:
> Hi,
>
> Are there any ports or users of old-run-webkit-tests left besides the iOS
> Simulator? I'm on the verge of completing iOS Simulator support for
> webkitpy and run-webkit-t
On Mon, Mar 24, 2014 at 3:32 PM, Bem Jones-Bey wrote:
>
> On Mar 24, 2014, at 14:54 , Dirk Pranke wrote:
>
>
>
>
> On Sun, Mar 23, 2014 at 12:52 PM, Benjamin Poulain wrote:
>
>> Same here :(
>>
>>
>> On 3/23/14, 12:15 PM, Darin Adler wrote:
>
On Sun, Mar 23, 2014 at 12:52 PM, Benjamin Poulain wrote:
> Same here :(
>
>
> On 3/23/14, 12:15 PM, Darin Adler wrote:
>
>> When I use run-webkit-tests to run the entire test suite, on a debug
>> build of TOT WebKit, on Mavericks, I’m having the following problems:
>>
>> - Towards the end of the
Ryosuke and I discussed this a bit over IRC. Ryosuke's main concern was
that supporting multiple document roots adds a fair amount of complexity to
NRWT. Conceptually, it's probably easier to add support to run the W3C's
new server (known as wptserve) and then maybe use it for *all* imported
tests
The way I got around this when I was first working on it was to simply map
imported/w3c onto a subdirectory of the document root in apache; it's a two
line change.
For some time I've toyed with the idea of changing the DocumentRoot to just
be LayoutTests/, so that any test could be run over http d
On Wed, Dec 4, 2013 at 11:19 AM, Darin Adler wrote:
>
> On Dec 4, 2013, at 6:48 AM, youenn fablet wrote:
>
> I am planning to add some XHR tests from
> https://github.com/w3c/web-platform-tests.
> My initial plan was to add them in a subdirectory of
> LayoutTests/http/tests/w3c.
> If adding them
On Fri, Aug 30, 2013 at 3:48 PM, Oliver Hunt wrote:
>
> On Aug 30, 2013, at 12:44 PM, Dirk Pranke wrote:
>
> On Fri, Aug 30, 2013 at 10:06 AM, Oliver Hunt wrote:
>
>>
>> On Aug 30, 2013, at 9:15 AM, Brendan Long wrote:
>>
>> > On 08/29/2013 05:45
On Fri, Aug 30, 2013 at 10:06 AM, Oliver Hunt wrote:
>
> On Aug 30, 2013, at 9:15 AM, Brendan Long wrote:
>
> > On 08/29/2013 05:45 PM, Benjamin Poulain wrote:
> >> Can you explain a bit what it is for? What are the common use cases?
> > This would be useful for certain kinds of web apps. For ex
I may be missing context, or just slow, but how does that link illustrate
things being harmful ? It looks like you're mostly adding the bug numbers
inline and/or taking skipped tests and making them flaky ?
-- Dirk
On Wed, May 22, 2013 at 6:11 PM, Ryosuke Niwa wrote:
> And there is an overwhel
It seems like you could get nearly both things if you just had people list
both their @webkit.org and @company.com addresses (or at least a company
affiliation, if not an actual address) in committers.py, right?
-- Dirk
On Mon, Apr 29, 2013 at 10:26 AM, Brian Weinstein wrote:
> What Simon said i
On Wed, Apr 24, 2013 at 4:00 PM, Darin Adler wrote:
> On Apr 24, 2013, at 3:52 PM, Dirk Pranke wrote:
>
> > You mean it's easy to write a test that is bigger than 800x600, and
> perhaps we should generate some sort of warning for this?
>
> It’s easy to write a tes
On Wed, Apr 24, 2013 at 3:49 PM, Darin Adler wrote:
> On Apr 24, 2013, at 3:45 PM, Dirk Pranke wrote:
>
> > in the absence of tests that *need* bigger viewports, I'd side w/ David
> and say that we should fix tests to fit within 800x600 so that they are
> portable to othe
On Wed, Apr 24, 2013 at 3:35 PM, Elliott Sprehn wrote:
>
> On Wed, Apr 24, 2013 at 3:31 PM, Dirk Pranke wrote:
>
>>
>>
>>
>> On Wed, Apr 24, 2013 at 3:29 PM, Elliott Sprehn wrote:
>>
>>> On Wed, Apr 24, 2013 at 11:11 AM, Dirk Pranke wrote:
>>
On Wed, Apr 24, 2013 at 3:29 PM, Elliott Sprehn wrote:
> On Wed, Apr 24, 2013 at 11:11 AM, Dirk Pranke wrote:
>
>>
>>> ...
>>>
>>>
>> I think this raises two related questions, both of which would be helped
>> by concrete examples:
>>
&g
On Wed, Apr 24, 2013 at 10:30 AM, L. David Baron wrote:
> On Wednesday 2013-04-24 09:55 -0700, Darin Adler wrote:
> > On Apr 23, 2013, at 11:36 AM, Benjamin Poulain
> wrote:
> >
> > > The current mode works fine for some ref-tests but is really annoying
> for others. I would love to have a way t
On Tue, Apr 16, 2013 at 3:58 PM, Brent Fulgham wrote:
> Hi Daniel,
>
> I'm afraid I don't quite understand the nature of the change you are
> proposing:
>
> 1. Is it sufficient to supply the full path to the include files (e.g.,
> change "Foo.h" to "WebCore/html/Foo.h") to achieve these gains?
>
Hi all,
Those of you who are subscribed to blink-dev@ will see that I just sent out
a note entitled "Blink, Testing and the W3C", describing stuff I'm working
on to get the W3C tests running regularly as part of the layout tests. The
W3C has gotten to the point where they have many thousands of re
On Fri, Apr 12, 2013 at 10:44 PM, Filip Pizlo wrote:
>
> On Apr 12, 2013, at 10:43 PM, Ryosuke Niwa wrote:
>
> Perhaps we can come up with some JS API for shared memory & lock and
> propose it in TC39 or WebApps WG?
>
>
> I think that would be wonderful. Anyone else interested?
>
>
Feel free to
On Fri, Apr 12, 2013 at 1:50 PM, Filip Pizlo wrote:
> I'm curious: would you want to use ParallelArray, if you had the
> flexibility of building a different abstraction?
>
> I find ParallelArray to be an awkward abstraction to begin with. I like
> work queues and such. The whole idea that the o
On Wed, Apr 10, 2013 at 1:17 PM, Filip Pizlo wrote:
> I.e. if you believe that (A) is not a solvable problem, then this
> constitutes an argument against ParallelArrays, and not against inferring
> that a normal array should behave like a ParallelArray.
>
> I believe that there are a class of sol
On Thu, Apr 11, 2013 at 10:29 AM, Leandro Pereira wrote:
> dpranke,
>
>
> On 04/11/2013 02:12 PM, Dirk Pranke wrote:
>
>
>> I'm not sure how useful a suggestion this is, but ANTLR has a pretty
>> strong framework for separating parsing from code generation and
On Thu, Apr 11, 2013 at 9:51 AM, Darin Adler wrote:
> On Apr 11, 2013, at 5:02 AM, Thiago Marcos P. Santos
> wrote:
>
> > Would be great if both projects could share the same generators.
>
> The part that would be OK to share would be the parsing.
>
> The actual code generation needs to change a
On Wed, Apr 10, 2013 at 4:59 PM, Timothy Hatcher wrote:
>
> On Apr 10, 2013, at 6:32 PM, Ryosuke Niwa wrote:
>
> Can we rewrite CodeGenerator*.pm in Ruby or Python? I feel that the
> current code is very hard to understand and hack on. In particular we have
> CodeGenerator.pm and CodeGenerator
array
> is a number)
>return doHardcoreMap();
>
> // carry on doing regular map
> ...
>
>
> Understand that the parallel APIs have to do all of this as well, the only
> thing they lose is the "is everything a number" check
>
> --Oliver
>
>
> On Apr 10,
se it if
> possible", and what's possible is arbitrarily limited, and require a
> distinct type that isn't an array.
>
> --Oliver
>
> On Apr 10, 2013, at 12:37 PM, Dirk Pranke wrote:
>
>
>
>
> On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo w
On Wed, Apr 10, 2013 at 7:37 AM, Filip Pizlo wrote:
>
>
> On Apr 10, 2013, at 2:29 AM, "Pozdnyakov, Mikhail" <
> mikhail.pozdnya...@intel.com> wrote:
>
> >
> >
> >> Why not infer ParallelArrays automatically?
> > Sorry, did not get it. Could you please elaborate?
>
> Normal JS arrays. You use the
TestFailures, as I understand it, provides a summarize view of current tree
failures clustered by the changes that might have caused the failures, kind
of like garden-o-matic's initial page.
I believe I broke it at one point accidentally, asked if anyone used it,
and Ossy said that he did (there m
On Thu, Apr 4, 2013 at 12:50 PM, Geoffrey Garen wrote:
> To clarify:
>
> (1) The EWS bots are still running.
>
> (2) The mac and mac-wk2 EWS bots are running tests, and passing.
>
> (3) The cr-linux bots are running tests, and failing.
>
> If we're OK with item (3), we can go ahead with cleaning
On Thu, Apr 4, 2013 at 12:30 AM, Geoffrey Garen wrote:
> Hi folks.
>
> Since we no longer need to support the Chromium port, let's take the
> opportunity to streamline. Hopefully, this will make development easier and
> more coherent for everyone. Adam and Eric offered to do some of this
> cleanu
On Tue, Mar 26, 2013 at 1:42 PM, Alexis Menard wrote:
> On Tue, Mar 26, 2013 at 5:40 PM, Dirk Pranke wrote:
> > On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain
> > wrote:
> >>
> >> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke
> wrote
> >>>
On Tue, Mar 26, 2013 at 1:29 PM, Benjamin Poulain wrote:
> On Tue, Mar 26, 2013 at 1:20 PM, Dirk Pranke wrote
>
>> If we have consensus that we should just switch to paths relative to
>> Source (or maybe a couple different options), that would be (IMO) a big
>> win. It
On Tue, Mar 26, 2013 at 11:47 AM, Ryosuke Niwa wrote:
> On Tue, Mar 26, 2013 at 11:42 AM, Jarred Nicholls wrote:
>
>> On Tue, Mar 26, 2013 at 2:37 PM, Ryosuke Niwa wrote:
>>
>>> On Tue, Mar 26, 2013 at 11:21 AM, Daniel Bratell wrote:
>>>
Is this something that has been talked about in the p
On Thu, Mar 7, 2013 at 3:04 PM, Tony Gentilcore wrote:
>> I also got a little inspiration from the
>> import-w3c-performance-wg-tests that already exists. I followed a few of
>> their steps, but had to add a few layers to handle the added complexity of
>> the CSS test suites.
>
> Is there any way
On Thu, Mar 7, 2013 at 8:46 AM, Rebecca Hauck wrote:
> Hi Dirk & Everyone,
>
> Dirk, your question about this in IRC the other day was timely indeed.
>
> I've recently written a batch of tests for CSS Regions that I intend to
> submit to both the W3C and Webkit (and have planned more to come). Ra
On Tue, Feb 26, 2013 at 1:03 PM, Ryosuke Niwa wrote:
> On Tue, Feb 26, 2013 at 12:47 PM, Dirk Pranke wrote:
>>
>> On Tue, Feb 26, 2013 at 2:11 AM, Ryosuke Niwa wrote:
>> > On Tue, Feb 26, 2013 at 1:55 AM, Tom Hudson
>> > wrote:
>> >>
>>
On Tue, Feb 26, 2013 at 2:11 AM, Ryosuke Niwa wrote:
> On Tue, Feb 26, 2013 at 1:55 AM, Tom Hudson wrote:
>>
>> On Mon, Feb 25, 2013 at 10:34 PM, Ryosuke Niwa wrote:
>>>
>>> It should be fairly straight forward to create a tool that analyzes files
>>> changed in each commit and deduce which test
On Mon, Feb 25, 2013 at 2:05 PM, Ryosuke Niwa wrote:
> On Mon, Feb 25, 2013 at 1:39 PM, Dirk Pranke wrote:
>> Are you suggesting we should land a "failling" baseline in the meantime?
>
>
> No. I'm suggesting patch authors perform their due diligence and
On Mon, Feb 25, 2013 at 1:33 PM, Ryosuke Niwa wrote:
> On Mon, Feb 25, 2013 at 1:29 PM, Dirk Pranke wrote:
>>
>> On Mon, Feb 25, 2013 at 1:22 PM, Ryosuke Niwa wrote:
>> > On Mon, Feb 25, 2013 at 12:52 PM, Dirk Pranke
>> > wrote:
>> >
>> >>
On Mon, Feb 25, 2013 at 1:22 PM, Ryosuke Niwa wrote:
> On Mon, Feb 25, 2013 at 12:52 PM, Dirk Pranke wrote:
>>
>> On Mon, Feb 25, 2013 at 12:38 PM, Eric Seidel wrote:
>> > I've noticed as of late several different approaches being used when
>> >
On Mon, Feb 25, 2013 at 12:38 PM, Eric Seidel wrote:
> I've noticed as of late several different approaches being used when
> adding/changing LayoutTests which need rebaselining on other platforms.
>
> Obviously we cannot expect developers to test/rebaseline on all platforms
> before landing given
Hi Jason,
On http://trac.webkit.org/wiki there are a bunch of pages under
"Layout Tests" and "Performance Tests" that describe much of the
infrastructure. These days most of it is written in Python.
I don't know what projects Benjamin has in mind so I don't know if
that will match what he was ref
On Wed, Feb 13, 2013 at 11:33 PM, Benjamin Poulain wrote:
> On Wed, Feb 13, 2013 at 11:16 PM, Dirk Pranke wrote:
>>
>> > Those changes are not harmless. There are people monitoring tests
>> > results
>> > full time in order to keep WebKit in good shape.
On Wed, Feb 13, 2013 at 11:07 PM, Benjamin Poulain wrote:
> On Wed, Feb 13, 2013 at 9:38 PM, Dongsung Huang
> wrote:
>>
>> I like this idea. I cannot find any harm if we have this functionality.
>
>
> Those changes are not harmless. There are people monitoring tests results
> full time in order t
On Mon, Feb 11, 2013 at 7:44 PM, Benjamin Poulain wrote:
>
> I am sorry, I should have given more context.
>
> There is visibly a growing discontent in the community about the cost
> imposed from small ports. Just two weeks ago, there were 2 threads
> discussing the cost of "peripheral ports".
> I
On Mon, Feb 11, 2013 at 4:30 PM, Kevin Ollivier wrote:
>
> On Feb 11, 2013, at 3:33 PM, Dirk Pranke wrote:
>
>> On Mon, Feb 11, 2013 at 3:26 PM, Kevin Ollivier
>> wrote:
>>>
>>> On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote:
>>>
>
On Sun, Feb 10, 2013 at 1:30 AM, Ryosuke Niwa wrote:
> On Sat, Feb 9, 2013 at 5:35 PM, Dirk Pranke wrote:
>>
>> Perhaps -- and this is a tangent to this thread -- we could also
>> investigate ways of writing tests that did render pngs but told NRWT
&
On Mon, Feb 11, 2013 at 3:26 PM, Kevin Ollivier wrote:
>
> On Feb 11, 2013, at 2:01 PM, Martin Robinson wrote:
>
>> On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier
>> wrote:
>>
>>> Actually, it will, if anything, increase the workload. Because I use waf, I
>>> am able to use Python to auto-gene
On Mon, Feb 11, 2013 at 1:41 PM, Kevin Ollivier wrote:
> Hi Martin,
>
> On Feb 11, 2013, at 12:47 PM, Martin Robinson wrote:
>
>> On Mon, Feb 11, 2013 at 11:27 AM, Kevin Ollivier
>> wrote:
>>
>>> The project is not dead per-se, but it's true that it's not very active
>>> these days. Recently, I h
On Sat, Feb 9, 2013 at 1:57 AM, Benjamin Poulain wrote:
> On Sat, Feb 9, 2013 at 1:24 AM, wrote:
>>
>> I did not say they cannot be tested with the two methods suggested :) It's
>> more about a preference to move some of those decisions from the test
>> infrastructure to the test itself, but pot
On Fri, Feb 8, 2013 at 11:12 AM, Ryosuke Niwa wrote:
> On Fri, Feb 8, 2013 at 5:35 AM, wrote:
>>
>> we don't currently have a solution in webkit's test infrastructure for
>> testing animations "on the fly", or in general for testing multiple image
>> results in the same test.
>> (If this was disc
On Tue, Feb 5, 2013 at 3:34 PM, Tim Ansell wrote:
> On 6 February 2013 07:17, Dirk Pranke wrote:
>>
>> On Tue, Feb 5, 2013 at 9:46 AM, Martin Robinson
>> wrote:
>> > On Tue, Feb 5, 2013 at 9:28 AM, Adam Barth wrote:
>> >> Do you know how they got rid
I have looked at YAML off and on over the years, and I'm not sure that
it would be much of an improvement in this case.
I do believe that dropping the strict python syntax could make some
things easier to read. I don't have a fully-baked proposal in mind,
and I don't know what the perf hit would b
On Tue, Feb 5, 2013 at 9:46 AM, Martin Robinson wrote:
> On Tue, Feb 5, 2013 at 9:28 AM, Adam Barth wrote:
>> Do you know how they got rid of flakiness in their tests? We've spent
>> a bunch of effort fixing flaky tests (and in marking the remaining
>> flaky tests as flaky), but there's still a
The short answer is, you can't.
The fastest path is probably to get a working set of gyp files for the
apple mac wk2. I'm going to start working on this just to see how far
of we are (Adam's work from a year or two ago had JSC and WebCore
building, but wasn't too functional beyond that; even so, i
On Sun, Feb 3, 2013 at 9:20 PM, Maciej Stachowiak wrote:
>
> On Feb 3, 2013, at 8:18 PM, Mike Lawther wrote:
>
> Hi Maciej!
>
> On 31 January 2013 11:15, Maciej Stachowiak wrote:
>>
>> It's far simplest for us if:
>> (a) There is an Xcode project (or a Makefile) that builds the Mac port
>> check
On Thu, Jan 31, 2013 at 3:12 PM, Alexey Proskuryakov wrote:
>
> 31.01.2013, в 14:57, Dirk Pranke написал(а):
>
>>>>>> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
>>>>>> the number of exports for each port, because it wou
On Thu, Jan 31, 2013 at 2:52 PM, Alexey Proskuryakov wrote:
>
> 31.01.2013, в 14:45, Dirk Pranke написал(а):
>
>>>> One thing to keep an eye on with WEBCORE_EXPORT is that it can increase
>>>> the number of exports for each port, because it would export symb
On Thu, Jan 31, 2013 at 9:48 AM, Ryosuke Niwa wrote:
> On Thu, Jan 31, 2013 at 9:43 AM, Alexey Proskuryakov wrote:
>>
>>
>> 31.01.2013, в 0:17, Ryosuke Niwa написал(а):
>>
>>> I did it for WTF and JSC with kevino@.
>>> https://bugs.webkit.org/show_bug.cgi?id=72855
>>> I hope I had had time to ex
On Thu, Jan 31, 2013 at 9:14 AM, Patrick Gansterer wrote:
>
> Am 31.01.2013 um 17:17 schrieb Maciej Stachowiak:
>
>
> On Jan 31, 2013, at 1:56 AM, Patrick Gansterer wrote:
>
> Am 31.01.2013 um 10:37 schrieb Ryosuke Niwa:
>
> On Thu, Jan 31, 2013 at 1:17 AM, Jochen Eisinger
> wrote:
>>
>> Another
On Thu, Jan 31, 2013 at 12:10 PM, Patrick Gansterer wrote:
>
> Am 31.01.2013 um 21:07 schrieb Dirk Pranke:
>
>> On Thu, Jan 31, 2013 at 11:48 AM, Hugo Parente Lima
>> wrote:
>>> On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
>>>>
On Thu, Jan 31, 2013 at 11:48 AM, Hugo Parente Lima
wrote:
> On Wednesday, January 30, 2013 04:15:48 PM Maciej Stachowiak wrote:
>> On Jan 30, 2013, at 3:24 PM, Dirk Pranke wrote:
>> > On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo wrote:
>> >> Thanks for sharing thi
On Wed, Jan 30, 2013 at 4:15 PM, Maciej Stachowiak wrote:
>
> On Jan 30, 2013, at 3:24 PM, Dirk Pranke wrote:
>
>> On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo wrote:
>>> Thanks for sharing this.
>>>
>>> On Jan 30, 2013, at 1:28 PM, Eric Seidel w
On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo wrote:
> Thanks for sharing this.
>
> On Jan 30, 2013, at 1:28 PM, Eric Seidel wrote:
>
> I wish we only had one build system (it were easy to add/remove/move files).
>
> I believe changes like http://trac.webkit.org/changeset/74849 are an
> unhealthy
This is the output of the test bots, right? I'm guessing this is due
to (a) us running pixel tests and (b) not checking in the expected
failing baselines. If I ever get back to working on supporting
-failing.png, this could go down *a lot*.
Alternatively, we could just decide to check in the exist
The build cop / gardener / sheriff / whatever may not have local or
easy access to a bot that reproduces the problem ... rolling it out
might be the only feasible way to test in that case.
On Tue, Dec 11, 2012 at 2:20 PM, Oliver Hunt wrote:
>
> On Dec 11, 2012, at 2:17 PM, Peter Kasting wrote:
>
On Mon, Dec 10, 2012 at 1:30 AM, Jochen Eisinger wrote:
> Will the buildbots use ninja or the "native" build tools?
>
> My only concern is that we're catching problems with e.g. MSVS only after we
> roll the WebKit deps in chromium and one of the MSVS bots starts failing.
>
Eric is only suggestin
On Fri, Nov 16, 2012 at 7:42 AM, Julien Chaffraix
wrote:
>> Seconded. I also think only the one who submitted the patch can clear
>> the r? flag. Others should NOT do that, please, even you are a
>> reviewer. You can r- the patch if you believe it is bad.
>
> I disagree with that. You seem to thin
On Tue, Nov 13, 2012 at 5:06 PM, Eric Seidel wrote:
>
>
>
>
> Does seem pretty simple.
>
>
>
>
>
> is even shorter. :)
>
> I support getting rid of pixel tests. I suspect that some very dumb
> scripts could turn large chunks of these existing pixel-tests into
> ref-tests. I doubt that thos
On Tue, Nov 13, 2012 at 4:59 PM, Darin Adler wrote:
> On Nov 13, 2012, at 4:56 PM, Dirk Pranke wrote:
>
>> Wouldn't the fact that there are a large set of tests with the same result
>> be an argument *for* doing the iframe thing?
>
> The simple hand-coded gree
On Tue, Nov 13, 2012 at 4:33 PM, Darin Adler wrote:
> On Nov 13, 2012, at 4:01 PM, Dirk Pranke wrote:
>
>> It turns out that we have a reasonably large number of tests that produce
>> the exact same pixel results. On chromium-mac on 10.8, for example, there
>> are
Hi all,
Currently, we have ~8000 pixel tests in the tree, and ~800 reference
tests. I would like to make that first number a lot smaller.
It turns out that we have a reasonably large number of tests that
produce the exact same pixel results. On chromium-mac on 10.8, for
example, there are 2048 te
On Tue, Nov 13, 2012 at 1:04 PM, Tony Chang wrote:
> On Tue, Nov 13, 2012 at 12:09 PM, Glenn Adams wrote:
>>
>> On Tue, Nov 13, 2012 at 1:02 PM, Tony Chang wrote:
>>>
>>> I don't think we should support port specific ref test results. That
>>> kind of misses the point of using a ref test in the
On Tue, Nov 13, 2012 at 12:29 PM, Dirk Pranke wrote:
> On Tue, Nov 13, 2012 at 12:13 PM, Darin Adler wrote:
>> I’d prefer an directory-based overlay/inheritance approach to sharing
>> WebKit1- vs. WebKit2-specific expectations over in-file keywords. I’d like
>> to s
On Tue, Nov 13, 2012 at 12:13 PM, Darin Adler wrote:
> I’d prefer an directory-based overlay/inheritance approach to sharing
> WebKit1- vs. WebKit2-specific expectations over in-file keywords. I’d like to
> share more than just a central expectations file, so we could share expected
> results o
On Tue, Nov 13, 2012 at 12:16 PM, Tony Chang wrote:
> On Tue, Nov 13, 2012 at 12:04 PM, Darin Adler wrote:
>>
>> On Nov 13, 2012, at 12:02 PM, Tony Chang wrote:
>>
>> > I don't think we should support port specific ref test results. That
>> > kind of misses the point of using a ref test in the f
On Tue, Nov 13, 2012 at 12:02 PM, Tony Chang wrote:
> On Tue, Nov 13, 2012 at 11:35 AM, Dirk Pranke wrote:
>>
>> On Tue, Nov 13, 2012 at 11:29 AM, Glenn Adams wrote:
>> >
>> > On Tue, Nov 13, 2012 at 12:09 PM, Dirk Pranke
>> > wrote:
>> &
On Tue, Nov 13, 2012 at 11:59 AM, Raphael Kubo da Costa
wrote:
> Dirk Pranke writes:
>
>> So, it seems like WK1 and WK2 keywords might be useful. However, I
>> don't really want to add more divergence between ports, so it would be
>> nice to have everyone agree t
Hi all,
I occasionally get asked if the TestExpectations syntax supports a way
to distinguish different results for WebKit1 and WebKit2 via keywords.
We currently don't do this, and different ports have worked around
this in slightly different ways by using dedicated wk2-specific
TestExpectations
Right.
On Tue, Nov 13, 2012 at 11:36 AM, Darin Adler wrote:
> If we do add base test expectations shared by all platforms, please don’t put
> the file into LayoutTests/platform/generic; just put it at the top level of
> LayoutTests.
>
> -- Darin
> ___
On Tue, Nov 13, 2012 at 11:29 AM, Glenn Adams wrote:
>
> On Tue, Nov 13, 2012 at 12:09 PM, Dirk Pranke wrote:
>>
>> We don't currently support port-specific reftests (or at least, not
>> very well), and we certainly should be trying to minimize where they
>>
We don't currently support port-specific reftests (or at least, not
very well), and we certainly should be trying to minimize where they
occur. Perhaps we should discuss why you need them (in a separate
thread with a separate subject line)? It sounds like this largely has
to do with what features a
That said, I think adding a generic TestExpectations file is a good
idea; it would allow us to replace the "-disabled" convention for some
tests and allow us to skip tests that were temporarily crashing or
timing out everywhere (which *-expected or *-failing wouldn't help
with). It should be easy e
Also, I just landed a change (r134445) that should in theory auto-fix
this. Let me know if anyone is still seeing issues.
-- Dirk
On Tue, Nov 13, 2012 at 10:53 AM, Dirk Pranke wrote:
> % rm -fr Tools/Scripts/webkitpy/thirdparty/autoinstalled/.pylint.url \
>
> Tool
Peter Beverloo wrote:
> I'm seeing the same on the Android bot. What is the right way to fix this?
>
> Cheers,
> Peter
>
> On 13 Nov 2012 18:31, "Dirk Pranke" wrote:
>>
>> Argh, yeah. Unfortunately, I'm not sure what triggers this problem.
>>
Argh, yeah. Unfortunately, I'm not sure what triggers this problem.
It's easy enough to fix as soon as I can find someone w/ access to the
CQ.
-- Dirk
On Tue, Nov 13, 2012 at 7:50 AM, Adam Barth wrote:
> Sounds related to a recent changed made by dpranke.
>
> Adam
>
>
> On Tue, Nov 13, 2012 at 7
On Tue, Nov 6, 2012 at 11:58 PM, Žan Doberšek wrote:
> Hi WebKitties,
>
> I'd like to see in what scale the --test-list option in NRWT is used and
> whether anyone would object a change in how its usage behaves.
>
> Currently the test gathering takes into account any paths that were passed
> in th
ed.hu/TestFailures/ we use a very old copy
> of test failures and it still works fine.
>
> Dirk Pranke írta:
>
>> http://build.webkit.org/TestFailures/
>>
>> I think Adam Roben was working on this a year or so ago. It appears to
>> be broken at the moment (it'
http://build.webkit.org/TestFailures/
I think Adam Roben was working on this a year or so ago. It appears to
be broken at the moment (it's likely that I broke it, in fact), but
before I spend much time fixing it I thought I'd check.
I've never actually used it myself, so I'm not sure what all it
It is/was intended to be useful for quickly reviewing and rebaselining
a bunch of failures in a local (on-disk) checkout. It's been largely
unmaintained and ignored for quite some time in favor of
garden-o-matic.
I have recently started to land some patches that will make
garden-o-matic work local
That would still be a bug, and still new to me :)
-- Dirk
On Mon, Oct 29, 2012 at 4:04 PM, Dana Jansens wrote:
> On Mon, Oct 29, 2012 at 6:59 PM, Dirk Pranke wrote:
>> If that's the case, it's a bug, and new to me.
>
> The output was present on the results page, but it
If that's the case, it's a bug, and new to me.
-- Dirk
On Mon, Oct 29, 2012 at 3:42 PM, Terry Anderson wrote:
> I was actually noticing that some of the stderr output was missing from a
> failing test, not a passing one.
>
> Terry
>
>
> On Sun, Oct 28, 2012
On Mon, Oct 29, 2012 at 4:17 AM, Maciej Stachowiak wrote:
>
> On Oct 28, 2012, at 3:30 PM, Antti Koivisto wrote:
>
>> We could clear the cache between tests but run each test twice in a row.
>> Second run will then happen with deterministically pre-populated cache. That
>> would both make thing
On Mon, Oct 29, 2012 at 5:48 AM, Maciej Stachowiak wrote:
>
> On Oct 28, 2012, at 10:09 PM, Dirk Pranke wrote:
>
>>
>> On Sun, Oct 28, 2012 at 6:32 AM, Maciej Stachowiak wrote:
>>>
>>> I think the nature of loader and cache code is that it's ve
As Balazs said, we don't save the stderr output from tests that pass.
So, you don't have to crash, but your tests have to at least fail. It
wouldn't be hard to change that somehow ...
-- Dirk
On Sun, Oct 28, 2012 at 4:29 PM, Terry Anderson wrote:
> Hi webkit-dev,
>
> When I include fprintf(stder
On Sun, Oct 28, 2012 at 2:47 PM, Ryosuke Niwa wrote:
> On Sun, Oct 28, 2012 at 2:09 PM, Dirk Pranke wrote:
>>
>> > On Oct 26, 2012, at 11:11 PM, Ryosuke Niwa wrote:
>> >> I’m sure Antti, Alexey, and others who have worked on the loader and
>> >> othe
> On Oct 26, 2012, at 11:11 PM, Ryosuke Niwa wrote:
>> I’m sure Antti, Alexey, and others who have worked on the loader and other
>> parts of WebKit are happy to write those tests or list the kind of things
>> they want to test. Heck, I don’t mind writing those tests if someone could
>> make a
On Fri, Oct 26, 2012 at 3:02 PM, Ryosuke Niwa wrote:
> On Fri, Oct 26, 2012 at 2:57 PM, Dirk Pranke wrote:
>>
>> Perhaps a slight variant of this is that we can agree to make the
>> changes on the Chromium port to clear the cache (much like the Qt and
>> EFL por
On Fri, Oct 26, 2012 at 12:43 PM, Alexey Proskuryakov wrote:
>
> 26.10.2012, в 11:04, Antti Koivisto написал(а):
>
>> The reality is that this "test coverage" today shows up as flakiness and
>> so is ignored anyway, meaning we don't actually have useful coverage here.
>> Even when flakiness is in
1 - 100 of 395 matches
Mail list logo
