[webkit-dev] Coding Style: Clarify some cases with spacing
Hi there, In bug 27499 (https://bugs.webkit.org/show_bug.cgi?id=27499) it was pointed out that the coding style guide doesn't clarify whether it is allowed to place a space before a comma or semicolon in a control condition or in functions. Thus asking the question whether the three following code snippets are should be discouraged by the coding style guide or not: for (int i = 0 ; i 10 ; i++) doSomething(); // Qt's foreach foreach (QString item , items) doSomething(); f(a , b); Personally I would opt for discouraging this, which David Levin points out to be more or less the current project style. If we can agree on this, I can patch the coding style guide. Cheers, Kenneth ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] SVN on Windows and the merits of svn:eol-style
If you do not develop on Windows, you may skip to the *** Question *** portion below. *** PSA for Windows developers *** Until now WebKit developers on Windows have had to use the Cygwin version of svn, rather than a standard Windows svn, due to limitations in the WebKit scripts, build process, etc. On https://bugs.webkit.org/show_bug.cgi?id=27323 I have been working to remove those roadblocks, and today I have locally succeeded in using my Windows SVN to: * check out * update (via update-webkit and resolve-ChangeLogs) * build (via build-webkit) * run (via run-safari) * prepare patches (via prepare-ChangeLog and svn-create-patch) * apply and unapply patches (via svn-apply and svn-unapply) * commit (using commit-log-editor) Added bonus of a couple other fixes: I did this with a WebKit-inside-Chromium checkout. In theory this means projects that wish to include WebKit from the master repository (via svn:externals or some other mechanism) as part of their source tree may be able to develop in a single checkout. Not all these patches have been reviewed and landed yet, but things are close. *** Question *** There is one roadblock to this setup. SVN-on-Windows seems to have a bug where sometimes (depending on the state of the repository and the checkout), the diffs it produces for files without svn:eol-style set won't apply/unapply cleanly, due to line ending issues. The obvious workaround is to set svn:eol-style everywhere. This has other side benefits (e.g. preventing files from being checked in with mixed line endings, and preventing line-ending-sensitive files from being changed accidentally), and I am told by Eric Seidel that in fact some time ago Darin Adler used to try and maintain something like this. As a result, a large portion of the WebKit tree already has this property set. My question is, how desirable and feasible would it be to return to having eol-style everywhere? For a relevant anecdote, in Chromium we enforce that files have svn:eol-style. This was done using three steps: * Scripts were used to find files lacking svn:eol-style and set it appropriately. * A commit hook was added to prevent developers from regressing this. * We document a set of auto-props to configure SVN with, so that it will automatically add eol-style on new files without developers having to do it manually. I am not capable of doing the first two of these steps myself, but there are Chromium team members who could consult if we decided this was a desirable path for WebKit. The goal would be to minimize disruption and not cause any ongoing annoyance. Comments? PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SVN on Windows and the merits of svn:eol-style
It seems like we should either be consistent and set svn:eol-style: native in all the appropriate files or remove it from all of them. Having a some files with the property arbitrarily seems like a bunch of unneeded entropy. Adam On Tue, Jul 21, 2009 at 4:11 PM, Peter Kastingpkast...@google.com wrote: If you do not develop on Windows, you may skip to the *** Question *** portion below. *** PSA for Windows developers *** Until now WebKit developers on Windows have had to use the Cygwin version of svn, rather than a standard Windows svn, due to limitations in the WebKit scripts, build process, etc. On https://bugs.webkit.org/show_bug.cgi?id=27323 I have been working to remove those roadblocks, and today I have locally succeeded in using my Windows SVN to: * check out * update (via update-webkit and resolve-ChangeLogs) * build (via build-webkit) * run (via run-safari) * prepare patches (via prepare-ChangeLog and svn-create-patch) * apply and unapply patches (via svn-apply and svn-unapply) * commit (using commit-log-editor) Added bonus of a couple other fixes: I did this with a WebKit-inside-Chromium checkout. In theory this means projects that wish to include WebKit from the master repository (via svn:externals or some other mechanism) as part of their source tree may be able to develop in a single checkout. Not all these patches have been reviewed and landed yet, but things are close. *** Question *** There is one roadblock to this setup. SVN-on-Windows seems to have a bug where sometimes (depending on the state of the repository and the checkout), the diffs it produces for files without svn:eol-style set won't apply/unapply cleanly, due to line ending issues. The obvious workaround is to set svn:eol-style everywhere. This has other side benefits (e.g. preventing files from being checked in with mixed line endings, and preventing line-ending-sensitive files from being changed accidentally), and I am told by Eric Seidel that in fact some time ago Darin Adler used to try and maintain something like this. As a result, a large portion of the WebKit tree already has this property set. My question is, how desirable and feasible would it be to return to having eol-style everywhere? For a relevant anecdote, in Chromium we enforce that files have svn:eol-style. This was done using three steps: * Scripts were used to find files lacking svn:eol-style and set it appropriately. * A commit hook was added to prevent developers from regressing this. * We document a set of auto-props to configure SVN with, so that it will automatically add eol-style on new files without developers having to do it manually. I am not capable of doing the first two of these steps myself, but there are Chromium team members who could consult if we decided this was a desirable path for WebKit. The goal would be to minimize disruption and not cause any ongoing annoyance. Comments? PK ___ 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] SVN on Windows and the merits of svn:eol-style
On Tue, Jul 21, 2009 at 5:06 PM, Adam Barth aba...@webkit.org wrote: It seems like we should either be consistent and set svn:eol-style: native in all the appropriate files or remove it from all of them. Note that you don't always want native (at least I think you don't). For example, in Chromium we've ended up marking .cc/.h files, as well as .sh files, as LF. .sln/.vcproj are CRLF (although I'm less sure what the issue there is... it seems like native had some subtle issue or other). I tend to feel like eol-style is unilaterally good except for any hassle it causes developers to go through (hence the importance of auto-props). Even having it on some files doesn't seem like a bad thing to me; I certainly wouldn't go through the tree and remove it from things. (In fact, removing it from some of the scripts in WebKitTools would break my checkout.) PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SVN on Windows and the merits of svn:eol-style
I was actually under the impression that svn:eol-stye was supposed to be set! I tend to make sure they are set to native in most places, and CRLF for sln/vcproj files. If this isn't documented somewhere (coding rules?), it probably should be. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SVN on Windows and the merits of svn:eol-style
Peter Kasting wrote: Note that you don't always want native (at least I think you don't). For example, in Chromium we've ended up marking .cc/.h files, as well as .sh files, as LF. .sln/.vcproj are CRLF (although I'm less sure what the issue there is... it seems like native had some subtle issue or other). We (Chromium) don't really have .sln or .vcproj files checked in any longer, but when we did, I think they were set to native. I suppose this made it easier to edit them on platforms with editors that don't expect CRLFs. Still, I would have chosen CRLF to make it easier to carry diffs, whole files, and even entire tarballs between platforms. Obviously, LF would be out because MSVS is going to write CRLFs in .sln and .vcproj files regardless of what you tell Subversion. Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Coding Style: Clarify some cases with spacing
I believe it is quite well established that a space should not be allowed before a ; or , in such circumstances. (I have r-ed for it even ;) ). I think we should definitely explicitly call this out in the guidelines if it is not already. -Sam On Tue, Jul 21, 2009 at 4:05 PM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: Hi there, In bug 27499 (https://bugs.webkit.org/show_bug.cgi?id=27499) it was pointed out that the coding style guide doesn't clarify whether it is allowed to place a space before a comma or semicolon in a control condition or in functions. Thus asking the question whether the three following code snippets are should be discouraged by the coding style guide or not: for (int i = 0 ; i 10 ; i++) doSomething(); // Qt's foreach foreach (QString item , items) doSomething(); f(a , b); Personally I would opt for discouraging this, which David Levin points out to be more or less the current project style. If we can agree on this, I can patch the coding style guide. Cheers, Kenneth ___ 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] Coding Style: Clarify some cases with spacing
On Jul 21, 2009, at 6:56 PM, Sam Weinig wrote: I believe it is quite well established that a space should not be allowed before a ; or , in such circumstances. (I have r-ed for it even ;) ). I think we should definitely explicitly call this out in the guidelines if it is not already. The examples in the coding style guidelines use the right style (i.e. no space before the comma or semicolon), it would be fine to make it an explicit rule. - Maciej -Sam On Tue, Jul 21, 2009 at 4:05 PM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: Hi there, In bug 27499 (https://bugs.webkit.org/show_bug.cgi?id=27499) it was pointed out that the coding style guide doesn't clarify whether it is allowed to place a space before a comma or semicolon in a control condition or in functions. Thus asking the question whether the three following code snippets are should be discouraged by the coding style guide or not: for (int i = 0 ; i 10 ; i++) doSomething(); // Qt's foreach foreach (QString item , items) doSomething(); f(a , b); Personally I would opt for discouraging this, which David Levin points out to be more or less the current project style. If we can agree on this, I can patch the coding style guide. Cheers, Kenneth ___ 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] TeaShark
Hi, According to the following archive http://lists.macosforge.org/pipermail/webkit-dev/2007-September/002427.h tml I wonder if there is source code release of TeaShark or not. Thanks, -Hieu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
