On Wed, Apr 18, 2012 at 10:40 AM, Milian Wolff milian.wo...@kdab.com wrote:
Hey all,
I'm working on isPrinting() support for the Qt port and noticed that if I do
something like this:
./Tools/Scripts/run-webkit-tests -p LayoutTests/printing/
Then I get lots of failures due to missing image
On Thu, Apr 12, 2012 at 12:36 AM, Ryosuke Niwa rn...@webkit.org wrote:
On Thu, Apr 12, 2012 at 12:12 AM, Osztrogonac Csaba o...@inf.u-szeged.hu
wrote:
I ran into a failing reftest and I didn't find a proper way for handling
it.
fast/multicol/cell-shrinkback.html is a new reftest introduced
I think this is great; I've been meaning to spend some time on the
apple win port trying to fix the remaining bugs holding up the switch
to NRWT, but the fact that the apple win port still uses VS2005 is
definitely an impediment (yes, I can probably just pull the binaries
down from a bot for my
PM, Jacob Goldstein jac...@adobe.com
wrote:
Isn't the goal of writing a ref test that it is not platform specific?
From: Ryosuke Niwa rn...@webkit.org
Date: Thu, 12 Apr 2012 12:29:42 -0700
To: Ojan Vafai o...@chromium.org
Cc: Dirk Pranke dpra...@chromium.org, WebKit Development
webkit-dev
, instead of
just checking out the whole repo?
-- Dirk
- Mark
From: webkit-dev-boun...@lists.webkit.org [
webkit-dev-boun...@lists.webkit.org] on behalf of Dirk Pranke [
dpra...@chromium.org]
Sent: Thursday, April 12, 2012 2:06 PM
To: Patrick Gansterer
On Apr 12, 2012 2:25 PM, Ojan Vafai o...@chromium.org wrote:
On Thu, Apr 12, 2012 at 2:18 PM, Dirk Pranke dpra...@chromium.org wrote:
On Apr 12, 2012 1:53 PM, Ryosuke Niwa rn...@webkit.org wrote:
My suggestion is to try to make it platform-independent but it's
significantly harder than
On Wed, Apr 11, 2012 at 12:25 PM, Robert Hogan li...@roberthogan.net wrote:
On Wednesday 11 April 2012 20:11:23 Alan Stearns wrote:
The best way to judge whether a reference result is correct is to submit
the result to the W3C CSS 2.1 test suite and have it reviewed. The only
way this test
On Wed, Apr 11, 2012 at 12:31 PM, Robert Hogan li...@roberthogan.net wrote:
On Wednesday 11 April 2012 20:27:23 Dirk Pranke wrote:
What does clean up the existing folder entail?
Just move any -expected.html file out of there and generate pixel results.
Or move the test and its
use run-webkit-tests (or attempt to pull the results from the trybots
by hand). You cannot pull new baselines from the try bots using
rebaseline.py.
-- Dirk
On Wed, Apr 11, 2012 at 3:26 PM, Tony Payne tpa...@chromium.org wrote:
Is the best way to do that to use run_webkit_tests to generate a
On Fri, Mar 9, 2012 at 2:49 PM, Sam Weinig wei...@apple.com wrote:
On Mar 7, 2012, at 4:41 PM, Ojan Vafai wrote:
I just did a first pass a greening the Chromium Lion
bot: http://trac.webkit.org/changeset/110096. Of these hundreds of tests,
~99% of them are perfect candidates for being
On Wed, Apr 11, 2012 at 3:46 PM, Dirk Pranke dpra...@chromium.org wrote:
On Fri, Mar 9, 2012 at 2:49 PM, Sam Weinig wei...@apple.com wrote:
On Mar 7, 2012, at 4:41 PM, Ojan Vafai wrote:
I just did a first pass a greening the Chromium Lion
bot: http://trac.webkit.org/changeset/110096
On Wed, Apr 11, 2012 at 4:00 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Apr 11, 2012 at 3:52 PM, Jacob Goldstein jac...@adobe.com wrote:
+1 on not introducing new pixel tests and allowing someone other than the
test author to create the -expected file.
We may also be able to streamline
On Wed, Apr 11, 2012 at 4:15 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Apr 11, 2012 at 4:05 PM, Jacob Goldstein jac...@adobe.com wrote:
Don't people currently fix tests that are failing and that they didn't
author?
We don't fix imported tests if you meant modifying html files, etc...
This change has been made.
I will note, however, that the fallback order for all WebKit ports is
still not a tree :( The webkit2 ports will use results in platform/wk2
in addition to their non-wk2 fallback paths :(
-- Dirk
On Mon, Mar 26, 2012 at 12:00 PM, Ojan Vafai o...@chromium.org wrote:
sure they
would appreciate it. Otherwise, treat it the same way you would treat
any other change ... It will just be more painful :).
-- Dirk
Tony
[1] http://www.w3.org/Graphics/Color/sRGB.html
On Wed, Apr 11, 2012 at 3:36 PM, Dirk Pranke dpra...@chromium.org wrote:
use run-webkit-tests
I agree with Ojan. It's clear that there are arguments for both
approaches and my initial note did not address all the situations that
come up. I will write up something further and put it on the wiki.
I will also continue mulling over what sorts of changes to the tools
we could do in the short
Hi all,
The latest thread on run-bindings-tests has reminded me that a few
months ago we discussed having one top-level script that would run
*all* of the tests in the repository (perl tests, python tests,
new-run-webkit-tests, unit tests, run-bindings-tests, etc.), but as
far as I know, no one
Hi all,
Recently I've noticed more people making changes and adding test
failure suppressions to various ports' test_expectations.txt files.
This is great!
However, I don't think we have an agreement over what the best
practices are here, so I thought I'd list out what I thought they
were, and
On Mon, Apr 9, 2012 at 3:02 PM, James Robinson jam...@google.com wrote:
3) Don't use test_expectations.txt to suppress failures across a
single cycle of the bot, just so you can gather updated baselines
without the tree going red. While it might seem that you're doing tree
maintainers a favor,
On Mon, Apr 9, 2012 at 3:50 PM, Julien Chaffraix jchaffr...@webkit.org wrote:
In my ideal world, you would be able to get updated baselines *prior*
to trying to land a patch. This is of course not really possible today
for any test that fails on multiple ports with different results, as
it's
On Wed, Mar 21, 2012 at 2:33 PM, Maciej Stachowiak m...@apple.com wrote:
On Mar 21, 2012, at 2:29 PM, Timothy Hatcher wrote:
Lately I have observed more and more and more changes going into WebKit that
lack any details about why a particular change was made. It is intended that
the ChangeLog
On Wed, Mar 21, 2012 at 4:18 PM, Timothy Hatcher timo...@apple.com wrote:
On Mar 21, 2012, at 3:14 PM, Dirk Pranke wrote:
I think this is a reasonable suggestion, but I don't agree with it :).
I would prefer that we try to get good changelogs through culture and
convention rather than
I have a vague recollection that we've instrumented the chromium tools
so that we can tell who is using git vs. svn and (I think) from which
platforms. If there's interest, I can dig up what we did and see if we
can use the same technique on our tools.
-- Dirk
On Sat, Mar 10, 2012 at 12:49 PM,
On Thu, Mar 8, 2012 at 7:52 PM, Ami Fischman fisch...@chromium.org wrote:
Hi webkittens,
The over-all question: how should webkit libraries declare which symbols
they export?
The trigger for the question: as described in bug 80062, the chromium
shared-library-based build links test code into
On Thu, Mar 8, 2012 at 9:22 AM, Geoffrey Garen gga...@apple.com wrote:
Rather than asking for a switch to git by fiat, why not improve git and our
git-related infrastructure to the point where people choose to switch
naturally?
The fact that many valuable contributors choose not to use git is
Hi all,
I have just landed a change to webkit-patch that tweaks the -g
handling slightly as a result of the discussion in the thread from
last week. The patch in question is in
https://bugs.webkit.org/show_bug.cgi?id=76958 .
In short, I have added a new UPSTREAM ref that will resolve to the
On Thu, Mar 8, 2012 at 2:10 PM, Maciej Stachowiak m...@apple.com wrote:
It seems like there are a couple of different issues here that affect how we
do version control. Currently we have an SVN primary repository, some
contributors use SVN, and others use git via git-svn.
It seems like there
On Thu, Mar 8, 2012 at 2:37 PM, David Barr davidb...@google.com wrote:
The monotonic labels that Ryosuke desires are known in git language as
generation numbers. If we maintain a canonical linear history going
forward, they would also be unique as with Subversion. This could be a
good reason
it should work exactly the same way. If it doesn't, please let me know :)
Or, use garden-o-matic, which is more friendly and better for nearly
every purpose.
Cheers,
-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
On Thu, Mar 1, 2012 at 9:43 AM, David Kilzer ddkil...@webkit.org wrote:
On Feb 29, 2012, at 3:28 PM, Dirk Pranke wrote:
In my view, I would actually rather upload the combination of
committed + staged + unstaged changes rather than be told I have to
commit things; in other words, I actually
On Wed, Feb 29, 2012 at 3:06 PM, Shawn Singh shawnsi...@chromium.org wrote:
Quote from the discussion:
that's why I said that having something like webkit-patch upload
range_of_commits will be nice to have, as you wouldn't have to create a
new branch and rebase several commits, just to
On Wed, Feb 29, 2012 at 6:10 PM, Mark Rowe mr...@apple.com wrote:
On 2012-02-29, at 17:05, Lucas Forschler lforsch...@apple.com wrote:
build.webkit.org should be back online now with 0.8.5.
Thanks for your patience!
For anyone following along at home, upgrading to Buildbot v0.8.5 alone
Hi all,
I have recently landed support for 'virtual test suites' in
new-run-webkit-tests (as the subject suggests ;) ). A virtual test
suite tells NRWT to run all the tests in directory 'foo' with an
additional set of command line arguments being passed to DRT, and to
look for baselines in
Hi all,
If you don't use webkit-patch and Git, you can stop reading now. Otherwise ...
Currently, webkit-patch -g has some special logic for figuring out
what to diff against for Git checkouts.
Specifically, webkit-patch -g commitish gets translated to the git
equivalent of 'git diff
Sorry, I'm not sure how I missed the subject line on this ...
-- Dirk
On Mon, Feb 27, 2012 at 5:56 PM, Dirk Pranke dpra...@chromium.org wrote:
Hi all,
If you don't use webkit-patch and Git, you can stop reading now. Otherwise ...
Currently, webkit-patch -g has some special logic
On Mon, Feb 27, 2012 at 6:02 PM, Oliver Hunt oli...@apple.com wrote:
On Feb 27, 2012, at 5:56 PM, Dirk Pranke wrote:
Hi all,
If you don't use webkit-patch and Git, you can stop reading now. Otherwise
...
Currently, webkit-patch -g has some special logic for figuring out
what to diff
Hi all,
I have recently landed a couple of changes to NRWT to make it slightly
more robust and/or waterfall-friendly.
First, on the chromium.org bots, there is now a webkit_lint step on
the bots that checks the expectations files for errors/warnings and
will fail if there are any. A similar
On Tue, Jan 24, 2012 at 5:37 PM, Dirk Pranke dpra...@chromium.org wrote:
Hi all,
new-run-webkit-tests, in addition to the --verbose flag, offers the
ability to turn on or off a number of different blocks of output by
passing a list of options to --print.
I suspect that I'm the only person who
On Wed, Jan 25, 2012 at 11:20 AM, Robert Hogan rob...@roberthogan.net wrote:
On Wednesday 25 January 2012 07:38:07 Ryosuke Niwa wrote:
On somewhat related note, can we simplify the output of
new-run-webkit-tests on bots? It's way too noisy as is. Maybe hide all
DEBUG information?
It would
I like the idea. I'm not sure I agree w/ Adam that I'd roll the code
into DRT, insofar as I don't know how big it is and I would definitely
want the code shared across all of the DRT implementations. I'd
probably also do a pass over all of the existing PNGs at some point
rather than wait for them
Hi all,
new-run-webkit-tests, in addition to the --verbose flag, offers the
ability to turn on or off a number of different blocks of output by
passing a list of options to --print.
I suspect that I'm the only person who has ever really used these
combinations, and I'm inclined to drastically
On Tue, Jan 3, 2012 at 3:28 PM, Adam Barth aba...@webkit.org wrote:
On Tue, Jan 3, 2012 at 3:22 PM, Nico Weber tha...@chromium.org wrote:
On Tue, Jan 3, 2012 at 3:00 PM, Adam Barth aba...@webkit.org wrote:
It looks like Chromium Mac has successfully moved to Skia.
I'd wait with this
All other things being equal, I'd prefer to keep things in Python
since there are a lot more people that can support that than Go. But
if there are some real benefits to Go, I don't have any real
objection.
-- Dirk
On Wed, Dec 7, 2011 at 3:39 PM, Ojan Vafai o...@chromium.org wrote:
Anyone have
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
with different tests
utlizing the same scripts in some cases. Does each 'worker' get a dedicated
http server instance or do they share the same http server?
On Mon, Dec 5, 2011 at 1:01 PM, Dirk Pranke dpra...@chromium.org wrote:
We never implemented the general way of marking subdirectories
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 !?!).
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
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
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
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 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 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 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
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 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
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 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, 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 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 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
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
-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
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
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
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
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
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
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
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
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 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 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
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
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
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
, 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
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
201 - 300 of 344 matches
Mail list logo
