Re: [webkit-dev] Cleaning House
Hi, The Qt port of WebKit (based on Qt 5.x) does not use v8. (Qt 5.x uses v8 in other places, but that is not relevant to the WebKit project and this discussion) Simon 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. ___ 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 Geoff, First of all, let me say upfront that I see all the potential advantages of sticking to just one JS engine, and also perfectly understand the points that most of the people here have made on favour of not supporting multiple engines. Also, my mail was not really a formal request to keep the V8 bits around in the long term, but just a quick reply to the following comment from Maciej: 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. So, my position with regard to this is pretty much the same as Per's one, so I'll just quote him too: I'm not asking you to support an alternative JavaScript engine where it complicates the code. Just please keep in mind there are people who use WebKit *without* JSC. Now I will try to answer your questions... [...] Who do you envision maintaining the v8 bindings going forward? In an ideal world, I would see the people interested in using those bindings doing it. And as per the feedback received so far, I understand it's just us for the V8 bindings, and maybe Oracle for the more generic bits about supporting multiple JS engines. However, that depends on whether those who were interested in WebKit + !JSC keep their interest on that for the long term, and I don't think this is a question that can be answered right now, as it probably depends on some other decisions. What do you see as their value to the WebKit project? I'm not an expert on JS engines at all, so I just see the obvious short term benefit of not breaking right now WebKit+V8 configurations that might be in use, and a more long-term benefit of having the needed bits in place to support other JS engines different than V8. Now, whether those are good enough benefits to keep this part of the code around in the future or not is something I can't answer either. Do you see any cost to the WebKit project in maintaining the v8 bindings? Yes. I obviously see the cost and limitations imposed by having to maintain code to support more than one JS engine when, in most of the cases, only one (JSC) will be used. Also, considering that JSC will be the only one supported in WebKit2 suggests that whoever who try to use WebKit with other engine is going to have a hard time maintaining downstream patches that will probably be harder and harder to deal with over time. So yes, I'm not blind on this topic. I clearly see the drawbacks :) Does the benefit outweigh the cost? As I said, I'm not an expert on the matter, but after reading the comments here, I feel like benefit probably won't outweight the cost in the long run. What would it take for WebKitGTK+ to adopt the JSC bindings? Martin already kindly answered this. To finish this mail, I'd just like to stress again that I was not requesting to keep this code forever in my previous mail. My point was more about keeping those bits for a while, or that just giving a smaller priority to the removal, since that would probably be appreciated in the short term by those that are currently using engines other than JSC. Thanks, Mario ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Qui, 2013-04-04 at 18:46 +0200, Balazs Kelemen 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? I mean the GTK+ port only, sorry for the confusion. When I said 'We' I meant Martin Robinson and myself. 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
Also, WebP project is unfinished state right now. This changeset requires libwebp version 0.3.0: https://trac.webkit.org/changeset/147048 But version 0.3.0 also supports animated webp, and google doesn't have the code for animation support in WEBPImageDecoder.cpp yet, not even in Chromium. So this needs to be maintained somehow. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
Hi Mario. First of all, let me say upfront that I see all the potential advantages of sticking to just one JS engine, and also perfectly understand the points that most of the people here have made on favour of not supporting multiple engines. Also, my mail was not really a formal request to keep the V8 bits around in the long term, but just a quick reply to the following comment from Maciej: 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. So, my position with regard to this is pretty much the same as Per's one, so I'll just quote him too: I'm not asking you to support an alternative JavaScript engine where it complicates the code. Just please keep in mind there are people who use WebKit *without* JSC. Thanks for clarifying. It sounds like you're not asking us to maintain the v8 bindings. Who do you envision maintaining the v8 bindings going forward? In an ideal world, I would see the people interested in using those bindings doing it. And as per the feedback received so far, I understand it's just us for the V8 bindings, and maybe Oracle for the more generic bits about supporting multiple JS engines. However, that depends on whether those who were interested in WebKit + !JSC keep their interest on that for the long term, and I don't think this is a question that can be answered right now, as it probably depends on some other decisions. I apologize if this question was a little to Socratic. The point of the question was to identify real world challenges and solutions, not an ideal world. My understanding is that, in the real world, nobody is maintaining the v8 bindings. As of today, there are no v8 ports in WebKit trunk that build successfully. What do you see as their value to the WebKit project? I'm not an expert on JS engines at all, so I just see the obvious short term benefit of not breaking right now WebKit+V8 configurations that might be in use, and a more long-term benefit of having the needed bits in place to support other JS engines different than V8. Now, whether those are good enough benefits to keep this part of the code around in the future or not is something I can't answer either. Do you see any cost to the WebKit project in maintaining the v8 bindings? Yes. I obviously see the cost and limitations imposed by having to maintain code to support more than one JS engine when, in most of the cases, only one (JSC) will be used. Also, considering that JSC will be the only one supported in WebKit2 suggests that whoever who try to use WebKit with other engine is going to have a hard time maintaining downstream patches that will probably be harder and harder to deal with over time. So yes, I'm not blind on this topic. I clearly see the drawbacks :) Does the benefit outweigh the cost? As I said, I'm not an expert on the matter, but after reading the comments here, I feel like benefit probably won't outweight the cost in the long run. What would it take for WebKitGTK+ to adopt the JSC bindings? Martin already kindly answered this. To finish this mail, I'd just like to stress again that I was not requesting to keep this code forever in my previous mail. My point was more about keeping those bits for a while, or that just giving a smaller priority to the removal, since that would probably be appreciated in the short term by those that are currently using engines other than JSC. I'm not clear on what you're proposing here. How long should we wait to remove the v8 bindings? The uses of the v8 bindings I've heard of -- Oracle's Java project, a GTK project, and a Qt project -- are downstream adopters that don't work in WebKit trunk, and that can adjust to this change at their leisure. Since I haven't heard of a specific disruption that will happen to a WebKit trunk contributor, I'm planning to remove the v8 bindings today. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Friday 05 April 2013, Max Stepin wrote: Also, WebP project is unfinished state right now. This changeset requires libwebp version 0.3.0: https://trac.webkit.org/changeset/147048 To me it looks more like it requires 0.3.0 to enable color correction. Older ABIs are still supported. `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
To me it looks more like it requires 0.3.0 to enable color correction. Older ABIs are still supported. Yes, but some WebP images (created with 0.3.0) will not work. I tried, not even the first frame is displayed. Would it be OK to just take future WEBPImageDecoder.cpp updates from Chromium? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Friday 05 April 2013, Max Stepin wrote: To me it looks more like it requires 0.3.0 to enable color correction. Older ABIs are still supported. Yes, but some WebP images (created with 0.3.0) will not work. I tried, not even the first frame is displayed. Would it be OK to just take future WEBPImageDecoder.cpp updates from Chromium? I would guess that is the plan for all cross-engine relevant fixes as long as the internal APIs remain similar enough. `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Cleaning House
On Apr 5, 2013, at 5:25 AM, Mario Sanchez Prada mario.pr...@samsung.com wrote: Also, my mail was not really a formal request to keep the V8 bits around in the long term, but just a quick reply to the following comment from Maciej: 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. So, my position with regard to this is pretty much the same as Per's one, so I'll just quote him too: I'm not asking you to support an alternative JavaScript engine where it complicates the code. Just please keep in mind there are people who use WebKit *without* JSC. By in-use I meant by in-tree ports. I don't think it makes sense to keep functionality in trunk that is only used by out-of-tree ports, if it is costly to do so. The maintainers of the separate tree can make the effort to support extra functionality in their own branch. After all, if you have a private tree, you can make whatever changes you want in your own repository. It's not entirely fair to ask upstream to do that maintenance work for you. 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 Friday, April 05, 2013 09:24:59 AM Geoffrey Garen wrote: Hi Mario. First of all, let me say upfront that I see all the potential advantages of sticking to just one JS engine, and also perfectly understand the points that most of the people here have made on favour of not supporting multiple engines. Also, my mail was not really a formal request to keep the V8 bits around in the long term, but just a quick reply to the following comment from Maciej: 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. So, my position with regard to this is pretty much the same as Per's one, so I'll just quote him too: I'm not asking you to support an alternative JavaScript engine where it complicates the code. Just please keep in mind there are people who use WebKit *without* JSC. Thanks for clarifying. It sounds like you're not asking us to maintain the v8 bindings. Who do you envision maintaining the v8 bindings going forward? In an ideal world, I would see the people interested in using those bindings doing it. And as per the feedback received so far, I understand it's just us for the V8 bindings, and maybe Oracle for the more generic bits about supporting multiple JS engines. However, that depends on whether those who were interested in WebKit + !JSC keep their interest on that for the long term, and I don't think this is a question that can be answered right now, as it probably depends on some other decisions. I apologize if this question was a little to Socratic. The point of the question was to identify real world challenges and solutions, not an ideal world. My understanding is that, in the real world, nobody is maintaining the v8 bindings. As of today, there are no v8 ports in WebKit trunk that build successfully. What do you see as their value to the WebKit project? I'm not an expert on JS engines at all, so I just see the obvious short term benefit of not breaking right now WebKit+V8 configurations that might be in use, and a more long-term benefit of having the needed bits in place to support other JS engines different than V8. Now, whether those are good enough benefits to keep this part of the code around in the future or not is something I can't answer either. Do you see any cost to the WebKit project in maintaining the v8 bindings? Yes. I obviously see the cost and limitations imposed by having to maintain code to support more than one JS engine when, in most of the cases, only one (JSC) will be used. Also, considering that JSC will be the only one supported in WebKit2 suggests that whoever who try to use WebKit with other engine is going to have a hard time maintaining downstream patches that will probably be harder and harder to deal with over time. So yes, I'm not blind on this topic. I clearly see the drawbacks :) Does the benefit outweigh the cost? As I said, I'm not an expert on the matter, but after reading the comments here, I feel like benefit probably won't outweight the cost in the long run. What would it take for WebKitGTK+ to adopt the JSC bindings? Martin already kindly answered this. To finish this mail, I'd just like to stress again that I was not requesting to keep this code forever in my previous mail. My point was more about keeping those bits for a while, or that just giving a smaller priority to the removal, since that would probably be appreciated in the short term by those that are currently using engines other than JSC. I'm not clear on what you're proposing here. How long should we wait to remove the v8 bindings? The uses of the v8 bindings I've heard of -- Oracle's Java project, a GTK project, and a Qt project -- are downstream adopters that don't work in WebKit trunk, and that can adjust to this change at their leisure. Qt doesn't use it at all, Oracle use just the structure used to support multiple JS engines (that will probably vanish after v8 removal), not the v8 bindings. Since I haven't heard of a specific disruption that will happen to a WebKit trunk contributor, I'm planning to remove the v8 bindings today. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev signature.asc Description: This is a digitally signed message part. ___ 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
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] 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
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] 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
