[webkit-dev] Cleaning House
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] Fwd: WebKit2 Extending Javascript
Hi My problem is that I have to extend Javascript in WebKit2. That is, I have to add a set of global variables and functions. Potentially I also need to add custom classes. However, this doesn't seem to be possible in WebKit2 since it is not yet supported. Can you help me on this matter? -- Best regards Christian ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
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. FWIW, mrobinson has been working on a GYP build for the GTK port, so I wouldn't delete all of the .gyp files (at least not w/o them weighing in on it). I thought there was some interest at Apple in also using GYP, but perhaps things have (or will) change given that interop w/ Chromium is no longer the big plus it would've been. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Thursday 04 April 2013, Geoffrey Garen 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 Unless you plan to scare more ports away, I would suggest double checking stuff to remove. As far as I know BlackBerry and EFL are using Skia, and I am sure there are ports using GoogleURL as well. For the record though I don't think Qt is using any of that those. Regards `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Hi, EFL port is using Cairo, not Skia. Kr, Christophe DUMEZ. From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Allan Sandfeld Jensen [k...@carewolf.com] Sent: Thursday, April 04, 2013 11:39 To: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Cleaning House On Thursday 04 April 2013, Geoffrey Garen 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 Unless you plan to scare more ports away, I would suggest double checking stuff to remove. As far as I know BlackBerry and EFL are using Skia, and I am sure there are ports using GoogleURL as well. For the record though I don't think Qt is using any of that those. Regards `Allan ___ 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
BlackBerry is moving away from Skia, a removal wouldn't hurt us at this point. With EFL being on cairo, it seems like that item can stay on the list.- Jakob From: Allan Sandfeld JensenSent: Thursday, April 4, 2013 4:39 AMTo: webkit-dev@lists.webkit.orgSubject: Re: [webkit-dev] Cleaning HouseOn Thursday 04 April 2013, Geoffrey Garen 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 Unless you plan to scare more ports away, I would suggest double checking stuff to remove. As far as I know BlackBerry and EFL are using Skia, and I am sure there are ports using GoogleURL as well.For the record though I don't think Qt is using any of that those.Regards`Allan___webkit-dev mailing listwebkit-dev@lists.webkit.orghttps://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
On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Thursday 04 April 2013, Geoffrey Garen 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 Unless you plan to scare more ports away, I would suggest double checking stuff to remove. As far as I know BlackBerry and EFL are using Skia, and I am sure there are ports using GoogleURL as well. For the record though I don't think Qt is using any of that those. Geoff posted the list in part because we'd like to know if any of the things above are used by other ports. We're not planning to remove things still in use. It would be good to know specifics. I could not find evidence of other ports using GoogleURL for instance. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Thursday 04 April 2013, jpe...@gmx.at wrote: BlackBerry is moving away from Skia, a removal wouldn't hurt us at this point. With EFL being on cairo, it seems like that item can stay on the list. Ah, right. Sorry for the confusion. I had the impression with all the places Skia specific code appears that it was used by more ports. I would be good to get that cleaned up. `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Geoffrey Garen gga...@apple.com writes: Also: Adopt libc++ My FreeBSD hat appreciates that, but can you elaborate? Is there something specific to libc++ not present in, say, libstdc++, that is going to be used? -- Intel Finland Oy Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
GoogleURL seems Chromium-specific, i.e. WTF_USE_GOOGLEURL is only defined for Chromium in Source/WebCore/config.h. Regards, -Z On Thu, Apr 4, 2013 at 10:50 AM, Maciej Stachowiak m...@apple.com wrote: On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Thursday 04 April 2013, Geoffrey Garen 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 Unless you plan to scare more ports away, I would suggest double checking stuff to remove. As far as I know BlackBerry and EFL are using Skia, and I am sure there are ports using GoogleURL as well. For the record though I don't think Qt is using any of that those. Geoff posted the list in part because we'd like to know if any of the things above are used by other ports. We're not planning to remove things still in use. It would be good to know specifics. I could not find evidence of other ports using GoogleURL for instance. 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
Re: [webkit-dev] Cleaning House
Hi, On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: [...] #if USE(V8) #if !USE(JSC) Here at Samsung we are using WebKitGTK+ and V8, and I bet we are not the only ones doing it, so it would be great to keep those guards there. Geoff posted the list in part because we'd like to know if any of the things above are used by other ports. We're not planning to remove things still in use. Cool, thanks. Mario ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Hey, On Qui, 2013-04-04 at 01:22 -0700, Dirk Pranke wrote: FWIW, mrobinson has been working on a GYP build for the GTK port, so I wouldn't delete all of the .gyp files (at least not w/o them weighing in on it). I thought there was some interest at Apple in also using GYP, but perhaps things have (or will) change given that interop w/ Chromium is no longer the big plus it would've been. We discussed this briefly yesterday and we seem to have a consensus there's no point in going further with that plan, since there's nobody else showing interest right now (if we're wrong let us know!). We will try to adopt cmake instead. Cheers, -- Gustavo Noronha Silva g...@gnome.org GNOME Project ___ 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
From: webkit-dev-boun...@lists.webkit.org [webkit-dev-boun...@lists.webkit.org] on behalf of Eric Seidel [e...@webkit.org] Sent: Thursday, April 04, 2013 9:41 AM To: Geoffrey Garen Cc: webkit-dev@lists.webkit.org Development Subject: Re: [webkit-dev] Cleaning House 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. To avoid getting new hardware, couldn't commit-queue be changed to use Qt or Gtk on Linux? Joe - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Geoffrey Garen gga...@apple.com writes: Concepts we plan to remove: Features #defines that haven't gained traction Do you already have anything in mind? Is the process described in the DeprecatingFeatures article on the wiki still going to be followed? -- Intel Finland Oy Open Source Technology Center ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Thu, Apr 4, 2013 at 3:56 AM, Mario Sanchez Prada mario.pr...@samsung.com wrote: On Apr 4, 2013, at 1:39 AM, Allan Sandfeld Jensen k...@carewolf.com wrote: [...] #if USE(V8) #if !USE(JSC) Here at Samsung we are using WebKitGTK+ and V8, and I bet we are not the only ones doing it, so it would be great to keep those guards there. Honestly, I don't see how this would be maintainable going forward. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On 04/04/2013 03:15 PM, Gustavo Noronha Silva wrote: Hey, On Qui, 2013-04-04 at 01:22 -0700, Dirk Pranke wrote: FWIW, mrobinson has been working on a GYP build for the GTK port, so I wouldn't delete all of the .gyp files (at least not w/o them weighing in on it). I thought there was some interest at Apple in also using GYP, but perhaps things have (or will) change given that interop w/ Chromium is no longer the big plus it would've been. We discussed this briefly yesterday and we seem to have a consensus there's no point in going further with that plan, since there's nobody else showing interest right now (if we're wrong let us know!). We will try to adopt cmake instead. Do you mean adopting cmake for the whole project, or just for Gtk? Cheers, ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Apr 4, 2013, at 2:01 AM, Raphael Kubo da Costa rak...@webkit.org wrote: Geoffrey Garen gga...@apple.com writes: Also: Adopt libc++ My FreeBSD hat appreciates that, but can you elaborate? Is there something specific to libc++ not present in, say, libstdc++, that is going to be used? I think this should be “require libc++ on Mac”. The Chromium port used libstdc++ since it had to build on Snow Leopard as well IIRC. - Anders ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
I would strongly suggest purging V8, for the many performance and code complexity reasons Google is removing JSC from blink. (See www.chromium.org/blink/developer-faq) I'd also suggest purging the chromium layout tests ASAP so we can enjoy the much-reduced archive sync costs. -Brent Sent from my iPhone On Apr 4, 2013, at 9:46 AM, Balazs Kelemen kbal...@webkit.org wrote: On 04/04/2013 03:15 PM, Gustavo Noronha Silva wrote: Hey, On Qui, 2013-04-04 at 01:22 -0700, Dirk Pranke wrote: FWIW, mrobinson has been working on a GYP build for the GTK port, so I wouldn't delete all of the .gyp files (at least not w/o them weighing in on it). I thought there was some interest at Apple in also using GYP, but perhaps things have (or will) change given that interop w/ Chromium is no longer the big plus it would've been. We discussed this briefly yesterday and we seem to have a consensus there's no point in going further with that plan, since there's nobody else showing interest right now (if we're wrong let us know!). We will try to adopt cmake instead. Do you mean adopting cmake for the whole project, or just for Gtk? Cheers, ___ 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
On Apr 4, 2013, at 10:03 AM, Brent Fulgham bfulg...@gmail.com wrote: I would strongly suggest purging V8, for the many performance and code complexity reasons Google is removing JSC from blink. (See www.chromium.org/blink/developer-faq) +1 I'd also suggest purging the chromium layout tests ASAP so we can enjoy the much-reduced archive sync costs. -Brent Sent from my iPhone On Apr 4, 2013, at 9:46 AM, Balazs Kelemen kbal...@webkit.org wrote: On 04/04/2013 03:15 PM, Gustavo Noronha Silva wrote: Hey, On Qui, 2013-04-04 at 01:22 -0700, Dirk Pranke wrote: FWIW, mrobinson has been working on a GYP build for the GTK port, so I wouldn't delete all of the .gyp files (at least not w/o them weighing in on it). I thought there was some interest at Apple in also using GYP, but perhaps things have (or will) change given that interop w/ Chromium is no longer the big plus it would've been. We discussed this briefly yesterday and we seem to have a consensus there's no point in going further with that plan, since there's nobody else showing interest right now (if we're wrong let us know!). We will try to adopt cmake instead. Do you mean adopting cmake for the whole project, or just for Gtk? Cheers, ___ 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
On Thu, Apr 4, 2013 at 10:34 AM, Geoffrey Garen gga...@apple.com wrote: What would it take for WebKitGTK+ to adopt the JSC bindings? Just for clarity's sake. WebKitGTK+ only supports JSC, but it seems there are some external branches/forks using V8. In the past, we've rejected proposals to add V8 support to WebKitGTK+. --Martin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Is the process described in the DeprecatingFeatures article on the wiki still going to be followed? Yes. I'm generally talking about features that will fall under the Cold turkey approach, based on rough consensus that they are either unsupported or unused. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Hi Martin. Just for clarity's sake. WebKitGTK+ only supports JSC, but it seems there are some external branches/forks using V8. In the past, we've rejected proposals to add V8 support to WebKitGTK+. OK, I think that pretty much confirms that no WebKit contributors are maintaining the v8 bindings. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Apr 4, 2013, at 10:37 AM, Martin Robinson mrobin...@webkit.org wrote: On Thu, Apr 4, 2013 at 10:34 AM, Geoffrey Garen gga...@apple.com wrote: What would it take for WebKitGTK+ to adopt the JSC bindings? Just for clarity's sake. WebKitGTK+ only supports JSC, but it seems there are some external branches/forks using V8. In the past, we've rejected proposals to add V8 support to WebKitGTK+. Geoffrey has a good point. V8 will develop along Blink. With a diverging Blink implementation from WebKit, the JS ABI must change as well. It is not clear if the V8 team is willing to make V8 compatible with other rendering engines, or if they even are able to. I expect that this won't be possible quite soon. WebKit projects should consider moving to, or moving back to JSC. Allowing both projects to continue quickly. Greetings, Dirk --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] Cleaning House
On Thu, Apr 4, 2013 at 11:03 AM, Brent Fulgham bfulg...@gmail.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. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Fwd: Cleaning House
On Thu, Apr 4, 2013 at 11:10 AM, Glenn Adams gl...@skynav.com wrote: On Thu, Apr 4, 2013 at 11:03 AM, Brent Fulgham bfulg...@gmail.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. We've been doing that. It's just that someone recently caused flakiness, and we had to stop runnings tests on Mac WebKit1. But we have been running tests on EWS for years. Having said that, we should probably just rebaseline all image results and turn on pixel tests on Mac. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
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
Re: [webkit-dev] Cleaning House
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
Re: [webkit-dev] Thank You
I may miss some mails, but I didn't see a proper reply for this mail. Personally, I think WebKit and its community should also be grateful to you guys. You did a lot for WebKit as well. Although the cooperation was not always smooth, let's just keep the good memories. I wish you luck for your Blink project. Regards, Zoltan 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
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
Re: [webkit-dev] Cleaning House
On Thu, Apr 4, 2013 at 1:44 PM, Filip Pizlo fpi...@apple.com wrote: Sent from my PDP-11 11/20? 11/40? RSX-11? RT-11? Love the split I/D memory on 11/70s. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Thu, Apr 4, 2013 at 1: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. +1 ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Hi, On Apr 4, 2013, at 12:50 PM, Geoffrey Garen gga...@apple.com wrote: (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. +1 -Brent ___ 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
Re: [webkit-dev] Cleaning House
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. I've posted a patch to turn off the tests on the cr-* EWS bots (though we'll still try to compile). https://bugs.webkit.org/show_bug.cgi?id=113959. Obviously, we can simply turn the bots off whenever they're no longer useful as well. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Status of Windows Port?
Considering Safari 6 is Mac only, and the departing of Chromium (the defacto Windows WebKit browser until yesterday) what is the current status of the Windows port? The webkit.org instructions still reference Visual Studio 2005 for instance Any interest in making it a first class citizen again so that Windows users can potentially have a official WebKit(2) browser and application developers have a more or less officially supported library that isn't Chromium based? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Status of Windows Port?
On Thu, Apr 4, 2013 at 2:37 PM, Justin Haygood justin.hayg...@reaktix.comwrote: Considering Safari 6 is Mac only, and the departing of Chromium (the defacto Windows WebKit browser until yesterday) what is the current status of the Windows port? The webkit.org instructions still reference Visual Studio 2005 for instance We should update that! Any interest in making it a first class citizen again so that Windows users can potentially have a official WebKit(2) browser and application developers have a more or less officially supported library that isn't Chromium based? There is one: Qt. The Qt port uses WebKit2 and supports Windows :) I would prefer seeing more work on existing stable ports to make them better rather than spreading the effort on a new port. Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Apple is taking over the commit queue
Hi all, Lucas and I are working hard to take over the ownership of the WebKit commit queue today. Thanks for your cooperation and patience. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Status of Windows Port?
If Qt is the way to support Windows, it would need some work to make it easy to integrate into an existing non-Qt Windows application. From memory, that isn't the easiest thing in the world to do. From: Benjamin Poulain benja...@webkit.orgmailto:benja...@webkit.org Date: Thursday, April 4, 2013 5:42 PM To: Justin Haygood justin.hayg...@reaktix.commailto:justin.hayg...@reaktix.com Cc: webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org webkit-dev@lists.webkit.orgmailto:webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Status of Windows Port? On Thu, Apr 4, 2013 at 2:37 PM, Justin Haygood justin.hayg...@reaktix.commailto:justin.hayg...@reaktix.com wrote: Considering Safari 6 is Mac only, and the departing of Chromium (the defacto Windows WebKit browser until yesterday) what is the current status of the Windows port? The webkit.orghttp://webkit.org instructions still reference Visual Studio 2005 for instance We should update that! Any interest in making it a first class citizen again so that Windows users can potentially have a official WebKit(2) browser and application developers have a more or less officially supported library that isn't Chromium based? There is one: Qt. The Qt port uses WebKit2 and supports Windows :) I would prefer seeing more work on existing stable ports to make them better rather than spreading the effort on a new port. Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Status of Windows Port?
We are also maintaining the WebKit1 Windows port at Apple. On Apr 4, 2013, at 3:09 PM, Justin Haygood justin.hayg...@reaktix.com wrote: If Qt is the way to support Windows, it would need some work to make it easy to integrate into an existing non-Qt Windows application. From memory, that isn't the easiest thing in the world to do ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Status of Windows Port?
On Thu, Apr 4, 2013 at 3:09 PM, Justin Haygood justin.hayg...@reaktix.comwrote: If Qt is the way to support Windows, it would need some work to make it easy to integrate into an existing non-Qt Windows application. From memory, that isn't the easiest thing in the world to do. I don't know exactly what is the problem with integrating Qt...but I think fixing that will be far less work than making a new WebKit2 port from scratch. WebKitGTK+ also run on Windows. But I don't know if it supports WebKit2. And there is always WebKit1 support for Windows... Cheers, Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Upcoming Contributors Meeting
Any update on the upcoming contributors meeting [1]? Logistics? Agenda? [1] http://trac.webkit.org/wiki/May%202013%20Meeting ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Status of Windows Port?
Hi Justin, On Apr 4, 2013, at 2:37 PM, Justin Haygood justin.hayg...@reaktix.com wrote: The webkit.org instructions still reference Visual Studio 2005 for instance We have full VS2010 support in SVN now; we haven't updated the instructions yet as the build/test machines are not cut over yet. Any interest in making it a first class citizen again so that Windows users can potentially have a official WebKit(2) browser and application developers have a more or less officially supported library that isn't Chromium based? WebKit on Windows is a first class citizen: Apple's WebKit port My WinCairo port WK2 support is lacking at the moment, but that would change if people were interested in contributing, Thanks, -Brent ___ 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
On 04/04/2013 10:21 AM, Oliver Hunt wrote: Supporting V8 places a considerable burden on webkit, there are a number of large, cumbersome and expensive abstractions required for to support multiple JS engines (see the original discussions on the topic from many years ago). We at Oracle are working on using WebKit with our own JavaScript engine, Nashorn: http://openjdk.java.net/projects/nashorn/ This is for the WebView component of JavaFX: http://docs.oracle.com/javafx/2/api/javafx/scene/web/package-summary.html This is still experimental, and no committed deliverable. However, it is obviously preferable in the eat-your-own-dogfood way that we use our own JavaScript engine, especially once that engine becomes part of the Java distribution. This is still in pretty rough shape, but we would find it unfortunate if if becomes more difficult to build WebKit with an alternative JavaScript engine. For the Nashorn port, I created a new WebCore/bindings/nashorn directory in parallel to WebCore/bindings/js and WebCore/bindings/v8. We generate .java class from the .idl file. No JavaScript classes are ever created. Instead Nashorn provides an on-the-fly bridge to the Java objects. -- --Per Bothner per.both...@oracle.com p...@bothner.com http://per.bothner.com/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Supporting multiple JS engines is a major burden, and prevents us from doing optimizations that more seamlessly bridge the gap between DOM and JSC. I suspect we won't want to continue supporting multiple JS engines like we did when the Chrome folks used WebKit with V8. -Filip On Apr 4, 2013, at 4:54 PM, Per Bothner per.both...@oracle.com wrote: On 04/04/2013 10:21 AM, Oliver Hunt wrote: Supporting V8 places a considerable burden on webkit, there are a number of large, cumbersome and expensive abstractions required for to support multiple JS engines (see the original discussions on the topic from many years ago). We at Oracle are working on using WebKit with our own JavaScript engine, Nashorn: http://openjdk.java.net/projects/nashorn/ This is for the WebView component of JavaFX: http://docs.oracle.com/javafx/2/api/javafx/scene/web/package-summary.html This is still experimental, and no committed deliverable. However, it is obviously preferable in the eat-your-own-dogfood way that we use our own JavaScript engine, especially once that engine becomes part of the Java distribution. This is still in pretty rough shape, but we would find it unfortunate if if becomes more difficult to build WebKit with an alternative JavaScript engine. For the Nashorn port, I created a new WebCore/bindings/nashorn directory in parallel to WebCore/bindings/js and WebCore/bindings/v8. We generate .java class from the .idl file. No JavaScript classes are ever created. Instead Nashorn provides an on-the-fly bridge to the Java objects. -- --Per Bothner per.both...@oracle.com p...@bothner.com http://per.bothner.com/ ___ 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] Apple is taking over the commit queue
We've started our experimental mac-mountainlion commit queue 13 minutes ago. We're going to add more machines once this one proved to be functional, and patches started to pile up on the queue. - R. Niwa - R. Niwa On Thu, Apr 4, 2013 at 3:00 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, Lucas and I are working hard to take over the ownership of the WebKit commit queue today. Thanks for your cooperation and patience. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
For the record though I don't think Qt is using any of that those. Qt 5.x uses V8. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Thu, Apr 4, 2013 at 6:01 PM, Markus kamika...@gmx.de wrote: For the record though I don't think Qt is using any of that those. Qt 5.x uses V8. QML uses V8. That does not matter for WebKit. QtWebKit uses exclusively JSC. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Apr 4, 2013, at 4:54 PM, Per Bothner per.both...@oracle.com wrote: On 04/04/2013 10:21 AM, Oliver Hunt wrote: Supporting V8 places a considerable burden on webkit, there are a number of large, cumbersome and expensive abstractions required for to support multiple JS engines (see the original discussions on the topic from many years ago). We at Oracle are working on using WebKit with our own JavaScript engine, Nashorn: http://openjdk.java.net/projects/nashorn/ This is for the WebView component of JavaFX: http://docs.oracle.com/javafx/2/api/javafx/scene/web/package-summary.html This is still experimental, and no committed deliverable. However, it is obviously preferable in the eat-your-own-dogfood way that we use our own JavaScript engine, especially once that engine becomes part of the Java distribution. This is still in pretty rough shape, but we would find it unfortunate if if becomes more difficult to build WebKit with an alternative JavaScript engine. For the Nashorn port, I created a new WebCore/bindings/nashorn directory in parallel to WebCore/bindings/js and WebCore/bindings/v8. We generate .java class from the .idl file. No JavaScript classes are ever created. Instead Nashorn provides an on-the-fly bridge to the Java objects. I think we'd be pretty reluctant to support this. Supporting multiple JS engines has been a pain, and we only agreed to it because it was a showstopper for Google, and we had the expectation that Google would be a valuable high-volume contributor. Which they were, during their time in the WebKit project. Even so, it caused significant code complexity, divergence of efforts, and friction on architectural direction, because of the differing characteristics of JSC and V8. I personally would be reluctant to make that type of deal again. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Re-enabling pixel tests
Now that all Chromium contributors are gone to work on Blink, I'd expect we will have much lower rate of commits. We've also converted quite few tests to text-only or ref-tests over the years. Can we do some mass rebaselines and re-enable pixel tests on Mac port now? It's really bad to have no pixel test coverage in WebKit. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Re-enabling pixel tests
On Thu, Apr 4, 2013 at 7:26 PM, Ryosuke Niwa rn...@webkit.org wrote: Now that all Chromium contributors are gone to work on Blink, I'd expect we will have much lower rate of commits. We've also converted quite few tests to text-only or ref-tests over the years. Can we do some mass rebaselines and re-enable pixel tests on Mac port now? It's really bad to have no pixel test coverage in WebKit. I would really like that. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Re-enabling pixel tests
On Apr 4, 2013, at 7:37 PM, Benjamin Poulain benja...@webkit.org wrote: On Thu, Apr 4, 2013 at 7:26 PM, Ryosuke Niwa rn...@webkit.org wrote: Now that all Chromium contributors are gone to work on Blink, I'd expect we will have much lower rate of commits. We've also converted quite few tests to text-only or ref-tests over the years. Can we do some mass rebaselines and re-enable pixel tests on Mac port now? It's really bad to have no pixel test coverage in WebKit. I would really like that. I agree in principle. We should start by removing all of the cross-platform pixel results that are no-alpha PNGs. However, whenever we've tried this in the past it's been a huge effort to maintain; OS updates require lots of rebaselining. Simon ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Re-enabling pixel tests
We should probably sort out some of our known and solvable OS-version-dependent color profile bugs *before* attempting any mass rebaselines, to avoid having to do them twice. On Apr 4, 2013, at 7:37 PM, Benjamin Poulain benja...@webkit.org wrote: On Thu, Apr 4, 2013 at 7:26 PM, Ryosuke Niwa rn...@webkit.org wrote: Now that all Chromium contributors are gone to work on Blink, I'd expect we will have much lower rate of commits. We've also converted quite few tests to text-only or ref-tests over the years. Can we do some mass rebaselines and re-enable pixel tests on Mac port now? It's really bad to have no pixel test coverage in WebKit. I would really like that. 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] Re-enabling pixel tests
On Thu, Apr 4, 2013 at 7:42 PM, Tim Horton timothy_hor...@apple.com wrote: We should probably sort out some of our known and solvable OS-version-dependent color profile bugs *before* attempting any mass rebaselines, to avoid having to do them twice. That sounds like a reasonable approach. With ImageOnlyFailures expectation, we can start from rebaselining ones that are OS-independent and gradually cover the entire test suite. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Deleting V8 bindings (was Cleaning House)
On Thu, Apr 4, 2013 at 7:08 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 4, 2013, at 4:54 PM, Per Bothner per.both...@oracle.com wrote: On 04/04/2013 10:21 AM, Oliver Hunt wrote: Supporting V8 places a considerable burden on webkit, there are a number of large, cumbersome and expensive abstractions required for to support multiple JS engines (see the original discussions on the topic from many years ago). We at Oracle are working on using WebKit with our own JavaScript engine, Nashorn: http://openjdk.java.net/projects/nashorn/ This is for the WebView component of JavaFX: http://docs.oracle.com/javafx/2/api/javafx/scene/web/package-summary.html This is still experimental, and no committed deliverable. However, it is obviously preferable in the eat-your-own-dogfood way that we use our own JavaScript engine, especially once that engine becomes part of the Java distribution. This is still in pretty rough shape, but we would find it unfortunate if if becomes more difficult to build WebKit with an alternative JavaScript engine. For the Nashorn port, I created a new WebCore/bindings/nashorn directory in parallel to WebCore/bindings/js and WebCore/bindings/v8. We generate .java class from the .idl file. No JavaScript classes are ever created. Instead Nashorn provides an on-the-fly bridge to the Java objects. I think we'd be pretty reluctant to support this. Supporting multiple JS engines has been a pain, and we only agreed to it because it was a showstopper for Google, and we had the expectation that Google would be a valuable high-volume contributor. Which they were, during their time in the WebKit project. Even so, it caused significant code complexity, divergence of efforts, and friction on architectural direction, because of the differing characteristics of JSC and V8. I'm with Maciej and others. There is a huge opportunity in front us to improve the performance of WebKit by making more aggressive architectural changes if we only had to worry about one JS engine. On the other hand, I don't think optimizing WebCore for JSC doesn't necessarily mean it'll become impossible for you to have a custom build of WebKit that uses some other binding code. For example, Mac has Objective-C bindings and that's not going anywhere in the foreseeable future. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Apple is taking over the commit queue
I've temporarily disabled testing on the commit queue in http://trac.webkit.org/changeset/147695 since we haven't added enough hardwares to keep up with patches. I'll re-enable testing once we've got up to speed. Again, thanks for your cooperation and patience. Meanwhile, Let me know (just email me) if commit-queue is stuck or acting weird. - R. Niwa ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
