On Sep 30, 2010, at 6:21 PM, Martin Robinson wrote:
> On Thu, Sep 30, 2010 at 5:46 PM, Darin Adler wrote:
>> If we can collapse multiple smart pointer types based on overloading, I
>> think that’s great. In those cases, I think it’s OK to have a single RefPtr
>> class that can handle multiple t
https://bugs.webkit.org/show_bug.cgi?id=46956
Unfortunately, it doesn't solve the whole problem. It does seem to
reduce the flakiness by a lot though.
Adam
On Thu, Sep 30, 2010 at 6:12 PM, Adam Barth wrote:
> Currently the WebSocket tests are served over HTTP from the WebSocket
> server itsel
First Blood!
^_- Roland
On Fri, Oct 1, 2010 at 11:26 AM, Ryosuke Niwa wrote:
> But thanks to your test suite, I noticed some very embarrassing fact:
> https://bugs.webkit.org/show_bug.cgi?id=46954
>
> - Ryosuke
>
>
> On Thu, Sep 30, 2010 at 6:58 PM, Roland Steiner
> wrote:
>
>> On Fri, Oct 1,
But thanks to your test suite, I noticed some very embarrassing fact:
https://bugs.webkit.org/show_bug.cgi?id=46954
- Ryosuke
On Thu, Sep 30, 2010 at 6:58 PM, Roland Steiner wrote:
> On Fri, Oct 1, 2010 at 10:49 AM, Ryosuke Niwa wrote:
>
>> Mn... I realized something strange here.
>>
>> RTE2-AC
On Fri, Oct 1, 2010 at 10:49 AM, Ryosuke Niwa wrote:
> Mn... I realized something strange here.
>
> RTE2-AC_JF_TEXT-1_SC fails on WebKit TOT and the test is: JustifyFull on
> "foo^bar". However, it clearly works on WebKit when I test it manually. It
> generates foobar. I'm not sure
> why the t
On Fri, Oct 1, 2010 at 10:27 AM, Ryosuke Niwa wrote:
> Great. I'm getting get 500 on the results page but is this because it's
> still beta?
>
Good question - shouldn't happen. Have to ping Lindsey to see what the
problem is... :(
Cheers,
- Roland
_
Mn... I realized something strange here.
RTE2-AC_JF_TEXT-1_SC fails on WebKit TOT and the test is: JustifyFull on
"foo^bar". However, it clearly works on WebKit when I test it manually. It
generates foobar. I'm not sure
why the test claims that WebKit fails on this particular test.
Best,
Ryosu
On Thu, Sep 30, 2010 at 2:30 AM, Roland Steiner
wrote:
>
> As a lot of folks here can probably attest to (Hi, Ryosuke! ;) ), the
> current state of rich text editing amongst various browsers is not ideal.
> WebKit is better than most, but still not perfect, either.
>
Hi, Roland!
In order to docum
On Thu, Sep 30, 2010 at 5:46 PM, Darin Adler wrote:
> If we can collapse multiple smart pointer types based on overloading, I think
> that’s great. In those cases, I think it’s OK to have a single RefPtr class
> that can handle multiple types as long as we can come up with a good name.
> But I
Currently the WebSocket tests are served over HTTP from the WebSocket
server itself (which is written in Python). It looks like we can
resolve the flakiness by serving the WebSocket tests from the normal
Apache server that servers the rest of our HTTP tests. I'm going to
work up a patch that does
On Sep 30, 2010, at 5:12 PM, Martin Robinson wrote:
> It does not use compile-time settings, but template specialization.
If we can collapse multiple smart pointer types based on overloading, I think
that’s great. In those cases, I think it’s OK to have a single RefPtr class
that can handle mul
On Wed, Sep 29, 2010 at 11:31 PM, Adam Barth wrote:
> Tonight I wrote a new webkit-patch command for detecting flaky tests.
Are you familiar with the Chromium flakiness dashboard?
It provides a continuous summary of test results aggregated across
multiple builders, including views into the expect
On Thu, Sep 30, 2010 at 5:02 PM, Darin Adler wrote:
> But couldn’t someone get into a situation where they want to use GObject and
> Cairo reference counted types in the same port?
This is the situation with the GTK+ port now. The GTK+ port simply
adds template specializations for GObject types
In case you're interested in Leopard Debug, here's the hit list from
the last 2000 revisions. Interesting notes:
1) Leopard seems way less flaky than Snow Leopard.
2) The websocket tests aren't flaky here.
3) http/tests/appcache/idempotent-update.html fails with an ASSERT
about a webView being nu
I see:
[2010-09-30 16:52:57,560] [CRITICAL] root: [Errno 48] Address already in use
in my pywebsocket.ws.log-30Sep2010-165257-err.txt after an error. Not
sure if it's related, but sounds possible. :)
On Thu, Sep 30, 2010 at 3:10 PM, Adam Barth wrote:
> I'm investigating the websocket issue. It
On Sep 30, 2010, at 4:54 PM, Martin Robinson wrote:
> There are several ports that use third party libraries with reference counted
> types. GTK+ / EFL / and gstreamer based ports use GObject and its associated
> reference-counting mechanism. In addition, Cairo-based ports (including GTK+
> and
On Thu, Sep 30, 2010 at 4:53 PM, Martin Robinson
wrote:
> On Thu, Sep 30, 2010 at 3:20 PM, Darin Adler wrote:
>> For example, for Core Foundation and Cocoa we made RetainPtr. For JavaScript
>> we made JSRetainPtr. For GTK I think we should have GTKRefPtr.
>> Is there really code where the abstra
What is the core idea behind PlatformRefPtr? There is a lot of ambiguity about
what the “platform” is. I’m not sure we should have a single RefPtr template
that tries to guess what the platform is and does that style of reference
counting.
For example, for Core Foundation and Cocoa we made Reta
I'm investigating the websocket issue. It seems these tests are flaky
because they time out. If you know about websockets, I'd appreciate
any tips you have via #webkit.
Adam
On Wed, Sep 29, 2010 at 11:31 PM, Adam Barth wrote:
> Tonight I wrote a new webkit-patch command for detecting flaky te
On Thu, Sep 30, 2010 at 11:51 AM, Chris Marrin wrote:
>
> On Sep 30, 2010, at 10:46 AM, Kenneth Russell wrote:
>
>>> ...
>>>
>>> Sure, transfer semantics avoid shared mutable state, though it would be
>>> inconsistent with most other "pure data" types. But what if you have some
>>> data that doesn
On Sep 30, 2010, at 10:46 AM, Kenneth Russell wrote:
>> ...
>>
>> Sure, transfer semantics avoid shared mutable state, though it would be
>> inconsistent with most other "pure data" types. But what if you have some
>> data that doesn't need mutating but you'd like to share with multiple other
>>
On Thu, Sep 30, 2010 at 11:06 AM, Eric Seidel wrote:
> I've filed bugs for the top two:
>
>> 19 media/audio-controls-rendering.html
>
> https://bugs.webkit.org/show_bug.cgi?id=46924
>
>> 50 compositing/geometry/limit-layer-bounds-transformed-overflow.html
>
> https://bugs.webkit.org/
On Thu, Sep 30, 2010 at 7:09 AM, Chris Marrin wrote:
>
> On Sep 29, 2010, at 6:34 PM, Maciej Stachowiak wrote:
>
> ...The idea is that when an ArrayBuffer is sent via postMessage, it is
>
> atomically "closed" on this side; its publicly visible length goes to
>
> 0, as do the lengths of any views
On Wed, Sep 29, 2010 at 11:31 PM, Adam Barth wrote:
> I'll run the last 1 revisions over night and report on the results.
I have the data for this if anyone's interested, but it's not as
helpful as I thought it would be. The data is similar to the data
from the past 2000 revisions, but with
2010/9/30 Fumitoshi Ukai (鵜飼文敏) :
> AFAIK the websocket tests are not so flaky on chromium (*).
> I wonder this is because of difference in platform code, but seems not so
> flaky on Leopard too.
> So, I suspect issues in test fixtures of websocket test (e.g. failed to
> start up pywebsocket server
29.09.2010, в 23:31, Adam Barth написал(а):
> 3) The appcache tests also have a serious flakiness problem.
Yes, there's a frequent crash that I'm investigating.
- WBR, Alexey Proskuryakov
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http:
On Sep 30, 2010, at 12:26 AM, Adam Barth wrote:
> On Wed, Sep 29, 2010 at 11:31 PM, Adam Barth wrote:
>>50 compositing/geometry/limit-layer-bounds-transformed-overflow.html
>
> Here's the failure diff:
>
> http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r68736%20
On Sep 29, 2010, at 6:34 PM, Maciej Stachowiak wrote:
>
>> ...The idea is that when an ArrayBuffer is sent via postMessage, it is
>> atomically "closed" on this side; its publicly visible length goes to
>> 0, as do the lengths of any views referring to it. On the other side,
>> a new ArrayBuffer
[Apologies if you have seen this already!]
Hi all,
As a lot of folks here can probably attest to (Hi, Ryosuke! ;) ), the
current state of rich text editing amongst various browsers is not ideal.
WebKit is better than most, but still not perfect, either.
In order to document this and provide a g
On Thu, Sep 30, 2010 at 15:31, Adam Barth wrote:
> Tonight I wrote a new webkit-patch command for detecting flaky tests.
> Here the tests that have flaked out on the Snow Leopard (Tests) build
> bot during the last 2000 revisions. This makes a good "hit list" of
> tests to fix to reduce flakines
On Wed, Sep 29, 2010 at 11:31 PM, Adam Barth wrote:
> 50 compositing/geometry/limit-layer-bounds-transformed-overflow.html
Here's the failure diff:
http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(Tests)/r68736%20(18480)/compositing/geometry/limit-layer-bounds-transformed-
31 matches
Mail list logo
