[webkit-dev] New wiki page for Visual Studio debugging tips

[Adam Roben]

While working on WebKit2 I've had to become a bit more savvy in my Visual 
Studio usage. I started a wiki page to record useful tips I've learned. You can 
find it here: 
. I hope 
others will find it useful, too. Please add your own tips to it!

-Adam

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

Re: [webkit-dev] Some new coding style rules

[David Kilzer]

On Wed, August 4, 2010 at 11:56:53 PM, Sam Weinig wrote:
> On Wed, Aug 4, 2010 at 1:29 AM, Nikolas Zimmermann 
> wrote:
> 
> >namespace WebCore {
> >...
> >} // namespace WebCore
> >
> >2. ENABLE(FOO) #endif comments
> >
> >#if ENABLE(FOO)
> >..
> >#endif // ENABLE(FOO)
> 
> I like these two forms of comments.

As do I.  My preference for rules is:

- Always use "} // namespace Foo" comments with namespaces.

- Always use "#endif // ENABLE(FOO)" comments if there are more than 10-15 
lines  of code between the matching #if/#else/#elif, or if the #endif is 
nested.  But  do not treat it as a warning/error if an #endif macro has a 
well-formed comment  and doesn't obey the 'required' rules in the previous 
sentence (unless this inconsistency would drive anyone nuts).


I like both of these comments for the following reasons:


- You don't have to scroll up or otherwise jump around the source to know 
what the right curly brace or the #endif macro is used for.

In the namespace case, the block almost always spans most of the file, so 
there's rarely a case when it's less than 10 lines away from the left 
curly brace.  Or to put it another way, the "namespace Foo {" line is always 
near the top of the file, and the "} // namespace Foo" line is always near the 
bottom of the file, so it's rare that you see them both at the same time.

In the case of the #endif macro, I find that the comments are useful if 
the corresponding #if/#else/#elif is more than 10-15 lines away (e.g., more 
than 
a screenful), or if there is any #if macro nesting such that #endif statements 
can appear next to each other (see Platform.h).


- When merging, having these comments are a great help to both the person 
doing the merge and to merge algorithms.

New methods are often added near the end of a namespace, which means the "}" 
for the end of the method looks the same as the "}" for the end of a 
namespace (especially with our current namespace indent rules), so merges with 
conflicts sometimes end up "repurposing" the namespace curly brace for the end 
of a new method.  Providing an explicit comment prevents this behavior, and 
provides a common anchor point in both the original ("ours") and new ("theirs") 
files.

Likewise, #endif macros (especially when grouped together due to nesting) 
will frequently get "repurposed" by merge algorithms.  This can create more 
work (especially the way some macros are nested in Platform.h) if there are 
changes to both files being merged.

--

On a related note, I think we should also define rules for indenting #if 
macros.  I think this is orthogonal to using comments, though, and I prefer 
having comments regardless of the indent rules.

Note that macro indenting has already started (haphazardly) in Platform.h 
and perhaps a few other places.

Here are some examples:

#if ENABLE(FOO)
#if PLATFORM(BAR)
#if USE(BAZ)
...
#else
...
#endif // USE(BAZ)
#endif // PLATFORM(BAR)
#endif // ENABLE(FOO)

#if ENABLE(FOO)
# if PLATFORM(BAR)
#  if USE(BAZ)
...
#  else
...
#  endif // USE(BAZ)
# endif // PLATFORM(BAR)
#endif // ENABLE(FOO)

#if ENABLE(FOO)
#if PLATFORM(BAR)
  #if USE(BAZ)
...
#else
...
  #endif // USE(BAZ)
#endif // PLATFORM(BAR)
#endif // ENABLE(FOO)

My original opinion was to never indent macros, but after staring at the 
above examples, I do think indenting makes them easier to read.  I'm still 
trying to decide whether I like the "#" anchored on the left or whether I 
prefer 
it anchored to if/else/elif/endif macro names, though.

Dave
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] HTML5 tree builder enabled

[Jeremy Orlow]

Impressive!  Thanks Eric+Adam for all the work on this!  You guys are quite
a team.

J

On Thu, Aug 5, 2010 at 9:10 AM, Adam Barth  wrote:

> The HTML5 tree builder is enabled as of
> .  Check out our awesome
> SVG-in-HTML demo (in a post r64712 build, of course):
>
>
> http://trac.webkit.org/export/LATEST/trunk/LayoutTests/svg/in-html/circle.html
>
> In light of the other thread about wanting more blog posts, I'm
> working on a blog post about this change that I hope to post some time
> later today.  If we've horribly broken everything, please file a bug
> and CC me and Eric.
>
> Thanks again,
> Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Some new coding style rules

[Tor Arne Vestbø]

On 04.08.10 20.04, Adam Roben wrote:

On Aug 4, 2010, at 7:15 AM, Jeremy Orlow wrote:


2. ENABLE(FOO) #endif comments

#if ENABLE(FOO)
..
#endif // ENABLE(FOO)

Shall we remove the comment, or require it explicitely in the style rules?


I find these comments especially helpful when there are nested #ifs involved. I 
also find them helpful (though less so) when there are no nested #ifs, but a 
lot of code is between the #if/#endif. I don't find them useful when a whole 
file (either .h or .cpp) is compiled out.


I agree, nested #ifs, especially when non-indented, are a lot easier to 
read with ending comments.


Tor Arne

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

Re: [webkit-dev] Fwd: webkit editing rewrite?

[Adam Barth]

On Thu, Aug 5, 2010 at 1:59 AM, Maciej Stachowiak  wrote:
>> On Aug 4, 2010 4:30:01 PM PDT, Darin Adler  wrote:
 On Aug 4, 2010, at 3:48 PM, Ryosuke Niwa wrote:
> I think the kind of crashes Ojan is talking about are ones caused by
 DOM mutation events.
>> 
>>> It’s possible we’ll address this by changing how DOM mutation events
>>> work.
>>
>> We need to change how DOM mutation events work regardless of this
>> proposal IMO. So, lets keep that a separate discussion.
>
> If mutation events tend to break editing, one simple solution is to turn then 
> off within the scope of editing operations and send a single mutation event 
> at the end. It's not clear if that kind of solution would be appropriate to 
> expose to Web content, though; you can't do the RAII idiom in JavaScript so 
> there could be too much risk of staying stuck in the "mutation events 
> deferred" state. On the other hand, a dynamic-wind-style solution might be 
> appropriate. This is one tiny example of how the same abstractions might not 
> be right internally and externally.

If we don't already have it, we definitely want a RAII for turning off
mutation events (or at least ASSERTing that we're not trying to fire
them) for the parser.  The new and old tree builders might explode if
they ever fire a mutation event.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Fwd: webkit editing rewrite?

[Maciej Stachowiak]

On Aug 4, 2010, at 6:12 PM, Ojan Vafai wrote:

> 
> On Tue, Aug 3, 2010 at 5:07 PM, Geoffrey Garen  wrote:
>>> -Ensures that the APIs we expose to the web are at least good enough for 
>>> our own editing code
>> 
>> I don't think this necessarily follows. Not everything exposed to the 
>> internal editing implementation would necessarily be exposed to the web. If 
>> we required that everything exposed to the internal editing implementation 
>> be exposed to the web, that would substantially slow development, since 
>> every new API would need to be vetted and possibly standardized. So this is 
>> either not true or a substantial con.
> 
> This would have been a fine point without the last sentence here. I'm
> not sure how to read that sentence without the implication that I'm
> either being stupid or manipulative. FWIW, I do think that everything
> exposed to the internal editing implementation should eventually be
> exposed to the web. I'll expand on that below.

I think Geoff is not saying that you are stupid or manipulative, just that he 
disagrees with your conclusion. There are many reasons someone could be wrong, 
for example that they are honestly mistaken. When I think someone is wrong, I 
usually assume they are honestly mistaken  and can probably be persuaded 
through logic. Or else, perhaps I am mistaken and will learn that through 
discussion. When someone else disagrees with me and says I am wrong, I try to 
assume they thought I made an honest mistake. Sometimes people actually do 
think I am stupid or are stupid themselves, but I find it makes technical 
discussions go better if I don't focus on those possibilities.

Short version: let's all try to assume good faith on the part of our fellow 
webkit-dev posters.

(That being said, I think a few parts of Geoff's message were a little too 
snarky, but I think the point you cited here is a reasonable one and not stated 
in an overly combative way.)

> On Tue, Aug 3, 2010 at 4:38 PM, Darin Adler  wrote:
>> Inventing a new layer to rebuild editing on top could well be good. Exposing 
>> that layer itself to webpages seems like it makes the job even harder rather 
>> than easier! Hidden implementation details can be changed more easily than 
>> exposed APIs.
> 
> I agree that these can be separated out. 1 and 2 are the ones I really
> care about. 3 and 4 were just an idea of one way to get there. I'm not
> attached to them.
> 
> I was picturing that we would first implement all or most of our
> editing code on top of the editing API and then, once we were
> confident with it, expose it as a webkit prefixed set of APIs that we
> propose to the appropriate standards body. I'd like to see an approach
> to this where we move (incrementally) in the direction of a clearly
> defined editing API that the editing code uses that we can eventually
> expose to the web.
> 
> I'll try and make some concrete proposals in the coming days.

I think this carries an assumption that the right internal abstractions are 
necessarily also a sensible public API. I don't know if that is a good 
assumption. 

First: It is tempting to argue along the lines of "the pieces needed to 
implement API X must be powerful primitives which should be exposed as API in 
their own right". But at some level, there has to be a next layer of 
implementation down that is not exposed, so clearly this line of argument has 
limits. It can't be API turtles all the way down.

Second, often the right internal implementation strategy bears very little 
relation to the proper public API. For example, CSS is a reasonable 
constraint-based system to express layout and style rules. Web designers seem 
to get along ok with it. But internally it's implemented via the render tree, 
which is a very different abstraction, though it relates to CSS concepts. 
Exposing the render tree in every detail would greatly constrain our ability to 
change implementation strategy in the future. So this is one clear-cut case 
where the implementation abstractions do not necessarily make sense as API. To 
give a simpler and more pervasive example, we use refcounting throughout many 
pieces of WebCore, but it would not be appropriate to expose to Web content 
because it's too low-level. I could cite endless examples where the public API 
exposed to Web content ends up very different from internal abstractions. The 
DOM is probably the one major subsystem where there is a lot of similarity, and 
even then, many critical implementation interfaces are not exposed, nor should 
they be.

Third, in the case of editing specifically, much of the existing behavior, in 
response to user actions and things like the execCommand API, has *really* 
weird quirks. And some of its behavior is probably wrong in light of what other 
browsers do. It may be that the pieces needed to build all those quirky 
behaviors are not really sane as a public API.

Overall, I think the API design process should work in the opposite direction. 
You do

[webkit-dev] HTML5 tree builder enabled

[Adam Barth]

The HTML5 tree builder is enabled as of
.  Check out our awesome
SVG-in-HTML demo (in a post r64712 build, of course):

http://trac.webkit.org/export/LATEST/trunk/LayoutTests/svg/in-html/circle.html

In light of the other thread about wanting more blog posts, I'm
working on a blog post about this change that I hope to post some time
later today.  If we've horribly broken everything, please file a bug
and CC me and Eric.

Thanks again,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev