[webkit-dev] (no subject)

[Sneha Bhat]

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] (no subject)

[Guido Trentalancia]

Hello everybody,

I have created some new webkit code changes to improve security and privacy by 
optionally disabling the CORS functionality:

https://bugs.webkit.org/show_bug.cgi?id=179886

Is there any way to speed up the review and approval process? 

Thanks, 

Guido
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] (no subject)

[Baskar CV]

Hi,

I'm currently trying to enhance the XSSAuditor available. Thus can someone help 
me knowing the flow of the code that leads to the XSSAuditor. When and by which 
it will be called and how it flows. What are its inputs and output. It's 
working.

Thanks in Advance
Baskar CV
  ___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] (no subject)

[Gino Casillas-Morsillo]

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] (no subject)

[Bem Jones-Bey]

On Sep 13, 2013, at 13:12 , Ryosuke Niwa 
mailto: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)

[Ryosuke Niwa]

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 wrote:

> 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

[webkit-dev] (no subject)

[Kabeer Kalra]

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] (no subject)

[Xueqing Huang]

Hi all:
It seems that WebCore/platform/graphics/win/
MediaPlayerPrivateFullscreenWindow.cpp should not exclude for WinCairo port.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] (no subject)

[Ashod Nakashian]

http://www.tiochechito.com/wp-content/themes/classica/olfdvd.html?dhe=zam.dhega&bmwwj=zafza.h&zmbn=wmmv
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] (no subject)

[Ashod Nakashian]

http://welovewashoku.com/wp-content/themes/elements-of-seo/glkrgw.html?yu=dhdh.dhmdh&zazar=urza.jdh&bf=fxyr
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] (no subject)

[Darin Fisher]

On Sun, Apr 29, 2012 at 1:25 PM, Ryosuke Niwa  wrote:

> On Sun, Apr 29, 2012 at 1:06 PM, Maciej Stachowiak  wrote:
>
>>
>> On Apr 29, 2012, at 12:53 PM, Ryosuke Niwa  wrote:
>>
>> On Sun, Apr 29, 2012 at 12:34 PM, Maciej Stachowiak wrote:
>>
>>> On Apr 29, 2012, at 11:01 AM, Adam Barth  wrote:
>>>
>>> I read , 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)

[Brendan Eich]

Maciej Stachowiak wrote:

On Apr 29, 2012, at 1:25 PM, Ryosuke Niwa  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)

[Maciej Stachowiak]

On Apr 29, 2012, at 1:25 PM, Ryosuke Niwa  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

[webkit-dev] (no subject)

[Ryosuke Niwa]

On Sun, Apr 29, 2012 at 1:06 PM, Maciej Stachowiak  wrote:

>
> On Apr 29, 2012, at 12:53 PM, Ryosuke Niwa  wrote:
>
> On Sun, Apr 29, 2012 at 12:34 PM, Maciej Stachowiak  wrote:
>
>> On Apr 29, 2012, at 11:01 AM, Adam Barth  wrote:
>>
>> I read , 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.

- Ryosuke
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] (no subject)

[Sergio Villar Senin]

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)

[Ojan Vafai]

On Wed, Feb 29, 2012 at 12:43 AM, Sergio Villar Senin wrote:

> 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)

[Sergio Villar Senin]

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)

[Konstantin Tokarev]

29.02.2012, 12:26, "Sergio Villar Senin" :
> 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)

[Sergio Villar Senin]

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)

[Sergio Villar Senin]

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)

[Dirk Pranke]

On Tue, Feb 28, 2012 at 10:58 AM, Ojan Vafai  wrote:
> On Mon, 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"
>
>
> 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?
>

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".

-- Dirk

>> 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..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)

[Ojan Vafai]

On Mon, 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"
>

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..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)

[Andy Wingo]

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)

[Dirk Pranke]

On Mon, Feb 27, 2012 at 7:46 PM, Ryosuke Niwa  wrote:
> 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".

I do; I often have several nested/pipelined branches in play as I am
working on a new feature and/or breaking up a new feature for review.
Git makes this quite easy, but unfortunately webkit-patch's
implementation (and our use of ChangeLogs) makes this painful, so I am
attempting to make things less painful.

If there are better ways to do what I am trying to do, I'm all ears :)

-- Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] (no subject)

[Ryosuke Niwa]

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  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..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)

[Konrad Piascik]

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 
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..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)

[Dirk Pranke]

On Mon, Feb 27, 2012 at 6:02 PM, Oliver Hunt  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)

[Oliver Hunt]

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

[webkit-dev] (no subject)

[Dirk Pranke]

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..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] (no subject)

[veparab]

http://danielcurran.net/EECore/images/signature_attachments/shffujk.html___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] (no subject)

[Jacques Quidu]

Hello,
 
WTF current implementation of StackBounds is not quite compatible with Windows 
fiber threads and/or custom stack sizes:
we have successfully implemented support for Windows fiber threads in 
StackBounds & fixed some 64 issues but we are still stuck on how to determine 
thread or fiber allocated stack size...
 
>From the fiber or thread context, i can only get the stack base & stack 
>current pointer but not the allocated stack size: any idea on how to get it 
>assuming that i cannot get stack size from the executable stack size because 
>our main app might use cooperative fiber threads with variable stack size, 
>along with preemptive threads created from WebKit ?
 
For now the only workaround i think about is to pass the fiber stack size as 
fiber data while creating the fiber in our main app & get it in StackBounds 
with GetFiberData() using a custom define to filter with our app impl: but it 
means adding code specific to our app in JavacriptCore/WTF which i would like 
to avoid if possible.
 
Kind regards, 

Jacques Quidu
Graphics Software Engineer
E-Mail: jqu...@hotmail.fr


  
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] (no subject)

[Mitsuru Nishibe]

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] (no subject)

[David Kilzer]

[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)

[David Kilzer]

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.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] (no subject)

[rakesh sadhu]

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.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] (no subject)

[Darren VanBuren]

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

[webkit-dev] (no subject)

[Jim L.]

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

RE: [webkit-dev] (no subject)

[Chris Brichford]

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=d&cd=//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)

[Mark Rowe]

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=d&cd=//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 Brichford]

 
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=d&cd=//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)

[Mark Rowe]

Hi Chris,

The instructions at  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=d&cd=//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

[webkit-dev] (no subject)

[Chris Brichford]

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=d&cd=//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