[webkit-dev] Adding new entries to TestExpectations can be harmful

2013-05-22 Thread Ryosuke Niwa
And there is an overwhelming evidence:
http://trac.webkit.org/changeset?reponame=&new=150559%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectations&old=150476%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectations

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Ref counting questions

2013-05-22 Thread Maciej Stachowiak

We could probably phase out TreeShared if we were really careful to avoid 
refcount thrash during tree construction/manipulation. I believe this can be 
done with careful use of PassRefPtr and swap() and it would likely be easier to 
understand if Nodes normally had a refcount of 1 instead of 0.

On May 22, 2013, at 10:41 AM, Antti Koivisto  wrote:

> TreeShared is essentially an implementation detail of the DOM tree (the only 
> other client besides Node is SVGElementInstance).  It shouldn't be used for 
> anything else.
> 
> TreeShared keeps Nodes alive when they are part of a tree (have a parent 
> node) even when they have zero refcount. This way nodes don't need to 
> explicitly ref and deref their children.
> 
> 
>   antti
> 
> 
> On Wed, May 22, 2013 at 7:26 PM, Bem Jones-Bey  wrote:
> Hey all,
> 
> I've read the document at http://www.webkit.org/coding/RefPtr.html, but I 
> still have some questions about using RefPtrs.
> 
> The first one is listed in the "Improving this document" section of the 
> aforementioned documentation:
> • Perils of programming with TreeShared.
> What does that mean? What gotchas should I be aware of? (Heck, more details 
> on any of the things in "improving this document" would be helpful, and I'll 
> do my best to update the document with anything I learn if that's desired.)
> 
> Also, I've noticed that there's both TreeShared and RefCounted, and they seem 
> fairly similar to my uninitiated eye. What's the difference between the two 
> and when should one use one or the other? Also, are there other 
> templates/classes that I should be aware of?
> 
> Thanks,
> Bem
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Ref counting questions

2013-05-22 Thread Antti Koivisto
TreeShared is essentially an implementation detail of the DOM tree (the
only other client besides Node is SVGElementInstance).  It shouldn't be
used for anything else.

TreeShared keeps Nodes alive when they are part of a tree (have a parent
node) even when they have zero refcount. This way nodes don't need to
explicitly ref and deref their children.


  antti


On Wed, May 22, 2013 at 7:26 PM, Bem Jones-Bey  wrote:

> Hey all,
>
> I've read the document at http://www.webkit.org/coding/RefPtr.html, but I
> still have some questions about using RefPtrs.
>
> The first one is listed in the "Improving this document" section of the
> aforementioned documentation:
> • Perils of programming with TreeShared.
> What does that mean? What gotchas should I be aware of? (Heck, more
> details on any of the things in "improving this document" would be helpful,
> and I'll do my best to update the document with anything I learn if that's
> desired.)
>
> Also, I've noticed that there's both TreeShared and RefCounted, and they
> seem fairly similar to my uninitiated eye. What's the difference between
> the two and when should one use one or the other? Also, are there other
> templates/classes that I should be aware of?
>
> Thanks,
> Bem
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


[webkit-dev] Ref counting questions

2013-05-22 Thread Bem Jones-Bey
Hey all,

I've read the document at http://www.webkit.org/coding/RefPtr.html, but I still 
have some questions about using RefPtrs.

The first one is listed in the "Improving this document" section of the 
aforementioned documentation:
• Perils of programming with TreeShared.
What does that mean? What gotchas should I be aware of? (Heck, more details on 
any of the things in "improving this document" would be helpful, and I'll do my 
best to update the document with anything I learn if that's desired.)

Also, I've noticed that there's both TreeShared and RefCounted, and they seem 
fairly similar to my uninitiated eye. What's the difference between the two and 
when should one use one or the other? Also, are there other templates/classes 
that I should be aware of?

Thanks,
Bem

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Moving WebCore/accessibility code into WebCore/platform/

2013-05-22 Thread Mario Sanchez Prada
Hi Maciej,

[.]
> I think the main problem with this change is that the
> current WebCore/accessibility code has lots of knowledge
> of the DOM and render tree. Making WebCore/platform
> depend on these Web-specific concepts is a layering
> violation - imagine how it would work if it was a
> top-level directory Platform that was a peer of WebCore,
> and built before it without access to its headers. 
> That is logically how it should operate.

That's absolutely right. When I sent the email I was thinking more of the
platform specific nature of the accessibility layer and its adaptation to
each port (the wrappers), but it's true that the relationship with those
other trees is so tight that moving it into platform (as it is now) would be
a problem.

> If the accessibility code could be redesigned to have
> a good abstraction between the parts that are tightly
> tied to Web-specific classes and concepts, and the part
> that is platform-specific, then the second part could
> be moved to WebCore/platform. A refactoring like that
> could be a good improvement, but is likely hard to do.

Agreed on this too. 

Thanks for the feedback,
Mario



___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev