Hi Chris,
In layout test results, we make the latest Mac OS X version the rule, and
earlier versions the exception. Tiger will look for results in mac-tiger
first, then in mac-leopard, then in mac-snowleopard, then in mac, then
finally in cross-platform results. Leopard will begin the search
On Sun, Aug 23, 2009 at 12:23 PM, Dan Bernsteinm...@apple.com wrote:
On Aug 23, 2009, at 11:28 AM, Dirk Pranke wrote:
Hi Chris,
In layout test results, we make the latest Mac OS X version the rule, and
earlier versions the exception. Tiger will look for results in mac-tiger
first
On Thu, Aug 27, 2009 at 11:55 AM, Peter Kastingpkast...@google.com wrote:
On Wed, Aug 26, 2009 at 10:43 PM, David Levin le...@chromium.org wrote:
fwiw, I know that the check-webkit-style checks for trailing whitespace
(and I approved that change - sorry), but I think it should probably be
On Fri, Aug 28, 2009 at 1:37 PM, Ojan Vafaio...@chromium.org wrote:
Does anyone actually have any objections to Maciej's proposal?
I can imagine a discipline where we ensure that pending commit entries sit
in a designated file in your tree, are made by a tool much like
prepare-ChangeLog, are
On Thu, Oct 1, 2009 at 11:47 AM, Darin Adler da...@apple.com wrote:
On Oct 1, 2009, at 11:41 AM, Drew Wilson wrote:
I don't have an opinion about flakey tests, but flat-out-busted tests
should get skipped. Any thoughts/objections?
I object.
If a test fails on some platforms and succeeds on
FWIW, Chromium has version-specific diffs between XP and Vista/Win-7.
I don't remember off-hand how bad the diffs where, but comparing the
files in:
http://src.chromium.org/viewvc/chrome/trunk/src/webkit/data/layout_tests/platform/chromium-win/LayoutTests/fast/ruby
On Thu, Dec 3, 2009 at 11:36 AM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Dec 3, 2009 at 11:20 AM, Alexey Proskuryakov a...@webkit.org wrote:
On 02.12.2009, at 23:35, Maciej Stachowiak wrote:
One possible conservative modification to the rule is that if you have a
multi-block if ...
On Fri, Dec 4, 2009 at 9:39 AM, Adam Treat tr...@kde.org wrote:
I don't think we should be changing the style guide for anything besides
clarifications of currently unwritten rules. No matter how the fashion may
change or how developers may change. Changing the rules throws consistency
out
On Fri, Dec 4, 2009 at 1:52 PM, Adam Treat tr...@kde.org wrote:
On Friday 04 December 2009 04:22:57 pm Dirk Pranke wrote:
On Fri, Dec 4, 2009 at 9:39 AM, Adam Treat tr...@kde.org wrote:
I don't think we should be changing the style guide for anything besides
clarifications of currently
On Wed, Dec 9, 2009 at 1:02 PM, Maciej Stachowiak m...@apple.com wrote:
That's my thinking on the matter, perhaps others have other opinions.
Regards,
Maciej
+1. Very sound rules of thumb; please preserve them somewhere! FWIW,
these are basically the principles we followed at Oracle; the only
Somewhere in between the two of you I got lost.
Which the framework are you referring to? If you're referring to the
run-webkit-tests in WebKitTools/Scripts, you are correct that it has
no way to distinguish Safari/Win from Chromium/Win. This doesn't
really matter, since this framework isn't used
On Tue, Dec 22, 2009 at 10:31 AM, Darin Adler da...@apple.com wrote:
On Dec 21, 2009, at 6:14 PM, Dirk Pranke wrote:
Given all that, Darin, what were you suggesting when you said Let's fix
that?
Lets add a feature so something in the tests tree can indicate a Chromium
Windows result
On Tue, Dec 22, 2009 at 4:58 PM, Darin Adler da...@apple.com wrote:
On Dec 22, 2009, at 4:27 PM, Dirk Pranke wrote:
In the completely generic case, I hope we are not checking in incorrect
results.
We do intentionally check in incorrect results, fairly often. For example,
we’ve checked
On Thu, Jan 7, 2010 at 8:18 PM, Darin Fisher da...@chromium.org wrote:
On Thu, Jan 7, 2010 at 5:17 PM, Ojan Vafai o...@chromium.org wrote:
Do we really need a separate set of bots for pixel tests? Lets just turn
the pixel tests on for the current bots. The only thing stopping us doing
that is
Hi all,
I'm about to upload a patch that depends on third-party python code
(simplejson). The patch is a bunch of scripts that'll live under
WebKitTools/Scripts . Is there an appropriate place for the simplejson
code? In the absence of a better location, I'll probably check it in
under
On Thu, Jan 21, 2010 at 1:30 PM, Dirk Pranke dpra...@chromium.org wrote:
Hi all,
I'm about to upload a patch that depends on third-party python code
(simplejson). The patch is a bunch of scripts that'll live under
WebKitTools/Scripts . Is there an appropriate place for the simplejson
code
+1. Note that the pep8 package is available on pypi and easy_install's:
http://pypi.python.org/pypi/pep8/
-- Dirk
On Fri, Jan 22, 2010 at 12:33 PM, Adam Barth aba...@webkit.org wrote:
If you don't care about coding style, you can ignore this message.
We're starting to grow a bunch of python
Hi all,
Recently my computer has started failing
platform/mac/fast/loader/file-url-mimetypes-2.html ; for some reason
I'm getting a null pointer back instead of application/postscript
back from UTI inside
of WebCoreURLResponse:adjustMIMETypeIfNecessary, which results in the
code crawling up the
/Frameworks/LaunchServices.framework/Support/lsregister
-eric
On Wed, Feb 10, 2010 at 6:35 PM, Dirk Pranke dpra...@chromium.org wrote:
Hi all,
Recently my computer has started failing
platform/mac/fast/loader/file-url-mimetypes-2.html ; for some reason
I'm getting a null pointer back instead
On Fri, Feb 19, 2010 at 6:27 PM, Maciej Stachowiak m...@apple.com wrote:
I like the fasterness and think the new tool is a good basis for future
work. Maybe it would be good to do a feature set comparison, so we can make
sure our future layout test running tool does everything we need.
There
In case this was missed on the bug, Chromium Win uses 2.4, so, yes. At
least until we upgrade to 2.5, and there's no ETA or plan for that at
this time.
-- Dirk
On Thu, Mar 4, 2010 at 12:17 PM, Eric Seidel e...@webkit.org wrote:
I think we should ignore Tiger for the purposes of this discussion.
On Fri, Mar 19, 2010 at 7:06 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 19, 2010, at 5:30 PM, Ojan Vafai wrote:
Currently we do BUG12345 for Chromium bugs. There are no WebKit bugs listed.
How about we instead use CR12345 for Chromium bugs and WK12345 for WebKit
bugs?
Another
Hi all,
I have just landed a patch that updates a bunch of incorrect image
checksums, and adds all of the currently failing pixel tests to the
test_expectations.txt file in LayoutTests/platform/mac.
If you take a look at that file you'll see that they are marked with a
BUG36620 string and the
On Fri, Apr 9, 2010 at 4:43 PM, Brady Eidson beid...@apple.com wrote:
On Apr 9, 2010, at 4:41 PM, Alexey Proskuryakov wrote:
On 09.04.2010, at 16:32, Brady Eidson wrote:
- Exposes more flaky tests due to running tests in a non-deterministic
order.
This sounds like a pro to me.
On Fri, Apr 9, 2010 at 5:03 PM, Yuzo Fujishima y...@google.com wrote:
I don't see /tmp/layout-test-results. Where are the errors logged?
/tmp/run-chromium-webkit-tests-layout-test-results/*
This was done intentionally at the time to not collide with
run-webkit-tests, but it should be changed
On Tue, Apr 13, 2010 at 11:54 AM, Ojan Vafai o...@chromium.org wrote:
On Mon, Mar 1, 2010 at 7:53 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 1, 2010, at 6:46 PM, Ojan Vafai wrote:
On Mon, Mar 1, 2010 at 6:40 PM, Maciej Stachowiak m...@apple.com wrote:
On the one hand, it's good to
Hi all,
As I'm sure the discussions in the webkit meeting over the past two
days made clear, it looks like most of our non-C++ code is getting
written in Python. Back in January, Adam Barth posted this thread [1]
where I thought it was agreed we would attempt to follow PEP 8 ([2] -
the standard
On Wed, Apr 14, 2010 at 2:13 PM, Eric Seidel e...@webkit.org wrote:
Question: Do SVN users wish to have webkit-patch be
current-working-directory aware?
[snip]
The propose change will make webkit-patch inconsistent between VCS
tools, but consistent with the users choice of SVN vs. Git. Is
On Wed, Apr 14, 2010 at 9:49 PM, Kalle Vahlman kalle.vahl...@gmail.com wrote:
2010/4/15 Dirk Pranke dpra...@chromium.org:
On Wed, Apr 14, 2010 at 2:13 PM, Eric Seidel e...@webkit.org wrote:
Question: Do SVN users wish to have webkit-patch be
current-working-directory aware?
[snip
I think having longer lines of code hurts readability. There is lots
of typographic evidence
to back this up ( e.g.
http://webtypography.net/Rhythm_and_Proportion/Horizontal_Motion/2.1.2/.
Of
course, the typographic commentary applies to text rather than code,
and most text isn't indented,
but I
On Tue, Jun 8, 2010 at 3:21 PM, Peter Kasting pkast...@google.com wrote:
On Tue, Jun 8, 2010 at 3:17 PM, Eric Seidel e...@webkit.org wrote:
Has anyone spent any time trying to reduce the number of includes in
WebCore? I know we have:
Hi all,
Is the Git repository stuck / behind / borked? It doesn't seem to have
any revisions after 61865.
-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
I have been thinking along these lines as well. I'm not sure how
relevant touching existing lines of code is versus just other people
who have hacked on the file at all or who have hacked on other files
in the same directory (i.e., you'd need to address new code and new
files, too). I think some
On Thu, Jul 29, 2010 at 10:59 AM, Darin Adler da...@apple.com wrote:
Hi folks.
WebKit regression tests are in a directory named LayoutTests. The object the
tests uses to do special test-specific operations is layoutTestController.
Both of these names are unwanted baggage, left over from
I thought Sputnik came from Microsoft?
-- Dirk
On Tue, Aug 10, 2010 at 11:51 AM, Eric Seidel e...@webkit.org wrote:
Chromium skips it (and if I remember correctly, they commissioned it?)
Why do we want to be running these 6000 tests and slowing down our
builds. I was talking with jamesr,
multithreading deadlocking issues we've
seen.
-- Dirk
On Tue, Aug 31, 2010 at 12:26 PM, Dirk Pranke dpra...@chromium.org wrote:
I think generally most scripts are written in Python nowadays, and we
have a large legacy of perl scripts that are getting ported over.
bdash mentions in the bug
Hi Sam,
Did you see the reply I sent on this thread? There are actually decent
reasons to rewrite the code into Python, to simplify and speed up the
new-run-webkit-tests implementation. Given that, do you still object
to the patch landing (since the work has already been done)?
-- Dirk
On Wed,
Keeping it off by default until it has some mainstream acceptance
seems like a bit of a self-defeating policy for new features; is this
often done in WebKit?
-- Dirk
On Mon, Oct 4, 2010 at 10:12 PM, Maciej Stachowiak m...@apple.com wrote:
Since a ping has been controversial in the past (for
Jeremy is correct; the Chromium port has seen real regressions that
virtually no concept of a fuzzy match that I can imagine would've
caught.
new-run-webkit-tests doesn't currently support the tolerance concept
at al, and I am inclined to argue that it shouldn't.
However, I frequently am wrong
Ojan
On Fri, Oct 8, 2010 at 1:03 PM, Simon Fraser simon.fra...@apple.com wrote:
I think the best solution to this pixel matching problem is ref tests.
How practical would it be to use ref tests for SVG?
Simon
On Oct 8, 2010, at 12:43 PM, Dirk Pranke wrote:
Jeremy is correct; the Chromium
I'm starting to hate mock tests.
It's a bug. The fix is one line, but it might be delayed a bit while I
figure out a better way to test this. Mihai's workaround should tide
you over.
Sorry for the inconvenience,
-- Dirk
On Fri, Nov 19, 2010 at 7:47 AM, W. James MacLean
wjmacl...@chromium.org
Really? XCode isn't installed on the default Mac OS X install. I mean,
sure, the easier it is to get started and all, but that's hardly a big
hurdle.
-- Dirk
On Tue, Nov 30, 2010 at 3:15 PM, Eric Seidel e...@webkit.org wrote:
I'm not sure git can be the default way to checkout webkit until it's
If you don't ever run new-run-webkit-tests, you can stop reading.
If you do, then it might interest you to know that by popular demand
(okay, two people), I have added a line that prints the actual command
line used to invoke DumpRenderTree as part of the config output, e.g.:
$
I think this is a great idea. I have one suggestion and one
potentially large, derailing comment :)
Suggestion: in theory, fixing the render tree output shouldn't change
the pixel output. So, I would suggest that as many ports as possible
should be running (up-to-date) pixel tests when do have
Hi all,
In the course of working on new-run-webkit-tests, I find myself
needing to implement a variant of some code normally provided in the
Python standard library. Attempting to implement this in a clean room
manner will be painful and nonobvious, so I'd just as soon just
cutpaste the relevant
, we've used autoinstall to make use of library code that
doesn't have a compatible license, assuming that the library is freely
distributed on the Internet. However, that approach does not seem
appropriate for this particular use.
Adam
On Tue, Jan 18, 2011 at 3:59 PM, Dirk Pranke dpra
to
the point where I branched off master. Then use -g option.
On Jan 27, 2011, at 1:55 PM, Dirk Pranke wrote:
I think that webkit-patch -g can only refer to checked in versions,
and not the current checkout or staged build. It may also be the case
that webkit-patch has bugs related to finding
Hi all,
Have there been any threads or blog posts in the past over an
appropriate level of comments in the code? A brief search of the
Google and the list archives didn't really turn up anything.
From what I've seen, code in WebKit is much less commented than most
if not all large projects I've
I agree with all of the sentiments below, except for possibly one or two cases.
Namely, sometimes you write code where the what is not obvious. In
that situation, it may not be possible to change the code to make it
more obvious, because you are bound by contract. For example, suppose
you are
-document tests and make them very hard to maintain.
Lastly, I volunteer to take whatever wisdom is offered up on this
thread and aggregate it onto the Wiki ...
-- Dirk
On Thu, Jan 27, 2011 at 4:38 PM, Dirk Pranke dpra...@chromium.org wrote:
I agree with all of the sentiments below, except
In short, what Adam just said :)
In long(-er),
Your annoyance is quite understandable. I won't go into the reasons
for the delay, but the major technical reason has been fixed, finally.
These are the issues that I am aware of that remain:
* There are GTK bots that run NRWT as well as the
On Fri, Mar 18, 2011 at 2:29 PM, Mark Rowe mr...@apple.com wrote:
On 2011-03-18, at 14:22, Dirk Pranke wrote:
In short, what Adam just said :)
In long(-er),
Your annoyance is quite understandable.
Not annoyed, just confused by the existence of two
similar-but-subtly-different tools
On Wed, Mar 23, 2011 at 1:33 PM, David Levin le...@google.com wrote:
On Wed, Mar 23, 2011 at 12:17 PM, Adam Barth aba...@webkit.org wrote:
$ time git svn rebase
[... update my working copy from changes during lunch (four revisions)
...]
real 1m10.316s
user 0m8.194s
sys
Hi Brent,
I definitely agree that gyp is rather undocumented and kind of hard to
use. It's nowhere near the level of documentation of CMake, let alone
Xcode or GNU makefiles. Hopefully we can fix this in the near future.
That said, I'd be kind of surprised if cmake was already installed on
your
Hi all,
I am getting increasingly close to having new-run-webkit-tests running
correctly on the apple mac platform with full feature parity to
old-run-webkit-tests. (And, of course, it continues to run on all of
the Chromium bots as well). I am hoping to close the remaining issues
blocking full
On Wed, Apr 6, 2011 at 9:01 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 6, 2011, at 7:39 PM, Dirk Pranke wrote:
There are also a number of bugs currently listed as blocking that I
don't think really qualify. Unless told otherwise, I'm plannning to
remove the blocking flag from
Hi Maciej,
Thanks for clarifying your concerns. I will address them a little
out-of-order, because I think we probably agree on the important
things even if we disagree on the less-important or more theoretical
things.
First, as far as the future discoveries go, I agree we should try to
fix as
Hi Brent,
I think we should consider sharding the PNG's out into different archives.
I think another option would be to make a concerted effort to convert
some of these tests into reftests. It would be interesting for someone
to sample some of platform-specific tests and see how many could be
Here is a link to the NRWT bot running the Mac Leopard Release build:
http://build.webkit.org/results/Leopard%20Intel%20Release%20(NRWT)/r85644%20(142)/results.html
-- Dirk
On Tue, May 3, 2011 at 2:14 PM, Eric Seidel e...@webkit.org wrote:
Is that a good example? It doesn't remind me much of
Reftests?
-- Dirk
On Mon, Jun 6, 2011 at 11:00 PM, Hao Zheng zheng...@chromium.org wrote:
Unfortunately, even for SVG or images, different drawing
implementations will lead to different pixel results. Like this Skia
bug, http://code.google.com/p/skia/issues/detail?id=179 , which caused
most
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 8, 2011 at 5:13 PM, Darin Fisher
I had one of the bugs in this state, and I had not landed it because I
had been meaning to do some more testing to see if it caused
regressions. However, someone CQ+'ed it over the weekend, and it was
committed w/o my involvement. Fortunately, it did not appear to cause
massive regressions
Can you expand a bit more on using libxml2 exposes its own share of problems?
-- Dirk
On Tue, Jun 28, 2011 at 6:12 PM, Jeffrey Pfau jp...@apple.com wrote:
Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming
XML. However, QtXml isn't always available, and using libxml2
Sounds good to me, except I wonder how often you'd get Fixed bug
where where XXX is the bug summary.
-- Dirk
On Thu, Jun 30, 2011 at 1:28 PM, Adam Roben aro...@apple.com wrote:
I'd like to propose that WebKit commit messages start with a one-line summary
of the change.
This change
-failing should trump -expected.
I also like Ojan's idea.
I do not believe that -expected should be used to track incorrect
results, because that makes understanding how tests are supposed to
run dependent on the knowledge of the bug database as well.
I think Ryosuke's concern is legitimate,
:
So then you'd never want both in the same directory, doing so shoudl
be an error?
-eric
On Fri, Jul 1, 2011 at 2:18 PM, Ojan Vafai o...@chromium.org wrote:
What Dirk said. It's just adding another layer into the fallback order.
On Fri, Jul 1, 2011 at 1:54 PM, Dirk Pranke dpra
On Fri, Jul 1, 2011 at 2:38 PM, Darin Adler da...@apple.com wrote:
On Jul 1, 2011, at 1:54 PM, Dirk Pranke wrote:
I do not believe that -expected should be used to track incorrect results
A huge percentage of our expected results are incorrect in one sense or
another. It’s a massive project
On Fri, Jul 1, 2011 at 3:24 PM, Darin Fisher da...@chromium.org wrote:
On Fri, Jul 1, 2011 at 3:04 PM, Darin Adler da...@apple.com wrote:
On Jul 1, 2011, at 2:54 PM, Dirk Pranke wrote:
Does that apply to -expected.txt files in the base directories, or just
platform-specific exceptions
want, no?
Obviously, it wouldn't help the thousands of -expected files that are
wrong but at least it could keep things from getting worse.
How to correct thousands of the wrong files is really a big problem...
On Sat, Jul 2, 2011 at 6:37 AM, Dirk Pranke dpra...@chromium.org wrote:
On Fri
On Tue, Jul 5, 2011 at 1:21 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Jul 5, 2011 at 12:29 PM, Dirk Pranke dpra...@chromium.org wrote:
The problem with your idea is I think what brought this idea up in the
first place: if you just track that the test is failing using
On Tue, Jul 5, 2011 at 1:53 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Jul 5, 2011 1:26 PM, Dirk Pranke dpra...@chromium.org wrote:
However, we can do the same with the existing testing framework since we
can
associate a test with a bug by adding a line like this:
BUGWK? my-test.html
On Tue, Jul 5, 2011 at 5:40 PM, Dirk Pranke dpra...@chromium.org wrote:
On Tue, Jul 5, 2011 at 5:16 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, Jul 5, 2011 at 4:51 PM, Dirk Pranke dpra...@chromium.org wrote:
On Tue, Jul 5, 2011 at 1:53 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Jul 5
On Wed, Jul 6, 2011 at 9:04 AM, Xan Lopez x...@gnome.org wrote:
On Wed, Jul 6, 2011 at 5:58 PM, Adam Roben aro...@apple.com wrote:
On Jul 6, 2011, at 11:53 AM, Adam Roben wrote:
Now that more and more ports are switching to NRWT, it would be great for
someone to explain what the best
On Tue, Jul 5, 2011 at 6:12 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Jul 5, 2011 at 5:40 PM, Dirk Pranke dpra...@chromium.org wrote:
I keep hearing that the syntax is excessively complicated. It's a
pretty simple syntax, but even you think that it is complicated, but
in what way
On Thu, Jul 7, 2011 at 10:27 AM, Tony Chang t...@chromium.org wrote:
One difference with the chromium port is that we try to use a single
test_expectations.txt that covers all platforms and OS versions (win xp,
vista, 7, mac leopard, snow leopard, linux 32, 64, GPU vs CPU, Debug vs
Release).
Hi all,
I've started adding a bunch of information on NRWT to the wiki. Some
of the pages are stubs at the moment, but the test_expectation page is
pretty complete. Other pages will be filled in over today and
tomorrow. Those of you who are also familiar with the functionality,
feel free to
On Mon, Jul 11, 2011 at 11:52 AM, Dirk Pranke dpra...@chromium.org wrote:
On Mon, Jul 11, 2011 at 10:46 AM, Adam Barth aba...@webkit.org wrote:
On Mon, Jul 11, 2011 at 12:30 AM, Maciej Stachowiak m...@apple.com wrote:
On Jul 10, 2011, at 12:11 PM, Adam Barth wrote:
On Sun, Jul 10, 2011 at 12
On Tue, Jul 12, 2011 at 8:05 PM, Dirk Pranke dpra...@chromium.org wrote:
On Mon, Jul 11, 2011 at 11:52 AM, Dirk Pranke dpra...@chromium.org wrote:
On Mon, Jul 11, 2011 at 10:46 AM, Adam Barth aba...@webkit.org wrote:
On Mon, Jul 11, 2011 at 12:30 AM, Maciej Stachowiak m...@apple.com wrote
On Tue, Jul 12, 2011 at 9:01 PM, Adam Barth aba...@webkit.org wrote:
On Tue, Jul 12, 2011 at 8:34 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Jul 12, 2011 at 8:19 PM, Dirk Pranke dpra...@chromium.org wrote:
Hum. I take it back ... it still wouldn't be a tree, since
chromium-mac-leopard
On Tue, Jul 12, 2011 at 10:01 PM, Dirk Pranke dpra...@chromium.org wrote:
On Tue, Jul 12, 2011 at 9:01 PM, Adam Barth aba...@webkit.org wrote:
On Tue, Jul 12, 2011 at 8:34 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Jul 12, 2011 at 8:19 PM, Dirk Pranke dpra...@chromium.org wrote:
Hum. I
On Wed, Jul 13, 2011 at 1:28 PM, Adam Barth aba...@webkit.org wrote:
On Wed, Jul 13, 2011 at 1:21 PM, Dirk Pranke dpra...@chromium.org wrote:
On Tue, Jul 12, 2011 at 10:01 PM, Dirk Pranke dpra...@chromium.org wrote:
On Tue, Jul 12, 2011 at 9:01 PM, Adam Barth aba...@webkit.org wrote:
On Tue
On Mon, Aug 22, 2011 at 3:45 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Aug 22, 2011 at 3:35 PM, James Robinson jam...@google.com wrote:
On Mon, Aug 22, 2011 at 3:24 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Aug 22, 2011 at 3:18 PM, James Robinson jam...@google.com wrote:
On Mon,
On Mon, Aug 22, 2011 at 3:24 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Aug 22, 2011 at 3:18 PM, James Robinson jam...@google.com wrote:
On Mon, Aug 22, 2011 at 3:07 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Aug 22, 2011 at 3:02 PM, James Robinson jam...@google.com wrote:
On Mon,
On Fri, Sep 9, 2011 at 10:17 AM, Geoffrey Garen gga...@apple.com wrote:
I also think it’s good to have a WebKit-specific or specific-enough word in
script names when possible so you can have the scripts in your path even
when not working on WebKit. That’s why run-webkit-tests has the word
Maybe we need a webkit-port-maintainers@ list that one could easily cc
rather than trying to add people by hand?
-- Dirk
On Wed, Sep 14, 2011 at 1:00 PM, Patrick Gansterer par...@paroga.com wrote:
Hi,
I completely agree with all of your points. I also don't think that it's
your task to keep
On Thu, Sep 15, 2011 at 12:17 PM, Geoffrey Garen gga...@apple.com wrote:
On Sep 14, 2011, at 1:02 PM, Dirk Pranke wrote:
Maybe we need a webkit-port-maintainers@ list that one could easily cc
rather than trying to add people by hand?
Sounds helpful. Not sure exactly how it would work, though
On Thu, Oct 20, 2011 at 8:16 AM, Simon Fraser simon.fra...@apple.com wrote:
On Oct 20, 2011, at 1:04 AM, Ryosuke Niwa wrote:
On Wed, Oct 19, 2011 at 2:04 PM, Elliot Poger epo...@google.com wrote:
Here are the various approaches I can think of... what's the
Hive-Mind-Approved approach?
On Fri, Oct 21, 2011 at 12:59 PM, Eric Seidel e...@webkit.org wrote:
I would recommend all ports who haven't switched to ORWT do so.
You presumably mean that you recommend all ports who haven't switched
to *NRWT* do so :)
Also, I would like to see us start working on turning on parallel
tests
On Fri, Nov 4, 2011 at 1:32 PM, Hayato Ito hay...@chromium.org wrote:
Could you clarify why we have to need to modify DRT if we have Link Element
approach?
I guess one of the reasons is the performance. It might be better that we
use DRT to parse and extract reference links from HTML since
On Fri, Nov 4, 2011 at 10:56 AM, Ryan Leavengood leaveng...@gmail.com wrote:
Actually regarding the 42,000 changesets: these have all come in the
last year and a half (), and are almost as many changesets as ever
came before in the current WebKit repo. This is exponential growth!
How is a
On Fri, Nov 4, 2011 at 3:21 PM, Alan Stearns stea...@adobe.com wrote:
Once we figure out how to support imported reftests, we should be
encouraging people to use reftests internally (even for tests we have no
intention of pushing to the W3C) instead of dumprendertree or pixel tests
(where
On Tue, Nov 8, 2011 at 12:24 PM, Adam Barth aba...@webkit.org wrote:
On Tue, Nov 8, 2011 at 12:20 PM, Tony Chang t...@chromium.org wrote:
On Tue, Nov 8, 2011 at 12:00 PM, Elliot Poger epo...@chromium.org wrote:
Perhaps I should approach this from a different angle:
What is the recommended
The Chromium Leopard bots are still using 2.5 as far as I know. Unless
move forward includes you upgrading those bots, you shouldn't remove
the 2.5 compat code until they have been upgraded. (If you are signing
up to upgrade them, then great!).
-- Dirk
On Thu, Nov 17, 2011 at 2:24 PM, Eric Seidel
On Thu, Nov 17, 2011 at 2:45 PM, Adam Barth aba...@webkit.org wrote:
On Thu, Nov 17, 2011 at 2:42 PM, Dirk Pranke dpra...@chromium.org wrote:
The Chromium Leopard bots are still using 2.5 as far as I know. Unless
move forward includes you upgrading those bots, you shouldn't remove
the 2.5
On Thu, Nov 17, 2011 at 5:06 PM, Eric Seidel e...@webkit.org wrote:
On Thu, Nov 17, 2011 at 4:53 PM, Tony Chang t...@chromium.org wrote:
new-run-webkit-httpd imports common/host.py which imports lots of stuff
including common/net/buildbot.py, which will fail to import the json module.
I would
Hi all,
You may be aware that some people are working on getting w3c-style
reftests to work in our infrastructure (using new-run-webkit-tests).
The few existing reftests we have follow a naming convention of
testname-expected.html or testname-expected-mismatch.html. This
makes it easy to
On Thu, Dec 1, 2011 at 2:08 PM, Ryosuke Niwa rn...@webkit.org wrote:
Do we know if Mozilla's test suite follow such a convention? Given we
already have tables/mozilla,
there appears be an interest to import some Mozilla tests to WebKit.
e.g. I'm planning to import Mozilla's
reftests for
On Fri, Dec 2, 2011 at 3:55 PM, Eric Seidel e...@webkit.org wrote:
run-webkit-tests is moving to parallell testing by default (this weekend)
I just moved Mac this afternoon. The SnowLeopard bot went from a 1 hr
4 min (!?!) cycle time, to 38 min (still !?!).
We never implemented the general way of marking subdirectories as
needing to run serially, but it would be easy to do if we needed to
[the 'http' dirs are still special-cased in the code].
There is code now (landed a few months ago) to control how many http
tests run in parallel separately from
On Mon, Dec 5, 2011 at 1:53 PM, Eric U er...@google.com wrote:
On Mon, Dec 5, 2011 at 1:01 PM, Dirk Pranke dpra...@chromium.org wrote:
We never implemented the general way of marking subdirectories as
needing to run serially, but it would be easy to do if we needed to
[the 'http' dirs
1 - 100 of 344 matches
Mail list logo
