Re: [webkit-dev] free functions

[Chris Jerdonek]

On Tue, May 25, 2010 at 10:01 AM, Darin Adler  wrote:
> On May 25, 2010, at 7:54 AM, Chris Jerdonek wrote:
>
>> I sometimes come across public member functions whose implementations do not 
>> depend on private data.
>>
>> There is a school of thought that such functions are better non-member 
>> because it reduces the number of functions coupled to private data. On the 
>> other hand, I've heard the argument that making such functions free creates 
>> naming issues -- it's not clear to the caller in which header file to find 
>> the free function.
>>
>> My question for WebKit is whether naming considerations outweigh 
>> encapsulation considerations.  And if so, is there a naming convention or 
>> otherwise that we can use to make finding free functions easier?
>
> We do need our classes to be smaller so we can understand the structure of 
> the code. The encapsulation benefits of having a much smaller number of 
> members in a class are well worth some cost. But there are at least two 
> considerations that come into play when replacing a member function with a 
> free function:
>
>    1) Free functions still have to go in some header/source file. The usual 
> rule for finding a function is to look for a file named based on the class. 
> Without a class name we have to do something to make it practical to find the 
> functions in the source tree without a lot of searching.
>
>    2) Free functions need names that are clear and unambiguous with no 
> context other than the WebCore namespace. We try to keep member function 
> names short, and we can do so in part because they have a class name context. 
> The same function as a free function will almost certainly need a longer 
> name. Each time we create a free function we have to think about what an 
> appropriate name is; it’s a mistake to leave the same short name that was 
> previously used for a class member.
>
> Another possible way to get encapsulation benefits with fewer of the other 
> problems is to group functions into classes or namespaces that have no data 
> and nothing else private. This may be helpful if the class or namespace name 
> has a good name with a clear concept.


Would the following simple convention be an acceptable option?  A free
function in a header file could go in a nested namespace whose name is
the name of the header file followed by "Functions" (as in "free
functions").  An example in Chrome.h might be--

WebCore::ChromeFunctions::applyWindowFeatures(Chrome*, const WindowFeatures&);

Would adding such a non-member function be preferable to adding to the
Chrome class a public member function that didn't depend on private
Chrome data?  The encapsulation discussion above suggests it would.

I'm just trying to think of a simple alternative so the default need
not always be to add another member function.

For comparison, we have essentially 8 files whose file name ends in "Functions":

JavaScriptCore/API/JSCallbackObjectFunctions.h
JavaScriptCore/runtime/JSGlobalObjectFunctions.*
JavaScriptCore/wtf/HashFunctions.h
JavaScriptCore/wtf/StringHashFunctions.h
WebCore/bindings/js/JSPluginElementFunctions.*
WebCore/dom/PositionCreationFunctions.h
WebCore/xml/XPathFunctions.*
WebKit/mac/Plugins/WebNetscapeDeprecatedFunctions.*

(For files like these, we would probably not want to use a convention
like the above.)

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

[webkit-dev] free functions

[Chris Jerdonek]

Hi, I have a question regarding WebKit's stance on free functions.

I sometimes come across public member functions whose implementations
do not depend on private data.

There is a school of thought that such functions are better non-member
because it reduces the number of functions coupled to private data.
On the other hand, I've heard the argument that making such functions
free creates naming issues -- it's not clear to the caller in which
header file to find the free function.

My question for WebKit is whether naming considerations outweigh
encapsulation considerations.  And if so, is there a naming convention
or otherwise that we can use to make finding free functions easier?

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

Re: [webkit-dev] What is the webkit-patch version of svn-unapply?

[Chris Jerdonek]

On Wed, May 19, 2010 at 11:22 AM, Jeremy Orlow  wrote:
> On Wed, May 19, 2010 at 7:15 PM, Adam Barth  wrote:
>> Another option is that the upload command could store a copy of the patch
>> locally that you could then use with svn-apply and svn-unapply
>> directly.
>
> What if we added an option to webkit-patch upload that unapplies the patch
> at the end?  In fact, for the first iteration, it could simply save the
> patch in some temporary location and then run 'svn-unapply'.  In other
> words, do what you just described but without the second webkit-patch run.

I've always wondered the extent to which svn-unapply works for people.
 It seems like sometime back, svn-unapply got behind svn-apply in
terms of functionality (perhaps around the time that support for Git
binary diffs was added to svn-apply).  This can happen because
svn-unapply is written separately from svn-apply.  They don't share
the same code path and so can get out of synch (this is a FIXME).
Maybe when Git users add functionality to svn-apply, they see less of
a need to make the corresponding change to svn-unapply since they
already have git-reset.  But I don't recall seeing any bug reports or
complaints about this from svn-unapply users.

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

Re: [webkit-dev] converting by constructor

[Chris Jerdonek]

On Mon, May 17, 2010 at 3:11 PM, Darin Adler  wrote:
> I think the best way for us to clarify our guideline for this would be to 
> discuss a few individual cases where we have a non-explicit constructor. We 
> can talk about why they are not explicit and see if we find they are just 
> bugs or show a principle at work.


I wasn't intending to create a formal guideline, but one example I encountered
recently is ResourceRequest, which has String and KURL single-parameter
constructors without the explicit keyword.

The FrameLoader class has about 25 methods that accept a ResourceRequest
(e.g. various load methods), so all of these also accept a String and
KURL.  This makes it harder to know the right way these methods
should be getting called.  This also makes it harder to refactor.  Call
sites seem to use all three variations.  The class also has other load-like
methods that accept a String url, and others that accept a KURL url.

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

[webkit-dev] converting by constructor

[Chris Jerdonek]

Hi, I have a basic question.  What has been WebKit's stance on the use of the
explicit keyword (for higher-level objects in particular)?  Do we prefer the
looser API's that conversion by constructor affords, or do we more often
discourage relying on conversion by constructor?

For comparison, the Google C++ style guide says the explicit keyword should
almost always be used.  Note that I'm not suggesting that this be added to
our style guide.

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

Re: [webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit

[Chris Jerdonek]

Thanks, Ojan.

On Sun, May 16, 2010 at 8:26 AM, Ojan Vafai  wrote:
> On Sat, May 15, 2010 at 2:17 PM, Chris Jerdonek 
> wrote:
>>  In particular, --git-commit=HEAD.. should be just the
>> uncommitted changes (staged and unstaged).
>
> This one I'm a bit iffy on. Should this include the commit at head? I think
> it should.

Currently, when using check-webkit-style for example, I need to pass
--git-commit=HEAD^.. to include the commit at head.  In other words,
it operates on ranges like the above exclusively with respect to the
endpoint.  This is similar to how git-diff behaves and is described
here:

http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html

Were you thinking about changing this behavior?

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

Re: [webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit

[Chris Jerdonek]

On Sat, May 15, 2010 at 2:17 PM, Chris Jerdonek  wrote:
> On Fri, May 14, 2010 at 6:29 PM, Ojan Vafai  wrote:
>> There's a couple edge cases that are unclear to me. a) How do you upload
>> just the working copy? Is that the default? b) Does --git-commit=* include
>> the working copy? I think it should.
>
>
> For check-webkit-style, I believe all uncommitted changes used to be the
> default (staged and unstaged).  check-webkit-style also used to include
> unstaged changes when using the --git-commit syntax (now it doesn't).
>
> Personally, I think webkit-patch and check-webkit-style should include
> unstaged changes when using the ".." syntax.  I also don't think it
> would be important for the scripts to make a distinction between unstaged
> and staged changes -- in part because svn-apply does not behave uniformly
> in this regard.  In particular, --git-commit=HEAD.. should be just the
> uncommitted changes (staged and unstaged).


I also meant to add--

In line with my original suggestion, I think webkit-patch should default to
the uncommitted changes (staged and unstaged) only if there are no local
commits.  Otherwise, barring configuration settings that may override
this behavior, it should error out/prompt the user.

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

Re: [webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit

[Chris Jerdonek]

Thanks for your responses, Ojan.

On Fri, May 14, 2010 at 6:29 PM, Ojan Vafai  wrote:
>> Maybe it already does this, but would it be possible to make the default
>> behavior be to throw an error if there is more than one possibility for
>> what should be committed?
>
> That's what it currently does.
>
>> It seems like this would reduce the chance of
>> accidentally committing the wrong information.  A configuration option
>> could still be used to override this behavior for those who know they want
>> to use one of the two behaviors exclusively.
>
> I think the --squash behavior is actually pretty simple. It's a lot like
> svn. It commits everything in your branch. End of story. Now
> that https://bugs.webkit.org/show_bug.cgi?id=38852 is almost fixed, it's
> much safer as well.


Yes, it's simple.  My point was that it may be safer if the script did not
commit everything by default.  That way we avoid accidental over-commits if
one forgets to type --git-commit or overlooks that their branch contains
multiple patches.

>> I also suggest this because it's not clear to me that there are only two
>> camps.  For example, I maintain one branch per bug (branch-per-bug), but I
>> will often create a branch from one of these when working on a bug that
>> depends on another of my bugs being landed (commit-per-bug).  So I can see
>> myself using both options.
>
> I don't actually see what the third option here is. I'd call both of those
> approaches branch-per-bug. You'll commit the first branch using --squash and
> then you can commit the second branch with --squash. That said, I find
> myself using --squash ~80% of the time and --git-commit the other 20%.
> Changing the default or the webkit-patch.squash value does not preclude you
> using another value via the command-line (i.e. command-line overrides both).


In my workflow I maintain one branch per bug.  I also maintain one commit
per bug because I commit locally using --amend.  So normally I would not
have a need for --squash.  In addition, when I am working on sequential
patches, there are points in my workflow where I have multiple uncommitted
bugs on a single branch.  My main reason for describing this scenario was
to illustrate a workflow where defaulting to committing everything would
increase the likelihood of an accidental over-commit (since I sometimes
have multiple bugs on a branch).

>> Finally, I'm wondering if the three options above could perhaps be
>> simplified
>> to a single option if we made it clear that webkit-patch supports working
>> with only one revision at a time.
>
> I agree, but you're essentially saying everyone should use branch-per-bug.
> There are enough people who specifically use git for the commit-per-bug
> approach that I don't think webkit-patch will meet everyone's needs if we do
> this.


It would support a commit-per-bug workflow.  Just not committing a patch
series all at once with a single invocation of webkit-patch (at least
for now -- see below).

>> If webkit-patch supported only one revision at a time, then it seems like
>> the three options could be reduced to a single --git-commit option, which
>> would specify which commits should go into creating the single
>> revision/patch.
>
> I would be very happy with this. It would greatly simplify webkit-patch
> (both the code and usage). However, we're basically saying we won't
> explicitly support commit-per-bug workflows. If someone wanted to
> upload/commit a range of commits as separate patches, they need to do each
> one as a separate command. That said, people who want to do commit-per-bug
> workflow could easily write a script that calls webkit-patch in a loop for
> each commit.


Yes, adding support via looping is what I had in mind (at least initially).
That way we can focus on simplifying and nailing down the semantics for the
single-patch use case before working out the semantics of committing multiple
patches at once.

> There's a couple edge cases that are unclear to me. a) How do you upload
> just the working copy? Is that the default? b) Does --git-commit=* include
> the working copy? I think it should.


For check-webkit-style, I believe all uncommitted changes used to be the
default (staged and unstaged).  check-webkit-style also used to include
unstaged changes when using the --git-commit syntax (now it doesn't).

Personally, I think webkit-patch and check-webkit-style should include
unstaged changes when using the ".." syntax.  I also don't think it
would be important for the scripts to make a distinction between unstaged
and staged changes -- in part because svn-apply does not behave uniformly
in this regard.  In particular, --git-commit=HEAD.. should be just the
uncommitted changes (staged and unstaged).

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

Re: [webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit

[Chris Jerdonek]

On Thu, May 13, 2010 at 11:13 AM, Ojan Vafai  wrote:
> I finally updated this
> page http://trac.webkit.org/wiki/UsingGitWithWebKit#webkit-patchcheck-webkit-styleandgit.
> As is clear from that, my earlier description of --no-squash was totally
> inaccurate. Sorry, I was being rushed. --no-squash and --git-commit still
> need significant work before they will work in the way the commit-per-bug
> camp wants it to. It's not too much work, but it's not trivial either.
> There are two clear camps with webkit-patch git usage. commit-per-bug and
> branch-per-bug. webkit-patch should support both. Which one is the default
> is a matter of preference. The current default is confusing and meets noones
> needs. I don't care which is the default as long as it's not the current
> middle-ground. I'd still like to make --squash the default since it is
> basically complete (except
> for https://bugs.webkit.org/show_bug.cgi?id=38852).
> There is little active work on --no-squash and --git-commit, so it's not
> clear how soon they'll be completed. So, unless the are objections, I'd like
> to do the following:
> 1. Fix https://bugs.webkit.org/show_bug.cgi?id=38852
> 2. Pick a date, e.g., June 1st, to make --squash the default. Send many
> ALL_CAPS emails warning people that the default behavior for webkit-patch
> and git checkouts is going to change.
> 3. Change it on June 1st.
> Which behavior is the default really doesn't matter since you can set
> webkit-patch.squash in your git config. I just want to get rid of the
> current default behavior and --no-squash isn't ready for that.


Maybe it already does this, but would it be possible to make the default
behavior be to throw an error if there is more than one possibility for
what should be committed?  It seems like this would reduce the chance of
accidentally committing the wrong information.  A configuration option
could still be used to override this behavior for those who know they want
to use one of the two behaviors exclusively.

I also suggest this because it's not clear to me that there are only two
camps.  For example, I maintain one branch per bug (branch-per-bug), but I
will often create a branch from one of these when working on a bug that
depends on another of my bugs being landed (commit-per-bug).  So I can see
myself using both options.

Finally, I'm wondering if the three options above could perhaps be simplified
to a single option if we made it clear that webkit-patch supports working
with only one revision at a time.  It doesn't seem like the semantics of
webkit-patch extend clearly to multiple revisions.  For example, would
the --reviewer flag need to be a delimited list to support one reviewer
per revision, and would --test cause the tests to be run before all
revisions, or before each revision?

If webkit-patch supported only one revision at a time, then it seems like
the three options could be reduced to a single --git-commit option, which
would specify which commits should go into creating the single revision/patch.
>From this perspective, the --squash option seems equivalent to specifying
"all local changes" for the --git-commit option.  If we were to do this,
maybe the --squash option could be replaced by a special value for the
--git-commit option (for example --git-commit=*), and there could still
be a configuration value to specify that --git-commit should always be "*".

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

Re: [webkit-dev] Python on the Tiger build bot

[Chris Jerdonek]

[Re-sending from correct address]

On Fri, May 7, 2010 at 9:10 PM, Eric Seidel  wrote:
> I'm happy to add a brief note to the tools.html page noting that
> python 2.5 is required and linking to a page.

A couple months ago I started a page that contains instructions on how
to upgrade:

http://trac.webkit.org/wiki/PythonGuidelines#UpgradingfromPython2.3orPython2.4

> Our scripts already print:
> webkitpy.python24.versioning: [WARNING] WebKit Python scripts do not
> support your current Python version (2.4.6).  The minimum supported
> version is 2.5.
>
> I'm happy to augment that warning to provide a download URL.

That message already contains an URL actually (as of 5 weeks ago):

test-webkitpy: WARNING  WebKit Python scripts do not support your
current Python version (2.4.6).  The minimum supported version is 2.5.
 See the following page to upgrade your Python version:

   http://trac.webkit.org/wiki/PythonGuidelines

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

[webkit-dev] svn-apply regression

[Chris Jerdonek]

Hi folks,

This e-mail is to let you know about a regression in svn-apply that
was discovered and fixed tonight and that may have affected you.

The regression is most likely to have affected you if, in the last 5
days (after r58495), you committed a patch that was an "e-mail diff"
using svn-apply's --force option (e.g. using the commit-queue).

Briefly, the regression would have caused the first file in your patch
to be skipped if your patch was an e-mail diff.  Thus, you may want to
review your recent commits to verify that the first file in each
commit was checked in.

The regression is described in more detail here:

https://bugs.webkit.org/show_bug.cgi?id=38507

We have slowly been increasing the code coverage of svn-apply and
-unapply, and the regression happened to be in the part that does not
yet have coverage.  In the future, we may want to consider adjusting
svn-apply and -unapply so that it does not routinely need to be run in
--force mode.  --force mode connotes something that should be done
less frequently and under more closely controlled and observed
settings.

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

Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths

[Chris Jerdonek]

On Sun, Apr 18, 2010 at 4:11 PM, Maciej Stachowiak  wrote:
> That reminds me, we should turn off the 80-column limit on bugs.webkit.org -
> there's no need for it to hard-wrap your text.

Great, I was wondering about that.  I filed a report for that here:

https://bugs.webkit.org/show_bug.cgi?id=37792

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

Re: [webkit-dev] python coding style, PEP-8, and 80-column line widths

[Chris Jerdonek]

I wanted to add a couple comments and a question to this discussion.

On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak  wrote:
>
> I haven't contributed to WebKit's Python code yet, but I will say that I
> agree with Eric's sentiments here. 80-column limit is archaic and pointless.
> No one is developing WebKit on a vt220.

Note that there are contexts where the limit does come into play that the
user might not have as much control over, for example pasting into the body
of an e-mail or into the comment box in bugs.webkit.org.

Take a look at these two comments for example (which, incidentally, are
about crash logs rather than code):

https://bugs.webkit.org/show_bug.cgi?id=23558#c4
https://bugs.webkit.org/show_bug.cgi?id=36707#c1

So non-Python developers know, one argument for treating Python differently
(aside from PEP8) is that the language supports a syntax for continuing
lines to the next line that other languages don't (implied line continuation).

Finally, just to clarify, which parts of PEP8 are we discussing ignoring?
PEP8 has more specific guidelines for docstrings and how they should be
formatted.  For instance, it also contains this guideline in addition to
the blanket 79-character limit:  "For flowing long blocks of text (docstrings
or comments), limiting the length to 72 characters is recommended."

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

Re: [webkit-dev] Join the URL hackathon (already in progress)!

[Chris Jerdonek]

Regarding the URL parsing code, could someone that attended the
session list what steps were proposed or tentatively agreed to (of
which the below is the first)?

Thanks a lot,
--Chris



On Tue, Apr 13, 2010 at 1:46 AM, Adam Barth  wrote:
> Have you ever wanted WebKit's URL parsing to be awesome?  Do crazy
> characters in URLs keep you up at night?  Do you love writing tests?
>
> If you answered yes to any of these questions, you might want to join
> the URL hackathon.  In this hackathon, we're adding a ton of test of
> our URL parsing code by adapting a BSD-licensed unit test suit into a
> set of LayoutTests.
>
> You can find the instructions and sign-up sheet at following URL:
>
> http://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTVnZmZ3dGNmNg&hl=en
>
> Thanks, and happy hacking!
> 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] How are discussions about patches working on bugzilla?

[Chris Jerdonek]

No, you shouldn't flip the flag back to r? to continue discussing.
Generally speaking, people on the CC list do receive an e-mail when
you post an additional comment.  After submitting a comment to
bugs.webkit.org, you can see for sure who will be receiving an e-mail
with the comment since the web page displays the list of addresses
that will be e-mailed.

You might just have to be more patient with the reviewers.  If you
don't receive requested feedback after a few days or so (the period of
time is up to your discretion), you may wish to post another comment
to remind those in question that you're still awaiting feedback.

--Chris


On Sun, Apr 11, 2010 at 12:34 PM, Stephan Assmus  wrote:
> Hi all,
>
> so far I've made the experience that if patches received an initial review
> with r-, then if I give further feedback on the patch and try to discuss
> the best way to resolve it, I am not receiving any more comments on the
> ticket unless I actually attach a new patch. Am I supposed to change the
> review flag back to "r?" to get additional feedback for the same patch? So
> far I thought that all people in the bug's CC list receive email
> notifications for additional comments. Is this not the case? Here are some
> specific bugs where I am waiting for feedback:
>
> 
> 
>
> best regards,
> -Stephan
> ___
> 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] Announcing a WebKit Contributors Meeting on April 12 and 13 at Apple's campus in Cupertino, CA

[Chris Jerdonek]

I started an unofficial sign-up list for the April 12-13 WebKit meeting here:

https://trac.webkit.org/wiki/April%202010%20Meeting

The page might be useful for other things as the meeting nears.



On Tue, Mar 9, 2010 at 2:27 PM, William Siegrist  wrote:
> On Mar 9, 2010, at 1:14 PM, Adam Roben wrote:
>
>> On Mar 9, 2010, at 4:05 PM, Eric Seidel wrote:
>>
>>> Is there any way to see who has registered?  Or is that something
>>> we'll need to make a wiki signup list for or similar?
>>
>> There isn't currently. Bill Siegrist (_wms) set up the page and knows the 
>> details of how hard that would be to do.
>>
>
>
> Its not hard, but I did not make a public page for that since it could have 
> some privacy implications.
>
> -Bill
>
> ___
> 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

[webkit-dev] webkit python code reorganization

[Chris Jerdonek]

Hi folks, I just wanted to let you know that the WebKit project's
Python code should be a lot easier to navigate and work in now.

Tonight, Adam Barth and I (along with Eric Seidel's blessing) moved
almost all of the modules in WebKitTools/Scripts/webkitpy into
appropriate subfolders of webkitpy (along with some other, similar
high-level clean-ups):

https://bugs.webkit.org/show_bug.cgi?id=36093

These changes should make the dependencies in webkitpy much easier to
discover and comprehend, and more inviting in general for people newer
to the code.  This is something we have wanted to do for quite a while
now.

Finally, a summary of how webkitpy/ is organized will go here:
https://trac.webkit.org/wiki/PythonGuidelines

Feel free to contact any of us if something in the scripts is not
working as expected, or if you detect a possible breakage due to these
changes.

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

Re: [webkit-dev] WebKit Icon license?

[Chris Jerdonek]

On Tue, Mar 23, 2010 at 3:31 AM, Jeremy Orlow  wrote:
> And does anyone know where the original artwork is and/or came from?

Here is a clue:

http://trac.webkit.org/browser/trunk/PlanetWebKit/wwwroot/images/planet-webkit.png?rev=28380

The "Tim" mentioned here (who potentially put the logo together) seems
to be Timothy Hatcher, and pewtermo...@webkit.org seems to be Matt
Lilek.


>
> On Tue, Mar 23, 2010 at 10:25 AM, Jeremy Orlow  wrote:
>>
>> It seems as though we should at very least change the main icon on
>> webkit.org to match what is apparently the official webkit logo.  The icons
>> for the Mac and Windows nightlies probably needn't change since they're run
>> within Safari anyway, but probably the nightly source icon should change.
>>  Anyone disagree?
>> I'll spin up a patch later this week.
>> J
>>
>> On Tue, Mar 23, 2010 at 6:02 AM, Eric Seidel  wrote:
>>>
>>> So it would appear then that www.webkit.org and nightly.webkit.org are
>>> the odd men out. :)
>>>
>>> On Mon, Mar 22, 2010 at 10:57 PM, Sam Weinig 
>>> wrote:
>>> > And our own http://planet.webkit.org/.
>>> > -Sam
>>> >
>>> > On Mon, Mar 22, 2010 at 3:11 PM, Chris Jerdonek 
>>> > wrote:
>>> >>
>>> >> On Mon, Mar 22, 2010 at 2:30 PM, Eric Seidel  wrote:
>>> >> > Interesting.  Looks like the WebKit icon on CIA is different from
>>> >> > webkit.org.  I could have sworn they used to be the same:
>>> >> > http://cia.vc/stats/project/webkit
>>> >>
>>> >> That's also the icon used for the WebKit group on LinkedIn:
>>> >>
>>> >> http://www.linkedin.com/groups?about=&gid=91394
>>> >>
>>> >> [Resent from correct address.]
>>> >>
>>> >>
>>> >> >
>>> >> > -eric
>>> >> >
>>> >> > On Mon, Mar 22, 2010 at 11:07 AM, Kenneth Christiansen
>>> >> >  wrote:
>>> >> >> Contest is fine :-) That is how our designers created the Maemo
>>> >> >> logo:
>>> >> >>
>>> >> >> https://wiki.maemo.org/Task:maemo.org_logo_contest
>>> >> >> http://wiki.maemo.org/Maemo.org_logo_contest_submissions
>>> >> >>
>>> >> >> I'm cc'ing Marcelo, who is our Brazilian Head of User Experience
>>> >> >> and
>>> >> >> Design.
>>> >> >>
>>> >> >> Cheers,
>>> >> >> Kenneth
>>> >> >>
>>> >> >> On Mon, Mar 22, 2010 at 12:55 PM, Dimitri Glazkov
>>> >> >>  wrote:
>>> >> >>> I just reached out to the Russian icon powerhouse, Turbomilk
>>> >> >>> (turbomilk.com), and they're interested in pitching in as well.
>>> >> >>> Maybe
>>> >> >>> we should have a contest?
>>> >> >>>
>>> >> >>> :DG<
>>> >> >>>
>>> >> >>> On Mon, Mar 22, 2010 at 5:43 AM, Kenneth Christiansen
>>> >> >>>  wrote:
>>> >> >>>> I have asked our designers to look into it :-)
>>> >> >>>>
>>> >> >>>> Kenneth
>>> >> >>>>
>>> >> >>>> On Mon, Mar 22, 2010 at 8:42 AM, Jeremy Orlow
>>> >> >>>> 
>>> >> >>>> wrote:
>>> >> >>>>> On Fri, Mar 19, 2010 at 4:00 PM, Darin Adler 
>>> >> >>>>> wrote:
>>> >> >>>>>>
>>> >> >>>>>> On Mar 19, 2010, at 8:40 AM, Dimitri Glazkov wrote:
>>> >> >>>>>>
>>> >> >>>>>> > Would you happen to know how WebKit icon is licensed?
>>> >> >>>>>>
>>> >> >>>>>> The icon currently on webkit.org has the icon for Apple’s
>>> >> >>>>>> Safari
>>> >> >>>>>> web
>>> >> >>>>>> browser in it. Because of that, Apple has provided no license
>>> >> >>>>>> to
>>> >> >>>>>> use the
>>> >> >>>>>> icon; we are continuing to use it with informal permission fr

Re: [webkit-dev] file names with spaces

[Chris Jerdonek]

On Mon, Mar 22, 2010 at 10:46 PM, Maciej Stachowiak  wrote:

> The most unavoidable exceptions seem to be for test cases that are
> specifically testing what happens when you have a space in the filename, not
> for third-party code. Does the no-spaces rule make it easier to write shell
> commands if there are still files that violate it?

If such files are fewer or limited to certain directories, it would be
easier to screen them out using primitive techniques (e.g. excluding a
test directory).

In my case, I executed a command like the following (simplifying it
for the sake of an example):

find WebKitTools -type f -wholename '*' \
 \! \( -wholename '*.svn*'  \) \
 -print0 | xargs sed -i '' -e ''

but got the following error--

sed: Layout: No such file or directory

because of this file--

./WebKitTools/DumpRenderTree/fonts/WebKit Layout Tests 2.ttf

My problem was that I left out the "-0" after xargs which I wouldn't
have otherwise needed.  While my issue was easy to fix, the following
page made it seem like it can be especially tricky to deal with spaces
if you are doing something more complicated:

http://www.macgeekery.com/tips/cli/handling_filenames_with_spaces_in_bash

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

Re: [webkit-dev] file names with spaces

[Chris Jerdonek]

On Mon, Mar 22, 2010 at 10:29 PM, Adele Peterson  wrote:
>
> On Mar 22, 2010, at 10:24 PM, Chris Jerdonek wrote:
>
>> I was wondering if there are any reasons we would ever need files in
>> our repository whose file names contain spaces.  The reason is that it
>> makes shell commands slightly trickier to write (e.g. using the bash
>> shell).
>>
>> I found that we currently have these files whose file names have spaces:
>>
>>> find . -wholename '* *' \! \( -wholename '*.svn*' -or -wholename 
>>> "*/WebKitBuild/*" \)
>>
>> ./LayoutTests/fast/encoding/resources/%25%u0435 0 %xx%%%ulike.html
>> ./LayoutTests/http/tests/misc/resources/a success.html
>> ./PageLoadTests/svg/files/42450-under the see.svg
>> ./PageLoadTests/svg/files/44057-drops on a blade.svg
>> ./WebCore/manual-tests/inspector/errors-with-space in-url.html
>
>        This one seems intentional.

Yes.  I think it's to be expected that rules will occasionally need to
be violated -- especially for testing purposes (e.g. tabs and trailing
spaces in test files).

Another possibility is landing third-party code as-is.

I guess I'm asking if it would be okay to establish a rule for cases
we control and that do not have a special need.

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

[webkit-dev] file names with spaces

[Chris Jerdonek]

I was wondering if there are any reasons we would ever need files in
our repository whose file names contain spaces.  The reason is that it
makes shell commands slightly trickier to write (e.g. using the bash
shell).

I found that we currently have these files whose file names have spaces:

> find . -wholename '* *' \! \( -wholename '*.svn*' -or -wholename 
> "*/WebKitBuild/*" \)

./LayoutTests/fast/encoding/resources/%25%u0435 0 %xx%%%ulike.html
./LayoutTests/http/tests/misc/resources/a success.html
./PageLoadTests/svg/files/42450-under the see.svg
./PageLoadTests/svg/files/44057-drops on a blade.svg
./WebCore/manual-tests/inspector/errors-with-space in-url.html
./WebKitSite/demos/transitions-and-transforms/Finder Coverflow.png
./WebKitSite/demos/transitions-and-transforms/Mail Stationery.png
./WebKitSite/demos/transitions-and-transforms/Quick Look.png
./WebKitSite/demos/transitions-and-transforms/Time Machine.png
./WebKitTools/DumpRenderTree/fonts/WebKit Layout Tests 2.ttf
./WebKitTools/DumpRenderTree/fonts/WebKit Layout Tests.ttf

Can we make it a part of our style guide that file names shouldn't have spaces?

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

Re: [webkit-dev] WebKit Icon license?

[Chris Jerdonek]

On Mon, Mar 22, 2010 at 2:30 PM, Eric Seidel  wrote:
> Interesting.  Looks like the WebKit icon on CIA is different from
> webkit.org.  I could have sworn they used to be the same:
> http://cia.vc/stats/project/webkit

That's also the icon used for the WebKit group on LinkedIn:

http://www.linkedin.com/groups?about=&gid=91394

[Resent from correct address.]


>
> -eric
>
> On Mon, Mar 22, 2010 at 11:07 AM, Kenneth Christiansen
>  wrote:
>> Contest is fine :-) That is how our designers created the Maemo logo:
>>
>> https://wiki.maemo.org/Task:maemo.org_logo_contest
>> http://wiki.maemo.org/Maemo.org_logo_contest_submissions
>>
>> I'm cc'ing Marcelo, who is our Brazilian Head of User Experience and Design.
>>
>> Cheers,
>> Kenneth
>>
>> On Mon, Mar 22, 2010 at 12:55 PM, Dimitri Glazkov  
>> wrote:
>>> I just reached out to the Russian icon powerhouse, Turbomilk
>>> (turbomilk.com), and they're interested in pitching in as well. Maybe
>>> we should have a contest?
>>>
>>> :DG<
>>>
>>> On Mon, Mar 22, 2010 at 5:43 AM, Kenneth Christiansen
>>>  wrote:
 I have asked our designers to look into it :-)

 Kenneth

 On Mon, Mar 22, 2010 at 8:42 AM, Jeremy Orlow  wrote:
> On Fri, Mar 19, 2010 at 4:00 PM, Darin Adler  wrote:
>>
>> On Mar 19, 2010, at 8:40 AM, Dimitri Glazkov wrote:
>>
>> > Would you happen to know how WebKit icon is licensed?
>>
>> The icon currently on webkit.org has the icon for Apple’s Safari web
>> browser in it. Because of that, Apple has provided no license to use the
>> icon; we are continuing to use it with informal permission from Apple.
>
> Given that WebKit has been more than just the rendering engine Safari uses
> for quite some time now, I wonder if it'd be worth trying to come up with
> something unique for the project.  One benefit would be that it could be
> used more freely.
> Anyone with graphic design skillz going to the WebKit meeting?  :-)
> J
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>



 --
 Kenneth Rohde Christiansen
 Technical Lead / Senior Software Engineer
 Qt Labs Americas, Nokia Technology Institute, INdT
 Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

>>>
>>
>>
>>
>> --
>> Kenneth Rohde Christiansen
>> Technical Lead / Senior Software Engineer
>> Qt Labs Americas, Nokia Technology Institute, INdT
>> Phone  +55 81 8895 6002 / E-mail kenneth.christiansen at openbossa.org
>> ___
>> 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
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] minimum python version to support

[Chris Jerdonek]

Mechanize (and ClientForm on which it depends) does work with Python 2.4:

http://wwwsearch.sourceforge.net/mechanize/

(See the section on compatibility.)


On Fri, Mar 19, 2010 at 9:19 AM, Adam Barth  wrote:
> My understanding is that some of the libraries we use, like Mechanize,
> don't work in Python 2.4.  My complaint in Bug 36063 is that we're
> re-implementing Mechanize poorly.  I'd rather we just upgraded the
> machines that need to run-webkit-tests to a more modern version of
> Python.
>
> Adam
>
>
> On Fri, Mar 19, 2010 at 7:41 AM, Chris Jerdonek  wrote:
>> No one responded back with a summary of the Python 2.4 discussion, so
>> I'll attempt a summary of my own after reading--
>>
>> https://bugs.webkit.org/show_bug.cgi?id=35584
>>
>> (If you recall, we are trying to decide what Python code we write
>> needs to work with Python 2.4.)
>>
>> The Chromium project still uses Python 2.4 in a significant way.  Some
>> Chromium bots run new-run-webkit-tests using 2.4, and a number of
>> developers use 2.4 in their development environments.  Generally
>> speaking, people support upgrading, but no one is spearheading an
>> upgrade and there is no ETA.
>>
>> For the time being, because of the bots, it seems like
>> new-run-webkit-tests definitely needs to keep working with 2.4.  But
>> for the tools used more in the development environment (webkit-patch,
>> etc), it seems like people would be willing to find a way to make
>> things work with 2.5+.
>>
>> It would be pretty easy to get all of our Python code working with 2.4
>> (we had a patch for this a couple weeks ago), but going back wouldn't
>> let us use some of the nicer constructs.  And we would have to contend
>> with at least one bug in 2.4.
>>
>> (End of summary.)
>>
>> Plainly, the options seem to be--
>>
>> (1) All Python 2.5+
>> (2) All Python 2.4
>> (3) Some combination of (1) and (2) (e.g. new-run-webkit-tests 2.4,
>> everything else 2.5)
>>
>> However, (1) does not seem to be an option.  Personally, I'm starting
>> to lean more toward to (2).  One reason is that we are already
>> starting to see a case of re-implementing in Python 2.4 (for
>> new-run-webkit-tests) code that was already written in 2.5:
>>
>> https://bugs.webkit.org/show_bug.cgi?id=36063#c4
>>
>> I also think it would be helpful if we did not need to have this
>> discussion for each new script we decide to write in Python.  I would
>> be willing to update the patch from a couple weeks ago that adjusts
>> things for 2.4.
>>
>> --Chris
>>
>>
>>
>>
>> On Sun, Mar 7, 2010 at 4:18 PM, Chris Jerdonek  wrote:
>>> On Fri, Mar 5, 2010 at 6:43 PM, David Kilzer  wrote:
>>>> On Thu, March 4, 2010 at 5:35:08 PM, William Siegrist wrote:
>>>>
>>>>> Since I have a Tiger machine handy, I tested this and was able to build 
>>>>> python
>>>>> 2.5.5 from MacPorts on a PowerPC. It takes a while, but it worked. I did 
>>>>> not try
>>>>> python 2.6.
>>>>
>>>> I've installed python 2.6.4 using MacPorts on my PowerBook G4 running 
>>>> Tiger 10.4.11, and it's worked find with webkit-patch the one or two times 
>>>> I tried it.
>>>
>>> That sounds great.  Thanks a lot, Dave and Bill.  So does it seem safe
>>> to say, then, that folks on 2.3 can upgrade if it ever becomes
>>> necessary to use one of the tools?
>>>
>>> As for Python 2.4, I haven't been following the discussion as closely
>>> since it seems to affect Chromium developers more.  Can someone
>>> summarize the state of the discussion there -- does it seem like there
>>> is a consensus?
>>>
>>> --Chris
>>>
>> ___
>> 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] minimum python version to support

[Chris Jerdonek]

No one responded back with a summary of the Python 2.4 discussion, so
I'll attempt a summary of my own after reading--

https://bugs.webkit.org/show_bug.cgi?id=35584

(If you recall, we are trying to decide what Python code we write
needs to work with Python 2.4.)

The Chromium project still uses Python 2.4 in a significant way.  Some
Chromium bots run new-run-webkit-tests using 2.4, and a number of
developers use 2.4 in their development environments.  Generally
speaking, people support upgrading, but no one is spearheading an
upgrade and there is no ETA.

For the time being, because of the bots, it seems like
new-run-webkit-tests definitely needs to keep working with 2.4.  But
for the tools used more in the development environment (webkit-patch,
etc), it seems like people would be willing to find a way to make
things work with 2.5+.

It would be pretty easy to get all of our Python code working with 2.4
(we had a patch for this a couple weeks ago), but going back wouldn't
let us use some of the nicer constructs.  And we would have to contend
with at least one bug in 2.4.

(End of summary.)

Plainly, the options seem to be--

(1) All Python 2.5+
(2) All Python 2.4
(3) Some combination of (1) and (2) (e.g. new-run-webkit-tests 2.4,
everything else 2.5)

However, (1) does not seem to be an option.  Personally, I'm starting
to lean more toward to (2).  One reason is that we are already
starting to see a case of re-implementing in Python 2.4 (for
new-run-webkit-tests) code that was already written in 2.5:

https://bugs.webkit.org/show_bug.cgi?id=36063#c4

I also think it would be helpful if we did not need to have this
discussion for each new script we decide to write in Python.  I would
be willing to update the patch from a couple weeks ago that adjusts
things for 2.4.

--Chris




On Sun, Mar 7, 2010 at 4:18 PM, Chris Jerdonek  wrote:
> On Fri, Mar 5, 2010 at 6:43 PM, David Kilzer  wrote:
>> On Thu, March 4, 2010 at 5:35:08 PM, William Siegrist wrote:
>>
>>> Since I have a Tiger machine handy, I tested this and was able to build 
>>> python
>>> 2.5.5 from MacPorts on a PowerPC. It takes a while, but it worked. I did 
>>> not try
>>> python 2.6.
>>
>> I've installed python 2.6.4 using MacPorts on my PowerBook G4 running Tiger 
>> 10.4.11, and it's worked find with webkit-patch the one or two times I tried 
>> it.
>
> That sounds great.  Thanks a lot, Dave and Bill.  So does it seem safe
> to say, then, that folks on 2.3 can upgrade if it ever becomes
> necessary to use one of the tools?
>
> As for Python 2.4, I haven't been following the discussion as closely
> since it seems to affect Chromium developers more.  Can someone
> summarize the state of the discussion there -- does it seem like there
> is a consensus?
>
> --Chris
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] minimum python version to support

[Chris Jerdonek]

On Sun, Mar 7, 2010 at 5:32 PM, Maciej Stachowiak  wrote:
>
> On Mar 7, 2010, at 3:18 PM, Chris Jerdonek wrote:
>
>> On Fri, Mar 5, 2010 at 6:43 PM, David Kilzer  wrote:
>>>
>>> On Thu, March 4, 2010 at 5:35:08 PM, William Siegrist wrote:
>>>
>>>> Since I have a Tiger machine handy, I tested this and was able to build
>>>> python
>>>> 2.5.5 from MacPorts on a PowerPC. It takes a while, but it worked. I did
>>>> not try
>>>> python 2.6.
>>>
>>> I've installed python 2.6.4 using MacPorts on my PowerBook G4 running
>>> Tiger 10.4.11, and it's worked find with webkit-patch the one or two times I
>>> tried it.
>>
>> That sounds great.  Thanks a lot, Dave and Bill.  So does it seem safe
>> to say, then, that folks on 2.3 can upgrade if it ever becomes
>> necessary to use one of the tools?
>
> I'd prefer that we provide an easy means to do the install of Python 2.6
> (ideally a single script you can run, and ideally without affecting the
> system copy), rather than making every Tiger developer figure it out on
> their own.

Thanks, Maciej.  Certainly.  I created a wiki page recently where we
can put that information:

http://trac.webkit.org/wiki/PythonGuidelines

And it seems likely that we could turn those instructions into a
script over time.

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

Re: [webkit-dev] minimum python version to support

[Chris Jerdonek]

On Fri, Mar 5, 2010 at 6:43 PM, David Kilzer  wrote:
> On Thu, March 4, 2010 at 5:35:08 PM, William Siegrist wrote:
>
>> Since I have a Tiger machine handy, I tested this and was able to build 
>> python
>> 2.5.5 from MacPorts on a PowerPC. It takes a while, but it worked. I did not 
>> try
>> python 2.6.
>
> I've installed python 2.6.4 using MacPorts on my PowerBook G4 running Tiger 
> 10.4.11, and it's worked find with webkit-patch the one or two times I tried 
> it.

That sounds great.  Thanks a lot, Dave and Bill.  So does it seem safe
to say, then, that folks on 2.3 can upgrade if it ever becomes
necessary to use one of the tools?

As for Python 2.4, I haven't been following the discussion as closely
since it seems to affect Chromium developers more.  Can someone
summarize the state of the discussion there -- does it seem like there
is a consensus?

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

Re: [webkit-dev] minimum python version to support

[Chris Jerdonek]

[Resending from correct address.]

On Thu, Mar 4, 2010 at 1:05 PM, Maciej Stachowiak  wrote:

> 4) If we have a smooth way to do it, then locally installing a newer Python
> as part of the WebKit development process might be acceptable as a part of
> the WebKit. After all, everyone developing on Windows has to install it.

There is probably a smooth way.  I used MacPorts on Snow Leopard to
install Python 2.4.  This worked fine for me, and MacPorts says they
support Tiger:

http://www.macports.org/install.php#requirements

MacPorts also makes available a command called python_select that lets
you switch your system between versions, like so--

> python -V
Python 2.6.4
> sudo python_select python24
Selecting version "python24" for python
> python -V
Python 2.4.6

For the purposes of this discussion, can we assume this approach will
work on Tiger and is acceptable (to install Python 2.5)?  It would be
good to know the highest Python version that can be installed on Tiger
using MacPorts.

Otherwise, if we plan to require even just one of our Python tools to
work with 2.3, we should probably be structuring our code with that in
mind now.  For example, we may want to add another layer to the folder
hierarchy in our Python library to let us partition the code by what
version it supports.  It would be easier to do this sooner rather than
later.  (For the purposes of the future, it may make sense to be doing
something like this anyways -- I don't know.)

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

[webkit-dev] minimum python version to support

[Chris Jerdonek]

Recently, there has been some off-list discussion about the minimum
Python version WebKit should support (i.e. for the Python scripts in
WebKitTools/Scripts).

Up to this point, we haven't been explicit about it.  This ambiguity
has occasionally caused things to break for people using versions
before Python 2.6.

It seems pretty clear that we at least want to support Python 2.5.
The question that still remains is how many people are using Python
2.4, and whether Python 2.4 is worth supporting.

This thread collects a lot of the discussion:

https://bugs.webkit.org/show_bug.cgi?id=35584

Does anyone want us to support Python 2.4, or are people okay with Python 2.5?

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

Re: [webkit-dev] The tree is on fire: a tragedy of the commons

[Chris Jerdonek]

On Fri, Feb 26, 2010 at 1:36 AM, Adam Barth  wrote:

> 2) Require pre-commit vetting of patches.  We have the resources to
>
> Here's how I would design the life and times of a patch:
>
> 1) Contributor uploads patch and nominates it for review.
> 2) Patch vetted by the EWS on numerous platforms.
> 3) If the EWS finds a problem, return to step 1.
> 4) Reviewer marks patch review+.

It seems like this would preclude serial patches from getting reviewed together.

If I break a larger patch into smaller pieces for the benefit of the
reviewer (so that the second piece depends on the first getting
committed, etc), it seems like this process would mean that the second
piece can't get reviewed until the first piece is committed.

It seems like the committer should be allowed to decide when (2) and
(3) happen relative to the other steps -- provided it happens some
time before landing.

--Chris

> 5) Committer decides the patch is ready to land.
> 6) Patch built and tested against top-of-tree on at least one platform.
> 7) If the patch fail to build or pass tests, return to step 1.
> 8) Patch landed.
> 9) If the patch turns any of the "core builders" red, patch is rolled
> out, return to step 1.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] changelog and patches

[Chris Jerdonek]

On Tue, Feb 23, 2010 at 4:27 AM, arno  wrote:
> Hi,
> I've recently submitted a few patches.
>
> My workflow is as follow:
> I use git repository.
> Once I've made my modifications, I run WebKitTools/Scripts/prepare-ChangeLog,
> then I git-commit changeset in a private branch, then I export my patch with
> git-format-patch or git-diff
>
> My first problem is that sometimes, my patch does not apply because of
> changelog. I suppose it's because webkit changelog has changed in the
> repository. See for example attachment 49123 in bug #35191

Your first problem doesn't seem to be because of ChangeLog files, at
least in the bug you referenced.  It looks like that patch didn't
apply because the first line of the patch you submitted is not the
"diff --git a/WebCore/ChangeLog b/WebCore/ChangeLog" line.  It is a
known issue that svn-apply doesn't work if the patch has "leading
junk".  See this report, for example:

https://bugs.webkit.org/show_bug.cgi?id=33119

Using git-diff instead of git-format-patch should probably resolve that one.

Also read the wiki page about using Git with WebKit:

http://trac.webkit.org/wiki/UsingGitWithWebKit

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

Re: [webkit-dev] WebKit API native coding style?

[Chris Jerdonek]

FYI, check-webkit-style now supports the following via configuration variables:

(1) Suppressing certain style checks (based on category name) for
particular files/folders
(2) Enabling custom style checks (again based on category name) for
particular files/folders
(3) Skipping the style check entirely for particular files/folders

Option (2), of course, requires writing additional code for the custom
style checks.  A consequence of (2) is that not only can ports
suppress WebKit style checks -- they can also check for and enforce
port-specific style rules.

--Chris


On Fri, Feb 19, 2010 at 7:18 AM, Evan Martin  wrote:
> On Fri, Feb 19, 2010 at 3:30 PM, Stephan Assmus  wrote:
>> I would like to know whether it's ok to adopt the respective platform's
>> coding style in the WebKit API that a port exposes. I am working on the
>> Haiku port and saw that other ports do this, but I thought I'd better ask
>> before I introduce changes that may eventually be rejected. :-)
>
> Yes, this is ok.  I'm sure you could find the discussion in the list
> archives with some searches involving the words "port" and "style".
> ;)
> ___
> 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] Compile Web-kit error because of libwebkit-1.0.so

[Chris Jerdonek]

Hi Thangdd,

> I have built libxt and xlib, gtk-directfb, gtk-x11 at all.
> I search these errors in google, but there is any right answer.
> Thanks for your helps.

Questions like these should be directed to webkit-help rather than webkit-dev.

The following page contains descriptions of the various WebKit mailing
lists and what they should be used for:

http://webkit.org/contact.html

Thanks,
--Chris



On Thu, Feb 11, 2010 at 2:14 PM, thangdd  wrote:
> Hi, everybody!
> I am new in webkit-dev. I 've been downloaded source code of WebKit-r54277.
> And compiling it:
>
> $ ./autogen.sh --with-target=directfb --prefix=/usr/
> $ make
> ...
> *When compiler comes here, it gets errors: *
> ./doltlibtool --tag=CC   --mode=link gcc -ansi -fno-strict-aliasing -Wall -W
> -Wcast-align -Wchar-subscripts -Wreturn-type -Wformat -Wformat-security
> -Wno-format-y2k -Wundef -Wmissing-format-attribute -Wpointer-arith
> -Wwrite-strings -Wno-unused-parameter -Wno-parentheses -fno-exceptions
> -fvisibility=hidden -D_REENTRANT -I/usr/include/gtk-2.0
> -I/usr/lib/gtk-2.0/include -I/usr//include/cairo -I/usr///include/directfb
> -I/usr/include/freetype2 -I/usr//include -I/usr/include/libpng12
> -I/usr/include/pixman-1 -I/usr/include/atk-1.0 -I/usr//include/pango-1.0
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
> -I/usr/include/libsoup-2.4 -I/usr/include/libxml2 -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include   -O2 -no-fast-install -no-install  -o
> Programs/GtkLauncher WebKitTools/GtkLauncher/Programs_GtkLauncher-main.o
> libwebkit-1.0.la -L/usr//lib -lgtk-directfb-2.0 -lgdk-directfb-2.0 -latk-1.0
> -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0
> -lgmodule-2.0 -lglib-2.0   -pthread -lgobject-2.0 -lgthread-2.0 -lrt
> -lglib-2.0   gcc -ansi -fno-strict-aliasing -Wall -W -Wcast-align
> -Wchar-subscripts -Wreturn-type -Wformat -Wformat-security -Wno-format-y2k
> -Wundef -Wmissing-format-attribute -Wpointer-arith -Wwrite-strings
> -Wno-unused-parameter -Wno-parentheses -fno-exceptions -fvisibility=hidden
> -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
> -I/usr//include/cairo -I/usr///include/directfb -I/usr/include/freetype2
> -I/usr//include -I/usr/include/libpng12 -I/usr/include/pixman-1
> -I/usr/include/atk-1.0 -I/usr//include/pango-1.0 -I/usr/include/glib-2.0
> -I/usr/lib/glib-2.0/include -I/usr/include/libsoup-2.4
> -I/usr/include/libxml2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
> -O2 -o Programs/GtkLauncher
> WebKitTools/GtkLauncher/Programs_GtkLauncher-main.o -pthread
>  ./.libs/libwebkit-1.0.so -L/usr//lib /usr/lib/libgtk-directfb-2.0.so
> /usr/lib/libgdk-directfb-2.0.so /usr/lib/libatk-1.0.so
> /usr/lib/libgdk_pixbuf-2.0.so /usr//lib/libpangocairo-1.0.so
> /usr//lib/libpango-1.0.so /usr//lib/libcairo.so /usr/lib/libgmodule-2.0.so
> /usr/lib/libgobject-2.0.so /usr/lib/libgthread-2.0.so -lrt
> /usr/lib/libglib-2.0.so  -Wl,--rpath
> -Wl,/home/thangdd/DFB/WebKit-r54277/.libs -Wl,--rpath -Wl,/usr//lib
> -Wl,--rpath -Wl,/usr//lib
> ./.libs/libwebkit-1.0.so: undefined reference to `gtk_xtbin_new'
> ./.libs/libwebkit-1.0.so: undefined reference to `gtk_xtbin_set_position'
> ./.libs/libwebkit-1.0.so: undefined reference to `gtk_xtbin_resize'
> ./.libs/libwebkit-1.0.so: undefined reference to `gtk_xtbin_get_type'
> collect2: ld returned 1 exit status
>
> I have built libxt and xlib, gtk-directfb, gtk-x11 at all.
> I search these errors in google, but there is any right answer.
> Thanks for your helps.
>
> *Best regards,*
> *Thangdd.*
> ___
> 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] Qt compilation problem

[Chris Jerdonek]

Hi Ismail, thanks for investigating this issue and for finding a possible fix.

I can't comment on the specifics, but usually the best way to deal
with issues like this is to file a bug report:

http://webkit.org/quality/reporting.html

The bugs database has a comment feature to allow for back-and-forth
discussion there.  And if this a Qt-specific issue, you can give it a
title that begins "[Qt] "  Finally, if you'd like to submit a
formal patch for the issue, you can follow the instructions here:

http://webkit.org/coding/contributing.html

Otherwise, you can simply include your suggested fix below and someone
else can take it from there.

Thanks a lot,
--Chris


On Sat, Feb 6, 2010 at 6:29 PM, İsmail Dönmez  wrote:
> Hi;
>
> On Fri, Feb 5, 2010 at 1:35 PM, İsmail Dönmez  wrote:
>>
>> Hi Darin;
>> On Fri, Feb 5, 2010 at 1:32 PM, Darin Adler  wrote:
>>>
>>> This is a question for the webkit-help mailing list or a Qt-specific one,
>>> not webkit-dev. The webkit-dev mailing list is for discussion of WebKit
>>> development, not building or using it.
>>>
>>> See .
>>>
>>
>>  The reason I used this mailing list is because this is a clear regression
>> not just a build problem on my side. If proven otherwise, I am sorry.
>
> Looks like nmake messes up when the filenames match. Following patch fixes
> this (of course after doing a git mv), can someone comment?
> diff --git a/WebCore/WebCore.pro b/WebCore/WebCore.pro
> index 4d2c597..0b062d0 100644
> --- a/WebCore/WebCore.pro
> +++ b/WebCore/WebCore.pro
> @@ -1999,7 +1999,7 @@ SOURCES += \
>      platform/qt/FileSystemQt.cpp \
>      platform/qt/SharedBufferQt.cpp \
>      platform/graphics/qt/FontCacheQt.cpp \
> -    platform/graphics/qt/FontCustomPlatformData.cpp \
> +    platform/graphics/qt/FontCustomPlatformDataQt.cpp \
>      platform/graphics/qt/GlyphPageTreeNodeQt.cpp \
>      platform/graphics/qt/SimpleFontDataQt.cpp \
>      platform/qt/KURLQt.cpp \
>
> Thanks,
> İsmail
> ___
> 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] std::complex affects isinf(), etc.

[Chris Jerdonek]

Does this issue have any bearing on the '"using" Statements' section
of the style guidelines?

http://webkit.org/coding/coding-style.html

Would it make sense to adjust them in some way in response to this issue?

--Chris

On Thu, Feb 4, 2010 at 12:01 PM, Sam Weinig  wrote:
> I would be in favor of fixing the existing uses by using explicit
> std::isinf.
> -Sam
>
> On Wed, Feb 3, 2010 at 5:07 PM, Chris Rogers  wrote:
>>
>> Basically, if you include  then it undefines the functions (or
>> macros) for isinf(), isnan(), and others, and then expects you
>> to use std::isinf(), std::isnan() instead.  We use these functions in a
>> number of places, so we'd need to figure out a reasonable solution.
>> Or just go with my original class.
>>
>> On Wed, Feb 3, 2010 at 5:01 PM, Sam Weinig  wrote:
>>>
>>> What specific errors are you getting? I don't understand why including a
>>> standard header would break other standard functions.
>>> -Sam
>>>
>>> On Wed, Feb 3, 2010 at 3:22 PM, Chris Rogers  wrote:

 I initially put in a patch for a class for Complex numbers, but people
 preferred that I just use the std::complex version.
 In the process of switching my code over to use std::complex I noticed a
 conflict with isinf(), isnan(), etc.
 The problem is that simply including:
 #include 
 breaks the isinf(), isnan() functions (and some others I think).  So now
 I'm getting compile errors in any header files
 which use these functions, such as WebGLFloatArray.h (which I need to
 include for music visualizer stuff).
 I'm a bit queasy about all the side-effects of simply including
  and am not even sure how to address the
 current situation, short of switching all of webkit over to using
 std::isinf, std::isnan, etc.
 Now I remember having similar problems with this in other codebases I've
 worked on, as the effects of  seem
 to be viral...
 Anybody have any recommendations?
 Thanks,
 Chris

 ___
 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
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] licensing question

[Chris Jerdonek]

On Wed, Feb 3, 2010 at 10:46 PM, Conrad Taylor  wrote:
>
> Chris, have you checked the licensing and/or spoke with the license
> owners of the 3rd party source?  If not, I would recommend starting
> there.

[Sorry for the duplicate e-mails, Conrad.]

Yes, I have the license text.  It seems fine to me.  It's just not
identical to either the BSD or LGPL license, which is what the WebKit
Committers Guidelines say are allowed without written clearance from
Apple.  (I don't know how close the text of the terms have to be to be
considered "BSD-style".)

As for contacting the license owner(s), I'm not sure what I would ask
them -- whether they can also license it under BSD?  The Guidelines
only say to contact the author if the source file has no licensing
terms attached to it.

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

[webkit-dev] licensing question

[Chris Jerdonek]

Quick question: if we would like to check in third-party code and it
is not obviously "BSD-style" (at least to me), what is the process for
checking whether the license is okay and clearing the license?

The WebKit Committer Guidelines say, "This means that you should
verify that each source file contains either a copy of the BSD or LGPL
text, or a license header stating that it is governed by either such
license. All other licenses are not acceptable unless cleared by Apple
in writing."

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

Re: [webkit-dev] DOM Serialization?

[Chris Jerdonek]

On Fri, Jan 22, 2010 at 7:16 AM, Christopher White  wrote:
> Is it possible to save the DOM resulting from the parsing of HTML / CSS into
> a file and then read it back instead of re-parsing the HTML (similar to Java
> object serialization). Does it save any time or is it a wash?

This is going back a couple weeks, but I was curious as to what use
cases you had in mind for this.  For example, you could imagine this
being done on the server side before sending to some kind of client.
But that's probably not what you had in mind.  And there is also the
web archive use case that Darin mentioned.

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

Re: [webkit-dev] changelogs: a reprise

[Chris Jerdonek]

On Tue, Jan 26, 2010 at 9:55 AM, David Kilzer  wrote:
>> (2) Consider phasing in support for an alternate workflow where new
>> ChangeLog entries for the next commit are stored separately from the
>> versioned ChangeLog files -- perhaps in individual .changelog files
>> for Subversion users and in the commit message for Git users.

> I'm not a big fan of wrapper scripts, mostly because I'll probably forget 
> about using them since I'm so used to using the basic git/svn commands.  (I 
> guess svn-create-patch is a counter-argument to that, but I rarely use svn 
> directly anymore.)
>
> Using .changelog-bugnum files should probably be optional if it's 
> implemented, e.g., tools should still be smart enough (or at least as smart 
> as they are today) to operate on ChangeLog files directly if developers 
> choose to continue doing that.  I say that because once there is a git merge 
> driver for ChangeLog files, the need for an alternative ChangeLog workflow 
> drops to zero, at least for me.

I ran into an issue today where "git diff" didn't generate me a patch
with the ChangeLog portion in the standard format.  Namely, the
ChangeLog diff had non-empty leading context (which can happen since
it doesn't run fixChangeLogPatch like the svn-create-patch wrapper
script).  Is there a way to address this issue for Git users without
using wrapper scripts or a change to the ChangeLog workflow?

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

Re: [webkit-dev] changelogs: a reprise

[Chris Jerdonek]

On Tue, Jan 26, 2010 at 9:55 AM, David Kilzer  wrote:
>
> I think I mentioned this before, but for git users, this can be solved in the 
> short term by a merge driver that uses resolve-ChangeLogs (once it knows how 
> to be invoked by git as a merge driver):

This seems like a good idea.

> I started hacking on resolve-ChangeLogs to be invoked by three arguments this 
> way, but haven't had time to finish it.

I came across this report:

https://bugs.webkit.org/show_bug.cgi?id=28721

"I looked briefly at writing this today.  The merge driver is passed paths to 3
temp files.  1. previous version 2. other branch version.  3.  this branch
version.  Maybe one of the other WebKit git users will get further than I did."

Looks like you and Eric might want to connect. ;)

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

[webkit-dev] changelogs: a reprise

[Chris Jerdonek]

I was reading through the old "I HATE CHANGELOGS" messages from August:

https://lists.webkit.org/pipermail/webkit-dev/2009-August/thread.html

The discussion attracted a lot of interest and ideas, but it looks
like it died out without reaching any conclusion.

It seems like the tools around ChangeLogs have improved somewhat since
then, but we still have, for example, the fundamental
conflict-on-commit annoyance.

What do people think about these two possibilities for short- and
mid-term strategies, respectively?

(1) Provide a simple wrapper around "svn commit" and "git svn dcommit"
that encapsulates the retry logic in case of ChangeLog conflicts.
This way, the end-user will never have to resolve ChangeLog conflicts
on commit.  Higher-level commands like webkit-patch could use this
under the hood, if they wanted, to cope with race conditions.

(2) Consider phasing in support for an alternate workflow where new
ChangeLog entries for the next commit are stored separately from the
versioned ChangeLog files -- perhaps in individual .changelog files
for Subversion users and in the commit message for Git users.  The
commands in (1) would be smart enough to read the new ChangeLog
information from these alternate locations, and then add the ChangeLog
information to the ChangeLog files at the last moment -- prior to
commit.  Users of this workflow would never have to resolve ChangeLog
conflicts during the review process, since new entries are stored
separately.  It may be easiest to support this new workflow for Git
users first.

The second idea is essentially Ojan's proposed modification of one of
Maciej's ideas:

https://lists.webkit.org/pipermail/webkit-dev/2009-August/009708.html

It is a mid-term rather than short-term strategy since it involves
changes to several scripts (e.g. svn-create-patch) to allow the review
process to support this alternate workflow.

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

Re: [webkit-dev] location in the tree for third party python code?

[Chris Jerdonek]

On Thu, Jan 21, 2010 at 6:54 PM, Maciej Stachowiak  wrote:
>
> The MIT license is equivalent to the standard no-advertising-clause BSD
> license that we use in WebKit. It would be acceptable.

For future reference--

While we're on the topic, is the Apache 1.1 license also acceptable
for such purposes?  I recently came across a third-party module with
that license.

http://www.apache.org/licenses/

It also has no advertising clause and is similar to BSD (but possibly
not similar enough).

--Chris

> On Jan 21, 2010, at 6:11 PM, David Levin wrote:
>
> I didn't see a web page about it, but when you submit a patch, every single
> bullet mentions only BSD or LGPL 2.1 is accepted.
>
> If you are sending in a patch to existing WebKit code, you agree by clicking
> below that your changes are licensed under the existing license terms of the
> file you are modifying (i.e., BSD license or GNU Lesser General Public
> License v.2.1, LGPL v. 2.1). Please also add your copyright (name and year)
> to the relevant files for changes that are more than 10 lines of code.
> If you are sending in a new file for inclusion in WebKit (no code copied
> from another source), the preferred license is BSD, but LGPL 2.1 is an
> option as well. Please include your copyright (name and year) and license
> preference (BSD or LGPL 2.1). By clicking below you agree that your file is
> licensed under either the BSD license or LGPL 2.1, as indicated in your
> file.
> If you aren't the author of the patch, you agree to include the original
> copyright notices and licensing terms with it, to the extent that they
> exist. If there wasn't a copyright notice or license, please make a note of
> it. Generally we can only take in patches that are BSD- or LGPL-licensed in
> order to maintain license compatibility within the project.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] webkit team wiki page

[Chris Jerdonek]

On Sun, Jan 24, 2010 at 2:02 PM, Adam Barth  wrote:
> In the conversion process, I removed the "areas of knowledge"
> information because it was often out of date or provincial.  svn
> blame, IRC, or social awareness is a more accurate way of figuring or
> who to ask about a particular piece of code.

Thanks for the explanation, Adam.

An additional type of information that was removed was the chronology,
so you could see roughly who has been involved in the project longer.
While this was not explicitly stated, I believe that within each
section individuals were added in the order they became involved.

I'm not saying this information shouldn't be removed.  I'd just like
to point out that it's something else that got lost in the change.

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

[webkit-dev] webkit team wiki page

[Chris Jerdonek]

I noticed that the "WebKit Team" wiki page changed significantly this past week:

http://trac.webkit.org/wiki/WebKit%20Team

I was curious about the reasons behind the change, and whether people
like the change.

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

Re: [webkit-dev] pep8 style for python code

[Chris Jerdonek]

> On Fri, Jan 22, 2010 at 12:33 PM, Adam Barth  wrote:
>> We're starting to grow a bunch of python code in the project.  I'd
>> like to propose that we use the PEP8 style guide for this python code:

I support adopting PEP 8.

I would like for us to be open to adding to these requirements,
though, in the future (i.e. adding guidelines where it is silent
rather than changing where it is not silent).

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

Re: [webkit-dev] questions about allow-tabs

[Chris Jerdonek]

On Fri, Jan 15, 2010 at 2:01 PM, David Kilzer  wrote:
> On Fri, January 15, 2010 1:52:19 PM, Chris Jerdonek wrote:
>> Thanks a lot for the response, David.  To add to the list,
>> svn:executable is another one.
>
> Yes, scripts don't work very well without execute permissions.  :)
>
> However, the git-svn script is smart enough to set that one, though.  The 
> others you don't get for "free" when using git to push patches to an svn 
> repository.

And svn-apply is not smart enough. :)

I was also asking to find out what subversion properties svn-apply
might be likely to encounter -- for the purpose of adding property
support to svn-apply and svn-unapply.

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

Re: [webkit-dev] questions about allow-tabs

[Chris Jerdonek]

On Thu, Jan 14, 2010 at 9:05 PM, David Kilzer  wrote:
> On Thu, January 14, 2010 at 6:59:17 PM, Chris Jerdonek wrote:
>> While I'm asking, I might as well also ask -- what other subversion
>> properties do we use?
>
>
> In the past, svn:eol-style has been applied so that when files are checked 
> out on Windows, they have the proper line endings.  There is also a concerted 
> effort to keep svn:mime-type set correctly on *-expected.png results for 
> pixel tests committed via git.

Thanks a lot for the response, David.  To add to the list,
svn:executable is another one.

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

Re: [webkit-dev] MathML Project Contact etc.

[Chris Jerdonek]

> Date: Thu, 14 Jan 2010 22:32:11 -0800
> From: Alex Milowski 
> Subject: [webkit-dev] MathML Project Contact etc.
>
> I'm presenting my MathML in WebKit work tomorrow at the Joint AMS/MAA
> meeting here in San Francisco.  After looking through my slides I feel
> that I'm unsatisfied with what I'm telling people about where to go for
> more information or to contribute to the project.
>
> I'd like a better way for:
>
>   * MathML in WebKit related discussions to take place,
>   * dissemination of status,
>   * collection of test cases, plans, roadmaps,
>   * builds of a MathML enabled WebKit for testers.

Thanks, Alex.  I realize some of this is probably covered by your earlier post:

https://lists.webkit.org/pipermail/webkit-dev/2010-January/011328.html

What were you originally going to tell people as far as the above four
things and where to go to contribute?

Good luck on your presentation!
--Chris
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] questions about allow-tabs

[Chris Jerdonek]

I have some background questions about the "allow-tabs" property.  I
imagine it pre-dates check-webkit-style by quite a while.

(1) What's the reason and history behind our use of the property?

(2) What component actually does the pre-commit check?  I didn't find
a reference to "allow-tabs" in WebKitTools/, but maybe I searched
incorrectly.

(3) Roughly speaking, how many and what types of files have the property set?

(4) Are there any issues to be aware of with it when using a Git
repository for development?

While I'm asking, I might as well also ask -- what other subversion
properties do we use?

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

Re: [webkit-dev] Remove underscore check in check-webkit-style?

[Chris Jerdonek]

> Date: Wed, 13 Jan 2010 15:49:05 -0800
> From: David Levin 
>
> 3) Stop checking code in gtk/qt platform directories for underscores?
>
> I think there are several other checks that code in some of these
> directories typically fail due to various issues (public api that should
> follow the standard public api format for that platform, etc.)

I made a bug report for this issue:

https://bugs.webkit.org/show_bug.cgi?id=33684

(This is distinct from the qt_ underscore issue, which has its own report:

https://bugs.webkit.org/show_bug.cgi?id=33663 )

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

Re: [webkit-dev] Did I break the build?

[Chris Jerdonek]

> Date: Thu, 7 Jan 2010 16:21:49 -0800
> From: Eric Seidel 
>
> http://build.webkit.org/console
>
> Will let you know.

If possible, it might be good to add this link to the
http://build.webkit.org/ home page.  Is it linked elsewhere?  It
doesn't look like the home page is stored in source control.

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

Re: [webkit-dev] test scripts

[Chris Jerdonek]

On Wed, Dec 30, 2009 at 2:33 PM, Sam Weinig  wrote:
> I would prefer we stick with the run prefix.
> I am also not sure why we would have separate testing scripts based by
> language.

Thanks, Sam.

The language-specific scripts are more an artifact of the fact that
the Perl test harness is written in Perl and the Python test harness
is written in Python.  They can be viewed as intermediate
implementation steps.

With the exception of a script for testing interpreted code (as Adam
suggested in an earlier e-mail), I do agree with you that contributors
shouldn't have to call or know about the language-specific scripts.  I
submitted a patch to that effect here:

https://bugs.webkit.org/show_bug.cgi?id=33045

>From an implementation perspective though, I do think they can provide
a useful layer of encapsulation when calling from other code.  As I
mentioned in an earlier e-mail, over time we can move the
language-specific scripts to a sub-folder so they won't be as visible
to the end user.

> If the number of these scripts got
> out of hand, we could always add a run-all-tests scripts which ran them all.

I think the intention is not to expose at the top level a separate
script for every component, but to provide only higher-level commands.
 But yes, an "all" script is good.

As for your preference regarding the "run" prefix, I elaborated on my
reasons in the comments to the bug report.  If you want, we can
continue the discussion there.

Thanks a lot,
--Chris
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] test scripts

[Chris Jerdonek]

On Tue, Dec 29, 2009 at 11:07 AM, Adam Barth  wrote:
> I'd prefer to have as few test commands as possible.  Ideally, I
> should just be able to run the grand unified test suite and know that
> my patch is ok to commit.  There's some advantages to breaking out the
> JSC tests from the WebCore tests so we can avoid building WebCore when
> testing JSC.  Similarly, there's an advantage to breaking out the
> tests of interpreted code from compiled code to avoid unnecessary
> compilation.  However, I don't see the advantage of dividing the Perl
> tests from the Python tests.

I agree with exposing higher-level test commands and having a single
script that tests both the Perl and Python code (e.g.
test-webkit-scripts).

For encapsulation purposes and to let the Perl tests be called more
easily from other languages, it may still be useful to have a single
script that runs all the Perl unit tests (and similarly for Python).
If we wanted to, we could perhaps move those language-specific scripts
to a sub-folder so the end user won't see them.

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

[webkit-dev] test scripts

[Chris Jerdonek]

Last night on IRC there was a brief discussion of the test scripts:
how they should be divided in the future and what they should be
called.  These scripts are in WebKitTools/Scripts.

I believe we currently have at least (correct me if I'm wrong)--

run-webkit-tests
run-javascriptcore-tests
run-webkit-unittests (tests Python scripts)

I also have a patch to add a script to test some Perl functionality.

Maciej mentioned that he thinks it's useful for scripts to begin with
an action word (i.e. a verb).  However, we currently have many scripts
(not just testing scripts) that begin with the generic word "run."

Going forward, how would people feel about giving new test scripts
names that begin with the word "test"?  For example--

test-webkit-perl
test-webkit-python
etc.

Separate from this question, I think it would be great if one of those
participating last night (or anyone else) could share their vision of
how they think our tests should be divided up in the mid to long-term.
 This can include new tests that we haven't written yet, but hope to.

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

Re: [webkit-dev] Style for Gtk/Qt code

[Chris Jerdonek]

Date: Mon, 21 Dec 2009 01:25:31 -0600
From: Eric Seidel 

> Can we get consensus on if the WebKit style applies to all sections of
> code?  And if it does not, what style applies to the code it does not?

It does not apply to all sections since the web site has this to say at least--

> Code Style Guidelines
>
> Patches must comply with the code style guidelines An exception is
> legacy components, which should not be cleaned up.

(from http://webkit.org/coding/contributing.html )

And from the Wiki:

> The WebKit source tree also contains the following project:

> 1. JavaScriptGlue: this is a legacy component needed for compatibility
> with some older Mac OS X software. It will eventually be retired and
> should not receive any new development.

(from http://trac.webkit.org/wiki/HighLevelOverview )

I don't know if there are any other sections.

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

[webkit-dev] questions re: patch length

[Chris Jerdonek]

I have a few questions related to patch length:

(1) Do reviewers take patch length into account when considering
whether to review a patch?  This is useful to know for those who would
rather have a short patch reviewed more quickly than wait longer for a
longer patch to be reviewed.

(2) If reviewers do take patch length into account, what's the best
way to handle trivial changes that might inflate patch length (for
example moving a large chunk of code or adding an image) -- should
such changes be submitted separately?

(3) Finally, in people's experience, what is the "sweet spot" for
patch length?  (There is an optimization problem here somewhere.)

I can add helpful info from responses to the web site where appropriate.

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

Re: [webkit-dev] bug life cycle questions

[Chris Jerdonek]

On Sun, Dec 13, 2009 at 4:21 PM, Brent Fulgham  wrote:

> This thread brought to mind something in the bug life cycle I've been unsure
> of.  What is WebKit ettiquette for adding people to the bug CC list?
> ...
> Maybe proper use of the CC list could also be included in this write-up?

I was wondering that, too.  I would be happy to include it.

A related question I had is -- after you update a bug, Bugzilla
displays who is receiving an e-mail as a result of your change.  Why
does this list sometimes include people not on the CC list?  That's
partly why I thought there may be other project roles (e.g. owners).

Also, does Bugzilla allow you to remove other people from the CC list?
 I've never tried it.  It seems like it would be an unusual feature.
I can't think of a natural use case.

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

[webkit-dev] bug life cycle questions

[Chris Jerdonek]

I have a few questions about the WebKit bug life cycle I was hoping
someone could answer.  I'm going to be updating the bug life cycle
page soon:

http://webkit.org/quality/lifecycle.html

So any information you provide is something I can incorporate.

Here are the questions:

(1) Generally speaking, who has Bugzilla "canconfirm" privileges?

(2) When a bug is out of the UNCONFIRMED status, what individuals can
set the "Assigned To" field?

(3) Before starting work on an UNCONFIRMED bug, what's the most
efficient way of getting that bug assigned to you (assuming you do not
have "canconfirm" privileges, etc)?

(4) Finally, the bug life cycle page says, "Each bug is initially
assigned to the person designated as owner of the component."  But
most new WebKit bugs I see have assignee "webkit-unassigned".  Does
the WebKit project have a concept of owner or the equivalent?

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

[webkit-dev] Should we ever change style guidelines? (was Re: Resolution on switch statement indentation)

[Chris Jerdonek]

At first glance these "meta-guidelines" seem fine.  If they are going
to be written down somewhere, a couple minor comments:

On Dec 9, 2009, Maciej Stachowiak wrote:

> I think something like
> the following should be our "meta-guidelines" for when to change the
> style guide:

It would be good to clarify that these are meta-guidelines for
changing the substance of the guide rather than the guide itself.  The
reason is that the guide can also change in non-substantive ways
(presentation, wording, examples, etc), and I don't think you mean for
your points to cover those as well.

> 3) If we have overwhelmingly strong evidence that a particular change
> would aid readability, even though the issue in question had been
> considered before, then we can consider changing. But there should be

I would use more general language here like, "If we have
overwhelmingly strong evidence that a particular change would result
in a net improvement..."  The reason is that, as has been pointed out,
not all of the guidelines have to do with readability.  For example,
some of the "using" statement guidelines have more to do with
building.  Maintainability is another consideration that does not
necessarily parallel readability, e.g.:

https://lists.webkit.org/pipermail/webkit-dev/2009-December/010862.html

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

Re: [webkit-dev] "using" statement clarifications

[Chris Jerdonek]

On Mon, Dec 7, 2009 at 9:30 AM, Darin Adler  wrote:
> Sorry, I wasn’t able to follow all the logic in the style guideline and the 
> email message nor fully understand what the script enforces. So I’ll give my 
> view on this and hope it helps.

Thanks.  To be clear, I will restate your clarifications and
suggestions as I understand them.  I will also explain how they
compare to the guidelines as currently stated.

(1) Add this to the guidelines: Do not use statements of the form
"using std:foo" in implementation files.  Use "using namespace std"
instead.  (The script currently enforces this rule, but for header
files and not just implementation files.)

(2) Clarify that the rule to put "using namespace" statements near the
beginning of a file applies only to implementation files. (It
currently applies also to header files.)  Also, strengthen the rule so
it applies to all "using" statements in implementation files and not
just "using namespace" statements.

> I also don’t see a need for "using" statements of either kind further down in 
> the file. It seems they can go at the top, right after the includes. But 
> maybe I’ve missed some useful case.

The existing guidelines single out the case of nested namespaces and
says they should appear further down when the parent exists.  For
example, instead of this--

> using namespace WebCore::HTMLNames;
>
> namespace WebCore {

do this--

> namespace WebCore {
>
> using namespace HTMLNames;

Should nested namespaces remain an exception?

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

[webkit-dev] "using" statement clarifications

[Chris Jerdonek]

This e-mail has two related questions.

I noticed that the style-check script enforces a rule that isn't
stated in the coding style guidelines.  I'd like to clarify this rule
before adding it to the guidelines.

The rule is that "using std::foo" statements should be replaced by
"using namespace std" in files not ending in .c or .m.  The
"check_using_std" function of cpp_style.py enforces this rule:

http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/modules/cpp_style.py

I've also noticed, though, that some existing _header_ files have
"using std::foo" statements (where "foo" is swap, pair, make_pair,
min, or max).

(Q1) What was the reason for this rule, and for consistency, which of
the following should hold?

(A) The "using std" rule above should not apply to header files.
(B) The "using std" rule above should apply to header files, in which
case we also need to clarify an existing style guideline as described
below.
(C) Statements of the form "using std::foo" should not be allowed in
header files at all -- even when not in global or "namespace" scope.
(They are already not allowed in header files in global or namespace
scope.)

The following related, existing guideline also seems to need
clarification (currently rule #4 in the "'using' statements" section):

> Any other "using namespace" statements [i.e. statements for non-nested
> namespaces or for nested namespaces whose parent namespace is not
> defined in the file] must be declared before the first namespace
> definition in the file.

It seems like this rule shouldn't apply to "using namespace"
statements in block or class scope, since this would imply that "using
namespace" statements aren't allowed in block or class scope.  At the
least, it seems like it shouldn't apply to header files since we don't
allow header files to have "using" statements in global scope to begin
with.

(Q2) What is the reason for the "using namespace" rule above, and to
clarify, which of the following should hold?

(L) The "using namespace" rule above should apply only to statements
already in global or namespace scope.
(M) The "using namespace" rule above should apply to all "using
namespace" statements (in particular, "using namespace" statements are
not allowed in block or class scope).  However, the rule should apply
only to implementation files (since we do not allow header files to
have "using" statements in global scope).
(N) The "using namespace" rule above should apply to all "using
namespace" statements.  In particular, "using namespace" statements
are not allowed in block or class scope, and header files cannot have
"using namespace" statements in any scope.

I'm listing (N) for completeness, even though at least one person has
already remarked that it's okay to use "using namespace" statements in
header files in non-global scopes:

https://lists.webkit.org/pipermail/webkit-dev/2009-November/010518.html

I will add clarifying information to the web site after I hear back.

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

Re: [webkit-dev] Proposing style guide change regarding braces on conditional arms

[Chris Jerdonek]

On Thu, Dec 3, 2009 at 10:17 PM, Peter Kasting  wrote:
> On Thu, Dec 3, 2009 at 6:24 PM, Chris Jerdonek 
> wrote:
>>
>> For the people thinking about this, it would be nice if the final
>> policy minimizes (and does not increase) the likelihood of having to
>> modify several lines of surrounding code after touching one line of
>> code.  I don't think this consideration has been raised.
>
> Do you mean "in the steady state of modifying the code base" or "while files
> aren't compliant with whatever change might get made"?

I meant the former (though my alternative below also reduces the latter).

> I think you mean the
> former, but if so, I'm not sure what policy would serve you best.  Ideally
> you'd want "always use braces", but failing that, each proposal has a
> different set of cases where you do/don't have to change as you touch
> things.

I don't feel strongly about this, but I will provide an example to
illustrate what I mean.

The illustrative case is several "else if" clauses with braces -- only
one of which exceeds one line.  If a code change removes the excess
lines in that one clause, the two rules being considered say you have
to remove the braces from all the clauses -- even though the clauses
are already lined up.  And this change can go back and forth
indefinitely.

Several people are already saying they value alignment within
individual if-else control structures more than they value the number
of braces.  So removing the braces from all the clauses in the example
above seems secondary.

An alternative policy is as follows:

(1) If-else control structures must have either braces around all
clauses or braces around no clauses.

(2) A clause with more than one line must be surrounded by braces.

A consequence of this policy is that if-else statements may gradually
converge to braces, but this change would take place only as needed.

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

Re: [webkit-dev] Proposing style guide change regarding braces on conditional arms

[Chris Jerdonek]

> Date: Wed, 2 Dec 2009 21:00:59 -0800
> From: Peter Kasting 
>
> This is a followup to my thread yesterday regarding consistent enforcement
> of the style guide.  Like Yong Li, I find the current rule about braces on
> conditional arms to be suboptimal.

For the people thinking about this, it would be nice if the final
policy minimizes (and does not increase) the likelihood of having to
modify several lines of surrounding code after touching one line of
code.  I don't think this consideration has been raised.

This is similar to a point Darin Adler raised a few months back with
regard to lining up comments:

> Things manually lined up in source code generally create a small
> maintainability problem. You can’t rename things without re-lining
> things up, and if you make other types code changes without noticing
> the lined-up comments the code ends up looking messy an peculiar.

( https://lists.webkit.org/pipermail/webkit-dev/2009-September/009814.html )

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

Re: [webkit-dev] namespace indent

[Chris Jerdonek]

On Tue, Dec 1, Jeremy Orlow wrote:

> Adam's right though: unlike most of the other style changes, if we don't fix
> this one all at once, only new files will ever match the style guide.  This
> is different than most of the other guidelines where things eventually
> converge as people touch lines of the file.

I am in favor of using a script to do this change.  It looks like
we're using a similar approach to do a global rename:

http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/do-webcore-rename

Once created, the script could be executed on a per folder, or per
project basis, etc. depending on what people prefer.  I expressed
interest a couple weeks ago in writing such a script:

https://lists.webkit.org/pipermail/webkit-dev/2009-November/010521.html

Since I don't have a time frame though, I'm not suggesting that people
hold off on fixing the issue in files they touch.

--Chris


> On Tue, Dec 1, 2009 at 3:22 PM, David Levin  wrote:
>
>> 4) (I think it may be possible to) notice that there are other unchanged
>> lines that have this problem, and then just not print the error if that
>> occurs.
>>
>> dave
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] style-queue entering beta

[Chris Jerdonek]

On Sun, Nov 29, 2009 at 9:35 AM, Adam Barth  wrote:

> On Sun, Nov 29, 2009 at 9:26 AM, Chris Jerdonek
>  wrote:
>> On Sat, Nov 28, 2009,  Adam Barth wrote:
>>> Hopefully, the script will improve over time, but it will
>>> never be perfect.
>>
>> Can you elaborate on this?  For example, are you saying there is a
>> basic reason that the script will always have bugs?  Without knowing
>> too much about the script, it seems like it wouldn't be too hard to at
>> least make the false negatives go away.  Or are you simply saying that
>> the guidelines and script will never fully capture what we mean by
>> "correct style"?
>
> Does this mean you're volunteering to remove all the false positives
> and false negatives?  :)

I was hoping to work on the script eventually, which is partly why I
asked for elaboration.

All that I meant above is that one could potentially disable (for the
bot) the style tests that report false violations, or else reduce
their confidence score.  That way, if the style bot flags a patch, it
is guaranteed to be meaningful without looking at the details of the
report.  This can only be done, though, if the problems with the
script are not so basic that they affect most or many of the tests.

(The reverse is not as straightforward, though.  It does not seem as
easy to change the script -- in a useful way -- so that if it reports
that a patch has met the guidelines, then the patch really meets the
guidelines.)

> One basic reason the script isn't perfect is that it's doesn't have a
> full C++ / Objective-C++ parser.

If we could go this route, would we prefer it?

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

Re: [webkit-dev] style-queue entering beta

[Chris Jerdonek]

On Sat, Nov 28, 2009,  Adam Barth wrote:

> One of the bots that Eric and I have been working on is about to come
> online.  This bot is a "style bot" that runs check-webkit-style on
> patches that have been nominated for review.

This seems like a good effort, thanks.  A couple minor comments below
on the first question in your FAQ:

> == Frequently Asked Questions ==
>
> Q1: If the style-queue doesn't complain, does that mean my patch has
> correct style?
>
> A1: Unfortunately, no.  First of all, check-webkit-style has false
> negatives.

It seems like this answers the different question, "If the style-queue
complains, does that mean my patch has incorrect style?"

> Hopefully, the script will improve over time, but it will
> never be perfect.

Can you elaborate on this?  For example, are you saying there is a
basic reason that the script will always have bugs?  Without knowing
too much about the script, it seems like it wouldn't be too hard to at
least make the false negatives go away.  Or are you simply saying that
the guidelines and script will never fully capture what we mean by
"correct style"?

> Second, the style-queue is only able to check
> patches that successfully download and apply to top-of-tree.  If your
> patch does not apply to top-of-tree (e.g., because it depends on
> another patch), then style-queue won't say anything.

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

Re: [webkit-dev] normalizing namespace indenting

[Chris Jerdonek]

On Tue, Nov 17, 2009 at 10:39 PM, Darin Adler  wrote:

> On Nov 16, 2009, at 7:54 PM, Chris Jerdonek wrote:
>
>> So, I was wondering if we can clarify the rule to apply only to the 
>> outermost namespace declaration.
>
> Yes, I think we can.
>
>> (Consecutive declarations like "namespace JSC { namespace WREC {" would be 
>> treated as a single declaration for the purpose of this rule.)
>
> Neat idea, I think.

Thanks.  The idea stems from a syntactic sugar for "using" blocks in
C# (different meaning of "using" from C++).  Instead of doing this--

using (Resource resource1 = new Resource())
{
using (Resource resource2 = new Resource())
{
...
}
}

You can do this:

using (Resource resource1 = new Resource())
using (Resource resource2 = new Resource())
{
...
}

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

[webkit-dev] normalizing namespace indenting

[Chris Jerdonek]

I am contemplating a script to normalize the namespace indenting
across our code to match our guidelines, so I wanted to clarify two
things.  First, it seems like the original motive was to avoid
pointlessly indenting nearly the whole file:

https://lists.webkit.org/pipermail/webkit-dev/2009-September/010002.html

So, I was wondering if we can clarify the rule to apply only to the
outermost namespace declaration.  Otherwise, files with nested
namespaces like the following become harder to read:

http://trac.webkit.org/browser/trunk/JavaScriptCore/wtf/FastAllocBase.h

(Consecutive declarations like "namespace JSC { namespace WREC {"
would be treated as a single declaration for the purpose of this
rule.)

Second, do people prefer nested namespace blocks to end with the
fully-qualified name (e.g. // namespace JSC::WREC) or just the final
name (e.g. // namespace WREC)?  I have seen both.

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

Re: [webkit-dev] "using namespace" style guideline

[Chris Jerdonek]

On Tue, Nov 10, 2009 at 8:30 PM, Darin Adler  wrote:

> No "using namespace" statements are permitted in header files. The guidelines 
> are talking about non-header files. We should clarify that.

Thanks for your later reply explaining the history behind the "using
WTF::..." statements.  It sounds reasonable.

I have a couple more questions related to the rule above though.  (For
everyone else's benefit, this rule now appears on the web site).

I found there to be seven files in WebKit that don't follow this rule,
and I wanted to double-check whether there should be any exceptions to
it.

In particular, the following file uses "using namespace WTF::Unicode"
five times, but within the bodies of various template definitions:

http://trac.webkit.org/browser/trunk/WebCore/platform/text/BidiResolver.h

(see line 304, for example)

Is this also not okay?

The following is another example.  The using statement for this one
appears at the beginning, outside of any definitions, but the file
seems to be central:

http://trac.webkit.org/browser/trunk/JavaScriptGlue/JSUtils.h

It uses "using namespace JSC".

My second question is whether the guideline above should apply, for
the same reason, to all "using" statements within header files -- and
not just to "using namespace" statements.  Statements of the form
"using WTF::..." would be exceptions.  You've already discussed those
here:

https://lists.webkit.org/pipermail/webkit-dev/2009-November/010453.html

I checked, and there are only about 40 files in all of WebKit that
wouldn't currently be following this -- slightly less than half of
which are in JSC.

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

Re: [webkit-dev] "using namespace" style guideline

[Chris Jerdonek]

On Tue, Nov 10, 2009 at 8:30 PM, Darin Adler  wrote:

> No "using namespace" statements are permitted in header files. The guidelines 
> are talking about non-header files. We should clarify that.

Thanks for the clarification.  I will go ahead and try adding that.

This is a good segue into another question I have.

What is the current thinking on all of the "using WTF::..." statements
at the end of many header files in JSC?  For example, what was the
original reason behind including those, and is there any chance that
they will be taken out at a later date (or has that already been ruled
out)?  I searched a bit and didn't come across any discussion of this.

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

[webkit-dev] "using namespace" style guideline

[Chris Jerdonek]

Hi, I have a question about the last of the WebKit Coding Style Guidelines:

http://webkit.org/coding/coding-style.html

It's the second of these two:

1. Any "using namespace" statements for a nested namespace whose
parent namespace is also defined in a file must be declared within
that namespace definition.

2. Any other "using namespace" statements must be declared before the
first namespace definition in the file.

Unlike most or all of the other rules, this one can affect
compilation.  So I was wondering what the rule is for.

For example, say I want to write the following in an existing header
file to avoid having to fully qualify several identifiers in the WTF
namespace:

namespace MyNewNameSpace {

using namespace WTF;

// code

}

Following rule 2 and putting the using statement outside the namespace
can cause compilation errors elsewhere in the project (due to
ambiguous overloads for bringing the WTF namespace into files already
including the above).  This actually happened to me while doing some
minor refactoring.

If I want to keep the "using namespace" statement, it seems like the
style guideline would require me to do an unknown amount of
refactoring outside the file.

Let me know your thoughts.

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

[webkit-dev] WTFNoncopyable namespace and ADL

[Chris Jerdonek]

I have a question regarding JSC's WTFNoncopyable::Noncopyable class
and argument-dependent lookup (ADL).  It seems like an old decision
may have been unintentionally undone in changeset 46933 (first
attempted in 46877).

The Noncopyable class (currently JavaScriptCore/wtf/Noncopyable.h) was
originally added in Feb 2006 with the following comment:

// We don't want argument-dependent lookup to pull in everything
// from the KXMLCore [now WTF] namespace when you use Noncopyable,
// so put it in its own namespace.

namespace KXMLCoreNoncopyable {

class Noncopyable {

( 
http://trac.webkit.org/changeset/12523/trunk/JavaScriptCore/kxmlcore/Noncopyable.h
)

Then, in changeset 46933 (August 2009), the class declaration was changed to--

namespace WTFNoncopyable {

-class Noncopyable {
+class Noncopyable : public FastAllocBase {

( http://trac.webkit.org/changeset/46933/trunk/JavaScriptCore/wtf/Noncopyable.h
)

But FastAllocBase is in the WTF namespace, defeating the aim of the commenter.

It seems like either the WTFNoncopyable namespace should be changed to
WTF and the comment removed, or else FastAllocBase should be put into
its own namespace as well (or something equivalent).  I'm not sure how
important it is to preserve the original ADL behavior.

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