[webkit-dev] possible repository corruption on the remote side
I'm trying to git clone webkit but I cant due to repository corruption on the remote side. I have the followed the steps in http://trac.webkit.org/wiki/UsingGitWithWebKit . Any suggestions? Thank you! [jul...@xx ~]$git clone git://git.webkit.org/WebKit.git WebKit Initialized empty Git repository in /home/julian/WebKit/.git/ remote: error: failed to unpack compressed delta at offset 721420248 from ./objects/pack/pack-5e8ffe535a2c4b156009904da09e511778104665.pack remote: error: failed to read object 1ffe2c60ebbada5d57ec6f494dbd84a19d679206 at offset 721420244 from ./objects/pack/pack-5e8ffe535a2c4b156009904da09e511778104665.pack remote: fatal: object 1ffe2c60ebbada5d57ec6f494dbd84a19d679206 is corrupted remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: index-pack failed [jul...@xx ~]$ git --version git version 1.6.5.2 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] possible repository corruption on the remote side
Il giorno 12/dic/2009, alle ore 13.55, Julián de Navascués ha scritto: remote: error: failed to unpack compressed delta at offset 721420248 from ./objects/pack/pack-5e8ffe535a2c4b156009904da09e511778104665.pack Confirmed, here too. Bye, Michelangelo ___ 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
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
