Re: [webkit-dev] Proposal to limit the size of the captured exception stack

[Mark Lam]

Matt,
I tested this on Firefox and Chrome and saw that Chrome captures up to 200 
frames.  I don’t see Firefox capturing frames at all when not throwing an 
Error.  Were you looking at Error.stack for Firefox when you came up with the 
128 frames number?  Maybe there’s a Firebug option I’m not familiar with?

Geoff,
It just occurred to me that the developer does have one recourse: he/she can 
use break on exception thrown / on uncaught exception, and inspect the full 
stack via the debugger.

Mark


> On Mar 28, 2017, at 9:08 PM, Mark Lam  wrote:
> 
> Currently, there’s no way for the developer to change this.  We can certainly 
> make it an option that the Inspector can change if desired.
> 
> Mark
> 
> 
>> On Mar 28, 2017, at 7:35 PM, Matt Baker > > wrote:
>> 
>>> On Mar 28, 2017, at 4:23 PM, Geoffrey Garen >> > wrote:
>>> 
>>> Does the separate exceptionStackTraceLimit mean that if a developer gets a 
>>> truncated stack trace in the Web Inspector, there’s no way for the 
>>> developer to remedy that? Is that what other browsers’ developer tools do?
>> 
>> FireFox and Chrome show console entires with exception stack traces with 128 
>> and 200 frames (respectively).
>> 
>>> 
>>> Geoff
>>> 
 On Mar 28, 2017, at 4:09 PM, Mark Lam > wrote:
 
 To follow up, I’ve implemented the change in r214289: .org/r214289>.  Error.stackTraceLimit is now 100.  I 
 also implemented a separate exceptionStackTraceLimit for stack traces 
 captured at the time of throwing a value (not to be confused with 
 Error.stack which is captured at the time of instantiation of the Error 
 object).  exceptionStackTraceLimit is also limited to 100 by default.
 
 Mark
 
 
> On Mar 17, 2017, at 1:04 PM, Mark Lam  > wrote:
> 
> @Geoff, my testing shows that we can do 200 frames and still perform well 
> (~1 second to console.log Error.stack).  Base on what we at present, I 
> think 100 is a good round number to use as our default stackTraceLimit.
> 
>> On Mar 17, 2017, at 11:40 AM, Maciej Stachowiak > > wrote:
>> 
>>> 
>>> On Mar 17, 2017, at 11:09 AM, Mark Lam >> > wrote:
>>> 
>>> Thanks for the reminder to back observations up with data.  I was 
>>> previously running some tests that throws StackOverflowErrors a lot 
>>> (which tainted my perspective), and I made a hasty conclusion which 
>>> isn’t good.  Anyway, here’s the data using an instrumented VM to take 
>>> some measurements and a simple test program that recurses forever to 
>>> throw a StackOverflowError (run on a MacPro):
>>> 
>>> 1. For a release build of jsc shell:
>>> Time to capture exception stack = 0.002807 sec
>>> Number of stack frames captured = 31722
>>> sizeof StackFrame = 24
>>> total memory consumed = ~761328 bytes.
>>> 
>>> 2. For a debug build of jsc shell:
>>> Time to capture exception stack = 0.052107 sec
>>> Number of stack frames captured = 31688
>>> sizeof StackFrame = 24
>>> total memory consumed = ~760512 bytes.
>>> 
>>> So, regarding performance, I was wrong.  The amount of time taken to 
>>> capture the entire JS stack each time is insignificant.
>>> Regarding memory usage, ~760K is not so good, but maybe it’s acceptable.
>>> 
>>> Comparing browsers with their respective inspectors open:
>>> 
>>> 1. Chrome
>>> number of frames captured: 10
>>> length of e.stack string: 824 chars
>>> time to console.log e.stack: 0.27 seconds
>>> 
>>> 2. Firefox
>>> number of frames captured: 129
>>> length of e.stack string: 8831 chars
>>> time to console.log e.stack: 0.93 seconds
>>> 
>>> 3. Safari
>>> number of frames captured: 31722
>>> length of e.stack string: 218821 chars
>>> time to console.log e.stack: 50.8 seconds
>>> 
>>> 4. Safari (with error.stack shrunk to 201 frames at time of capture to 
>>> simulate my proposal)
>>> number of frames captured: 201
>>> length of e.stack string: 13868 chars
>>> time to console.log e.stack: 1 second
>>> 
>>> With my proposal, the experience of printing Error.stack drops from 
>>> 50.8 seconds to about 1 second.  The memory used for capturing the 
>>> stack also drops from ~760K to 5K.
>>> 
>>> I wasn’t aware of the Error.stackTraceLimit, but that does sound like a 
>>> better solution than my proposal since it gives developers the ability 
>>> to capture more stack frames if they 

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

[Mark Lam]

Currently, there’s no way for the developer to change this.  We can certainly 
make it an option that the Inspector can change if desired.

Mark


> On Mar 28, 2017, at 7:35 PM, Matt Baker  wrote:
> 
>> On Mar 28, 2017, at 4:23 PM, Geoffrey Garen > > wrote:
>> 
>> Does the separate exceptionStackTraceLimit mean that if a developer gets a 
>> truncated stack trace in the Web Inspector, there’s no way for the developer 
>> to remedy that? Is that what other browsers’ developer tools do?
> 
> FireFox and Chrome show console entires with exception stack traces with 128 
> and 200 frames (respectively).
> 
>> 
>> Geoff
>> 
>>> On Mar 28, 2017, at 4:09 PM, Mark Lam >> > wrote:
>>> 
>>> To follow up, I’ve implemented the change in r214289: >> .org/r214289>.  Error.stackTraceLimit is now 100.  I 
>>> also implemented a separate exceptionStackTraceLimit for stack traces 
>>> captured at the time of throwing a value (not to be confused with 
>>> Error.stack which is captured at the time of instantiation of the Error 
>>> object).  exceptionStackTraceLimit is also limited to 100 by default.
>>> 
>>> Mark
>>> 
>>> 
 On Mar 17, 2017, at 1:04 PM, Mark Lam > wrote:
 
 @Geoff, my testing shows that we can do 200 frames and still perform well 
 (~1 second to console.log Error.stack).  Base on what we at present, I 
 think 100 is a good round number to use as our default stackTraceLimit.
 
> On Mar 17, 2017, at 11:40 AM, Maciej Stachowiak  > wrote:
> 
>> 
>> On Mar 17, 2017, at 11:09 AM, Mark Lam > > wrote:
>> 
>> Thanks for the reminder to back observations up with data.  I was 
>> previously running some tests that throws StackOverflowErrors a lot 
>> (which tainted my perspective), and I made a hasty conclusion which 
>> isn’t good.  Anyway, here’s the data using an instrumented VM to take 
>> some measurements and a simple test program that recurses forever to 
>> throw a StackOverflowError (run on a MacPro):
>> 
>> 1. For a release build of jsc shell:
>> Time to capture exception stack = 0.002807 sec
>> Number of stack frames captured = 31722
>> sizeof StackFrame = 24
>> total memory consumed = ~761328 bytes.
>> 
>> 2. For a debug build of jsc shell:
>> Time to capture exception stack = 0.052107 sec
>> Number of stack frames captured = 31688
>> sizeof StackFrame = 24
>> total memory consumed = ~760512 bytes.
>> 
>> So, regarding performance, I was wrong.  The amount of time taken to 
>> capture the entire JS stack each time is insignificant.
>> Regarding memory usage, ~760K is not so good, but maybe it’s acceptable.
>> 
>> Comparing browsers with their respective inspectors open:
>> 
>> 1. Chrome
>> number of frames captured: 10
>> length of e.stack string: 824 chars
>> time to console.log e.stack: 0.27 seconds
>> 
>> 2. Firefox
>> number of frames captured: 129
>> length of e.stack string: 8831 chars
>> time to console.log e.stack: 0.93 seconds
>> 
>> 3. Safari
>> number of frames captured: 31722
>> length of e.stack string: 218821 chars
>> time to console.log e.stack: 50.8 seconds
>> 
>> 4. Safari (with error.stack shrunk to 201 frames at time of capture to 
>> simulate my proposal)
>> number of frames captured: 201
>> length of e.stack string: 13868 chars
>> time to console.log e.stack: 1 second
>> 
>> With my proposal, the experience of printing Error.stack drops from 50.8 
>> seconds to about 1 second.  The memory used for capturing the stack also 
>> drops from ~760K to 5K.
>> 
>> I wasn’t aware of the Error.stackTraceLimit, but that does sound like a 
>> better solution than my proposal since it gives developers the ability 
>> to capture more stack frames if they need it.  Chrome’s default 
>> Error.stackTraceLimit appears to be 10.  MS appears to support it as 
>> well and defaults to 10 
>> (https://docs.microsoft.com/en-us/scripting/javascript/reference/stacktracelimit-property-error-javascript
>>  
>> ).
>>   Firefox does now.
> 
> Out of curiosity: Why does Firefox capture 129 frames instead of 31722 in 
> this case? Do they have a hardcoded limit?
 
 Actually, my previous frame counts are a bit off.  I was using 
 e.stack.split(/\r\n|\r|\n/).length as the frame count.  Below, I just copy 
 the console.log dump 

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

[Matt Baker]

> On Mar 28, 2017, at 4:23 PM, Geoffrey Garen  wrote:
> 
> Does the separate exceptionStackTraceLimit mean that if a developer gets a 
> truncated stack trace in the Web Inspector, there’s no way for the developer 
> to remedy that? Is that what other browsers’ developer tools do?

FireFox and Chrome show console entires with exception stack traces with 128 
and 200 frames (respectively).

> 
> Geoff
> 
>> On Mar 28, 2017, at 4:09 PM, Mark Lam > > wrote:
>> 
>> To follow up, I’ve implemented the change in r214289: > .org/r214289>.  Error.stackTraceLimit is now 100.  I 
>> also implemented a separate exceptionStackTraceLimit for stack traces 
>> captured at the time of throwing a value (not to be confused with 
>> Error.stack which is captured at the time of instantiation of the Error 
>> object).  exceptionStackTraceLimit is also limited to 100 by default.
>> 
>> Mark
>> 
>> 
>>> On Mar 17, 2017, at 1:04 PM, Mark Lam >> > wrote:
>>> 
>>> @Geoff, my testing shows that we can do 200 frames and still perform well 
>>> (~1 second to console.log Error.stack).  Base on what we at present, I 
>>> think 100 is a good round number to use as our default stackTraceLimit.
>>> 
 On Mar 17, 2017, at 11:40 AM, Maciej Stachowiak > wrote:
 
> 
> On Mar 17, 2017, at 11:09 AM, Mark Lam  > wrote:
> 
> Thanks for the reminder to back observations up with data.  I was 
> previously running some tests that throws StackOverflowErrors a lot 
> (which tainted my perspective), and I made a hasty conclusion which isn’t 
> good.  Anyway, here’s the data using an instrumented VM to take some 
> measurements and a simple test program that recurses forever to throw a 
> StackOverflowError (run on a MacPro):
> 
> 1. For a release build of jsc shell:
> Time to capture exception stack = 0.002807 sec
> Number of stack frames captured = 31722
> sizeof StackFrame = 24
> total memory consumed = ~761328 bytes.
> 
> 2. For a debug build of jsc shell:
> Time to capture exception stack = 0.052107 sec
> Number of stack frames captured = 31688
> sizeof StackFrame = 24
> total memory consumed = ~760512 bytes.
> 
> So, regarding performance, I was wrong.  The amount of time taken to 
> capture the entire JS stack each time is insignificant.
> Regarding memory usage, ~760K is not so good, but maybe it’s acceptable.
> 
> Comparing browsers with their respective inspectors open:
> 
> 1. Chrome
> number of frames captured: 10
> length of e.stack string: 824 chars
> time to console.log e.stack: 0.27 seconds
> 
> 2. Firefox
> number of frames captured: 129
> length of e.stack string: 8831 chars
> time to console.log e.stack: 0.93 seconds
> 
> 3. Safari
> number of frames captured: 31722
> length of e.stack string: 218821 chars
> time to console.log e.stack: 50.8 seconds
> 
> 4. Safari (with error.stack shrunk to 201 frames at time of capture to 
> simulate my proposal)
> number of frames captured: 201
> length of e.stack string: 13868 chars
> time to console.log e.stack: 1 second
> 
> With my proposal, the experience of printing Error.stack drops from 50.8 
> seconds to about 1 second.  The memory used for capturing the stack also 
> drops from ~760K to 5K.
> 
> I wasn’t aware of the Error.stackTraceLimit, but that does sound like a 
> better solution than my proposal since it gives developers the ability to 
> capture more stack frames if they need it.  Chrome’s default 
> Error.stackTraceLimit appears to be 10.  MS appears to support it as well 
> and defaults to 10 
> (https://docs.microsoft.com/en-us/scripting/javascript/reference/stacktracelimit-property-error-javascript
>  
> ).
>   Firefox does now.
 
 Out of curiosity: Why does Firefox capture 129 frames instead of 31722 in 
 this case? Do they have a hardcoded limit?
>>> 
>>> Actually, my previous frame counts are a bit off.  I was using 
>>> e.stack.split(/\r\n|\r|\n/).length as the frame count.  Below, I just copy 
>>> the console.log dump into an editor and take the line count from there as 
>>> the frame count instead.  The result of that string.split appears to be a 
>>> bit off from the actual frames printed by console.log. 
>>> 
>>> I also modified my recursing test function to console.log the re-entry 
>>> count on entry and this is what I saw:
>>> 
>>> 1. Chrome
>>> test reported reentry 

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

[Geoffrey Garen]

Does the separate exceptionStackTraceLimit mean that if a developer gets a 
truncated stack trace in the Web Inspector, there’s no way for the developer to 
remedy that? Is that what other browsers’ developer tools do?

Geoff

> On Mar 28, 2017, at 4:09 PM, Mark Lam  wrote:
> 
> To follow up, I’ve implemented the change in r214289:  .org/r214289>.  Error.stackTraceLimit is now 100.  I 
> also implemented a separate exceptionStackTraceLimit for stack traces 
> captured at the time of throwing a value (not to be confused with Error.stack 
> which is captured at the time of instantiation of the Error object).  
> exceptionStackTraceLimit is also limited to 100 by default.
> 
> Mark
> 
> 
>> On Mar 17, 2017, at 1:04 PM, Mark Lam > > wrote:
>> 
>> @Geoff, my testing shows that we can do 200 frames and still perform well 
>> (~1 second to console.log Error.stack).  Base on what we at present, I think 
>> 100 is a good round number to use as our default stackTraceLimit.
>> 
>>> On Mar 17, 2017, at 11:40 AM, Maciej Stachowiak >> > wrote:
>>> 
 
 On Mar 17, 2017, at 11:09 AM, Mark Lam > wrote:
 
 Thanks for the reminder to back observations up with data.  I was 
 previously running some tests that throws StackOverflowErrors a lot (which 
 tainted my perspective), and I made a hasty conclusion which isn’t good.  
 Anyway, here’s the data using an instrumented VM to take some measurements 
 and a simple test program that recurses forever to throw a 
 StackOverflowError (run on a MacPro):
 
 1. For a release build of jsc shell:
 Time to capture exception stack = 0.002807 sec
 Number of stack frames captured = 31722
 sizeof StackFrame = 24
 total memory consumed = ~761328 bytes.
 
 2. For a debug build of jsc shell:
 Time to capture exception stack = 0.052107 sec
 Number of stack frames captured = 31688
 sizeof StackFrame = 24
 total memory consumed = ~760512 bytes.
 
 So, regarding performance, I was wrong.  The amount of time taken to 
 capture the entire JS stack each time is insignificant.
 Regarding memory usage, ~760K is not so good, but maybe it’s acceptable.
 
 Comparing browsers with their respective inspectors open:
 
 1. Chrome
 number of frames captured: 10
 length of e.stack string: 824 chars
 time to console.log e.stack: 0.27 seconds
 
 2. Firefox
 number of frames captured: 129
 length of e.stack string: 8831 chars
 time to console.log e.stack: 0.93 seconds
 
 3. Safari
 number of frames captured: 31722
 length of e.stack string: 218821 chars
 time to console.log e.stack: 50.8 seconds
 
 4. Safari (with error.stack shrunk to 201 frames at time of capture to 
 simulate my proposal)
 number of frames captured: 201
 length of e.stack string: 13868 chars
 time to console.log e.stack: 1 second
 
 With my proposal, the experience of printing Error.stack drops from 50.8 
 seconds to about 1 second.  The memory used for capturing the stack also 
 drops from ~760K to 5K.
 
 I wasn’t aware of the Error.stackTraceLimit, but that does sound like a 
 better solution than my proposal since it gives developers the ability to 
 capture more stack frames if they need it.  Chrome’s default 
 Error.stackTraceLimit appears to be 10.  MS appears to support it as well 
 and defaults to 10 
 (https://docs.microsoft.com/en-us/scripting/javascript/reference/stacktracelimit-property-error-javascript
  
 ).
   Firefox does now.
>>> 
>>> Out of curiosity: Why does Firefox capture 129 frames instead of 31722 in 
>>> this case? Do they have a hardcoded limit?
>> 
>> Actually, my previous frame counts are a bit off.  I was using 
>> e.stack.split(/\r\n|\r|\n/).length as the frame count.  Below, I just copy 
>> the console.log dump into an editor and take the line count from there as 
>> the frame count instead.  The result of that string.split appears to be a 
>> bit off from the actual frames printed by console.log. 
>> 
>> I also modified my recursing test function to console.log the re-entry count 
>> on entry and this is what I saw:
>> 
>> 1. Chrome
>> test reported reentry count = 10150
>> split(…).length = 11 (because Chromes starts e.stack with a line 
>> "RangeError: Maximum call stack size exceeded”)
>> e.stack lines according to editor = 10 frames
>> 
>> 2. Firefox
>> test reported reentry count = 222044
>> split(…).length = 129 (probably because there’s an extra 

Re: [webkit-dev] Proposal to limit the size of the captured exception stack

[Mark Lam]

To follow up, I’ve implemented the change in r214289: .org/r214289>.  Error.stackTraceLimit is now 100.  I also 
implemented a separate exceptionStackTraceLimit for stack traces captured at 
the time of throwing a value (not to be confused with Error.stack which is 
captured at the time of instantiation of the Error object).  
exceptionStackTraceLimit is also limited to 100 by default.

Mark


> On Mar 17, 2017, at 1:04 PM, Mark Lam  wrote:
> 
> @Geoff, my testing shows that we can do 200 frames and still perform well (~1 
> second to console.log Error.stack).  Base on what we at present, I think 100 
> is a good round number to use as our default stackTraceLimit.
> 
>> On Mar 17, 2017, at 11:40 AM, Maciej Stachowiak > > wrote:
>> 
>>> 
>>> On Mar 17, 2017, at 11:09 AM, Mark Lam >> > wrote:
>>> 
>>> Thanks for the reminder to back observations up with data.  I was 
>>> previously running some tests that throws StackOverflowErrors a lot (which 
>>> tainted my perspective), and I made a hasty conclusion which isn’t good.  
>>> Anyway, here’s the data using an instrumented VM to take some measurements 
>>> and a simple test program that recurses forever to throw a 
>>> StackOverflowError (run on a MacPro):
>>> 
>>> 1. For a release build of jsc shell:
>>> Time to capture exception stack = 0.002807 sec
>>> Number of stack frames captured = 31722
>>> sizeof StackFrame = 24
>>> total memory consumed = ~761328 bytes.
>>> 
>>> 2. For a debug build of jsc shell:
>>> Time to capture exception stack = 0.052107 sec
>>> Number of stack frames captured = 31688
>>> sizeof StackFrame = 24
>>> total memory consumed = ~760512 bytes.
>>> 
>>> So, regarding performance, I was wrong.  The amount of time taken to 
>>> capture the entire JS stack each time is insignificant.
>>> Regarding memory usage, ~760K is not so good, but maybe it’s acceptable.
>>> 
>>> Comparing browsers with their respective inspectors open:
>>> 
>>> 1. Chrome
>>> number of frames captured: 10
>>> length of e.stack string: 824 chars
>>> time to console.log e.stack: 0.27 seconds
>>> 
>>> 2. Firefox
>>> number of frames captured: 129
>>> length of e.stack string: 8831 chars
>>> time to console.log e.stack: 0.93 seconds
>>> 
>>> 3. Safari
>>> number of frames captured: 31722
>>> length of e.stack string: 218821 chars
>>> time to console.log e.stack: 50.8 seconds
>>> 
>>> 4. Safari (with error.stack shrunk to 201 frames at time of capture to 
>>> simulate my proposal)
>>> number of frames captured: 201
>>> length of e.stack string: 13868 chars
>>> time to console.log e.stack: 1 second
>>> 
>>> With my proposal, the experience of printing Error.stack drops from 50.8 
>>> seconds to about 1 second.  The memory used for capturing the stack also 
>>> drops from ~760K to 5K.
>>> 
>>> I wasn’t aware of the Error.stackTraceLimit, but that does sound like a 
>>> better solution than my proposal since it gives developers the ability to 
>>> capture more stack frames if they need it.  Chrome’s default 
>>> Error.stackTraceLimit appears to be 10.  MS appears to support it as well 
>>> and defaults to 10 
>>> (https://docs.microsoft.com/en-us/scripting/javascript/reference/stacktracelimit-property-error-javascript
>>>  
>>> ).
>>>   Firefox does now.
>> 
>> Out of curiosity: Why does Firefox capture 129 frames instead of 31722 in 
>> this case? Do they have a hardcoded limit?
> 
> Actually, my previous frame counts are a bit off.  I was using 
> e.stack.split(/\r\n|\r|\n/).length as the frame count.  Below, I just copy 
> the console.log dump into an editor and take the line count from there as the 
> frame count instead.  The result of that string.split appears to be a bit off 
> from the actual frames printed by console.log. 
> 
> I also modified my recursing test function to console.log the re-entry count 
> on entry and this is what I saw:
> 
> 1. Chrome
> test reported reentry count = 10150
> split(…).length = 11 (because Chromes starts e.stack with a line 
> "RangeError: Maximum call stack size exceeded”)
> e.stack lines according to editor = 10 frames
> 
> 2. Firefox
> test reported reentry count = 222044
> split(…).length = 129 (probably because there’s an extra newline in 
> there somewhere)
> e.stack lines according to editor = 128 frames
> 
> 3. Safari
> test reported reentry count = 31701
> split(…).length = 31722 (I don’t know why there’s a 21 frame 
> discrepancy here.  I’ll debug this later)
> e.stack lines according to editor = ??? frames (WebInspector hangs every 
> time I try to scroll in it, let alone let me highlight and copy the stack 
> trace.  So I gave up)
> 
> 

Re: [webkit-dev] Scheduled downtime - svn.webkit.org and git.webkit.org 5.30 - 6.30pm PDT Monday 3/27/2017

[Ling Ho]

Thanks for your mail. For some reason, the post-commit to push git got 
stuck after r214463. It is now updated and I will watch for the next 
commit to make sure it's fine.


...
ling

On 3/28/17 2:04 AM, z...@falconsigh.net wrote:

On Tue, Mar 28, 2017, at 10:01 AM, Ling Ho wrote:

Hi Zan,

I have tested a git clone earlier and it should be working for you 
too. We have also taken care notification emails issue to 
webkit-changes list.


Thanks,
...
ling



Hi,

the Git mirror is working now, but it's fallen behind the SVN 
repository. It's stuck at r214463 while SVN is at this moment at r214469.

https://git.webkit.org/?p=WebKit.git;a=shortlog

Cheers,
Zan



On 3/28/17 12:04 AM, z...@falconsigh.net  
wrote:

On Tue, Mar 28, 2017, at 08:45 AM, Lucas Forschler wrote:

Quick update:

We are currently tracking issues with our EWS bots, as well as not 
sending change notification emails to 
webkit-chan...@lists.webkit.org 
.


If you notice anything awry, please let us know so we can investigate.
Thanks,
Lucas


The git.webkit.org mirror doesn't seem to be operational. The server 
itself is up and running, but Git requests against it time out.


Cheers,
Zan



On Mar 27, 2017, at 5:36 PM, Lucas Forschler > wrote:


Hello everyone,

Commits have been disabled on svn.webkit.org 
 while we update infrastructure.

We will send a follow-up when the repository is back online.

Thanks,
Lucas

On Mar 27, 2017, at 11:31 AM, Ling Ho > wrote:


Hello WebKit developers,

We will be switching and upgrading our Subversion and Git mirror 
servers this evening at 5.30pm PDT. We will be stopping svn 
commit at 5.30pm, and the new server should go into service 
shortly after DNS change is made. We will send out another notice 
once commit is possible again on the new server.


Thanks,
...
ling



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

Re: [webkit-dev] Scheduled downtime - svn.webkit.org and git.webkit.org 5.30 - 6.30pm PDT Monday 3/27/2017

[zan]

On Tue, Mar 28, 2017, at 10:01 AM, Ling Ho wrote:

> Hi Zan,

> 

>  I have tested a git clone earlier and it should be working for you
>  too. We have also taken care notification emails issue to webkit-
>  changes list.
> 

>  Thanks,

>  ...

>  ling

> 



Hi,



the Git mirror is working now, but it's fallen behind the SVN
repository. It's stuck at r214463 while SVN is at this moment at
r214469.
https://git.webkit.org/?p=WebKit.git;a=shortlog



Cheers,

Zan



> 

> On 3/28/17 12:04 AM, z...@falconsigh.net wrote:

>> On Tue, Mar 28, 2017, at 08:45 AM, Lucas Forschler wrote:

>>> Quick update:

>>> 

>>> We are currently tracking issues with our EWS bots, as well as not
>>> sending change notification emails to webkit-
>>> chan...@lists.webkit.org.
>>> 

>>> If you notice anything awry, please let us know so we can
>>> investigate.
>>> Thanks,

>>> Lucas

>> 

>> The git.webkit.org mirror doesn't seem to be operational. The server
>> itself is up and running, but Git requests against it time out.
>> 

>> Cheers,

>> Zan

>> 

>>> 

 On Mar 27, 2017, at 5:36 PM, Lucas Forschler 
 wrote:
 

 Hello everyone,

 

 Commits have been disabled on svn.webkit.org[1] while we update
 infrastructure.
 We will send a follow-up when the repository is back online.

 

 Thanks,

 Lucas

 

> On Mar 27, 2017, at 11:31 AM, Ling Ho  wrote:

> 

> Hello WebKit developers,

> 

> We will be switching and upgrading our Subversion and Git mirror
> servers this evening at 5.30pm PDT. We will be stopping svn commit
> at 5.30pm, and the new server should go into service shortly after
> DNS change is made. We will send out another notice once commit is
> possible again on the new server.
> 

> Thanks,

> ...

> ling

> 

> 

> 

> ___

> 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 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 mailing list

> webkit-dev@lists.webkit.org

> https://lists.webkit.org/mailman/listinfo/webkit-dev




Links:

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

Re: [webkit-dev] Scheduled downtime - svn.webkit.org and git.webkit.org 5.30 - 6.30pm PDT Monday 3/27/2017

[Ling Ho]

Hi Zan,

I have tested a git clone earlier and it should be working for you too. 
We have also taken care notification emails issue to webkit-changes list.


Thanks,
...
ling

On 3/28/17 12:04 AM, z...@falconsigh.net wrote:

On Tue, Mar 28, 2017, at 08:45 AM, Lucas Forschler wrote:

Quick update:

We are currently tracking issues with our EWS bots, as well as not 
sending change notification emails to webkit-chan...@lists.webkit.org 
.


If you notice anything awry, please let us know so we can investigate.
Thanks,
Lucas


The git.webkit.org mirror doesn't seem to be operational. The server 
itself is up and running, but Git requests against it time out.


Cheers,
Zan



On Mar 27, 2017, at 5:36 PM, Lucas Forschler > wrote:


Hello everyone,

Commits have been disabled on svn.webkit.org 
 while we update infrastructure.

We will send a follow-up when the repository is back online.

Thanks,
Lucas

On Mar 27, 2017, at 11:31 AM, Ling Ho > wrote:


Hello WebKit developers,

We will be switching and upgrading our Subversion and Git mirror 
servers this evening at 5.30pm PDT. We will be stopping svn commit 
at 5.30pm, and the new server should go into service shortly after 
DNS change is made. We will send out another notice once commit is 
possible again on the new server.


Thanks,
...
ling



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

Re: [webkit-dev] Scheduled downtime - svn.webkit.org and git.webkit.org 5.30 - 6.30pm PDT Monday 3/27/2017

[zan]

On Tue, Mar 28, 2017, at 08:45 AM, Lucas Forschler wrote:

> Quick update:

> 

> We are currently tracking issues with our EWS bots, as well as not
> sending change notification emails to webkit-chan...@lists.webkit.org.
> 

> If you notice anything awry, please let us know so we can investigate.
> Thanks,

> Lucas



The git.webkit.org mirror doesn't seem to be operational. The server
itself is up and running, but Git requests against it time out.


Cheers,

Zan



> 

>> On Mar 27, 2017, at 5:36 PM, Lucas Forschler
>>  wrote:
>> 

>> Hello everyone,

>> 

>> Commits have been disabled on svn.webkit.org[1] while we update
>> infrastructure.
>> We will send a follow-up when the repository is back online.

>> 

>> Thanks,

>> Lucas

>> 

>>> On Mar 27, 2017, at 11:31 AM, Ling Ho  wrote:

>>> 

>>> Hello WebKit developers,

>>> 

>>> We will be switching and upgrading our Subversion and Git mirror
>>> servers this evening at 5.30pm PDT. We will be stopping svn commit
>>> at 5.30pm, and the new server should go into service shortly after
>>> DNS change is made. We will send out another notice once commit is
>>> possible again on the new server.
>>> 

>>> Thanks,

>>> ...

>>> ling

>>> 

>>> 

>>> 

>>> ___

>>> 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 mailing list

> webkit-dev@lists.webkit.org

> https://lists.webkit.org/mailman/listinfo/webkit-dev




Links:

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

Re: [webkit-dev] Scheduled downtime - svn.webkit.org and git.webkit.org 5.30 - 6.30pm PDT Monday 3/27/2017

[Lucas Forschler]

Quick update:

We are currently tracking issues with our EWS bots, as well as not sending 
change notification emails to webkit-chan...@lists.webkit.org 
.

If you notice anything awry, please let us know so we can investigate.
Thanks,
Lucas


> On Mar 27, 2017, at 5:36 PM, Lucas Forschler  wrote:
> 
> Hello everyone,
> 
> Commits have been disabled on svn.webkit.org  while 
> we update infrastructure.
> We will send a follow-up when the repository is back online.
> 
> Thanks,
> Lucas
> 
>> On Mar 27, 2017, at 11:31 AM, Ling Ho > > wrote:
>> 
>> Hello WebKit developers,
>> 
>> We will be switching and upgrading our Subversion and Git mirror servers 
>> this evening at 5.30pm PDT. We will be stopping svn commit at 5.30pm, and 
>> the new server should go into service shortly after DNS change is made. We 
>> will send out another notice once commit is possible again on the new server.
>> 
>> Thanks,
>> ...
>> ling
>> 
>> 
>> 
>> ___
>> 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 mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev