Re: [webkit-dev] Proposal: Make Ninja the default build-system for build-webkit --chromium
Will the buildbots use ninja or the native build tools? My only concern is that we're catching problems with e.g. MSVS only after we roll the WebKit deps in chromium and one of the MSVS bots starts failing. Otherwise, I'm all for switching to ninja. best -jochen On Sat, Dec 8, 2012 at 9:29 AM, Eric Seidel e...@webkit.org wrote: If you don't work on the Chromium port, feel free to ignore. If you work on the Chromium port of WebKit and do not use Ninja as you build system (GYP_GENERATORS='ninja' or update-webkit --chromium --ninja) I want to hear from you! As far as I can tell, the vast majority of Chromium contributors use Ninja as their build system of choice. Particularly for Chromium-Android contributors this seems to be true. With that knowledge, I have posted a patch to make update-webkit ---chromium/--chromium-android generate Ninja build files instead of platform-native build files (XCode, Visual Studio, Make, etc.) by default. This of course only affects the chromium port. https://bugs.webkit.org/show_bug.cgi?id=104434 Thanks! p.s. If you don't already know: update-webkit --chromium --ninja build-webkit --chromium is all you need to use Ninja today. You don't even need to have installed/built your own copy of ninja (Chromium has done that for you). p.p.s. Ninja is awesome. Awesomely quiet. Awesomely fast. http://martine.github.com/ninja/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Make Ninja the default build-system for build-webkit --chromium
The buildbots will use ninja by default, but could opt-out (with --no-ninja) if that were desired behavior. I've so far received one other concern: Robert Hogan raised that chromium's depot_tools does not contain a 32-bit build of ninja, and the error message is somewhat confusing in that case. I've filed https://bugs.webkit.org/show_bug.cgi?id=104523 for tracking that issue. On Mon, Dec 10, 2012 at 1:30 AM, Jochen Eisinger joc...@chromium.org wrote: Will the buildbots use ninja or the native build tools? My only concern is that we're catching problems with e.g. MSVS only after we roll the WebKit deps in chromium and one of the MSVS bots starts failing. Otherwise, I'm all for switching to ninja. best -jochen On Sat, Dec 8, 2012 at 9:29 AM, Eric Seidel e...@webkit.org wrote: If you don't work on the Chromium port, feel free to ignore. If you work on the Chromium port of WebKit and do not use Ninja as you build system (GYP_GENERATORS='ninja' or update-webkit --chromium --ninja) I want to hear from you! As far as I can tell, the vast majority of Chromium contributors use Ninja as their build system of choice. Particularly for Chromium-Android contributors this seems to be true. With that knowledge, I have posted a patch to make update-webkit ---chromium/--chromium-android generate Ninja build files instead of platform-native build files (XCode, Visual Studio, Make, etc.) by default. This of course only affects the chromium port. https://bugs.webkit.org/show_bug.cgi?id=104434 Thanks! p.s. If you don't already know: update-webkit --chromium --ninja build-webkit --chromium is all you need to use Ninja today. You don't even need to have installed/built your own copy of ninja (Chromium has done that for you). p.p.s. Ninja is awesome. Awesomely quiet. Awesomely fast. http://martine.github.com/ninja/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Make Ninja the default build-system for build-webkit --chromium
Clarifying the error messages seems like a win in either case. From Android's perspective, I'm of course in favor of switching to ninja. One minor nit, but I'll reply with that on the bug. Thanks for doing this! Peter On Mon, Dec 10, 2012 at 9:39 AM, Eric Seidel e...@webkit.org wrote: The buildbots will use ninja by default, but could opt-out (with --no-ninja) if that were desired behavior. I've so far received one other concern: Robert Hogan raised that chromium's depot_tools does not contain a 32-bit build of ninja, and the error message is somewhat confusing in that case. I've filed https://bugs.webkit.org/show_bug.cgi?id=104523 for tracking that issue. On Mon, Dec 10, 2012 at 1:30 AM, Jochen Eisinger joc...@chromium.org wrote: Will the buildbots use ninja or the native build tools? My only concern is that we're catching problems with e.g. MSVS only after we roll the WebKit deps in chromium and one of the MSVS bots starts failing. Otherwise, I'm all for switching to ninja. best -jochen On Sat, Dec 8, 2012 at 9:29 AM, Eric Seidel e...@webkit.org wrote: If you don't work on the Chromium port, feel free to ignore. If you work on the Chromium port of WebKit and do not use Ninja as you build system (GYP_GENERATORS='ninja' or update-webkit --chromium --ninja) I want to hear from you! As far as I can tell, the vast majority of Chromium contributors use Ninja as their build system of choice. Particularly for Chromium-Android contributors this seems to be true. With that knowledge, I have posted a patch to make update-webkit ---chromium/--chromium-android generate Ninja build files instead of platform-native build files (XCode, Visual Studio, Make, etc.) by default. This of course only affects the chromium port. https://bugs.webkit.org/show_bug.cgi?id=104434 Thanks! p.s. If you don't already know: update-webkit --chromium --ninja build-webkit --chromium is all you need to use Ninja today. You don't even need to have installed/built your own copy of ninja (Chromium has done that for you). p.p.s. Ninja is awesome. Awesomely quiet. Awesomely fast. http://martine.github.com/ninja/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding CSS3 background-position offsets.
On Tue, Dec 4, 2012 at 8:36 AM, Alexis Menard ale...@webkit.org wrote: On Mon, Dec 3, 2012 at 5:59 PM, Dirk Schulze dschu...@adobe.com wrote: On Dec 3, 2012, at 12:07 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Dec 3, 2012 at 11:11 AM, Dirk Schulze dschu...@adobe.com wrote: Why does this feature have a flag at all? background-position with up to 4 arguments is specified with CSS3 background and borders. There are three major implementations with this feature. So we are just catching up. If the future works as expected (and we should have tests that verify it), then we should remove the flag completely. Sounds like good practice to me. Why _not_ start that feature with a flag then remove the flag when fully ready/tested??? Depends on the future. But for such a small patch, a new flag seems to be overdone. I looked into the patch, and adding the flag caused more code, then the actual feature (even if the computed style is missing). I believe we should remove the flag ASAP. Flags are for bigger new features of features that likely will change IMO. Both seems not to be the case for background-position. The computed style is there see http://trac.webkit.org/changeset/136378. I split the whole thing into two pieces to ease the review process. So as today the feature is enable on all ports with bots (Chromium, Mac, GTK, Qt, EFL) and tests are doing fine. We had to rebase a test in ietestcenter that was buggy because it was landed with a wrong expected png, luckily the Chromium bots were here to tell me. I also turned on the feature for -webkit-mask which now align with the spec [1]. Anybody objects to remove the flag? [1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#mask-property Greetings, Dirk Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Software Engineer @ Intel Open Source Technology Center -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Adding CSS3 background-position offsets.
Le 10 déc. 2012 09:24, Alexis Menard ale...@webkit.org a écrit : On Tue, Dec 4, 2012 at 8:36 AM, Alexis Menard ale...@webkit.org wrote: On Mon, Dec 3, 2012 at 5:59 PM, Dirk Schulze dschu...@adobe.com wrote: On Dec 3, 2012, at 12:07 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Dec 3, 2012 at 11:11 AM, Dirk Schulze dschu...@adobe.com wrote: Why does this feature have a flag at all? background-position with up to 4 arguments is specified with CSS3 background and borders. There are three major implementations with this feature. So we are just catching up. If the future works as expected (and we should have tests that verify it), then we should remove the flag completely. Sounds like good practice to me. Why _not_ start that feature with a flag then remove the flag when fully ready/tested??? Depends on the future. But for such a small patch, a new flag seems to be overdone. I looked into the patch, and adding the flag caused more code, then the actual feature (even if the computed style is missing). I believe we should remove the flag ASAP. Flags are for bigger new features of features that likely will change IMO. Both seems not to be the case for background-position. The computed style is there see http://trac.webkit.org/changeset/136378. I split the whole thing into two pieces to ease the review process. So as today the feature is enable on all ports with bots (Chromium, Mac, GTK, Qt, EFL) and tests are doing fine. We had to rebase a test in ietestcenter that was buggy because it was landed with a wrong expected png, luckily the Chromium bots were here to tell me. I also turned on the feature for -webkit-mask which now align with the spec [1]. Anybody objects to remove the flag? The patch is there https://bugs.webkit.org/show_bug.cgi?id=104539 up for review. The mac ews is sick at the moment but my work environment is Mac so it should be fine. [1] http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html#mask-property Greetings, Dirk Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev -- Software Engineer @ Intel Open Source Technology Center -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Make Ninja the default build-system for build-webkit --chromium
On Mon, Dec 10, 2012 at 1:30 AM, Jochen Eisinger joc...@chromium.org wrote: Will the buildbots use ninja or the native build tools? My only concern is that we're catching problems with e.g. MSVS only after we roll the WebKit deps in chromium and one of the MSVS bots starts failing. The idea is that gyp tries to write ninja files that behave as similar as possible to xcodebuild / devenv (or msbuild). In practice, this seems to work pretty well and it's rare that a ninja build works while xcodebuild doesn't -- well enough that all the chromium trybots use only ninja. Nico Otherwise, I'm all for switching to ninja. best -jochen On Sat, Dec 8, 2012 at 9:29 AM, Eric Seidel e...@webkit.org wrote: If you don't work on the Chromium port, feel free to ignore. If you work on the Chromium port of WebKit and do not use Ninja as you build system (GYP_GENERATORS='ninja' or update-webkit --chromium --ninja) I want to hear from you! As far as I can tell, the vast majority of Chromium contributors use Ninja as their build system of choice. Particularly for Chromium-Android contributors this seems to be true. With that knowledge, I have posted a patch to make update-webkit ---chromium/--chromium-android generate Ninja build files instead of platform-native build files (XCode, Visual Studio, Make, etc.) by default. This of course only affects the chromium port. https://bugs.webkit.org/show_bug.cgi?id=104434 Thanks! p.s. If you don't already know: update-webkit --chromium --ninja build-webkit --chromium is all you need to use Ninja today. You don't even need to have installed/built your own copy of ninja (Chromium has done that for you). p.p.s. Ninja is awesome. Awesomely quiet. Awesomely fast. http://martine.github.com/ninja/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Make Ninja the default build-system for build-webkit --chromium
On Mon, Dec 10, 2012 at 1:30 AM, Jochen Eisinger joc...@chromium.org wrote: Will the buildbots use ninja or the native build tools? My only concern is that we're catching problems with e.g. MSVS only after we roll the WebKit deps in chromium and one of the MSVS bots starts failing. Eric is only suggesting changing update-webkit and build-webkit, which means that only the webkit.org bots would be affected. As long as the chromium.org canaries are still using chromium checkouts (and the native build systems), we'll still have coverage. Of course, your point is still valid for other scenarios where we don't have coverage of what we use on the official builds, but as Nico pointed out in a separate thread, so far this hasn't been a frequent problem. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Prefix naming scheme for DOM-exposed functions
On Fri, Dec 7, 2012 at 1:36 PM, Maciej Stachowiak m...@apple.com wrote: Would this involve creating a bindingsFoo() for every method foo() that is exposed to bindings? For example, would we have to add XMLHttpRequest::bindingsSend(), even though there's no real need for a special internal XMLHttpRequest::send()? Would getters and setters that map to JavaScript properties (but which do not reflect markup attributes) also need a bindings... version? For example, would we need HTMLMediaElement::bindingsMuted() and HTMLMediaElement::bindingsSetMuted() to wrap the regular muted() and setMuted()? I see no internal clients for HTMLMediaElement::muted()/setMuted() so there would be no need for internal versions for it. I suspect that in many cases we would at most need an internal accessor (which could then properly follow our naming conventions HTMLMediaElement::isMuted()). If the answer to these questions is yes, then I think this is too much complexity tax on all exposed methods and properties to make up for the benefit. It's likely only a minority of methods where it's highly desirable to have a specialized version for internal use. Probably the only way to find out is try doing it and seeing how the patch ends up looking like. As a side note, I don't see how this would address the concrete example given, that of firstElementChild likely becoming more efficient than firstChild. If we add bindingsFirstChild() and bindingsFirstElementChild(), how does this help WebCore developers know that they should use the internal firstElementChild() instead of the internal firstChild()? I expect both have to exist, because there really are cases where you need to traverse the whole DOM, not just elements, and even if we were to convert, firstElementChild() is not a drop-in replacement. This would create more freedom for our internal document tree to diverge from how it looks like through the DOM api. For example internal firstChild() that returns Node* may no longer make sense at all if we eliminate Text nodes. antti It also seems to me that internal methods that do the exact same thing as a bindings...() version but lack an ExceptionCode parameter, we'll still want to avoid excess code duplication, in some cases of tricky algorithms. I would not want a second copy of ContainerNode::insertBefore() and its helper methods that replaces exception checking with preflight checks that return false without setting an exeption code (I don't think you can just skip the checks entirely or you'd make a method that is extremely dangerous to call if you have not met very complex preconditions). I do agree with the goal of having efficient internal interfaces that are not constrained by what is exposed to the Web, but a blanket introduction of methods just for bindings does not seem like a good way to get there. Possible alternatives: - Use something in the IDL to call a bindings... variant only in cases where we know there is a materially better internal method. - Use the style checker to ban calling select exposed methods from hand-written WebCore code, and give the corresponding internal methods different names. These approaches could achieve the goals described for critical DOM methods without having to infect things like XHR::send() or HTMLMediaElement::setMuted(). Regards, Maciej On Dec 7, 2012, at 9:27 AM, Darin Adler da...@apple.com wrote: Hi folks. Many of the APIs designed for use in the DOM are not efficient for use inside WebKit, or have designs that are better for JavaScript than for C++. Antti Koivisto and I have been discussing how to best communicate this to WebKit contributors so they don’t end up using inefficient idioms just because they are familiar with them from use in JavaScript code on websites. So far, our best idea for this is to add a prefix to function names that indicate they are functions for use by the bindings machinery. Thus, a function like appendChild would get a new name: void bindingsAppendChild(Node*, ExceptionCode); The internal function that’s used to add a child node would be designed for the best clarity, ease of use, and efficiency within WebKit implementation code, even when that does not match up with the DOM standard. And could be refactored over time as WebKit design changes without affecting the bindings. - It’s not clear what the best prefix is. I don’t like the prefix “dom”, since it’s a lowercased acronym and an overloaded not all that precise term. The prefix “bindings” is sort of silly because these functions are not themselves “bindings”, rather they are the non-language-specific functions designed to be bound to each language. However, I do like the idea of a brief non-acronym word. So, still looking for a great prefix. - When appropriate, these exposed functions can be short inline functions that turn around and call internal functions. - These functions aren’t needed at
