Re: [webkit-dev] free functions
On Tue, May 25, 2010 at 10:01 AM, Darin Adler da...@apple.com 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
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
[webkit-dev] converting by constructor
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] converting by constructor
On Mon, May 17, 2010 at 3:11 PM, Darin Adler da...@apple.com 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
Re: [webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit
Thanks, Ojan. On Sun, May 16, 2010 at 8:26 AM, Ojan Vafai o...@chromium.org wrote: On Sat, May 15, 2010 at 2:17 PM, Chris Jerdonek cjerdo...@webkit.org 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
Thanks for your responses, Ojan. On Fri, May 14, 2010 at 6:29 PM, Ojan Vafai o...@chromium.org 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
On Thu, May 13, 2010 at 11:13 AM, Ojan Vafai o...@chromium.org 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
[Re-sending from correct address] On Fri, May 7, 2010 at 9:10 PM, Eric Seidel e...@webkit.org 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
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
On Sun, Apr 18, 2010 at 4:11 PM, Maciej Stachowiak m...@apple.com 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
I wanted to add a couple comments and a question to this discussion. On Fri, Apr 16, 2010 at 2:54 PM, Maciej Stachowiak m...@apple.com 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)!
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 aba...@webkit.org 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=0AZpchfQ5mBrEZGQ0cDh3YzRfMTVnZmZ3dGNmNghl=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?
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 supersti...@gmx.de 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: https://bugs.webkit.org/show_bug.cgi?id=35288 https://bugs.webkit.org/show_bug.cgi?id=34683 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
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 wsiegr...@apple.com 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
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] file names with spaces
On Mon, Mar 22, 2010 at 10:46 PM, Maciej Stachowiak m...@apple.com 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] WebKit Icon license?
On Tue, Mar 23, 2010 at 3:31 AM, Jeremy Orlow jor...@chromium.org 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 jor...@chromium.org 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 e...@webkit.org 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 sam.wei...@gmail.com wrote: And our own http://planet.webkit.org/. -Sam On Mon, Mar 22, 2010 at 3:11 PM, Chris Jerdonek cjerdo...@webkit.org wrote: On Mon, Mar 22, 2010 at 2:30 PM, Eric Seidel e...@webkit.org 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 kenneth.christian...@openbossa.org 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 dglaz...@chromium.org 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 kenneth.christian...@openbossa.org wrote: I have asked our designers to look into it :-) Kenneth On Mon, Mar 22, 2010 at 8:42 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Mar 19, 2010 at 4:00 PM, Darin Adler da...@apple.com 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 ___ 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] WebKit Icon license?
On Mon, Mar 22, 2010 at 2:30 PM, Eric Seidel e...@webkit.org 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 kenneth.christian...@openbossa.org 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 dglaz...@chromium.org 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 kenneth.christian...@openbossa.org wrote: I have asked our designers to look into it :-) Kenneth On Mon, Mar 22, 2010 at 8:42 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Mar 19, 2010 at 4:00 PM, Darin Adler da...@apple.com 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
[webkit-dev] file names with spaces
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] file names with spaces
On Mon, Mar 22, 2010 at 10:29 PM, Adele Peterson ad...@apple.com 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
Re: [webkit-dev] minimum python version to support
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 cjerdo...@webkit.org wrote: On Fri, Mar 5, 2010 at 6:43 PM, David Kilzer ddkil...@webkit.org 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
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 aba...@webkit.org 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 cjerdo...@webkit.org 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 cjerdo...@webkit.org wrote: On Fri, Mar 5, 2010 at 6:43 PM, David Kilzer ddkil...@webkit.org 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
On Fri, Mar 5, 2010 at 6:43 PM, David Kilzer ddkil...@webkit.org 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
[Resending from correct address.] On Thu, Mar 4, 2010 at 1:05 PM, Maciej Stachowiak m...@apple.com 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
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
On Fri, Feb 26, 2010 at 1:36 AM, Adam Barth aba...@webkit.org 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
On Tue, Feb 23, 2010 at 4:27 AM, arno a...@renevier.net 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?
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 e...@chromium.org wrote: On Fri, Feb 19, 2010 at 3:30 PM, Stephan Assmus supersti...@gmx.de 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
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 than...@tsdv.com.vn 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
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 ism...@namtrac.org wrote: Hi; On Fri, Feb 5, 2010 at 1:35 PM, İsmail Dönmez ism...@namtrac.org wrote: Hi Darin; On Fri, Feb 5, 2010 at 1:32 PM, Darin Adler da...@apple.com 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 http://webkit.org/contact.html. 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] DOM Serialization?
On Fri, Jan 22, 2010 at 7:16 AM, Christopher White skullkn...@gmail.com 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
[webkit-dev] licensing question
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] licensing question
On Wed, Feb 3, 2010 at 10:46 PM, Conrad Taylor conra...@gmail.com 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
Re: [webkit-dev] changelogs: a reprise
On Tue, Jan 26, 2010 at 9:55 AM, David Kilzer ddkil...@webkit.org 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
On Tue, Jan 26, 2010 at 9:55 AM, David Kilzer ddkil...@webkit.org 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
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
[webkit-dev] webkit team wiki page
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] webkit team wiki page
On Sun, Jan 24, 2010 at 2:02 PM, Adam Barth aba...@webkit.org 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
Re: [webkit-dev] MathML Project Contact etc.
Date: Thu, 14 Jan 2010 22:32:11 -0800 From: Alex Milowski a...@milowski.org 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
Re: [webkit-dev] questions about allow-tabs
On Thu, Jan 14, 2010 at 9:05 PM, David Kilzer ddkil...@webkit.org 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] questions about allow-tabs
On Fri, Jan 15, 2010 at 2:01 PM, David Kilzer ddkil...@webkit.org 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] Remove underscore check in check-webkit-style?
Date: Wed, 13 Jan 2010 15:49:05 -0800 From: David Levin le...@google.com 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
[webkit-dev] questions about allow-tabs
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] Did I break the build?
Date: Thu, 7 Jan 2010 16:21:49 -0800 From: Eric Seidel e...@webkit.org 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
On Wed, Dec 30, 2009 at 2:33 PM, Sam Weinig sam.wei...@gmail.com 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
On Tue, Dec 29, 2009 at 11:07 AM, Adam Barth aba...@webkit.org 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
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
Date: Mon, 21 Dec 2009 01:25:31 -0600 From: Eric Seidel e...@webkit.org 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
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
[webkit-dev] bug life cycle questions
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)
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
On Mon, Dec 7, 2009 at 9:30 AM, Darin Adler da...@apple.com 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
Re: [webkit-dev] Proposing style guide change regarding braces on conditional arms
On Thu, Dec 3, 2009 at 10:17 PM, Peter Kasting pkast...@google.com wrote: On Thu, Dec 3, 2009 at 6:24 PM, Chris Jerdonek chris.jerdo...@gmail.com 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
Date: Wed, 2 Dec 2009 21:00:59 -0800 From: Peter Kasting pkast...@google.com 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
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 levin at chromium.org 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
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] style-queue entering beta
On Sun, Nov 29, 2009 at 9:35 AM, Adam Barth aba...@webkit.org wrote: On Sun, Nov 29, 2009 at 9:26 AM, Chris Jerdonek chris.jerdo...@gmail.com 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] normalizing namespace indenting
On Tue, Nov 17, 2009 at 10:39 PM, Darin Adler da...@apple.com 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
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
On Tue, Nov 10, 2009 at 8:30 PM, Darin Adler da...@apple.com 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
On Tue, Nov 10, 2009 at 8:30 PM, Darin Adler da...@apple.com 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] WTFNoncopyable namespace and ADL
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
[webkit-dev] using namespace style guideline
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
