On Mon, Jun 11, 2012 at 11:45 PM, Ryosuke Niwa wrote:
> On Mon, Jun 11, 2012 at 11:37 PM, Dirk Pranke wrote:
>>
>> On Thu, Jun 7, 2012 at 4:47 PM, Dirk Pranke wrote:
>> > I believe most if not all of the ports have started using either
>> > TestExpectations files or a combination of TestExpectat
On Mon, Jun 11, 2012 at 11:37 PM, Dirk Pranke wrote:
> On Thu, Jun 7, 2012 at 4:47 PM, Dirk Pranke wrote:
> > I believe most if not all of the ports have started using either
> > TestExpectations files or a combination of TestExpectations files
> > (except for the Apple Win port).
> >
> > Can we
On Thu, Jun 7, 2012 at 4:47 PM, Dirk Pranke wrote:
> I believe most if not all of the ports have started using either
> TestExpectations files or a combination of TestExpectations files
> (except for the Apple Win port).
>
> Can we explicitly switch to the TestExpectations files at this point
> an
I don't think there is any consistency across the project here except
everyone agrees that imported test suites shouldn't go in fast, e.g. all
our new flexbox tests have gone in css3/flexbox.
On Mon, Jun 11, 2012 at 10:28 PM, James Robinson wrote:
> There are plenty of non-text tests in fast/, e
On Mon, Jun 11, 2012 at 9:32 PM, Filip Pizlo wrote:
> I think that a lot of the performance penalty can be alleviated by:
>
> 1) Moving rarely executed paths into non-inlineable methods.
>
> 2) Marking the various refing methods ALWAYS_INLINE, after you've moved as
> much as possible out of line.
On Mon, Jun 11, 2012 at 5:46 PM, Maciej Stachowiak wrote:
>
> On Jun 10, 2012, at 9:26 AM, Ojan Vafai wrote:
>
> On Sun, Jun 10, 2012 at 4:54 AM, Balazs Kelemen wrote:
>>>
>>> So the unit tests are superfluous. In particular, if I had to pick
>>> between only having unit tests or only having re
There are plenty of non-text tests in fast/, even entire directories of
them (fast/repaint). My understanding of the meaning of fast/ is that it is
where new tests that are not imported should go. This meaning is not
universally applied.
- James
On Jun 11, 2012 7:33 PM, "Mike Lawther" wrote:
> I
Hi ggaren and pizlo
Sorry for posting a not-yet-optimized WIP patch. I'll re-post it after
optimization you suggested.
Also, I described the algorithm I am now implementing. I guess that
this algorithm would have less overhead:
https://bugs.webkit.org/show_bug.cgi?id=88834#c3
On Tue, Jun 12,
I think that a lot of the performance penalty can be alleviated by:
1) Moving rarely executed paths into non-inlineable methods.
2) Marking the various refing methods ALWAYS_INLINE, after you've moved as much
as possible out of line.
3) Using LIKELY and UNLIKELY where appropriate.
The reaso
> Actually I've tried the approach yesterday but confirmed 25.9%
> performance regression, even if I have TreeShared hold a pointer to
> the root. Please look at the WIP patch and the performance test in
> https://bugs.webkit.org/show_bug.cgi?id=88834.
>
> What I've learned is that we must not ins
>> IMHO, (a) would be the best semantics.
>
> I agree, and I think that the specification actually does require this.
>
> The real issue here is how to fix this bug efficiently. I believe that Geoff
> Garen has been contemplating this and also has a proposal for how to do it.
I believe you coul
Thanks ggaren!
I filed a bug here: https://bugs.webkit.org/show_bug.cgi?id=88834
> I believe you could achieve (a) (i.e., preserve all reachable nodes without
> help from the JavaScript garbage collector) with these semantics in the C++
> DOM:
>
> = Design =
>
> ref():
>
> ++this->refC
On Mon, Jun 11, 2012 at 7:33 PM, Mike Lawther wrote:
>
> I did so because I not all my tests are 'text only' tests, but I still
> wanted them all together. My understanding was that the 'fast' directory
> was intended for 'text only' tests only.
>
That's not the case. The reason we have many pixel
I'm the guy that added css3/calc tests.
I did so because I not all my tests are 'text only' tests, but I still
wanted them all together. My understanding was that the 'fast' directory
was intended for 'text only' tests only.
Does having the 'fast' directory still serve a useful purpose? I reckon
On Mon, Jun 11, 2012 at 6:29 PM, Maciej Stachowiak wrote:
> On Jun 7, 2012, at 1:10 PM, Adam Barth wrote:
>> On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa wrote:
>>> On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan
>>> wrote:
I wanted to let you know that I plan to add support for
n
On Jun 7, 2012, at 1:10 PM, Adam Barth wrote:
> On Thu, Jun 7, 2012 at 1:00 PM, Ryosuke Niwa wrote:
>> On Wed, Jun 6, 2012 at 1:51 PM, Annie Sullivan
>> wrote:
>>>
>>> I wanted to let you know that I plan to add support for
>>> navigator.buildType (e.g., "nightly", "beta", "final") to WebKit.
Thanks Maciej
I am trying to implement a WIP patch that guarantees "Reachable DOM nodes
are kept alive", without regressing performance nor without adding member
variables to Node objects. The patch will remove guardRef() as a natural
consequence. Although I'm not 100% sure if the work succeeds or
On Jun 11, 2012, at 6:06 PM, Maciej Stachowiak wrote:
> not a self-only reference (at some point renamed to guardRef).
BTW I was able to find where it was renamed but not a good explanation of why.
I think selfOnlyRef() was a much clearer name.
The history seems to be that it was renamed wh
On Jun 6, 2012, at 6:27 PM, Darin Adler wrote:
> On Jun 6, 2012, at 6:14 PM, Kentaro Hara wrote:
>
>> IMHO, (a) would be the best semantics.
>
> I agree, and I think that the specification actually does require this.
>
> The real issue here is how to fix this bug efficiently. I believe that
On Jun 10, 2012, at 9:26 AM, Ojan Vafai wrote:
> On Sun, Jun 10, 2012 at 4:54 AM, Balazs Kelemen wrote:
>> So the unit tests are superfluous. In particular, if I had to pick between
>> only having unit tests or only having regression tests, I might pick unit
>> tests. But if I already have
On 6/11/12 2:37 PM, "Ryosuke Niwa" mailto:rn...@webkit.org>>
wrote:
On Mon, Jun 11, 2012 at 2:33 PM, Dirk Pranke
mailto:dpra...@chromium.org>> wrote:
Technically, it does (at least NRWT does), but I wouldn't recommend
it. NRWT is designed to allow tests to live in multiple repos, but it
seems li
On Mon, Jun 11, 2012 at 2:33 PM, Dirk Pranke wrote:
>
> Technically, it does (at least NRWT does), but I wouldn't recommend
> it. NRWT is designed to allow tests to live in multiple repos, but it
> seems like all of the tests in the webkit repo should be under a
> single top-level dir.
>
I don't
On Mon, Jun 11, 2012 at 2:24 PM, Ryosuke Niwa wrote:
> On Mon, Jun 11, 2012 at 2:21 PM, Jacob Goldstein wrote:
>>
>> Can we just create an imported-w3c folder at the same level as
>> LayoutTests?
>
>
> You mean at trunk? I don't think that makes sense, and our testing
> infrastructure doesn't sup
On Mon, Jun 11, 2012 at 2:25 PM, Jacob Goldstein wrote:
> On 6/11/12 2:24 PM, "Ryosuke Niwa" wrote:
>
> On Mon, Jun 11, 2012 at 2:21 PM, Jacob Goldstein wrote:
>>
>> Can we just create an imported-w3c folder at the same level as
>> LayoutTests?
>>
>
> You mean at trunk? I don't think that makes
On 6/11/12 2:24 PM, "Ryosuke Niwa" mailto:rn...@webkit.org>>
wrote:
On Mon, Jun 11, 2012 at 2:21 PM, Jacob Goldstein
mailto:jac...@adobe.com>> wrote:
Can we just create an imported-w3c folder at the same level as LayoutTests?
You mean at trunk? I don't think that makes sense, and our testing
i
On Mon, Jun 11, 2012 at 2:21 PM, Jacob Goldstein wrote:
>
> Can we just create an imported-w3c folder at the same level as LayoutTests?
>
You mean at trunk? I don't think that makes sense, and our testing
infrastructure doesn't support that.
- Ryosuke
On 6/11/12 11:11 AM, "Alexis Menard" wrote:
>On Mon, Jun 11, 2012 at 3:09 PM, Simon Fraser
>wrote:
>> I think imported tests should be outside of LayoutTests/fast.
>
>I agree a dedicated folder seems more appropriate.
>
>My two cents.
>
>>
>> Simon
>>
>> On Jun 11, 2012, at 1:57 AM, Ryosuke Niwa
On Mon, Jun 11, 2012 at 3:09 PM, Simon Fraser wrote:
> I think imported tests should be outside of LayoutTests/fast.
I agree a dedicated folder seems more appropriate.
My two cents.
>
> Simon
>
> On Jun 11, 2012, at 1:57 AM, Ryosuke Niwa wrote:
>
> Hi,
>
> I realized that there are a whole bunc
I think imported tests should be outside of LayoutTests/fast.
Simon
On Jun 11, 2012, at 1:57 AM, Ryosuke Niwa wrote:
> Hi,
>
> I realized that there are a whole bunch of tests in LayoutTests/css3 that use
> layoutTestController (e.g. css3/calc, css3/filters, etc...), which appears to
> mean t
On 2012-06-10 19:09, Žan Doberšek wrote:
I think it would suffice to replace all the FAIL occurrences with
TEXT, except for the failing reftests - those should have FAIL turned
into IMAGE. Gtk bots don't run pixel tests yet so any other IMAGE
failures could perhaps be addressed at later time.
On Mon, Jun 11, 2012 at 2:08 AM, TAMURA, Kent wrote:
> Do you want WebExposed for a simple bug fix of an existing feature? Do you
> want it for bugs with no patches?
>
If the change might impact Web Developers - yes. Of course, use your own
judgement here; it won't have much benefit for minor fi
Hi,
I realized that there are a whole bunch of tests in LayoutTests/css3 that
use layoutTestController (e.g. css3/calc, css3/filters, etc...), which
appears to mean that they're our own tests. However, css3/selectors3 is an
imported W3C test suite. It's very confusing to mix imported tests and
Web
Hello WebKit community,
We want to announce a "European WebKit Hackathon" event hosted by Adobe. The
event will take place in Adobe office in Bucharest on September 20th - 22nd.
We hope that this hackathon will offer attendees the opportunity to know each
other better, share WebKit expertise, a
33 matches
Mail list logo
