Re: [webkit-dev] Introduce WebKit Android port

I agree that JSC for Android should be useful as JSC is the fastest JavaScript engine. I will try build JSCOnly for Android soon then. Thank you for your suggestion. :) -Original Message- From: "Konstantin Tokarev"annu...@yandex.ru To: "장대웅"daewoong.j...@navercorp.com; "Michael

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

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

Re: [webkit-dev] Introduce WebKit Android port

17.03.2017, 21:04, "장대웅" : > Hi. > > It is not just a code drop and I will continue maintain it. Actually, I’d > like to code > together with anyone who is interested in it. I think WebKit is a really > great project and > I hope Android port make WebKit more

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

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

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

Thanks for the detailed write-up. The main thing that sticks out to me in this data is that Safari defaults to capturing a stack that is, in the worst case, roughly 3000X larger than the stack in IE and Chrome. That’s a big difference. I think this could be a real website compatibility problem

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

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

Re: [webkit-dev] Introduce WebKit Android port

Hi. It is not just a code drop and I will continue maintain it. Actually, I’d like to code together with anyone who is interested in it. I think WebKit is a really great project and I hope Android port make WebKit more widely used and encourage Android developers to contribute. I wrote

Re: [webkit-dev] svn.webkit.org, git.webkit.org, trac.webkit.org and perf.webkit.org transition today on Friday at 10am PDT

We are postponing the changes to mid next week because of blocking task not able to complete in time. Apologies for any disruption this may have caused. ... ling On 3/16/17 5:34 PM, Ling Ho wrote: Hello WebKit developers, We have rescheduled our switch of svn.webkit.org and git.webkit.org

Re: [webkit-dev] build.webkit.org transition today at 3pm PDT

Hi Carlos, The results folder is being copied over, it’s just taking a long time since it’s many TB of data. Interesting on the build counter being reset to zero… that is unexpected. I will investigate. Thanks for pointing it out! Lucas > On Mar 17, 2017, at 5:09 AM, Carlos Alberto Lopez

Re: [webkit-dev] build.webkit.org transition today at 3pm PDT

On 16/03/17 22:40, Ling Ho wrote: > Hello WebKit developers: > > We are continuing our transitioning of webkit.org servers today and > tomorrow. Between 3pm and 4pm Pacific, we will be moving > build.webkit.org. Please email us at ad...@webkit.org if you encounter > any issue with your build bots

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

Can you be more specific about the motivation here? Do we have any motivating examples that will tell us wether time+memory were unacceptable before this change, or are acceptable after this change? In our motivating examples, does Safari use more time+memory than other browsers? If so, how