Re: [webkit-dev] EFL and GTK EWS bots having issues
Sorry, wrong address. On Sat, Jul 12, 2014 at 10:55 AM, Eric Seidel esei...@google.com wrote: I used to use http://isitup.org/ to watch the front page. It would be trivial to extend the QueueStatusServer code to provide easier patches for services like isitup to watch: https://github.com/WebKit/webkit/tree/master/Tools/QueueStatusServer Similarly I think it's also possible to have app-engine email folks directly. On Fri, Jul 11, 2014 at 2:51 PM, Manuel Rego Casasnovas r...@igalia.com wrote: Hi, On 11/07/14 22:38, Joseph Pecoraro wrote: - GTK EWS bot has Unable to build without patch” with: ninja: error: build.ninja:3225: lexing error We found the problem and the EWS should be running properly again. Who would be best to look into these issues? I thought there used to be a list of EWS maintainers, but I couldn’t find it. I don't know about any list, but usually you can contact me or lti...@igalia.com for any issue with the EWS GTK+ bots (other people in Igalia could be an option too if we're not around). Bye, Rego ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] On Safari 5.1.8 for Snow Leopard...
As Maciej notes, this is not the right mailing list to ask these sorts of things. But since the answer appears simple, here it is: http://en.wikipedia.org/wiki/Safari_version_history claims that Safari 5.1.8 means WebKit 534.58.2 which theoretically comes from: http://trac.webkit.org/browser/branches/safari-534.58-branch http://opensource.apple.com/release/mac-os-x-1068/ also contains all the open-source code from the latest Snow Leopard (10.6.8). I don't work for Apple, and Wikipedia may be wrong. But at least now you have the source. On Tue, Apr 23, 2013 at 12:02 AM, Maciej Stachowiak m...@apple.com wrote: This isn't really a proper forum for this question. This list is for development of WebKit, not discussing the contents of specific vendor releases. For more information on this specific question, you can look at Apple's release notes for 5.1.8, or contact Apple Developer Relations. - Maciej On Apr 21, 2013, at 11:57 PM, Yuhong Bao yuhongbao_...@hotmail.com wrote: To the Apple people on this list: What exactly does Safari 5.1.8 for Snow Leopard contain? Does it contain security updates? Yuhong Bao ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling Experimental Features
FWIW, Blink is going through this right now too. We're attempting to move completely away from prefixed development: http://www.chromium.org/blink#vendor-prefixes To do that, that requires making it possible enable/disable CSS properties at runtime: https://code.google.com/p/chromium/issues/detail?id=232181 https://code.google.com/p/chromium/issues/detail?id=234270 Perhaps this is another opportunity for the two code bases to learn from one another as we both implement solutions to this. On Mon, Apr 22, 2013 at 9:32 AM, Simon Fraser simon.fra...@apple.com wrote: On Apr 20, 2013, at 10:03 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 19, 2013, at 3:50 PM, Timothy Hatcher timo...@apple.com wrote: On Apr 19, 2013, at 6:15 PM, Bear Travis betra...@adobe.com wrote: What do folks think about adding a mechanism for users to toggle features like this on in WebKit nightlies? I don't have a definite approach yet, but wanted to float the idea for feedback. I like the idea. Having things off for everyone but the engineers is a bad approach and misses out on testing. We could have WebKit modify Safari's Develop menu to provide additional items to toggle. Safari provides an Enable WebGL item, we could inject more items next to it. On Mac, we could at the very last use 'defaults write' to toggle experimental runtime-enabled features. One problem is that most CSS-exposed experimental features are not runtime-switchable. We'd have to do a bunch of work in the parser and style resolver to make this possible. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Rewriting binding code generator, maybe?
I retract my earlier statement. I think that the constraints here between WebKit and blink are different enough that we should only re-examine sharing code after both projects have had a chance to re-write this subsystem to better fit their needs. We originally imported these bindings generators from KDOM (and changed them quite a bit), but I suspect that they were never really a perfect fit for WebKit in the first place. Since we're both theoretically parsing WebIDL here, presumably there are several good parsers already. If both WebKit and Blink choose the same language to re-write their respective bindings generators in, perhaps we'll end up using the same parser library. Best of luck! On Wed, Apr 10, 2013 at 3:36 PM, Eric Seidel e...@webkit.org wrote: I know some folks in our TOK office have expressed strong interest in re-writing it in python for Blink. Perhaps there is an opportunity for some x-project collaboration here. On Wed, Apr 10, 2013 at 3:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, Can we rewrite CodeGenerator*.pm in Ruby or Python? I feel that the current code is very hard to understand and hack on. In particular we have CodeGenerator.pm and CodeGeneratorJS.pm (CodeGeneratorV8.pm has been removed), and we need to merge them anyway. I've seen many people expressing their inability to improve the binding code because of its being written in Perl. I'm not necessarily volunteering to do the work myself at this moment but I wanted to see if there is any interest in this idea or not. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Sunsetting committership and reviewership
Unrelated to Dmitry's suggestion, but since I brought up emeritus contributors earlier in the thread, I should explain my usage. The emeritus class proposed in the ancient webkit-reviewers thread about sunsetting was simply to answer the fact that committers.py has two purposes: 1. It exists as a public Access Control List (ACL) for svn.webkit.org (since I know of no other public ACL). 2. It exists as a way for our tools to lookup Contributor objects based on name, irc nick, svn email etc. emeritus contributors (in my original proposal on webkit-reviewers years ago) only exist to serve the second purpose, not the first. This would be similar to the Contributor and Account superclasses which have (since that old thread) been added to committers.py to allow committers.py to list non-commiters and even bots which we might want to have in our CC list, but not give any privileges to. Again, my thoughts on this may bear no reflection to what Dmitry had in mind with his use of the word emeritus, so I should let him speak! On Tue, Apr 9, 2013 at 11:39 PM, Filip Pizlo fpi...@apple.com wrote: Interesting. What privileges, if any, would you propose 'emeritus reviewers' to have? -Filip On Apr 9, 2013, at 2:54 PM, Dmitry Titov dim...@chromium.org wrote: How about creating an 'emeritus reviewer' status (no r+ power) and let people *voluntarily* move themselves to this status? I bet a lot of 'inactive reviewers' would do that, since everybody understands the issue of getting out of sync with current code base. It may have different vibe though than figuring some automatic time-based enforcement system... As an added bonus, this gives such people a good way to avoid being asked to review a patch for a colleague while keeping some ties with the project... On Mon, Apr 8, 2013 at 3:34 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 7, 2013, at 5:53 PM, Benjamin Poulain benja...@webkit.org wrote: On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher timo...@apple.com wrote: I think 6 months is fine for deactivating SVN accounts. And a full revoke of reviewer status after 2 years of no activity sounds reasonable to me. We could make it easier to get reviewer status again after a 2 year sunset if the person becomes active again and shows good judgment still. +1 to this. I think 2 years to revoke reviewer rights is too long. All the drive-by reviews that have caused problems were from reviewers that were inactive for less than 2 years. Nevertheless, 2 years is better than the current situation so it is a good start. We sometimes get low-quality drive-by reviews even from people who are active at the time. I feel like that's not the right basis for the time cutoff. If we do have a sunset period, we should think about it in terms of how long it takes to be so out of touch with the current state of the project that there's little chance you can give a useful review. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Sunsetting committership and reviewership
If we create an emeritus class in committers.py, we also have a whole bunch of old (long-webkit-retired) Apple committers/reviewers (ken, vicki, cblu, gramps, etc.) which should go there. :) Then the tools (including validate-committer-lists) would be less confused by their presence in ChangeLogs and commit messages. On Wed, Apr 10, 2013 at 12:41 AM, Filip Pizlo fpi...@apple.com wrote: I don't know if this is in line with what you and Dmitry were thinking, but here's what I like about a symbolic emeritus status: it takes care of the possible drive-by review problem while also continuing to recognize the person within the project. It's symbolic, and it feels nicer than just wiping them from the system. The fact that it serves the purpose of supporting lookup (your point (2)) is good, also. -Filip On Apr 10, 2013, at 12:37 AM, Eric Seidel e...@webkit.org wrote: Unrelated to Dmitry's suggestion, but since I brought up emeritus contributors earlier in the thread, I should explain my usage. The emeritus class proposed in the ancient webkit-reviewers thread about sunsetting was simply to answer the fact that committers.py has two purposes: 1. It exists as a public Access Control List (ACL) for svn.webkit.org (since I know of no other public ACL). 2. It exists as a way for our tools to lookup Contributor objects based on name, irc nick, svn email etc. emeritus contributors (in my original proposal on webkit-reviewers years ago) only exist to serve the second purpose, not the first. This would be similar to the Contributor and Account superclasses which have (since that old thread) been added to committers.py to allow committers.py to list non-commiters and even bots which we might want to have in our CC list, but not give any privileges to. Again, my thoughts on this may bear no reflection to what Dmitry had in mind with his use of the word emeritus, so I should let him speak! On Tue, Apr 9, 2013 at 11:39 PM, Filip Pizlo fpi...@apple.com wrote: Interesting. What privileges, if any, would you propose 'emeritus reviewers' to have? -Filip On Apr 9, 2013, at 2:54 PM, Dmitry Titov dim...@chromium.org wrote: How about creating an 'emeritus reviewer' status (no r+ power) and let people *voluntarily* move themselves to this status? I bet a lot of 'inactive reviewers' would do that, since everybody understands the issue of getting out of sync with current code base. It may have different vibe though than figuring some automatic time-based enforcement system... As an added bonus, this gives such people a good way to avoid being asked to review a patch for a colleague while keeping some ties with the project... On Mon, Apr 8, 2013 at 3:34 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 7, 2013, at 5:53 PM, Benjamin Poulain benja...@webkit.org wrote: On Sun, Apr 7, 2013 at 5:49 PM, Timothy Hatcher timo...@apple.com wrote: I think 6 months is fine for deactivating SVN accounts. And a full revoke of reviewer status after 2 years of no activity sounds reasonable to me. We could make it easier to get reviewer status again after a 2 year sunset if the person becomes active again and shows good judgment still. +1 to this. I think 2 years to revoke reviewer rights is too long. All the drive-by reviews that have caused problems were from reviewers that were inactive for less than 2 years. Nevertheless, 2 years is better than the current situation so it is a good start. We sometimes get low-quality drive-by reviews even from people who are active at the time. I feel like that's not the right basis for the time cutoff. If we do have a sunset period, we should think about it in terms of how long it takes to be so out of touch with the current state of the project that there's little chance you can give a useful review. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Rewriting binding code generator, maybe?
I know some folks in our TOK office have expressed strong interest in re-writing it in python for Blink. Perhaps there is an opportunity for some x-project collaboration here. On Wed, Apr 10, 2013 at 3:32 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, Can we rewrite CodeGenerator*.pm in Ruby or Python? I feel that the current code is very hard to understand and hack on. In particular we have CodeGenerator.pm and CodeGeneratorJS.pm (CodeGeneratorV8.pm has been removed), and we need to merge them anyway. I've seen many people expressing their inability to improve the binding code because of its being written in Perl. I'm not necessarily volunteering to do the work myself at this moment but I wanted to see if there is any interest in this idea or not. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Sunsetting committership and reviewership
Neither here nor there, but... I had interest in sunsetting committers/reviewers in the past. There are loads of folks listed in committers.py who haven't committed or reviewed in 5+ years. I believe there are some old threads on webkit-reviewers about such. I believe the timeout for sunsetting discussed in those old threads was more along the lines of 2-years. I should note that committers.py has some historical uses (for associating committers with commits), so you might want to consider using an emeritus section instead of removing entries. Best of luck. On Fri, Apr 5, 2013 at 12:05 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Apr 4, 2013 at 11:56 PM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Am 05.04.2013 um 08:19 schrieb Ryosuke Niwa rn...@webkit.org: Hi, This is somewhat related to the bulk move of Chromium-WebKit contributors to Blink, but we might want to consider sunsetting/expiring committership and reviewership. I'm thinking of something like expiring committership/reviwership of a person after the person didn't have any SVN activities for 3 or 6 months. Hm, that sounds really harsh - at least if the person is still within the WebKit project. I personally couldn't land a patch the last months as I'm busy with my thesis, but I'm clearly still qualified for SVG reviews and discussions, no? I follow development closely, even if not writing patches on my own at the moment. Would something like one year be a reasonable timeframe? I'm not suggesting that you have to go through non-committer status and wait for committer/reviewer nominations again once you passed that threshold. It's more about temporarily suspending accounts and removing people from committers.py to better access control things. If they're coming back to WebKit, they can request their committerships and reviewerships reinstated. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Sunsetting committership and reviewership
Sorry. Wrong address again. On Fri, Apr 5, 2013 at 12:09 AM, Eric Seidel esei...@google.com wrote: Neither here nor there, but... I had interest in sunsetting committers/reviewers in the past. There are loads of folks listed in committers.py who haven't committed or reviewed in 5+ years. I believe there are some old threads on webkit-reviewers about such. I believe the timeout for sunsetting discussed in those old threads was more along the lines of 2-years. I should note that committers.py has some historical uses (for associating committers with commits), so you might want to consider using an emeritus section instead of removing entries. Best of luck. On Fri, Apr 5, 2013 at 12:05 AM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Apr 4, 2013 at 11:56 PM, Nikolas Zimmermann zimmerm...@physik.rwth-aachen.de wrote: Am 05.04.2013 um 08:19 schrieb Ryosuke Niwa rn...@webkit.org: Hi, This is somewhat related to the bulk move of Chromium-WebKit contributors to Blink, but we might want to consider sunsetting/expiring committership and reviewership. I'm thinking of something like expiring committership/reviwership of a person after the person didn't have any SVN activities for 3 or 6 months. Hm, that sounds really harsh - at least if the person is still within the WebKit project. I personally couldn't land a patch the last months as I'm busy with my thesis, but I'm clearly still qualified for SVG reviews and discussions, no? I follow development closely, even if not writing patches on my own at the moment. Would something like one year be a reasonable timeframe? I'm not suggesting that you have to go through non-committer status and wait for committer/reviewer nominations again once you passed that threshold. It's more about temporarily suspending accounts and removing people from committers.py to better access control things. If they're coming back to WebKit, they can request their committerships and reviewerships reinstated. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
We'll be in #webkit and happy to be helpful in any way we can. I considered posting patches to remove *Chromium files yesterday afternoon, but then abarth reminded me that the commit-queue currently uses chromium-linux. I spoke with rniwa at some length yesterday in #webkit about transitioning the CQ to Mac, it sounded like it was mostly a question of ordering hardware. Relatedly, we're happy to turn down the Chromium EWS bots as soon as that's desired. Alan Cutter (alancutter) is our current administrator of such, also in #webkit and happy to help (he's on Australia time). On Thu, Apr 4, 2013 at 12:30 AM, Geoffrey Garen gga...@apple.com wrote: Hi folks. Since we no longer need to support the Chromium port, let's take the opportunity to streamline. Hopefully, this will make development easier and more coherent for everyone. Adam and Eric offered to do some of this cleanup, but I think it's healthier for people who will continue to be a part of WebKit to decide what gets cleaned up, and execute on the plan. Below is a high-level view of some improvements we're planning over the coming weeks. Concepts we plan to remove: Layering violations in WebCore/platform, where a Page* or Frame* is passed to a function Supplementable and Supplement #if USE(GOOGLEURL) #if USE(V8) #if !USE(JSC) #if PLATFORM(CHROMIUM) Skia DOMFileSystem WebLayer and its scrolling implementation Features #defines that haven't gained traction Specific files we plan to remove: .gyp build files WebCore/bindings/v8 WebCore/bindings/scripts/*v8* LayoutTests/platform/chromium* WebKit/chromium WTF/wtf/chromium WebCore/platform/chromium WebCore/*Chromium* Source/Platform/chromium ManualTests/chromium/ Tools/BuildSlaveSupport/chromium/ Tools/DumpRenderTree/chromium/ Also: Adopt libc++ Please let me know if you have other suggestions for improvements, or if you see something in the list that shouldn't be there. Thanks, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
We're ready to turn down the cr-linux EWS bots at your command. Just let us know (via email or #webkit). Thanks! On Thu, Apr 4, 2013 at 12:50 PM, Geoffrey Garen gga...@apple.com wrote: To clarify: (1) The EWS bots are still running. (2) The mac and mac-wk2 EWS bots are running tests, and passing. (3) The cr-linux bots are running tests, and failing. If we're OK with item (3), we can go ahead with cleaning house, and break the cr-* EWS bots entirely, while we work on making the mac and mac-wk2 EWS bots faster. Geoff On Apr 4, 2013, at 12:44 PM, Filip Pizlo fpi...@apple.com wrote: I think everyone is agreeing that we should have a suitable replacement for EWS. But I also want to see us move forward with clean ups. I think such clean ups will bring clarity to what we would want our EWS testing to look like since we'll have fewer configurations to test. I like the approach of switching to manual testing in the short term, and working in parallel on an EWS replacement. Sent from my PDP-11 On Apr 4, 2013, at 12:02 PM, Brent Fulgham bfulg...@gmail.com wrote: Hi folks, I definitely do not want to see the EWS system go away. But in the short term , I would be in favor of manual commits and manual testing. We still have the build bots running tests, so it's not like we lose all coverage. Thanks, -Brent Sent from my iPhone On Apr 4, 2013, at 11:56 AM, Geoffrey Garen gga...@apple.com wrote: I'd also suggest purging the chromium layout tests ASAP so we can enjoy the much-reduced archive sync costs. We really need to get the Mac or Win EWS performing tests by default and reliably before doing this. At present, only the chromium-linux EWS bot has been consistently running tests. When Mac/Win tests were turned on recently, it resulted in huge backups on those EWS bots, and eventually having tests disabled. Sorry, I got excited and removed the Chromium test results before I read this email. If committers are willing to do their own regression testing and committing, we can move forward with cleaning house. (For what it's worth, that's how I've always worked.) Otherwise, if we want to depend on the Chromium EWS tester and the Chromium commit queue, we have to put cleaning house on hold. We need to keep the Chromium/v8 port building, and maintain its test results, until we have alternate sources for that stuff. If that's the consensus, I'll restore the cr-linux and cr-linux-x86 test results. My preference is to move forward with cleaning house. It has already reduced the webkit download size by 1GB. What do other folks think? Regards, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Resent from the right address. On Thu, Apr 4, 2013 at 1:09 PM, Eric Seidel esei...@google.com wrote: We're ready to turn down the cr-linux EWS bots at your command. Just let us know (via email or #webkit). Thanks! On Thu, Apr 4, 2013 at 12:50 PM, Geoffrey Garen gga...@apple.com wrote: To clarify: (1) The EWS bots are still running. (2) The mac and mac-wk2 EWS bots are running tests, and passing. (3) The cr-linux bots are running tests, and failing. If we're OK with item (3), we can go ahead with cleaning house, and break the cr-* EWS bots entirely, while we work on making the mac and mac-wk2 EWS bots faster. Geoff On Apr 4, 2013, at 12:44 PM, Filip Pizlo fpi...@apple.com wrote: I think everyone is agreeing that we should have a suitable replacement for EWS. But I also want to see us move forward with clean ups. I think such clean ups will bring clarity to what we would want our EWS testing to look like since we'll have fewer configurations to test. I like the approach of switching to manual testing in the short term, and working in parallel on an EWS replacement. Sent from my PDP-11 On Apr 4, 2013, at 12:02 PM, Brent Fulgham bfulg...@gmail.com wrote: Hi folks, I definitely do not want to see the EWS system go away. But in the short term , I would be in favor of manual commits and manual testing. We still have the build bots running tests, so it's not like we lose all coverage. Thanks, -Brent Sent from my iPhone On Apr 4, 2013, at 11:56 AM, Geoffrey Garen gga...@apple.com wrote: I'd also suggest purging the chromium layout tests ASAP so we can enjoy the much-reduced archive sync costs. We really need to get the Mac or Win EWS performing tests by default and reliably before doing this. At present, only the chromium-linux EWS bot has been consistently running tests. When Mac/Win tests were turned on recently, it resulted in huge backups on those EWS bots, and eventually having tests disabled. Sorry, I got excited and removed the Chromium test results before I read this email. If committers are willing to do their own regression testing and committing, we can move forward with cleaning house. (For what it's worth, that's how I've always worked.) Otherwise, if we want to depend on the Chromium EWS tester and the Chromium commit queue, we have to put cleaning house on hold. We need to keep the Chromium/v8 port building, and maintain its test results, until we have alternate sources for that stuff. If that's the consensus, I'll restore the cr-linux and cr-linux-x86 test results. My preference is to move forward with cleaning house. It has already reduced the webkit download size by 1GB. What do other folks think? Regards, Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Thank You
I’m writing to say thank you, personally, and on behalf of the Chromium project. Chromium could not have happened without WebKit and the help of its contributors. As you likely have seen, Adam just posted http://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html announcing Blink, which is a departure from our previous WebKit workflow. I hope that others will see Blink as I do: as a chance to take the WebKit codebase to exciting new places. I hope someday that many of the ideas we pursue in Blink will find their way into many platforms, including WebKit. For those interested in the technical details, we’ll be posting more of our thoughts and plans to blink-...@chromium.org. WebKit and Chromium have a long, shared history, and we hope to continue our relationship. We will be available on #webkit and webkit-dev and hope to continue our connections with this great community for years to come. Thank you again. Eric p.s. Adam and I are happy to work with other reviewers to remove PLATFORM(CHROMIUM) code and other messes we may have caused over the years from webkit.org. Adam and I are still running queues.webkit.org and associated EWS/CQ/sherriff-bot and plan to do so for the next few weeks as we work to transition them to new owners. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Ever increasing binary size
It seems like it should be trivial to set up an EWS bot to track size changes. It would (sadly) need to clobber, as my understanding is that incremental builds are not deterministic in their sizes: https://code.google.com/p/chromium/issues/detail?id=110002 (our bug about this for Chromium Try servers). Thankfully the EWS is very well suited for this task. On Fri, Mar 22, 2013 at 1:29 AM, Benjamin Poulain benja...@webkit.org wrote: On Fri, Mar 22, 2013 at 12:12 AM, Ryosuke Niwa rn...@webkit.org wrote: WebKit nightly build for r135421 dated November 21st, 2012 was 46.1MB. WebKit nightly build for r145786 dated March 13th, 2013 was 49.4MB. Our binary size increased by 7.2% in just 4 months. I have been tracking this issue for a bit. I can send more detailed view of the growth if anyone is interested. Is this a problem? I think it is. It means that we use more RAM when WebKit is loaded onto memory. It means that it takes longer to load WebKit into RAM. It means that auto-update, etc... various browsers that use WebKit needs to send more data over the network. 6MB costs you a ton if you're wiring over cellar network. RAM space is not the only problem we have with big binaries. The bigger our code gets, the less efficiently we use the fast CPU caches and WebKit gets slower over time overall. On embedded, you typically have tiny caches and slower memory. This leads to a lot of memory pressure and we had to cut binary size sometimes to get the performance back. What strategies can we use to address this problem? I would like it if EWS could report growth and shrinkage somehow, and have a warning in case of abnormal growth. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Ever increasing binary size
Perhaps useful to you: http://neugierig.org/software/chromium/bloat/ On Fri, Mar 22, 2013 at 12:06 PM, Elliott Sprehn espr...@chromium.org wrote: I'd be really interesting to see what patches are causing the growth and by how much. I wonder how much of this is from some of the fancier template things we have (ex. the 600 template expansions from StyleBuilder) On Fri, Mar 22, 2013 at 5:22 AM, Eric Seidel e...@webkit.org wrote: It seems like it should be trivial to set up an EWS bot to track size changes. It would (sadly) need to clobber, as my understanding is that incremental builds are not deterministic in their sizes: https://code.google.com/p/chromium/issues/detail?id=110002 (our bug about this for Chromium Try servers). Thankfully the EWS is very well suited for this task. On Fri, Mar 22, 2013 at 1:29 AM, Benjamin Poulain benja...@webkit.org wrote: On Fri, Mar 22, 2013 at 12:12 AM, Ryosuke Niwa rn...@webkit.org wrote: WebKit nightly build for r135421 dated November 21st, 2012 was 46.1MB. WebKit nightly build for r145786 dated March 13th, 2013 was 49.4MB. Our binary size increased by 7.2% in just 4 months. I have been tracking this issue for a bit. I can send more detailed view of the growth if anyone is interested. Is this a problem? I think it is. It means that we use more RAM when WebKit is loaded onto memory. It means that it takes longer to load WebKit into RAM. It means that auto-update, etc... various browsers that use WebKit needs to send more data over the network. 6MB costs you a ton if you're wiring over cellar network. RAM space is not the only problem we have with big binaries. The bigger our code gets, the less efficiently we use the fast CPU caches and WebKit gets slower over time overall. On embedded, you typically have tiny caches and slower memory. This leads to a lot of memory pressure and we had to cut binary size sometimes to get the performance back. What strategies can we use to address this problem? I would like it if EWS could report growth and shrinkage somehow, and have a warning in case of abnormal growth. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: EWS bots now upload results again
I think to expect folks to use these results, we're going to need to give them nice tools, like: https://bugs.webkit.org/show_bug.cgi?id=92033 On Thu, Mar 21, 2013 at 10:55 AM, Ryosuke Niwa rn...@webkit.org wrote: Fixed it in http://trac.webkit.org/changeset/146443. So yeah, don't add entries for rebaselines in platform/mac/TestExpectations please. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: EWS bots now upload results again
Thank you very much for making the uploads (and thus the flaky test reporter) work again! On Thu, Mar 21, 2013 at 2:52 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Mar 21, 2013 at 2:50 PM, Eric Seidel e...@webkit.org wrote: I think to expect folks to use these results, we're going to need to give them nice tools, like: https://bugs.webkit.org/show_bug.cgi?id=92033 I might work on that tonight if I decide to stay up 'til 4am again. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Best practices for landing new/changed layout test expectations?
Thanks for following up Philip. I don't feel like this thread met much consensus, more just went off into the weeds. Given the history of that page, I'm not sure it truly reflects the consensus of the project: https://trac.webkit.org/wiki/CreatingLayoutTests?action=history Regardless of whether you are making a platform independent change or dependent change, it is your responsibility to ensure that the change does not negatively affect any other ports / platforms. This includes updating platform specific results or contacting a port maintainer to do this for you (for contacts, see: http://trac.webkit.org/wiki/WebKit%20Team). I'm not sure I see anyone following this these days. The EWS system and sherriffiing cultures seem to have largely replaced bot-monitoring. We also don't really have a system of core ports, thus all ports seems a bit broad here. Once your change is landed, there are some steps required to verify the change. Note: These steps apply for all changes. If you are making a platform dependent change, you should expect that additional results will be required for each platform but the actions are the same. I'm not sure it makes any sense to ask contributors to update other ports. In many cases, it's not possible for contributors to even build other ports. We clearly need some sort of automated system for this, but right now I believe the expectation is that maintainers of the various ports will add the port-specific results, and that those contributing new layout tests should just land their results as the common ones? But I could be mistaken. I think the reality is that the project doesn't really have consensus here, likely meaning this is a good topic for the contributors meeting. On Wed, Mar 13, 2013 at 3:12 PM, Philip Rogers p...@google.com wrote: The steps described here differ from what I've been doing. In the interest of closure and port happiness, I've updated the wiki to reflect what is being proposed: https://trac.webkit.org/wiki/CreatingLayoutTests Please feel free to update it further. Philip On Tue, Feb 26, 2013 at 2:34 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Feb 26, 2013 at 1:03 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 26, 2013 at 12:47 PM, Dirk Pranke dpra...@chromium.org wrote: On Tue, Feb 26, 2013 at 2:11 AM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 26, 2013 at 1:55 AM, Tom Hudson tomhud...@google.com wrote: On Mon, Feb 25, 2013 at 10:34 PM, Ryosuke Niwa rn...@webkit.org wrote: It should be fairly straight forward to create a tool that analyzes files changed in each commit and deduce which tests' expected results have been changed. The tool can then fetch results from each port' bot for those tests and automatically land them. It can then comment on the bug automatically about these rebaseline commits. There is no need to add remove entries from TestExpectation files. Wait, what? For some reason neither I nor the mailing list archives got your initial message, nor Silvia or Tom's responses, nor your responses (at least as of the time of me writing this), so I feel like I've missed a radical shift in this thread, and maybe I missed some of the context. https://lists.webkit.org/pipermail/webkit-dev/2013-February/023967.html This link doesn't point to any of those messages, but perhaps it's not that important. You're proposing that we automatically land updated baselines without review and then somehow update bugs, have people go back and look at the updated bugs to see if the baseline changes represent actual regressions or just expected changes? Right. Given that the commit already contains information as to which tests have been rebaselined, a script should be able to fetch new baselines for those affected tests on each platform and land them or upload as patches as needed. It's possible that we could fetch and cluster new baselines based on what changed in the initial commit. I would be concerned that there could be a fair amount of noise in either direction (tests that changed on the initial platform didn't on others, and others did), and you'd also have to figure out how to cluster changes since most builds on the bots contain multiple changes. But, you could probably use some of garden-o-matic's results to help here. That said, I'm not sure this workflow would actually improve things much over garden-o-matic. I am quite a bit more reluctant to automatically land any such changes; it seems like it would be hard if not impossible to tell (programmatically) whether a baseline changed as expected or if it represented a regression. If we were to work on new tooling, I would be much more in favor of pushing this up to an EWS-time step like Ossy suggests. -- Dirk ___ webkit-dev mailing list
[webkit-dev] Elliot Sprehn is now a reviewer
May our generated content (and general render safety and speed) live long and prosper. :) Grats Elliot! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] PSA: --profile works in run-webkit-tests now too
As of http://trac.webkit.org/changeset/144719 --profile and --profiler= work in run-webkit-tests, just like they do in run-perf-tests. For example you can find out why your/favorite/tests are so slow with: run-webkit-tests your/favorite/tests --profile RWT will sample each DRT instance and print out instructions on how to view it (or show you the top 10 samples if you're on an OS with command-line). On my Mac, it says something like: iprofiler: Profiling process 21958 (DumpRenderTree) for 10 seconds iprofiler: Session saved at /Users/eseidel/Projects/WebKit/Source/WebKit/chromium/webkit/Release/layout-test-results/test-72.dtps I've found these incredibly useful for making WebKit faster, and I hope you do too. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Philip Rogers is now a Reviewer
Nice to have another hand for SVG reviews. :) Grats to pdr! ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Best practices for landing new/changed layout test expectations?
I've noticed as of late several different approaches being used when adding/changing LayoutTests which need rebaselining on other platforms. Obviously we cannot expect developers to test/rebaseline on all platforms before landing given our current infrastructure. But what should we expect them to do? Currently some folks add failing expectations to other ports TestExpectations. Some add [skip]. Some even add them to the (new) global TestExpectations file. What's the proper course of action? I checked: http://trac.webkit.org/wiki/Keeping%20the%20Tree%20Green http://trac.webkit.org/wiki/Creating%20and%20Submitting%20Layout%20Tests%20and%20Patches http://trac.webkit.org/wiki/TestExpectations and didn't see the I expect this to fail/need rebaseline on other ports case discussed. I remember some discussion of a [rebaseline] keyword in TestExpectations, but I'm not sure that ever made it in? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [Coding Style] Clarification about multiple assignments on one line
I have no objection to us using this compiler feature. On Fri, Feb 22, 2013 at 2:35 PM, Julien Chaffraix jchaffr...@webkit.orgwrote: Hi WebKit folks, over several reviews, I have been saying that the following line is a coding style violation: firstVariable = secondVariable = 0; For a concrete example, the computePreferredLogicalWidths uses the following pattern: minWidth = maxWidth = maxint(minWidth, tableLogicalWidth.value()); My justification is that those are 2 statements and thus should be on 2 lines per Each statement should get its own line.. Some people consider that the previous rule doesn't apply to multiple assignments on one line and that such code is fine by the book. What do people think? Thanks, Julien ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] build.webkit.org problem
App engine error perhaps? http://webkit-commit-queue.appspot.com/active-bots On Sun, Feb 17, 2013 at 4:15 AM, Mike West mk...@chromium.org wrote: (Resending from the right address, sorry...) Perhaps relatedly (but probably not), the CQ and other Chromium EWS bots apparently died about 13 hours ago: http://webkit-commit-queue.appspot.com/ Adam, Eric, mind taking a quick look? -mike -Mike On Sun, Feb 17, 2013 at 12:29 PM, Mike West mk...@google.com wrote: Perhaps relatedly (but probably not), the CQ and other Chromium EWS bots apparently died about 13 hours ago: http://webkit-commit-queue.appspot.com/ Adam, Eric, mind taking a quick look? -mike On Feb 17, 2013 10:30 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote: Hi, It seems something happened with build.webkit.org. There are pending builds on all builder, but the master doesn't make slaves start these builds. Could you check what happened with the buildbot master, please? Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] build.webkit.org problem
24.22.211.12 - - [17/Feb/2013:09:35:10 -0800] GET /active-bots HTTP/1.1 500 0 http://webkit-commit-queue.appspot.com/; Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.57 Safari/537.17 webkit-commit-queue.appspot.com ms=9380 cpu_ms=2030 loading_request=1 pending_ms=1180 exit_code=105 instance=00c61b117ce3ad08e236a217d9ee5bdce8f5 C 2013-02-17 09:35:10.282 Exceeded soft private memory limit with 182.148 MB after servicing 0 requests total I 2013-02-17 09:35:10.282 This request caused a new process to be started for your application, and thus caused your application code to be loaded for the first time. This request may thus take longer and use more CPU than a typical request for your application. W 2013-02-17 09:35:10.282 While handling this request, the process that handled this request was found to be using too much memory and was terminated. This is likely to cause a new process to be used for the next request to your application. If you see this message frequently, you may have a memory leak in your application. On Sun, Feb 17, 2013 at 9:31 AM, Eric Seidel esei...@google.com wrote: App engine error perhaps? http://webkit-commit-queue.appspot.com/active-bots On Sun, Feb 17, 2013 at 4:15 AM, Mike West mk...@chromium.org wrote: (Resending from the right address, sorry...) Perhaps relatedly (but probably not), the CQ and other Chromium EWS bots apparently died about 13 hours ago: http://webkit-commit-queue.appspot.com/ Adam, Eric, mind taking a quick look? -mike -Mike On Sun, Feb 17, 2013 at 12:29 PM, Mike West mk...@google.com wrote: Perhaps relatedly (but probably not), the CQ and other Chromium EWS bots apparently died about 13 hours ago: http://webkit-commit-queue.appspot.com/ Adam, Eric, mind taking a quick look? -mike On Feb 17, 2013 10:30 AM, Osztrogonác Csaba o...@inf.u-szeged.hu wrote: Hi, It seems something happened with build.webkit.org. There are pending builds on all builder, but the master doesn't make slaves start these builds. Could you check what happened with the buildbot master, please? Ossy ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Version control survey results
I wonder if the git-taking-over-the-project trend has continued a year later. I'm also glad to see efforts like https://bugs.webkit.org/show_bug.cgi?id=110073 towards standardizing on a simpler git workflow. :) Thanks again for running the survey. On Sat, Apr 7, 2012 at 4:58 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 22, 2012, at 9:16 PM, Adam Barth wrote: On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak m...@apple.com wrote: I made a bad choice of survey site. They want to charge me to see more than 100 responses or to export the data, but they won't take my money. Sadness. Please try this survey instead, it will run through the 17th. The survey seems to be over. Any word on the results? Here's the results: == All persons responding == Total responses: 167 Use SVN only: 24 (14%) Use SVN+ Git: 26 (16%) Use Git Only: 115 (69%) Other: 2 (1%) == Only committers + reviewers == Total responses: 105 Use SVN only: 18 (17%) Use SVN+ Git: 21 (20%) Use Git Only: 65 (62%) Other: 1 (1%) == Only reviewers == Total responses: 48 Use SVN only: 12 (25%) Use SVN+ Git: 13 (27%) Use Git Only: 22 (45%) Other: 1 (2%) == Values of other responses == 1 git-svn 1 Commit queue + trac == Conclusions (assuming the sample is representative) == - More of the WebKit community uses Git than SVN to access the WebKit repository - Quite a few people use both - A significant proportion of the community uses SVN, and a significant fraction of those use it exclusively - Reviewers (presumably longer-time, more experienced contributors) are more likely to use SVN than newer contributors - Newer participants are particularly likely to use Git ___ 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 https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Version control survey results
On Sun, Feb 17, 2013 at 9:54 PM, Maciej Stachowiak m...@apple.com wrote: There's probably proportionately more people using Git. Making these web surveys is a pain, so I'd rather not do it again if we don't need to. What would be the pros and cons of the master repository being git instead of svn, for git users? The conversion is clearly not loss-less. :) So it's like asking what would be the pros of backing an SVN checkout with an SVN repository instead of a Git one (or a CVS one for that matter). I'm sure someone who cares more deeply about version control than I do could give you a list. :) But that's not really an argument I'm interested in pushing. I believe eventually the remaining SVN users will switch to distributed version control of their own will, and we'll eventually decide to stop supporting SVN because not enough of the project is using it to justify causing the majority of users to use a translated solution. But we have larger problems to solve in WebKit besides what version control system we're using. :) I'm sorry for re-starting this thread and distracting from more important discussions. It just crossed my mind for whatever reason again this evening. (For current svn users I assume using svn would become effectively impossible; the only tool I could find to do this is server-side and essentially maintains git and svn repositories in parallel.) - Maciej On Feb 17, 2013, at 9:00 PM, Eric Seidel e...@webkit.org wrote: I wonder if the git-taking-over-the-project trend has continued a year later. I'm also glad to see efforts like https://bugs.webkit.org/show_bug.cgi?id=110073 towards standardizing on a simpler git workflow. :) Thanks again for running the survey. On Sat, Apr 7, 2012 at 4:58 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 22, 2012, at 9:16 PM, Adam Barth wrote: On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak m...@apple.com wrote: I made a bad choice of survey site. They want to charge me to see more than 100 responses or to export the data, but they won't take my money. Sadness. Please try this survey instead, it will run through the 17th. The survey seems to be over. Any word on the results? Here's the results: == All persons responding == Total responses: 167 Use SVN only: 24 (14%) Use SVN+ Git: 26 (16%) Use Git Only: 115 (69%) Other: 2 (1%) == Only committers + reviewers == Total responses: 105 Use SVN only: 18 (17%) Use SVN+ Git: 21 (20%) Use Git Only: 65 (62%) Other: 1 (1%) == Only reviewers == Total responses: 48 Use SVN only: 12 (25%) Use SVN+ Git: 13 (27%) Use Git Only: 22 (45%) Other: 1 (2%) == Values of other responses == 1 git-svn 1 Commit queue + trac == Conclusions (assuming the sample is representative) == - More of the WebKit community uses Git than SVN to access the WebKit repository - Quite a few people use both - A significant proportion of the community uses SVN, and a significant fraction of those use it exclusively - Reviewers (presumably longer-time, more experienced contributors) are more likely to use SVN than newer contributors - Newer participants are particularly likely to use Git ___ 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 https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Version control survey results
On Sun, Feb 17, 2013 at 10:07 PM, Eric Seidel e...@webkit.org wrote: On Sun, Feb 17, 2013 at 9:54 PM, Maciej Stachowiak m...@apple.com wrote: There's probably proportionately more people using Git. Making these web surveys is a pain, so I'd rather not do it again if we don't need to. What would be the pros and cons of the master repository being git instead of svn, for git users? The conversion is clearly not loss-less. :) So it's like asking what would be the pros of backing an SVN checkout with an SVN repository instead of a Git one (or a CVS one for that matter). Of course I meant backing an SVN checkout with a Git repository instead of an SVN one (or a CVS one for that matter). If that makes any more sense. :) I'm sure someone who cares more deeply about version control than I do could give you a list. :) But that's not really an argument I'm interested in pushing. I believe eventually the remaining SVN users will switch to distributed version control of their own will, and we'll eventually decide to stop supporting SVN because not enough of the project is using it to justify causing the majority of users to use a translated solution. But we have larger problems to solve in WebKit besides what version control system we're using. :) I'm sorry for re-starting this thread and distracting from more important discussions. It just crossed my mind for whatever reason again this evening. (For current svn users I assume using svn would become effectively impossible; the only tool I could find to do this is server-side and essentially maintains git and svn repositories in parallel.) - Maciej On Feb 17, 2013, at 9:00 PM, Eric Seidel e...@webkit.org wrote: I wonder if the git-taking-over-the-project trend has continued a year later. I'm also glad to see efforts like https://bugs.webkit.org/show_bug.cgi?id=110073 towards standardizing on a simpler git workflow. :) Thanks again for running the survey. On Sat, Apr 7, 2012 at 4:58 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 22, 2012, at 9:16 PM, Adam Barth wrote: On Sat, Mar 10, 2012 at 12:49 PM, Maciej Stachowiak m...@apple.com wrote: I made a bad choice of survey site. They want to charge me to see more than 100 responses or to export the data, but they won't take my money. Sadness. Please try this survey instead, it will run through the 17th. The survey seems to be over. Any word on the results? Here's the results: == All persons responding == Total responses: 167 Use SVN only: 24 (14%) Use SVN+ Git: 26 (16%) Use Git Only: 115 (69%) Other: 2 (1%) == Only committers + reviewers == Total responses: 105 Use SVN only: 18 (17%) Use SVN+ Git: 21 (20%) Use Git Only: 65 (62%) Other: 1 (1%) == Only reviewers == Total responses: 48 Use SVN only: 12 (25%) Use SVN+ Git: 13 (27%) Use Git Only: 22 (45%) Other: 1 (2%) == Values of other responses == 1 git-svn 1 Commit queue + trac == Conclusions (assuming the sample is representative) == - More of the WebKit community uses Git than SVN to access the WebKit repository - Quite a few people use both - A significant proportion of the community uses SVN, and a significant fraction of those use it exclusively - Reviewers (presumably longer-time, more experienced contributors) are more likely to use SVN than newer contributors - Newer participants are particularly likely to use Git ___ 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 https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the New XMLParser dead?
He's dead, Jim: https://bugs.webkit.org/show_bug.cgi?id=107522 On Thu, Jan 17, 2013 at 5:54 PM, Maciej Stachowiak m...@apple.com wrote: I think it's fine to shoot it in the head now. We do still want to come back to it eventually, but it's now apparent that we won't in the next 1.5 months. - Maciej On Jan 17, 2013, at 4:15 PM, Adam Barth aba...@webkit.org wrote: Maciej has asked that we keep it around until the end of February: https://bugs.webkit.org/show_bug.cgi?id=100710 Adam On Thu, Jan 17, 2013 at 4:10 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi, It has been 11 months since Eric initially raised the concern. Can we go ahead and remove the parser now? - R. Niwa ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing ENABLE(WEB_INTENTS) code
Having just spent all day removing NEW_XML cruft, I'm glad to see this unused code go sooner rather than later. :) On Mon, Feb 11, 2013 at 3:44 PM, Nico Weber tha...@chromium.org wrote: Going once, going twice… https://bugs.webkit.org/show_bug.cgi?id=109501 On Sat, Feb 2, 2013 at 3:09 PM, Sam Weinig wei...@apple.com wrote: Sounds good to me as well. -Sam On Jan 30, 2013, at 3:54 PM, Nico Weber tha...@chromium.org wrote: Hi, I'd like to delete all the ENABLE(WEB_INTENTS) code. As far as I know, nobody ever shipped this and nobody intents to. Please speak up if you'd like that code to stick around. Nico ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Is the wxWidgets port maintained?
This entire email thread makes me sad. I'm sad because we did this to ourselves (our porting systems/policies are lacking), we did this very abruptly (the last port we kicked out of webkit.org took a year?), and we don't have any clear policy for this sort of thing (adding/removing ports in webkit.org). I think this, and many recent threads on the subject, are symptoms of the same problem: We are at a point in WebKit (and have been for a long time) where we are focused less on the Web Platform (via WebKit) being everywhere, and more on that Web Platform being awesome. Maybe it's time we clarified this in our goals doc? Our (my!) previous platform-abstraction mistakes have also left us in an awkward position where it is difficult for us to support 7+ ports with separate build systems, and separate sets of constraints (however minor) on WebCore. I think it is the right decision to de-couple all ports from the core code, but doing that is going to take us a very long time. I think that moving closer to one build system will help, but won't help those trying to advance WebCore from having to deal with 8 different port APIs, 5 different networking libraries, 2 different XML parser, 4 different GraphicsContext implementations, and countless other configuration options! I guess the point of this all is that I'm sorry. I'm sorry to Kevin, and all the other ports that I've helped integrate with WebKit, that I and others didn't sit down years ago and design better, more maintainable porting systems for WebKit. I think if we as a community are actively interested in maintaining as many ports as we have (and welcoming new ones) we need to come up with better ways to do so. And clearer policies for what it means to be a port in WebKit. In the specific case of Wx, I am reluctantly agreed that code with only one(?) maintainer is pretty close to dead and thus per WebKit's long-standing dead/commented-out code policies should be removed. :( Kevin has been with us a long time, and asking him to leave in this manner is saddening. Of course saying Wx is dead code, begs the question as to what is needed for a port to be considered live in WebKit.org? With our current porting architecture, I would argue that at least 3 full time people are probably needed, and that this should be considered before accepting new ports. I'm not in any rush to see Wx removed, and I agree it makes sense to let Kevin write the patches as much as he's willing. I think certainly having to wake up one day to see that one of your Open Source projects is kicking you out, is pretty jaring. :( I hope we can do this better next time, and maybe we should have a separate discussion about what it means to be a supported port in WebKit.org and what new/existing ports need to do to meet that bar. As for the future of WebKit on Wx: I don't know enough about WebKit2 to know if it has a more easily portable/maintainable architecture. For the port I work on (chromium), others haven't really ported in WebKit.org, but rather port at a higher level -- Chromium's Content layer or https://code.google.com/p/chromiumembedded/. Maybe one of those options are a better solution for a port like Wx with limited resources? Again, my apologies to you Kevin for my part in all this. On Mon, Feb 11, 2013 at 7:44 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Feb 11, 2013 at 6:17 PM, Kevin Ollivier kev...@theolliviers.com wrote: To be honest, I think I know more about the wx port, and would probably be better able to cleanly remove it from the tree, than you would. As I've said from the start, I'll remove it if that's what people want, but I do think the severity of this problem is being exaggerated, and going from posing the question of project status to giving a one week eviction notice in less than 24 hours seems a bit rash to say the least. I wish I could get paid good money to spend my time doing things like creating patches to remove inactive files from source trees. :) As it stands, though, this wasn't exactly on my TODO list for this week as of, say, this morning, and I do have plenty on it right now. I'm already even regretting how much time I've put into this discussion. I am sorry, I should have given more context. There is visibly a growing discontent in the community about the cost imposed from small ports. Just two weeks ago, there were 2 threads discussing the cost of peripheral ports. I am convinced a part of this is technical. The project has not changed its policies while the number of ports was growing. While duplicated code and interfaces was okay when there were only 3 ports, it has become a pain when we have 7+ ports to updates. This weekend, I was looking at technical ways to reduce the problems, and the wx port looks like one of the issue. Everyone with whom I have discussed that today seems to agree. You said yourself As things stand, I'd not only be okay with, but actually prefer, that no
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
I'm curious if YAML was ever considered? I have very limited experience with YAML, except for Google App Engine config files. It's very python parse-able? :) On Tue, Feb 5, 2013 at 11:55 AM, Mark Mentovai m...@chromium.org wrote: You’re not supposed to use arbitrary Python, it’s highly discouraged. We have a linter that keeps you from doing things you’re not supposed to do (like this), but it slows things down, so it’s not part of the “standard” GYP run that developers normally use. It can run as a pre-commit script or test on the bot or something else. Used as we’re using it, GYP basically is simple JSON, except the rules about commas are looser and # introduces comments. On Tue, Feb 5, 2013 at 2:47 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Feb 5, 2013 at 6:09 AM, Mark Mentovai m...@chromium.org wrote: The parser (and the grammar) works the way it does because it’s just Python This works great for people who like Python syntax but not for someone like myself who dislikes Python syntax. I also find it particularly annoying that people can use whatever Python constructs they want to use in GYP. It dramatically reduces language portability because you need to support quite a few Python constructs and quirks in order to correctly parse GYP. I personally would have much preferred for it be a simple JSON file. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Common build system (was Re: WebKit Wishes)
+1 Ninja is beyond-words amazing. http://martine.github.com/ninja/ For better or worse, it is not designed to use human-editable build files, but rather to be used by a meta build system, like GYP or CMake. So using ninja is really an orthogonal discussion to the single build system discussion for WebKit. :) Were the WebKit project to convert to using a single meta-build system, ninja would become an option many users might choose. I'm told most Chromium hackers have GYP set to output ninja files these days, with the exception of some folks who still want the MSVC build environment. For WebKit ports already using CMake, they should definitely try ninja today! Anyway, my wish was not about arguing for a specific build solution. I'm instead noting that for the project to continue to move quickly, we need to stop needing to edit 8 build systems for every file move/addition. Whether that's GYP or CMake or something else, I don't really care. Adam and I tried GYP-for-WebKIt a while back. But any of these solutions will require buy-in from Apple, as they will have to do the largest amount of work converting to use something other than XCode. On Sat, Feb 2, 2013 at 8:20 PM, Nico Weber tha...@chromium.org wrote: On Sat, Feb 2, 2013 at 4:58 PM, Adam Barth aba...@webkit.org wrote: Ninja has extremely fast incremental builds and can be generated by GYP. Here are some stats from a year ago: https://plus.google.com/101038813433650812235/posts/irc26fhRtPC Ninja has gotten even faster since then. If you're interested in trying it out, you can play around with incremental builds of the Chromium port on Mac or Linux. You can also look at the build output from the chromium bots. Empty build in 1s: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66807/steps/compile-webkit/logs/stdio Build with a few files changed in 15s: http://build.webkit.org/builders/Chromium%20Linux%20Release/builds/66800/steps/compile-webkit/logs/stdio …and this is on fairly slow bots. On my SSD-equipped laptop, I can do incremental rebuilds of all of chrome after touching one (cpp or mm) file in 2-6s. Adam On Fri, Feb 1, 2013 at 4:58 PM, Balazs Kelemen kbal...@webkit.org wrote: I think one important aspect of build systems was not considered yet int this conversation: speed. The time an incremental build takes has a great effect on developer productivity. I don't think any of the meta-build systems we use does a great job here - although I only have experiences with qmake, cmake and autotools (and I don't have an SSD that could help somewhat). The technic I found useful here is to avoid calling build-webkit always and instead just rebuild the subproject you have edited, so I think it is important to have a build system that supports it. Let me share my experiences here. With qmake nowadays this work perfectly. The developer build is producing a shared library for every subdir (WTF, JavaScriptCore, WebCore, WebKit2), which means you only need to call make in the specific subdirectory (i.e. if I only touched WebKit2 files I do make -C WebKitBuild/Release/Source/WebKit2 which is pretty quick). Still WebCore is so big that make is quite slowly find out the files you actually edited and need to be rebuilt. What could help here is to devide WebCore into smaller parts, like the ongoing work of extracting Platform. Maybe the next logical candidate could be svg (I don't have real knowledge about how feasible it is). Note that I don't come up with qmake because I would like to recommend it as the one and only build system (in fact it has a ridiculously inconvenient syntax, and a lot of bugs), just as an example. With Cmake fast incremental rebuilds are also possible, maybe in a bit more complicated way. When working with the EFL port I found a quick rule for WebKit2 in the generated makefile. Although the makefiles are usually call back to Cmake, and make is not faster than build-webkit, if you use the special fast target, which is something like eflWebKit/fast (i.e. make -C WebKitBuild/Release/Source/WebKit2 eflWebKit/fast), it will not check dependencies but just rebuild the files that have changed. I did not find a similar thing for WebCore, I guess because it is not built as a shared library. What I dislike in Cmake is that I am disappointed by how slow a normal incremental build with it (i.e. build-webkit). qmake is not faster at all, but it generate plain makefiles that typically no call back to qmake if not specified explicitly to do so, and directly calling make is faster, yet it can handle most of the non-trivial changes, for example editing a generator file. I don't know gyp, so I wonder about how would it do in this comparison (but I guess it generates simple makefiles as well, so it's similar than qmake in this manner.) I hope I added something to this conversation that is worth to consider with my late nightly brain dump. -kbalazs
Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))
What I've learned from this thread, is that AppleWin and AppleMac are the only two ports which require lists of exported symbols. If both were to convert to using EXPORT decorators instead, then we could remove needs for fixing export lists. Please correct me if I've misunderstood. Other ports (including GTK), it seems need an internals-specific export macro, in order to export window.internals necessary symbols from their WebKit dynamic library. I believe this is true of all ports (with the possible exception of Chromium). On Thu, Jan 31, 2013 at 5:55 PM, Martin Robinson mrobin...@webkit.orgwrote: On Thu, Jan 31, 2013 at 5:39 PM, Ryosuke Niwa rn...@webkit.org wrote: Doesn't GTK+ port also require symbol exports for WebKit2? In particular, I thought all symbols used in Internals need to be exported there. WebKitGTK+ does not need to export symbols from WebCore for WebKit2, because WebCore is built as a static convenience library. We do need to export symbols for the Internals library because it's built as a separate object that links against libwebkitgtk. Adding an export macro for Internals would be great for us, since we wouldn't have to export so many symbols via Source/autotools/symbols.filter. It would also decrease the maintenance burden for non-GTK+ port contributors. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))
I should have been more clear. By which require lists of exported symbols, I meant which require lists of exported symbols for WebCore. The Internals discussion is obviously about WebCore symbols which are exported through WebKit as well. It seems no other symbols from WebCore should ever be exported from WebKit on any port besides Internals symbols. On Sat, Feb 2, 2013 at 10:23 PM, Eric Seidel e...@webkit.org wrote: What I've learned from this thread, is that AppleWin and AppleMac are the only two ports which require lists of exported symbols. If both were to convert to using EXPORT decorators instead, then we could remove needs for fixing export lists. Please correct me if I've misunderstood. Other ports (including GTK), it seems need an internals-specific export macro, in order to export window.internals necessary symbols from their WebKit dynamic library. I believe this is true of all ports (with the possible exception of Chromium). On Thu, Jan 31, 2013 at 5:55 PM, Martin Robinson mrobin...@webkit.orgwrote: On Thu, Jan 31, 2013 at 5:39 PM, Ryosuke Niwa rn...@webkit.org wrote: Doesn't GTK+ port also require symbol exports for WebKit2? In particular, I thought all symbols used in Internals need to be exported there. WebKitGTK+ does not need to export symbols from WebCore for WebKit2, because WebCore is built as a static convenience library. We do need to export symbols for the Internals library because it's built as a separate object that links against libwebkitgtk. Adding an export macro for Internals would be great for us, since we wouldn't have to export so many symbols via Source/autotools/symbols.filter. It would also decrease the maintenance burden for non-GTK+ port contributors. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Wishes
On Wed, Jan 30, 2013 at 1:50 PM, Filip Pizlo fpi...@apple.com wrote: Thanks for sharing this. On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote: I wish we only had one build system (it were easy to add/remove/move files). I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. +1 This is a hard problem. It is a problem worth solving. Do you have more thoughts on this, particularly since you know quite well how both Xcode and gyp work? I suspect this is one of those things that it would be hard to achieve consensus on since there are so many stakeholders. But it may be fruitful to have a what if discussion about what this might look like. This has broken off into a separate thread. If I were king of the project, I would declare GYP as the one-true solution, not because I like GYP, but because it has solved the problem for 50% of WebKit developers, and seems reasonable for solving it for the other 50%. I'm not king :) and thus would not wish to decree any specific solution. I think what really matters here is what multi-port solution Apple believes they could use. It's possible for Chromium to move away from GYP. I don't personally care too much what meta-build system we end up using, so long as we end up with one. I do not think that a script to add/move/remove files/folders is a very robust solution, unfortunately. Leaving a meta-build system as the only obvious option in my mind. I wish I felt like reviewers understood/trusted each other more. I’ve worked at both Apple and Google. The WebKit community is full of brilliant engineers. Yet I frequently feel a lack of trust in my (or others) judgement, or witness hot-headed remarks on bugs, lists or IRC. I don’t think it’s that people don’t trust me after nearly 8 years (!?) on this project, but rather that we forget, or fail to communicate trust among ourselves. Social problems are perhaps harder to solve for us technical types, but I worry that for many of us it’s just become “us” and “them” and we’ve stopped trying. I wish it were easy to work on feature branches. We have no good solution for features. For one-patch features, you do them on your own. For larger, you maybe use github or most likely you just land on trunk behind a #define. None of these have worked well. Some of this is the limits of SVN, but it should be trivial for someone to work on a new feature a long time, w/o endangering trunk or having massive merge pain every day. Other projects can do this. So should we. This is both impeding progress, and destabilizing trunk. I've done this for JSC JIT optimization work before, and I think it worked quite well. The pain of merging the branch back into trunk was bad, but the reward was that I had ~2 months of time where I didn't have to worry about breaking other people's junk. Merging only took a week. One week of pain in return for 2 months of bliss? I'll take that. Certainly. I much prefer to work on branches. Our current lack of official branching solution (and tools) has left everyone to go their own. When I use GitHub for branching it feels like a very private fork. It's difficult for the rest of the project to know about or follow my work. Meaning that it's easy for me to go off into the crazy-weeds the longer I'm out on my own branch. :) Some of this is risks intrinsic with branching. But imagine a world in which every bug fix was its own branch? Imagine a world where branches were merged into trunk instead of committed as patches? Some of this is crazy-talk, I understand. :) But I think we can do better than our current tooling/process. :) I concur that we can do better on this. I would especially love to see feature branching and merging follow a review process as if it were on trunk. Creating a branch involves a bug and a review. Patches that land on the branch are reviewed. Merging is either reviewed or rubber stamped. Correct! Having branching always be off somewhere else is OK, but lacks the connection to the rest of the project (and the review process). I wish we didn’t have to worry about platforms we couldn’t test. It can’t be the job of the core maintainers to care about all the peripheral ports which contribute very little core code. Our code needs to be structured in such a manner that its easy for the core to march forward, while letting the ports catch up as they need to asynchronously. Platform support code shouldn’t even need to be in webkit.org! Porting webkit.org’s platform abstractions should be trivial, but core developers (which probably 90% of them use only 2 ports Mac
Re: [webkit-dev] WebKit Wishes
On Wed, Jan 30, 2013 at 1:57 PM, Maciej Stachowiak m...@apple.com wrote: Hi Eric, These are great thoughts. I agree with you on all points. One informative comment below: On Jan 30, 2013, at 1:28 PM, Eric Seidel e...@webkit.org wrote: I wish we only had one build system (it were easy to add/remove/move files). I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. I wish I felt like reviewers understood/trusted each other more. I’ve worked at both Apple and Google. The WebKit community is full of brilliant engineers. Yet I frequently feel a lack of trust in my (or others) judgement, or witness hot-headed remarks on bugs, lists or IRC. I don’t think it’s that people don’t trust me after nearly 8 years (!?) on this project, but rather that we forget, or fail to communicate trust among ourselves. Social problems are perhaps harder to solve for us technical types, but I worry that for many of us it’s just become “us” and “them” and we’ve stopped trying. I wish it were easy to work on feature branches. We have no good solution for features. For one-patch features, you do them on your own. For larger, you maybe use github or most likely you just land on trunk behind a #define. None of these have worked well. Some of this is the limits of SVN, but it should be trivial for someone to work on a new feature a long time, w/o endangering trunk or having massive merge pain every day. Other projects can do this. So should we. This is both impeding progress, and destabilizing trunk. I wish we didn’t have to worry about platforms we couldn’t test. It can’t be the job of the core maintainers to care about all the peripheral ports which contribute very little core code. Our code needs to be structured in such a manner that its easy for the core to march forward, while letting the ports catch up as they need to asynchronously. Platform support code shouldn’t even need to be in webkit.org! Porting webkit.org’s platform abstractions should be trivial, but core developers (which probably 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to worry about keeping all ports working. I wish that the tree always built and tested cleanly. Other (much larger) projects than WebKit accomplish this. Yet somehow Google pays 2 full-time engineers to watch our bots and yet we fail. I know other companies do similar. Automated rollouts is one solution. Branched-based development, or trybots are others. But at the size and scale we’re at now, every minute of a broken tree, is 100x or more minutes of potentially lost developer productivity. I wish I felt like I could follow what was going on (and trust WebKit to guard the web, instead of depending on Apple or Google). We’re the leading browser engine, with hundreds of committers, any of whom can add an API to 50% of internet browsers with a single commit. I wish we had a public process for feature/web-api review. I wish I felt like both major companies were willing participants in such. (Google has an internal process, but it sees limited use, in part because it’s powerless -- a ‘yes’ from our process is not a ‘yes’ from WebKit.) I want to feel like I can better observe and participate in the development of our web-api (and trust that it’s being done well!) without scanning every changeset just to be able to comment post-facto. (This is also reflected in the fact that the features enabled by the major Apple or Google ports are wildly different, with seemingly little rhyme or reason.) I wish WebCore was not trapped by Mac WebKit1’s legacy designs. WebKit2 is obviously a step towards the future. But until we can kill the Widget tree, the insanely fragile loader complexity, and the limits imposed by the least-common-denominator on classes like ResourceRequest, we’re still trapped in the past. One of the things I’ve learned in working on Chromium, is that we were wrong many years ago to fold our platform abstraction (Qt-implementation) and khtml into one library. In a sand-boxed multi-process world, the rendering library is just a hunk of code running the same on every platform. And platform code has no place in our core engine code (aka WebCore). In designing WebKit2, we tried to avoid some mistakes in the WebKit1 Mac API design (such as exposing the underlying network library, exposing our NSView hierarchy as part of the API, and giving too much salience to frames). While we can't remove those parts of the API entirely, if we get more Mac API clients onto WebKit2, then the performance of these details of the WK1 API becomes less
Re: [webkit-dev] WebKit Wishes
On Wed, Jan 30, 2013 at 2:11 PM, Xan Lopez x...@gnome.org wrote: Hi Eric, On Wed, Jan 30, 2013 at 10:28 PM, Eric Seidel e...@webkit.org wrote: I wish we didn’t have to worry about platforms we couldn’t test. It can’t be the job of the core maintainers to care about all the peripheral ports which contribute very little core code. Our code needs to be structured in such a manner that its easy for the core to march forward, while letting the ports catch up as they need to asynchronously. Platform support code shouldn’t even need to be in webkit.org! Porting webkit.org’s platform abstractions should be trivial, but core developers (which probably 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to worry about keeping all ports working. I agree this is a hard problem. Also a stressful situation to get oneself into. Coming up with ways to allow port code to survive core changes would be excellent for everyone, even for the small ports people who hack on the core and also cannot easily test Mac WK2, Chromium Linux or any other port. I write less out of pain, and more out of hope for the future. I believe all of these are solvable problems, but I believe we need the will to solve them. Apple’s recent announcement of WebKit2 lockdown is clearly one attempt at some of these. But for the other 50% of WebKit developers who don’t work on WebKit2, locking down WebCore is not a good solution. I agree the WebKit2 lockdown is one attempt at solving this, but hopefully we can agree it's not a particularly innovative one. Breaking builds and allowing bugs to pile up while they are fixed is a nasty situation, one that historically we have tried really hard to avoid for very well known reasons. I understand in the final analysis allowing the core to move fast could be more important than having an healthy ecosystem of minor ports without huge teams behind them, but I really hope that this is only a temporary solution and that in the future we'll be able to find better solutions like those that you suggest in your email. Also, on a personal note, I've been around for enough years to remember the time when people trying to get ports started were eagerly welcomed by Apple employees, who would go out of their way to help us get started, review our patches when we had no reviewers in our team, patiently explain this or that part of the code, etc. I made sure to tell everyone I knew that WebKit was one of the most well managed open source projects in existence, one of those rare combinations of success and fidelity to some of the best values that open source supposedly represents. It is with a bit of sadness that years later I find that the same project (even the same people) now has a very different attitude, and that long term contributors who I believe have modestly helped to make this project more robust and popular are mostly seen as part of a problem instead of as part of its thriving community. I suppose wild success has some unfortunate costs. I would like to say that I agree with you. I also have been around long enough to remember days of helping new ports come to WebKit. :) And I would argue that our current situation is all our own fault. We've provided ports poor APIs to port with. WebCore/platform is nice, but as I've learned from Chromium, it's *way* too low a level to hook into. I believe that for WebCore/WebKit to be long-term successful, that WebCore needs to know *nothing* about the platform that it's running on. That it should be completely abstracted from the outside world. Right now we're no where close to that, and thus any major change in WebCore requires changes and testing on all of our ports. If WebCore had only one true-way to talk to the outside world, than I believe we'd have a much easier time making large architectural changes, and I believe that individual porting communities would have a much easier time of maintaining their builds/tests. In any case, I don't want to end on a pessimistic note. I'm sure there's enough brilliance in this community to come up with better solutions for everyone, including future ports that do not exist yet but that might be very relevant in this world that moves at breakneck pace. Cheers, Xan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Wishes
On Wed, Jan 30, 2013 at 3:24 PM, Patrick Gansterer par...@paroga.com wrote: Hi, Am 30.01.2013 um 22:28 schrieb Eric Seidel: I wish we only had one build system (it were easy to add/remove/move files). I've created CMake files for two different ports at [1] and [2] already, but did't get positive feedback from the port-maintainer. So I stopped working on it. If any port is still interested in switching to CMake I'd like to help creating the required files, but only with feedback of the port-maintainer. The only solution which matters is one which gets AppleMac to move. Apple Mac WK2 accounts for a large portion of developers/reviewers, and is also by far the hardest build system to edit. -- Patrick [1] https://bugs.webkit.org/show_bug.cgi?id=72816 [2] https://bugs.webkit.org/show_bug.cgi?id=73100 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit Wishes
On Thu, Jan 31, 2013 at 4:16 AM, Alexis Menard ale...@webkit.org wrote: On Wed, Jan 30, 2013 at 6:28 PM, Eric Seidel e...@webkit.org wrote: I wish we only had one build system (it were easy to add/remove/move files). I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. I wish I felt like reviewers understood/trusted each other more. I’ve worked at both Apple and Google. The WebKit community is full of brilliant engineers. Yet I frequently feel a lack of trust in my (or others) judgement, or witness hot-headed remarks on bugs, lists or IRC. I don’t think it’s that people don’t trust me after nearly 8 years (!?) on this project, but rather that we forget, or fail to communicate trust among ourselves. Social problems are perhaps harder to solve for us technical types, but I worry that for many of us it’s just become “us” and “them” and we’ve stopped trying. I wish it were easy to work on feature branches. We have no good solution for features. For one-patch features, you do them on your own. For larger, you maybe use github or most likely you just land on trunk behind a #define. None of these have worked well. Some of this is the limits of SVN, but it should be trivial for someone to work on a new feature a long time, w/o endangering trunk or having massive merge pain every day. Other projects can do this. So should we. This is both impeding progress, and destabilizing trunk. I wish we didn’t have to worry about platforms we couldn’t test. It can’t be the job of the core maintainers to care about all the peripheral ports which contribute very little core code. Our code needs to be structured in such a manner that its easy for the core to march forward, while letting the ports catch up as they need to asynchronously. Platform support code shouldn’t even need to be in webkit.org! Porting webkit.org’s platform abstractions should be trivial, but core developers (which probably 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to worry about keeping all ports working. Sure. I'm wondering how you would define a peripheral port? Anything not Apple or Google? I guess I would go the other way and define some sort of kernel ports which should never be broken by a patch. Those ports are defined as the ones which added-up account for 90% or 80% or something of WebCore developers. The idea here is not one of exclusion, but rather one of productivity. We need to keep our WebCore developers as productive as possible, so we should not break their builds, but they shouldn't need to worry about breaking uncommon builds. As I've said in other mails, this is *completely our fault*. And by our I mean all of us who were around 6 years ago when we designed the porting layer. I think we didn't understand then how exposing the details of a port into WebCore would bind us. We can have our cake and eat it too! We can have lots of ports and yet never have to care about them (and never have them break!). But I don't believe we can do that with current WebCore designs, where WebCore knows intimate details about each port. :( In my dream WebCore would not have a single PLATFORM() #if. Many little ports are very active every day, sure some of them does not contribute as much as they should on common parts but some companies behind these are just limited on resources. They are not Google or Apple with an army of engineers who have time to take any spec of W3C and implements it. Agreed! In WebCore the contribution is pain mostly because the buildsystem. For the rest if EWS goes red, in many cases it's a real bug, a real problem. Coming from a so called peripheral port I find very frustrating and demotivating that our contributions are devalorized the way they are or our reviews discredited. Many of us contributes important feature and improvements to WebCore and sure not as visible as Google or Apple in terms of log but still crucial or important. I can only imagine. I wish it were easier for you, not harder. :( I believe you and many people are not aware what little ports contribute because we don't work on high visibility feature such as Regions, Grid, FooBar W3C API. We do improve W3C compliance (CSS, XHR, media queries, viewport interactions, @viewport rule, various work on tests infrastructure, WebGL fixes) and I'm talking only of the people in my company and I'm probably forgetting some work. The number of contributions per day makes hard for me to see what others than Google or Apple are doing. Oh, I'm quite aware. :) Depending on how you count commits, lines of code, etc. some very
Re: [webkit-dev] Exporting symbols (was Re: Common build system (was Re: WebKit Wishes))
I believe that it's a design mistake for WebCore to need to know anything about it's embedder, more than that there is a defined set of platform APIs and callbacks which it talks to (which should be the exact same for every embedder). (The export dependency dates back to the WebCore/WebKit separation, which in my recollection was done largely to be able to isolate LGPL code from the non-LGPL Mac WebKit layer.) But I believe it is a mistake that WebCore changes need to care about the possibility that different ports may export functions differently, or even worse, that different ports may need a different set of functions exported. I don't recommend using a more complicated export macro, but rather finding ways that WebCore doesn't need to care about diverging sets of exports. I believe most ports (with the exception of AppleWin/AppleMac) do not build WebCore as a separate dynamic library from WebKit, which makes exports a non-concern in the static case. In my perfect future world, WebCore would be split into many static libraries, and core-code - WebKit exports would be a non-issue. And of course, no embedder of core-code would ever expose core types, so no exports would ever need to be marked. On Thu, Jan 31, 2013 at 3:38 PM, Alexey Proskuryakov a...@webkit.org wrote: 31.01.2013, в 15:15, Dirk Pranke dpra...@chromium.org написал(а): I don't have concrete examples, and I don't know how big an effect on performance increasing the number of exports would have. It's something to keep an eye on, not a reason to avoid trying. I'm not parsing your reply properly -- avoid trying what? A common EXPORT macro that is set as appropriate by each port? Yes, you are parsing it correctly :) - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] WebKit2/Mac and C++11
The future! Is now! :) Very exciting. I hope some day we can use C++11 for the rest of WebCore too. On Wed, Jan 30, 2013 at 12:17 PM, Anders Carlsson ander...@apple.com wrote: Hello! This is just a friendly heads-up that the Mac specific parts of WebKit2 will soon start requiring C++11 features (move semantics and variadic templates being the two most important). Any recent version of Xcode (4.2 or later) should support this, and we're already building all of WebKit2 as C++11 on Mac anyway. - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] WebKit Wishes
*I wish we only had one build system (it were easy to add/remove/move files).* * I believe changes like http://trac.webkit.org/changeset/74849 are an unhealthy sign for the project. Adam is not the only person who has chosen to empty files instead of removing them. The pain of updating 8 build system is so great, we jump through hoops to avoid it. Which means it took us months to move JavaScriptCore/wtf to WTF, and will take us years to kill WebCore/platform. I wish I felt like reviewers understood/trusted each other more. * *I’ve worked at both Apple and Google. The WebKit community is full of brilliant engineers. Yet I frequently feel a lack of trust in my (or others) judgement, or witness hot-headed remarks on bugs, lists or IRC. I don’t think it’s that people don’t trust me after nearly 8 years (!?) on this project, but rather that we forget, or fail to communicate trust among ourselves. Social problems are perhaps harder to solve for us technical types, but I worry that for many of us it’s just become “us” and “them” and we’ve stopped trying. I wish it were easy to work on feature branches. * *We have no good solution for features. For one-patch features, you do them on your own. For larger, you maybe use github or most likely you just land on trunk behind a #define. None of these have worked well. Some of this is the limits of SVN, but it should be trivial for someone to work on a new feature a long time, w/o endangering trunk or having massive merge pain every day. Other projects can do this. So should we. This is both impeding progress, and destabilizing trunk. I wish we didn’t have to worry about platforms we couldn’t test. * *It can’t be the job of the core maintainers to care about all the peripheral ports which contribute very little core code. Our code needs to be structured in such a manner that its easy for the core to march forward, while letting the ports catch up as they need to asynchronously. Platform support code shouldn’t even need to be in webkit.org! Porting webkit.org’s platform abstractions should be trivial, but core developers (which probably 90% of them use only 2 ports Mac WK2 + Chromium Linux) shouldn’t need to worry about keeping all ports working. I wish that the tree always built and tested cleanly. * *Other (much larger) projects than WebKit accomplish this. Yet somehow Google pays 2 full-time engineers to watch our bots and yet we fail. I know other companies do similar. Automated rollouts is one solution. Branched-based development, or trybots are others. But at the size and scale we’re at now, every minute of a broken tree, is 100x or more minutes of potentially lost developer productivity. I wish I felt like I could follow what was going on (and trust WebKit to guard the web, instead of depending on Apple or Google). * *We’re the leading browser engine, with hundreds of committers, any of whom can add an API to 50% of internet browsers with a single commit. I wish we had a public process for feature/web-api review. I wish I felt like both major companies were willing participants in such. (Google has an internal process, but it sees limited use, in part because it’s powerless -- a ‘yes’ from our process is not a ‘yes’ from WebKit.) I want to feel like I can better observe and participate in the development of our web-api (and trust that it’s being done well!) without scanning every changeset just to be able to comment post-facto. (This is also reflected in the fact that the features enabled by the major Apple or Google ports are wildly different, with seemingly little rhyme or reason.) I wish WebCore was not trapped by Mac WebKit1’s legacy designs. * *WebKit2 is obviously a step towards the future. But until we can kill the Widget tree, the insanely fragile loader complexity, and the limits imposed by the least-common-denominator on classes like ResourceRequest, we’re still trapped in the past. One of the things I’ve learned in working on Chromium, is that we were wrong many years ago to fold our platform abstraction (Qt-implementation) and khtml into one library. In a sand-boxed multi-process world, the rendering library is just a hunk of code running the same on every platform. And platform code has no place in our core engine code (aka WebCore). I write less out of pain, and more out of hope for the future. I believe all of these are solvable problems, but I believe we need the will to solve them. Apple’s recent announcement of WebKit2 lockdown is clearly one attempt at some of these. But for the other 50% of WebKit developers who don’t work on WebKit2, locking down WebCore is not a good solution. I think we need to work together to bring about some of these dreams, for the short and long term health of the WebKit project. Thank you for listening. * ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Enabling unprefixed CSS Transitions by default.
Thank you for sharing! It appears that unless you're logged into WordPress (I had to go dig up my credentials) you just get a 404. On Tue, Jan 29, 2013 at 6:17 PM, Dean Jackson d...@apple.com wrote: Related: when the unprefixed transitions are enabled by default, we plan to make a long-overdue blog post on Recent Updates to Transitions and Animations where recent means about 2 or 3 years :) http://www.webkit.org/blog/?p=2233preview=true The idea is that it would cover all the interesting things we've added, even if we think most people know about them. Feel free to edit the draft (if that's possible - otherwise email me), especially if there are features we've forgotten. Dean On 30/01/2013, at 8:03 AM, Alexis Menard ale...@webkit.org wrote: Hi, Last month I started working on supporting unprefixed CSS Transitions in WebKit. Today this work is guarded behind CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED enabled by default in trunk (but disabled in Chrome and probably release branches of other ports). After various patches we (Dean Jackson and myself) feel confident that the work on the transitions is ready for prime time. We still have bugs open in our bug tracker but that doesn't block the unprefixed version to go live. So the proposal is the following one : - Rename CSS_TRANSFORMS_ANIMATIONS_TRANSITIONS_UNPREFIXED to CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED to cover the future work for unprefixing the animations and the transforms (that I plan to focus after this). - Ship CSS Transitions unprefixed enabled by default with no feature flag to disable it. My proposal is tracked here : https://bugs.webkit.org/show_bug.cgi?id=108216 We can also be proud to say our implementation is maybe the most complete one (thanks to the various people involved). On a side note the usage of prefixed/unprefixed version is monitored through the FeatureObserver so we can later in the future have an idea of the usage and maybe remove the prefixed support. Thoughts? Patched landed : http://trac.webkit.org/changeset/141119 http://trac.webkit.org/changeset/140560 http://trac.webkit.org/changeset/140448 http://trac.webkit.org/changeset/140010 http://trac.webkit.org/changeset/139922 http://trac.webkit.org/changeset/139762 http://trac.webkit.org/changeset/139200 http://trac.webkit.org/changeset/139106 http://trac.webkit.org/changeset/139070 http://trac.webkit.org/changeset/138728 http://trac.webkit.org/changeset/138721 http://trac.webkit.org/changeset/138184 Thanks. -- Software Engineer @ Intel Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] build.webkit.org down
I'm surprised that chromium mac is 3x the size of Apple Mac... debug even! Chromium build output should be much smaller... at least as of late. On Fri, Jan 25, 2013 at 9:30 AM, William Siegrist wsiegr...@apple.com wrote: Here are the largest results sets on the master in GB. We currently store 6.8TB of total results, going back 14 months, and 1.1TB of archives going back 1 week. 1500Apple MountainLion (Leaks) 1018Chromium Mac Release (Tests) 857 Chromium Linux Release (Tests) 532 Chromium Win Release (Tests) 371 Apple MountainLion Debug WK2 (Tests) 324 Apple Lion Debug WK2 (Tests) 299 Chromium Linux Release (Grid Layout) 173 GTK Linux 64-bit Release 171 Chromium Android Release (Tests) 160 EFL Linux 64-bit Debug WK2 158 Apple Lion (Leaks) 145 EFL Linux 64-bit Release 113 EFL Linux 64-bit Debug 105 GTK Linux 32-bit Release 94 GTK Linux 64-bit Debug 94 GTK Linux 64-bit Release WK2 (Tests) 85 EFL Linux 64-bit Release WK2 80 Apple Lion Release WK1 (Tests) 77 Apple Lion Release WK2 (Tests) 60 Apple Lion Debug WK1 (Tests) 60 Apple MountainLion Debug WK1 (Tests) 59 Apple MountainLion Release WK1 (Tests) 53 Qt Linux Release Archives are already pruning after 1 week. Next week, I'm going to start pruning results older than 14 months since we don't have much more space. If anyone thinks you need more than 14 months of results, let me know soon and we can see what our options are. -Bill ___ 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] Do any ports still disable SVG?
This question came up in: https://bugs.webkit.org/show_bug.cgi?id=92393 Do any ports still disable SVG? Should we be removing the ENABLE_SVG defines (and potentially unifying SVG and HTML style resolve more closely)? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Can't upload patch
Sorry. webkit-patch upload does not have very good error handling: https://bugs.webkit.org/show_bug.cgi?id=72863 On Thu, Jan 17, 2013 at 10:49 AM, Raymond Toy r...@google.com wrote: Hmm. I have a git checkout of webkit so svn-create-patch doesn't want to work. Yeah, the patch is probably too big. The particular patch could be broken up into 3-4 separate smaller patches. Perhaps that will work. On Thu, Jan 17, 2013 at 9:52 AM, Adam Barth aba...@webkit.org wrote: Have you tried uploading the patch manually by running svn-create-patch and using the attachments UI in bugs.webkit.org? One possibility is that your patch is too big for bugs.webkit.org to handle. You mention that it contains a number of binary files, which might be the cause of the problem. Adam On Thu, Jan 17, 2013 at 9:43 AM, Raymond Toy r...@google.com wrote: I'm trying to upload a patch and webkit-patch upload appears to do everything except actually add the patch to the bug. I first ran webkit-patch upload and it correctly created the bug (https://bugs.webkit.org/show_bug.cgi?id=106955) for me, but didn't upload the patch. When I run webkit-patch upload again, it correctly shows the diff, which consists of a a change to TestExpectations and several binary files. It says it adding the patch, but when I look at the bug, there's no patch. I'm missing something, but I don't know what it is. I've uploaded patches before, so I know it used to work. :-( Any suggestions? Ray ___ 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] EWS commenting about ancient patches
I believe the queue was actually cleared when they were brought online. As Ossy notes, this is expected behavior. Every time the feeder queue boots up (which is every 2 hours), it sends *all* patches marked for review to queues.webkit.org. queues.webkit.org makes sure that each individual EWS queue has either has a result for each patch, or adds it to each individual queue. Since there are some ancient patches still marked r?, new queues will process ancient patches. :) (The feeder-queue is then smart enough to keep an in-memory list of what it's sent to queues.webkit.org, so it only send incremental lists until it restarts itself again in 2 hours.) -eric On Thu, Jan 17, 2013 at 11:43 AM, Ryosuke Niwa rn...@webkit.org wrote: Sorry, that's my fault. I added Mac-WK2 EWS to the EWS queue much earlier than we added bots. So we ended up having 1000+ backlogs of patches. As Ossy points out, Mac WK2 EWS bots have caught up with patches so this shouldn't be a problem in the future. - R. Niwa On Thu, Jan 17, 2013 at 8:40 AM, Alexey Proskuryakov a...@webkit.org wrote: On several occasions over the last few days, I noticed EWS commenting in bugs that didn't have any recent activity, e.g. https://bugs.webkit.org/show_bug.cgi?id=87527. Is EWS picking ancient patches, or is it posting comments to wrong bugs? - WBR, Alexey Proskuryakov ___ 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] EWS commenting about ancient patches
That seems totally reasonable, and simple to implement: https://bugs.webkit.org/show_bug.cgi?id=107152 On Thu, Jan 17, 2013 at 11:55 AM, Adam Barth aba...@webkit.org wrote: Maybe we shouldn't bother feeding the bots patches that are over a certain age (perhaps a week)? Adam On Thu, Jan 17, 2013 at 11:50 AM, Eric Seidel e...@webkit.org wrote: I believe the queue was actually cleared when they were brought online. As Ossy notes, this is expected behavior. Every time the feeder queue boots up (which is every 2 hours), it sends *all* patches marked for review to queues.webkit.org. queues.webkit.org makes sure that each individual EWS queue has either has a result for each patch, or adds it to each individual queue. Since there are some ancient patches still marked r?, new queues will process ancient patches. :) (The feeder-queue is then smart enough to keep an in-memory list of what it's sent to queues.webkit.org, so it only send incremental lists until it restarts itself again in 2 hours.) -eric On Thu, Jan 17, 2013 at 11:43 AM, Ryosuke Niwa rn...@webkit.org wrote: Sorry, that's my fault. I added Mac-WK2 EWS to the EWS queue much earlier than we added bots. So we ended up having 1000+ backlogs of patches. As Ossy points out, Mac WK2 EWS bots have caught up with patches so this shouldn't be a problem in the future. - R. Niwa On Thu, Jan 17, 2013 at 8:40 AM, Alexey Proskuryakov a...@webkit.org wrote: On several occasions over the last few days, I noticed EWS commenting in bugs that didn't have any recent activity, e.g. https://bugs.webkit.org/show_bug.cgi?id=87527. Is EWS picking ancient patches, or is it posting comments to wrong bugs? - WBR, Alexey Proskuryakov ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Changing Github repository to mirror git.webkit.org (was Github vs. git.webkit.org)
Yes, but I'm more interested in rebasing my existing github branches. :) But you're right, I could probably run Tools/Scripts/sync-master-with-upstream from my existing git.webkit.org checkout and not have to download anything. I'd still have a bunch of github branches which I can't easily rebase on top of that, but that's a start. On Thu, Jan 17, 2013 at 4:00 AM, Dominik Röttsches dominik.rottsc...@intel.com wrote: On 01/16/2013 10:07 PM, Eric Seidel wrote: Do we know if there is a way to re-write our existing forks w/o pulling the whole repo down, just to push it back up again? If you make the new github mirror fork a remote for your existing git.webkit.org clone and push from there you would only need to push a small amount - at least that's how it worked for me. Dominik ___ 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] Changing Github repository to mirror git.webkit.org (was Github vs. git.webkit.org)
Do we know if there is a way to re-write our existing forks w/o pulling the whole repo down, just to push it back up again? :) On Wed, Jan 16, 2013 at 11:51 AM, Adam Barth aba...@webkit.org wrote: If you were using GitHub to contribute to WebKit previously, you might want to delete your fork of https://github.com/WebKit/webkit and re-fork https://github.com/WebKit/webkit. It's also possible to push a force update to your repository that re-writes the hashes, but I found that re-forking was easier. Adam On Wed, Jan 16, 2013 at 4:55 AM, Jesus Sanchez-Palencia je...@webkit.org wrote: Hi, The mirror is finally ready again: https://github.com/WebKit/webkit It now follows the same hashes of git.webkit.org. People who have forked this repository on github before will now have to rebase their branches. I was hold back a bit because Github wasn't allowing me to push more than 2GB. I contacted them but before I could get answer I decide to 'split' the push. First I git reset --hard the repository back to a commit from 2008, pushed this, then reset --hard to 2009 and pushed this, and so on. In the middle of the process the folks from github increased our push limit to 20GB and David (barrbrain) was kind enough to push one last sync, getting us back to 2012. After that I kept the syncing manullay for a few hours but now the repository is being updated automatically every 5 minutes to stay in sync with git.webkit.org . I will now coordinate with William so we can get Apple pushing to the mirror at the same time they push to git.webkit.org . Thanks everyone that got involved for the help! Cheers, jesus 2013/1/14 Jesus Sanchez-Palencia je...@webkit.org: Hi, Just yet another quick heads-up: 2013/1/14 Jesus Sanchez-Palencia je...@webkit.org: We have decided that the best approach for this is to start a new repository (webkit-mirror), delete the old one (https://github.com/WebKit/webkit) and then rename the new repository. I had to change my strategy here after talking to a few people on #github. It seems that doing a git push -f to the current repository (https://github.com/WebKit/webkit) will actually have less impact on people branching/forking it on github. In other words, it should be less painful to rebase your fork on github for the new hashes after I'm done with the setup. I will let you know when the switching is done. Cheers, jesus I will be doing the mirroring myself for while, until Apple can set this up from the same machine that git pushes to git.webkit.org. People that are using the current github repository will probably have to re-clone and rebase their branches. This won't affect git.webkit.org or any other official WebKit repository. Cheers, jesus 2012/12/11 Jesus Sanchez-Palencia jesus.palen...@openbossa.org: Hi, 2012/12/4 Tor Arne Vestbø tor.arne.ves...@digia.com: Bill, what do you think about pushing the official SVN import to GitHub as well? tor arne Any updates about this? Cheers, jesus So we might be able to rename the existing one and ask github to pull our git.webkit.org http://git.webkit.org repository into github/WebKit/webkit. Apparently Apache takes that way: https://github.com/apache The mirroring icon indicates kind of official-ness. I don't know how long their mirroring delay is, though. On Sat, Dec 1, 2012 at 12:07 AM, Tor Arne Vestbø tor.arne.ves...@digia.com mailto:tor.arne.ves...@digia.com wrote: On 11/28/12 16:55 , Adam Barth wrote: My sense is that the WebKit community would prefer that the hashes in GitHub match the hashes in git.webkit.org http://git.webkit.org so that folks can more easily move branches between the two. For my part, I've switched over to using GitHub exclusive of git.webkit.org http://git.webkit.org, so the the difference in hashes aren't an issue for me, but I can understand why they'd be problematic for other people. Yepp, agreed. Let's switch it over. After the force-push, would you still be able to push updates automatically? If so, you can switch the hashes whenever is convenient for you. (It might be nice to announce the date/time on this list so that folks aren't taken by surprise.) The mirror is also pushed to http://gitorious.org/webkit/__webkit http://gitorious.org/webkit/webkit, which I was planning to keep as is for now, so that would mean setting up an extra mirroring for the non-author-rewritten history :/ Also, the server I run this on has a somewhat uncertain future. With that in mind it's probably easier to just push directly from the same import that's pushed to git.webkit.org http://git.webkit.org, and make the GitHub mirror an official mirror? tor arne _ webkit-dev mailing list
Re: [webkit-dev] SVG external referencing not working as of latest chrome canary
I believe https://bugs.webkit.org/show_bug.cgi?id=91237 is the bug you're looking for. I've CC'd relevant chrome folks. As Maciej notes, webkit-dev isn't really the place for bug reports. :) It's a mailing list of over 2000 people. Most of whom don't care about specific SVG bugs. Regardless, thanks for the report. Please take further discussion to the bugs system. -eric On Sun, Jan 13, 2013 at 1:37 PM, Maciej Stachowiak m...@apple.com wrote: Hi Steve, If you're interested in more complete SVG support, here are some things you can do: (1) File bugs for any missing features that don't have bugs already. (2) Create a meta-bug for complete SVG 1.1 support or what have you that's blocked by all the relevant feature bugs. (3) Add useful reduced test cases to the relevant bugs. (4) Cite real-world sites using the functionality to the relevant bugs. (5) Work on implementing some of these features yourself. (6) Persuade WebKit hackers that you know (offlist) to work on some of these features. (7) Contact one of the vendors that works on WebKit via their developer relations channels and ask them to implement the features you care about. If you are interested in more complete SVG support, I encourage you to do some or all of these things. Note, however, that posting feature requests or advocacy for specific bugs is not really appropriate for this list. It's for talking about the development of WebKit itself, and no one uses requests on this list as a way to drive priorities. I'm glad to see you are interested in WebKit's SVG support and I hope you will consider some of the possible steps above to improve it. Cheers, Maciej On Jan 13, 2013, at 8:37 AM, Steve Williams stephen.j.h.willi...@googlemail.com wrote: Hi all, I've done a little experimenting to see where we're at wrt to svg feature set and it seems webkit is lagging some way behind gecko. Of particular concern is lack of external referencing capability through the svg use tag. I attach a simple example that works in firefox for your consideration. root.svg should link through to object.svg and render it. It doesn't in latest chrome canary. You've had a bug filed on this for a long time but it's still unresolved so thought I'd mail. https://bugs.webkit.org/show_bug.cgi?id=12499 We are lowering the priority because this is not heavily used. The feature is not used heavily because it doesn't work properly. Never use lack of use as a reason to not do something :) SVG is important because it's the lowest common denominator high spec graphics interface across all major browsers. Looks like you're behind ie9 in terms of implementation. You should at least match their implementation so we can raise the bar. Of course IE should implement webgl but until they do SVG is the best we've got across all mainstream browsers. Thanks in advance for your consideration. webkit is behind the curve in implementation of this web standard - please address this. Best regards, Steve Williams root.svgobject.svg___ 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
[webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread
We're planning to move parts of the HTML Parser off of the main thread: https://bugs.webkit.org/show_bug.cgi?id=106127 This is driven by our testing showing that HTML parsing on mobile is be slow, and long (causing user-visible delays averaging 10 frames / 150ms). https://bug-106127-attachments.webkit.org/attachment.cgi?id=182002 Complete data can be found at [1]. Mozilla moved their parser onto a separate thread during their HTML5 parser re-write: https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/HTML_parser_threading We plan to take a slightly simpler approach, moving only Tokenizing off of the main thread: https://docs.google.com/drawings/d/1hwYyvkT7HFLAtTX_7LQp2lxA6LkaEWkXONmjtGCQjK0/edit The left is our current design, the middle is a tokenizer-only design, and the right is more like mozilla's threaded-parser design. Profiling shows Tokenizing accounts for about 10x the number of samples as TreeBuilding. Including Antti's recent testing (.5% vs. 3%): https://bugs.webkit.org/show_bug.cgi?id=106127#c10 If after we do this we measure and find ourselves still spending a lot of main-thread time parsing, we'll move the TreeBuilder too. :) (This work is a nicely separable sub-set of larger work needed to move the TreeBuilder.) We welcome your thoughts and comments. 1. https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdGtJTWlSaUItQ1hYaDFDcWkzeVAxOGc#gid=0 (Epic thanks to Nat Duca for helping us collect that data.) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Feature Announcement: Moving HTML Parser off the Main Thread
On Wed, Jan 9, 2013 at 6:38 PM, Oliver Hunt oli...@apple.com wrote: How will we ensure thread safety? Even at just the tokenizing level don't we use AtomicString? AtromicString isn't threadsafe wrt StringImpl IIRC so this seems like it sould add a world of hurt. AtomicString is already usable from other threads (http://trac.webkit.org/changeset/38094), but are correct this is the core concern! PickledToken (or whatever it's called) will have to be written very carefully in order to minimize/eliminate copies, while still guaranteeing thread safety. The correct design and handling of PickledToken is the entire question of this whole endeavor. I realise it's been a long time since I've worked on this so it's completely possible that I'm not aware of the current behavior. That aside I question what the benefit of this will be. All those cases where we've started parsing html are intrinsically tied to the web's general single thread of execution model, which implies that even if we do push parsing into a separate thread we'll just end up with the ui thread blocked on the parsing thread which doesn't seem hugely superior. What is the objective here? To improve performance, add parallelism, or reduce latency? The core goal is to reduce latency -- to free up the main thread for JavaScript and UI interaction -- which as you correctly note, cannot be moved off of the main thread due to the single thread of execution model of the web. One could view the pre-load scanner as a lay-man's attempt at this type of tokenize asynchronously approach. This model gets preload scanning for free, as well as can easily answer wkb.ug/90751 request to speculative tokenizing of the entire document. (We just have to save markers before every script token, as if the script uses document.write, any tokens after /script become invalid.) I should also note that not all HTML parsing can be moved off of the main thread. innerHTML for example, would still be done entirely on the main thread. I would imagine that when we were to land this on trunk it would be behind a feature flag and ports could opt-in to the threaded-parsing path, as we must maintain the main-thread parsing ability for innerHTML anyway. --Oliver On Jan 9, 2013, at 6:10 PM, Adam Barth aba...@webkit.org wrote: On Wed, Jan 9, 2013 at 6:00 PM, Eric Seidel e...@webkit.org wrote: We're planning to move parts of the HTML Parser off of the main thread: https://bugs.webkit.org/show_bug.cgi?id=106127 This is driven by our testing showing that HTML parsing on mobile is be slow, and long (causing user-visible delays averaging 10 frames / 150ms). https://bug-106127-attachments.webkit.org/attachment.cgi?id=182002 Complete data can be found at [1]. In case it's not clear from that link, the ParseHTML column is the total amount of time the web inspector attributes to HTML parsing when loading those URLs on a Nexus 7 using a top-of-tree build of Chromium's content_shell (similar to WebKitTestRunner). The HTML parser parses data a chunk at a time, which means the total time doesn't tell the whole story. The ParseHTML_max column shows the largest single block of time spent in the HTML parser, which is more of a measure of the main thread jank caused by the parser. Antti has pointed out that the inspector isn't the best source of data. He measured total time using instruments, and got numbers that are consistent (within a factor of 2) of the inspector measurements. (We were using different data sets, so we wouldn't expect perfect agreement even if we were measuring precisely the same thing.) Adam Mozilla moved their parser onto a separate thread during their HTML5 parser re-write: https://developer.mozilla.org/en-US/docs/Mozilla/Gecko/HTML_parser_threading We plan to take a slightly simpler approach, moving only Tokenizing off of the main thread: https://docs.google.com/drawings/d/1hwYyvkT7HFLAtTX_7LQp2lxA6LkaEWkXONmjtGCQjK0/edit The left is our current design, the middle is a tokenizer-only design, and the right is more like mozilla's threaded-parser design. Profiling shows Tokenizing accounts for about 10x the number of samples as TreeBuilding. Including Antti's recent testing (.5% vs. 3%): https://bugs.webkit.org/show_bug.cgi?id=106127#c10 If after we do this we measure and find ourselves still spending a lot of main-thread time parsing, we'll move the TreeBuilder too. :) (This work is a nicely separable sub-set of larger work needed to move the TreeBuilder.) We welcome your thoughts and comments. 1. https://docs.google.com/spreadsheet/ccc?key=0AlC4tS7Ao1fIdGtJTWlSaUItQ1hYaDFDcWkzeVAxOGc#gid=0 (Epic thanks to Nat Duca for helping us collect that data.) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev
Re: [webkit-dev] WebKit Commit Queue is not processing patches
Sorry, the feeder-queue went down again last night. The Feeder Queue is responsible for scraping bugzilla and feeding all the EWS, style, commit-queues. (To cause 1x load on bugs.webkit.org instead of 20x.) Unfortunately this results in a single-point of failure for the whole system. :( It's run almost entirely without incident for the last year. I believe the two failures in the last month were caused by the git.chromium.orgwebkit-mirror confusion of late. Adam and I are looking into a more stable solution. Please feel encouraged to email he or I if you see the bots down in the future. Thanks. On Wed, Dec 19, 2012 at 10:12 PM, Kiran Muppala cmupp...@apple.com wrote: Yup, the restart definitely fixed the issue. My patch progressed through the queue and landed. Thanks, Kiran On Dec 19, 2012, at 9:09 PM, Eric Seidel e...@webkit.org wrote: I didn't see the feeder-queue listed at: http://queues.webkit.org/active-bots So I SSH'd into the machine and attached to the screen session. The Feeder queue appeared to be there and working? I then restarted all the queues on that machine (style-queue, sherrifbot and feeder-queue). It's possible the feeder was somehow stuck updating it's git repo or something. We were having some git trouble last week. In any case, I believe the issue is resolved. Please let me know if you have any more trouble! On Wed, Dec 19, 2012 at 9:02 PM, Kiran Muppala cmupp...@apple.com wrote: No problem. Thanks for looking into it so quickly. - Kiran On Dec 19, 2012, at 8:55 PM, Eric Seidel e...@webkit.org wrote: The Feeder queue is down (and thus likely sherrifbot and the style-queue which are also hosted on the same EC2 instance). I'll see if I can restart it. Thanks for letting me know. On Wed, Dec 19, 2012 at 8:53 PM, Eric Seidel e...@webkit.org wrote: This time from @webkit. On Wed, Dec 19, 2012 at 8:52 PM, Eric Seidel esei...@google.com wrote: Ouch. I'll take a look. On Wed, Dec 19, 2012 at 8:49 PM, Kiran Muppala cmupp...@apple.comwrote: Hi folks, All the bots on WebKit commit queue are in a loop of Starting Queue, Stopping Queue, reason: Delegate terminated queue and back to Starting Queue. Because of this, no patches are being processed. Eric Seidel and Adam Barth, who usually manage the queue, I am told might be on vacation. if theres anyone else who can take a look at the commit queue bots, please do so. Thanks, Kiran ___ 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] WebKit Commit Queue is not processing patches
Ouch. I'll take a look. On Wed, Dec 19, 2012 at 8:49 PM, Kiran Muppala cmupp...@apple.com wrote: Hi folks, All the bots on WebKit commit queue are in a loop of Starting Queue, Stopping Queue, reason: Delegate terminated queue and back to Starting Queue. Because of this, no patches are being processed. Eric Seidel and Adam Barth, who usually manage the queue, I am told might be on vacation. if theres anyone else who can take a look at the commit queue bots, please do so. Thanks, Kiran ___ 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] WebKit Commit Queue is not processing patches
This time from @webkit. On Wed, Dec 19, 2012 at 8:52 PM, Eric Seidel esei...@google.com wrote: Ouch. I'll take a look. On Wed, Dec 19, 2012 at 8:49 PM, Kiran Muppala cmupp...@apple.com wrote: Hi folks, All the bots on WebKit commit queue are in a loop of Starting Queue, Stopping Queue, reason: Delegate terminated queue and back to Starting Queue. Because of this, no patches are being processed. Eric Seidel and Adam Barth, who usually manage the queue, I am told might be on vacation. if theres anyone else who can take a look at the commit queue bots, please do so. Thanks, Kiran ___ 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] WebKit Commit Queue is not processing patches
The Feeder queue is down (and thus likely sherrifbot and the style-queue which are also hosted on the same EC2 instance). I'll see if I can restart it. Thanks for letting me know. On Wed, Dec 19, 2012 at 8:53 PM, Eric Seidel e...@webkit.org wrote: This time from @webkit. On Wed, Dec 19, 2012 at 8:52 PM, Eric Seidel esei...@google.com wrote: Ouch. I'll take a look. On Wed, Dec 19, 2012 at 8:49 PM, Kiran Muppala cmupp...@apple.comwrote: Hi folks, All the bots on WebKit commit queue are in a loop of Starting Queue, Stopping Queue, reason: Delegate terminated queue and back to Starting Queue. Because of this, no patches are being processed. Eric Seidel and Adam Barth, who usually manage the queue, I am told might be on vacation. if theres anyone else who can take a look at the commit queue bots, please do so. Thanks, Kiran ___ 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] WebKit Commit Queue is not processing patches
I didn't see the feeder-queue listed at: http://queues.webkit.org/active-bots So I SSH'd into the machine and attached to the screen session. The Feeder queue appeared to be there and working? I then restarted all the queues on that machine (style-queue, sherrifbot and feeder-queue). It's possible the feeder was somehow stuck updating it's git repo or something. We were having some git trouble last week. In any case, I believe the issue is resolved. Please let me know if you have any more trouble! On Wed, Dec 19, 2012 at 9:02 PM, Kiran Muppala cmupp...@apple.com wrote: No problem. Thanks for looking into it so quickly. - Kiran On Dec 19, 2012, at 8:55 PM, Eric Seidel e...@webkit.org wrote: The Feeder queue is down (and thus likely sherrifbot and the style-queue which are also hosted on the same EC2 instance). I'll see if I can restart it. Thanks for letting me know. On Wed, Dec 19, 2012 at 8:53 PM, Eric Seidel e...@webkit.org wrote: This time from @webkit. On Wed, Dec 19, 2012 at 8:52 PM, Eric Seidel esei...@google.com wrote: Ouch. I'll take a look. On Wed, Dec 19, 2012 at 8:49 PM, Kiran Muppala cmupp...@apple.comwrote: Hi folks, All the bots on WebKit commit queue are in a loop of Starting Queue, Stopping Queue, reason: Delegate terminated queue and back to Starting Queue. Because of this, no patches are being processed. Eric Seidel and Adam Barth, who usually manage the queue, I am told might be on vacation. if theres anyone else who can take a look at the commit queue bots, please do so. Thanks, Kiran ___ 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] run-perf-tests --profile
I recently added a --profile option to run-perf-tests to make it easier to acquire cpu-profiles of PerformanceTests. The option is available on Linux, Mac and Chromium Android. You can see some minimal documentation here: https://trac.webkit.org/wiki/Performance%20Tests#ProfilingPerformanceTests Let me know if you have any questions. -eric ___ 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
This is now complete: http://trac.webkit.org/changeset/137371 I'm watching the bots. Please contact me if you have any trouble. Thank you all for your feedback. On Mon, Dec 10, 2012 at 10:11 AM, Dirk Pranke dpra...@chromium.org wrote: 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] Proposal: Make Ninja the default build-system for build-webkit --chromium
Nevermind. After further discussion with Nico, this can't work yet. Ninja is currently configured to use a non-webkitty out build directory, which is undoubtably going to confus some scripts/bots. We'll try this again at a later time. Apologies for the noise. http://trac.webkit.org/changeset/137375 On Tue, Dec 11, 2012 at 3:33 PM, Eric Seidel e...@webkit.org wrote: This is now complete: http://trac.webkit.org/changeset/137371 I'm watching the bots. Please contact me if you have any trouble. Thank you all for your feedback. On Mon, Dec 10, 2012 at 10:11 AM, Dirk Pranke dpra...@chromium.org wrote: 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] 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
[webkit-dev] Proposal: Make Ninja the default build-system for build-webkit --chromium
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
Re: [webkit-dev] commit-queue offline for the rest of the day
I believe the CQs are back up and running. Adam moved them to git.webkit.org for the time-being (they were using git.chromium.org as a mirror). Stefan is investigating our mirror to understand what went wrong. Sorry for the troubles. http://queues.webkit.org/queue-status/commit-queue On Tue, Dec 4, 2012 at 3:15 PM, Adam Barth aba...@webkit.org wrote: Both the commit hashes mentioned in the log appear to be real hashes from today, about ten revisions apart. I'm not enough of a git expert to understand what's going on. Adam On Tue, Dec 4, 2012 at 2:49 PM, Osztrogonac Csaba o...@inf.u-szeged.hu wrote: Hi, Is it possible if http://git.chromium.org/external/Webkit is broken? Or somebody pushed non fast forward commits? Maybe a manual kick can help: git reset --hard HEAD~1000 git clean -dxf git pull These lines always helped me if something went wrong on my git repository. Ossy Eric Seidel írta: An example of the git failures can be found here: http://queues.webkit.org/results/15120956 (For any with git-knowledge who might know what's wrong.) On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote: There's some problem with the commit-queue failing with some git error. I'm taking it offline for the rest of the day. Hopefully I'll figure it out tonight. Adam ___ 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] commit-queue offline for the rest of the day
An example of the git failures can be found here: http://queues.webkit.org/results/15120956 (For any with git-knowledge who might know what's wrong.) On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote: There's some problem with the commit-queue failing with some git error. I'm taking it offline for the rest of the day. Hopefully I'll figure it out tonight. Adam ___ 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] commit-queue offline for the rest of the day
On Tue, Dec 4, 2012 at 12:39 PM, Eric Seidel esei...@google.com wrote: An example of the git failures can be found here: http://queues.webkit.org/results/15120956 (For any with git-knowledge who might know what's wrong.) On Tue, Dec 4, 2012 at 12:36 PM, Adam Barth aba...@webkit.org wrote: There's some problem with the commit-queue failing with some git error. I'm taking it offline for the rest of the day. Hopefully I'll figure it out tonight. Adam ___ 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] Github vs. git.webkit.org
This has come up in the past. I believe the current recommended path is to use the github.com SHAs and just live in a github-only world. https://lists.webkit.org/pipermail/webkit-dev/2012-March/020002.html has some discussion. https://trac.webkit.org/wiki/UsingGitHub I am not aware of any plan to change the SHAs in the github mirror or git.webkit.org (which is unfortunate, but the current reality). -eric On Sat, Nov 24, 2012 at 3:39 PM, Gergely Kis gerg...@homejinni.com wrote: Hi, It looks like that the github mirror and git.webkit.org still has different SHA ids for commits. Is this final, or is the plan still to switch to the git.webkit.org SHA ids? For our MIPS staging repository we created a new mirror on github from git.webkit.org, and now we were asked by the github admins to reduce the repository to less than 1GB. I assume that if we would fork from the github.com/WebKit/webkit repository, then it would be fine with the github admins. However, if it is still the plan to switch to the git.webkit.org SHA ids in the github mirror as well, then we would like to avoid the extra work of rebasing our work to the github mirror commits, and then rebasing it back when the transition is made. We have to decide in the next couple days, because github will disable access to our repository again, so any status update on this transition plan would be helpful. Alternatively, if you have any experience with the github admins in how to ask for more space for webkit repositories, any advice would be very appreciated. Best Regards, Gergely Kis ___ 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] Github vs. git.webkit.org
Yes, I remember that thread now, and you're correct: https://lists.webkit.org/pipermail/webkit-dev/2012-April/020494.html One answer is to take your mirror and make it the main mirror on GitHub instead of Tor's. On Sat, Nov 24, 2012 at 3:53 PM, Gergely Kis gerg...@homejinni.com wrote: Hi, Yes, I saw that thread, but I got confused by this other thread: https://lists.webkit.org/pipermail/webkit-dev/2012-April/020339.html Here most of the participants seemed to agree that moving the 2 repositories to use the same SHA ids is the best course of action. In any case, if the github repo is the way to go now, then we will do the transition... Thanks, Gergely On Sat, Nov 24, 2012 at 10:48 PM, Eric Seidel e...@webkit.org wrote: This has come up in the past. I believe the current recommended path is to use the github.com SHAs and just live in a github-only world. https://lists.webkit.org/pipermail/webkit-dev/2012-March/020002.html has some discussion. https://trac.webkit.org/wiki/UsingGitHub I am not aware of any plan to change the SHAs in the github mirror or git.webkit.org (which is unfortunate, but the current reality). -eric On Sat, Nov 24, 2012 at 3:39 PM, Gergely Kis gerg...@homejinni.com wrote: Hi, It looks like that the github mirror and git.webkit.org still has different SHA ids for commits. Is this final, or is the plan still to switch to the git.webkit.org SHA ids? For our MIPS staging repository we created a new mirror on github from git.webkit.org, and now we were asked by the github admins to reduce the repository to less than 1GB. I assume that if we would fork from the github.com/WebKit/webkit repository, then it would be fine with the github admins. However, if it is still the plan to switch to the git.webkit.org SHA ids in the github mirror as well, then we would like to avoid the extra work of rebasing our work to the github mirror commits, and then rebasing it back when the transition is made. We have to decide in the next couple days, because github will disable access to our repository again, so any status update on this transition plan would be helpful. Alternatively, if you have any experience with the github admins in how to ask for more space for webkit repositories, any advice would be very appreciated. Best Regards, Gergely Kis ___ 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] sharing more test references
!DOCTYPE html body style=margin: 0px div style=height: 100px; width: 100px; background-color: green Does seem pretty simple. !DOCTYPE html body style=margin: 0px svgrect width=100px height=100px fill=greensvg is even shorter. :) I support getting rid of pixel tests. I suspect that some very dumb scripts could turn large chunks of these existing pixel-tests into ref-tests. I doubt that those would be the interesting ones though (where platforms have divergent results). On Tue, Nov 13, 2012 at 4:59 PM, Darin Adler da...@apple.com wrote: On Nov 13, 2012, at 4:56 PM, Dirk Pranke dpra...@chromium.org wrote: Wouldn't the fact that there are a large set of tests with the same result be an argument *for* doing the iframe thing? The simple hand-coded green square in upper left corner should be simple, perhaps even simpler than the iframe thing. What is the advantage to having 50 copies of a hand-coded green square in upper left corner reference test? Tests standing alone and being independent, easy to move around, revise, and understand individually rather than as part of a suite. I don’t have a strong objection to your iframe technique, but I’d start simpler and do it only if it’s really needed. -- Darin ___ 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] RenderArena: Teaching an old dog new tricks
RenderArena was a perf optimization for the rendering tree, which hyatt imported from Mozilla 10 years ago: http://trac.webkit.org/changeset/2635 The prevailing lore has long been that RenderArena is no longer useful, ugly, and should be killed! http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg12681.html The (unfortunate?) reality is that we've failed to do so, despite trying several times. http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg12682.html However, like those bell-bottoms in your father's closet, RenderArena is back in vogue and Chromium's security team very excited about RenderArena's security benefits. Why, you might ask? Slab-allocators (i.e. RenderArena) hand out memory all from a single region, guaranteeing (among other things) that free'd objects can only be ever overwritten by other objects from the same pool. This makes it much harder, for example to find a Use-After-Free of a RenderBlock and then fill that RenderBlock's memory (and vtable pointer) with arbitrary memory (like the contents of a javascript array). http://en.wikipedia.org/wiki/Slab_allocation We're aware of multiple high-profile past WebKit exploits (including the last $60,000-winning Pwnium 2 exploit) which would have been defeated by a Slab-allocated DOM. Various members of Chromium's security team have also been working on improving RenderArena: http://trac.webkit.org/changeset/133119 http://trac.webkit.org/changeset/132970 http://trac.webkit.org/changeset/129583 http://trac.webkit.org/changeset/97009 Since RenderArena is generic, the current plan to move it to WTF (as by Chris Marrin suggested back in http://www.mail-archive.com/webkit-dev@lists.webkit.org/msg12672.html), clean up the code further, and investigate wider deployment (like to the DOM tree) for the security benefit and possible perf win. https://bugs.webkit.org/show_bug.cgi?id=101087 Also on the list is making our smart-pointers (OwnPtr,ReftPtr) smarter, to avoid the current manual use/free mess of current RenderArena clients. Personally, I hope we bring back mullets next. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] …Inlines.h vs …InlineMethods.h
My understanding was that *Inlines/*InlineMethods were more about limiting includes in the main header. Maybe that's just a happy side effect. :) I also prefer the *Inlines naming. :) On Fri, Nov 2, 2012 at 5:48 PM, Mark Lam mark@apple.com wrote: FYI, some time in the near future (maybe this weekend), I plan to do some work to break inline methods in JavaScriptCore out of header files into their own inline header files. Naming-wise, the existing JSC code has a few inline headers named …Inlines.h and more named …InlinedMethods.h. On the WebCore side, the few that exists there are named …InlineMethods.h. I have a preference for the …Inlines.h convention because it is shorter and concisely communicates the intent. I plan to rename all these inline headers to be …Inlines.h for consistency. Does anyone object to my renaming the inline headers? Also, a lot of the existing inlined methods are 1 liners. I plan to leave these in the original header file. Here's the convention I'm going to adopt: 1. If the inline method is a 1 liner, then leave it in the original header file. 2. If it takes more than 1 line, then move it into a corresponding inline header file. I will only be breaking out the inline methods (per the above convention) in the JSC sources. Apart from renaming the few WebCore inline headers, I won't be looking into WebCore's placement of inline methods for now. If anyone has an opinion on this, please let me know asap. Thanks. Regards, Mark ___ 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] Fwd: build-webkit stopped working for me
Is Snow Leopard deprecated? Dave (WebKit's MathML guy) is reporting trouble building the Apple Mac port on Snow Leopard. We don't seem to have a Snow Leopard bot on: http://build.webkit.org/console?category=AppleMac so it seems totally concievable that it's broken. If it is deprecated, I'm happy to post patches to remove support. :) -- Forwarded message -- From: Dave Barton dbar...@mathscribe.com I'm sorry to bug you guys, but I don't know who else to ask. After my last update-webkit, build-webkit --debug doesn't work for me. I tried asking in IRC but got no response. Below is some sample output. The script actually dies after failing to compile 7 files in JavaScriptCore: runtime/InitializeThreading.cpp runtime/Options.cpp heap/GCThreadSharedData.cpp heap/SlotVisitor.cpp heap/Heap.cpp heap/HeapStatistics.cpp heap/GCThread.cpp I am running on Snow Leopard, to try to stay compatible with another project (job). Has WebKit stopped supporting that for development? I haven't seen any notice on webkit-dev e-mail. I notice that on http://build.chromium.org/p/chromium.webkit/console the Mac OS 10.6 bots are failing, but they're failing tests not compiles. All 7 compile failures are at the same place, so I've included 2 below that together show how all 7 fail. At /usr/include/c++/4.2.1/bits/locale_classes.h:411, std::locale::facet::_M_remove_reference() (an internal C++ standard library function) does a try/catch, but the gcc-4.2 command includes -fno-exceptions. Do I need a later gcc (C++ standard library)? Is there a way to find out what WebKit supports/requires, or what the bots are using? Thanks very much for any help or pointers. If there's someone better for me to ask, please let me know. Take care, Dave B. === BUILD NATIVE TARGET JavaScriptCore OF PROJECT JavaScriptCore WITH CONFIGURATION Debug === Check dependencies ProcessInfoPlistFile /Users/drb/devel/WebKit/WebKitBuild/Debug/JavaScriptCore.framework/Versions/A/Resources/Info.plist Info.plist cd /Users/drb/devel/WebKit/Source/JavaScriptCore builtin-infoPlistUtility Info.plist -expandbuildsettings -platform macosx -o /Users/drb/devel/WebKit/WebKitBuild/Debug/JavaScriptCore.framework/Versions/A/Resources/Info.plist CompileC /Users/drb/devel/WebKit/WebKitBuild/JavaScriptCore.build/Debug/JavaScriptCore.build/Objects-normal/x86_64/Heap.o heap/Heap.cpp normal x86_64 c++ com.apple.compilers.gcc.4_2 cd /Users/drb/devel/WebKit/Source/JavaScriptCore setenv LANG en_US.US-ASCII /Developer/usr/bin/gcc-4.2 -x c++ -arch x86_64 -fmessage-length=0 -pipe -Wno-trigraphs -fno-exceptions -fno-rtti -fpascal-strings -fasm-blocks -O0 -Werror -Wmissing-prototypes -Wnon-virtual-dtor -Wsign-compare -Wnewline-eof -DHAVE_DTRACE=1 -DWEBKIT_VERSION_MIN_REQUIRED=WEBKIT_VERSION_LATEST -DHAVE_HEADER_DETECTION_H -fstrict-aliasing -fvisibility=hidden -fvisibility-inlines-hidden -fno-threadsafe-statics -mmacosx-version-min=10.6 -gdwarf-2 -I/Users/drb/devel/WebKit/WebKitBuild/JavaScriptCore.build/Debug/JavaScriptCore.build/JavaScriptCore.hmap -Wall -Wextra -Wcast-qual -Wchar-subscripts -Wextra-tokens -Wformat=2 -Winit-self -Wmissing-format-attribute -Wmissing-noreturn -Wpacked -Wpointer-arith -Wredundant-decls -Wundef -Wwrite-strings -F/Users/drb/devel/WebKit/WebKitBuild/Debug -I/Users/drb/devel/WebKit/WebKitBuild/Debug/include -I/Users/drb/devel/WebKit/WebKitBuild/Debug/DerivedSources/JavaScriptCore -I. -Iicu -I/Users/drb/devel/WebKit/WebKitBuild/Debug/usr/local/include -I/Users/drb/devel/WebKit/WebKitBuild/JavaScriptCore.build/Debug/JavaScriptCore.build/DerivedSources/x86_64 -I/Users/drb/devel/WebKit/WebKitBuild/JavaScriptCore.build/Debug/JavaScriptCore.build/DerivedSources -include /var/folders/RC/RCYcW-YGHj0lsQvZo63kAk+++TM/-Caches-/com.apple.Xcode.502/SharedPrecompiledHeaders/JavaScriptCorePrefix-eomldsaqazlgrmgzqddxqhcetggy/JavaScriptCorePrefix.h -c /Users/drb/devel/WebKit/Source/JavaScriptCore/heap/Heap.cpp -o /Users/drb/devel/WebKit/WebKitBuild/JavaScriptCore.build/Debug/JavaScriptCore.build/Objects-normal/x86_64/Heap.o In file included from /usr/include/c++/4.2.1/bits/ios_base.h:47, from /usr/include/c++/4.2.1/ios:48, from /usr/include/c++/4.2.1/ostream:45, from /usr/include/c++/4.2.1/iterator:70, from /Users/drb/devel/WebKit/WebKitBuild/Debug/usr/local/include/wtf/Deque.h:36, from /Users/drb/devel/WebKit/Source/JavaScriptCore/heap/HeapStatistics.h:29, from /Users/drb/devel/WebKit/Source/JavaScriptCore/heap/Heap.cpp:31: /usr/include/c++/4.2.1/bits/locale_classes.h: In member function 'void std::locale::facet::_M_remove_reference() const': /usr/include/c++/4.2.1/bits/locale_classes.h:411: error: exception handling disabled, use -fexceptions to enable CompileC /Users/drb/devel/WebKit/WebKitBuild/JavaScriptCore.build/Debug/JavaScriptCore.build/Objects-normal/x86_64/GCThreadSharedData.o heap/GCThreadSharedData.cpp normal x86_64 c++
Re: [webkit-dev] build-webkit stopped working for me
Thank you both for the clarification. On Sun, Oct 21, 2012 at 2:21 PM, Dirk Pranke dpra...@chromium.org wrote: On Sun, Oct 21, 2012 at 2:17 PM, Maciej Stachowiak m...@apple.com wrote: Apple did not ship the last release of Safari to SnowLeopard and we have no plans to maintain SnowLeopard support on trunk. We haven't actively ripped out SL-specific ifdefs because we were under the impression that the Chromium port still targets SL and sometimes uses Mac code paths. This is correct; Chromium still supports SL. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Accessing bugs.webkit.org via XML-RPC
Bill and I have talked about this in the past. I don't remember what the outcome was. Right now webkit-patch just uses Mechanize: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/net/bugzilla We also might get some of this as part of the upgrade: https://bugs.webkit.org/show_bug.cgi?id=55882 If you (or someone else on your team) is interested in working on the upgrade, I suspect some of the CC'd would be happy to have the help. On Fri, Oct 19, 2012 at 10:53 AM, Mihai Balan miba...@adobe.com wrote: Hi there, Does anyone know what’s the status of the XML-RPC interface on bugs.webkit.org? It seems to be there, but all calls result in a Application failed during request deserialization: no element found at line 1, column 0, byte -1 at /usr/lib64/perl5/XML/Parser.pm line 187 error. Any extra info or pointers on how to address this are super-welcome! Thanks in advance, miChou Mihai Balan | Quality Engineer / WebKit team | miba...@adobe.com | +4-031.413.3653 / x83653 | Adobe Systems Romania ___ 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] [chromium] as of r131699, the chromium port no longer uses any baselines from LayoutTests/platform/mac
Does that mean our fallback graph is now finally a tree?? :) https://docs.google.com/drawings/d/1z65SKkWrD4Slm6jobIphHwwRADyUtjOAxwGBVKBY8Kc/edit On Wed, Oct 17, 2012 at 8:15 PM, Dirk Pranke dpra...@chromium.org wrote: All of the Chromium ports will use baselines in their port-specific directories, then fall back through various paths to platform/chromium and then to next to the test. Which means you Apple folks can feel free to break things in platform/mac to your hearts' content :). Let me know if you see any weirdness or problems. Thanks! -- Dirk ___ 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 new BugZilla keyword
Done. On Fri, Oct 5, 2012 at 7:49 AM, Mihai Balan miba...@adobe.com wrote: Hello, Can anyone help me adding a new BugZilla keyword (as those over at https://bugs.webkit.org/describekeywords.cgi )? We’d like it named AdobeTracked. I need it for marking bugs that Adobe contributors are actively working on – it would help us in the internal „book-keeping” we’re doing. Thanks in advance, miChou Mihai Balan | Quality Engineer / WebKit team | miba...@adobe.com | +4-031.413.3653 / x83653 | Adobe Systems Romania ___ 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] A new test in a patch passes locally fails on ews
I think that's an interesting idea. The bots don't have a mail server. :) But we could presumably wire up some sort of service for them. On Thu, Oct 4, 2012 at 6:41 PM, Emil A Eklund e...@chromium.org wrote: What if we mail the zip files to the person that uploaded the patch? That way the responsibility of managing the storage is shifted to the author and the author still benefits from the results from all platforms. ___ 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] Tips on why run-webkit-tests is not working for me?
That stack is confusing. It looks like it's in Mac._build_java_test_support: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/port/mac.py#L133 But that shouldn't be trying to execute run-webkit-tests? Perhaps make is missing? or the java directory its trying to build is missing and it's just printing the wrong path? On Wed, Oct 3, 2012 at 9:05 AM, Darin Adler da...@apple.com wrote: I’m trying to test some changes on my Mountain Lion Mac, using the Mac port. When I call run-webkit-tests it fails with file not found. Using port 'mac-mountainlion' Test configuration: mountainlion, x86_64, debug Placing test results in /Users/darin/Build/Debug/layout-test-results Baseline search path: mac - generic Using Debug build Pixel tests disabled Regular timeout: 35000, slow test timeout: 175000 Command line: /Users/darin/Build/Debug/DumpRenderTree - Found 31448 tests; running 29263, skipping 2185. Checking build ... OSError raised: [Errno 2] No such file or directory File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/layout_tests/run_webkit_tests.py, line 110, in run unexpected_result_count = manager.run(args) File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/layout_tests/controllers/manager.py, line 404, in run if not self._set_up_run(): File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/layout_tests/controllers/manager.py, line 355, in _set_up_run if not self._port.check_build(self.needs_servers()): File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/layout_tests/port/base.py, line 240, in check_build if not self._check_port_build(): File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/layout_tests/port/mac.py, line 162, in _check_port_build return self._build_java_test_support() File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/layout_tests/port/mac.py, line 136, in _build_java_test_support if self._executive.run_command(build_java, return_exit_code=True): # Paths are absolute, so we don't need to set a cwd. File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/common/system/executive.py, line 402, in run_command close_fds=self._should_close_fds()) File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/common/system/executive.py, line 458, in popen return subprocess.Popen(*args, **kwargs) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py, line 679, in __init__ errread, errwrite) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py, line 1228, in _execute_child raise child_exception Failed to execute Tools/Scripts/new-run-webkit-tests at /Users/darin/Safari/Internal/Tools/Scripts/../../../OpenSource/Tools/Scripts/run-webkit-tests line 126. Anyone know why? -- Darin ___ 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] Tips on why run-webkit-tests is not working for me?
This is Executive.run_command: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/system/executive.py#L378 I would suggest running test-webkitpy (which will go through and delete any orphaned .pyc files which could be confusing things). -eric On Wed, Oct 3, 2012 at 9:19 AM, Eric Seidel e...@webkit.org wrote: That stack is confusing. It looks like it's in Mac._build_java_test_support: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/layout_tests/port/mac.py#L133 But that shouldn't be trying to execute run-webkit-tests? Perhaps make is missing? or the java directory its trying to build is missing and it's just printing the wrong path? On Wed, Oct 3, 2012 at 9:05 AM, Darin Adler da...@apple.com wrote: I’m trying to test some changes on my Mountain Lion Mac, using the Mac port. When I call run-webkit-tests it fails with file not found. Using port 'mac-mountainlion' Test configuration: mountainlion, x86_64, debug Placing test results in /Users/darin/Build/Debug/layout-test-results Baseline search path: mac - generic Using Debug build Pixel tests disabled Regular timeout: 35000, slow test timeout: 175000 Command line: /Users/darin/Build/Debug/DumpRenderTree - Found 31448 tests; running 29263, skipping 2185. Checking build ... OSError raised: [Errno 2] No such file or directory File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/layout_tests/run_webkit_tests.py, line 110, in run unexpected_result_count = manager.run(args) File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/layout_tests/controllers/manager.py, line 404, in run if not self._set_up_run(): File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/layout_tests/controllers/manager.py, line 355, in _set_up_run if not self._port.check_build(self.needs_servers()): File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/layout_tests/port/base.py, line 240, in check_build if not self._check_port_build(): File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/layout_tests/port/mac.py, line 162, in _check_port_build return self._build_java_test_support() File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/layout_tests/port/mac.py, line 136, in _build_java_test_support if self._executive.run_command(build_java, return_exit_code=True): # Paths are absolute, so we don't need to set a cwd. File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/common/system/executive.py, line 402, in run_command close_fds=self._should_close_fds()) File /Users/darin/Safari/OpenSource/Tools/Scripts/webkitpy/common/system/executive.py, line 458, in popen return subprocess.Popen(*args, **kwargs) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py, line 679, in __init__ errread, errwrite) File /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py, line 1228, in _execute_child raise child_exception Failed to execute Tools/Scripts/new-run-webkit-tests at /Users/darin/Safari/Internal/Tools/Scripts/../../../OpenSource/Tools/Scripts/run-webkit-tests line 126. Anyone know why? -- Darin ___ 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] Tips on why run-webkit-tests is not working for me?
I should note that webkit-patch does do some magic to find it's checkout. Its possible it's somehow confused by your svn setup? I don't personally use the svn codepaths very often. In case this is useful, here is some more context on what webkitpy is trying to do: Most webkitpy clients, including webkit-patch, create a Host object: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/host.py#L128 which includes an SCM object, which is created by looking for your checkout_root via the SCMDetector: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/checkout/scm/detection.py#L44 In your case it likely decides it's SVN: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/checkout/scm/svn.py#L85 and then walks up to find the root of the checkout: http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/common/checkout/scm/svn.py#L112 It has some fancy logic to handle nested SVN checkouts. This is designed to emulate the wkdirs.pm behavior from all the perl-scripts of yor. (I really like that I can run build-webkit from any command-prompt and have it do the right thing. webkit-patch tries to behave the same.) On Wed, Oct 3, 2012 at 3:39 PM, Darin Adler da...@apple.com wrote: On Oct 3, 2012, at 9:10 AM, Ryosuke Niwa rn...@webkit.org wrote: Could you tell us what your directory structure look like and where you're executing that command? Looks like a path confusion. My WebKit source tree is in ~/Safari/OpenSource and my build products are in ~/Builds. I am running the script inside the ~/Safari/OpenSource directory. On Oct 3, 2012, at 9:11 AM, Ojan Vafai o...@chromium.org wrote: I'm guessing there's something about your checkout that is confusing the code that finds the path to run-webkit-tests. Does /Users/darin/Safari/Internal/Tools/Scripts/../../../OpenSource/Tools/Scripts/run-webkit-tests actually exist or is that path incorrect? That path is correct, although I don’t know where it’s coming from. Maybe related to how I originally checked out my tree from Subversion. On Oct 3, 2012, at 9:19 AM, Eric Seidel e...@webkit.org wrote: It looks like it's in Mac._build_java_test_support: I don’t think I have Java installed on this computer. Maybe that’s somehow related to the problem. I would suggest running test-webkitpy (which will go through and delete any orphaned .pyc files which could be confusing things). OK, I’ll do that when I get a chance. Perhaps make is missing? I often use make from the command line to build, so it’s in my path. I wish the error message made it clearer what file couldn’t be found. The thing that changed most recently on my machine is how Xcode is installed, so I’m guessing the problem is somehow related to that, since I’ve run the tests many times in the past. -- Darin ___ 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] Settings and Preferences in layout tests
I would agree with Adam, and the more we can move to window.internals, the less technical debt we incur with each new DRT feature. I would love to see overridePreferences go away (or only be used for preferences which need to test the WebKit-side plumbing). TestExpectation files on all ports are full of: # unskip these tests when we add obscure-drt-feature-x http://trac.webkit.org/browser/trunk/LayoutTests/platform/wk2/Skipped#L107 http://trac.webkit.org/browser/trunk/LayoutTests/platform/wk2/Skipped#L209 http://trac.webkit.org/browser/trunk/LayoutTests/platform/wk2/Skipped#L247 http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/TestExpectations#L115 http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/TestExpectations#L948 http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/TestExpectations#L958 as just a few examples. :) I didn't even look at the less-well-funded ports. :) On Wed, Sep 26, 2012 at 4:05 PM, Adam Barth aba...@webkit.org wrote: [re-sent from the proper address] On Wed, Sep 26, 2012 at 2:00 PM, Adam Barth abarth@nowhere wrote: On Wed, Sep 26, 2012 at 1:53 PM, Brady Eidson beid...@apple.com wrote: On Sep 26, 2012, at 1:48 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Sep 26, 2012 at 1:44 PM, Simon Fraser simon.fra...@apple.com wrote: First, direct calls on testRunner that just set preferences should be migrated to internals.settings or testRunner.overridePreference calls, I think (I don't know if either is preferred). I support the idea of unifying the approaches and just use internals.settings. However, the last time I checked, Alexey had some concerns about using internals due to settings may not be properly propagated to WebKit2 layer. Has this concern been addressed? In general I prefer the overridePreference() calls whenever they exist. internals.settings are not exposed in any real-world product whereas preferences exist in each platform's WebKit-layer API that they expose to their embedders in some form. The main downside of overridePreference is that it requires that you expose an API for twiddling the preference on every port. That can lead to us exposing unneeded APIs (making them harder to remove) and to a bunch of port-specific code in an otherwise port-independent patch. IMHO, we should prefer InternalSettings unless we need to test the WebKit-layer code. Adam ___ 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] Anyone willing to update webkit.org?
I was noticing today that http://www.webkit.org/ is quite old and out of date. What xenon built 6 years ago, has stood up remarkably well, but it may be time for a refresh. (It also has no high-dpi support.) I'm aware that I have the ability to change it. But I'm also inviting others to do so: http://trac.webkit.org/browser/trunk/Websites/webkit.org In particular: - It mentions nothing of Safari on iOS or Chrome (which must be some huge fraction of our userbase by now) - Could link to numerous other sites showing information about WebKit (cia, ohloh, svnsearch) - Projects like SVG really aren't the current focus. :) I'm sure this list is full of individuals with infinitely more visual design sense than I. So I invite your patches, my reviewing and committing fingers stand ready. :) -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Pre-proposal: Adding a Coverity instance for WebKIt
I wish to subscribe to this product and or service. Count me in. I'm not particularly worried about who has access. But maybe I should be? Its not like the bad-guys can't run coverity themselves. On Mon, Sep 17, 2012 at 6:11 PM, James Hawkins jhawk...@chromium.org wrote: Hey folks, TL;DR - If you have opinions one way or another about having a Coverity instance available for WebKit developers, please respond to this message. Coverity is a static analysis tool [1] which scans source code and reports defects in the code. We've been using Coverity to find defects in Chrome for a while now, and though there is sometimes a bit of subjectivity involved in the defect types (e.g. whether a return value should be checked), the signal is generally high. Off the top of my head, the following are the defects I spend most of my time fixing: * Uninitialized variables (including member variables). - Chrome has had at least 4 crash fixes in the past few months due to this defect (which were caught by Coverity). * Passing large parameters by value. - Generally a trivial fix. I don't have performance data to say what affect fixing these hash, but 'death by a thousand cuts' eh? * Forward/Reverse/I - Nulls. - Coverity is very good at understanding when a value is NULL and the tool will tell you which code paths are using a NULL value. * Tons of security issue-causing defects. I'd like to propose adding a Coverity instance for the WebKit community, but I want to make sure there's general support before writing up the detailed proposal. A few details: * Google will front the cost of the license (non-zero...very far from zero) and the infrastructure. * I'd leave it up to the WebKit leadership to decide who has access (most likely limited to WebKit committers for security purposes). The biggest rationale is to provide a strong defect signal for the entire WebKit community, which would directly impact the success of all WebKit-based projects. Coverity has provided free licenses for unsponsored (by larger corporations anyway) open-source projects; this has resulted in significant improvements [2] to the code bases of these projects, one of which I was directly involved with years ago (Wine). Let me know if you love the idea or hate it. Thanks, James [1] http://www.coverity.com/products/static-analysis.html [2] http://softwareintegrity.coverity.com/coverity-scan-2011-open-source-integrity-report-registration.html - registration required now :( ___ 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] Pre-proposal: Adding a Coverity instance for WebKIt
On Mon, Sep 17, 2012 at 6:35 PM, Benjamin Poulain benja...@webkit.org wrote: On Mon, Sep 17, 2012 at 4:11 PM, James Hawkins jhawk...@chromium.org wrote: A few details: * Google will front the cost of the license (non-zero...very far from zero) and the infrastructure. * I'd leave it up to the WebKit leadership to decide who has access (most likely limited to WebKit committers for security purposes). The biggest rationale is to provide a strong defect signal for the entire WebKit community, which would directly impact the success of all WebKit-based projects. Coverity has provided free licenses for unsponsored (by larger corporations anyway) open-source projects; this has resulted in significant improvements [2] to the code bases of these projects, one of which I was directly involved with years ago (Wine). I am a little skeptical of Coverity because of bad patches that originated for its report (sometimes even discussed on webkit-dev). I think we should keep in mind the tool also make many mistakes and we should not blindly follows it. Could this be integrated with the EWS like a kind of advanced style check? I think this is a great idea, and would be trivial if coverity could be convinced to run on a diff file, or if we could wrap it in a script to only report errors on the changed lines. Either sounds very doable. The EWS infrastructure is already in place once such a script exists. Reporting possible improvements before patches lands would be more useful than a separate bot. 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
Re: [webkit-dev] How to diagnose a failing early-warning failure that passes on my machine?
The cr-linux bots used to upload the results to the bug itself. Maybe that changed? On Tue, Sep 11, 2012 at 3:20 PM, Adam Barth aba...@webkit.org wrote: Currently, there's no way to get results from the bots. You might need to land your patch and see what the bots on build.webkit.org tell you. Adam On Tue, Sep 11, 2012 at 2:45 PM, John J Barton johnjbar...@johnjbarton.com wrote: On Bug 96040 (https://bugs.webkit.org/show_bug.cgi?id=96040) I posted a patch. The little oval thingys are all green except cr-linux. Clicking the failing oval gives a long file including these lines: Regressions: Unexpected text failures : (1) inspector/extensions/extensions-panel.html = TEXT This is a file I changed so I would like to know what failed in that test. It passes on my linux box. Any hints? jjb ___ 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] Initializing String and AtomicString with literals
The wiki might also note that: String bar = ASCIILiteral(foo); is not free. :) There is still a malloc() of a StringImpl under there. On Mon, Aug 27, 2012 at 12:26 PM, Benjamin Poulain benja...@webkit.org wrote: On Sun, Aug 26, 2012 at 10:15 AM, Ojan Vafai o...@chromium.org wrote: So, is the rule something like Use ASCIILiteral unless you can show improvement on a benchmark by using ConstructFromLiteral. Could you add some simple explanation like that to the wiki page? As someone who doesn't understand the implementation details, what's on the page right now doesn't give me a clear enough rule of when to use which. I think it is a good rule, I added your sentence to the Wiki page. 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
Re: [webkit-dev] Is the New XMLParser dead?
Checking back in: Curious if this effort is still underway. Adam and I would like to delete the New XML Parser if it's not needed in order to simplify the HTML 5 Parser again. :) On Thu, Mar 15, 2012 at 1:58 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 15, 2012, at 1:29 PM, Eric Seidel wrote: It seems the New XML Parser hasn't been touched in about 8 months: http://trac.webkit.org/browser/trunk/Source/WebCore/xml/parser Are there any plans to continue work on such, or can it be removed? The refactoring which was done to support it seems to mostly just confuse the HTML 5 Parser code... :( (I went looking for how something was implemented in the HTML5 parser... and it took me a long time to find it this afternoon). Yes, we plan to get more active on this effort again within a few months. Note that some of the refactoring was able to benefit the WebVTT parser, so we need some generic parser abstractions in any case. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] RenderStyleConstants.h - enum naming conventions?
E is an old style from KHTML.
We should update our style guide to say more than it does. :)
Enum members should user InterCaps with an initial capital letter.
[names-enum-members]
On Thu, Aug 23, 2012 at 11:53 PM, Glenn Adams gl...@skynav.com wrote:
I'm implementing a patch for [1], namely to support the CSS3 line-break
property.
[1] https://bugs.webkit.org/show_bug.cgi?id=89235
There is an older -{khtml,webkit}-line-break enum EKHTMLLineBreak defined in
RenderStyleConstants.h. I see that some enums use a 'E' prefix, while others
do not, e.g.,
enum ELineClampType { LineClampLineCount, LineClampPercentage };
vs
enum LineAlign { LineAlignNone, LineAlignEdges };
plus, there appears to be a different convention for enum member names,
e.g.,
enum EKHTMLLineBreak { LBNORMAL, AFTER_WHITE_SPACE };
Would it be better to have:
enum LineBreak { LineBreakNormal, LineBreakAfterWhiteSpace };
or, with the new keywords from CSS3 Text line-break, write this as:
enum LineBreak { LineBreakAuto, LineBreakLoose, LineBreakNormal,
LineBreakStrict, LineBreakAfterWhiteSpace };
___
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] RenderStyleConstants.h - enum naming conventions?
Sorry, I was unclear. I haven't seen someone create a new enum using
E in years. LineBreakType or similar would be better than
ELineBreakType.
On Thu, Aug 23, 2012 at 11:57 PM, Eric Seidel e...@webkit.org wrote:
E is an old style from KHTML.
We should update our style guide to say more than it does. :)
Enum members should user InterCaps with an initial capital letter.
[names-enum-members]
On Thu, Aug 23, 2012 at 11:53 PM, Glenn Adams gl...@skynav.com wrote:
I'm implementing a patch for [1], namely to support the CSS3 line-break
property.
[1] https://bugs.webkit.org/show_bug.cgi?id=89235
There is an older -{khtml,webkit}-line-break enum EKHTMLLineBreak defined in
RenderStyleConstants.h. I see that some enums use a 'E' prefix, while others
do not, e.g.,
enum ELineClampType { LineClampLineCount, LineClampPercentage };
vs
enum LineAlign { LineAlignNone, LineAlignEdges };
plus, there appears to be a different convention for enum member names,
e.g.,
enum EKHTMLLineBreak { LBNORMAL, AFTER_WHITE_SPACE };
Would it be better to have:
enum LineBreak { LineBreakNormal, LineBreakAfterWhiteSpace };
or, with the new keywords from CSS3 Text line-break, write this as:
enum LineBreak { LineBreakAuto, LineBreakLoose, LineBreakNormal,
LineBreakStrict, LineBreakAfterWhiteSpace };
___
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] What's the proper care and feeding of the Apple Mac Lion Pixel Results?
I'm attempting to fix some repaint bugs in WebKit, thus I'm using the --pixel tests. run-webkit-tests -p fast/repaint shows a bunch of failures on my Mac Lion box. I'd like to fix those failures, but I'm not sure what the proper procedure is. run-webkit-tests -p fast/repaint --reset-results changes nearly 200 pngs! in fast/repaint (presumably due to changed checksums embedded in the pngs?) Is there a proper way to maintain pngs for the Apple Mac Lion port? Should I just check mine in? Thanks! -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] PSA: removing CSS3_FLEXBOX define
Do we know what ports have CSS3_FLEXBOX enabled? On Fri, Aug 17, 2012 at 6:47 PM, Ojan Vafai o...@chromium.org wrote: Next week we plan to remove the CSS3_FLEXBOX define again. We had added it back in because the spec was about to change a lot (mostly renaming). At this point the spec is stable and has been approved to go to CR. Also, our implementation has been fuzz-tested for crashes/memory errors. I'm fairly confident in the code and API stability at this point. Is there any port that doesn't want this enabled? If not, we'll remove the define. Sometime in the next couple months we also plan to check our compatibility with other implementations (if there are any shipping by that time) and remove the vendor prefix. Ojan ___ 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 to remove list-item special counter
Since it sounds like it doesn't do anything, then yes. Removing it
sounds like the correct course of action. Someone who later
implements ::marker or lands CSS3-list tests, can revert your patch.
On Wed, Aug 15, 2012 at 2:29 PM, Elliott Sprehn espr...@chromium.org wrote:
WebKit is the only browser that implements the magic counter named
list-item and we have no tests for it. This is from the CSS3 Lists module
(http://dev.w3.org/csswg/css3-lists/). This special counter was added back
in the initial implementation of CSS counters 6 years ago.
ex.
style li:before { content: ( counter(list-item) ); } /style
ol
li
/ol
It's not useful since we don't support the ::marker psuedo element, nor does
any other browser. The above example outputs (2) since the implied counter
increment is on the list marker which we don't actually support. I can't
find references to this thing in Google outside the spec itself either.
Can I remove this feature?
- Elliott
___
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] svns...@macosforge.org ?
Bill would know. On Tue, Aug 14, 2012 at 1:58 AM, Philippe Normand ph...@igalia.com wrote: On Wed, 2012-08-08 at 13:52 -0700, Adam Barth wrote: I noticed today that some patches are authored by svns...@macosforge.org: http://trac.webkit.org/search?q=svnsync Is this behavior expected? I guess this is a bug in one of the SVN commit hooks? Philippe ___ 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] Is bugzilla down ?
I think the notice was simply lost in all the bike-shedding of late. :) Thank you Bill for taking care of the migration. I saw and appreciated your email notice earlier. -eric On Thu, Jul 19, 2012 at 7:00 PM, Ryosuke Niwa rn...@webkit.org wrote: If it weren't too much trouble, it might be nice to show some kind of under maintenance page in the future so that we know for sure it's due to the migration instead of migration-related outage. - Ryosuke On Thu, Jul 19, 2012 at 6:36 PM, William Siegrist wsiegr...@apple.com wrote: See my earlier email about the migration. -Bill On Jul 19, 2012, at 6:31 PM, Gyuyoung Kim gyuyoung@samsung.com wrote: Hi webkit folks, I can't aceess bugs.webkit.org now. It looks bugzilla system is not working correctly. Is bugzilla dead ? Gyuyoung. ___ 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web APIs and class name collisions
bikeshedding Just like we don't call the class DOMDocument, there is no need to add the CSS prefix where there aren't collisions (IMO). I do think we should drop the WebKit prefix from all classes, and use InterfaceName= the .idl to map from InternalName to WebKitExternalName. http://trac.webkit.org/wiki/WebKitIDL#InterfaceName /bikeshedding On Fri, Jul 13, 2012 at 7:17 AM, Andrei Bucur abu...@adobe.com wrote: CSSRegion is it then! I'll also make a patch to rename WebKitNamedFlow into CSSNamedFlow. Thx! Andrei. On 7/12/12 10:37 PM, Alexis Menard alexis.men...@openbossa.org wrote: So far in the css/ directory we tried to renamed slowly classes so that : CSS* prefixed classes are the implementation of CSSOM whatevername is for internal classes. For example we renamed CSSStyleApplyProperty class to StyleBuilder because it's internal. Hope that helps. On Thu, Jul 12, 2012 at 2:52 PM, Simon Fraser simon.fra...@apple.com wrote: I'd prefer we keep Region for the low-level graphics primitive Region (just like Path), and use something prefixed for the higher-level layout concept. Simon On Jul 12, 2012, at 10:26 AM, Dana Jansens wrote: On Thu, Jul 12, 2012 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote: I'd vote for CSSRegion or CSSOMRegion for the class you're adding but I'll also suggest we rename the existing Region class now that the term region has a specific semantic in CSS. Maybe LayoutRegion or ScreenRegion? IntRegion? It seems closer to an IntRect than a LayoutRect. - Ryosuke On Jul 12, 2012 10:13 AM, Eric Seidel e...@webkit.org wrote: I would go with CSSRegion, and stick it in the css/ folder. Much of the CSS folder is our implementation of the CSS Object Model (CSSOM). At some point it might make sense to pull all the classes which implement the CSSOM out of css/ into a new cssom/ similar to dom/, but that's a later discussion. -eric On Thu, Jul 12, 2012 at 10:03 AM, Andrei Bucur abu...@adobe.com wrote: From my knowledge the CSS prefix is reserved for the CSS engine classes in WebKit. Prefixing the Region class with CSS could prove confusing. Regards, Andrei. From: Alan Stearns stea...@adobe.com Date: Thursday, July 12, 2012 7:39 PM To: Adam Barth aba...@webkit.org, Andrei Bucur abu...@adobe.com Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Web APIs and class name collisions The spec itself consistently and deliberately calls them CSS Regions, so a CSS prefix could be appropriate. Thanks, Alan From: Adam Barth aba...@webkit.org To: Andrei Bucur abu...@adobe.com Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Web APIs and class name collisions One common thing we do is prefix DOM to DOM-level concepts. For example, DOMWindow and DOMFileSystem. I'm not sure if we have an established convention for CSS-level concepts. Adam On Thu, Jul 12, 2012 at 9:18 AM, Andrei Bucur abu...@adobe.com wrote: Hello Webkittens! While implementing the Region interface ( http://dev.w3.org/csswg/css3-regions/#the-region-interface ) I've noticed that the name Region is already taken by a class in platform/graphics. I'd like to know what's the best approach in these kind of situations: Rename the existing WebCore class to something else and use the name Region for the Web API so there's parity between the implementation and the spec Somehow prefix the Web API implementation class name? As the Web APIs expand I suppose this situation may occur again in the future and I suppose there should be a rule describing what's the best approach to take. Thanks! Andrei. ___ 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 ___ 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 -- Alexis Menard (darktears) Software Engineer openBossa @ INdT - Instituto Nokia de Tecnologia ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Web APIs and class name collisions
I for one, very much appreciate your cleanup/organizational efforts! On Thu, Jul 12, 2012 at 12:37 PM, Alexis Menard alexis.men...@openbossa.org wrote: So far in the css/ directory we tried to renamed slowly classes so that : CSS* prefixed classes are the implementation of CSSOM whatevername is for internal classes. For example we renamed CSSStyleApplyProperty class to StyleBuilder because it's internal. Hope that helps. On Thu, Jul 12, 2012 at 2:52 PM, Simon Fraser simon.fra...@apple.com wrote: I'd prefer we keep Region for the low-level graphics primitive Region (just like Path), and use something prefixed for the higher-level layout concept. Simon On Jul 12, 2012, at 10:26 AM, Dana Jansens wrote: On Thu, Jul 12, 2012 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote: I'd vote for CSSRegion or CSSOMRegion for the class you're adding but I'll also suggest we rename the existing Region class now that the term region has a specific semantic in CSS. Maybe LayoutRegion or ScreenRegion? IntRegion? It seems closer to an IntRect than a LayoutRect. - Ryosuke On Jul 12, 2012 10:13 AM, Eric Seidel e...@webkit.org wrote: I would go with CSSRegion, and stick it in the css/ folder. Much of the CSS folder is our implementation of the CSS Object Model (CSSOM). At some point it might make sense to pull all the classes which implement the CSSOM out of css/ into a new cssom/ similar to dom/, but that's a later discussion. -eric On Thu, Jul 12, 2012 at 10:03 AM, Andrei Bucur abu...@adobe.com wrote: From my knowledge the CSS prefix is reserved for the CSS engine classes in WebKit. Prefixing the Region class with CSS could prove confusing. Regards, Andrei. From: Alan Stearns stea...@adobe.com Date: Thursday, July 12, 2012 7:39 PM To: Adam Barth aba...@webkit.org, Andrei Bucur abu...@adobe.com Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Web APIs and class name collisions The spec itself consistently and deliberately calls them CSS Regions, so a CSS prefix could be appropriate. Thanks, Alan From: Adam Barth aba...@webkit.org To: Andrei Bucur abu...@adobe.com Cc: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Web APIs and class name collisions One common thing we do is prefix DOM to DOM-level concepts. For example, DOMWindow and DOMFileSystem. I'm not sure if we have an established convention for CSS-level concepts. Adam On Thu, Jul 12, 2012 at 9:18 AM, Andrei Bucur abu...@adobe.com wrote: Hello Webkittens! While implementing the Region interface ( http://dev.w3.org/csswg/css3-regions/#the-region-interface ) I've noticed that the name Region is already taken by a class in platform/graphics. I'd like to know what's the best approach in these kind of situations: Rename the existing WebCore class to something else and use the name Region for the Web API so there's parity between the implementation and the spec Somehow prefix the Web API implementation class name? As the Web APIs expand I suppose this situation may occur again in the future and I suppose there should be a rule describing what's the best approach to take. Thanks! Andrei. ___ 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 ___ 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 -- Alexis Menard (darktears) Software Engineer openBossa @ INdT - Instituto Nokia de Tecnologia ___ 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] Please include function-level comments in change log entries
Per: You began by thread-jacking Dan's discussion of ChangeLogs, and now appear to be attacking a seasoned contributors polite response with sarcasm and derision. I recommend you soften your words, and try again on another thread. Commenting, or lack there of, has been discussed at great length on previous webkit-dev threads. I'm sure there are many things we could continue to discuss, but I recommend doing so in a friendlier tone, on a separate thread. I would recommend that we close this thread, Dan's original email was simple a Public Service Announcement. Thank you all, and happy hacking! On Fri, Jul 6, 2012 at 12:54 PM, Per Bothner per.both...@oracle.com wrote: On 07/06/2012 11:41 AM, Ryosuke Niwa wrote: Indeed, we try to avoid adding comments as much as possible since comments tend to get out-of-date very quickly, we don't want to be spending all our time updating comments. Heavens forbid that someone who actually understands the code should have to update the comments once in a while. Better to keep it inscrutable so newbies spend all of *their* time trying to figure it all out. Instead, we try to refactor code so that code is self-evident or add assertions to codify the comments. You're deluding yourself if you think the code (or any code this large and complicated) is or can be self-evident. I find it quite painful to figure out my way through the WebKit code-base, and I'm hardly inexperienced. The biggest annoyance I found is lack of class-level comments. For example what is an Interpreter? How many instances are there in the system? (I.e. is it a singleton class? Is there one per window? One per thread?) What is the relationship to JSGlobalData, JSGlobalObject, RootObject. There are a lot of these classes, and it takes quite a bit of staring at the code to figure it out. Worse, it's hard to remember it all, so if I come back to the codebase after working on something else I have to figure out all out again: I might remember some aspects (like a class starting with JS is probably some kind of JavaScript object), but not a lot of other relationships and properties of the classes. Those of you who work on WebKit all the time might be comfortable with the lack of comments, but I think it's a misguided and unfriendly policy. Of course sometimes I fail to comments classes and functions where I should, but I understand that's a bug, not a feature, -- --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] Putting your own Webkit variant back into the Nightly build WebKit App
You want the build-* scripts in this directory: http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport I also think you want the webkit-help mailing list instead of webkit-dev. I believe it's supposed to cover these sorts of topics. :) Last I knew, Mark Rowe wrote those scripts and maintains nightly.webkit.org. If you manage to find him, he's probably the right person to talk to. Best of luck! On Fri, Jun 29, 2012 at 3:07 PM, Mark Gilbert web...@gallery.co.uk wrote: Hi Folks. I wonder if someone could help me figure out how to move my newly compiled WebKit (with tweaks) into the bundle of the Nightly build application. I want to have a self contained browser running with my webkit-variation. I did manage to do this once last year, and I have the self contained app to prove it, but I don't appear to be able to repeat the feat a year later with a newer set of code. Probably I have forgotten a step and I am missing out something All I am doing is copying the 4 frameworks out of my release folder and replacing the ones in the nightly build folder (in the 10.7 subfolder, since I am testing on 10.7). Whilst my build does what I expect when I use run-safari, the re-bundled Nightly Build webkit app seems to be reverting to the built in webkit, (or at least 'another' web kit without my changes). Maybe I need to copy the frameworks into the 10.6 folder as well ?? Could anyone offer any advice? Thanks. Mark. ___ 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] [PATCH] Errors from build-webkit --debug --minimal
If someone wanted to set up a --minimal bot, I'm sure that would be welcome. We used to have a --qt --minimal bot at some point. http://trac.webkit.org/wiki/BuildBot On Mon, Jun 25, 2012 at 12:28 PM, Pablo Flouret pab...@motorola.com wrote: On Mon, 25 Jun 2012 12:03:12 -0700, Arthur O'Dwyer art...@push.am wrote: I'm trying to build WebKit by the simplest possible method. I checked out the SVN tree and did cd WebKit ; Tools/Scripts/build-webkit --debug --minimal. This produced compiler errors! I tried the same thing a while ago, and submitted patches to fix some of the issues, but what i was told is that there aren't really any bots building with --minimal, so it's not guaranteed to build. Last i remember, after you fix those issues you mention you're probably gonna come up against trickier ones in --web-audio, --geolocation, --netscape-plugin-api and --fullscreen-api (although i haven't checked recently). You can still run --minimal and enable the features that are giving you trouble (e.g. build-webkit --debug --minimal --javascript-debugger --geolocation ... etc.) Cheers, -- pablo flouret motorola | webkit / browser team ___ 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
