On Tue, May 3, 2011 at 1:22 AM, Won J Jeon wjj...@gmail.com wrote:
Thanks for the update. BTW, is there any switch that I need to turn on in
order to enable WebGL support with QT port?
I built the code by using '--3d-canvas --3d-rendering' switches and
launched QtTestBrowser by using
On Mon, May 2, 2011 at 9:39 PM, naren.me...@gmail.com wrote:
So, I am facing a roadblock now.
Is there any other way to run those layout tests on wekbkit2-gtk ??
Can I use the available patch in the above listed bug report ??
While waiting for my patch to finish the review process, feel free
It looks like Tiger support in WebKit is slowly being removed. There
no longer is a libWebKitSystemInterfaceTiger.a in the project, nor is
there a Tiger buildbot or tiger expectations.
Can we go ahead and kill all the ifdefs too? Or is it too early to
call Tiger dead?
-eric
On 2011-05-03, at 10:58, Eric Seidel wrote:
It looks like Tiger support in WebKit is slowly being removed. There
no longer is a libWebKitSystemInterfaceTiger.a in the project, nor is
there a Tiger buildbot or tiger expectations.
Can we go ahead and kill all the ifdefs too? Or is it too
I was referring mostly to build-webkit ifs, assuming that the #ifdefs
in the cpp code were still around as well. But it's possible those
already got removed. :)
-eric
On Tue, May 3, 2011 at 11:07 AM, Mark Rowe mr...@apple.com wrote:
On 2011-05-03, at 10:58, Eric Seidel wrote:
It looks like
I was referring mostly to build-webkit ifs, assuming that the #ifdefs
in the cpp code were still around as well. But it's possible those
already got removed. :)
I think Eric's question is broader than just #ifdefs. Bugzilla has
some Tiger bugs that we should close if we consider Tiger's
The results load considerably faster now. For runs where many tests fail,
the filesize is considerably smaller than the old-run-webkit-tests
filesize. Also,
I've added in the image toggling behavior of old-run-webkit-tests and made
the aesthetics a bit closer to the old-run-webkit-test format.
On May 3, 2011, at 4:01 PM, Ojan Vafai wrote:
The results load considerably faster now. For runs where many tests fail, the
filesize is considerably smaller than the old-run-webkit-tests filesize.
Also, I've added in the image toggling behavior of old-run-webkit-tests and
made the
On Tue, May 3, 2011 at 1:44 PM, Adam Roben aro...@apple.com wrote:
On May 3, 2011, at 4:01 PM, Ojan Vafai wrote:
The results load considerably faster now. For runs where many tests fail,
the filesize is considerably smaller than the
old-run-webkit-tests filesize. Also, I've added in the
Is that a good example? It doesn't remind me much of the ORWT output.
The disclosure triangles don't seem to do anything for hte failures on
that page.
On Tue, May 3, 2011 at 2:05 PM, Ojan Vafai o...@chromium.org wrote:
On Tue, May 3, 2011 at 1:44 PM, Adam Roben aro...@apple.com wrote:
On
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
IIRC the showing wdiff when there is no wdiff bug has since been
fixed? (but that bot just hasn't updated?)
what's the failure type column? (and why can't I select its text?)
Why do expected flaky tests show up in the Expected to fail but passed list?
Seems expected flaky tests should be in
If we have + buttons for all the failures, might as well have them for
the http logs too. :p
On Tue, May 3, 2011 at 2:23 PM, Eric Seidel e...@webkit.org wrote:
IIRC the showing wdiff when there is no wdiff bug has since been
fixed? (but that bot just hasn't updated?)
what's the failure type
13 matches
Mail list logo
