[webkit-dev] Inspector code

2017-02-24 Thread kwadwo amankwa
Hi all,

Just studying the Inspector code and interested to know how(or where) the
Inspector front-end connects to the backend.

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


Re: [webkit-dev] SVN trouble

2017-02-24 Thread Alexey Proskuryakov

> 24 февр. 2017 г., в 9:31, Carlos Alberto Lopez Perez  
> написал(а):
> 
> On 24/02/17 18:08, Alexey Proskuryakov wrote:
>> works. There is almost certainly more cleanup that needs to be done - I
>> can see that trac.webkit.org  is broken. Please

Trac works now.

> git-svn is broken


How does one create a local git-svn checkout to try this out? Given that the 
offending file has been effectively deleted from svn, I think that git-svn 
should work too.

- Alexey


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


Re: [webkit-dev] DNS issues with webkit.org

2017-02-24 Thread Lucas Forschler
Things should be back online now. Please let me know if you run into any 
problems.
Lucas

> On Feb 24, 2017, at 3:59 PM, Lucas Forschler  wrote:
> 
> Hello folks,
> 
> We are having a DNS issue with many webkit.org domains. Engineers are 
> investigating, and we hope to be back online as quickly as possible.
> 
> Lucas
> 
> ___
> 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] SVN trouble

2017-02-24 Thread Antti Koivisto
Hi,

Looks like https://bugs.webkit.org/show_bug.cgi?id=168774 caused some sort
of SVN problem. Please hold commits until this is resolved.


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


Re: [webkit-dev] SVN trouble

2017-02-24 Thread Alexey Proskuryakov

> 24 февр. 2017 г., в 7:48, Antti Koivisto  написал(а):
> 
> Hi,
> 
> Looks like https://bugs.webkit.org/show_bug.cgi?id=168774 
>  caused some sort of SVN 
> problem. Please hold commits until this is resolved.

I deleted the remaining PDF file from resources, so svn checkout now works. 
There is almost certainly more cleanup that needs to be done - I can see that 
trac.webkit.org  is broken. Please reply to the thread 
about what else you see not working.

- Alexey



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


Re: [webkit-dev] SVN trouble

2017-02-24 Thread Carlos Alberto Lopez Perez
On 24/02/17 20:16, Alexey Proskuryakov wrote:
> 
> How does one create a local git-svn checkout to try this out? Given that
> the offending file has been effectively deleted from svn, I think that
> git-svn should work too.

You have the script:
Tools/Scripts/webkit-patch setup-git-clone

And there is more doc here:
https://trac.webkit.org/wiki/UsingGitWithWebKit

I can confirm that now it seems to work :) Thanks.

Also the git mirror is now updated beyond r212951.

How do you fixed this?

I see now that the files on r212951 have different sha1 hashes:

$ svn co 
https://svn.webkit.org/repository/webkit/trunk/LayoutTests/http/tests/cache/@r212951

$ find cache/|grep pdf|xargs sha1sum
1880d3e60a5f888c5eb077dd6c52a9a80423d971  
cache/disk-cache/resources/shattered-1-nocollision.pdf
38762cf7f55934b34d179ae6a4c80cadccbb7f0a  
cache/disk-cache/resources/shattered-1.pdf
682ca0c01721fe5e49a91da2253b4aa2fe2cde1c  
cache/disk-cache/resources/shattered-2-nocollision.pdf




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] SVN trouble

2017-02-24 Thread Carlos Alberto Lopez Perez
On 24/02/17 18:08, Alexey Proskuryakov wrote:
> 
>> 24 февр. 2017 г., в 7:48, Antti Koivisto > > написал(а):
>>
>> Hi,
>>
>> Looks like https://bugs.webkit.org/show_bug.cgi?id=168774 caused some
>> sort of SVN problem. Please hold commits until this is resolved.
> 
> I deleted the remaining PDF file from resources, so svn checkout now
> works. There is almost certainly more cleanup that needs to be done - I
> can see that trac.webkit.org  is broken. Please
> reply to the thread about what else you see not working.
> 
> - Alexey
> 
> 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

Any svn mirror will be unable to sync beyond r212950 [1].

And I think we can seize that to fix this as follows:

 * Create a svn mirror of the webkit repository up to r212950
 * Replace the current repository with that mirror.

That would effectively reset the WebKit repository to r212950,
like if r212951/r212952 never happened.

Something like this would do the trick:

$ svnadmin create webkit-svn-clone
$ cd webkit-svn-clone/
$ echo '#!/bin/true' > hooks/pre-revprop-change
$ chmod +x hooks/pre-revprop-change
$ svnsync init file://$(pwd) https://svn.webkit.org/repository/webkit/
# [...]
# This will sync up to r212950 that is precisely what we want (r212951 is the 
bad commit).
# [...]
# Copied properties for revision 212950.
# Transmitting file data ..svnsync: E200014: Checksum mismatch for resulting 
fulltext
# (/trunk/LayoutTests/http/tests/cache/disk-cache/resources/shattered-2.pdf):
#   expected:  5bd9d8cabc46041579a311230539b8d1
# actual:  ee4aa52b139d925f8d8884402b0a750c

# Now remove the hook for pre-revpro-change
$ rm -f hooks/pre-revprop-change

And rename the old svn repository directory (to keep a copy of it just in case 
we
need to recover something that was overlooked here)

And put this new mirror as the official one.

Check if there is any hook on the old one that should be moved also to the new


Note: It will take a lot to sync, so to speed up it an idea is to sync the 
mirror on
the server where the repo is located, by using a file://var/svn/webkit uri or 
similar.


Regards
---
[1] https://bugs.webkit.org/show_bug.cgi?id=168774#c32



signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] SVN trouble

2017-02-24 Thread Carlos Alberto Lopez Perez
On 24/02/17 18:08, Alexey Proskuryakov wrote:
> 
>> 24 февр. 2017 г., в 7:48, Antti Koivisto > > написал(а):
>>
>> Hi,
>>
>> Looks like https://bugs.webkit.org/show_bug.cgi?id=168774 caused some
>> sort of SVN problem. Please hold commits until this is resolved.
> 
> I deleted the remaining PDF file from resources, so svn checkout now
> works. There is almost certainly more cleanup that needs to be done - I
> can see that trac.webkit.org  is broken. Please
> reply to the thread about what else you see not working.
> 
> - Alexey
> 
> 
> 
> 
> 
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
> 

git-svn is broken

$ git log -1 --oneline HEAD
0d9a180f8c9 [Mac][cmake] Unreviewed buildfix after r212736.

$ git svn fetch
A   
LayoutTests/http/tests/cache/disk-cache/resources/shattered-1-nocollision.pdf
A   
LayoutTests/http/tests/cache/disk-cache/resources/shattered-1.pdf
A   
LayoutTests/http/tests/cache/disk-cache/resources/shattered-2-nocollision.pdf
APR does not understand this error code: ra_serf: The server sent a truncated 
HTTP response body. at /usr/share/perl5/Git/SVN/Ra.pm line 312.

$ git svn rebase
Index mismatch: 8f07398718ee1335bdf913347d759fb5d0a8535f != 
4f1b8dd4ff430af3ecac101de0063cbb9d8177bf
rereading 0d9a180f8c9d608a310c79a9a7a879d2f631d8a3
A   
LayoutTests/http/tests/cache/disk-cache/resources/shattered-1-nocollision.pdf
A   
LayoutTests/http/tests/cache/disk-cache/resources/shattered-1.pdf
A   
LayoutTests/http/tests/cache/disk-cache/resources/shattered-2-nocollision.pdf
APR does not understand this error code: ra_serf: The server sent a truncated 
HTTP response body. at /usr/share/perl5/Git/SVN/Ra.pm line 312.

$ git pull
Already up-to-date.

$ git log -1 --oneline HEAD
0d9a180f8c9 [Mac][cmake] Unreviewed buildfix after r212736.





signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] SVN trouble

2017-02-24 Thread Alexey Proskuryakov

From my testing, bot git.webkit.org and git-svn work now.

The only thing I did was block access to 
cache/disk-cache/resources/shattered-2.pdf using authz (this is the file with 
collision). I think that the reason why mirrors only updated now is that 
someone committed to trunk, and thus invoked post-commit hooks.

I believe that all infrastructure has recovered. We are currently looking into 
one unrelated issue with webkit-queues, so EWS and commit queue don't work.

- Alexey


> 24 февр. 2017 г., в 11:29, Carlos Alberto Lopez Perez  
> написал(а):
> 
> On 24/02/17 20:16, Alexey Proskuryakov wrote:
>> 
>> How does one create a local git-svn checkout to try this out? Given that
>> the offending file has been effectively deleted from svn, I think that
>> git-svn should work too.
> 
> You have the script:
> Tools/Scripts/webkit-patch setup-git-clone
> 
> And there is more doc here:
> https://trac.webkit.org/wiki/UsingGitWithWebKit
> 
> I can confirm that now it seems to work :) Thanks.
> 
> Also the git mirror is now updated beyond r212951.
> 
> How do you fixed this?
> 
> I see now that the files on r212951 have different sha1 hashes:
> 
> $ svn co 
> https://svn.webkit.org/repository/webkit/trunk/LayoutTests/http/tests/cache/@r212951
> 
> $ find cache/|grep pdf|xargs sha1sum
> 1880d3e60a5f888c5eb077dd6c52a9a80423d971  
> cache/disk-cache/resources/shattered-1-nocollision.pdf
> 38762cf7f55934b34d179ae6a4c80cadccbb7f0a  
> cache/disk-cache/resources/shattered-1.pdf
> 682ca0c01721fe5e49a91da2253b4aa2fe2cde1c  
> cache/disk-cache/resources/shattered-2-nocollision.pdf
> 
> 
> ___
> 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] SVN trouble

2017-02-24 Thread Carlos Alberto Lopez Perez
On 24/02/17 18:46, Carlos Alberto Lopez Perez wrote:
> On 24/02/17 18:08, Alexey Proskuryakov wrote:
>>
>>> 24 февр. 2017 г., в 7:48, Antti Koivisto >> > написал(а):
>>>
>>> Hi,
>>>
>>> Looks like https://bugs.webkit.org/show_bug.cgi?id=168774 caused some
>>> sort of SVN problem. Please hold commits until this is resolved.
>>
>> I deleted the remaining PDF file from resources, so svn checkout now
>> works. There is almost certainly more cleanup that needs to be done - I
>> can see that trac.webkit.org  is broken. Please
>> reply to the thread about what else you see not working.
>>
>> - Alexey
>>
>>
>>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
> 
> Any svn mirror will be unable to sync beyond r212950 [1].
> 
> And I think we can seize that to fix this as follows:
> 
>  * Create a svn mirror of the webkit repository up to r212950
>  * Replace the current repository with that mirror.
> 
> That would effectively reset the WebKit repository to r212950,
> like if r212951/r212952 never happened.
> 
> Something like this would do the trick:
> 
> $ svnadmin create webkit-svn-clone
> $ cd webkit-svn-clone/
> $ echo '#!/bin/true' > hooks/pre-revprop-change
> $ chmod +x hooks/pre-revprop-change
> $ svnsync init file://$(pwd) https://svn.webkit.org/repository/webkit/

^ The command below was missing after the svnsync init:

$ svnsync --non-interactive sync file://$(pwd)




signature.asc
Description: OpenPGP digital signature
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] SVN trouble

2017-02-24 Thread JF Bastien
The github mirror also seems sad:

https://github.com/WebKit/webkit/commits/master

It's at r212950.

On Fri, Feb 24, 2017 at 11:29 AM, Carlos Alberto Lopez Perez <
clo...@igalia.com> wrote:

> On 24/02/17 20:16, Alexey Proskuryakov wrote:
> >
> > How does one create a local git-svn checkout to try this out? Given that
> > the offending file has been effectively deleted from svn, I think that
> > git-svn should work too.
>
> You have the script:
> Tools/Scripts/webkit-patch setup-git-clone
>
> And there is more doc here:
> https://trac.webkit.org/wiki/UsingGitWithWebKit
>
> I can confirm that now it seems to work :) Thanks.
>
> Also the git mirror is now updated beyond r212951.
>
> How do you fixed this?
>
> I see now that the files on r212951 have different sha1 hashes:
>
> $ svn co https://svn.webkit.org/repository/webkit/trunk/
> LayoutTests/http/tests/cache/@r212951
>
> $ find cache/|grep pdf|xargs sha1sum
> 1880d3e60a5f888c5eb077dd6c52a9a80423d971  cache/disk-cache/resources/
> shattered-1-nocollision.pdf
> 38762cf7f55934b34d179ae6a4c80cadccbb7f0a  cache/disk-cache/resources/
> shattered-1.pdf
> 682ca0c01721fe5e49a91da2253b4aa2fe2cde1c  cache/disk-cache/resources/
> shattered-2-nocollision.pdf
>
>
>
> ___
> 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] SVN trouble

2017-02-24 Thread Chris Dumez


> On Feb 24, 2017, at 11:41 AM, Alexey Proskuryakov  wrote:
> 
> The only thing I did was block access to 
> cache/disk-cache/resources/shattered-2.pdf using authz (this is the file with 
> collision). I think that the reason why mirrors only updated now is that 
> someone committed to trunk, and thus invoked post-commit hooks.


Yes, I confirm manual commits work now :)

--
 Chris Dumez

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


Re: [webkit-dev] SVN trouble

2017-02-24 Thread Alexey Proskuryakov

> 24 февр. 2017 г., в 19:50, Chris Dumez  написал(а):
> 
> 
> 
> 
>> On Feb 24, 2017, at 11:41 AM, Alexey Proskuryakov > > wrote:
>> 
>> I believe that all infrastructure has recovered. We are currently looking 
>> into one unrelated issue with webkit-queues, so EWS and commit queue don't 
>> work.
>> 
>> - Alexey
> 
> 
> It looks like EWS is still down. Did it break again or is it just not fixed 
> yet?


It did work for a period of time, but no conclusive fix yet.

- Alexey

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


[webkit-dev] VM::setExclusiveThread()

2017-02-24 Thread Mark Lam
The JSC VM has this method setExclusiveThread().  Some details:
1. setExclusiveThread() is only used to forego actually locking/unlocking the 
underlying lock inside JSLock.
2. setExclusiveThread() is only used by WebCore where we can guarantee that the 
VM will only ever be used exclusively on one thread.
3. the underlying lock inside JSLock used to be a slow system lock.

Now that we have fast locking, I propose that we simplify the JSLock code by 
removing the concept of the exclusiveThread and always lock/unlock the 
underlying lock.  This also give us the ability to tryLock the JSLock 
(something I would like to be able to do for something new I’m working on).

Does anyone see a reason why we can’t remove the concept of the exclusiveThread?

Thanks.

Mark

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


Re: [webkit-dev] VM::setExclusiveThread()

2017-02-24 Thread Filip Pizlo
Seems like if the relevant benchmarks (speedometer) are ok with it then we 
should just do this. 

-Filip

> On Feb 24, 2017, at 20:50, Mark Lam  wrote:
> 
> The JSC VM has this method setExclusiveThread().  Some details:
> 1. setExclusiveThread() is only used to forego actually locking/unlocking the 
> underlying lock inside JSLock.
> 2. setExclusiveThread() is only used by WebCore where we can guarantee that 
> the VM will only ever be used exclusively on one thread.
> 3. the underlying lock inside JSLock used to be a slow system lock.
> 
> Now that we have fast locking, I propose that we simplify the JSLock code by 
> removing the concept of the exclusiveThread and always lock/unlock the 
> underlying lock.  This also give us the ability to tryLock the JSLock 
> (something I would like to be able to do for something new I’m working on).
> 
> Does anyone see a reason why we can’t remove the concept of the 
> exclusiveThread?
> 
> Thanks.
> 
> Mark
> 
> ___
> 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] DNS issues with webkit.org

2017-02-24 Thread Lucas Forschler
Hello folks,

We are having a DNS issue with many webkit.org domains. Engineers are 
investigating, and we hope to be back online as quickly as possible.

Lucas

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


Re: [webkit-dev] Inspector code

2017-02-24 Thread Joseph Pecoraro
Whoever hosts the Web Inspector frontend page has the real connection to the 
backend. The host provides an InspectorFrontendHost global object to the 
frontend page that can be used to send messages through that already 
established connection. Likewise when the host wants to trigger operations in 
the frontend page it calls methods on InspectorFrontendAPI.

• The frontend page uses InspectorFrontendHost.sendMessageToBackend to send 
JSON Inspector Protocol messages to the backend. This is never used directly, 
we generate APIs that construct the JSON messages that get sent through this.

• The frontend page receives messages from the backend through 
InspectorFrontendAPI.prototype.dispatchMessageAsync. Again generated APIs route 
these incoming messages to more convenient places such as domain observers or 
callbacks for earlier commands.

On the native side you can look at WebInspectorProxy::sendMessageToBackend to 
see how the frontend host's native connection to the backend is used and 
related code to see how it was established. Ultimately only a 
Inspector::FrontendChannel needs to be provided to WebCore's 
InspectorController to establish a backend <-> frontend connection. So you can 
set a breakpoint on WebCore::InspectorController::connectFrontend and see how / 
where it gets triggered. The common case in WebKit2 happens under 
WebKit::WebInspector::show.

- Joe

> On Feb 24, 2017, at 5:33 AM, kwadwo amankwa  wrote:
> 
> Hi all,
> 
> Just studying the Inspector code and interested to know how(or where) the 
> Inspector front-end connects to the backend.
> 
> cheers
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

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


Re: [webkit-dev] SVN trouble

2017-02-24 Thread Chris Dumez



> On Feb 24, 2017, at 11:41 AM, Alexey Proskuryakov  wrote:
> 
> I believe that all infrastructure has recovered. We are currently looking 
> into one unrelated issue with webkit-queues, so EWS and commit queue don't 
> work.
> 
> - Alexey


It looks like EWS is still down. Did it break again or is it just not fixed yet?

--
 Chris Dumez

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