Re: [webkit-dev] run-webkit-tests is moving to parallell testing by default (this weekend)
All bots (except Qt) are now transitioned to using parallel testing by default. As expected, this was a big win for all the bots. (Gtk 32-bit -- as a randomly selected example -- went form 37min cycle times to 18min cycle times.) I expect there will be a few more flaky tests we'll need to fix/disable. Let me know if you see any troubles. -eric On Fri, Dec 2, 2011 at 3:55 PM, Eric Seidel e...@webkit.org wrote: run-webkit-tests is moving to parallell testing by default (this weekend) I just moved Mac this afternoon. The SnowLeopard bot went from a 1 hr 4 min (!?!) cycle time, to 38 min (still !?!). http://build.webkit.org/builders/SnowLeopard%20Intel%20Debug%20%28Tests%29/builds/3317 http://build.webkit.org/builders/SnowLeopard%20Intel%20Debug%20%28Tests%29/builds/3318 I will start working on the other bots once I believe the Mac ones to be stable. Let me know if you have any troubles! Thanks -eric p.s. I will not be moving the Qt bots, as Ossy has asked not to have them moved yet. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] run-webkit-tests is moving to parallell testing by default (this weekend)
I should have said all platforms. run-webkit-tests will use parallel testing on all platforms (except Qt), not just on the buildbot machines. -eric On Mon, Dec 5, 2011 at 1:24 AM, Eric Seidel e...@webkit.org wrote: All bots (except Qt) are now transitioned to using parallel testing by default. As expected, this was a big win for all the bots. (Gtk 32-bit -- as a randomly selected example -- went form 37min cycle times to 18min cycle times.) I expect there will be a few more flaky tests we'll need to fix/disable. Let me know if you see any troubles. -eric On Fri, Dec 2, 2011 at 3:55 PM, Eric Seidel e...@webkit.org wrote: run-webkit-tests is moving to parallell testing by default (this weekend) I just moved Mac this afternoon. The SnowLeopard bot went from a 1 hr 4 min (!?!) cycle time, to 38 min (still !?!). http://build.webkit.org/builders/SnowLeopard%20Intel%20Debug%20%28Tests%29/builds/3317 http://build.webkit.org/builders/SnowLeopard%20Intel%20Debug%20%28Tests%29/builds/3318 I will start working on the other bots once I believe the Mac ones to be stable. Let me know if you have any troubles! Thanks -eric p.s. I will not be moving the Qt bots, as Ossy has asked not to have them moved yet. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] run-webkit-tests is moving to parallell testing by default (this weekend)
On Dec 2, 2011, at 6:55 PM, Eric Seidel wrote: The SnowLeopard bot went from a 1 hr 4 min (!?!) cycle time, to 38 min (still !?!). I suspect our Mac test bots could use a dose of RAM. Many of them only have 3GB, since when you're running tests one by one you don't really need much more. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
Hi all, Many languages compile to JavaScript today to run on the web. As alternative, we’ve been experimenting with enabling different language runtimes in WebKit to run in web pages alongside JavaScript. This could be used to support languages like Python, Java, Ruby, Lua, or - what inspired us - Dart (www.dartlang.org). Some reasons to consider additional runtimes include: - Speed. Many languages are faster than JavaScript when run natively and/or do not compile to JavaScript efficiently. - Developer choice. Another runtime provides developers with more choice without requiring them to use a toolchain. - Development experience. Languages supported directly in the browser can have a significantly better debugging and profiling experience than they can with compiled code. We have a quite early patch of this work available here: - multi-vm changes: http://codereview.chromium.org/8806015/ - dart bindings: http://codereview.chromium.org/8802010/ We’re planning to create a multi-vm branch on webkit.org to experiment with this idea. Our goal with this branch is to (a) demonstrate the above points and (b) show that we can do this without degrading JavaScript performance or the WebKit development experience. If successful, we’d like to submit these changes to WebKit trunk. We welcome your feedback. Regards, Anton Muhin Pavel Podivilov Vijay Menon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] run-webkit-tests is moving to parallell testing by default (this weekend)
Had to revert this for Mac in http://trac.webkit.org/changeset/102013 due to 20+ tests timing out and nrwt existing early: http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29?numbuilds=100 - Ryosuke On Mon, Dec 5, 2011 at 6:55 AM, Adam Roben aro...@apple.com wrote: On Dec 2, 2011, at 6:55 PM, Eric Seidel wrote: The SnowLeopard bot went from a 1 hr 4 min (!?!) cycle time, to 38 min (still !?!). I suspect our Mac test bots could use a dose of RAM. Many of them only have 3GB, since when you're running tests one by one you don't really need much more. -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] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders)
On Dec 3, 2011, at 11:57 PM, Adam Barth wrote: On Sat, Dec 3, 2011 at 11:37 PM, Dean Jackson d...@apple.com wrote: On 04/12/2011, at 6:06 PM, Adam Barth wrote: On Mon, Oct 24, 2011 at 9:51 PM, Adam Barth aba...@webkit.org wrote: Personally, I don't believe it's possible to implement this feature securely, at least not using the approach prototyped by Adobe. However, I would love to be proven wrong because this is certainly a powerful primitive with many use cases. I spent some more time looking into timing attacks on CSS Shaders. I haven't created a proof-of-concept exploit, but I believe the current design is vulnerable to timing attacks. I've written up blog post explaining the issue: http://www.schemehostport.com/2011/12/timing-attacks-on-css-shaders.html Thanks for writing this up. I'm still interested to know what the potential rate of data leakage is. Like I mentioned before, there are plenty of existing techniques that could expose information to a timing attack. For example, SVG Filters can manipulate the color channels of cross-domain images, and using CSS overflow on an iframe could potentially detect rendering slowdowns as particular colors/elements/images come into view. My understanding is that shader languages allow several orders of magnitude greater differences in rendering times than these approaches. However, as I wrote in the post, I don't have a proof-of-concept, so I cannot give you exact figures. CSS shaders increase the rate of leakage because they execute fast and can be tweaked to exaggerate the timing, but one could imagine that the GPU renderers now being used in many of WebKit's ports could be exploited in the same manner (e.g. discover a CSS trick that drops the renderer into software mode). I don't understand how those attacks would work without shaders. Can you explain in more detail? Specifically, how would an attacker extract the user's identity from a Facebook Like button? In the CSS Shader scenario, I can write a shader that runs 1000x slower on a black pixel than one a white pixel, which means I can extract the text that accompanies the Like button. Once I have the text, I'm sure you'd agree I'd have little trouble identifying the user. To be clear, it's not the difference between white and black pixels, it's the difference between pixels with transparency and those without. And I've never seen a renderer that runs 1000x slower when rendering a pixel with transparency. It may runs a few times slower, and maybe even 10x slower. But that's about it. I'm still waiting to see an actual compelling attack. The one you mention here: http://www.contextis.co.uk/resources/blog/webgl/poc/index.html has never seemed very compelling to me. At the default medium quality setting the image still takes over a minute to be generated and it's barely recognizable. You can't read the text in the image or even really tell what the image is unless you had the reference next to it. For something big, like the WebGL logo, you can see the shape. But that's because it's a lot of big solid color. And of course the demo only captures black and white, so none of the colors in an image come through. If you turn it to its highest quality mode you can make out the blocks of text, but that takes well over 15 minutes to generate. And this exploit is using WebGL, where the author has a huge amount of control over the rendering. CSS Shaders (and other types of rendering on the page) give you much less control over when rendering occurs so it makes it much more difficult to time the operations. I stand behind the statement, ... it seems difficult to mount such an attack with CSS shaders because the means to measure the time taken by a cross-domain shader are limited., which you dismissed as dubious in your missive. With WebGL you can render a single triangle, wait for it to finish, and time it. Even if you tuned a CSS attack to a given browser whose rendering behavior you understand, it would take many frame times to determine the value of a single pixel and even then I think the accuracy and repeatability would be very low. I'm happy to be proven wrong about this, but I've never seen a convincing demo of any CSS rendering exploit. This all begs the question. What is an exploit? If I can reproduce with 90% accuracy a 100x100 block of RGB pixels in 2 seconds, then I think we'd all agree that we have a pretty severe exploit. But what if I can determine the color of a single pixel on the page with 50% accuracy in 30 seconds. Is that an exploit? Some would say yes, because that can give back information (half the time) about visited links. If that's the case, then our solution is very different than in the first case. I think we need to agree on the problem we're trying to solve and then prove that the problem actually exists before trying to solve it. In fact, I think that's a general rule I live my
Re: [webkit-dev] run-webkit-tests is moving to parallell testing by default (this weekend)
I looked at one example that didn't exit early: http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/35153/steps/layout-test/logs/stdio In that case, the http tests were the long tail and took 6 minutes longer than all the other tests. We don't split the http tests up because every time we've tried it's caused too much flakiness. It's unclear if the flakiness points to a bug in the test harness (e.g. in how we setup apache) or to bugs in the tests themselves or both. If someone has time to look into this, this is probably the biggest benefit to be found in NRWT runtime when running tests in parallel. FYI, NRWT outputs a log of the runtime after each run: 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/9: 4696 tests, 1746.63 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/8: 1177 tests, 1693.47 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/3: 1408 tests, 2033.51 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/2: 941 tests, 2119.65 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/1: 1121 tests, 2041.97 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/0: 1453 tests, 2515.75 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/7: 1189 tests, 1731.12 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/6: 3556 tests, 2114.37 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/5: 948 tests, 2097.13 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/4: 1411 tests, 1716.66 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/15: 795 tests, 2027.16 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/14: 1123 tests, 1732.72 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/13: 425 tests, 2021.25 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/12: 1175 tests, 1710.09 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/11: 3462 tests, 2096.30 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/10: 1449 tests, 1722.68 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO31120.45 cumulative, 1945.03 optimal That shows you that, if we fully sharded all the tests, they would in theory take 1945 seconds to run, but worker/0 (the worker that runs the http tests) took 2515 seconds to run. Ojan On Mon, Dec 5, 2011 at 6:55 AM, Adam Roben aro...@apple.com wrote: On Dec 2, 2011, at 6:55 PM, Eric Seidel wrote: The SnowLeopard bot went from a 1 hr 4 min (!?!) cycle time, to 38 min (still !?!). I suspect our Mac test bots could use a dose of RAM. Many of them only have 3GB, since when you're running tests one by one you don't really need much more. -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] run-webkit-tests is moving to parallell testing by default (this weekend)
I believe there are some tests (copy/paste) that it would be very hard to fully shard due to how they work. dave On Mon, Dec 5, 2011 at 11:08 AM, Ojan Vafai o...@chromium.org wrote: I looked at one example that didn't exit early: http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/35153/steps/layout-test/logs/stdio In that case, the http tests were the long tail and took 6 minutes longer than all the other tests. We don't split the http tests up because every time we've tried it's caused too much flakiness. It's unclear if the flakiness points to a bug in the test harness (e.g. in how we setup apache) or to bugs in the tests themselves or both. If someone has time to look into this, this is probably the biggest benefit to be found in NRWT runtime when running tests in parallel. FYI, NRWT outputs a log of the runtime after each run: 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/9: 4696 tests, 1746.63 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/8: 1177 tests, 1693.47 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/3: 1408 tests, 2033.51 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/2: 941 tests, 2119.65 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/1: 1121 tests, 2041.97 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/0: 1453 tests, 2515.75 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/7: 1189 tests, 1731.12 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/6: 3556 tests, 2114.37 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/5: 948 tests, 2097.13 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/4: 1411 tests, 1716.66 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/15: 795 tests, 2027.16 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/14: 1123 tests, 1732.72 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/13: 425 tests, 2021.25 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/12: 1175 tests, 1710.09 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/11: 3462 tests, 2096.30 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/10: 1449 tests, 1722.68 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO31120.45 cumulative, 1945.03 optimal That shows you that, if we fully sharded all the tests, they would in theory take 1945 seconds to run, but worker/0 (the worker that runs the http tests) took 2515 seconds to run. Ojan On Mon, Dec 5, 2011 at 6:55 AM, Adam Roben aro...@apple.com wrote: On Dec 2, 2011, at 6:55 PM, Eric Seidel wrote: The SnowLeopard bot went from a 1 hr 4 min (!?!) cycle time, to 38 min (still !?!). I suspect our Mac test bots could use a dose of RAM. Many of them only have 3GB, since when you're running tests one by one you don't really need much more. -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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] run-webkit-tests is moving to parallell testing by default (this weekend)
Why is that? I don't know about other ports, but AFAIK, chromium writes to a mock clipboard and the Apple mac port writes to a local OS clipboard instance instead of the global one, specifically to avoid copy/paste tests interacting. Even without running tests in parallel, it's probably a good idea in order to avoid copy-pastes the developer is doing from affecting the test run. That said, I believe we have a general way of marking subdirectories as needing to run serially (which is what we do for http) if there are other reasons we need to. On Mon, Dec 5, 2011 at 11:12 AM, David Levin le...@google.com wrote: I believe there are some tests (copy/paste) that it would be very hard to fully shard due to how they work. dave On Mon, Dec 5, 2011 at 11:08 AM, Ojan Vafai o...@chromium.org wrote: I looked at one example that didn't exit early: http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/35153/steps/layout-test/logs/stdio In that case, the http tests were the long tail and took 6 minutes longer than all the other tests. We don't split the http tests up because every time we've tried it's caused too much flakiness. It's unclear if the flakiness points to a bug in the test harness (e.g. in how we setup apache) or to bugs in the tests themselves or both. If someone has time to look into this, this is probably the biggest benefit to be found in NRWT runtime when running tests in parallel. FYI, NRWT outputs a log of the runtime after each run: 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/9: 4696 tests, 1746.63 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/8: 1177 tests, 1693.47 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/3: 1408 tests, 2033.51 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/2: 941 tests, 2119.65 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/1: 1121 tests, 2041.97 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/0: 1453 tests, 2515.75 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/7: 1189 tests, 1731.12 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/6: 3556 tests, 2114.37 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/5: 948 tests, 2097.13 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/4: 1411 tests, 1716.66 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/15: 795 tests, 2027.16 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/14: 1123 tests, 1732.72 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/13: 425 tests, 2021.25 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/12: 1175 tests, 1710.09 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/11: 3462 tests, 2096.30 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/10: 1449 tests, 1722.68 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO31120.45 cumulative, 1945.03 optimal That shows you that, if we fully sharded all the tests, they would in theory take 1945 seconds to run, but worker/0 (the worker that runs the http tests) took 2515 seconds to run. Ojan On Mon, Dec 5, 2011 at 6:55 AM, Adam Roben aro...@apple.com wrote: On Dec 2, 2011, at 6:55 PM, Eric Seidel wrote: The SnowLeopard bot went from a 1 hr 4 min (!?!) cycle time, to 38 min (still !?!). I suspect our Mac test bots could use a dose of RAM. Many of them only have 3GB, since when you're running tests one by one you don't really need much more. -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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders)
On Mon, Dec 5, 2011 at 10:53 AM, Chris Marrin cmar...@apple.com wrote: To be clear, it's not the difference between white and black pixels, it's the difference between pixels with transparency and those without. Can you explain why the attack is limited to distinguishing between black and transparent pixels? My understanding is that these attacks are capable of distinguishing arbitrary pixel values. And I've never seen a renderer that runs 1000x slower when rendering a pixel with transparency. It may runs a few times slower, and maybe even 10x slower. But that's about it. As I wrote above, I don't have a proof-of-concept, so I can't give you exact figures on how many bits the attacker can extract per second. I'm still waiting to see an actual compelling attack. The one you mention here: http://www.contextis.co.uk/resources/blog/webgl/poc/index.html has never seemed very compelling to me. At the default medium quality setting the image still takes over a minute to be generated and it's barely recognizable. You can't read the text in the image or even really tell what the image is unless you had the reference next to it. For something big, like the WebGL logo, you can see the shape. But that's because it's a lot of big solid color. And of course the demo only captures black and white, so none of the colors in an image come through. If you turn it to its highest quality mode you can make out the blocks of text, but that takes well over 15 minutes to generate. A few points: 1) Attacks only get better, never worse. It's unlikely that this demo is the best possible attack. It just gives us a feel for what kinds of attacks are within the realm of possibility. 2) That attack isn't optimized for extracting text. For the attack I'm worried about, the attacker is interested in computing a binary predicate over each pixel, which is much easier than computing the value of the pixel. Moreover, the attacker doesn't need to extract every pixel. He or she just needs to extract enough information to distinguish glyphs in a known typeface. 3) According to the data we gathered for this paper http://www.adambarth.com/papers/2007/jackson-barth-bortz-shao-boneh.pdf, an attacker can easily spend four or five minutes executing an attack like this without losing too many users. And this exploit is using WebGL, where the author has a huge amount of control over the rendering. CSS Shaders (and other types of rendering on the page) give you much less control over when rendering occurs so it makes it much more difficult to time the operations. I stand behind the statement, ... it seems difficult to mount such an attack with CSS shaders because the means to measure the time taken by a cross-domain shader are limited., which you dismissed as dubious in your missive. With WebGL you can render a single triangle, wait for it to finish, and time it. Even if you tuned a CSS attack to a given browser whose rendering behavior you understand, it would take many frame times to determine the value of a single pixel and even then I think the accuracy and repeatability would be very low. I'm happy to be proven wrong about this, but I've never seen a convincing demo of any CSS rendering exploit. This all begs the question. What is an exploit? If I can reproduce with 90% accuracy a 100x100 block of RGB pixels in 2 seconds, then I think we'd all agree that we have a pretty severe exploit. But what if I can determine the color of a single pixel on the page with 50% accuracy in 30 seconds. Is that an exploit? Some would say yes, because that can give back information (half the time) about visited links. If that's the case, then our solution is very different than in the first case. It's a matter of risk. I'm not sure it's helpful to set a hard cut-off for what bit rate constitues an exploit. We'd never be able to figure out the exact bit rate anyway. Instead, we should view more efficient attack vectors as being higher risk. I think we need to agree on the problem we're trying to solve and then prove that the problem actually exists before trying to solve it. In fact, I think that's a general rule I live my life by :-) I think it's clear what problem we're trying to solve. We do not want to provide web attackers a mechanism for extracting sensitive data from the browser. Here are a couple examples of sensitive data: 1) The text of other web sites. 2) Whether the user has visited another site previously. I presume that's all non-controversial. The part we seem to disagree about is whether CSS Shaders causes this problem. Based on everything we know today, it seems quite likely they do. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
Looking at http://www.webkit.org/projects/goals.html, I see: Goals …. Hackability To make rapid progress possible, we try to keep the code relatively easy to understand…. Non-Goals …. WebKit is an engineering project not a science project. For new features to be adopted into WebKit, we strongly prefer for the technology or at least the use case for it to be proven. It sounds like you're proposing a change to the goals of the WebKit project -- namely, to use a branch in the WebKit project as a substrate for experiments with new technologies, including new technologies that might negatively impact hackability. Is that right? Geoff On Dec 5, 2011, at 9:26 AM, Vijay Menon wrote: Hi all, Many languages compile to JavaScript today to run on the web. As alternative, we’ve been experimenting with enabling different language runtimes in WebKit to run in web pages alongside JavaScript. This could be used to support languages like Python, Java, Ruby, Lua, or - what inspired us - Dart (www.dartlang.org). Some reasons to consider additional runtimes include: - Speed. Many languages are faster than JavaScript when run natively and/or do not compile to JavaScript efficiently. - Developer choice. Another runtime provides developers with more choice without requiring them to use a toolchain. - Development experience. Languages supported directly in the browser can have a significantly better debugging and profiling experience than they can with compiled code. We have a quite early patch of this work available here: - multi-vm changes: http://codereview.chromium.org/8806015/ - dart bindings: http://codereview.chromium.org/8802010/ We’re planning to create a multi-vm branch on webkit.org to experiment with this idea. Our goal with this branch is to (a) demonstrate the above points and (b) show that we can do this without degrading JavaScript performance or the WebKit development experience. If successful, we’d like to submit these changes to WebKit trunk. We welcome your feedback. Regards, Anton Muhin Pavel Podivilov Vijay Menon ___ 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 branch to support multiple VMs (e.g., Dart)
On 12/05/2011 09:26 AM, Vijay Menon wrote: We’re planning to create a multi-vm branch on webkit.org http://webkit.org to experiment with this idea. Our goal with this branch is to (a) demonstrate the above points and (b) show that we can do this without degrading JavaScript performance or the WebKit development experience. If successful, we’d like to submit these changes to WebKit trunk. We welcome your feedback. What is there to provide feedback on? Asking people to provide feedback on a huge patch dump seems unreasonable. Why did you choose the approach you did? Is there a planning document or white-paper? What changes did you make at a *high* level - not a set of patches? Did you run into problems or have to decide between alternative solutions? This may be interesting to the webnode portion of Oracle's JavaFX. We already have to deal with multiple VMs: The JSC JavaScript VM and the Java VM. Having a standard and more efficient way of combining them might be helpful. Likewise more direct access from Java to the WebKit core might be helpful, though the standard DOM bindings don't require JavaScript. I don't know if a WebKit port using Nashorn (Oracle's next-generation JavaScript implementation on the JVM) will be helped by a multi-VM WebKit, or make it irrelevant (from Oracle's point of view, of course). -- --Per Bothner per.both...@oracle.com p...@bothner.com http://per.bothner.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] run-webkit-tests is moving to parallell testing by default (this weekend)
We never implemented the general way of marking subdirectories as needing to run serially, but it would be easy to do if we needed to [the 'http' dirs are still special-cased in the code]. There is code now (landed a few months ago) to control how many http tests run in parallel separately from the main parallelism flag (so you can run 16 workers but only 2 http tests at a time). I implemented it but never flipped the switch because it was in the middle of Eric flipping the bots over to NRWT in the first place. We should try experimenting with this to see at some point once everything stabilizes otherwise (this is the max_locked_shards() call in manager.py; there's no command line flag). -- Dirk On Mon, Dec 5, 2011 at 11:17 AM, Ojan Vafai o...@chromium.org wrote: Why is that? I don't know about other ports, but AFAIK, chromium writes to a mock clipboard and the Apple mac port writes to a local OS clipboard instance instead of the global one, specifically to avoid copy/paste tests interacting. Even without running tests in parallel, it's probably a good idea in order to avoid copy-pastes the developer is doing from affecting the test run. That said, I believe we have a general way of marking subdirectories as needing to run serially (which is what we do for http) if there are other reasons we need to. On Mon, Dec 5, 2011 at 11:12 AM, David Levin le...@google.com wrote: I believe there are some tests (copy/paste) that it would be very hard to fully shard due to how they work. dave On Mon, Dec 5, 2011 at 11:08 AM, Ojan Vafai o...@chromium.org wrote: I looked at one example that didn't exit early: http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/35153/steps/layout-test/logs/stdio In that case, the http tests were the long tail and took 6 minutes longer than all the other tests. We don't split the http tests up because every time we've tried it's caused too much flakiness. It's unclear if the flakiness points to a bug in the test harness (e.g. in how we setup apache) or to bugs in the tests themselves or both. If someone has time to look into this, this is probably the biggest benefit to be found in NRWT runtime when running tests in parallel. FYI, NRWT outputs a log of the runtime after each run: 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/9: 4696 tests, 1746.63 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/8: 1177 tests, 1693.47 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/3: 1408 tests, 2033.51 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/2: 941 tests, 2119.65 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/1: 1121 tests, 2041.97 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/0: 1453 tests, 2515.75 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/7: 1189 tests, 1731.12 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/6: 3556 tests, 2114.37 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/5: 948 tests, 2097.13 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/4: 1411 tests, 1716.66 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/15: 795 tests, 2027.16 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/14: 1123 tests, 1732.72 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/13: 425 tests, 2021.25 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/12: 1175 tests, 1710.09 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/11: 3462 tests, 2096.30 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/10: 1449 tests, 1722.68 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO31120.45 cumulative, 1945.03 optimal That shows you that, if we fully sharded all the tests, they would in theory take 1945 seconds to run, but worker/0 (the worker that runs the http tests) took 2515 seconds to run. Ojan On Mon, Dec 5, 2011 at 6:55 AM, Adam Roben aro...@apple.com wrote: On Dec 2, 2011, at 6:55 PM, Eric Seidel wrote: The SnowLeopard bot went from a 1 hr 4 min (!?!) cycle time, to 38 min (still !?!). I suspect our Mac test bots could use a dose of RAM. Many of them only have 3GB, since when you're running tests one by one you don't really need much more. -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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
On Mon, Dec 5, 2011 at 11:48 AM, Geoffrey Garen gga...@apple.com wrote: Looking at http://www.webkit.org/projects/goals.html, I see: Goals …. Hackability To make rapid progress possible, we try to keep the code relatively easy to understand…. Non-Goals …. WebKit is an engineering project not a science project.For new features to be adopted into WebKit, we strongly prefer for the technology or at least the use case for it to be proven. It sounds like you're proposing a change to the goals of the WebKit project -- namely, to use a branch in the WebKit project as a substrate for experiments with new technologies, including new technologies that might negatively impact hackability. Is that right? Hi Geoff, I don't think we're inconsistent with the goals. I'm reading adopted into WebKit to mean checked into WebKit trunk. That's not what we're trying to do right now. We're creating a branch in order to demonstrate that it's useful and that it does not negatively impact hackability or performance. Are there guidelines as to what is appropriate for a branch? Cheers, Vijay Geoff On Dec 5, 2011, at 9:26 AM, Vijay Menon wrote: Hi all, Many languages compile to JavaScript today to run on the web. As alternative, we’ve been experimenting with enabling different language runtimes in WebKit to run in web pages alongside JavaScript. This could be used to support languages like Python, Java, Ruby, Lua, or - what inspired us - Dart (www.dartlang.org). Some reasons to consider additional runtimes include: - Speed. Many languages are faster than JavaScript when run natively and/or do not compile to JavaScript efficiently. - Developer choice. Another runtime provides developers with more choice without requiring them to use a toolchain. - Development experience. Languages supported directly in the browser can have a significantly better debugging and profiling experience than they can with compiled code. We have a quite early patch of this work available here: - multi-vm changes: http://codereview.chromium.org/8806015/ - dart bindings: http://codereview.chromium.org/8802010/ We’re planning to create a multi-vm branch on webkit.org to experiment with this idea. Our goal with this branch is to (a) demonstrate the above points and (b) show that we can do this without degrading JavaScript performance or the WebKit development experience. If successful, we’d like to submit these changes to WebKit trunk. We welcome your feedback. Regards, Anton Muhin Pavel Podivilov Vijay Menon ___ 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 branch to support multiple VMs (e.g., Dart)
Hi Per, At a high-level, the idea is pretty simple. We want to be able to run another VM along a JS one. For example, if we see a Dart script on a web page, we want the Dart VM to be able to handle it. If we see a JS script, we want the JS one to handle it. Similarly, if an event listener on a page is triggered, we want to forward to the appropriate VM to run the user listener code. The changes here are mostly about refactoring some classes (e.g., ScriptController, ScheduledAction) to add that extra dispatch. I'm not familiar enough with the JavaFX model, but this may be useful if you want to provide direct access from Java to the DOM via Java bindings. Do you have a pointer on how you're handling multiple VMs in WebKit today? Cheers, Vijay On Mon, Dec 5, 2011 at 12:50 PM, Per Bothner per.both...@oracle.com wrote: On 12/05/2011 09:26 AM, Vijay Menon wrote: We’re planning to create a multi-vm branch on webkit.org http://webkit.org to experiment with this idea. Our goal with this branch is to (a) demonstrate the above points and (b) show that we can do this without degrading JavaScript performance or the WebKit development experience. If successful, we’d like to submit these changes to WebKit trunk. We welcome your feedback. What is there to provide feedback on? Asking people to provide feedback on a huge patch dump seems unreasonable. Why did you choose the approach you did? Is there a planning document or white-paper? What changes did you make at a *high* level - not a set of patches? Did you run into problems or have to decide between alternative solutions? This may be interesting to the webnode portion of Oracle's JavaFX. We already have to deal with multiple VMs: The JSC JavaScript VM and the Java VM. Having a standard and more efficient way of combining them might be helpful. Likewise more direct access from Java to the WebKit core might be helpful, though the standard DOM bindings don't require JavaScript. I don't know if a WebKit port using Nashorn (Oracle's next-generation JavaScript implementation on the JVM) will be helped by a multi-VM WebKit, or make it irrelevant (from Oracle's point of view, of course). -- --Per Bothner per.both...@oracle.com p...@bothner.com http://per.bothner.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
What is the benefit to the project in exposing an additional (non standardized) language to the web? All the bindings that webkit currently provides to are either standardized EcmaScript or platform specific bindings used by native code developers embedding webkit. Adding an additional web facing language (that isn't standardized) doesn't seem beneficial to the project, if anything it seems harmful (cf. VBScript in IE). Anyway if we were to add an additional language the language people have been asking for for years is Python which is already extremely popular and well known so it seems that it would be a much better choice to expose, but even then it seems like a bad idea. --Oliver On Dec 5, 2011, at 1:22 PM, Vijay Menon wrote: Hi Per, At a high-level, the idea is pretty simple. We want to be able to run another VM along a JS one. For example, if we see a Dart script on a web page, we want the Dart VM to be able to handle it. If we see a JS script, we want the JS one to handle it. Similarly, if an event listener on a page is triggered, we want to forward to the appropriate VM to run the user listener code. The changes here are mostly about refactoring some classes (e.g., ScriptController, ScheduledAction) to add that extra dispatch. I'm not familiar enough with the JavaFX model, but this may be useful if you want to provide direct access from Java to the DOM via Java bindings. Do you have a pointer on how you're handling multiple VMs in WebKit today? Cheers, Vijay On Mon, Dec 5, 2011 at 12:50 PM, Per Bothner per.both...@oracle.com wrote: On 12/05/2011 09:26 AM, Vijay Menon wrote: We’re planning to create a multi-vm branch on webkit.org http://webkit.org to experiment with this idea. Our goal with this branch is to (a) demonstrate the above points and (b) show that we can do this without degrading JavaScript performance or the WebKit development experience. If successful, we’d like to submit these changes to WebKit trunk. We welcome your feedback. What is there to provide feedback on? Asking people to provide feedback on a huge patch dump seems unreasonable. Why did you choose the approach you did? Is there a planning document or white-paper? What changes did you make at a *high* level - not a set of patches? Did you run into problems or have to decide between alternative solutions? This may be interesting to the webnode portion of Oracle's JavaFX. We already have to deal with multiple VMs: The JSC JavaScript VM and the Java VM. Having a standard and more efficient way of combining them might be helpful. Likewise more direct access from Java to the WebKit core might be helpful, though the standard DOM bindings don't require JavaScript. I don't know if a WebKit port using Nashorn (Oracle's next-generation JavaScript implementation on the JVM) will be helped by a multi-VM WebKit, or make it irrelevant (from Oracle's point of view, of course). -- --Per Bothner per.both...@oracle.com p...@bothner.com http://per.bothner.com/ ___ 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] run-webkit-tests is moving to parallell testing by default (this weekend)
On Mon, Dec 5, 2011 at 1:01 PM, Dirk Pranke dpra...@chromium.org wrote: We never implemented the general way of marking subdirectories as needing to run serially, but it would be easy to do if we needed to [the 'http' dirs are still special-cased in the code]. Does it also special-case the storage tests that may collide? I'm thinking particularly of the filesystem/filewriter tests, but anything that deals with quota may also have issues. There is code now (landed a few months ago) to control how many http tests run in parallel separately from the main parallelism flag (so you can run 16 workers but only 2 http tests at a time). I implemented it but never flipped the switch because it was in the middle of Eric flipping the bots over to NRWT in the first place. We should try experimenting with this to see at some point once everything stabilizes otherwise (this is the max_locked_shards() call in manager.py; there's no command line flag). -- Dirk On Mon, Dec 5, 2011 at 11:17 AM, Ojan Vafai o...@chromium.org wrote: Why is that? I don't know about other ports, but AFAIK, chromium writes to a mock clipboard and the Apple mac port writes to a local OS clipboard instance instead of the global one, specifically to avoid copy/paste tests interacting. Even without running tests in parallel, it's probably a good idea in order to avoid copy-pastes the developer is doing from affecting the test run. That said, I believe we have a general way of marking subdirectories as needing to run serially (which is what we do for http) if there are other reasons we need to. On Mon, Dec 5, 2011 at 11:12 AM, David Levin le...@google.com wrote: I believe there are some tests (copy/paste) that it would be very hard to fully shard due to how they work. dave On Mon, Dec 5, 2011 at 11:08 AM, Ojan Vafai o...@chromium.org wrote: I looked at one example that didn't exit early: http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/35153/steps/layout-test/logs/stdio In that case, the http tests were the long tail and took 6 minutes longer than all the other tests. We don't split the http tests up because every time we've tried it's caused too much flakiness. It's unclear if the flakiness points to a bug in the test harness (e.g. in how we setup apache) or to bugs in the tests themselves or both. If someone has time to look into this, this is probably the biggest benefit to be found in NRWT runtime when running tests in parallel. FYI, NRWT outputs a log of the runtime after each run: 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/9: 4696 tests, 1746.63 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/8: 1177 tests, 1693.47 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/3: 1408 tests, 2033.51 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/2: 941 tests, 2119.65 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/1: 1121 tests, 2041.97 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/0: 1453 tests, 2515.75 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/7: 1189 tests, 1731.12 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/6: 3556 tests, 2114.37 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/5: 948 tests, 2097.13 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/4: 1411 tests, 1716.66 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/15: 795 tests, 2027.16 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/14: 1123 tests, 1732.72 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/13: 425 tests, 2021.25 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/12: 1175 tests, 1710.09 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/11: 3462 tests, 2096.30 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/10: 1449 tests, 1722.68 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO 31120.45 cumulative, 1945.03 optimal That shows you that, if we fully sharded all the tests, they would in theory take 1945 seconds to run, but worker/0 (the worker that runs the http tests) took 2515 seconds to run. Ojan On Mon, Dec 5, 2011 at 6:55 AM, Adam Roben aro...@apple.com wrote: On Dec 2, 2011, at 6:55 PM, Eric Seidel wrote: The SnowLeopard bot went from a 1 hr 4 min (!?!) cycle time, to 38 min (still !?!). I suspect our Mac test bots could use a dose of RAM. Many of them only have 3GB, since when you're running tests one by one you don't really need much more. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
Oliver, I could say the same about GLSL, but it's a huge help in my work, so I won't. The proposal is to better enable multiple VMs. Their work would lower the costs of introducing Python. It -may- help with LLVM integration to the DOM. I can hope. -Charles On Dec 5, 2011, at 1:36 PM, Oliver Hunt oli...@apple.com wrote: What is the benefit to the project in exposing an additional (non standardized) language to the web? All the bindings that webkit currently provides to are either standardized EcmaScript or platform specific bindings used by native code developers embedding webkit. Adding an additional web facing language (that isn't standardized) doesn't seem beneficial to the project, if anything it seems harmful (cf. VBScript in IE). Anyway if we were to add an additional language the language people have been asking for for years is Python which is already extremely popular and well known so it seems that it would be a much better choice to expose, but even then it seems like a bad idea. --Oliver On Dec 5, 2011, at 1:22 PM, Vijay Menon wrote: Hi Per, At a high-level, the idea is pretty simple. We want to be able to run another VM along a JS one. For example, if we see a Dart script on a web page, we want the Dart VM to be able to handle it. If we see a JS script, we want the JS one to handle it. Similarly, if an event listener on a page is triggered, we want to forward to the appropriate VM to run the user listener code. The changes here are mostly about refactoring some classes (e.g., ScriptController, ScheduledAction) to add that extra dispatch. I'm not familiar enough with the JavaFX model, but this may be useful if you want to provide direct access from Java to the DOM via Java bindings. Do you have a pointer on how you're handling multiple VMs in WebKit today? Cheers, Vijay On Mon, Dec 5, 2011 at 12:50 PM, Per Bothner per.both...@oracle.com wrote: On 12/05/2011 09:26 AM, Vijay Menon wrote: We’re planning to create a multi-vm branch on webkit.org http://webkit.org to experiment with this idea. Our goal with this branch is to (a) demonstrate the above points and (b) show that we can do this without degrading JavaScript performance or the WebKit development experience. If successful, we’d like to submit these changes to WebKit trunk. We welcome your feedback. What is there to provide feedback on? Asking people to provide feedback on a huge patch dump seems unreasonable. Why did you choose the approach you did? Is there a planning document or white-paper? What changes did you make at a *high* level - not a set of patches? Did you run into problems or have to decide between alternative solutions? This may be interesting to the webnode portion of Oracle's JavaFX. We already have to deal with multiple VMs: The JSC JavaScript VM and the Java VM. Having a standard and more efficient way of combining them might be helpful. Likewise more direct access from Java to the WebKit core might be helpful, though the standard DOM bindings don't require JavaScript. I don't know if a WebKit port using Nashorn (Oracle's next-generation JavaScript implementation on the JVM) will be helped by a multi-VM WebKit, or make it irrelevant (from Oracle's point of view, of course). -- --Per Bothner per.both...@oracle.com p...@bothner.com http://per.bothner.com/ ___ 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] run-webkit-tests is moving to parallell testing by default (this weekend)
On Mon, Dec 5, 2011 at 1:53 PM, Eric U er...@google.com wrote: On Mon, Dec 5, 2011 at 1:01 PM, Dirk Pranke dpra...@chromium.org wrote: We never implemented the general way of marking subdirectories as needing to run serially, but it would be easy to do if we needed to [the 'http' dirs are still special-cased in the code]. Does it also special-case the storage tests that may collide? I'm thinking particularly of the filesystem/filewriter tests, but anything that deals with quota may also have issues. It does not, although it would be easy to add such support. I will also note that by default all of the tests in the same directory are run sequentially in a single thread, so that may be why it hasn't been much of an issue. -- Dirk There is code now (landed a few months ago) to control how many http tests run in parallel separately from the main parallelism flag (so you can run 16 workers but only 2 http tests at a time). I implemented it but never flipped the switch because it was in the middle of Eric flipping the bots over to NRWT in the first place. We should try experimenting with this to see at some point once everything stabilizes otherwise (this is the max_locked_shards() call in manager.py; there's no command line flag). -- Dirk On Mon, Dec 5, 2011 at 11:17 AM, Ojan Vafai o...@chromium.org wrote: Why is that? I don't know about other ports, but AFAIK, chromium writes to a mock clipboard and the Apple mac port writes to a local OS clipboard instance instead of the global one, specifically to avoid copy/paste tests interacting. Even without running tests in parallel, it's probably a good idea in order to avoid copy-pastes the developer is doing from affecting the test run. That said, I believe we have a general way of marking subdirectories as needing to run serially (which is what we do for http) if there are other reasons we need to. On Mon, Dec 5, 2011 at 11:12 AM, David Levin le...@google.com wrote: I believe there are some tests (copy/paste) that it would be very hard to fully shard due to how they work. dave On Mon, Dec 5, 2011 at 11:08 AM, Ojan Vafai o...@chromium.org wrote: I looked at one example that didn't exit early: http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/35153/steps/layout-test/logs/stdio In that case, the http tests were the long tail and took 6 minutes longer than all the other tests. We don't split the http tests up because every time we've tried it's caused too much flakiness. It's unclear if the flakiness points to a bug in the test harness (e.g. in how we setup apache) or to bugs in the tests themselves or both. If someone has time to look into this, this is probably the biggest benefit to be found in NRWT runtime when running tests in parallel. FYI, NRWT outputs a log of the runtime after each run: 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/9: 4696 tests, 1746.63 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/8: 1177 tests, 1693.47 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/3: 1408 tests, 2033.51 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/2: 941 tests, 2119.65 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/1: 1121 tests, 2041.97 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/0: 1453 tests, 2515.75 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/7: 1189 tests, 1731.12 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/6: 3556 tests, 2114.37 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/5: 948 tests, 2097.13 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/4: 1411 tests, 1716.66 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/15: 795 tests, 2027.16 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/14: 1123 tests, 1732.72 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/13: 425 tests, 2021.25 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/12: 1175 tests, 1710.09 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/11: 3462 tests, 2096.30 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/10: 1449 tests, 1722.68 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO 31120.45 cumulative, 1945.03 optimal That shows you that, if we fully sharded all the tests, they would in theory take 1945 seconds to run, but worker/0 (the worker that runs the http tests) took 2515 seconds to run. Ojan On Mon, Dec 5, 2011 at 6:55 AM, Adam Roben aro...@apple.com wrote: On Dec 2, 2011, at 6:55 PM, Eric Seidel wrote: The SnowLeopard bot went from a 1 hr 4 min (!?!) cycle time, to 38 min (still !?!). I suspect our Mac test bots could use a dose of RAM. Many of them only have 3GB, since when you're
Re: [webkit-dev] run-webkit-tests is moving to parallell testing by default (this weekend)
Some http tests make use of stateful php scritps with different tests utlizing the same scripts in some cases. Does each 'worker' get a dedicated http server instance or do they share the same http server? On Mon, Dec 5, 2011 at 1:01 PM, Dirk Pranke dpra...@chromium.org wrote: We never implemented the general way of marking subdirectories as needing to run serially, but it would be easy to do if we needed to [the 'http' dirs are still special-cased in the code]. There is code now (landed a few months ago) to control how many http tests run in parallel separately from the main parallelism flag (so you can run 16 workers but only 2 http tests at a time). I implemented it but never flipped the switch because it was in the middle of Eric flipping the bots over to NRWT in the first place. We should try experimenting with this to see at some point once everything stabilizes otherwise (this is the max_locked_shards() call in manager.py; there's no command line flag). -- Dirk On Mon, Dec 5, 2011 at 11:17 AM, Ojan Vafai o...@chromium.org wrote: Why is that? I don't know about other ports, but AFAIK, chromium writes to a mock clipboard and the Apple mac port writes to a local OS clipboard instance instead of the global one, specifically to avoid copy/paste tests interacting. Even without running tests in parallel, it's probably a good idea in order to avoid copy-pastes the developer is doing from affecting the test run. That said, I believe we have a general way of marking subdirectories as needing to run serially (which is what we do for http) if there are other reasons we need to. On Mon, Dec 5, 2011 at 11:12 AM, David Levin le...@google.com wrote: I believe there are some tests (copy/paste) that it would be very hard to fully shard due to how they work. dave On Mon, Dec 5, 2011 at 11:08 AM, Ojan Vafai o...@chromium.org wrote: I looked at one example that didn't exit early: http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/35153/steps/layout-test/logs/stdio In that case, the http tests were the long tail and took 6 minutes longer than all the other tests. We don't split the http tests up because every time we've tried it's caused too much flakiness. It's unclear if the flakiness points to a bug in the test harness (e.g. in how we setup apache) or to bugs in the tests themselves or both. If someone has time to look into this, this is probably the biggest benefit to be found in NRWT runtime when running tests in parallel. FYI, NRWT outputs a log of the runtime after each run: 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/9: 4696 tests, 1746.63 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/8: 1177 tests, 1693.47 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/3: 1408 tests, 2033.51 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/2: 941 tests, 2119.65 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/1: 1121 tests, 2041.97 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/0: 1453 tests, 2515.75 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/7: 1189 tests, 1731.12 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/6: 3556 tests, 2114.37 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/5: 948 tests, 2097.13 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/4: 1411 tests, 1716.66 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/15: 795 tests, 2027.16 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/14: 1123 tests, 1732.72 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/13: 425 tests, 2021.25 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/12: 1175 tests, 1710.09 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/11: 3462 tests, 2096.30 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/10: 1449 tests, 1722.68 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO31120.45 cumulative, 1945.03 optimal That shows you that, if we fully sharded all the tests, they would in theory take 1945 seconds to run, but worker/0 (the worker that runs the http tests) took 2515 seconds to run. Ojan On Mon, Dec 5, 2011 at 6:55 AM, Adam Roben aro...@apple.com wrote: On Dec 2, 2011, at 6:55 PM, Eric Seidel wrote: The SnowLeopard bot went from a 1 hr 4 min (!?!) cycle time, to 38 min (still !?!). I suspect our Mac test bots could use a dose of RAM. Many of them only have 3GB, since when you're running tests one by one you don't really need much more. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org
Re: [webkit-dev] run-webkit-tests is moving to parallell testing by default (this weekend)
if http server instance == apache child process, then no. We don't do anything to particularly limit the number of apache children running or bind them, but given that in the normal case there is only ever one http test running at a time, you shouldn't see any issues from contention. (You would, of course, if we start running multiple http tests in parallel, so that's something to keep in mind, especially if we shard by-test instead of by-directory). -- Dirk On Mon, Dec 5, 2011 at 3:13 PM, Michael Nordman micha...@google.com wrote: Some http tests make use of stateful php scritps with different tests utlizing the same scripts in some cases. Does each 'worker' get a dedicated http server instance or do they share the same http server? On Mon, Dec 5, 2011 at 1:01 PM, Dirk Pranke dpra...@chromium.org wrote: We never implemented the general way of marking subdirectories as needing to run serially, but it would be easy to do if we needed to [the 'http' dirs are still special-cased in the code]. There is code now (landed a few months ago) to control how many http tests run in parallel separately from the main parallelism flag (so you can run 16 workers but only 2 http tests at a time). I implemented it but never flipped the switch because it was in the middle of Eric flipping the bots over to NRWT in the first place. We should try experimenting with this to see at some point once everything stabilizes otherwise (this is the max_locked_shards() call in manager.py; there's no command line flag). -- Dirk On Mon, Dec 5, 2011 at 11:17 AM, Ojan Vafai o...@chromium.org wrote: Why is that? I don't know about other ports, but AFAIK, chromium writes to a mock clipboard and the Apple mac port writes to a local OS clipboard instance instead of the global one, specifically to avoid copy/paste tests interacting. Even without running tests in parallel, it's probably a good idea in order to avoid copy-pastes the developer is doing from affecting the test run. That said, I believe we have a general way of marking subdirectories as needing to run serially (which is what we do for http) if there are other reasons we need to. On Mon, Dec 5, 2011 at 11:12 AM, David Levin le...@google.com wrote: I believe there are some tests (copy/paste) that it would be very hard to fully shard due to how they work. dave On Mon, Dec 5, 2011 at 11:08 AM, Ojan Vafai o...@chromium.org wrote: I looked at one example that didn't exit early: http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/35153/steps/layout-test/logs/stdio In that case, the http tests were the long tail and took 6 minutes longer than all the other tests. We don't split the http tests up because every time we've tried it's caused too much flakiness. It's unclear if the flakiness points to a bug in the test harness (e.g. in how we setup apache) or to bugs in the tests themselves or both. If someone has time to look into this, this is probably the biggest benefit to be found in NRWT runtime when running tests in parallel. FYI, NRWT outputs a log of the runtime after each run: 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/9: 4696 tests, 1746.63 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/8: 1177 tests, 1693.47 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/3: 1408 tests, 2033.51 secs 2011-12-03 03:09:30,018 58036 printing.py:462 INFO worker/2: 941 tests, 2119.65 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/1: 1121 tests, 2041.97 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/0: 1453 tests, 2515.75 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/7: 1189 tests, 1731.12 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/6: 3556 tests, 2114.37 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/5: 948 tests, 2097.13 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/4: 1411 tests, 1716.66 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/15: 795 tests, 2027.16 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/14: 1123 tests, 1732.72 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/13: 425 tests, 2021.25 secs 2011-12-03 03:09:30,019 58036 printing.py:462 INFO worker/12: 1175 tests, 1710.09 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/11: 3462 tests, 2096.30 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO worker/10: 1449 tests, 1722.68 secs 2011-12-03 03:09:30,020 58036 printing.py:462 INFO 31120.45 cumulative, 1945.03 optimal That shows you that, if we fully sharded all the tests, they would in theory take 1945 seconds to run, but worker/0
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
On Dec 5, 2011, at 1:22 PM, Vijay Menon wrote: At a high-level, the idea is pretty simple. We want to be able to run another VM along a JS one. For example, if we see a Dart script on a web page, we want the Dart VM to be able to handle it. If we see a JS script, At one time I was very enthusiastic about providing support for multiple languages in all sorts of contexts. I would rush out and learn every obscure language and wonder why the rest of the world wasn't as enthusiastic in learning (and using it) as I was. As I've matured (or perhaps become more curmudgeonly), I now find greater satisfaction in systems that just work. Minimizing the number of variables that come into play when rendering pages just seems like a smart approach. Consider also the massive shift currently underway in the mobile space. Flash has been abandoned in favor of standardized tools available on multiple platforms with no need for the user to locate, install, and maintain external VMs or other infrastructure. While this project has a lot of academic merit, I don't know that it makes a lot of sense to include it in WebKit proper. Finally, you might consider the approach taken by Appcelerator, who basically built custom URL handlers that allow web pages to be coded in a combination of Python, Ruby, JavaScript, etc. Getting these changes merged into the mainstream WebKit is probably a quicker route to meet your needs. Best regards, -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
On 12/5/11 3:18 PM, Brent Fulgham wrote: As I've matured (or perhaps become more curmudgeonly), I now find greater satisfaction in systems that just work. Minimizing the number of variables that come into play when rendering pages just seems like a smart approach. Consider also the massive shift currently underway in the mobile space. Flash has been abandoned in favor of standardized tools available on multiple platforms with no need for the user to locate, install, and maintain external VMs or other infrastructure. Adobe's Air has reasonably tight integration with WebKit. Not to the extent being proposed here, but it is an active example. I think this issue is better examined from the scope of webkit than from the realm of universal web technologies. Unless I'm misunderstanding something, the proposal here is that webkit support script type in a sufficient manner. What individual webkit vendors do with that is up to them. -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
Could you post a complete patch of your multi-vm changes to a WebKit bug? I final chromium's diff viewer very difficult to use. Regardless of whether this is good for the web or not, some of your multi-vm changes may be nice to have in WebCore. -eric On Mon, Dec 5, 2011 at 11:48 AM, Geoffrey Garen gga...@apple.com wrote: Looking at http://www.webkit.org/projects/goals.html, I see: Goals …. Hackability To make rapid progress possible, we try to keep the code relatively easy to understand…. Non-Goals …. WebKit is an engineering project not a science project.For new features to be adopted into WebKit, we strongly prefer for the technology or at least the use case for it to be proven. It sounds like you're proposing a change to the goals of the WebKit project -- namely, to use a branch in the WebKit project as a substrate for experiments with new technologies, including new technologies that might negatively impact hackability. Is that right? Geoff On Dec 5, 2011, at 9:26 AM, Vijay Menon wrote: Hi all, Many languages compile to JavaScript today to run on the web. As alternative, we’ve been experimenting with enabling different language runtimes in WebKit to run in web pages alongside JavaScript. This could be used to support languages like Python, Java, Ruby, Lua, or - what inspired us - Dart (www.dartlang.org). Some reasons to consider additional runtimes include: - Speed. Many languages are faster than JavaScript when run natively and/or do not compile to JavaScript efficiently. - Developer choice. Another runtime provides developers with more choice without requiring them to use a toolchain. - Development experience. Languages supported directly in the browser can have a significantly better debugging and profiling experience than they can with compiled code. We have a quite early patch of this work available here: - multi-vm changes: http://codereview.chromium.org/8806015/ - dart bindings: http://codereview.chromium.org/8802010/ We’re planning to create a multi-vm branch on webkit.org to experiment with this idea. Our goal with this branch is to (a) demonstrate the above points and (b) show that we can do this without degrading JavaScript performance or the WebKit development experience. If successful, we’d like to submit these changes to WebKit trunk. We welcome your feedback. Regards, Anton Muhin Pavel Podivilov Vijay Menon ___ 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] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders)
On Dec 5, 2011, at 11:32 AM, Adam Barth wrote: On Mon, Dec 5, 2011 at 10:53 AM, Chris Marrin cmar...@apple.com wrote: To be clear, it's not the difference between white and black pixels, it's the difference between pixels with transparency and those without. Can you explain why the attack is limited to distinguishing between black and transparent pixels? My understanding is that these attacks are capable of distinguishing arbitrary pixel values. This is my misunderstanding. I was referring to the attacks using WebGL, which measure the difference between rendering alpha and non-alpha pixels. But I think there is another, more dangerous attack vector specific to CSS shaders. Shaders have the source image (the image of that part of the page) available. So it is an easy thing to make a certain color pixel take a lot longer to render (your 1000x slower case). So you can easily and quickly detect, for instance, the color of a link. So I take back my statement that CSS Shaders are less dangerous than WebGL. They are more!!! As I've said many times (with many more expletives), I hate the Internet. I think the solution is clear. We should create a whole new internet where we only let in people we trust. :-) - ~Chris cmar...@apple.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Commit queue rejecting all patches
We are getting this: Attachment XXX did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/10728791 New failing tests: svg/custom/linking-uri-01-b.svg Can someone fix it? -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Commit queue rejecting all patches
On Mon, Dec 5, 2011 at 3:43 PM, Darin Adler da...@apple.com wrote: We are getting this: Attachment XXX did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/10728791 New failing tests: svg/custom/linking-uri-01-b.svg Can someone fix it? It looks like it's very flaky. I'll look into it. Thanks. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Commit queue rejecting all patches
On Mon, Dec 5, 2011 at 3:52 PM, Adam Barth aba...@webkit.org wrote: On Mon, Dec 5, 2011 at 3:43 PM, Darin Adler da...@apple.com wrote: We are getting this: Attachment XXX did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/10728791 New failing tests: svg/custom/linking-uri-01-b.svg Can someone fix it? It looks like it's very flaky. I'll look into it. Thanks. I've filed https://bugs.webkit.org/show_bug.cgi?id=73872 about this issue and marked the flakiness as expected so that it won't impact the chromium-ews. I'll post further updates to the bug. Thanks, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Timing attacks on CSS Shaders (was Re: Security problems with CSS shaders)
On 12/5/11 3:34 PM, Chris Marrin wrote: On Dec 5, 2011, at 11:32 AM, Adam Barth wrote: On Mon, Dec 5, 2011 at 10:53 AM, Chris Marrincmar...@apple.com wrote: To be clear, it's not the difference between white and black pixels, it's the difference between pixels with transparency and those without. Can you explain why the attack is limited to distinguishing between black and transparent pixels? My understanding is that these attacks are capable of distinguishing arbitrary pixel values. This is my misunderstanding. I was referring to the attacks using WebGL, which measure the difference between rendering alpha and non-alpha pixels. But I think there is another, more dangerous attack vector specific to CSS shaders. Shaders have the source image (the image of that part of the page) available. So it is an easy thing to make a certain color pixel take a lot longer to render (your 1000x slower case). So you can easily and quickly detect, for instance, the color of a link. Can this proposal be moved forward on CORS + HTMLMediaElement, HTMLImageElement and HTMLCanvasElement? The proposal would really benefit users and authors on those media types, even if it falls short of applying to general HTML elements and CSS urls in the first draft. I realize that it falls short of the lofty goals of the presentation, but it would make a good impact and set the stage for further work. It seems entirely do-able to disable a:visited on elements that have custom filters applied, but, like the timing issues, there needs to be some empirical data on risks before moving forward on them. So I take back my statement that CSS Shaders are less dangerous than WebGL. They are more!!! As I've said many times (with many more expletives), I hate the Internet. I think the solution is clear. We should create a whole new internet where we only let in people we trust. :-) - ~Chris cmar...@apple.com I still love my iPhone. ;-) -Charles ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
Hi Vijay. I don't think we're inconsistent with the goals. I'm reading adopted into WebKit to mean checked into WebKit trunk. That's not what we're trying to do right now. We're creating a branch in order to demonstrate that it's useful and that it does not negatively impact hackability or performance. Are there guidelines as to what is appropriate for a branch? It hadn't occurred to me to view the goals of the WebKit project as applying only to trunk, and not to branches. I'd be interested in hearing from other WebKit engineers: Do you think that the goals of the WebKit project apply to trunk alone, or to branches as well? Vijay, if we assume that WebKit's goals do not apply to this branch, what goals would you like to apply? Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
On Mon, Dec 5, 2011 at 5:22 PM, Geoffrey Garen gga...@apple.com wrote: We're creating a branch in order to demonstrate that it's useful and that it does not negatively impact hackability or performance. It hadn't occurred to me to view the goals of the WebKit project as applying only to trunk, and not to branches. I'd be interested in hearing from other WebKit engineers: Do you think that the goals of the WebKit project apply to trunk alone, or to branches as well? It sounds from the quote above like Vijay is not trying to change what the goals are, only to obtain an environment where it's possible to demonstrate, by practical experience, that some set of changes is indeed consistent with WebKit's goals. In principle a branch seems appropriate for that to me unless there is widespread agreement that the entire idea of these patches is so contrary to what we want that no one should have ever even thought about doing them in the first place. I'm not sure things are that clear-cut, so seeing a more fleshed-out system might be useful. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
I agree with Peter here. It appears to me that having a WebKit branch to experiment a new feature will help us making an informed decision as to whether we want to accept patches or not for the feature better than looking at two giant patches posted on chromium.org. Preferably, Vijay also file a bug and possibly post a patch on bugs.webkit.org. - Ryosuke On Mon, Dec 5, 2011 at 5:39 PM, Peter Kasting pkast...@chromium.org wrote: On Mon, Dec 5, 2011 at 5:22 PM, Geoffrey Garen gga...@apple.com wrote: We're creating a branch in order to demonstrate that it's useful and that it does not negatively impact hackability or performance. It hadn't occurred to me to view the goals of the WebKit project as applying only to trunk, and not to branches. I'd be interested in hearing from other WebKit engineers: Do you think that the goals of the WebKit project apply to trunk alone, or to branches as well? It sounds from the quote above like Vijay is not trying to change what the goals are, only to obtain an environment where it's possible to demonstrate, by practical experience, that some set of changes is indeed consistent with WebKit's goals. In principle a branch seems appropriate for that to me unless there is widespread agreement that the entire idea of these patches is so contrary to what we want that no one should have ever even thought about doing them in the first place. I'm not sure things are that clear-cut, so seeing a more fleshed-out system might be useful. 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] WebKit branch to support multiple VMs (e.g., Dart)
Previous branches have been used to bring up interestingly complicated features, or features that had the potential to cause dramatic stability issues during their early work (such as the old svg-experimental branch). This project appear to be largely a make work project as it's already possible to have bindings for multiple languages (as the C++, GLib, ObjC, V8 and JSC bindings demonstrate). It seems an academic exercise to see if we can create a general architecture to make more bindings, as is exporting support for proprietary extensions like vbscript, python or dart to the web. As the 90s demonstrated such features are bad for developers, and bad for the open web. This may not be apparent to people who have not spent years working in the environment but random additions frequently cause significant pain down the road, even in the cases where the overall result was a good thing -- such as canvas - for the subsequent standardisation caused us quite a bit of compatibility problems, even though it was a very compact and contained api. --Oliver On Dec 5, 2011, at 6:09 PM, Ryosuke Niwa wrote: I agree with Peter here. It appears to me that having a WebKit branch to experiment a new feature will help us making an informed decision as to whether we want to accept patches or not for the feature better than looking at two giant patches posted on chromium.org. Preferably, Vijay also file a bug and possibly post a patch on bugs.webkit.org. - Ryosuke On Mon, Dec 5, 2011 at 5:39 PM, Peter Kasting pkast...@chromium.org wrote: On Mon, Dec 5, 2011 at 5:22 PM, Geoffrey Garen gga...@apple.com wrote: We're creating a branch in order to demonstrate that it's useful and that it does not negatively impact hackability or performance. It hadn't occurred to me to view the goals of the WebKit project as applying only to trunk, and not to branches. I'd be interested in hearing from other WebKit engineers: Do you think that the goals of the WebKit project apply to trunk alone, or to branches as well? It sounds from the quote above like Vijay is not trying to change what the goals are, only to obtain an environment where it's possible to demonstrate, by practical experience, that some set of changes is indeed consistent with WebKit's goals. In principle a branch seems appropriate for that to me unless there is widespread agreement that the entire idea of these patches is so contrary to what we want that no one should have ever even thought about doing them in the first place. I'm not sure things are that clear-cut, so seeing a more fleshed-out system might be useful. 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
On Mon, Dec 5, 2011 at 7:01 PM, Oliver Hunt oli...@apple.com wrote: As the 90s demonstrated such features are bad for developers, and bad for the open web. This may not be apparent to people who have not spent years working in the environment but random additions frequently cause significant pain down the road, even in the cases where the overall result was a good thing -- such as canvas - for the subsequent standardisation caused us quite a bit of compatibility problems, even though it was a very compact and contained api. I can't agree more. On the other hand, I feel bad to push back people from doing new experiments especially on branches. Do you have an alternative suggestion for Vijay and others to do (potentially) controversial experiments? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
On Mon, Dec 5, 2011 at 5:22 PM, Geoffrey Garen gga...@apple.com wrote: We're creating a branch in order to demonstrate that it's useful and that it does not negatively impact hackability or performance. It hadn't occurred to me to view the goals of the WebKit project as applying only to trunk, and not to branches. I'd be interested in hearing from other WebKit engineers: Do you think that the goals of the WebKit project apply to trunk alone, or to branches as well? It sounds from the quote above like Vijay is not trying to change what the goals are, only to obtain an environment where it's possible to demonstrate, by practical experience, that some set of changes is indeed consistent with WebKit's goals. In principle a branch seems appropriate for that to me unless there is widespread agreement that the entire idea of these patches is so contrary to what we want that no one should have ever even thought about doing them in the first place. I'm not sure things are that clear-cut, so seeing a more fleshed-out system might be useful. I want to experiment with an unproven technology is plainly inconsistent with we strongly prefer for the technology… to be proven. It's gratifying that the Dart experiment may result, in the long term, in a patch or set of patches consistent with WebKit's goals. Or it may not. That is true of any long-term experiment. But that doesn't make long-term experiments consistent with WebKit's goals. It's hard to discuss the Dart experiment without acknowledging the implicit request for a change in project goals, or an exemption from them. If I take our existing goals as my premises, it seems undeniable to me that a reviewer should r- a patch to add web-facing bindings for an unstandardized language, which is supported by no other browser engines and used by no popular websites -- whether on or off by default. But perhaps the Dart experiment is so good that it deserves an exemption we wouldn't give to other experiments; or perhaps WebKit's goals are wrong, and should change. I'd like to find out. We can't have that conversation until somebody acknowledges that the Dart experiment is asking for a change, explains what the change is, and explains why the change is good for the long-term health of the WebKit project. For reference, we have historically said no to the same experiment with Python. Is your proposition that we should have said yes, or that Dart is special? Geoff___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] New to Webkit development: Eclipse under Linux?
Hi Dave, QtCreator is another good option, you may try. It works well on my Ubuntu system. -Antaryami On Sun, Dec 4, 2011 at 4:59 AM, Philip Rogers p...@google.com wrote: Dave, I've used EclipseCDT for Chromium and it works fairly well (syntax highlighting, debugging, etc). The instructions on this page have everything you'll need and should work for WebKit as well: http://code.google.com/p/chromium/wiki/LinuxEclipseDev Eclipse's GUI frontend to gdb does have some rough edges but overall works pretty well. Philip On Sat, Dec 3, 2011 at 5:25 PM, Dave Tharp dth...@codeaurora.org wrote: Has anyone successfully configured Eclipse CDT for Webkit development and debugging (gdb) under Linux? I'd be interested in either : a) Some pointers for setting up Eclipse - or - b) Suggestions for a better (best?) alternative for development/debugging under Linux (other than vi / command line gdb. And buy a Mac isn't helpful either :-) ) I've looked at ddd, and nemiver. They are perhaps viable, but I'd like more of a capable IDE, and Eclipse seems a good way to go on the surface. I'd like some advice from the community before I invest the time into configuring from scratch if possible. Thanks in advance, -Dave Tharp __**_ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/**mailman/listinfo.cgi/webkit-**devhttp://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 branch to support multiple VMs (e.g., Dart)
Yes, we will upload this to a WebKit bug shortly. Cheers, Vijay On Mon, Dec 5, 2011 at 3:35 PM, Eric Seidel e...@webkit.org wrote: Could you post a complete patch of your multi-vm changes to a WebKit bug? I final chromium's diff viewer very difficult to use. Regardless of whether this is good for the web or not, some of your multi-vm changes may be nice to have in WebCore. -eric On Mon, Dec 5, 2011 at 11:48 AM, Geoffrey Garen gga...@apple.com wrote: Looking at http://www.webkit.org/projects/goals.html, I see: Goals …. Hackability To make rapid progress possible, we try to keep the code relatively easy to understand…. Non-Goals …. WebKit is an engineering project not a science project.For new features to be adopted into WebKit, we strongly prefer for the technology or at least the use case for it to be proven. It sounds like you're proposing a change to the goals of the WebKit project -- namely, to use a branch in the WebKit project as a substrate for experiments with new technologies, including new technologies that might negatively impact hackability. Is that right? Geoff On Dec 5, 2011, at 9:26 AM, Vijay Menon wrote: Hi all, Many languages compile to JavaScript today to run on the web. As alternative, we’ve been experimenting with enabling different language runtimes in WebKit to run in web pages alongside JavaScript. This could be used to support languages like Python, Java, Ruby, Lua, or - what inspired us - Dart (www.dartlang.org). Some reasons to consider additional runtimes include: - Speed. Many languages are faster than JavaScript when run natively and/or do not compile to JavaScript efficiently. - Developer choice. Another runtime provides developers with more choice without requiring them to use a toolchain. - Development experience. Languages supported directly in the browser can have a significantly better debugging and profiling experience than they can with compiled code. We have a quite early patch of this work available here: - multi-vm changes: http://codereview.chromium.org/8806015/ - dart bindings: http://codereview.chromium.org/8802010/ We’re planning to create a multi-vm branch on webkit.org to experiment with this idea. Our goal with this branch is to (a) demonstrate the above points and (b) show that we can do this without degrading JavaScript performance or the WebKit development experience. If successful, we’d like to submit these changes to WebKit trunk. We welcome your feedback. Regards, Anton Muhin Pavel Podivilov Vijay Menon ___ 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 branch to support multiple VMs (e.g., Dart)
On Mon, Dec 5, 2011 at 7:28 PM, Oliver Hunt oli...@apple.com wrote: The issue here isn't can we make multiple vms live in webkit it's can we expose multiple languages to the web, to the former i say obviously as we already do, to the latter I say that we don't want to. People are already using multiple languages on the web. E.g., https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS. Native runtime support is a natural next step. WebKit does support multiple VMs, but it does not support them concurrently at runtime. That is essentially what we want to enable. Cheers, Vijay ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit branch to support multiple VMs (e.g., Dart)
It's not quite true that multiple languages are exposed to the web. One Turing-complete language is exposed, and any Turing-complete language can be compiled to any other Turing-complete language. The fact that some developers compile their favorite languages to JS doesn't mean that we should support all of them natively. Supporting multiple VMs is a big infrastructural challenge, both in terms of initial bring-up and in terms of long-term maintenance. You'll need to make sure that the different GCs can coordinate, which will induce overhead. Otherwise you will either not have an story of object reclamation, or you'll have memory leaks. It's just sufficient if one program, in one language, can reference a window containing code written in a different language. Doing this right is hard. See either Wegiel and Krintz OOPSLA'10 or Pizlo, Hosking, and Vitek LCTES'07 for studies of prior attempts to have interoperability between independent GCs. Both seem to indicate 5% throughput regression. Are you claiming that a 5% throughput regression is worth it to support a new language, that is not an open standard, and currently has nonexistent adoption? -Filip On 2011-12-05, at 10:43 PM, Vijay Menon v...@google.com wrote: On Mon, Dec 5, 2011 at 7:28 PM, Oliver Hunt oli...@apple.com wrote: The issue here isn't can we make multiple vms live in webkit it's can we expose multiple languages to the web, to the former i say obviously as we already do, to the latter I say that we don't want to. People are already using multiple languages on the web. E.g., https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS. Native runtime support is a natural next step. WebKit does support multiple VMs, but it does not support them concurrently at runtime. That is essentially what we want to enable. Cheers, Vijay ___ 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 branch to support multiple VMs (e.g., Dart)
It's not quite true that multiple languages are exposed to the web. One Turing-complete language is exposed, and any Turing-complete language can be compiled to any other Turing-complete language. The fact that some developers compile their favorite languages to JS doesn't mean that we should support all of them natively. Such a complicated way to say no :) Actually I agree with those who think this would be too much burden on the project. Both in terms of maintainability and performance. However, setting up your own branch somewhere you have access should not be a trouble. We do that all the time when we need custom features. If your project will be successful, we could add A+ to the supported languages ;) Regards, Zoltan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
