Re: [webkit-dev] (no subject)
Unsubscribe at https://lists.webkit.org/mailman/listinfo/webkit-dev I'm getting really tired of seeing these emails. How hard is it to open the URL attached on every email sent to this mailing list? On Fri, Sep 13, 2013 at 1:08 PM, Kabeer Kalra kabir.kal...@gmail.comwrote: I DO NOT WANT TO BE IN THE MAILING LIST ___ 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] (no subject)
On Sep 13, 2013, at 13:12 , Ryosuke Niwa rn...@webkit.orgmailto:rn...@webkit.org wrote: Unsubscribe at https://lists.webkit.org/mailman/listinfo/webkit-dev I'm getting really tired of seeing these emails. How hard is it to open the URL attached on every email sent to this mailing list? I wonder if this is a gmail problem: I think gmail hides that by default when you are reading mail from a mailing list, like it tries to be helpful by hiding people's signatures by default as well. Maybe Kabeer can tell us if the footer on this message is visible in gmail. (Unfortunately, I have no idea how one would go about fixing that.) - Bem ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] (no subject)
On Apr 29, 2012, at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote: I'm actually curious as to how the session participants reached this consensus (probably on a separate thread). It seems like the bar shouldn't too high for removing prefixed APIs when they are unprefixed equivalents because I'm certain web developers want to use the ones that work on all browsers instead of just on WebKit. Here's some evidence that Web developers do not always care about this, and that lack of support for webkit-prefixed properties can be detrimental to Web compatibility: http://dev.opera.com/articles/view/opera-mobile-emulator-experimental-webkit-prefix-support/ Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
Maciej Stachowiak wrote: On Apr 29, 2012, at 1:25 PM, Ryosuke Niwarn...@webkit.org wrote: I'm actually curious as to how the session participants reached this consensus (probably on a separate thread). It seems like the bar shouldn't too high for removing prefixed APIs when they are unprefixed equivalents because I'm certain web developers want to use the ones that work on all browsers instead of just on WebKit. Here's some evidence that Web developers do not always care about this, and that lack of support for webkit-prefixed properties can be detrimental to Web compatibility: http://dev.opera.com/articles/view/opera-mobile-emulator-experimental-webkit-prefix-support/ I agree with this, including the careful do not always and can be detrimental words ;-). This message may not be interesting to webkit-dev. Skip if you are not interested in prefix usage studies, what Mozilla might do about prefixes, etc. We have been studying prefix usage in: https://bugzilla.mozilla.org/show_bug.cgi?id=708406 The situation for Opera is much worse than for Mozilla for many properties, e.g. border-radius, where -moz- is often observed to be used alongside -webkit-. See in particular: https://bugzilla.mozilla.org/show_bug.cgi?id=708406#c39 The table's tabs don't lay out nicely in bugzilla. Here's my attempt at fixing the layout by hand: base_property num_domains num_rules pct_no_unprefixed_and_no_moz animation-count11 100.0 animation-delay5137 80.0 animation-direction810 62.5 animation-duration 73 324 87.9 animation-fill-mode23 50.0 animation-iteration-count 51 78 84.7 animation-name 72 756 87.6 animation-play-state 230.0 animation-timing-function 51 100 94.5 text-size-adjust 779 635299.5 transform-origin 68 196 56.9 transform-origin-y 230.0 transform-style35 50 100.0 transition-delay 19 53 63.2 transition-duration208 853 71.5 transition-property156 491 76.2 transition-timing 120.0 transition-timing-function 45 111 58.9 Clearly Mozilla feels Opera's pain for certain properties, e.g. text-size-adjust. Per the bug, 99.5% of 6352 found instances do not have unprefixed or -moz-prefixed equivalents of text-size-adjust. Lack of -webkit- prefix support may not be detrimental to a particular browser's mobile web compatibility where that browser engine's prefix (or no prefix) is widely used. It depends on the browser and the particular style property. So (just FYI) we at Mozilla are not contemplating emulating -webkit- quite so much as Opera may be. We do want to sort this all out in the CSS-WG and avoid unnecessary fragmentation. /be ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
On Sun, Apr 29, 2012 at 1:25 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Apr 29, 2012 at 1:06 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 29, 2012, at 12:53 PM, Ryosuke Niwa rn...@webkit.org wrote: On Sun, Apr 29, 2012 at 12:34 PM, Maciej Stachowiak m...@apple.comwrote: On Apr 29, 2012, at 11:01 AM, Adam Barth aba...@webkit.org wrote: I read https://trac.webkit.org/wiki/DeprecatingFeatures, but I'm still unsure how to proceed with removing webkitPostMessage and aligning postMessage with the spec. No one responded to my earlier message, so I'm inclined to just post a patch. Comparing your post to the recommended steps on that page (the page says the same steps should be applied to removing only the prefixed version of a feature): It looks like you did this: - Any deprecation should be sent to webkit-dev for discussion. It doesn't look like you did any of these yet: - Any deprecation requires some data as to why the feature can be deprecated. The goal of the data is to show that the feature is not widely used and is not popular. The following would qualify: - usage statistics in the wild (either by instrumenting the browser or any other means). - some discussions on the standard mailing lists underlining that the standards' bodies don't think there is enough traction to get the feature standardized. - some proof that there is others way to achieve the same result that are better. It appears to me that the the unprefixed version will be a better alternative in this case since the websites can just use the same API on all spec-compliant browsers if ArrayBuffer is supported in the unprefixed version. Is there evidence that authors are either not using the prefixed version or are highly willing to migrate? I ask because another part of the policy says: The burden on the overall project needs to be evaluated as it should be the primary driver for dropping any feature. Small features that require very little maintenance may not qualify under this rule and their deprecation would need to be argued extensively. This implies to me that the burden of proof is higher for lower-maintenance-cost features (which I imagine applies to a prefixed method that also exists in unprefixed form). I'm not necessarily saying that lots of evidence is required in this case. But we can use this instance as a test case to adjust the policy. I'm actually curious as to how the session participants reached this consensus (probably on a separate thread). It seems like the bar shouldn't too high for removing prefixed APIs when they are unprefixed equivalents because I'm certain web developers want to use the ones that work on all browsers instead of just on WebKit. The discussion went like this: It is good to remove vendor prefixed features in favor of their standardized, unprefixed forms. However, the process for removing a vendor prefixed feature is the same as the process for removing any feature. In both cases, we care about the impact to users of WebKit-based products. The vendor prefix just provides motivation for wanting to remove a feature. It doesn't necessarily make it any easier to remove a feature. Just as we announce feature addition on webkit-dev, I think it is a good idea to announce feature removal on webkit-dev. -- If we have data to indicate that a feature is nearly unused, then removing the feature straight-away seems good. We can learn quickly if we made a mistake. -- If we have data to indicate that a feature is somewhat used, then we can still deprecate it, but we probably need to take our time, complain in the JS console about deprecated API usage for some time, and then remove the feature from trunk and see who complains. -- If we have data to indicate that a feature is highly used, then perhaps we are stuck with the feature. We may have some hard discussions here if someone is truly motivated to remove such a feature. -Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
En 28/02/12 04:46, Ryosuke Niwa escribiu: Do people really use git diff that often? I don't use git much but when I do I always get annoyed by the way git diff works because I almost always want git diff master. From my own experience, when you're used to a git workflow, you almost never mean git diff master when you do git diff. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
En 28/02/12 22:06, Dirk Pranke escribiu: I'm beginning to think it probably makes sense to add a different commandline argument that works exactly like diff (e.g. takes an optional second value). --git-diff perhaps? Based on the responses on this thread, I agree with you. It looks like a fair number of people either want cherry-pick or diff against remote master. I will probably implement a separate switch for pure git. Although I normally use it for cherry-picking a commit to upload, I have always missed the option to upload a bunch of commits as a single patch. Basically, as you said, forcing people to merge several commits in a single one to upload a patch to bz totally breaks the typical git workflow (micro-commits and so). BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
29.02.2012, 12:26, Sergio Villar Senin svil...@igalia.com: En 28/02/12 22:06, Dirk Pranke escribiu: I'm beginning to think it probably makes sense to add a different commandline argument that works exactly like diff (e.g. takes an optional second value). --git-diff perhaps? Based on the responses on this thread, I agree with you. It looks like a fair number of people either want cherry-pick or diff against remote master. I will probably implement a separate switch for pure git. Although I normally use it for cherry-picking a commit to upload, I have always missed the option to upload a bunch of commits as a single patch. Basically, as you said, forcing people to merge several commits in a single one to upload a patch to bz totally breaks the typical git workflow (micro-commits and so). Do you know how to use git rebase -i? -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
En 29/02/12 09:33, Konstantin Tokarev escribiu: Although I normally use it for cherry-picking a commit to upload, I have always missed the option to upload a bunch of commits as a single patch. Basically, as you said, forcing people to merge several commits in a single one to upload a patch to bz totally breaks the typical git workflow (micro-commits and so). Do you know how to use git rebase -i? Konstantin, that's why I meant with merge several commits in a single one. You do not normally want to do that while you're developing a patch as having multiple commits gives you a lot of flexibility while developing. I normally have to create a new branch to rebase the commits I want in a single patch to upload it to the bz. That is annoying, that's why I said that having something like webkit-patch upload range_of_commits will be nice to have, as you wouldn't have to create a new branch and rebase several commits, just to upload a new patch to the bz. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
On Wed, Feb 29, 2012 at 12:43 AM, Sergio Villar Senin svil...@igalia.comwrote: En 29/02/12 09:33, Konstantin Tokarev escribiu: Although I normally use it for cherry-picking a commit to upload, I have always missed the option to upload a bunch of commits as a single patch. Basically, as you said, forcing people to merge several commits in a single one to upload a patch to bz totally breaks the typical git workflow (micro-commits and so). Do you know how to use git rebase -i? Konstantin, that's why I meant with merge several commits in a single one. You do not normally want to do that while you're developing a patch as having multiple commits gives you a lot of flexibility while developing. I normally have to create a new branch to rebase the commits I want in a single patch to upload it to the bz. That is annoying, that's why I said that having something like webkit-patch upload range_of_commits will be nice to have, as you wouldn't have to create a new branch and rebase several commits, just to upload a new patch to the bz. You can do this with the current -g option by adding a commit range, e.g. -g=commit1..commit2. AFAIK, the only thing you can't do currently with -g is pass a commit range *and* include the staged/working copy changes. Under the hood it basically does what you described (create a new branch, copy the commits over as a single commit, upload from the branch, etc). ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
En 29/02/12 18:42, Ojan Vafai escribiu: On Wed, Feb 29, 2012 at 12:43 AM, Sergio Villar Senin Do you know how to use git rebase -i? Konstantin, that's why I meant with merge several commits in a single one. You do not normally want to do that while you're developing a patch as having multiple commits gives you a lot of flexibility while developing. I normally have to create a new branch to rebase the commits I want in a single patch to upload it to the bz. That is annoying, that's why I said that having something like webkit-patch upload range_of_commits will be nice to have, as you wouldn't have to create a new branch and rebase several commits, just to upload a new patch to the bz. You can do this with the current -g option by adding a commit range, e.g. -g=commit1..commit2. AFAIK, the only thing you can't do currently with -g is pass a commit range *and* include the staged/working copy changes. Good to know. Thx Ojan for the clarification. BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
Hi Dirk, On Mon, 2012-02-27 at 17:56 -0800, Dirk Pranke wrote: 1) Do you use -g foo to upload a single change? Yes, it's pretty much the only way I use it. If so, would you be annoyed if I changed that syntax to a different argument That would be fine. , or eliminated it completely (so that you would have to type foo^..foo)? I'd be a little annoyed ;-) My mental model of webkit-patch -g is that it's like cherry-pick, and so using individual commits is sensible. But there might be bugs in my mental model :) Regards, Andy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
On Mon, Feb 27, 2012 at 5:56 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, If you don't use webkit-patch and Git, you can stop reading now. Otherwise ... Currently, webkit-patch -g has some special logic for figuring out what to diff against for Git checkouts. Specifically, webkit-patch -g commitish gets translated to the git equivalent of 'git diff commitish^..commitish'. Then, we have an additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to pick up any uncommitted changes, and if nothing is specified, we will attempt to diff against the remote master/trunk version. This is very useful if you typically want to just upload a single commit issue, but is a bit un-git-like, and actually thwarts some other use cases. My questions are: 1) Do you use -g foo to upload a single change? If so, would you be annoyed if I changed that syntax to a different argument, or eliminated it completely (so that you would have to type foo^..foo)? 2) Do you object to changing the default to match what 'git diff' does? This would change the defaults so that: a) instead of no arguments meaning diff against remote master, it would mean diff against what is staged for commit I'd rather this not change. It used to work like this and there was much happiness when it changed to the current scheme. I think a lot of people's workflows depend on the no argument case uploading all the changes in their branch. b) 'git diff commitish would show the diff between commitish and your current working directory Now that I think about it, I realize that this doesn't really work without also changing (a). Also, there seem to be at least a few people who expect -g to work like cherry-pick. I'm beginning to think it probably makes sense to add a different commandline argument that works exactly like diff (e.g. takes an optional second value). --git-diff perhaps? If there is a consensus that we shouldn't change the defaults, I will likely implement a different command line argument that does mirror what git does. As an aside, I will probably be adding a patch that will figure out what the 'tracking' branch (as defined by branch.branchname.merge) is for your current checkout, and give webkit-patch a way to use that instead of the remote head (this would make using stacked local branches much easier). I haven't decided if this should be the default or if you should have to request this via something like 'webkit-patch diff -g UPSTREAM' instead; if you have an opinion, feel free to comment. There is a bug tracking this work at https://bugs.webkit.org/show_bug.cgi?id=76958 if you want to comment there instead of here or follow along with whatever ends up happening. Thanks, -- Dirk ___ 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] (no subject)
On Feb 27, 2012, at 5:56 PM, Dirk Pranke wrote: Hi all, If you don't use webkit-patch and Git, you can stop reading now. Otherwise ... Currently, webkit-patch -g has some special logic for figuring out what to diff against for Git checkouts. Specifically, webkit-patch -g commitish gets translated to the git equivalent of 'git diff commitish^..commitish'. Then, we have an additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to pick up any uncommitted changes, and if nothing is specified, we will attempt to diff against the remote master/trunk version. This is very useful if you typically want to just upload a single commit issue, but is a bit un-git-like, and actually thwarts some other use cases. My questions are: 1) Do you use -g foo to upload a single change? If so, would you be annoyed if I changed that syntax to a different argument, or eliminated it completely (so that you would have to type foo^..foo)? 2) Do you object to changing the default to match what 'git diff' does? This would change the defaults so that: a) instead of no arguments meaning diff against remote master, it would mean diff against what is staged for commit This would annoy me quite a lot -- Any delta including new files or anything implicitly staged (eg. by git stash apply) would not be included. Or do you mean git diff HEAD ? --Oliver ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
On Mon, Feb 27, 2012 at 6:02 PM, Oliver Hunt oli...@apple.com wrote: On Feb 27, 2012, at 5:56 PM, Dirk Pranke wrote: Hi all, If you don't use webkit-patch and Git, you can stop reading now. Otherwise ... Currently, webkit-patch -g has some special logic for figuring out what to diff against for Git checkouts. Specifically, webkit-patch -g commitish gets translated to the git equivalent of 'git diff commitish^..commitish'. Then, we have an additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to pick up any uncommitted changes, and if nothing is specified, we will attempt to diff against the remote master/trunk version. This is very useful if you typically want to just upload a single commit issue, but is a bit un-git-like, and actually thwarts some other use cases. My questions are: 1) Do you use -g foo to upload a single change? If so, would you be annoyed if I changed that syntax to a different argument, or eliminated it completely (so that you would have to type foo^..foo)? 2) Do you object to changing the default to match what 'git diff' does? This would change the defaults so that: a) instead of no arguments meaning diff against remote master, it would mean diff against what is staged for commit This would annoy me quite a lot -- Any delta including new files or anything implicitly staged (eg. by git stash apply) would not be included. Or do you mean git diff HEAD ? I did not (i.e., I explcitly meant what you get with 'git diff' and not 'git diff HEAD'). In order to include both staged and unstaged changes, you would have to do 'webkit-patch -g HEAD' (just like you would have to do 'git diff HEAD'). Your annoyance is duly noted, and it might make more sense for 'HEAD' to be the default; if we did that, though, we might want some other way to indicate just the unstaged changes ... As a broader point ... there are obviously a lot of different use cases possible with git, and any logic we have is likely to work really well for some and really annoy others. My thinking in proposing the change above is that at least we'd match what git does by default, and so it's fairly understandable (if you understand git). We could also add some sort of preference to webkit-patch here ... that has the usual discoverability issues, but might make sense given git's TMTOWTDI nature. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
I typically use webkit-patch to upload a single patch but really like your proposed change in 2a) to diff against what is staged for commit. This looks like it will be useful and cool. Konrad Sent from my BlackBerry on the Rogers Wireless Network - Original Message - From: Dirk Pranke [mailto:dpra...@chromium.org] Sent: Monday, February 27, 2012 08:56 PM To: WebKit-Dev webkit-dev@lists.webkit.org Subject: [webkit-dev] (no subject) Hi all, If you don't use webkit-patch and Git, you can stop reading now. Otherwise ... Currently, webkit-patch -g has some special logic for figuring out what to diff against for Git checkouts. Specifically, webkit-patch -g commitish gets translated to the git equivalent of 'git diff commitish^..commitish'. Then, we have an additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to pick up any uncommitted changes, and if nothing is specified, we will attempt to diff against the remote master/trunk version. This is very useful if you typically want to just upload a single commit issue, but is a bit un-git-like, and actually thwarts some other use cases. My questions are: 1) Do you use -g foo to upload a single change? If so, would you be annoyed if I changed that syntax to a different argument, or eliminated it completely (so that you would have to type foo^..foo)? 2) Do you object to changing the default to match what 'git diff' does? This would change the defaults so that: a) instead of no arguments meaning diff against remote master, it would mean diff against what is staged for commit b) 'git diff commitish would show the diff between commitish and your current working directory If there is a consensus that we shouldn't change the defaults, I will likely implement a different command line argument that does mirror what git does. As an aside, I will probably be adding a patch that will figure out what the 'tracking' branch (as defined by branch.branchname.merge) is for your current checkout, and give webkit-patch a way to use that instead of the remote head (this would make using stacked local branches much easier). I haven't decided if this should be the default or if you should have to request this via something like 'webkit-patch diff -g UPSTREAM' instead; if you have an opinion, feel free to comment. There is a bug tracking this work at https://bugs.webkit.org/show_bug.cgi?id=76958 if you want to comment there instead of here or follow along with whatever ends up happening. Thanks, -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev - 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 http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
Do people really use git diff that often? I don't use git much but when I do I always get annoyed by the way git diff works because I almost always want git diff master. But then I don't really use git that much especially for WebKit, so ignore me if people who primarily use git thinks this is a good idea. - Ryosuke On Mon, Feb 27, 2012 at 5:56 PM, Dirk Pranke dpra...@chromium.org wrote: Hi all, If you don't use webkit-patch and Git, you can stop reading now. Otherwise ... Currently, webkit-patch -g has some special logic for figuring out what to diff against for Git checkouts. Specifically, webkit-patch -g commitish gets translated to the git equivalent of 'git diff commitish^..commitish'. Then, we have an additional tweak that rewrites '-g HEAD' to '-g HEAD..' in order to pick up any uncommitted changes, and if nothing is specified, we will attempt to diff against the remote master/trunk version. This is very useful if you typically want to just upload a single commit issue, but is a bit un-git-like, and actually thwarts some other use cases. My questions are: 1) Do you use -g foo to upload a single change? If so, would you be annoyed if I changed that syntax to a different argument, or eliminated it completely (so that you would have to type foo^..foo)? 2) Do you object to changing the default to match what 'git diff' does? This would change the defaults so that: a) instead of no arguments meaning diff against remote master, it would mean diff against what is staged for commit b) 'git diff commitish would show the diff between commitish and your current working directory If there is a consensus that we shouldn't change the defaults, I will likely implement a different command line argument that does mirror what git does. As an aside, I will probably be adding a patch that will figure out what the 'tracking' branch (as defined by branch.branchname.merge) is for your current checkout, and give webkit-patch a way to use that instead of the remote head (this would make using stacked local branches much easier). I haven't decided if this should be the default or if you should have to request this via something like 'webkit-patch diff -g UPSTREAM' instead; if you have an opinion, feel free to comment. There is a bug tracking this work at https://bugs.webkit.org/show_bug.cgi?id=76958 if you want to comment there instead of here or follow along with whatever ends up happening. Thanks, -- Dirk ___ 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] (no subject)
[Please keep replies on the list in case anyone else is able to help.] Basic debugging from here calls for: 0. Does .libs/libwebkit-1.0.so.1.0.0 exist? Was libwebkit built successfully, or did the make command actually fail? 1. Does /usr/local/lib exist? 2. If so, what are the permissions for /usr/local/lib, e.g., are you able to write to it as your user or as root? 3. Does /usr/local/lib/libwebkit-1.0.so.1.0.0 already exist? 4. If so, what are its permissions, e.g, are you able to delete it or write over it as your user or as root? 5. Is /usr/local/lib on a read-only partition or mounted read-only? 6. Are there any extended attributes (e.g., for Linux ext2/3 or Windows NTFS) that prevent you from writing to that directory or overwriting that file? 7. What happens when you try to copy the file by hand? cp -p .libs/libwebkit-1.0.so.1.0.0 /usr/local/lib/libwebkit-1.0.so.1.0.0 Dave On Fri, 9/5/08, rakesh sadhu [EMAIL PROTECTED] wrote: i also tried with root permissions!!! sudo make install but still same error!!! On Sat, Sep 6, 2008 at 3:03 AM, David Kilzer [EMAIL PROTECTED] wrote: Do you have write access to /usr/local/lib? Perhaps you need to run make install as root? Or run sudo make install? Be careful--running as root can be dangerous! Dave On Fri, 9/5/08, rakesh sadhu [EMAIL PROTECTED] wrote: i am facing a problem while building webkit r33943 ; when i do make install make install make install-am make[1]: Entering directory `/home/rakesh/Desktop/WebKit-r33943' make[2]: Entering directory `/home/rakesh/Desktop/WebKit-r33943' test -z /usr/local/lib || /bin/mkdir -p /usr/local/lib test -z /usr/local/lib || /bin/mkdir -p /usr/local/lib /bin/bash ./libtool --mode=install /usr/bin/install -c 'libwebkit-1.0.la' '/usr/local/lib/libwebkit-1.0.la' /usr/bin/install -c .libs/libwebkit-1.0.so.1.0.0 /usr/local/lib/libwebkit-1.0.so.1.0.0 /usr/bin/install: accessing `/usr/local/lib/libwebkit-1.0.so.1.0.0': Input/output error make[2]: *** [install-libLTLIBRARIES] Error 1 make[2]: Leaving directory `/home/rakesh/Desktop/WebKit-r33943' make[1]: *** [install-am] Error 2 make[1]: Leaving directory `/home/rakesh/Desktop/WebKit-r33943' make: *** [install] Error 2 [EMAIL PROTECTED]:~/Desktop/WebKit-r33943$ i need a help!!how to solve this!! -- Regards, RakeshSadhu Boulevard Road, Srinagar, CASHMERE. -- Regards, RakeshSadhu Boulevard Road, Srinagar, CASHMERE. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
To unsubscribe, you must use the Mailman web interface. See the bottom of this email for a link to the web interface. On Jun 11, 2008, at 4:31 PM, Jim L. wrote: PLease take me off your mailing list. Thank you ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev Darren VanBuren [EMAIL PROTECTED] -- Administrator of Onekopakaspace Trunk MediaWiki install: http://oks.verymad.net/~onekopaka/mwtrunk/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] (no subject)
Hi Chris, The instructions at http://opensource.adobe.com/wiki/index.php/Using_Perforce_with_the_Adobe_Source_Libraries do not appear to work for getting a copy of the WebKit tree. The instructions there seem to deal with 3 paths within the repository -- //media, //release, and //submission. Attempting to use the p4 command-line client to access //webkit/M3/WebKit results in a strange error message: Error in client specification. Mapping '//webkit/...' is not under '//media/...'. I'm a complete newbie when it comes to Perforce, so perhaps I'm doing something silly. Thanks, Mark Rowe On 21/03/2007, at 7:38 AM, Chris Brichford wrote: Hi, We just put out our first public version of Apollo, which is using WebKit. You can check out our version of WebKit at http://opensource.adobe.com:8080/@md=dcd=//webkit/M3/c=2oh@//webkit/M3/WebKit/?ac=83 . For information on how to get the tree on your local machine see: http://opensource.adobe.com/wiki/index.php/Using_Perforce_with_the_Adobe_Source_Libraries We are using version of WebKit that was top of tree around September 11, 2006. We did not attempt to get our changes into the svn repository at WebKit.org because we are so far out of date. We are now working on getting our version of WebKit updated to top of tree WebKit. We plan, in future, to submit our changes directly back to the WebKit svn repository. Integrating WebKit with Apollo uncovered some technical issues that I'll be posting about in the next day or so. I'm interested in getting your feedback to our proposed solutions to these issues. We are really happy to be using WebKit and we'd like to thank all of those who helped us out over email and IRC. Chris Brichford Adobe Systems Inc. http://www.adobe.com/go/apollo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
RE: [webkit-dev] (no subject)
You want your client spec to look something like this: # A Perforce Client Specification. Client:username-somename-somemachine Owner: username Description: Created by username. Root: /Users/username/p4/somename Options: noallwrite noclobber compress unlocked nomodtime normdir LineEnd: local View: //webkit/M3/... //username-somename-somemachine/webkit/... You can edit your client spec by running: p4 -u username -p opensource.adobe.com:10666 -P yourpassword client username-somename-somemachine After editing your client spec, run: p4 -u username -p opensource.adobe.com:10666 -P yourpassword -c username-somename-somemachine sync Hope this helps, Chris -Original Message- From: Mark Rowe [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2007 3:30 PM To: Chris Brichford Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] (no subject) Hi Chris, The instructions at http://opensource.adobe.com/wiki/index.php/Using_Perforce_with_the_Adobe_Source_Libraries do not appear to work for getting a copy of the WebKit tree. The instructions there seem to deal with 3 paths within the repository -- //media, //release, and //submission. Attempting to use the p4 command-line client to access //webkit/M3/WebKit results in a strange error message: Error in client specification. Mapping '//webkit/...' is not under '//media/...'. I'm a complete newbie when it comes to Perforce, so perhaps I'm doing something silly. Thanks, Mark Rowe On 21/03/2007, at 7:38 AM, Chris Brichford wrote: Hi, We just put out our first public version of Apollo, which is using WebKit. You can check out our version of WebKit at http://opensource.adobe.com:8080/@md=dcd=//webkit/M3/c=2oh@//webkit/ M3/WebKit/?ac=83 . For information on how to get the tree on your local machine see: http://opensource.adobe.com/wiki/index.php/Using_Perforce_with_the_Ado be_Source_Libraries We are using version of WebKit that was top of tree around September 11, 2006. We did not attempt to get our changes into the svn repository at WebKit.org because we are so far out of date. We are now working on getting our version of WebKit updated to top of tree WebKit. We plan, in future, to submit our changes directly back to the WebKit svn repository. Integrating WebKit with Apollo uncovered some technical issues that I'll be posting about in the next day or so. I'm interested in getting your feedback to our proposed solutions to these issues. We are really happy to be using WebKit and we'd like to thank all of those who helped us out over email and IRC. Chris Brichford Adobe Systems Inc. http://www.adobe.com/go/apollo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] (no subject)
Chris, My client spec contains: //webkit/M3/... //atlas/webkit/... I'm still seeing the error that I mentioned. Perhaps the guest user doesn't have permission to access this portion of the repository? The error message isn't particularly clear about whatever the problem is. Thanks, Mark On 21/03/2007, at 9:52 AM, Chris Brichford wrote: You want your client spec to look something like this: # A Perforce Client Specification. Client:username-somename-somemachine Owner:username Description: Created by username. Root:/Users/username/p4/somename Options:noallwrite noclobber compress unlocked nomodtime normdir LineEnd:local View: //webkit/M3/... //username-somename-somemachine/webkit/... You can edit your client spec by running: p4 -u username -p opensource.adobe.com:10666 -P yourpassword client username-somename-somemachine After editing your client spec, run: p4 -u username -p opensource.adobe.com:10666 -P yourpassword -c username-somename-somemachine sync Hope this helps, Chris -Original Message- From: Mark Rowe [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2007 3:30 PM To: Chris Brichford Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] (no subject) Hi Chris, The instructions at http://opensource.adobe.com/wiki/index.php/Using_Perforce_with_the_Adobe_Source_Libraries do not appear to work for getting a copy of the WebKit tree. The instructions there seem to deal with 3 paths within the repository -- //media, //release, and //submission. Attempting to use the p4 command-line client to access //webkit/M3/WebKit results in a strange error message: Error in client specification. Mapping '// webkit/...' is not under '//media/...'. I'm a complete newbie when it comes to Perforce, so perhaps I'm doing something silly. Thanks, Mark Rowe On 21/03/2007, at 7:38 AM, Chris Brichford wrote: Hi, We just put out our first public version of Apollo, which is using WebKit. You can check out our version of WebKit at http://opensource.adobe.com:8080/@md=dcd=//webkit/M3/c=2oh@// webkit/ M3/WebKit/?ac=83 . For information on how to get the tree on your local machine see: http://opensource.adobe.com/wiki/index.php/ Using_Perforce_with_the_Ado be_Source_Libraries We are using version of WebKit that was top of tree around September 11, 2006. We did not attempt to get our changes into the svn repository at WebKit.org because we are so far out of date. We are now working on getting our version of WebKit updated to top of tree WebKit. We plan, in future, to submit our changes directly back to the WebKit svn repository. Integrating WebKit with Apollo uncovered some technical issues that I'll be posting about in the next day or so. I'm interested in getting your feedback to our proposed solutions to these issues. We are really happy to be using WebKit and we'd like to thank all of those who helped us out over email and IRC. Chris Brichford Adobe Systems Inc. http://www.adobe.com/go/apollo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
RE: [webkit-dev] (no subject)
Try again, I updated your client spec. It did not appear to contain what you thought it did. To see what your client spec is you can run: p4 -u guest -p opensource.adobe.com:10666 client -o atlas Chris -Original Message- From: Mark Rowe [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2007 3:57 PM To: Chris Brichford Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] (no subject) Chris, My client spec contains: //webkit/M3/... //atlas/webkit/... I'm still seeing the error that I mentioned. Perhaps the guest user doesn't have permission to access this portion of the repository? The error message isn't particularly clear about whatever the problem is. Thanks, Mark On 21/03/2007, at 9:52 AM, Chris Brichford wrote: You want your client spec to look something like this: # A Perforce Client Specification. Client:username-somename-somemachine Owner:username Description: Created by username. Root:/Users/username/p4/somename Options:noallwrite noclobber compress unlocked nomodtime normdir LineEnd:local View: //webkit/M3/... //username-somename-somemachine/webkit/... You can edit your client spec by running: p4 -u username -p opensource.adobe.com:10666 -P yourpassword client username-somename-somemachine After editing your client spec, run: p4 -u username -p opensource.adobe.com:10666 -P yourpassword -c username-somename-somemachine sync Hope this helps, Chris -Original Message- From: Mark Rowe [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 20, 2007 3:30 PM To: Chris Brichford Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] (no subject) Hi Chris, The instructions at http://opensource.adobe.com/wiki/index.php/Using_Perforce_with_the_Ad obe_Source_Libraries do not appear to work for getting a copy of the WebKit tree. The instructions there seem to deal with 3 paths within the repository -- //media, //release, and //submission. Attempting to use the p4 command-line client to access //webkit/M3/WebKit results in a strange error message: Error in client specification. Mapping '// webkit/...' is not under '//media/...'. I'm a complete newbie when it comes to Perforce, so perhaps I'm doing something silly. Thanks, Mark Rowe On 21/03/2007, at 7:38 AM, Chris Brichford wrote: Hi, We just put out our first public version of Apollo, which is using WebKit. You can check out our version of WebKit at http://opensource.adobe.com:8080/@md=dcd=//webkit/M3/c=2oh@// webkit/ M3/WebKit/?ac=83 . For information on how to get the tree on your local machine see: http://opensource.adobe.com/wiki/index.php/ Using_Perforce_with_the_Ado be_Source_Libraries We are using version of WebKit that was top of tree around September 11, 2006. We did not attempt to get our changes into the svn repository at WebKit.org because we are so far out of date. We are now working on getting our version of WebKit updated to top of tree WebKit. We plan, in future, to submit our changes directly back to the WebKit svn repository. Integrating WebKit with Apollo uncovered some technical issues that I'll be posting about in the next day or so. I'm interested in getting your feedback to our proposed solutions to these issues. We are really happy to be using WebKit and we'd like to thank all of those who helped us out over email and IRC. Chris Brichford Adobe Systems Inc. http://www.adobe.com/go/apollo ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
