Re: [webkit-dev] Python on the Tiger build bot
I heard on #webkit that the Tiger bot has been on Python 2.5 for some time, and found r+ for https://bugs.webkit.org/show_bug.cgi?id=38886 and https://bugs.webkit.org/show_bug.cgi?id=38822. I believe we have consensus to use Python 2.5 (or later) for webkit development environment. I tried to land autoinstalled pywebsocket 0.5 https://bugs.webkit.org/show_bug.cgi?id=38034 again, but get error on tiger bot when launching websocket server as below. Is python on the tiger bot still 2.3? I'm wondering why the script raises SyntaxError at with-statement, although it uses from __future__ import with_statement at the beginning of the same file. Doesn't python raise error when it tries to import with_statement, rather than it sees with statement later? Anyway, I just marked to skip websocket/tests on tiger for now, hoping python2.5 is available on tiger bot soon. This is log: http://build.webkit.org/builders/Tiger%20Intel%20Release/builds/11971/steps/layout-test/logs/stdio websocket/tests .Traceback (most recent call last): File WebKitTools/Scripts/new-run-webkit-websocketserver, line 38, in ? import webkitpy.layout_tests.port.websocket_server as websocket_server File /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKitTools/Scripts/webkitpy/layout_tests/port/websocket_server.py, line 241 with codecs.open(self._pidfile, w, ascii) as file: ^ SyntaxError: invalid syntax websocket/tests/bad-handshake-crash.html - failed . websocket/tests/bad-sub-protocol-control-chars.html - failed . websocket/tests/bad-sub-protocol-empty.html - failed . websocket/tests/bad-sub-protocol-non-ascii.html - failed . websocket/tests/bufferedAmount-after-close.html - failed . websocket/tests/close-on-navigate-new-location.html - failed . websocket/tests/close-on-unload-and-force-gc.html - failed . websocket/tests/close-on-unload-reference-in-parent.html - failed . websocket/tests/close-on-unload.html - failed . websocket/tests/cross-origin.html - failed . websocket/tests/error-detect.html - failed . websocket/tests/frame-length-longer-than-buffer.html - failed . websocket/tests/frame-length-skip.html - failed . websocket/tests/frame-lengths.html - failed . websocket/tests/handshake-error.html - failed . websocket/tests/handshake-fail-by-cross-origin.html - failed . websocket/tests/handshake-fail-by-sub-protocol-mismatch.html - failed . websocket/tests/httponly-cookie.pl - failed . websocket/tests/long-invalid-header.html - failed . websocket/tests/multiple-connections.html - failed Exiting early after 20 failures. 17934 tests run. 762.46s total testing time Traceback (most recent call last): File WebKitTools/Scripts/new-run-webkit-websocketserver, line 38, in ? import webkitpy.layout_tests.port.websocket_server as websocket_server File /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKitTools/Scripts/webkitpy/layout_tests/port/websocket_server.py, line 241 with codecs.open(self._pidfile, w, ascii) as file: ^ SyntaxError: invalid syntax -- ukai On Tue, May 11, 2010 at 15:07, Maciej Stachowiak m...@apple.com wrote: On May 10, 2010, at 11:01 PM, Eric Seidel wrote: On Mon, May 10, 2010 at 2:25 AM, Maciej Stachowiak m...@apple.com wrote: My feeling about requiring a higher Python version for Tiger remains this: I'd prefer that we provide an easy means to do the install of Python 2.6 (ideally a single script you can run, and ideally without affecting the system copy), rather than making every Tiger developer figure it out on their own. http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html For those of us who still need to support Tiger, it would be a huge hassle to have to figure out how to update Python manually to even run the layout tests. The fact that it's not a primary development platform doesn't mean that it's ok to add stumbling blocks to the development process. In fact, it kinda makes it less ok, because then it takes more work to shift gears when fixing a Tiger-specific bug. Provided: https://bugs.webkit.org/show_bug.cgi?id=38886 At minimum, there should be instructions here, and ideally the install should be one step: http://webkit.org/building/tools.html Provided: https://bugs.webkit.org/show_bug.cgi?id=38822 Yay thanks! (Will try to review these later if no one beats me.) Regards, Maciej ___ 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
That error looks like its trying to use python 2.5. Skipping the websocket tests on Tiger (manually at least) is bad. Would be better to do it based on detected python. Filed: https://bugs.webkit.org/show_bug.cgi?id=39058 about doing just that. -eric On Thu, May 13, 2010 at 2:14 AM, Fumitoshi Ukai (鵜飼文敏) u...@chromium.org wrote: I heard on #webkit that the Tiger bot has been on Python 2.5 for some time, and found r+ for https://bugs.webkit.org/show_bug.cgi?id=38886 and https://bugs.webkit.org/show_bug.cgi?id=38822. I believe we have consensus to use Python 2.5 (or later) for webkit development environment. I tried to land autoinstalled pywebsocket 0.5 https://bugs.webkit.org/show_bug.cgi?id=38034 again, but get error on tiger bot when launching websocket server as below. Is python on the tiger bot still 2.3? I'm wondering why the script raises SyntaxError at with-statement, although it uses from __future__ import with_statement at the beginning of the same file. Doesn't python raise error when it tries to import with_statement, rather than it sees with statement later? Anyway, I just marked to skip websocket/tests on tiger for now, hoping python2.5 is available on tiger bot soon. This is log: http://build.webkit.org/builders/Tiger%20Intel%20Release/builds/11971/steps/layout-test/logs/stdio websocket/tests .Traceback (most recent call last): File WebKitTools/Scripts/new-run-webkit-websocketserver, line 38, in ? import webkitpy.layout_tests.port.websocket_server as websocket_server File /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKitTools/Scripts/webkitpy/layout_tests/port/websocket_server.py, line 241 with codecs.open(self._pidfile, w, ascii) as file: ^ SyntaxError: invalid syntax websocket/tests/bad-handshake-crash.html - failed . websocket/tests/bad-sub-protocol-control-chars.html - failed . websocket/tests/bad-sub-protocol-empty.html - failed . websocket/tests/bad-sub-protocol-non-ascii.html - failed . websocket/tests/bufferedAmount-after-close.html - failed . websocket/tests/close-on-navigate-new-location.html - failed . websocket/tests/close-on-unload-and-force-gc.html - failed . websocket/tests/close-on-unload-reference-in-parent.html - failed . websocket/tests/close-on-unload.html - failed . websocket/tests/cross-origin.html - failed . websocket/tests/error-detect.html - failed . websocket/tests/frame-length-longer-than-buffer.html - failed . websocket/tests/frame-length-skip.html - failed . websocket/tests/frame-lengths.html - failed . websocket/tests/handshake-error.html - failed . websocket/tests/handshake-fail-by-cross-origin.html - failed . websocket/tests/handshake-fail-by-sub-protocol-mismatch.html - failed . websocket/tests/httponly-cookie.pl - failed . websocket/tests/long-invalid-header.html - failed . websocket/tests/multiple-connections.html - failed Exiting early after 20 failures. 17934 tests run. 762.46s total testing time Traceback (most recent call last): File WebKitTools/Scripts/new-run-webkit-websocketserver, line 38, in ? import webkitpy.layout_tests.port.websocket_server as websocket_server File /Volumes/Data/WebKit-BuildSlave/tiger-intel-release/build/WebKitTools/Scripts/webkitpy/layout_tests/port/websocket_server.py, line 241 with codecs.open(self._pidfile, w, ascii) as file: ^ SyntaxError: invalid syntax -- ukai On Tue, May 11, 2010 at 15:07, Maciej Stachowiak m...@apple.com wrote: On May 10, 2010, at 11:01 PM, Eric Seidel wrote: On Mon, May 10, 2010 at 2:25 AM, Maciej Stachowiak m...@apple.com wrote: My feeling about requiring a higher Python version for Tiger remains this: I'd prefer that we provide an easy means to do the install of Python 2.6 (ideally a single script you can run, and ideally without affecting the system copy), rather than making every Tiger developer figure it out on their own. http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg10331.html For those of us who still need to support Tiger, it would be a huge hassle to have to figure out how to update Python manually to even run the layout tests. The fact that it's not a primary development platform doesn't mean that it's ok to add stumbling blocks to the development process. In fact, it kinda makes it less ok, because then it takes more work to shift gears when fixing a Tiger-specific bug. Provided: https://bugs.webkit.org/show_bug.cgi?id=38886 At minimum, there should be instructions here, and ideally the install should be one step: http://webkit.org/building/tools.html Provided: https://bugs.webkit.org/show_bug.cgi?id=38822 Yay thanks! (Will try to review these later if no one beats me.) Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Ancient patches in pending-review
One of the least fun things in the project is to pour a bunch of effort into writing a patch only to see it sit forever waiting for review. In the past, I've tried to single-handedly tackle the patches that have been up for review for more than a month. That approach is less than ideal because (1) it's too big a task for one person and (2) it causes me to review outside my area. As we've been discussing on #webkit recently, we'd like for reviewers to focus their reviews on their area of expertise to make sure each patch gets a high-quality review before landing. I've triaged the oldest patches in http://webkit.org/pending-review into groups and assigned an owner (see below). You don't need to review the patches in a group just because I've assigned it to you, but if you don't review them, please find someone to look at them. If a patch is unassigned, please consider whether you feel confident reviewing patches in that area. If you're an expert in an area by not necessarily a reviewer yet, please consider giving one or more of these patches an informal review. An informal review is especially useful if it points out areas of a patch that the contributor can improve. Ideally, an informal review would cause the contributor to improve their patch before it receives a formal review. (If you're not a reviewer, please don't alter the Review flag; just leave a comment.) Our biggest problem spots appear to be Editing and WINCE. Below, I've asked Enrica to provide informal reviews of the editing patches and Ojan to provide the formal reviews. I've also asked jamesr to provide informal reviews for the CSS and Rendering patches because he's expressed interest in learning Hyatt's secret tricks. As for WINCE, are there any reviewers interested in reviewing patches for that port? Adam Editing (Enrica, Ojan) * 24943: Command-B and Command-I do not generate keydown events in contentEditable regions. * 35632: htmlediting.cpp : isEmptyTableCell() is incomplete * 32605: Regression: Selection anchor + focus swap when arrow keys after setBaseAndExtent * 32077: textarea grows when you type * 36359: Double clicking page's last editable inline element doesn't select a word. * 32123: cursor movement and text selection does not work well if a block is followed by an inline * 35791: 2x execCommand rea...@null * 35530: Enum value FORWARD, BACKWARD, RIGHT, LEFT are causing macro conflicts. WINCE (???) - Do we have any WINCE reviewers? * 34953: Implement DEFINE_STUB_FUNCTION for WinCE * 33004: NetworkStateNotifierWin.cpp doesn't work always * 32169: Implement TextCodec for WINCE port * 37287: Rename Wince file to WinCE * 32963: buildfix for ResourceHandleWin.cpp * 37440: [WINCE] Port tiled backing store * 28272: WINCE PORT: graphics files only for WINCE DOM (Depends on area...) * 34945: Improve form validation messages. * 31718: Framework to show form validation message for invalid controls * 37012: dropEffect not set to correct default values in dragenter / dragover * 37117: Add platform-independent JPEG/PNG image encoders and toDataURL * 22261: Clicking button input does not give it focus CSS (dhyatt, dethbakin, jamesr) * 32412: css2:order of counters in out-of flow content * 32309: noAccess url schemes block access to inline stylesheets * 13097: Unsupported content:inherit value * 37443: CSSStyleSelector should pass through origin information when determined if link visited Rendering (dhyatt, jamesr) * 15994: REGRESSION: Incomplete repaint of CSS image substitution * 23556: On RTL pages, horizontal scrollbar is missing JavaScriptCore (gbarra, ggaren, olliej) * 36050: Add the possibility for a head and footer section to create_jit_stubs * 36500: Generated JIT stubs does not compile because of compiler directives Websocket (dave_levin?) * 35573: WebSocket add new event: CloseEvent Qt (tronical) * 36171: QtWebKit doesn't support NPAPI for DirectFB Gtk (xan) * 37369: [GTK] Enable building whatever already exists of WebKit2 Plugins (???) * 36721: Use Chromium's plugins/get-url-with-blank-target.html for all platforms Inspector (xenon, yurys) * 18530: Inspector's Console should distinguish console.info from console.log ___ 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
13.05.2010, в 06:15, Eric Seidel написал(а): That error looks like its trying to use python 2.5. Skipping the websocket tests on Tiger (manually at least) is bad. Would be better to do it based on detected python. Filed: https://bugs.webkit.org/show_bug.cgi?id=39058 about doing just that. I don't think that skipping tests due to a different version of python installed is acceptable. Either new python should be installed, or tests should fail, silently ignoring them is wrong. Better yet, run-webkit-tests should work with all versions of python that are shipped on supported Mac OS X versions. Unless someone is going to update python on buildbots, rolling out the patch again seems to be the only option. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ancient patches in pending-review
On Thu, May 13, 2010 at 9:12 AM, Adam Barth aba...@webkit.org wrote: One of the least fun things in the project is to pour a bunch of effort into writing a patch only to see it sit forever waiting for review. In the past, I've tried to single-handedly tackle the patches that have been up for review for more than a month. That approach is less than ideal because (1) it's too big a task for one person and (2) it causes me to review outside my area. As we've been discussing on #webkit recently, we'd like for reviewers to focus their reviews on their area of expertise to make sure each patch gets a high-quality review before landing. I've triaged the oldest patches in http://webkit.org/pending-review into groups and assigned an owner (see below). You don't need to review the patches in a group just because I've assigned it to you, but if you don't review them, please find someone to look at them. If a patch is unassigned, please consider whether you feel confident reviewing patches in that area. If you're an expert in an area by not necessarily a reviewer yet, please consider giving one or more of these patches an informal review. An informal review is especially useful if it points out areas of a patch that the contributor can improve. Ideally, an informal review would cause the contributor to improve their patch before it receives a formal review. (If you're not a reviewer, please don't alter the Review flag; just leave a comment.) Our biggest problem spots appear to be Editing and WINCE. Below, I've asked Enrica to provide informal reviews of the editing patches and Ojan to provide the formal reviews. I've also asked jamesr to provide informal reviews for the CSS and Rendering patches because he's expressed interest in learning Hyatt's secret tricks. As for WINCE, are there any reviewers interested in reviewing patches for that port? Adam Editing (Enrica, Ojan) Unfortunately, Enrica is not a reviewer yet and can't be (56 patches) but was been willing to look at a patch when I asked. It may be a good opportunity to do some reviews as if they were real before being nominated to be a reviewer (which I find very to be nice to submit with a reviewer nomination). * 24943: Command-B and Command-I do not generate keydown events in contentEditable regions. * 35632: htmlediting.cpp : isEmptyTableCell() is incomplete * 32605: Regression: Selection anchor + focus swap when arrow keys after setBaseAndExtent * 32077: textarea grows when you type * 36359: Double clicking page's last editable inline element doesn't select a word. * 32123: cursor movement and text selection does not work well if a block is followed by an inline * 35791: 2x execCommand rea...@null * 35530: Enum value FORWARD, BACKWARD, RIGHT, LEFT are causing macro conflicts. WINCE (???) - Do we have any WINCE reviewers? * 34953: Implement DEFINE_STUB_FUNCTION for WinCE * 33004: NetworkStateNotifierWin.cpp doesn't work always * 32169: Implement TextCodec for WINCE port * 37287: Rename Wince file to WinCE * 32963: buildfix for ResourceHandleWin.cpp * 37440: [WINCE] Port tiled backing store * 28272: WINCE PORT: graphics files only for WINCE DOM (Depends on area...) * 34945: Improve form validation messages. * 31718: Framework to show form validation message for invalid controls * 37012: dropEffect not set to correct default values in dragenter / dragover I think JianLi has been doing work in drag/drop. * 37117: Add platform-independent JPEG/PNG image encoders and toDataURL * 22261: Clicking button input does not give it focus CSS (dhyatt, dethbakin, jamesr) * 32412: css2:order of counters in out-of flow content * 32309: noAccess url schemes block access to inline stylesheets * 13097: Unsupported content:inherit value * 37443: CSSStyleSelector should pass through origin information when determined if link visited Rendering (dhyatt, jamesr) * 15994: REGRESSION: Incomplete repaint of CSS image substitution * 23556: On RTL pages, horizontal scrollbar is missing JavaScriptCore (gbarra, ggaren, olliej) * 36050: Add the possibility for a head and footer section to create_jit_stubs * 36500: Generated JIT stubs does not compile because of compiler directives Websocket (dave_levin?) * 35573: WebSocket add new event: CloseEvent I think ap is much more familiar with WebSockets -- though I am willing to look if needed. Qt (tronical) * 36171: QtWebKit doesn't support NPAPI for DirectFB Gtk (xan) * 37369: [GTK] Enable building whatever already exists of WebKit2 Plugins (???) * 36721: Use Chromium's plugins/get-url-with-blank-target.html for all platforms Inspector (xenon, yurys) * 18530: Inspector's Console should distinguish console.info from console.log ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ancient patches in pending-review
On Thu, May 13, 2010 at 5:41 PM, David Levin le...@google.com wrote: On Thu, May 13, 2010 at 9:12 AM, Adam Barth aba...@webkit.org wrote: One of the least fun things in the project is to pour a bunch of effort into writing a patch only to see it sit forever waiting for review. In the past, I've tried to single-handedly tackle the patches that have been up for review for more than a month. That approach is less than ideal because (1) it's too big a task for one person and (2) it causes me to review outside my area. As we've been discussing on #webkit recently, we'd like for reviewers to focus their reviews on their area of expertise to make sure each patch gets a high-quality review before landing. I've triaged the oldest patches in http://webkit.org/pending-review into groups and assigned an owner (see below). You don't need to review the patches in a group just because I've assigned it to you, but if you don't review them, please find someone to look at them. If a patch is unassigned, please consider whether you feel confident reviewing patches in that area. If you're an expert in an area by not necessarily a reviewer yet, please consider giving one or more of these patches an informal review. An informal review is especially useful if it points out areas of a patch that the contributor can improve. Ideally, an informal review would cause the contributor to improve their patch before it receives a formal review. (If you're not a reviewer, please don't alter the Review flag; just leave a comment.) Our biggest problem spots appear to be Editing and WINCE. Below, I've asked Enrica to provide informal reviews of the editing patches and Ojan to provide the formal reviews. Dave, I think you missed this bit :-) I've also asked jamesr to provide informal reviews for the CSS and Rendering patches because he's expressed interest in learning Hyatt's secret tricks. As for WINCE, are there any reviewers interested in reviewing patches for that port? Adam Editing (Enrica, Ojan) Unfortunately, Enrica is not a reviewer yet and can't be (56 patches) but was been willing to look at a patch when I asked. It may be a good opportunity to do some reviews as if they were real before being nominated to be a reviewer (which I find very to be nice to submit with a reviewer nomination). Definitely agree! * 24943: Command-B and Command-I do not generate keydown events in contentEditable regions. * 35632: htmlediting.cpp : isEmptyTableCell() is incomplete * 32605: Regression: Selection anchor + focus swap when arrow keys after setBaseAndExtent * 32077: textarea grows when you type * 36359: Double clicking page's last editable inline element doesn't select a word. * 32123: cursor movement and text selection does not work well if a block is followed by an inline * 35791: 2x execCommand rea...@null * 35530: Enum value FORWARD, BACKWARD, RIGHT, LEFT are causing macro conflicts. WINCE (???) - Do we have any WINCE reviewers? * 34953: Implement DEFINE_STUB_FUNCTION for WinCE * 33004: NetworkStateNotifierWin.cpp doesn't work always * 32169: Implement TextCodec for WINCE port * 37287: Rename Wince file to WinCE * 32963: buildfix for ResourceHandleWin.cpp * 37440: [WINCE] Port tiled backing store * 28272: WINCE PORT: graphics files only for WINCE DOM (Depends on area...) * 34945: Improve form validation messages. * 31718: Framework to show form validation message for invalid controls * 37012: dropEffect not set to correct default values in dragenter / dragover I think JianLi has been doing work in drag/drop. * 37117: Add platform-independent JPEG/PNG image encoders and toDataURL * 22261: Clicking button input does not give it focus CSS (dhyatt, dethbakin, jamesr) * 32412: css2:order of counters in out-of flow content * 32309: noAccess url schemes block access to inline stylesheets * 13097: Unsupported content:inherit value * 37443: CSSStyleSelector should pass through origin information when determined if link visited Rendering (dhyatt, jamesr) * 15994: REGRESSION: Incomplete repaint of CSS image substitution * 23556: On RTL pages, horizontal scrollbar is missing JavaScriptCore (gbarra, ggaren, olliej) * 36050: Add the possibility for a head and footer section to create_jit_stubs * 36500: Generated JIT stubs does not compile because of compiler directives Websocket (dave_levin?) * 35573: WebSocket add new event: CloseEvent I think ap is much more familiar with WebSockets -- though I am willing to look if needed. Qt (tronical) * 36171: QtWebKit doesn't support NPAPI for DirectFB Gtk (xan) * 37369: [GTK] Enable building whatever already exists of WebKit2 Plugins (???) * 36721: Use Chromium's plugins/get-url-with-blank-target.html for all platforms Inspector (xenon, yurys) * 18530: Inspector's Console should distinguish console.info from console.log
Re: [webkit-dev] Ancient patches in pending-review
13.05.2010, в 9:41, David Levin написал(а): * 35573: WebSocket add new event: CloseEvent I think ap is much more familiar with WebSockets -- though I am willing to look if needed. Anyone can review this patch - the key to reviewing is to decide whether a close event actually makes sense. A reviewer would want to read relevant parts of WebSocket spec, and to understand TCP state diagram well. I've been hesitant to review, hoping for possible conceptual issues to be resolved in IETF spec review first. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ancient patches in pending-review
On Thu, May 13, 2010 at 10:15 AM, Alexey Proskuryakov a...@webkit.org wrote: 13.05.2010, в 9:41, David Levin написал(а): * 35573: WebSocket add new event: CloseEvent I think ap is much more familiar with WebSockets -- though I am willing to look if needed. Anyone can review this patch - the key to reviewing is to decide whether a close event actually makes sense. A reviewer would want to read relevant parts of WebSocket spec, and to understand TCP state diagram well. I've been hesitant to review, hoping for possible conceptual issues to be resolved in IETF spec review first. Should we just r- and ask that it wait for conceptual issues to be resolved in IETF spec review first (unless for some reason it is needed quickly and that takes too long)? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ancient patches in pending-review
On May 13, 2010, at 12:12 PM, Adam Barth wrote: * 34953: Implement DEFINE_STUB_FUNCTION for WinCE I think this bug (and bug 36050, which it depends on) should be reviewed by Gavin Barraclough. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Ancient patches in pending-review
13.05.2010, в 10:19, David Levin написал(а): Should we just r- and ask that it wait for conceptual issues to be resolved in IETF spec review first (unless for some reason it is needed quickly and that takes too long)? I am not aware of any specific conceptual issues, just the fact that TCP connection closing is not as simple as some people think. It would take me more time to refresh my knowledge than I've been able to afford yet, but there is nothing here that should stop another reviewer. - 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-patch, check-webkit-style and git now support --squash and --git-commit
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. Ojan On Mon, Apr 26, 2010 at 9:16 PM, tonikitoo (Antonio Gomes) toniki...@gmail.com wrote: Hi, Eventually, I'd like to make --squash the default, but I want this to bake and get some usage before flipping that switch. But I don't think this makes sense as a default to me. But maybe I use git differently than everyone else… I don't do the whole branch-per-bug business. I usually have one git commit per commit I plan to push to SVN (each with a separate ChangeLog entry). I am also on the same boat, so I do not thing --squash should be the default. it would be against the current resulting action of git push, git svn dcommit and svn commit. Apart from that, great work! -- --Antonio Gomes ___ 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
[webkit-dev] jsc -d does not dump bytecode in debug builds
What gives? The documentation says, Usage: jsc [options] [files] [-- arguments] -d Dumps bytecode (debug builds only) -e Evaluate argument as script code -f Specifies a source file (deprecated) -h|--help Prints this help message -i Enables interactive mode (default if no files are specified) -s Installs signal handlers that exit on a crash (Unix platforms only)___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] jsc -d does not dump bytecode in debug builds
What's your testcase? One potential issue you could be seeing is that we don't dump the bytecode until we compile code so the code for a function won't be dumped until you call it for instance, but you should at the very least be getting an bc dump for the containing global code. --Oliver On May 13, 2010, at 4:24 PM, Auro Tripathy wrote: What gives? The documentation says, Usage: jsc [options] [files] [-- arguments] -d Dumps bytecode (debug builds only) -e Evaluate argument as script code -f Specifies a source file (deprecated) -h|--help Prints this help message -i Enables interactive mode (default if no files are specified) -s Installs signal handlers that exit on a crash (Unix platforms only) ___ 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
