[webkit-dev] wiki spammer
Hi, Please ban demetgelin...@gmail.com user from trac, because it started to SPAM the wiki: 01:07 UsingGitWithWebKit edited by demetgelin...@gmail.com (diff) 01:02 WikiStart edited by demetgelin...@gmail.com (diff) I removed these SPAMs. PS. We should add captcha for the registration to avoid spamming in the future. br, Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Loop invariant code motion support
Hi. In this article http://wingolog.org/archives/2011/10/28/javascriptcore-the-webkit-js-implementationis saying that DFG jit doesn't support loop invariant code motion. But the article is written on 28 October, so does DFG currently support loop invariant code motion or is anyone working on it?? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Loop invariant code motion support
On Mon, 2012-02-27 at 18:55 +0400, vahag vardanyan wrote: DFG jit doesn't support loop invariant code motion. See https://bugs.webkit.org/show_bug.cgi?id=76770 In short, maybe JSC will do LICM in a few months, but there are some refactorings to do before then. Andy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
24.02.2012, в 10:00, Adam Barth написал(а): I'm happy to re-check them for license errors. If you can send me a list of the license errors you've noticed, I'll make sure they get addressed. For the record, I sent comments via private e-mail, and Adam refused to follow up on this promise (there was a partial patch he made before receiving my e-mail, but that was all). A number the files still have license errors, mostly copyright assigned to Google on code that was written by others. I did not send a specific list of things to fix, however I don't think that it's too much to ask one to go through patches in a specific area they reviewed recently. I'm deeply concerned about the way this refactoring is implemented - it doesn't have much of a meaningful purpose overall, and patches are reviewed carelessly. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
2012/2/27 Adam Barth aba...@webkit.org: 2012/2/27 Alexey Proskuryakov a...@webkit.org: 24.02.2012, в 10:00, Adam Barth написал(а): I'm happy to re-check them for license errors. If you can send me a list of the license errors you've noticed, I'll make sure they get addressed. For the record, I sent comments via private e-mail, and Adam refused to follow up on this promise (there was a partial patch he made before receiving my e-mail, but that was all). A number the files still have license errors, mostly copyright assigned to Google on code that was written by others. I did not send a specific list of things to fix, however I don't think that it's too much to ask one to go through patches in a specific area they reviewed recently. I'm deeply concerned about the way this refactoring is implemented - it doesn't have much of a meaningful purpose overall, and patches are reviewed carelessly. Huh? I'm sorry, I thought I addressed all the issues you spotted. Are there more I missed? I certainly don't have any wish (or motivation) to mess up the copyright blocks. For the record, I re-checked the three issues Alexey pointed me to in private email. Two have been fixed and one was in a patch that was never reviewed or landed. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit modularization
2012/2/27 Alexey Proskuryakov a...@webkit.org:
27.02.2012, в 11:54, Adam Barth написал(а):
Huh? I'm sorry, I thought I addressed all the issues you spotted.
Are there more I missed? I certainly don't have any wish (or
motivation) to mess up the copyright blocks.
Thank you!
I made the conclusion that you were unwilling to address the remaining issues
based on the fact that a number of them remain unaddressed, and that your
response was just that you'll be more careful in the future.
Two have been fixed and one was in a patch that was never reviewed or landed.
Which bug has the patch? I can't find it in request queue.
This is the one that was in a patch that was never reviewed or landed:
https://bugs.webkit.org/attachment.cgi?id=128716action=review
We're still working on removing ENABLE(SQL_DATABASE) ifdefs from
WebCore proper (e.g., I need to address Morrita's comments on
https://bugs.webkit.org/show_bug.cgi?id=79633). We'll likely come
back to this patch once we've made more progress on SQL database, and
hopefully we'll get the copyright block right then.
I have now spent the time to hunt down a few more specific license issues
currently in ToT:
JSDOMWebAudioCustom.cpp is LGPL
JSDOMWindowWebSocketCustom.cpp is LGPL
DOMWindowSQLDatabase.cpp and .h have Google as copyright holder (I'm fairly
sure this code was written by Apple)
NavigatorGeolocation.{h,cpp,idl} have Google as copyright holder, which may
or may not be correct (I think it's Apple)
NavigatorMediaStream.{h,cpp,idl} have Google as copyright holder, which may
or may not be correct (I think it's Ericsson)
DOMURLMediaStream.idl is LGPL
Thanks. I'll fix these by EOD.
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Moving WTF out of JavaScriptCore
Thank you, particularly to the Qt/Gtk folks who further readied their ports for this move over the last month. We're ready to go forward with this. We will be moving Source/JavaScriptCore/wtf to Source/WTF (and associated build files) this Wednesday, Feb 27th, 5PM PST. The move will likely break a couple bots, but I'll be watching the bots and will pick up any pieces. Let me know if you have issues with this specific timeframe, and thanks again for all your help. -eric On Tue, Jan 10, 2012 at 10:35 AM, Eric Seidel e...@webkit.org wrote: If a Qt person wants to make this move even less error-prone for Qt, adding a newwtf.a library which just builds WTF/Stub.cpp and links it into JavaScriptCore (similar to what Mac, Gtk, and Chromium do today), then there won't need to be any guess work on my part when moving wtf.a I'll have newwtf.a as an example. If you look in Source/WTF/ you can see examples of how Gtk, Mac and Chromium build/link in newwtf.a today. On Tue, Jan 10, 2012 at 7:41 AM, Jarred Nicholls jar...@webkit.org wrote: On Tue, Jan 10, 2012 at 5:41 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Tue, Jan 10, 2012 at 7:07 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jan 9, 2012 at 8:36 PM, Eric Seidel e...@webkit.org wrote: We've been talking about moving WTF out of JavaScriptCore for a long time. We believe we're nearly there. https://bugs.webkit.org/show_bug.cgi?id=75673 This will mean that WTF will be built as a separate static library on all ports. The plan is to do this move all in one piece, after work hours PST, when the tree is least active. It won't be the most beautiful transition (as we're likely to break at least one port in the process), but we'll try not to make too much of a mess. We believe all the ports are ready for the move, except AppleWin: https://bugs.webkit.org/show_bug.cgi?id=75897 Once AppleWin is ready we'll schedule a date for the transition and announce it one this thread. Hi Eric, Is there a patch somewhere or you are still working on it? The bug link contains nothing. I would like to apply it here and test the Qt port so you'll get a bit more confidence before landing it. I believe other ports are interested too. Nevermind wtf is already a static lib for Qt :D. /me is going to hide himself for not opening wtf.pro for a while. To be clear, if we're talking about moving Source/JavaScriptCore/wtf = Source/WTF, there would still be project file changes necessary to support that move, so testing it wouldn't hurt :) -Jarred Thanks. Thanks! -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ 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] Moving WTF out of JavaScriptCore
This will require some coordination to ensure that it doesn't break Apple's internal builds. It would be great if you could post a patch ahead of time so that we have some time to test and prepare for the changes on our side. Thanks, - Mark On 2012-02-27, at 15:27, Eric Seidel e...@webkit.org wrote: Thank you, particularly to the Qt/Gtk folks who further readied their ports for this move over the last month. We're ready to go forward with this. We will be moving Source/JavaScriptCore/wtf to Source/WTF (and associated build files) this Wednesday, Feb 27th, 5PM PST. The move will likely break a couple bots, but I'll be watching the bots and will pick up any pieces. Let me know if you have issues with this specific timeframe, and thanks again for all your help. -eric On Tue, Jan 10, 2012 at 10:35 AM, Eric Seidel e...@webkit.org wrote: If a Qt person wants to make this move even less error-prone for Qt, adding a newwtf.a library which just builds WTF/Stub.cpp and links it into JavaScriptCore (similar to what Mac, Gtk, and Chromium do today), then there won't need to be any guess work on my part when moving wtf.a I'll have newwtf.a as an example. If you look in Source/WTF/ you can see examples of how Gtk, Mac and Chromium build/link in newwtf.a today. On Tue, Jan 10, 2012 at 7:41 AM, Jarred Nicholls jar...@webkit.org wrote: On Tue, Jan 10, 2012 at 5:41 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Tue, Jan 10, 2012 at 7:07 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jan 9, 2012 at 8:36 PM, Eric Seidel e...@webkit.org wrote: We've been talking about moving WTF out of JavaScriptCore for a long time. We believe we're nearly there. https://bugs.webkit.org/show_bug.cgi?id=75673 This will mean that WTF will be built as a separate static library on all ports. The plan is to do this move all in one piece, after work hours PST, when the tree is least active. It won't be the most beautiful transition (as we're likely to break at least one port in the process), but we'll try not to make too much of a mess. We believe all the ports are ready for the move, except AppleWin: https://bugs.webkit.org/show_bug.cgi?id=75897 Once AppleWin is ready we'll schedule a date for the transition and announce it one this thread. Hi Eric, Is there a patch somewhere or you are still working on it? The bug link contains nothing. I would like to apply it here and test the Qt port so you'll get a bit more confidence before landing it. I believe other ports are interested too. Nevermind wtf is already a static lib for Qt :D. /me is going to hide himself for not opening wtf.pro for a while. To be clear, if we're talking about moving Source/JavaScriptCore/wtf = Source/WTF, there would still be project file changes necessary to support that move, so testing it wouldn't hurt :) -Jarred Thanks. Thanks! -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ 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] Moving WTF out of JavaScriptCore
The patch will be large (and thus likely un-reviewable/readable). But sure. I'll make sure to have a Mac-only patch for you by EOD tomorrow. I'll email this list with a link to the patch. On Mon, Feb 27, 2012 at 3:43 PM, Mark Rowe mr...@apple.com wrote: This will require some coordination to ensure that it doesn't break Apple's internal builds. It would be great if you could post a patch ahead of time so that we have some time to test and prepare for the changes on our side. Thanks, - Mark On 2012-02-27, at 15:27, Eric Seidel e...@webkit.org wrote: Thank you, particularly to the Qt/Gtk folks who further readied their ports for this move over the last month. We're ready to go forward with this. We will be moving Source/JavaScriptCore/wtf to Source/WTF (and associated build files) this Wednesday, Feb 27th, 5PM PST. The move will likely break a couple bots, but I'll be watching the bots and will pick up any pieces. Let me know if you have issues with this specific timeframe, and thanks again for all your help. -eric On Tue, Jan 10, 2012 at 10:35 AM, Eric Seidel e...@webkit.org wrote: If a Qt person wants to make this move even less error-prone for Qt, adding a newwtf.a library which just builds WTF/Stub.cpp and links it into JavaScriptCore (similar to what Mac, Gtk, and Chromium do today), then there won't need to be any guess work on my part when moving wtf.a I'll have newwtf.a as an example. If you look in Source/WTF/ you can see examples of how Gtk, Mac and Chromium build/link in newwtf.a today. On Tue, Jan 10, 2012 at 7:41 AM, Jarred Nicholls jar...@webkit.org wrote: On Tue, Jan 10, 2012 at 5:41 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Tue, Jan 10, 2012 at 7:07 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jan 9, 2012 at 8:36 PM, Eric Seidel e...@webkit.org wrote: We've been talking about moving WTF out of JavaScriptCore for a long time. We believe we're nearly there. https://bugs.webkit.org/show_bug.cgi?id=75673 This will mean that WTF will be built as a separate static library on all ports. The plan is to do this move all in one piece, after work hours PST, when the tree is least active. It won't be the most beautiful transition (as we're likely to break at least one port in the process), but we'll try not to make too much of a mess. We believe all the ports are ready for the move, except AppleWin: https://bugs.webkit.org/show_bug.cgi?id=75897 Once AppleWin is ready we'll schedule a date for the transition and announce it one this thread. Hi Eric, Is there a patch somewhere or you are still working on it? The bug link contains nothing. I would like to apply it here and test the Qt port so you'll get a bit more confidence before landing it. I believe other ports are interested too. Nevermind wtf is already a static lib for Qt :D. /me is going to hide himself for not opening wtf.pro for a while. To be clear, if we're talking about moving Source/JavaScriptCore/wtf = Source/WTF, there would still be project file changes necessary to support that move, so testing it wouldn't hurt :) -Jarred Thanks. Thanks! -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ 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] Moving WTF out of JavaScriptCore
On 2012-02-27, at 15:46, Eric Seidel e...@webkit.org wrote: The patch will be large (and thus likely un-reviewable/readable). But sure. I'll make sure to have a Mac-only patch for you by EOD tomorrow. Mac-only in what sense? We'd like to ensure it doesn't break our Windows builds too! I'll email this list with a link to the patch. Thanks! - Mark On Mon, Feb 27, 2012 at 3:43 PM, Mark Rowe mr...@apple.com wrote: This will require some coordination to ensure that it doesn't break Apple's internal builds. It would be great if you could post a patch ahead of time so that we have some time to test and prepare for the changes on our side. Thanks, - Mark On 2012-02-27, at 15:27, Eric Seidel e...@webkit.org wrote: Thank you, particularly to the Qt/Gtk folks who further readied their ports for this move over the last month. We're ready to go forward with this. We will be moving Source/JavaScriptCore/wtf to Source/WTF (and associated build files) this Wednesday, Feb 27th, 5PM PST. The move will likely break a couple bots, but I'll be watching the bots and will pick up any pieces. Let me know if you have issues with this specific timeframe, and thanks again for all your help. -eric On Tue, Jan 10, 2012 at 10:35 AM, Eric Seidel e...@webkit.org wrote: If a Qt person wants to make this move even less error-prone for Qt, adding a newwtf.a library which just builds WTF/Stub.cpp and links it into JavaScriptCore (similar to what Mac, Gtk, and Chromium do today), then there won't need to be any guess work on my part when moving wtf.a I'll have newwtf.a as an example. If you look in Source/WTF/ you can see examples of how Gtk, Mac and Chromium build/link in newwtf.a today. On Tue, Jan 10, 2012 at 7:41 AM, Jarred Nicholls jar...@webkit.org wrote: On Tue, Jan 10, 2012 at 5:41 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Tue, Jan 10, 2012 at 7:07 AM, Alexis Menard alexis.men...@openbossa.org wrote: On Mon, Jan 9, 2012 at 8:36 PM, Eric Seidel e...@webkit.org wrote: We've been talking about moving WTF out of JavaScriptCore for a long time. We believe we're nearly there. https://bugs.webkit.org/show_bug.cgi?id=75673 This will mean that WTF will be built as a separate static library on all ports. The plan is to do this move all in one piece, after work hours PST, when the tree is least active. It won't be the most beautiful transition (as we're likely to break at least one port in the process), but we'll try not to make too much of a mess. We believe all the ports are ready for the move, except AppleWin: https://bugs.webkit.org/show_bug.cgi?id=75897 Once AppleWin is ready we'll schedule a date for the transition and announce it one this thread. Hi Eric, Is there a patch somewhere or you are still working on it? The bug link contains nothing. I would like to apply it here and test the Qt port so you'll get a bit more confidence before landing it. I believe other ports are interested too. Nevermind wtf is already a static lib for Qt :D. /me is going to hide himself for not opening wtf.pro for a while. To be clear, if we're talking about moving Source/JavaScriptCore/wtf = Source/WTF, there would still be project file changes necessary to support that move, so testing it wouldn't hurt :) -Jarred Thanks. Thanks! -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil -- Alexis Menard (darktears) Software Engineer INdT Recife Brazil ___ 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] (no subject)
Hi all, If you don't use webkit-patch and Git, you can stop reading now. Otherwise ... Currently, webkit-patch -g has some special logic for figuring out what to diff against for Git checkouts. Specifically, webkit-patch -g commitish gets translated to the git equivalent of 'git diff commitish^..commitish'. Then, we have an additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to pick up any uncommitted changes, and if nothing is specified, we will attempt to diff against the remote master/trunk version. This is very useful if you typically want to just upload a single commit issue, but is a bit un-git-like, and actually thwarts some other use cases. My questions are: 1) Do you use -g foo to upload a single change? If so, would you be annoyed if I changed that syntax to a different argument, or eliminated it completely (so that you would have to type foo^..foo)? 2) Do you object to changing the default to match what 'git diff' does? This would change the defaults so that: a) instead of no arguments meaning diff against remote master, it would mean diff against what is staged for commit b) 'git diff commitish would show the diff between commitish and your current working directory If there is a consensus that we shouldn't change the defaults, I will likely implement a different command line argument that does mirror what git does. As an aside, I will probably be adding a patch that will figure out what the 'tracking' branch (as defined by branch.branchname.merge) is for your current checkout, and give webkit-patch a way to use that instead of the remote head (this would make using stacked local branches much easier). I haven't decided if this should be the default or if you should have to request this via something like 'webkit-patch diff -g UPSTREAM' instead; if you have an opinion, feel free to comment. There is a bug tracking this work at https://bugs.webkit.org/show_bug.cgi?id=76958 if you want to comment there instead of here or follow along with whatever ends up happening. Thanks, -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] webkit-patch and git revisions (was Re: (no subject))
Sorry, I'm not sure how I missed the subject line on this ... -- Dirk On Mon, Feb 27, 2012 at 5:56 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, If you don't use webkit-patch and Git, you can stop reading now. Otherwise ... Currently, webkit-patch -g has some special logic for figuring out what to diff against for Git checkouts. Specifically, webkit-patch -g commitish gets translated to the git equivalent of 'git diff commitish^..commitish'. Then, we have an additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to pick up any uncommitted changes, and if nothing is specified, we will attempt to diff against the remote master/trunk version. This is very useful if you typically want to just upload a single commit issue, but is a bit un-git-like, and actually thwarts some other use cases. My questions are: 1) Do you use -g foo to upload a single change? If so, would you be annoyed if I changed that syntax to a different argument, or eliminated it completely (so that you would have to type foo^..foo)? 2) Do you object to changing the default to match what 'git diff' does? This would change the defaults so that: a) instead of no arguments meaning diff against remote master, it would mean diff against what is staged for commit b) 'git diff commitish would show the diff between commitish and your current working directory If there is a consensus that we shouldn't change the defaults, I will likely implement a different command line argument that does mirror what git does. As an aside, I will probably be adding a patch that will figure out what the 'tracking' branch (as defined by branch.branchname.merge) is for your current checkout, and give webkit-patch a way to use that instead of the remote head (this would make using stacked local branches much easier). I haven't decided if this should be the default or if you should have to request this via something like 'webkit-patch diff -g UPSTREAM' instead; if you have an opinion, feel free to comment. There is a bug tracking this work at https://bugs.webkit.org/show_bug.cgi?id=76958 if you want to comment there instead of here or follow along with whatever ends up happening. Thanks, -- Dirk ___ 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] (no subject)
On Feb 27, 2012, at 5:56 PM, Dirk Pranke wrote: Hi all, If you don't use webkit-patch and Git, you can stop reading now. Otherwise ... Currently, webkit-patch -g has some special logic for figuring out what to diff against for Git checkouts. Specifically, webkit-patch -g commitish gets translated to the git equivalent of 'git diff commitish^..commitish'. Then, we have an additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to pick up any uncommitted changes, and if nothing is specified, we will attempt to diff against the remote master/trunk version. This is very useful if you typically want to just upload a single commit issue, but is a bit un-git-like, and actually thwarts some other use cases. My questions are: 1) Do you use -g foo to upload a single change? If so, would you be annoyed if I changed that syntax to a different argument, or eliminated it completely (so that you would have to type foo^..foo)? 2) Do you object to changing the default to match what 'git diff' does? This would change the defaults so that: a) instead of no arguments meaning diff against remote master, it would mean diff against what is staged for commit This would annoy me quite a lot -- Any delta including new files or anything implicitly staged (eg. by git stash apply) would not be included. Or do you mean git diff HEAD ? --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
On Mon, Feb 27, 2012 at 6:02 PM, Oliver Hunt oli...@apple.com wrote: On Feb 27, 2012, at 5:56 PM, Dirk Pranke wrote: Hi all, If you don't use webkit-patch and Git, you can stop reading now. Otherwise ... Currently, webkit-patch -g has some special logic for figuring out what to diff against for Git checkouts. Specifically, webkit-patch -g commitish gets translated to the git equivalent of 'git diff commitish^..commitish'. Then, we have an additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to pick up any uncommitted changes, and if nothing is specified, we will attempt to diff against the remote master/trunk version. This is very useful if you typically want to just upload a single commit issue, but is a bit un-git-like, and actually thwarts some other use cases. My questions are: 1) Do you use -g foo to upload a single change? If so, would you be annoyed if I changed that syntax to a different argument, or eliminated it completely (so that you would have to type foo^..foo)? 2) Do you object to changing the default to match what 'git diff' does? This would change the defaults so that: a) instead of no arguments meaning diff against remote master, it would mean diff against what is staged for commit This would annoy me quite a lot -- Any delta including new files or anything implicitly staged (eg. by git stash apply) would not be included. Or do you mean git diff HEAD ? I did not (i.e., I explcitly meant what you get with 'git diff' and not 'git diff HEAD'). In order to include both staged and unstaged changes, you would have to do 'webkit-patch -g HEAD' (just like you would have to do 'git diff HEAD'). Your annoyance is duly noted, and it might make more sense for 'HEAD' to be the default; if we did that, though, we might want some other way to indicate just the unstaged changes ... As a broader point ... there are obviously a lot of different use cases possible with git, and any logic we have is likely to work really well for some and really annoy others. My thinking in proposing the change above is that at least we'd match what git does by default, and so it's fairly understandable (if you understand git). We could also add some sort of preference to webkit-patch here ... that has the usual discoverability issues, but might make sense given git's TMTOWTDI nature. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Start to run layout-test on EFL build bot.
Excellent!! 2012년 2월 27일 오전 10:08, Gyuyoung Kim gyuyoung@samsung.com님의 말: Hello WebKit folks, Finally, EFL build bot starts to run the layout test (as well as WebKit build) from Yesterday. - url : http://build.webkit.org/builders/EFL%20Linux%20Release = Results: 19475/28486 tests passed (68.4%) = Tests to be fixed (9011): 1 DumpRenderTree crash ( 0.0%) 28 no expected results found ( 0.3%) 256 text diff mismatch ( 2.8%) 21 image mismatch ( 0.2%) 8705 skipped (96.6%) = Tests that will only be fixed if they crash (WONTFIX) (0): As you can see from the above result, pass ratio of EFL port layout test is worse than the other ports. So, WebKit EFL developers are going to submit a number of patches related to layout test. I hope that submitted patches are going to be reviewed by many reviewers as well. In addition, I’m planning to add a new server for WebKit EFL debug build. I expect the new server will be set up within next month. Cheers, Gyuyoung. ___ 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] (no subject)
I typically use webkit-patch to upload a single patch but really like your proposed change in 2a) to diff against what is staged for commit. This looks like it will be useful and cool. Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Dirk Pranke [mailto:dpra...@chromium.org] Sent: Monday, February 27, 2012 08:56 PM To: WebKit-Dev webkit-dev@lists.webkit.org Subject: [webkit-dev] (no subject) Hi all, If you don't use webkit-patch and Git, you can stop reading now. Otherwise ... Currently, webkit-patch -g has some special logic for figuring out what to diff against for Git checkouts. Specifically, webkit-patch -g commitish gets translated to the git equivalent of 'git diff commitish^..commitish'. Then, we have an additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to pick up any uncommitted changes, and if nothing is specified, we will attempt to diff against the remote master/trunk version. This is very useful if you typically want to just upload a single commit issue, but is a bit un-git-like, and actually thwarts some other use cases. My questions are: 1) Do you use -g foo to upload a single change? If so, would you be annoyed if I changed that syntax to a different argument, or eliminated it completely (so that you would have to type foo^..foo)? 2) Do you object to changing the default to match what 'git diff' does? This would change the defaults so that: a) instead of no arguments meaning diff against remote master, it would mean diff against what is staged for commit b) 'git diff commitish would show the diff between commitish and your current working directory If there is a consensus that we shouldn't change the defaults, I will likely implement a different command line argument that does mirror what git does. As an aside, I will probably be adding a patch that will figure out what the 'tracking' branch (as defined by branch.branchname.merge) is for your current checkout, and give webkit-patch a way to use that instead of the remote head (this would make using stacked local branches much easier). I haven't decided if this should be the default or if you should have to request this via something like 'webkit-patch diff -g UPSTREAM' instead; if you have an opinion, feel free to comment. There is a bug tracking this work at https://bugs.webkit.org/show_bug.cgi?id=76958 if you want to comment there instead of here or follow along with whatever ends up happening. Thanks, -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
Do people really use git diff that often? I don't use git much but when I do I always get annoyed by the way git diff works because I almost always want git diff master. But then I don't really use git that much especially for WebKit, so ignore me if people who primarily use git thinks this is a good idea. - Ryosuke On Mon, Feb 27, 2012 at 5:56 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, If you don't use webkit-patch and Git, you can stop reading now. Otherwise ... Currently, webkit-patch -g has some special logic for figuring out what to diff against for Git checkouts. Specifically, webkit-patch -g commitish gets translated to the git equivalent of 'git diff commitish^..commitish'. Then, we have an additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to pick up any uncommitted changes, and if nothing is specified, we will attempt to diff against the remote master/trunk version. This is very useful if you typically want to just upload a single commit issue, but is a bit un-git-like, and actually thwarts some other use cases. My questions are: 1) Do you use -g foo to upload a single change? If so, would you be annoyed if I changed that syntax to a different argument, or eliminated it completely (so that you would have to type foo^..foo)? 2) Do you object to changing the default to match what 'git diff' does? This would change the defaults so that: a) instead of no arguments meaning diff against remote master, it would mean diff against what is staged for commit b) 'git diff commitish would show the diff between commitish and your current working directory If there is a consensus that we shouldn't change the defaults, I will likely implement a different command line argument that does mirror what git does. As an aside, I will probably be adding a patch that will figure out what the 'tracking' branch (as defined by branch.branchname.merge) is for your current checkout, and give webkit-patch a way to use that instead of the remote head (this would make using stacked local branches much easier). I haven't decided if this should be the default or if you should have to request this via something like 'webkit-patch diff -g UPSTREAM' instead; if you have an opinion, feel free to comment. There is a bug tracking this work at https://bugs.webkit.org/show_bug.cgi?id=76958 if you want to comment there instead of here or follow along with whatever ends up happening. Thanks, -- Dirk ___ 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
