Re: [webkit-dev] Patch to use V8 engine with Gtk port
The work was done for my employer for their own reasons. I both understand why they chose V8 and agree with the decision. I'm not comfortable giving a detailed reason for the decision and I think thats understandable. A clearer explanation would require a more formal response and its tied to our products so hopefully you can understand its not something I want to get into. As a engineer hopefully you can understand my desire to not go down this path lets leave it to the marketing team. However given the nature of the submission regardless of why it was made its also obvious that getting it integrated into the trunk is far better than leaving it as a fork. My focus is simply to do my best to get the code ready for submission and it does contain controversial decisions. Its been a long time since I posted but somehow I seem to manage to get myself on the wrong side of many issues. I think I'm cursed, chance would not give such consistent results :) Why this project was done is not the top issue and that should be obvious if you read the bug report. I've got other problems to deal with :) I honestly did not expect this response equating this submission to other work that needs to be done but given my track record its not surprising that I'm surprised it must be part of my curse :) I don't get the logic behind it. I think the assumption is that if I was not working on this JS engine submission then I would have been working on other areas that are considered more important however this is not true. The basic premise is false as I would actually have been working on something else. I assure you that I don't have the luxury of devoting my time to the project based on its most pressing problems if I did, I would of course try and help. On Fri, Dec 11, 2009 at 10:28 PM, Holger Freyther ze...@selfish.org wrote: On Friday 11 December 2009 23:55:06 Eric Seidel wrote: I don't see a patch on the bug, but I look forward to seeing it when it's posted. I'm surprised that having switch-able JS engines would bubble up on the list of things to do above things like passing the layout tests: http://trac.webkit.org/browser/trunk/LayoutTests/platform/gtk/Skipped Dear Mike, is JavaScript execution really the dominating cost in your (page loading tests)? When I profile on ARM (not WebKit/GTK+ though) I see various other areas of improvement? holger ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch to use V8 engine with Gtk port
I'm really surprised that other members of the community are questioning your priorities. You're free to work on whatever you think is important. That's the first principle of open source software outlined in The Cathedral and the Bazaar: http://catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s02.html Adam On Sat, Dec 12, 2009 at 12:15 PM, Mike Emmel mike.em...@gmail.com wrote: The work was done for my employer for their own reasons. I both understand why they chose V8 and agree with the decision. I'm not comfortable giving a detailed reason for the decision and I think thats understandable. A clearer explanation would require a more formal response and its tied to our products so hopefully you can understand its not something I want to get into. As a engineer hopefully you can understand my desire to not go down this path lets leave it to the marketing team. However given the nature of the submission regardless of why it was made its also obvious that getting it integrated into the trunk is far better than leaving it as a fork. My focus is simply to do my best to get the code ready for submission and it does contain controversial decisions. Its been a long time since I posted but somehow I seem to manage to get myself on the wrong side of many issues. I think I'm cursed, chance would not give such consistent results :) Why this project was done is not the top issue and that should be obvious if you read the bug report. I've got other problems to deal with :) I honestly did not expect this response equating this submission to other work that needs to be done but given my track record its not surprising that I'm surprised it must be part of my curse :) I don't get the logic behind it. I think the assumption is that if I was not working on this JS engine submission then I would have been working on other areas that are considered more important however this is not true. The basic premise is false as I would actually have been working on something else. I assure you that I don't have the luxury of devoting my time to the project based on its most pressing problems if I did, I would of course try and help. On Fri, Dec 11, 2009 at 10:28 PM, Holger Freyther ze...@selfish.org wrote: On Friday 11 December 2009 23:55:06 Eric Seidel wrote: I don't see a patch on the bug, but I look forward to seeing it when it's posted. I'm surprised that having switch-able JS engines would bubble up on the list of things to do above things like passing the layout tests: http://trac.webkit.org/browser/trunk/LayoutTests/platform/gtk/Skipped Dear Mike, is JavaScript execution really the dominating cost in your (page loading tests)? When I profile on ARM (not WebKit/GTK+ though) I see various other areas of improvement? holger ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch to use V8 engine with Gtk port
I think questioning someone's priorities in an open source project is generally not polite, unless there is some direct relationship between different tasks. For example, if someone introduce a new feature (let's say support for parts of the FooML language) and it had lots of bugs, it might be reasonable to ask them to fix some of the bugs before implementing more FooML features. But that doesn't seem to be the case here. Ultimately, I think it's up to the Gtk port maintainers and the folks maintaining v8 bindings to decide whether they want to support and maintain this functionality, and to review the patch as they see fit. Regards, Maciej On Dec 12, 2009, at 12:15 PM, Mike Emmel wrote: The work was done for my employer for their own reasons. I both understand why they chose V8 and agree with the decision. I'm not comfortable giving a detailed reason for the decision and I think thats understandable. A clearer explanation would require a more formal response and its tied to our products so hopefully you can understand its not something I want to get into. As a engineer hopefully you can understand my desire to not go down this path lets leave it to the marketing team. However given the nature of the submission regardless of why it was made its also obvious that getting it integrated into the trunk is far better than leaving it as a fork. My focus is simply to do my best to get the code ready for submission and it does contain controversial decisions. Its been a long time since I posted but somehow I seem to manage to get myself on the wrong side of many issues. I think I'm cursed, chance would not give such consistent results :) Why this project was done is not the top issue and that should be obvious if you read the bug report. I've got other problems to deal with :) I honestly did not expect this response equating this submission to other work that needs to be done but given my track record its not surprising that I'm surprised it must be part of my curse :) I don't get the logic behind it. I think the assumption is that if I was not working on this JS engine submission then I would have been working on other areas that are considered more important however this is not true. The basic premise is false as I would actually have been working on something else. I assure you that I don't have the luxury of devoting my time to the project based on its most pressing problems if I did, I would of course try and help. On Fri, Dec 11, 2009 at 10:28 PM, Holger Freyther ze...@selfish.org wrote: On Friday 11 December 2009 23:55:06 Eric Seidel wrote: I don't see a patch on the bug, but I look forward to seeing it when it's posted. I'm surprised that having switch-able JS engines would bubble up on the list of things to do above things like passing the layout tests: http://trac.webkit.org/browser/trunk/LayoutTests/platform/gtk/ Skipped Dear Mike, is JavaScript execution really the dominating cost in your (page loading tests)? When I profile on ARM (not WebKit/GTK+ though) I see various other areas of improvement? holger ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch to use V8 engine with Gtk port
On Saturday 12 December 2009 22:42:34 Maciej Stachowiak wrote: I think questioning someone's priorities in an open source project is generally not polite, unless there is some direct relationship between different tasks. For example, if someone introduce a new feature (let's say support for parts of the FooML language) and it had lots of bugs, it might be reasonable to ask them to fix some of the bugs before implementing more FooML features. But that doesn't seem to be the case here. Ultimately, I think it's up to the Gtk port maintainers and the folks maintaining v8 bindings to decide whether they want to support and maintain this functionality, and to review the patch as they see fit. Hello Mike, All, I'm not questioning your priorities. I'm solely looking at this from a maintaining WebKit/GTK+ point of view. The problem with WebKit (or any big software project) is that we are not done when landing a fundamental new feature/configure option but it is really only the beginning. The questions are around, who is running a buildbot with this configuration option, who will look at this buildbot, who will keep it building. In general it is better to have less options (as these could be actually checked prior to a release). So it is really not about me telling Mike what to do, but thinking about what is maintainable for WebKit/GTK+. E.g. we have an experimental GLib Unicode implementation, and saving the storage size for ICU (12 mb when not statically linked) is a pretty good reason for some. At the end of the day I feel responsible for the Gtk+ port and I would just like to know why it makes sense for us to maintain it. regards holger. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch to use V8 engine with Gtk port
On Sat, Dec 12, 2009 at 6:19 PM, Holger Freyther ze...@selfish.org wrote: On Saturday 12 December 2009 22:42:34 Maciej Stachowiak wrote: I think questioning someone's priorities in an open source project is generally not polite, unless there is some direct relationship between different tasks. For example, if someone introduce a new feature (let's say support for parts of the FooML language) and it had lots of bugs, it might be reasonable to ask them to fix some of the bugs before implementing more FooML features. But that doesn't seem to be the case here. Ultimately, I think it's up to the Gtk port maintainers and the folks maintaining v8 bindings to decide whether they want to support and maintain this functionality, and to review the patch as they see fit. Hello Mike, All, I'm not questioning your priorities. I'm solely looking at this from a maintaining WebKit/GTK+ point of view. The problem with WebKit (or any big software project) is that we are not done when landing a fundamental new feature/configure option but it is really only the beginning. The questions are around, who is running a buildbot with this configuration option, who will look at this buildbot, who will keep it building. In general it is better to have less options (as these could be actually checked prior to a release). So it is really not about me telling Mike what to do, but thinking about what is maintainable for WebKit/GTK+. To be clear the dependency on Gtk itself is small. I'll push the code into a git repo somewhere and link to the bug on monday. Now of course I had to seriously munge the makefiles but they already suffer bit rot. You mention the new font system a refactoring of the makefiles is probably needed for a host of reasons the changes needed to compile V8 just expose this. My point is a refactoring of the makefiles to make the port easier to maintain is probably a must before the V8 support could come in and it would help the overall Gtk project. Of course given my track record I could also be the only one with that opinion and everyone else is happy. If so then forget the offer :) However I think we have overlapping areas of concern and if so bringing some sanity back to the build will help everyone both in making the official build feature set clear and allowing easy work on optional or experimental features. The Linux kernel had similar issues and resolved them. I know that the v8 patch pushed things over the edge to a ridiculous set of ifdefs. Perhaps autoconf allows nested features or perhaps feature bundles are the answer or meta config switches they set and unset a compatible group of options. I don't know the right answer just that its probably time to overhaul the build system a bit and I can help. E.g. we have an experimental GLib Unicode implementation, and saving the storage size for ICU (12 mb when not statically linked) is a pretty good reason for some. At the end of the day I feel responsible for the Gtk+ port and I would just like to know why it makes sense for us to maintain it. regards holger. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch to use V8 engine with Gtk port
On Sat, Dec 12, 2009 at 8:40 PM, Mike Emmel mike.em...@gmail.com wrote: I don't know the right answer just that its probably time to overhaul the build system a bit and I can help. You are certainly welcome to look at the GYP system that the Chromium project uses to create builds for multiple OSes, JS engines, etc. It's definitely been the best of a series of mechanisms we've used over the project lifetime. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch to use V8 engine with Gtk port
On Sun, Dec 13, 2009 at 4:19 AM, Holger Freyther ze...@selfish.org wrote: On Saturday 12 December 2009 22:42:34 Maciej Stachowiak wrote: I think questioning someone's priorities in an open source project is generally not polite, unless there is some direct relationship between different tasks. For example, if someone introduce a new feature (let's say support for parts of the FooML language) and it had lots of bugs, it might be reasonable to ask them to fix some of the bugs before implementing more FooML features. But that doesn't seem to be the case here. Ultimately, I think it's up to the Gtk port maintainers and the folks maintaining v8 bindings to decide whether they want to support and maintain this functionality, and to review the patch as they see fit. Hello Mike, All, I'm not questioning your priorities. I'm solely looking at this from a maintaining WebKit/GTK+ point of view. The problem with WebKit (or any big software project) is that we are not done when landing a fundamental new feature/configure option but it is really only the beginning. The questions are around, who is running a buildbot with this configuration option, who will look at this buildbot, who will keep it building. In general it is better to have less options (as these could be actually checked prior to a release). So it is really not about me telling Mike what to do, but thinking about what is maintainable for WebKit/GTK+. Hi all, as one of the WebKitGTK+ maintainers I mostly agree with Holger here. As long as you are willing to provide support for this feature of the port, some sort of on-going testing, the patch itself is not overly intrusive (in the bug you hint that there might be no other way to do this than some big refactoring) and we manage to get it done without pushing the build system beyond unmaintainability I have nothing in principle with having this optional feature in. I'll CC to the bug and follow its progress. Xan E.g. we have an experimental GLib Unicode implementation, and saving the storage size for ICU (12 mb when not statically linked) is a pretty good reason for some. At the end of the day I feel responsible for the Gtk+ port and I would just like to know why it makes sense for us to maintain it. regards holger. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Patch to use V8 engine with Gtk port
Hi all. Its been a while. I just pushed a large patch that will need some serious work. https://bugs.webkit.org/show_bug.cgi?id=32452 It allows the v8 js engine and debugger to work with the gtk webkit port. Including remote debugging for arm or embedded platforms using chromedevtools. I'm also emailing the list because to get it accepted will require some help from a number of individuals some at google and the gtk team. I doubt I can do it on my own or at least not in a timely manner. In my opinion getting both engines equally supported across most ports would be good for the entire community so I hope people are interested. The Gtk dependencies are minor and it should be trivial to support other ports. Of course not everything is working for example dumptree is turned off the HTML debugger is off etc. But I think its initial base. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch to use V8 engine with Gtk port
I don't see a patch on the bug, but I look forward to seeing it when it's posted. I'm surprised that having switch-able JS engines would bubble up on the list of things to do above things like passing the layout tests: http://trac.webkit.org/browser/trunk/LayoutTests/platform/gtk/Skipped :/ -eric On Fri, Dec 11, 2009 at 2:51 PM, Mike Emmel mike.em...@gmail.com wrote: Hi all. Its been a while. I just pushed a large patch that will need some serious work. https://bugs.webkit.org/show_bug.cgi?id=32452 It allows the v8 js engine and debugger to work with the gtk webkit port. Including remote debugging for arm or embedded platforms using chromedevtools. I'm also emailing the list because to get it accepted will require some help from a number of individuals some at google and the gtk team. I doubt I can do it on my own or at least not in a timely manner. In my opinion getting both engines equally supported across most ports would be good for the entire community so I hope people are interested. The Gtk dependencies are minor and it should be trivial to support other ports. Of course not everything is working for example dumptree is turned off the HTML debugger is off etc. But I think its initial base. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch to use V8 engine with Gtk port
I changed the cc list the patch should be there now hmm not sure why it did not go on the initial submit. I don't know anything about the layout test issues. The patches relationship to the gtk port itself is minor its the one I happen to use. The gtk specific issues have a lot more to do with the changes to the GNUMakefiles. I'd be happy to refactor them so they where more flexible and could handle changes like this. If for some reason the layout test are considered a show stopper perhaps I can do another patch using a different platform. I'm on linux so a few are possible then come back to gtk specific issues later technically its not much just messy. On Fri, Dec 11, 2009 at 2:55 PM, Eric Seidel e...@webkit.org wrote: I don't see a patch on the bug, but I look forward to seeing it when it's posted. I'm surprised that having switch-able JS engines would bubble up on the list of things to do above things like passing the layout tests: http://trac.webkit.org/browser/trunk/LayoutTests/platform/gtk/Skipped :/ -eric On Fri, Dec 11, 2009 at 2:51 PM, Mike Emmel mike.em...@gmail.com wrote: Hi all. Its been a while. I just pushed a large patch that will need some serious work. https://bugs.webkit.org/show_bug.cgi?id=32452 It allows the v8 js engine and debugger to work with the gtk webkit port. Including remote debugging for arm or embedded platforms using chromedevtools. I'm also emailing the list because to get it accepted will require some help from a number of individuals some at google and the gtk team. I doubt I can do it on my own or at least not in a timely manner. In my opinion getting both engines equally supported across most ports would be good for the entire community so I hope people are interested. The Gtk dependencies are minor and it should be trivial to support other ports. Of course not everything is working for example dumptree is turned off the HTML debugger is off etc. But I think its initial base. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch to use V8 engine with Gtk port
My two cents are that you can pick the priorities for your own contributions. If you think this work is more important than working on LayoutTests, I think that's your decision to make as a contributor to the project. I have some technical questions, but we can discuss those on the bug. Adam On Fri, Dec 11, 2009 at 3:09 PM, Mike Emmel mike.em...@gmail.com wrote: I changed the cc list the patch should be there now hmm not sure why it did not go on the initial submit. I don't know anything about the layout test issues. The patches relationship to the gtk port itself is minor its the one I happen to use. The gtk specific issues have a lot more to do with the changes to the GNUMakefiles. I'd be happy to refactor them so they where more flexible and could handle changes like this. If for some reason the layout test are considered a show stopper perhaps I can do another patch using a different platform. I'm on linux so a few are possible then come back to gtk specific issues later technically its not much just messy. On Fri, Dec 11, 2009 at 2:55 PM, Eric Seidel e...@webkit.org wrote: I don't see a patch on the bug, but I look forward to seeing it when it's posted. I'm surprised that having switch-able JS engines would bubble up on the list of things to do above things like passing the layout tests: http://trac.webkit.org/browser/trunk/LayoutTests/platform/gtk/Skipped :/ -eric On Fri, Dec 11, 2009 at 2:51 PM, Mike Emmel mike.em...@gmail.com wrote: Hi all. Its been a while. I just pushed a large patch that will need some serious work. https://bugs.webkit.org/show_bug.cgi?id=32452 It allows the v8 js engine and debugger to work with the gtk webkit port. Including remote debugging for arm or embedded platforms using chromedevtools. I'm also emailing the list because to get it accepted will require some help from a number of individuals some at google and the gtk team. I doubt I can do it on my own or at least not in a timely manner. In my opinion getting both engines equally supported across most ports would be good for the entire community so I hope people are interested. The Gtk dependencies are minor and it should be trivial to support other ports. Of course not everything is working for example dumptree is turned off the HTML debugger is off etc. But I think its initial base. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Patch to use V8 engine with Gtk port
On Friday 11 December 2009 23:55:06 Eric Seidel wrote: I don't see a patch on the bug, but I look forward to seeing it when it's posted. I'm surprised that having switch-able JS engines would bubble up on the list of things to do above things like passing the layout tests: http://trac.webkit.org/browser/trunk/LayoutTests/platform/gtk/Skipped Dear Mike, is JavaScript execution really the dominating cost in your (page loading tests)? When I profile on ARM (not WebKit/GTK+ though) I see various other areas of improvement? holger ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
