On Feb 22, 2011, at 1:01 PM, Oliver Hunt wrote:
> I agree. My hope was always that the OpenGL backend could be shared among
> all the webkit ports, my only suggestion is that rather than having a
> separate OpenGLExtensionsFunctions class, I think we probably want something
> like
>
> Graphi
-- Forwarded message --
From: Ryosuke Niwa
Date: Wed, Feb 23, 2011 at 2:29 PM
Subject: Re: [webkit-dev] Snow Leopard
To: Mihai Parparita
Cc: Eric Seidel , WebKit Development <
webkit-dev@lists.webkit.org>
On Wed, Feb 23, 2011 at 2:20 PM, Mihai Parparita wrote:
> The SL bot is n
Mihai cleared things up for me in #webkit. media tests were broke
from yesterday until this afternoon, then the crasher rolled in, then
it just got rolled out, and the other media test I was seeing was a
webkit2 failure not SL.
SL is green and the cq is landing in 5-way parallel. :)
-eric
On Tu
The SL bot is now green
(http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20(Tests)),
ever since http://trac.webkit.org/changeset/79390 rolled out a change
that resulted in "all layout tests are crashing on Snow Leopard" per
the comment. It doesn't look like the cq has done a full cyc
The SL bot has been broken since yesterday. Meaning the commit-queue
is now up to 22 patches pending.
There have been a couple media tests failing since checkin. But more
concerning is there appears to be a marauding memory smasher:
http://build.webkit.org/results/SnowLeopard%20Intel%20Release%2
Hi!
I'm returning to this work now, and I see that folks have been quiet about
this since I posted my plan. Here's how I'm going to proceed:
Step 1: I will add beforeload to prefetch & icon rel types. Expect a CL for
this soon.
Step 2: I will add a new subresource rel type, which will have high
That said, I'm *very* excited to see patches supporting 3.0. :) Just
please don't break 2.5 support.
On Tue, Feb 22, 2011 at 2:04 PM, Eric Seidel wrote:
> We expect all python in webkit to work in Python 2.5.
>
> We arrived at that version by looking at the lowest version shipping
> on the commo
We expect all python in webkit to work in Python 2.5.
We arrived at that version by looking at the lowest version shipping
on the common platforms used for webkit development. Mac OS X Leopard
was the platform with the lowest shipping python version (2.5).
If/when Apple stops actively developing
On 2011-02-22, at 13:20, Benjamin wrote:
> Hello,
>
> I would like to update webkit-patch to support Python 3 because that is what
> I use by default.
> I think that would not be too much problem to support Python >= 2.6. If we
> have to support as low as Python 2.4, that could be a problem be
Hi,
We have Debian Lenny on Qt buildbots and Qt EWS with
python 2.5.2. Upgrading to Debian Squeeze is in progress,
I think we can finish it in this week.
If you can wait a little bit, it would be great.
br,
Ossy
Benjamin írta:
I would like to update webkit-patch to support Python 3 because tha
Hello,
I would like to update webkit-patch to support Python 3 because that is what
I use by default.
I think that would not be too much problem to support Python >= 2.6. If we
have to support as low as Python 2.4, that could be a problem because of
some new syntax elements introduced in 2.6.
Sho
I agree. My hope was always that the OpenGL backend could be shared among all
the webkit ports, my only suggestion is that rather than having a separate
OpenGLExtensionsFunctions class, I think we probably want something like
GraphicsContext3DOpenGL.{h,cpp} for all the common logic
and then
G
Hi,
I'm writing this mail in order to propose changes that would make the OpenGL
implementation of the GraphicsContext3D a lot easier to share between the
Mac and Gtk port.
Currently the mentioned implementation is only used by the Mac port. The Gtk
port is also interested in using this implement
That's an interesting thread. I had always assumed that either the testers
always synced to the same rev as the builders, or at least that they pulled
the layout test files/expectations from the builders along with the
executables. Not doing this just seems inherently broken, but I understand
why w
Ah, true. The code changes were long ago.
On Tue, Feb 22, 2011 at 21:40, Mihai Parparita wrote:
> But these were rebaselines, which don't depend on any code changes.
>
> Mihai
>
> On Tue, Feb 22, 2011 at 10:35 AM, Mikhail Naganov
> wrote:
>> I have a suspicion that the cause of canaries failure
But these were rebaselines, which don't depend on any code changes.
Mihai
On Tue, Feb 22, 2011 at 10:35 AM, Mikhail Naganov wrote:
> I have a suspicion that the cause of canaries failures is described
> here:
> https://groups.google.com/a/google.com/group/chrome-webkit-gardening/browse_thread/t
I have a suspicion that the cause of canaries failures is described
here:
https://groups.google.com/a/google.com/group/chrome-webkit-gardening/browse_thread/thread/d3b3a4fc647e804d
In short, bots can run tests prematurely, emitting false failures. I
observed this during my gardening, and I think y
Yeah, it's weird. I rebaselined those tests, but the chromium canaries still
showed them as red. Now, however, the canaries are showing many of them
passing. I was planning to remove the lines from test_expectations today to
see if they stay green.
-atw
On Tue, Feb 22, 2011 at 6:46 AM, Mihai Parp
Hello,
I have not been on the calls but I have posted about my remote debugger work on
the FireBug working group message board. It is true that Crossfire is smaller
than the Web Inspector protocol but it has all I need for the remote debugging
of a faceless server that runs JavaScript.
In fact
OK, cool! Thanks a lot. Nice to see a functioning browser to browser debugging.
Do you know if the Web Inspector protocol specification is stable and finalized
now?
Thanks!
-Sergiy
De : Joseph Pecoraro [mailto:pecor...@apple.com]
Envoyé : vendredi 18 février 2011 19:31
À : Sergiy Temnikov
Cc :
It looks like Drew checked in baselines with
http://trac.webkit.org/changeset/79034 (which may be why
rebaseline-chromium-webkit-tests isn't doing anything, since it
already has "correct" pixel baselines), but given
http://trac.webkit.org/changeset/79088 it didn't seem to work. Drew,
any ideas why?
Hi,
On 2011-02-15 17:50, Leandro Graciá Gil wrote:
> Yes, the platform independent code in the device element will determine
> if a selection has been made, or altered, in the list of available
> devices
> Provided by the platform. Before passing it to the device element, the
>
Hi Chromium WebKit folks,
I'm looking for a help to retrieve the latest expectation files for
Chromium Mac LayoutTest.
At the weekend there was a change that triggers massive amount of
pixel test failures that requires rebaselining.
(https://bugs.webkit.org/b/54736)
But the buildbot doesn't have t
Bug filed: https://bugs.webkit.org/show_bug.cgi?id=54942
I'll work on the bug this week.
2011/2/22 Darin Adler
> I misread this and thought it was the unload attribute on the body element,
> not an iframe element.
>
> My answer was completely wrong for an iframe element!
>
>-- Darin
>
>
24 matches
Mail list logo
