Re: [webkit-dev] WebKit-EFL finally merged, pay attention to CMake build system!
On Sat, May 15, 2010 at 2:06 PM, Adam Barth aba...@webkit.org wrote:
On Sat, May 15, 2010 at 9:14 AM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
I'm glad to say that WebKit-EFL was finally merged as the last but
definitely bit, the build system, was merged into tree today. Many,
many thanks to all the friends that helped with this painful task,
including Eric Seidel, Adam Treat, Kenneth Christiansen, Gustavo
Noronha and possible lots of others.
Now a warning: when renaming files, pay attention to CMakeLists*.txt
files in tree! The generic files are stored in CMakeLists.txt, while
the port specific goes into CMakeLists${PORT}.txt I just noticed that
another patch went in that moved WebGLArray and now we're in tree but
cannot compile as the old file we refer is not there anymore.
Next step is trying to setup a build server so we can participate into
the regular EWS checks. But until there, remember to do that manually
as you already do for GNUmakefile.am, *.gyp, etc..
If you'd like to run an EWS bot, you can add your port to this file:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/config/ports.py
and then make a new subclass of AbstractEarlyWarningSystem in this file:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/tool/commands/earlywarningsystem.py
Yeah, first we need to find out a machine that can keep the required
pace, setup EFL in it and etc.
Thanks and best regards,
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit-EFL finally merged, pay attention to CMake build system!
On Sat, May 15, 2010 at 9:14 AM, Gustavo Sverzut Barbieri
barbi...@profusion.mobi wrote:
Hi all,
I'm glad to say that WebKit-EFL was finally merged as the last but
definitely bit, the build system, was merged into tree today. Many,
many thanks to all the friends that helped with this painful task,
including Eric Seidel, Adam Treat, Kenneth Christiansen, Gustavo
Noronha and possible lots of others.
Now a warning: when renaming files, pay attention to CMakeLists*.txt
files in tree! The generic files are stored in CMakeLists.txt, while
the port specific goes into CMakeLists${PORT}.txt I just noticed that
another patch went in that moved WebGLArray and now we're in tree but
cannot compile as the old file we refer is not there anymore.
FYI, the WebKitTools/Scripts/do-webcore-rename script, which was used
to do the WebGL renaming, performs a search-in-replace in all files in
WebCore, WebKit and JavaScriptCore. I think the reason for the skew
was that your files weren't in the tree yet, but any subsequent
renamings done with this script should adjust them automatically.
-Ken
Next step is trying to setup a build server so we can participate into
the regular EWS checks. But until there, remember to do that manually
as you already do for GNUmakefile.am, *.gyp, etc..
BR,
PS: We'd welcome more ports to come to CMake! Adam Treat is trying to
move one port to it, and we should help with GTK when time allows.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
___
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] HitTest'ing scrollbars
Hi, just sharing a few words from hyatt on IRC: May 17 00:07:00 dhyattyeah your analysis is right May 17 00:08:34 dhyattthat RenderLayer comment is about dragging the map in google maps May 17 00:08:41 dhyattso that would be the thing to test to make sure it doesn't break May 17 00:09:47 dhyatttonikitoo: but yeah it's weird May 17 00:10:25 tonikitoo dhyatt, I am think is more inconsistent is the fact that we fired mousedown, but do not fire click or mouseup May 17 00:10:41 tonikitoo while firefox, for example, fires the first and the later May 17 00:10:41 dhyattyeah, i don't really have strong opinions other than don't break the web please :) On Sun, May 9, 2010 at 11:07 PM, Darin Adler da...@apple.com wrote: I think your analysis is right, but I’m not sure. Hyatt did a lot of the scrollbar work for Windows that was later imitated on the other platforms. Maybe he can comment on this? -- --Antonio Gomes ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] converting by constructor
Hi, I have a basic question. What has been WebKit's stance on the use of the explicit keyword (for higher-level objects in particular)? Do we prefer the looser API's that conversion by constructor affords, or do we more often discourage relying on conversion by constructor? For comparison, the Google C++ style guide says the explicit keyword should almost always be used. Note that I'm not suggesting that this be added to our style guide. Thanks, --Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] webkit-patch, check-webkit-style and git now support --squash and --git-commit
On Sun, May 16, 2010 at 10:38 AM, Chris Jerdonek cjerdo...@webkit.orgwrote: On Sun, May 16, 2010 at 8:26 AM, Ojan Vafai o...@chromium.org wrote: On Sat, May 15, 2010 at 2:17 PM, Chris Jerdonek cjerdo...@webkit.org wrote: In particular, --git-commit=HEAD.. should be just the uncommitted changes (staged and unstaged). This one I'm a bit iffy on. Should this include the commit at head? I think it should. Currently, when using check-webkit-style for example, I need to pass --git-commit=HEAD^.. to include the commit at head. In other words, it operates on ranges like the above exclusively with respect to the endpoint. This is similar to how git-diff behaves and is described here: http://www.kernel.org/pub/software/scm/git/docs/git-rev-parse.html Were you thinking about changing this behavior? Someone also pointed out off thread that including working copy changes doesn't match any existing git commands. I think we should try to stay as close to git semantics as possible. So, I'm revising the proposal. It weirds me out the --git-commit=head~3..head~2 and --git-commit=head~2 do the same thing, but it turns out most git commands work that way. I propose: default: operate on working copy changes. Errors if there are no working copy changes or if there are committed changes. Gives a nice error message saying what to do. --git-commit=* operate on all changes in your branch as a single commit, including working copy changes --git-commit=head~2 operate on head~2 --git-commit=head~2.. operate on head~2, head~1 and head --git-commit=head~4..head~2 operate on head~3 and head~2 as a single commit Sound good? Ojan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] converting by constructor
My understanding is that we almost always use the explicit keyword unless we explicitly want implicit construction. For example, AtomicString has a non-explicit constructor that takes a String on purpose (or at least controlled by NO_IMPLICIT_ATOMICSTRING). Adam On Mon, May 17, 2010 at 12:39 PM, Chris Jerdonek cjerdo...@webkit.org wrote: Hi, I have a basic question. What has been WebKit's stance on the use of the explicit keyword (for higher-level objects in particular)? Do we prefer the looser API's that conversion by constructor affords, or do we more often discourage relying on conversion by constructor? For comparison, the Google C++ style guide says the explicit keyword should almost always be used. Note that I'm not suggesting that this be added to our style guide. Thanks, --Chris ___ 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] converting by constructor
I think the Google guideline is pretty close to what a WebKit guideline would be. The explicit keyword should almost always be used when a constructor is creating an object and not just converting type from one to another. Leaving out the explicit keyword should be thought of as equivalent to defining a conversion operator, albeit working in the opposite direction. The AtomicString example Adam Barth cited is a problematic one. The cost of making an AtomicString from a String is high enough that having the conversion be implicit might be a mistake! But it was intentional I think the best way for us to clarify our guideline for this would be to discuss a few individual cases where we have a non-explicit constructor. We can talk about why they are not explicit and see if we find they are just bugs or show a principle at work. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Pixel test differences between Leopard and Snow Leopard
Leopard and Snow Leopard have subtle differences in the way they render antialiased text. This does not affect the text metrics but does cause slight pixel differences. The majority of our existing pixel test baselines appear to have been generated on Leopard, but there is a growing minority of tests that have been generated on Snow Leopard as well as a small number of baselines that are out of date or just plain incorrect. This means that when run with --tolerance=0, there are a significant number of failures on Snow Leopard that do not have anything to do with the behavior they are intended to test. Here are some concrete numbers (taken around r59000, the exact results vary slightly from revision to revision but not hugely). On a Leopard machine, running the tests with -p --tolerance=0 yields 120 failures. With the default tolerance (0.1%) there are 68 failures. On Snow Leopard, with -p --tolerance=0 there are 3934 failures. With the default tolerance (0.1%) there are 144 failures. Based on this, it seems reasonable to assume that there are ~3814 pixel test results in platform/mac that are Leopard specific. There is also a smaller number of results generated from Snow Leopard machines that fail on Leopard. I think this is an unhealthy state for the project as it prevents people developing on a Mac on Snow Leopard from running the pixel tests without getting a huge number of spurious failures. Currently pretty much all Mac developers are likely to be on Snow Leopard, except for Google employees who will be moving to Snow Leopard in the near future. The pixel tests are our only coverage for lots of the repaint logic currently. I think fundamentally there is a short term and a longer term problem here. The short term problem is that since the Mac pixel results are in such a bad state for people on Snow Leopard, people making changes to the code are not likely to update the pixel results at all which leads to an even worse mess in platform/mac. The longer term problem is that since the pixel tests are only run on build bots by one port (Chromium) and not run on build.webkit.org by anyone, the pixel tests are likely to languish. To resolve the immediate problem of Leopard-specific results in platform/mac, I'd like to move all of the Leopard-specific results currently in platform/mac to platform/mac-leopard and to generate new Snow Leopard specific results for those tests in platform/mac. Specifically my plan is to do this: For each test T with pixel results in platform/mac that fails on Leopard or Snow Leopard with -p --tolerance=0: - if T passes pixel tests exactly on Leopard and fails with a 0.5% pixel difference on Snow Leopard, assume the only pixel difference is due to text antialiasing and do the following: - svn mv the current platform/mac pixel results to platform/mac-leopard - add new pixel results generated on Snow Leopard into platform/mac - there should be around 3800 tests in this category - if T passes pixel tests exactly on Snow Leopard and fails with a 0.5% pixel difference on Leopard: - generate new pixel baselines for Leopard and add to platform/mac-leopard - there should be around 50 tests in this category - if T fails on both Leopard and Snow Leopard, remove the current expectations and file a bug - there should be around 70 tests in this category After this is done it should be possible to run the full layout test suite with --tolerance=0 on Snow Leopard and have no failures. Assuming this happens, I would like to switch the default value of --tolerance from 0.1 to 0.0 to try to keep regressions from creeping back in. Does this sound like a good plan? The biggest impact on the project will be a number of large commits in LayoutTests/platform/ to do the svn move and svn add operations to move results from platform/mac - platform/mac-leopard and to add new Snow Leopard results to platform/mac. This can be done over a weekend and mostly by a script to try to minimize impact. - James ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Pixel test differences between Leopard and Snow Leopard
On May 17, 2010, at 3:44 PM, James Robinson wrote: Leopard and Snow Leopard have subtle differences in the way they render antialiased text. This does not affect the text metrics but does cause slight pixel differences. The majority of our existing pixel test baselines appear to have been generated on Leopard, but there is a growing minority of tests that have been generated on Snow Leopard as well as a small number of baselines that are out of date or just plain incorrect. This means that when run with --tolerance=0, there are a significant number of failures on Snow Leopard that do not have anything to do with the behavior they are intended to test. Here are some concrete numbers (taken around r59000, the exact results vary slightly from revision to revision but not hugely). On a Leopard machine, running the tests with -p --tolerance=0 yields 120 failures. With the default tolerance (0.1%) there are 68 failures. On Snow Leopard, with -p --tolerance=0 there are 3934 failures. With the default tolerance (0.1%) there are 144 failures. Based on this, it seems reasonable to assume that there are ~3814 pixel test results in platform/mac that are Leopard specific. There is also a smaller number of results generated from Snow Leopard machines that fail on Leopard. I think this is an unhealthy state for the project as it prevents people developing on a Mac on Snow Leopard from running the pixel tests without getting a huge number of spurious failures. Currently pretty much all Mac developers are likely to be on Snow Leopard, except for Google employees who will be moving to Snow Leopard in the near future. The pixel tests are our only coverage for lots of the repaint logic currently. I think fundamentally there is a short term and a longer term problem here. The short term problem is that since the Mac pixel results are in such a bad state for people on Snow Leopard, people making changes to the code are not likely to update the pixel results at all which leads to an even worse mess in platform/mac. The longer term problem is that since the pixel tests are only run on build bots by one port (Chromium) and not run on build.webkit.org by anyone, the pixel tests are likely to languish. Thanks for doing this, James. At one point we had pixel bots at Apple, but they fell by the wayside. To resolve the immediate problem of Leopard-specific results in platform/mac, I'd like to move all of the Leopard-specific results currently in platform/mac to platform/mac-leopard and to generate new Snow Leopard specific results for those tests in platform/mac. Specifically my plan is to do this: For each test T with pixel results in platform/mac that fails on Leopard or Snow Leopard with -p --tolerance=0: - if T passes pixel tests exactly on Leopard and fails with a 0.5% pixel difference on Snow Leopard, assume the only pixel difference is due to text antialiasing and do the following: - svn mv the current platform/mac pixel results to platform/mac-leopard - add new pixel results generated on Snow Leopard into platform/mac - there should be around 3800 tests in this category - if T passes pixel tests exactly on Snow Leopard and fails with a 0.5% pixel difference on Leopard: - generate new pixel baselines for Leopard and add to platform/mac-leopard - there should be around 50 tests in this category - if T fails on both Leopard and Snow Leopard, remove the current expectations and file a bug - there should be around 70 tests in this category After this is done it should be possible to run the full layout test suite with --tolerance=0 on Snow Leopard and have no failures. Assuming this happens, I would like to switch the default value of --tolerance from 0.1 to 0.0 to try to keep regressions from creeping back in. You may find that some of the text antialiasing differences are hardware-dependent, so I'm not sure if a tolerance of 0 would be possible. Does this sound like a good plan? The biggest impact on the project will be a number of large commits in LayoutTests/platform/ to do the svn move and svn add operations to move results from platform/mac - platform/mac-leopard and to add new Snow Leopard results to platform/mac. This can be done over a weekend and mostly by a script to try to minimize impact. This sounds like a great short-term plan. I think a longer-term plan would be to move as many tests to ref-tests as possible, which eliminates any text-aliasing issues. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] converting by constructor
On Mon, May 17, 2010 at 3:11 PM, Darin Adler da...@apple.com wrote: I think the best way for us to clarify our guideline for this would be to discuss a few individual cases where we have a non-explicit constructor. We can talk about why they are not explicit and see if we find they are just bugs or show a principle at work. I wasn't intending to create a formal guideline, but one example I encountered recently is ResourceRequest, which has String and KURL single-parameter constructors without the explicit keyword. The FrameLoader class has about 25 methods that accept a ResourceRequest (e.g. various load methods), so all of these also accept a String and KURL. This makes it harder to know the right way these methods should be getting called. This also makes it harder to refactor. Call sites seem to use all three variations. The class also has other load-like methods that accept a String url, and others that accept a KURL url. --Chris ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] converting by constructor
On Mon, May 17, 2010 at 5:28 PM, Chris Jerdonek cjerdo...@webkit.org wrote: On Mon, May 17, 2010 at 3:11 PM, Darin Adler da...@apple.com wrote: I think the best way for us to clarify our guideline for this would be to discuss a few individual cases where we have a non-explicit constructor. We can talk about why they are not explicit and see if we find they are just bugs or show a principle at work. I wasn't intending to create a formal guideline, but one example I encountered recently is ResourceRequest, which has String and KURL single-parameter constructors without the explicit keyword. The FrameLoader class has about 25 methods that accept a ResourceRequest (e.g. various load methods), so all of these also accept a String and KURL. This makes it harder to know the right way these methods should be getting called. This also makes it harder to refactor. Call sites seem to use all three variations. Ouch. That sounds like a bug. :) The class also has other load-like methods that accept a String url, and others that accept a KURL url. Yeah, the whole String/KURL representation of a url issue is something we'd like to clean up at some point too. One of the considerations here is that KURL takes more memory than String to represent a URL. We'd like to measure and see how big an effect that is. One thing we could do in the intermediate term is use the type URLString for URLs that we store as Strings. This change wouldn't affect the compiled code, but it would help us keep track of what's going on better and pave the way for further changes in the future. I wrote a patch that started to do this, but the discussion got a bit sidetracked into the larger questions surrounding how to represent URLs: https://bugs.webkit.org/show_bug.cgi?id=36794 Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] converting by constructor
On May 17, 2010, at 12:39 PM, Chris Jerdonek wrote: Hi, I have a basic question. What has been WebKit's stance on the use of the explicit keyword (for higher-level objects in particular)? Do we prefer the looser API's that conversion by constructor affords, or do we more often discourage relying on conversion by constructor? For comparison, the Google C++ style guide says the explicit keyword should almost always be used. Note that I'm not suggesting that this be added to our style guide. We like to use implicit conversion where it makes sense. We only use the explicit keyword to prevent specifically undesired implicit conversions. As an example, the implicit conversions between String and AtomicString are very useful. They let the bindings generator write code from IDL without having to know whether the underlying C++ method takes a String or an AtomicString. An example of a bad implicit conversion would be the Vector constructor that takes just a size_t. We don't want numbers passed as parameters to magically turn into Vectors, not only is that confusing but it would lead to ambiguous overloads. So we mark it explicit. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
