On Sat, Feb 9, 2013 at 5:35 PM, Dirk Pranke dpra...@chromium.org 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
to ignore them (e.g., dumpAsTextAndIgnoredImage() or something), or
conveyed which
On 02/07/2013 01:48 AM, Maciej Stachowiak wrote:
I think we should continue to use uint8_t instead of char as the
primary way to represent a raw byte in WebKit. First, it's good to
distinguish raw data from C strings at the type system level, and
second, the unpredictable signedness of char
On Sun, Feb 10, 2013 at 10:03 AM, Balazs Kelemen kbal...@webkit.org wrote:
On 02/07/2013 01:48 AM, Maciej Stachowiak wrote:
I think we should continue to use uint8_t instead of char as the primary
way to represent a raw byte in WebKit. First, it's good to distinguish raw
data from C
Short answer, yes.
On Feb 10, 2013, at 9:14 AM, Glenn Adams gl...@skynav.com wrote:
Because LChar is often (always?) UTF-8 encoded, the individual encoding units
of which are 0x00 through 0xFF.
Close.
LChar is always Latin-1 encoded. That’s what the L is for. That’s the same
thing as the
On Sat, Feb 9, 2013 at 7:41 PM, Maciej Stachowiak m...@apple.com wrote:
Hi Peter,
On Feb 9, 2013, at 3:48 PM, Peter Kasting pkast...@google.com wrote:
On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak m...@apple.com wrote:
There are certainly pros and cons to merging. It would be great
On Sun, Feb 10, 2013 at 10:39 AM, Ojan Vafai o...@chromium.org wrote:
On Sat, Feb 9, 2013 at 7:41 PM, Maciej Stachowiak m...@apple.com wrote:
Hi Peter,
On Feb 9, 2013, at 3:48 PM, Peter Kasting pkast...@google.com wrote:
On Sat, Feb 9, 2013 at 11:52 AM, Maciej Stachowiak m...@apple.com
On Sun, Feb 10, 2013 at 11:38 AM, Darin Adler da...@apple.com wrote:
Short answer, yes.
On Feb 10, 2013, at 9:14 AM, Glenn Adams gl...@skynav.com wrote:
Because LChar is often (always?) UTF-8 encoded, the individual encoding
units of which are 0x00 through 0xFF.
Close.
LChar is always
Here is a list all iOS-specific changes in WebCore and below that are due to
the iOS WebKit threading model, from an exhaustive review of diffs to the
downstream source. I'm not sure anyone needs this to make a decision any more,
but it may be helpful to people to know what's coming as we
On Feb 10, 2013, at 10:48 AM, Adam Barth aba...@webkit.org wrote:
Ok. I'm sold. I suspect we'll want to move the iOS port off of
USE(WEB_THREAD), but I can see how it's better to do that work in trunk.
We definitely want to get off the web thread over time. There's two paths by
which
Hi Maciej,
Thank you for taking the time to clearly enumerate these different tasks.
It must have been a tedious effort, but I think the list is quite helpful
in understanding the changes you are proposing.
1. The WTF changes seem like they could be easily protected by preprocessor
macros to not
Hi,
Today, adding a support for a new function in TestRunner requires
(painfully) changing:
-WebKitTestRunner.
-Common DRT + 6 implementations (Mac, Win, GTK, EFL, WX, Blackberry).
-Chromium DRT.
-Qt DRT.
I think we can do much better. A first step is to have more common code in
DRT.
One of the
Hi again,
While looking into DRT changes, I notice there is zero activity on the
wxWidgets implementation.
Looking at WebCore/WebKit, excluding general changes, the last commit for
wxWidgets is 6 months old: http://trac.webkit.org/changeset/126457
So...is the port still active?
Maybe it should
On Feb 10, 2013, at 5:14 PM, Brent Fulgham bfulg...@gmail.com wrote:
Hi Maciej,
Thank you for taking the time to clearly enumerate these different tasks. It
must have been a tedious effort, but I think the list is quite helpful in
understanding the changes you are proposing.
1. The
On Sun, Feb 10, 2013 at 10:30 PM, 85.mukesh 85.muk...@gmail.com wrote:
I want to put any kind of Box2d effect on html element. These things I
want to do with css extension. [...]
Wrong mailing list.
WebKit-dev is for the development of WebKit. If you want to make some kind
of non-standard
On Mon, Feb 11, 2013 at 3:37 AM, Benjamin Poulain benja...@webkit.orgwrote:
Hi,
Today, adding a support for a new function in TestRunner requires
(painfully) changing:
-WebKitTestRunner.
-Common DRT + 6 implementations (Mac, Win, GTK, EFL, WX, Blackberry).
-Chromium DRT.
-Qt DRT.
I think
On Sun, Feb 10, 2013 at 10:56 PM, Jochen Eisinger joc...@chromium.orgwrote:
Today, adding a support for a new function in TestRunner requires
(painfully) changing:
-WebKitTestRunner.
-Common DRT + 6 implementations (Mac, Win, GTK, EFL, WX, Blackberry).
-Chromium DRT.
-Qt DRT.
I think we
On Mon, Feb 11, 2013 at 8:19 AM, Benjamin Poulain benja...@webkit.orgwrote:
On Sun, Feb 10, 2013 at 10:56 PM, Jochen Eisinger joc...@chromium.orgwrote:
Today, adding a support for a new function in TestRunner requires
(painfully) changing:
-WebKitTestRunner.
-Common DRT + 6 implementations
On Sun, Feb 10, 2013 at 11:20 PM, Jochen Eisinger joc...@chromium.orgwrote:
I'm not sure I understand. In what cases do you then add something to DRT
and need to change all of them?
Take this for example: http://trac.webkit.org/changeset/130416
It does not make sense to test everything
18 matches
Mail list logo
