Re: [webkit-dev] run-bindings-tests
On Sep 8, 2011, at 7:21 PM, Alexey Proskuryakov wrote: 08.09.2011, в 12:25, Darin Adler написал(а): I find the bindings tests quite helpful. Because the perl script is so hard to read, it’s the changes in bindings script test results that I look at when reviewing changes to the bindings scripts. The fact that the results are checked in helps me review patches. OK, then they are valuable indeed. However, I still feel that there is a disconnect between the desired effect (provide a diff in a patch for review) and the implementation (tests that can pass or fail). This also puts the burden of maintaining the results on people who needn't care about them - for example, Oliver's patch clearly didn't need someone look over generated code changes. I think the argument is that it _did_ need someone - the reviewer didn't have any nice way to see the difference in output that would have been visible had i included updates to the expected output. My problem with the test is that it isn't run as part of run-webkit-tests (which is what we say you must run), the test output is fairly awful, and the test script doesn't support --help, or --reset (it turns out it does have an equivalent to --reset, but why use a different argument in one tool from what we use in the main one?) --Oliver I'm not sure what the better solution would be though. Perhaps a bot could provide a diff of DerivedSources for any patch that touches code generators, but I'm not volunteering to implement one :-) - WBR, Alexey Proskuryakov ___ 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-bindings-tests
2011/9/8 Oliver Hunt oli...@apple.com: On Sep 8, 2011, at 7:21 PM, Alexey Proskuryakov wrote: 08.09.2011, в 12:25, Darin Adler написал(а): I find the bindings tests quite helpful. Because the perl script is so hard to read, it’s the changes in bindings script test results that I look at when reviewing changes to the bindings scripts. The fact that the results are checked in helps me review patches. OK, then they are valuable indeed. However, I still feel that there is a disconnect between the desired effect (provide a diff in a patch for review) and the implementation (tests that can pass or fail). This also puts the burden of maintaining the results on people who needn't care about them - for example, Oliver's patch clearly didn't need someone look over generated code changes. I think the argument is that it _did_ need someone - the reviewer didn't have any nice way to see the difference in output that would have been visible had i included updates to the expected output. My problem with the test is that it isn't run as part of run-webkit-tests (which is what we say you must run), the test output is fairly awful, and the test script doesn't support --help, or --reset (it turns out it does have an equivalent to --reset, but why use a different argument in one tool from what we use in the main one?) Those all sound like very fixable issues. I'm sorry I picked the wrong flag name. I was trying to copy the name of the flag used by run-webkit-tests, but I must have screwed it up somehow. If you'd be willing to file bugs about the improvements you'd like to see in the test, I'll be happy to make them. I'm not quite up to the task of making run-webkit-tests run all the various tests, but hopefully someone will volunteer to make that happen. Adam I'm not sure what the better solution would be though. Perhaps a bot could provide a diff of DerivedSources for any patch that touches code generators, but I'm not volunteering to implement one :-) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing style scoped
On Fri, Sep 9, 2011 at 12:28 AM, Roland Steiner rolandstei...@chromium.orgwrote: ad 3.) Implementation of scoped selector matching works as follows: .) scoped style sheet rules are contained in a separate map scoping element address - RuleSet .) add a field to ParentStackFrame that identifies the closest ParentStackFrame that refers to a scoping element .) during matching only check RuleSets that are thusly identified in ParentStackFrame (plus a slow path that climbs the tree in case ParentStackFrame isn't applicable), plus global rules .) add a 'scope' parameter to the matching functions that identifies the scoping element that limits the matching. Note that with this implementation rules in scoped RuleSets that are not in scope aren't even looked at. Also note that the actual selector data is NOT modified for this. I.e., a selector in a scoped style sheet is not different from a global selector. This has several benefits: Sounds good to me. We don't currently rely on ParentStackFrames to get any semantics right, it is just for performance optimization. You will need to take care that it is now functional (rebuild as needed) in all cases. Inroducing root should be ok for fastCheckSelector path too, testing against root element shouldn't be slower than testing against null. I was anyway thinking of moving the parent stack to SelectorChecker. With this it will actually be needed for querySelectorAll. antti .) no updating necessary if a style element is inserted or removed from the document, nor when the 'scoped' attribute is set/unset. .) paves the way for a trivial implementation of a similarly scoped querySelector[All]. .) for components: several component instantiations can re-use the same template style sheet without the need to clone its rules. Please let me know your thoughts, - Roland ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] How does a *Prefix.h work on other platforms?
On Thu, Sep 8, 2011 at 12:54 PM, Mark Rowe mr...@apple.com wrote: On 2011-09-07, at 21:22, Xianzhu Wang (王显著) wrote: Hi, There are some *Prefix.h files that I guess are injected as header files into *.cpp files when compiling with xcode. I guess on other platforms they are just no use and the source files should include all necessary header files, right? Is this right? However, a file in question is Tools/TestWebKitAPI/TestWebKitAPIPrefix.h which injects '#include gtest/gtest.h' the unit test source files which don't have the includes. AFAIK TestWebKitAPI works on Mac and Windows, but I haven't found anything in TestWebKitAPI.vcproj for injecting TestWebKitAPIPrefix.h into the source files. How does this work on Windows? Tools/TestWebKitAPI/Configurations/TestWebKitAPICommon.vsprops: ForcedIncludeFiles=TestWebKitAPIPrefix.h Thanks Mark. I had only grep-ed the files under win/. - Mark ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] run-bindings-tests
On Thu, Sep 8, 2011 at 12:44 PM, Darin Adler da...@apple.com wrote: On Sep 8, 2011, at 12:29 PM, Eric Seidel wrote: I'm happy to write a run-all-tests script which runs all known tests that platform can handle. :) I think run-webkit-tests should be this. We can come up with a new name for the “just run the tests in the LayoutTests directory” tool. I would like that too. But there are going to be stages to get here. If we did this today, bots would break if nothing else. I'll see about adding a run-all-tests script soon and we can work to have it replace run-webkit-tests. (new-new-run-webkit-tests anyone?) ;) A bigger problem is the different way that all the various tests indicate tests have run, succeeded, or failed. If you try to run all of these it’s not trivial to figure out what happened. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] run-bindings-tests
On Sep 9, 2011, at 10:52 AM, Eric Seidel wrote: On Thu, Sep 8, 2011 at 12:44 PM, Darin Adler da...@apple.com wrote: On Sep 8, 2011, at 12:29 PM, Eric Seidel wrote: I'm happy to write a run-all-tests script which runs all known tests that platform can handle. :) I think run-webkit-tests should be this. We can come up with a new name for the “just run the tests in the LayoutTests directory” tool. I would like that too. But there are going to be stages to get here. If we did this today, bots would break if nothing else. I'll see about adding a run-all-tests script soon and we can work to have it replace run-webkit-tests. (new-new-run-webkit-tests anyone?) An alternate path to success would be: 1) Decide what to call the script that just runs tests from LayoutTests 2) Rename run-webkit-tests to that new name and add a new script called run-webkit-tests that just calls the renamed script 3) Slowly make run-webkit-tests call out to other test-running scripts -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] run-bindings-tests
On Sep 9, 2011, at 10:59 AM, Adam Roben wrote: On Sep 9, 2011, at 10:52 AM, Eric Seidel wrote: On Thu, Sep 8, 2011 at 12:44 PM, Darin Adler da...@apple.com wrote: On Sep 8, 2011, at 12:29 PM, Eric Seidel wrote: I'm happy to write a run-all-tests script which runs all known tests that platform can handle. :) I think run-webkit-tests should be this. We can come up with a new name for the “just run the tests in the LayoutTests directory” tool. I would like that too. But there are going to be stages to get here. If we did this today, bots would break if nothing else. I'll see about adding a run-all-tests script soon and we can work to have it replace run-webkit-tests. (new-new-run-webkit-tests anyone?) An alternate path to success would be: 1) Decide what to call the script that just runs tests from LayoutTests 2) Rename run-webkit-tests to that new name and add a new script called run-webkit-tests that just calls the renamed script 3) Slowly make run-webkit-tests call out to other test-running scripts I of course forgot: 2.5) Change the bots to call the renamed script -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] run-bindings-tests
run-layout-tests? On Sep 9, 2011 8:04 AM, Adam Roben aro...@apple.com wrote: On Sep 9, 2011, at 10:59 AM, Adam Roben wrote: On Sep 9, 2011, at 10:52 AM, Eric Seidel wrote: On Thu, Sep 8, 2011 at 12:44 PM, Darin Adler da...@apple.com wrote: On Sep 8, 2011, at 12:29 PM, Eric Seidel wrote: I'm happy to write a run-all-tests script which runs all known tests that platform can handle. :) I think run-webkit-tests should be this. We can come up with a new name for the “just run the tests in the LayoutTests directory” tool. I would like that too. But there are going to be stages to get here. If we did this today, bots would break if nothing else. I'll see about adding a run-all-tests script soon and we can work to have it replace run-webkit-tests. (new-new-run-webkit-tests anyone?) An alternate path to success would be: 1) Decide what to call the script that just runs tests from LayoutTests 2) Rename run-webkit-tests to that new name and add a new script called run-webkit-tests that just calls the renamed script 3) Slowly make run-webkit-tests call out to other test-running scripts I of course forgot: 2.5) Change the bots to call the renamed script -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-bindings-tests
On Fri, Sep 9, 2011 at 12:07 PM, Adam Barth aba...@webkit.org wrote: run-layout-tests? too obvious. as an ode to Paul, I propose run-the-mother-effing-layout-tests http://mothereffinghsl.com/ ;) On Sep 9, 2011 8:04 AM, Adam Roben aro...@apple.com wrote: On Sep 9, 2011, at 10:59 AM, Adam Roben wrote: On Sep 9, 2011, at 10:52 AM, Eric Seidel wrote: On Thu, Sep 8, 2011 at 12:44 PM, Darin Adler da...@apple.com wrote: On Sep 8, 2011, at 12:29 PM, Eric Seidel wrote: I'm happy to write a run-all-tests script which runs all known tests that platform can handle. :) I think run-webkit-tests should be this. We can come up with a new name for the “just run the tests in the LayoutTests directory” tool. I would like that too. But there are going to be stages to get here. If we did this today, bots would break if nothing else. I'll see about adding a run-all-tests script soon and we can work to have it replace run-webkit-tests. (new-new-run-webkit-tests anyone?) An alternate path to success would be: 1) Decide what to call the script that just runs tests from LayoutTests 2) Rename run-webkit-tests to that new name and add a new script called run-webkit-tests that just calls the renamed script 3) Slowly make run-webkit-tests call out to other test-running scripts I of course forgot: 2.5) Change the bots to call the renamed script -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 -- *Sencha* Jarred Nicholls, Senior Software Architect @jarrednicholls http://twitter.com/jarrednicholls ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] run-bindings-tests
On Sep 9, 2011, at 9:07 AM, Adam Barth wrote: run-layout-tests? Sorry in advance for bikeshed'ing this: That would be a good name if we thought LayoutTests was the right name for our main regression test suite. Since I think it’s not, I would love to figure out that new name and have the script reflect the new name even before we rename the directory. I also think it’s good to have a WebKit-specific or specific-enough word in script names when possible so you can have the scripts in your path even when not working on WebKit. That’s why run-webkit-tests has the word WebKit in it, and run-safari does not. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] run-bindings-tests
I also think it’s good to have a WebKit-specific or specific-enough word in script names when possible so you can have the scripts in your path even when not working on WebKit. That’s why run-webkit-tests has the word WebKit in it, and run-safari does not. I'd suggest one script -- run-webkit-tests -- with flags for including or excluding specific testing (layout tests, unit tests, bindings tests, etc.). That way, there's only one name to remember, you get a sensible default, and you can always use --help to figure special subtest settings as necessary. (I think a little bike shedding is OK here, since this is a tool we all use every day.) Geoff___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] run-bindings-tests
On Fri, Sep 9, 2011 at 7:59 AM, Adam Roben aro...@apple.com wrote: An alternate path to success would be: 1) Decide what to call the script that just runs tests from LayoutTests 2) Rename run-webkit-tests to that new name and add a new script called run-webkit-tests that just calls the renamed script 3) Slowly make run-webkit-tests call out to other test-running scripts Just as a remainder, step 2 will require modifying various scripts and, most importantly, bot configurations that refer to run-webkit-tests or new-run-webkit-tests. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] run-bindings-tests
On Fri, Sep 9, 2011 at 10:17 AM, Geoffrey Garen gga...@apple.com wrote: I also think it’s good to have a WebKit-specific or specific-enough word in script names when possible so you can have the scripts in your path even when not working on WebKit. That’s why run-webkit-tests has the word WebKit in it, and run-safari does not. I'd suggest one script -- run-webkit-tests -- with flags for including or excluding specific testing (layout tests, unit tests, bindings tests, etc.). That way, there's only one name to remember, you get a sensible default, and you can always use --help to figure special subtest settings as necessary. (I think a little bike shedding is OK here, since this is a tool we all use every day.) Note that the mechanisms for running each sub-suite may vary significantly, so practically the top-level script may just end up shelling out to subscripts anyway. That said, I agree that the top-level script should have the characteristics you describe. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Do you maintain PLATFORM(BREWMP) or OS(QNX)?
Hi folks. It looks like the two build variants that rely on threads not existing in WebKit and JavaScriptCore are PLATFORM(BREWMP) and OS(QNX). In the short term, I think this means that making threads always exist in WebKit and JavaScriptCore will break those two build variants. Do you maintain either build variant? If so, are you interested in fixing the build? If nobody maintains these build variants, I'm inclined to remove them in a follow-up patch. Thanks, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing style scoped
On Thu, Sep 8, 2011 at 6:51 PM, Ryosuke Niwa rn...@webkit.org wrote: Very excited for this feature! On Thu, Sep 8, 2011 at 2:28 PM, Roland Steiner rolandstei...@chromium.org wrote: As per discussion on http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032056.html, our implementation would diverge from the current HTML5 spec Why do diverge? It seems like we should at least prefix the attribute with webkit in the case spec changes in the future. See above linked discussion for details. In the end we felt limiting the selector matching to the scope is more natural, and - with the proposed exception providued by :root and :scope - is more flexible. However, naming the attribute 'webkit-scoped' may certainly be a good idea. Can we take these steps behind a flag given the attribute doesn't work properly without some steps? I would prefer not to use a flag for the following reasons: .) I already have the basic functionality working, with the exception of scoped @keyframes and @font-face, so landing should not take a long time (I am currently in the process of breaking the patch up, and adding more tests). .) There are quite a few changes that add parameters to functions, etc., which makes adding a flag ugly. Cheers, - Roland ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing style scoped
On Fri, Sep 9, 2011 at 12:51 PM, Roland Steiner rolandstei...@google.comwrote: On Thu, Sep 8, 2011 at 6:51 PM, Ryosuke Niwa rn...@webkit.org wrote: Very excited for this feature! On Thu, Sep 8, 2011 at 2:28 PM, Roland Steiner rolandstei...@chromium.org wrote: As per discussion on http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-June/032056.html, our implementation would diverge from the current HTML5 spec Why do diverge? It seems like we should at least prefix the attribute with webkit in the case spec changes in the future. See above linked discussion for details. In the end we felt limiting the selector matching to the scope is more natural, and - with the proposed exception providued by :root and :scope - is more flexible. However, naming the attribute 'webkit-scoped' may certainly be a good idea. Yes, please use webkitscoped (no - since this is content attribute?). I would prefer not to use a flag for the following reasons: .) I already have the basic functionality working, with the exception of scoped @keyframes and @font-face, so landing should not take a long time (I am currently in the process of breaking the patch up, and adding more tests). .) There are quite a few changes that add parameters to functions, etc., which makes adding a flag ugly. Okay. SGTM. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Do you compile with ENABLE_SVG diabled?
I am interested in removing the ENABLE_SVG define, and all associated sub-defines ENABLE_SVG_ANIMATION ENABLE_SVG_AS_IMAGE ENABLE_SVG_FONTS ENABLE_SVG_FOREIGN_OBJECT ENABLE_SVG_USE SVG is part of HTML5, and all major ports compile and ship with SVG enabled (and have for years). Please let me know if you are compiling with ENABLE_SVG disabled. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do you compile with ENABLE_SVG diabled?
I build debug with !ENABLE_SVG on my laptop to mitigate some of the pain of building on the road. Not saying I couldn't live without it, it'd just be a life of ~doubled compile times. :-) -Kling On Fri, Sep 9, 2011 at 11:42 PM, Eric Seidel e...@webkit.org wrote: I am interested in removing the ENABLE_SVG define, and all associated sub-defines ENABLE_SVG_ANIMATION ENABLE_SVG_AS_IMAGE ENABLE_SVG_FONTS ENABLE_SVG_FOREIGN_OBJECT ENABLE_SVG_USE SVG is part of HTML5, and all major ports compile and ship with SVG enabled (and have for years). Please let me know if you are compiling with ENABLE_SVG disabled. -eric ___ 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] Do you compile with ENABLE_SVG diabled?
I know webOS ships (or doesn't these days?) sans-SVG. On Fri, Sep 9, 2011 at 2:42 PM, Eric Seidel e...@webkit.org wrote: I am interested in removing the ENABLE_SVG define, and all associated sub-defines ENABLE_SVG_ANIMATION ENABLE_SVG_AS_IMAGE ENABLE_SVG_FONTS ENABLE_SVG_FOREIGN_OBJECT ENABLE_SVG_USE SVG is part of HTML5, and all major ports compile and ship with SVG enabled (and have for years). Please let me know if you are compiling with ENABLE_SVG disabled. -eric ___ 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] Do you compile with ENABLE_SVG diabled?
We could at least remove the subsets of SVG. Some developers build without SVG for compile time reasons. Dirk Am 09.09.2011 um 23:45 schrieb Levi Weintraub: I know webOS ships (or doesn't these days?) sans-SVG. On Fri, Sep 9, 2011 at 2:42 PM, Eric Seidel e...@webkit.org wrote: I am interested in removing the ENABLE_SVG define, and all associated sub-defines ENABLE_SVG_ANIMATION ENABLE_SVG_AS_IMAGE ENABLE_SVG_FONTS ENABLE_SVG_FOREIGN_OBJECT ENABLE_SVG_USE SVG is part of HTML5, and all major ports compile and ship with SVG enabled (and have for years). Please let me know if you are compiling with ENABLE_SVG disabled. -eric ___ 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] Do you compile with ENABLE_SVG diabled?
That seems like a very reasonable solution to me. On Fri, Sep 9, 2011 at 2:51 PM, Dirk Schulze k...@webkit.org wrote: We could at least remove the subsets of SVG. Some developers build without SVG for compile time reasons. Dirk Am 09.09.2011 um 23:45 schrieb Levi Weintraub: I know webOS ships (or doesn't these days?) sans-SVG. On Fri, Sep 9, 2011 at 2:42 PM, Eric Seidel e...@webkit.org wrote: I am interested in removing the ENABLE_SVG define, and all associated sub-defines ENABLE_SVG_ANIMATION ENABLE_SVG_AS_IMAGE ENABLE_SVG_FONTS ENABLE_SVG_FOREIGN_OBJECT ENABLE_SVG_USE SVG is part of HTML5, and all major ports compile and ship with SVG enabled (and have for years). Please let me know if you are compiling with ENABLE_SVG disabled. -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Color profiles in expected.png files
It turns out that some of the layout test expected.png files have color profiles (Generic RGB), and some do not https://bugs.webkit.org/show_bug.cgi?id=67880. On my Lion machine, at least, this affects the appearance of the standard green color, and causes pixel tests to fail. It appears that these files have come from various sources, including Tony Chang's embedding of checksums in image files, and new expected results created on Lion. I think we should be consistent about color profiles, and in a way that doesn't break pixel tests. Does anyone want to vote one way or the other? Once we decide, we should also have some kind of protection against adding new pixel results which don't follow convention. Maybe webkit-patch can be taught about this. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Do you compile with ENABLE_SVG diabled?
Hi Eric, chromium's mac tryservers (which are similar to webkit's EWS) all build with svg disabled. Nico On Fri, Sep 9, 2011 at 2:42 PM, Eric Seidel e...@webkit.org wrote: I am interested in removing the ENABLE_SVG define, and all associated sub-defines ENABLE_SVG_ANIMATION ENABLE_SVG_AS_IMAGE ENABLE_SVG_FONTS ENABLE_SVG_FOREIGN_OBJECT ENABLE_SVG_USE SVG is part of HTML5, and all major ports compile and ship with SVG enabled (and have for years). Please let me know if you are compiling with ENABLE_SVG disabled. -eric ___ 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
