Re: [webkit-dev] WebKitIDL syntax: unsigned int
2012/3/16 Adam Barth : > I recommend posting a patch and getting the appropriate folks to > review it rather than emailing all of webkit-dev for such a small > detail. Okay, sorry. I will not post about IDL syntax again. If you are interested you can follow the meta bug: https://bugs.webkit.org/show_bug.cgi?id=81128 I tend to err on the side of posting too much rather than posting too little. Since I am a novice, I may misjudge what is a small detail and what is not. Your help in this matter is appreciated. -- Seo Sanghyeon ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Using GitHub to Contribute to WebKit (Experimental)
Hi webkit-dev, After reading last week's discussion about switching the project to git, I wondered if it would be possible to get some of the benefits of git-style development without forcing everyone to switch to git. One of the benefits of git-style development is the ability to review a series of patches at once. GitHub has some nice tools to reviewing pull requests, so I wrote up a short wiki page describing how someone might use GitHub to contribute to WebKit: https://trac.webkit.org/wiki/UsingGitHub I'm not sure we'll want to switch the whole project over to GitHub any time soon, but it might be something that folks who like git might want to experiment with. Happy hacking, Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git/SVN is slow
Do you know what is causing the issue? - Ryosuke On Thu, Mar 15, 2012 at 2:43 PM, William Siegrist wrote: > Thanks everyone for the debugging information. We are working on both > hardware and software solutions, but I have no ETA to give you. > > -Bill > > > > On Mar 15, 2012, at 2:05 PM, Levi Weintraub wrote: > > > Likewise in Mountain View... it's making WebKit gardening impossible :( > > > > On Thu, Mar 15, 2012 at 2:03 PM, Dmitry Titov > wrote: > > over here in Seattle I am getting 5KiB/s all day, no way to get an > updated checkout today :-( > > > > > > On Thu, Mar 15, 2012 at 10:54 AM, Jarred Nicholls > wrote: > > Well I was just about to follow up that from the east coast on Comcast > bbone, I'm pulling at acceptable rates from git.webkit.org, ~700KiB/s. > That's about as fast as it's always been. Same goes for > nightly.webkit.org. > > > > There's a number of possible issues that would result in slow response > times and slow downloads. E.g., it could be sheer packet loss between > carrier backbones and not necessarily tapped bandwidth. > > > > > > On Thu, Mar 15, 2012 at 1:45 PM, > Ryosuke Niwa > Software Engineer > Google Inc. > > > wrote: > > I don't really think checking the latency is interesting. What's killing > us is bandwidth. As far as I tested yesterday, the ping at my work (Google > SF office) gives me a reasonable time as well. > > > > There's something that's killing our bandwidth. Does anyone know some > tools to investigate this? > > > > - Ryosuke > > > > > > On Thu, Mar 15, 2012 at 10:40 AM, Jarred Nicholls > wrote: > > Ditto, @ ae-11-70 attempting to get to ae-21-60 the trace dies. Pings > to svn.webkit.org succeed in acceptable times however, for me. Perhaps > the hops following ae-11-70 and ae-21-60 simple aren't able to reply with > proper ICMP packets; no real conclusion to based on that info alone, but > maybe worth passing off to the provider and/or directly to Level3. > > > > Jarred > > > > > > On Thu, Mar 15, 2012 at 1:22 PM, Levi Weintraub > wrote: > > Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN > updates are dog slow :( > > > > 6 pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230) 4.306 ms 4.966 > ms * > > 7 xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153) 20.116 ms 3.031 > ms 3.056 ms > > 8 ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 4.316 ms > > ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 4.239 ms > > ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 4.545 ms > > 9 * * * > > 10 * * * > > 11 * * * > > > > > > On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers wrote: > > Bill, > > > > I'm currently pulling from svn.webkit.org at what feels like 5kbps, and > poor http://build.webkit.org/console hits the page refresh before it's > even able to render to the bottom :( > > > > Below is a traceroute to webkit.org: > > traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte > packets > > 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms > > 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms > > 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms > > 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) > 14.588 ms 15.541 ms 15.733 ms > > 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) > 16.563 ms 16.929 ms 16.946 ms > > 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) > 17.967 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125) > 14.599 ms 11.428 ms > > 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms > > 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms > vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms > vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms > > 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms > ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms > ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms > > 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 ms > 34.950 ms > > 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms 65.766 > ms 66.692 ms > > 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 > ms 78.175 ms > > 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms 78.520 > ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms > > 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms > ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms > ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms > > 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms > ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms > ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms > > 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms > ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms > ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms > > 17 * * * > > 18 * * * > > 19 * * * > > 20 * * * > > 21 * * *
Re: [webkit-dev] Git/SVN is slow
Thanks everyone for the debugging information. We are working on both hardware and software solutions, but I have no ETA to give you. -Bill On Mar 15, 2012, at 2:05 PM, Levi Weintraub wrote: > Likewise in Mountain View... it's making WebKit gardening impossible :( > > On Thu, Mar 15, 2012 at 2:03 PM, Dmitry Titov wrote: > over here in Seattle I am getting 5KiB/s all day, no way to get an updated > checkout today :-( > > > On Thu, Mar 15, 2012 at 10:54 AM, Jarred Nicholls wrote: > Well I was just about to follow up that from the east coast on Comcast bbone, > I'm pulling at acceptable rates from git.webkit.org, ~700KiB/s. That's about > as fast as it's always been. Same goes for nightly.webkit.org. > > There's a number of possible issues that would result in slow response times > and slow downloads. E.g., it could be sheer packet loss between carrier > backbones and not necessarily tapped bandwidth. > > > On Thu, Mar 15, 2012 at 1:45 PM, Ryosuke Niwa wrote: > I don't really think checking the latency is interesting. What's killing us > is bandwidth. As far as I tested yesterday, the ping at my work (Google SF > office) gives me a reasonable time as well. > > There's something that's killing our bandwidth. Does anyone know some tools > to investigate this? > > - Ryosuke > > > On Thu, Mar 15, 2012 at 10:40 AM, Jarred Nicholls wrote: > Ditto, @ ae-11-70 attempting to get to ae-21-60 the trace dies. Pings to > svn.webkit.org succeed in acceptable times however, for me. Perhaps the hops > following ae-11-70 and ae-21-60 simple aren't able to reply with proper ICMP > packets; no real conclusion to based on that info alone, but maybe worth > passing off to the provider and/or directly to Level3. > > Jarred > > > On Thu, Mar 15, 2012 at 1:22 PM, Levi Weintraub wrote: > Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN updates are > dog slow :( > > 6 pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230) 4.306 ms 4.966 ms * > 7 xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153) 20.116 ms 3.031 ms > 3.056 ms > 8 ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 4.316 ms > ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 4.239 ms > ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 4.545 ms > 9 * * * > 10 * * * > 11 * * * > > > On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers wrote: > Bill, > > I'm currently pulling from svn.webkit.org at what feels like 5kbps, and poor > http://build.webkit.org/console hits the page refresh before it's even able > to render to the bottom :( > > Below is a traceroute to webkit.org: > traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte packets > 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms > 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms > 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms > 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) 14.588 > ms 15.541 ms 15.733 ms > 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) 16.563 > ms 16.929 ms 16.946 ms > 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) 17.967 ms > pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125) 14.599 ms > 11.428 ms > 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms > 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms > vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms > vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms > 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms > ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms > ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms > 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 ms > 34.950 ms > 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms 65.766 ms > 66.692 ms > 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 ms > 78.175 ms > 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms 78.520 ms > ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms > 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms > ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms > ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms > 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms > ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms > ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms > 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms > ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms > ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > Thanks for looking into this. > Philip > > On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist > wrote: > Our network provider did not find an
Re: [webkit-dev] DFG jit Type checking
> I'm trying to figure out how does the DFG JIT type checking work?
In brief: We first predict what the types of expressions will be based on value
profiling in both the LLInt and baseline JIT, and then attempt to generate code
with the minimal set of type checks needed to ensure soundness. Type check
failures result in OSR exit to baseline JIT code, so after a type check the
subsequent code is compiled with a propagated type proof. Type checks are both
hoisted and sunk; we try to place type checks at the first use that requires
type information after the assignment to the variable (sinking to first use),
except for cases where the live range of the variable crosses basic blocks, in
which case the checks are hoisted to the basic blocks that did the assignments
(this is a cheap alternative to loop invariant type check motion). Really
simple example:
x = o.f; // no type check for x here, though there may be a type check for o,
if it's o's first yse
// ... much of things that are not related to x
y = x; // no type check for x, since the use is type-agnostic
z = x + 6; // check that x is whatever we predicted. for example if the
predictions say that x is an int and we know that this expression is unlikely
to overflow, we will check that it's an int
w = x - 1; // no type check, since we already checked x.
v = z + 2; // no type check, since we know that z must be an int because it was
created by an int binary op that does not overflow.
> I'm also interested in the following: if I start DFG JIT without using LICM
> will the types of variables be checked in the cycle?
No, type checks are almost always hoisted up to the basic block that assigned
the variable.
> To make it clear, I'll bring this example
> for (var j=0; j<1; j++)
> {
> var i = 10;
> var h = j + i;
> }
> How will the type of variable " i " be checked in that example?
>
"i" will not have any checks, since you set i to 10, which is a constant.
Actually, this program is going to be almost entirely optimized away, since all
of the assignments are dead. Our compiler will not completely kill all of this
code yet, since we don't yet have all of the control flow simplification
awesomeness that we want. But you might consider a slightly more interesting
example, assuming for that "i" is still typically an integer:
var o = p.g; // we will check p's type if it hadn't already been checked, and
we will check o's type as well, because its live range crosses basic blocks and
this is the last assignment before the end of this basic block
for (var j = 0; j < 1; ++j) { // no type checks for j, since we know
statically that j is an int
var i = o.f; // we will not check o's type, but we will not hoist o.f out
of the loop - both because we don't do full LICM and because the print()
statement below may be a side effect.
var h = j + i; // check i's type. j's type doesn't need to be checked.
print(h); // load "print" from the global object, check that it's the
"print" that we expected, and call it.
}
Hope this helps!
-Filip
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git/SVN is slow
Likewise in Mountain View... it's making WebKit gardening impossible :( On Thu, Mar 15, 2012 at 2:03 PM, Dmitry Titov wrote: > over here in Seattle I am getting 5KiB/s all day, no way to get an updated > checkout today :-( > > > On Thu, Mar 15, 2012 at 10:54 AM, Jarred Nicholls wrote: > >> Well I was just about to follow up that from the east coast on Comcast >> bbone, I'm pulling at acceptable rates from git.webkit.org, ~700KiB/s. >> That's about as fast as it's always been. Same goes for >> nightly.webkit.org. >> >> There's a number of possible issues that would result in slow response >> times and slow downloads. E.g., it could be sheer packet loss between >> carrier backbones and not necessarily tapped bandwidth. >> >> >> On Thu, Mar 15, 2012 at 1:45 PM, Ryosuke Niwa wrote: >> >>> I don't really think checking the latency is interesting. What's killing >>> us is bandwidth. As far as I tested yesterday, the ping at my work (Google >>> SF office) gives me a reasonable time as well. >>> >>> There's something that's killing our bandwidth. Does anyone know some >>> tools to investigate this? >>> >>> - Ryosuke >>> >>> >>> On Thu, Mar 15, 2012 at 10:40 AM, Jarred Nicholls wrote: >>> Ditto, @ ae-11-70 attempting to get to ae-21-60 the trace dies. Pings to svn.webkit.org succeed in acceptable times however, for me. Perhaps the hops following ae-11-70 and ae-21-60 simple aren't able to reply with proper ICMP packets; no real conclusion to based on that info alone, but maybe worth passing off to the provider and/or directly to Level3. Jarred On Thu, Mar 15, 2012 at 1:22 PM, Levi Weintraub wrote: > Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN > updates are dog slow :( > > 6 pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230) 4.306 ms > 4.966 ms * > 7 xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153) 20.116 ms > 3.031 ms 3.056 ms > 8 ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 4.316 ms > ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 4.239 ms > ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 4.545 ms > 9 * * * > 10 * * * > 11 * * * > > > On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers wrote: > >> Bill, >> >> I'm currently pulling from svn.webkit.org at what feels like 5kbps, >> and poor http://build.webkit.org/console hits the page refresh >> before it's even able to render to the bottom :( >> >> Below is a traceroute to webkit.org: >> traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte >> packets >> 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms >> 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms >> 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms >> 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net(68.85.91.177) >> 14.588 ms 15.541 ms 15.733 ms >> 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) >> 16.563 ms 16.929 ms 16.946 ms >> 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) >> 17.967 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net(68.86.93.125) >> 14.599 ms 11.428 ms >> 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms >> 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms >> vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms >> vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms >> 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms >> ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms >> ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms >> 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 >> ms 34.950 ms >> 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms >> 65.766 ms 66.692 ms >> 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms >> 78.007 ms 78.175 ms >> 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms >> 78.520 ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms >> 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms >> ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms >> ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms >> 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms >> ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms >> ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms >> 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms >> ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms >> ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms >> 17 * * * >> 18 * * * >> 19 * * * >> 20 * * * >> 21 * * * >> 22 * * * >> 23 * * * >> 24 * * * >> 25 * * * >> 26 * * * >> 27 * * * >> 28 *
Re: [webkit-dev] Git/SVN is slow
over here in Seattle I am getting 5KiB/s all day, no way to get an updated checkout today :-( On Thu, Mar 15, 2012 at 10:54 AM, Jarred Nicholls wrote: > Well I was just about to follow up that from the east coast on Comcast > bbone, I'm pulling at acceptable rates from git.webkit.org, ~700KiB/s. > That's about as fast as it's always been. Same goes for > nightly.webkit.org. > > There's a number of possible issues that would result in slow response > times and slow downloads. E.g., it could be sheer packet loss between > carrier backbones and not necessarily tapped bandwidth. > > > On Thu, Mar 15, 2012 at 1:45 PM, Ryosuke Niwa wrote: > >> I don't really think checking the latency is interesting. What's killing >> us is bandwidth. As far as I tested yesterday, the ping at my work (Google >> SF office) gives me a reasonable time as well. >> >> There's something that's killing our bandwidth. Does anyone know some >> tools to investigate this? >> >> - Ryosuke >> >> >> On Thu, Mar 15, 2012 at 10:40 AM, Jarred Nicholls wrote: >> >>> Ditto, @ ae-11-70 attempting to get to ae-21-60 the trace dies. Pings >>> to svn.webkit.org succeed in acceptable times however, for me. Perhaps >>> the hops following ae-11-70 and ae-21-60 simple aren't able to reply with >>> proper ICMP packets; no real conclusion to based on that info alone, but >>> maybe worth passing off to the provider and/or directly to Level3. >>> >>> Jarred >>> >>> >>> On Thu, Mar 15, 2012 at 1:22 PM, Levi Weintraub wrote: >>> Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN updates are dog slow :( 6 pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230) 4.306 ms 4.966 ms * 7 xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153) 20.116 ms 3.031 ms 3.056 ms 8 ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 4.316 ms ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 4.239 ms ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 4.545 ms 9 * * * 10 * * * 11 * * * On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers wrote: > Bill, > > I'm currently pulling from svn.webkit.org at what feels like 5kbps, > and poor http://build.webkit.org/console hits the page refresh before > it's even able to render to the bottom :( > > Below is a traceroute to webkit.org: > traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte > packets > 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms > 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms > 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms > 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) > 14.588 ms 15.541 ms 15.733 ms > 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) > 16.563 ms 16.929 ms 16.946 ms > 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) > 17.967 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net(68.86.93.125) > 14.599 ms 11.428 ms > 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms > 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms > vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms > vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms > 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms > ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms > ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms > 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 > ms 34.950 ms > 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms > 65.766 ms 66.692 ms > 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 > ms 78.175 ms > 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms > 78.520 ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms > 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms > ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms > ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms > 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms > ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms > ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms > 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms > ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms > ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > Thanks for looking into this. > Philip > > On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist < > wsiegr...@apple.com> wrote: > >> Our network provider did not find anything wro
Re: [webkit-dev] Is the New XMLParser dead?
On Mar 15, 2012, at 1:29 PM, Eric Seidel wrote: > It seems the "New XML Parser" hasn't been touched in about 8 months: > > http://trac.webkit.org/browser/trunk/Source/WebCore/xml/parser > > Are there any plans to continue work on such, or can it be removed? > The refactoring which was done to support it seems to mostly just > confuse the HTML 5 Parser code... :( > > (I went looking for how something was implemented in the HTML5 > parser... and it took me a long time to find it this afternoon). Yes, we plan to get more active on this effort again within a few months. Note that some of the refactoring was able to benefit the WebVTT parser, so we need some generic parser abstractions in any case. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When should we turn on new features?
By the way, can we add a point of contact for each one of these features? I often find it hard to figure out who "owns" which feature/flag. - Ryosuke On Thu, Mar 15, 2012 at 11:51 AM, Ryosuke Niwa wrote: > Great. Thanks! > > On Thu, Mar 15, 2012 at 5:01 AM, TAMURA, Kent wrote: > >> I made https://trac.webkit.org/wiki/FeatureFlags . >> I extracted all of ENABLE(FOO) in *.cpp and *.mm, and added some >> comments. Feel free to edit it! >> >> >> On Wed, Mar 14, 2012 at 13:03, TAMURA, Kent wrote: >> >>> I'll add a Wiki page for the table of existing feature flags and their >>> descriptions. >>> >>> >>> On Tue, Feb 14, 2012 at 11:09, Maciej Stachowiak wrote: >>> I think we're talking about a couple of different things now: 1) Table of what the WebKit community as a whole (instead of individual point maintainers) thinks should be enabled in stable releases. This would be input to port maintainers looking to make a release. >>> >>> 2) Documenting what enable flags are actually on for given ports as shipped. Probably hard to gather this info, but might be useful input for the WebKit community. 3) Changing build systems to enable compiling "nightly" and "stable" versions from the same tree, so both modes are documented in trunk. Requires some coding for various build systems. I like (2) and (3), but I don't think they replace the usefulness of (1). I think the mention of "the feature-table page" is blending (2) and (1), which would serve different purposes. Regards, Maciej On Feb 13, 2012, at 4:21 PM, Hajime Morrita wrote: > (Re-sending from the right address...) > > I'd +1 Adam's point. > > It would be great if we can do something like "webkit-build --gtk > --stable", "webkit-build --chromium --canary" or "webkit-build > --nightly" where the script read the central configuration file and > find an appropriate configuration. In this way, there would be no > duplication we should maintain. > > Even though some ports currently don't support switches through > build-webkit, we can gradually switch over to the central list-based > configuration settings by, for example, generating features.gypi, > FeatureDefines.xcconfig or a set of flags for autoconf. > > Also the feature-table page could be generated from the list. We can > even start from simply generating an HTML from the machine-readable > configuration file, then integrate it to each build system. > > Although it might be overkill, I personally prefer this kind of "don't > repeat youself" direction. > -- > morrita > > On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak wrote: >> >> On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa Software Engineer Google Inc. wrote: >> >> On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak wrote: >>> >>> I think you raise a good point. Another point worth mentioning is that >>> sometimes a feature can be complete and useful in one port, but half-baked >>> in another (for example, fullscreen API was shipped in Safari and at the >>> same time present but non-functional in Chrome). >>> >>> I think in the past, port owners have made clear that they want to own the >>> final decisions on what features are enabled in their ports. >>> >>> But we as a community could do better, by having a shared recommendation >>> of what features we think should be enabled in shipping releases. In some >>> cases, this may not match the settings on trunk, as some features may be >>> desirable to enable for experimental builds, but not in shipping product. >>> For features that we recommended disabling, ideally we'd identify a reason. >>> And in some cases, those might be port-specific issues. >> >> >> Right. Even just having a list of new features with flag(s) to >> enable/disable and the status (e.g. list of outstanding bugs) on wiki page >> will be helpful. >> >> For example, vertical writing mode doesn't work on Windows, Chromium, etc... >> but port owners may not necessarily realize that the feature is enabled by >> default and each port needs to modify the code that draws text. >> >> >> I personally think such a page would be a good idea. I'd love to hear input >> from more folks on whether this is a good idea and what the right approach >> is. >> >> Cheers, >> Maciej >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> _
Re: [webkit-dev] WebKitIDL syntax: unsigned int
I recommend posting a patch and getting the appropriate folks to
review it rather than emailing all of webkit-dev for such a small
detail.
Adam
On Thu, Mar 15, 2012 at 10:34 AM, Seo Sanghyeon wrote:
> "unsigned int" is an invalid Type in WebIDL.
>
> {Int8,Uint8,Uint8Clamped,Int16,Uint16,Int32,Uint32,Float32,Float64}Array.idl
> define: const unsigned int BYTES_PER_ELEMENT.
>
> Latest Typed Array Specification defines BYTES_PER_ELEMENT as
> unsigned long.
> http://www.khronos.org/registry/typedarray/specs/latest/
>
> It seems to me that code generators ignore types of constants.
> Therefore fixing this should be harmless, but I want to make sure.
> Am I right?
>
> --
> Seo Sanghyeon
> ___
> 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
[webkit-dev] Is the New XMLParser dead?
It seems the "New XML Parser" hasn't been touched in about 8 months: http://trac.webkit.org/browser/trunk/Source/WebCore/xml/parser Are there any plans to continue work on such, or can it be removed? The refactoring which was done to support it seems to mostly just confuse the HTML 5 Parser code... :( (I went looking for how something was implemented in the HTML5 parser... and it took me a long time to find it this afternoon). -eric ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] DFG jit Type checking
I'm trying to figure out how does the DFG JIT type checking work?
I'm also interested in the following: if I start DFG JIT without using LICM
will the types of variables be checked in the cycle? To make it clear, I'll
bring this example
for (var j=0; j<1; j++)
{
var i = 10;
var h = j + i;
}
How will the type of variable " i " be checked in that example?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When should we turn on new features?
Great. Thanks! On Thu, Mar 15, 2012 at 5:01 AM, TAMURA, Kent wrote: > I made https://trac.webkit.org/wiki/FeatureFlags . > I extracted all of ENABLE(FOO) in *.cpp and *.mm, and added some comments. > Feel free to edit it! > > > On Wed, Mar 14, 2012 at 13:03, TAMURA, Kent wrote: > >> I'll add a Wiki page for the table of existing feature flags and their >> descriptions. >> >> >> On Tue, Feb 14, 2012 at 11:09, Maciej Stachowiak wrote: >> >>> >>> I think we're talking about a couple of different things now: >>> >>> 1) Table of what the WebKit community as a whole (instead of individual >>> point maintainers) thinks should be enabled in stable releases. This would >>> be input to port maintainers looking to make a release. >> >> >>> 2) Documenting what enable flags are actually on for given ports as >>> shipped. Probably hard to gather this info, but might be useful input for >>> the WebKit community. >>> >>> 3) Changing build systems to enable compiling "nightly" and "stable" >>> versions from the same tree, so both modes are documented in trunk. >>> Requires some coding for various build systems. >>> >>> I like (2) and (3), but I don't think they replace the usefulness of >>> (1). I think the mention of "the feature-table page" is blending (2) and >>> (1), which would serve different purposes. >>> >>> Regards, >>> Maciej >>> >>> >>> On Feb 13, 2012, at 4:21 PM, Hajime Morrita wrote: >>> >>> > (Re-sending from the right address...) >>> > >>> > I'd +1 Adam's point. >>> > >>> > It would be great if we can do something like "webkit-build --gtk >>> > --stable", "webkit-build --chromium --canary" or "webkit-build >>> > --nightly" where the script read the central configuration file and >>> > find an appropriate configuration. In this way, there would be no >>> > duplication we should maintain. >>> > >>> > Even though some ports currently don't support switches through >>> > build-webkit, we can gradually switch over to the central list-based >>> > configuration settings by, for example, generating features.gypi, >>> > FeatureDefines.xcconfig or a set of flags for autoconf. >>> > >>> > Also the feature-table page could be generated from the list. We can >>> > even start from simply generating an HTML from the machine-readable >>> > configuration file, then integrate it to each build system. >>> > >>> > Although it might be overkill, I personally prefer this kind of "don't >>> > repeat youself" direction. >>> > -- >>> > morrita >>> > >>> > On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak >>> wrote: >>> >> >>> >> On Feb 13, 2012, at 1:21 PM, >>> Ryosuke Niwa >>> Software Engineer >>> Google Inc. >>> >>> >>> wrote: >>> >> >>> >> On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak >>> wrote: >>> >>> >>> >>> I think you raise a good point. Another point worth mentioning is >>> that >>> >>> sometimes a feature can be complete and useful in one port, but >>> half-baked >>> >>> in another (for example, fullscreen API was shipped in Safari and at >>> the >>> >>> same time present but non-functional in Chrome). >>> >>> >>> >>> I think in the past, port owners have made clear that they want to >>> own the >>> >>> final decisions on what features are enabled in their ports. >>> >>> >>> >>> But we as a community could do better, by having a shared >>> recommendation >>> >>> of what features we think should be enabled in shipping releases. In >>> some >>> >>> cases, this may not match the settings on trunk, as some features >>> may be >>> >>> desirable to enable for experimental builds, but not in shipping >>> product. >>> >>> For features that we recommended disabling, ideally we'd identify a >>> reason. >>> >>> And in some cases, those might be port-specific issues. >>> >> >>> >> >>> >> Right. Even just having a list of new features with flag(s) to >>> >> enable/disable and the status (e.g. list of outstanding bugs) on wiki >>> page >>> >> will be helpful. >>> >> >>> >> For example, vertical writing mode doesn't work on Windows, Chromium, >>> etc... >>> >> but port owners may not necessarily realize that the feature is >>> enabled by >>> >> default and each port needs to modify the code that draws text. >>> >> >>> >> >>> >> I personally think such a page would be a good idea. I'd love to hear >>> input >>> >> from more folks on whether this is a good idea and what the right >>> approach >>> >> is. >>> >> >>> >> Cheers, >>> >> Maciej >>> >> >>> >> ___ >>> >> 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 >>> >> >> >> >> -- >> TAMURA Kent >> Software Engineer, Google >> >> >> >> > > > -- > TAMURA Kent > Software Engineer, Google > > > > > ___ > webkit-dev mailing list > webkit-dev
Re: [webkit-dev] Git/SVN is slow
Well I was just about to follow up that from the east coast on Comcast bbone, I'm pulling at acceptable rates from git.webkit.org, ~700KiB/s. That's about as fast as it's always been. Same goes for nightly.webkit.org . There's a number of possible issues that would result in slow response times and slow downloads. E.g., it could be sheer packet loss between carrier backbones and not necessarily tapped bandwidth. On Thu, Mar 15, 2012 at 1:45 PM, Ryosuke Niwa wrote: > I don't really think checking the latency is interesting. What's killing > us is bandwidth. As far as I tested yesterday, the ping at my work (Google > SF office) gives me a reasonable time as well. > > There's something that's killing our bandwidth. Does anyone know some > tools to investigate this? > > - Ryosuke > > > On Thu, Mar 15, 2012 at 10:40 AM, Jarred Nicholls wrote: > >> Ditto, @ ae-11-70 attempting to get to ae-21-60 the trace dies. Pings to >> svn.webkit.org succeed in acceptable times however, for me. Perhaps the >> hops following ae-11-70 and ae-21-60 simple aren't able to reply with >> proper ICMP packets; no real conclusion to based on that info alone, but >> maybe worth passing off to the provider and/or directly to Level3. >> >> Jarred >> >> >> On Thu, Mar 15, 2012 at 1:22 PM, Levi Weintraub wrote: >> >>> Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN >>> updates are dog slow :( >>> >>> 6 pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230) 4.306 ms 4.966 >>> ms * >>> 7 xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153) 20.116 ms 3.031 >>> ms 3.056 ms >>> 8 ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 4.316 ms >>> ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 4.239 ms >>> ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 4.545 ms >>> 9 * * * >>> 10 * * * >>> 11 * * * >>> >>> >>> On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers wrote: >>> Bill, I'm currently pulling from svn.webkit.org at what feels like 5kbps, and poor http://build.webkit.org/console hits the page refresh before it's even able to render to the bottom :( Below is a traceroute to webkit.org: traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte packets 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) 14.588 ms 15.541 ms 15.733 ms 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) 16.563 ms 16.929 ms 16.946 ms 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) 17.967 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net(68.86.93.125) 14.599 ms 11.428 ms 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 ms 34.950 ms 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms 65.766 ms 66.692 ms 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 ms 78.175 ms 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms 78.520 ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Thanks for looking into this. Philip On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist >>> > wrote: > Our network provider did not find anything wrong. If anyone is > currently seeing slow download times, I would like to see a traceroute to > the server. > > Thanks, > -Bill > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webk
Re: [webkit-dev] Git/SVN is slow
I don't really think checking the latency is interesting. What's killing us is bandwidth. As far as I tested yesterday, the ping at my work (Google SF office) gives me a reasonable time as well. There's something that's killing our bandwidth. Does anyone know some tools to investigate this? - Ryosuke On Thu, Mar 15, 2012 at 10:40 AM, Jarred Nicholls wrote: > Ditto, @ ae-11-70 attempting to get to ae-21-60 the trace dies. Pings to > svn.webkit.org succeed in acceptable times however, for me. Perhaps the > hops following ae-11-70 and ae-21-60 simple aren't able to reply with > proper ICMP packets; no real conclusion to based on that info alone, but > maybe worth passing off to the provider and/or directly to Level3. > > Jarred > > > On Thu, Mar 15, 2012 at 1:22 PM, Levi Weintraub wrote: > >> Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN updates >> are dog slow :( >> >> 6 pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230) 4.306 ms 4.966 >> ms * >> 7 xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153) 20.116 ms 3.031 >> ms 3.056 ms >> 8 ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 4.316 ms >> ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 4.239 ms >> ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 4.545 ms >> 9 * * * >> 10 * * * >> 11 * * * >> >> >> On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers wrote: >> >>> Bill, >>> >>> I'm currently pulling from svn.webkit.org at what feels like 5kbps, and >>> poor http://build.webkit.org/console hits the page refresh before it's >>> even able to render to the bottom :( >>> >>> Below is a traceroute to webkit.org: >>> traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte >>> packets >>> 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms >>> 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms >>> 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms >>> 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) >>> 14.588 ms 15.541 ms 15.733 ms >>> 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) >>> 16.563 ms 16.929 ms 16.946 ms >>> 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) >>> 17.967 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125) >>> 14.599 ms 11.428 ms >>> 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms >>> 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms >>> vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms >>> vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms >>> 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms >>> ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms >>> ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms >>> 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 ms >>> 34.950 ms >>> 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms 65.766 >>> ms 66.692 ms >>> 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 >>> ms 78.175 ms >>> 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms 78.520 >>> ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms >>> 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms >>> ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms >>> ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms >>> 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms >>> ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms >>> ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms >>> 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms >>> ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms >>> ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms >>> 17 * * * >>> 18 * * * >>> 19 * * * >>> 20 * * * >>> 21 * * * >>> 22 * * * >>> 23 * * * >>> 24 * * * >>> 25 * * * >>> 26 * * * >>> 27 * * * >>> 28 * * * >>> 29 * * * >>> 30 * * * >>> >>> Thanks for looking into this. >>> Philip >>> >>> On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist >>> wrote: >>> Our network provider did not find anything wrong. If anyone is currently seeing slow download times, I would like to see a traceroute to the server. Thanks, -Bill ___ 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 >>> >>> >> >> ___ >> 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] Git/SVN is slow
Ditto, @ ae-11-70 attempting to get to ae-21-60 the trace dies. Pings to svn.webkit.org succeed in acceptable times however, for me. Perhaps the hops following ae-11-70 and ae-21-60 simple aren't able to reply with proper ICMP packets; no real conclusion to based on that info alone, but maybe worth passing off to the provider and/or directly to Level3. Jarred On Thu, Mar 15, 2012 at 1:22 PM, Levi Weintraub wrote: > Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN updates > are dog slow :( > > 6 pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230) 4.306 ms 4.966 > ms * > 7 xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153) 20.116 ms 3.031 > ms 3.056 ms > 8 ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 4.316 ms > ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 4.239 ms > ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 4.545 ms > 9 * * * > 10 * * * > 11 * * * > > > On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers wrote: > >> Bill, >> >> I'm currently pulling from svn.webkit.org at what feels like 5kbps, and >> poor http://build.webkit.org/console hits the page refresh before it's >> even able to render to the bottom :( >> >> Below is a traceroute to webkit.org: >> traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte >> packets >> 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms >> 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms >> 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms >> 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) >> 14.588 ms 15.541 ms 15.733 ms >> 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) >> 16.563 ms 16.929 ms 16.946 ms >> 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) 17.967 >> ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125) 14.599 >> ms 11.428 ms >> 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms >> 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms >> vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms >> vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms >> 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms >> ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms >> ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms >> 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 ms >> 34.950 ms >> 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms 65.766 >> ms 66.692 ms >> 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 ms >> 78.175 ms >> 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms 78.520 >> ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms >> 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms >> ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms >> ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms >> 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms >> ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms >> ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms >> 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms >> ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms >> ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms >> 17 * * * >> 18 * * * >> 19 * * * >> 20 * * * >> 21 * * * >> 22 * * * >> 23 * * * >> 24 * * * >> 25 * * * >> 26 * * * >> 27 * * * >> 28 * * * >> 29 * * * >> 30 * * * >> >> Thanks for looking into this. >> Philip >> >> On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist >> wrote: >> >>> Our network provider did not find anything wrong. If anyone is currently >>> seeing slow download times, I would like to see a traceroute to the server. >>> >>> Thanks, >>> -Bill >>> >>> >>> ___ >>> 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 >> >> > > ___ > 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] Git/SVN is slow
It appears that I get a much better bandwidth (can download the svn tarball at roughly 1.8MB/s) at home (Comcast business class) than at work (something around 10-20KB/s yesterday). At home, I see: traceroute to webkit.org (17.254.20.237), 64 hops max, 52 byte packets 1 buffalo.setup (192.168.11.1) 5.823 ms 0.916 ms 0.863 ms 2 10.1.10.1 (10.1.10.1) 1.876 ms 1.698 ms 1.662 ms 3 96.135.192.1 (96.135.192.1) 36.260 ms 28.821 ms 30.721 ms 4 te-4-1-ur01.sffolsom.ca.sfba.comcast.net (68.85.100.121) 13.265 ms 12.646 ms 12.627 ms 5 te-1-10-0-2-ar01.sfsutro.ca.sfba.comcast.net (68.85.154.62) 23.339 ms 39.367 ms 14.842 ms 6 pos-3-2-0-0-cr01.sanjose.ca.ibone.comcast.net (68.86.90.153) 18.621 ms 16.256 ms 15.185 ms 7 xe-11-1-0.edge1.sanjose1.level3.net (4.79.43.133) 16.010 ms 11.261 ms 16.856 ms 8 ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 12.322 ms ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 15.883 ms ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 17.818 ms 9 * * * 10 * * * 11 * * * ... - Ryosuke On Thu, Mar 15, 2012 at 10:22 AM, Levi Weintraub wrote: > Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN updates > are dog slow :( > > 6 pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230) 4.306 ms 4.966 > ms * > 7 xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153) 20.116 ms 3.031 > ms 3.056 ms > 8 ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 4.316 ms > ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 4.239 ms > ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 4.545 ms > 9 * * * > 10 * * * > 11 * * * > > > On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers wrote: > >> Bill, >> >> I'm currently pulling from svn.webkit.org at what feels like 5kbps, and >> poor http://build.webkit.org/console hits the page refresh before it's >> even able to render to the bottom :( >> >> Below is a traceroute to webkit.org: >> traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte >> packets >> 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms >> 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms >> 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms >> 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) >> 14.588 ms 15.541 ms 15.733 ms >> 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) >> 16.563 ms 16.929 ms 16.946 ms >> 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) 17.967 >> ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125) 14.599 >> ms 11.428 ms >> 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms >> 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms >> vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms >> vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms >> 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms >> ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms >> ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms >> 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 ms >> 34.950 ms >> 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms 65.766 >> ms 66.692 ms >> 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 ms >> 78.175 ms >> 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms 78.520 >> ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms >> 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms >> ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms >> ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms >> 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms >> ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms >> ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms >> 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms >> ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms >> ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms >> 17 * * * >> 18 * * * >> 19 * * * >> 20 * * * >> 21 * * * >> 22 * * * >> 23 * * * >> 24 * * * >> 25 * * * >> 26 * * * >> 27 * * * >> 28 * * * >> 29 * * * >> 30 * * * >> >> Thanks for looking into this. >> Philip >> >> On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist >> wrote: >> >>> Our network provider did not find anything wrong. If anyone is currently >>> seeing slow download times, I would like to see a traceroute to the server. >>> >>> Thanks, >>> -Bill >>> >>> >>> ___ >>> 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 >> >> > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi
Re: [webkit-dev] Git/SVN is slow
My "git fetch" transfer rates seam to depend on the time and day of the week. Last weekend I fetched with about 800 KiB/s, now I get about 250 KiB/s, but I reach only about 40 KiB/s during US working hours 1-2 weeks ago. The traceroute looks the same from Austria: 9 ae-11-11.car1.Vienna1.Level3.net (4.69.135.29) 1.870 ms 1.860 ms 0.867 ms 10 ae-6-6.ebr1.Frankfurt1.Level3.net (4.69.135.34) 12.836 ms 12.833 ms 12.923 ms 11 ae-61-61.csw1.Frankfurt1.Level3.net (4.69.140.2) 12.912 ms ae-91-91.csw4.Frankfurt1.Level3.net (4.69.140.14) 12.911 ms ae-71-71.csw2.Frankfurt1.Level3.net (4.69.140.6) 12.912 ms 12 ae-72-72.ebr2.Frankfurt1.Level3.net (4.69.140.21) 12.911 ms ae-62-62.ebr2.Frankfurt1.Level3.net (4.69.140.17) 12.901 ms ae-72-72.ebr2.Frankfurt1.Level3.net (4.69.140.21) 12.922 ms 13 ae-23-23.ebr2.London1.Level3.net (4.69.148.193) 21.908 ms ae-22-22.ebr2.London1.Level3.net (4.69.148.189) 21.898 ms ae-21-21.ebr2.London1.Level3.net (4.69.148.185) 21.897 ms 14 ae-44-44.ebr1.NewYork1.Level3.net (4.69.137.78) 90.846 ms ae-43-43.ebr1.NewYork1.Level3.net (4.69.137.74) 90.921 ms ae-42-42.ebr1.NewYork1.Level3.net (4.69.137.70) 90.917 ms 15 ae-81-81.csw3.NewYork1.Level3.net (4.69.134.74) 90.899 ms ae-91-91.csw4.NewYork1.Level3.net (4.69.134.78) 90.896 ms ae-81-81.csw3.NewYork1.Level3.net (4.69.134.74) 90.893 ms 16 ae-62-62.ebr2.NewYork1.Level3.net (4.69.148.33) 90.891 ms ae-72-72.ebr2.NewYork1.Level3.net (4.69.148.37) 90.882 ms ae-62-62.ebr2.NewYork1.Level3.net (4.69.148.33) 90.881 ms 17 ae-2-2.ebr4.SanJose1.Level3.net (4.69.135.185) 158.886 ms 158.877 ms 158.873 ms 18 ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 158.869 ms ae-71-71.csw2.SanJose1.Level3.net (4.69.153.6) 161.884 ms ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 159.883 ms 19 ae-11-70.car1.SanJose2.Level3.net (4.69.152.75) 159.880 ms ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 159.867 ms 159.857 ms 20 * * * 21 * * * 22 * * * - Patrick Am 15.03.2012 um 18:22 schrieb Levi Weintraub: > Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN updates are > dog slow :( > > 6 pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230) 4.306 ms 4.966 ms * > 7 xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153) 20.116 ms 3.031 ms > 3.056 ms > 8 ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 4.316 ms > ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 4.239 ms > ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 4.545 ms > 9 * * * > 10 * * * > 11 * * * > > > On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers wrote: > Bill, > > I'm currently pulling from svn.webkit.org at what feels like 5kbps, and poor > http://build.webkit.org/console hits the page refresh before it's even able > to render to the bottom :( > > Below is a traceroute to webkit.org: > traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte packets > 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms > 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms > 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms > 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) 14.588 > ms 15.541 ms 15.733 ms > 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) 16.563 > ms 16.929 ms 16.946 ms > 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) 17.967 ms > pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125) 14.599 ms > 11.428 ms > 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms > 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms > vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms > vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms > 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms > ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms > ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms > 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 ms > 34.950 ms > 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms 65.766 ms > 66.692 ms > 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 ms > 78.175 ms > 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms 78.520 ms > ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms > 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms > ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms > ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms > 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms > ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms > ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms > 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms > ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms > ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * *
[webkit-dev] WebKitIDL syntax: unsigned int
"unsigned int" is an invalid Type in WebIDL.
{Int8,Uint8,Uint8Clamped,Int16,Uint16,Int32,Uint32,Float32,Float64}Array.idl
define: const unsigned int BYTES_PER_ELEMENT.
Latest Typed Array Specification defines BYTES_PER_ELEMENT as
unsigned long.
http://www.khronos.org/registry/typedarray/specs/latest/
It seems to me that code generators ignore types of constants.
Therefore fixing this should be harmless, but I want to make sure.
Am I right?
--
Seo Sanghyeon
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git/SVN is slow
Likewise, I lose everything past *.car1.sanjose2.level3.net. SVN updates are dog slow :( 6 pr01-xe-8-2-0.sjc07.net.google.com (72.14.218.230) 4.306 ms 4.966 ms * 7 xe-11-1-0.edge2.sanjose3.level3.net (4.79.40.153) 20.116 ms 3.031 ms 3.056 ms 8 ae-31-90.car1.sanjose2.level3.net (4.69.152.203) 4.316 ms ae-11-70.car1.sanjose2.level3.net (4.69.152.75) 4.239 ms ae-21-60.car1.sanjose2.level3.net (4.69.152.11) 4.545 ms 9 * * * 10 * * * 11 * * * On Thu, Mar 15, 2012 at 7:31 AM, Philip Rogers wrote: > Bill, > > I'm currently pulling from svn.webkit.org at what feels like 5kbps, and > poor http://build.webkit.org/console hits the page refresh before it's > even able to render to the bottom :( > > Below is a traceroute to webkit.org: > traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte packets > 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms > 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms > 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms > 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) > 14.588 ms 15.541 ms 15.733 ms > 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) > 16.563 ms 16.929 ms 16.946 ms > 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) 17.967 > ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125) 14.599 > ms 11.428 ms > 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms > 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms > vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms > vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms > 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms > ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms > ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms > 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 ms > 34.950 ms > 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms 65.766 > ms 66.692 ms > 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 ms > 78.175 ms > 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms 78.520 > ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms > 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms > ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms > ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms > 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms > ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms > ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms > 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms > ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms > ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * * > 28 * * * > 29 * * * > 30 * * * > > Thanks for looking into this. > Philip > > On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist wrote: > >> Our network provider did not find anything wrong. If anyone is currently >> seeing slow download times, I would like to see a traceroute to the server. >> >> Thanks, >> -Bill >> >> >> ___ >> 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 > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] NPAPI plugin crashes while calling npnfuncs->invoke in GtkLauncher
Please find the gdb trace: Program received signal SIGSEGV, Segmentation fault. 0x0046b886 in _NPN_Invoke () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 (gdb) bt #0 0x0046b886 in _NPN_Invoke () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #1 0x02a86fe0 in threadImplementation (msg=0x0) at wcfplugin.c:110 #2 0x0099585a in WebCore::PluginMainThreadScheduler::dispatchCallsForPlugin(_NPP*, WTF::Deque const&) () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #3 0x00995cd1 in WebCore::PluginMainThreadScheduler::dispatchCalls() () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #4 0x00995d6d in WebCore::PluginMainThreadScheduler::mainThreadCallback(void*) () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #5 0x01504f43 in WTF::dispatchFunctionsFromMainThread() () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libjavascriptcoregtk-3.0.so.0 #6 0x01504ba7 in WTF::timeoutFired(void*) () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libjavascriptcoregtk-3.0.so.0 #7 0x026234dc in g_timeout_dispatch (source=0x81ed5b8, callback=0x46b860 <_NPN_Invoke>, user_data=0x0) at gmain.c:3907 #8 0x02622d15 in g_main_dispatch (context=0x80804a0) at gmain.c:2441 #9 g_main_context_dispatch (context=0x80804a0) at gmain.c:3011 #10 0x02626b20 in g_main_context_iterate (context=0x80804a0, block=, dispatch=1, self=0x80516e0) at gmain.c:3089 #11 0x02626f4f in g_main_loop_run (loop=0x81f94c8) at gmain.c:3297 #12 0x01ce8e64 in gtk_dialog_run (dialog=0x81f40a8) at gtkdialog.c:1110 #13 0x002f5cf0 in webkit_web_view_script_dialog(_WebKitWebView*, _WebKitWebFrame*, char const*, WebKitScriptDialogType, char const*, char**) () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #14 0x002f5f3f in webkit_web_view_real_script_alert(_WebKitWebView*, _WebKitWebFrame*, char const*) () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #15 0x002ff36b in webkit_marshal_BOOLEAN__OBJECT_STRING () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #16 0x0257eea7 in g_type_class_meta_marshal (closure=0xbfffe2c4, return_value=0xbfffe2c4, n_param_values=3, param_values=0x81f40a8, invocation_hint=0xbfffe2b0, marshal_data=0x200) at gclosure.c:885 #17 0x025805ea in g_closure_invoke (closure=0x80b5978, return_value=0xbfffe2c4, n_param_values=3, param_values=0x812c920, invocation_hint=0xbfffe2b0) at gclosure.c:774 #18 0x02597490 in signal_emit_unlocked_R (node=, detail=, instance=0x80c0008, emission_return=0xbfffe41c, instance_and_params=0x812c920) at gsignal.c:3310 #19 0x0259898b in g_signal_emit_valist (instance=0x80c0008, signal_id=170, detail=0, var_args=0xbfffe4e0 "\374\344\377\277(\346\377\277\b\345\377\277ڨ\212") at gsignal.c:3013 #20 0x02598d7a in g_signal_emit_by_name (instance=0x80c0008, detailed_signal=0x116199a "script-alert") at gsignal.c:3097 #21 0x002bfe8e in WebKit::ChromeClient::runJavaScriptAlert(WebCore::Frame*, WTF::String const&) () ---Type to continue, or q to quit--- from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #22 0x0087b693 in WebCore::Chrome::runJavaScriptAlert(WebCore::Frame*, WTF::String const&) () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #23 0x0088c9d1 in WebCore::DOMWindow::alert(WTF::String const&) () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #24 0x00dac0ea in WebCore::jsDOMWindowPrototypeFunctionAlert(JSC::ExecState*) () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #25 0x02a82c09 in ?? () #26 0x013a5ba2 in JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libjavascriptcoregtk-3.0.so.0 #27 0x01455d86 in JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libjavascriptcoregtk-3.0.so.0 #28 0x003f8f5f in WebCore::JSMainThreadExecState::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&) () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #29 0x003f8508 in WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*) () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #30 0x0057c635 in WebCore::EventTarget::fireEventListeners(WebCore::Event*, WebCore::EventTargetData*, WTF::Vector&) () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #31 0x0057c78d in WebCore::EventTarget::fireEventListeners(WebCore::Event*) () from /home/souvik/Webkit/Webkit/webkit-1.6.1/.libs/libwebkitgtk-3.0.so.0 #32 0x0058b572 in WebCore::Node::handleLocalEven
Re: [webkit-dev] NPAPI plugin crashes while calling npnfuncs->invoke in GtkLauncher
En 15/03/12 08:13, souvik.da...@wipro.com escribiu: > Hi, > > I am trying to load my NPAPI plugin in GtkLauncher ( built from source > version-1.6.1 under Ubuntu 10.10). The plugin is used to communicate > with a native shared library. Although I am able to load the plugin ( > Got NP_Initialize and NP_GetEntryPoints calls on the console ) and make > successful calls to my native shared library from Java Scripts (through > my plugin), but when I am trying to call a java script function "from" > my plugin using : > > err = npnfuncs->invoke(npp_, console, id, args_temp, > sizeof(args_temp) / sizeof(args_temp[0]), > &voidResponse); > > I am observing a segmentation fault. This is always happenning. Can you get a trace? BR ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Git/SVN is slow
Bill, I'm currently pulling from svn.webkit.org at what feels like 5kbps, and poor http://build.webkit.org/console hits the page refresh before it's even able to render to the bottom :( Below is a traceroute to webkit.org: traceroute to svn.webkit.org (17.254.20.241), 30 hops max, 60 byte packets 1 DD-WRT (192.168.2.1) 0.233 ms 0.297 ms 0.371 ms 2 10.1.10.1 (10.1.10.1) 2.446 ms 2.445 ms 2.518 ms 3 96.176.191.1 (96.176.191.1) 24.451 ms 25.398 ms 28.688 ms 4 xe-11-0-0-0-sur01.a2atlanta.ga.atlanta.comcast.net (68.85.91.177) 14.588 ms 15.541 ms 15.733 ms 5 xe-2-1-3-0-ar01.b0atlanta.ga.atlanta.comcast.net (68.86.106.57) 16.563 ms 16.929 ms 16.946 ms 6 pos-3-6-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.201) 17.967 ms pos-3-5-0-0-cr01.atlanta.ga.ibone.comcast.net (68.86.93.125) 14.599 ms 11.428 ms 7 4.28.24.77 (4.28.24.77) 15.973 ms 17.858 ms 17.307 ms 8 vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 19.688 ms vlan52.ebr2.Atlanta2.Level3.net (4.69.150.126) 14.891 ms vlan51.ebr1.Atlanta2.Level3.net (4.69.150.62) 15.116 ms 9 ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.651 ms ae-63-63.ebr3.Atlanta2.Level3.net (4.69.148.241) 13.767 ms ae-73-73.ebr3.Atlanta2.Level3.net (4.69.148.253) 14.955 ms 10 ae-7-7.ebr3.Dallas1.Level3.net (4.69.134.21) 34.004 ms 36.807 ms 34.950 ms 11 ae-3-3.ebr2.LosAngeles1.Level3.net (4.69.132.77) 66.601 ms 65.766 ms 66.692 ms 12 ae-6-6.ebr2.SanJose5.Level3.net (4.69.148.202) 78.577 ms 78.007 ms 78.175 ms 13 ae-1-100.ebr1.SanJose5.Level3.net (4.69.148.109) 78.594 ms 78.520 ms ae-5-5.ebr4.SanJose1.Level3.net (4.69.148.142) 81.371 ms 14 ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 71.989 ms ae-5-5.ebr1.SanJose1.Level3.net (4.69.148.138) 77.341 ms ae-34-34.ebr2.SanJose1.Level3.net (4.69.153.33) 77.662 ms 15 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 80.375 ms ae-61-61.csw1.SanJose1.Level3.net (4.69.153.2) 87.895 ms ae-81-81.csw3.SanJose1.Level3.net (4.69.153.10) 77.137 ms 16 ae-31-90.car1.SanJose2.Level3.net (4.69.152.203) 77.660 ms ae-41-80.car1.SanJose2.Level3.net (4.69.152.139) 78.313 ms ae-21-60.car1.SanJose2.Level3.net (4.69.152.11) 77.746 ms 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * * 28 * * * 29 * * * 30 * * * Thanks for looking into this. Philip On Thu, Mar 15, 2012 at 10:23 AM, William Siegrist wrote: > Our network provider did not find anything wrong. If anyone is currently > seeing slow download times, I would like to see a traceroute to the server. > > Thanks, > -Bill > > > ___ > 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] Git/SVN is slow
Our network provider did not find anything wrong. If anyone is currently seeing slow download times, I would like to see a traceroute to the server. Thanks, -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] When should we turn on new features?
I made https://trac.webkit.org/wiki/FeatureFlags . I extracted all of ENABLE(FOO) in *.cpp and *.mm, and added some comments. Feel free to edit it! On Wed, Mar 14, 2012 at 13:03, TAMURA, Kent wrote: I'll add a Wiki page for the table of existing feature flags and their descriptions. On Tue, Feb 14, 2012 at 11:09, Maciej Stachowiak wrote: I think we're talking about a couple of different things now: 1) Table of what the WebKit community as a whole (instead of individual point maintainers) thinks should be enabled in stable releases. This would be input to port maintainers looking to make a release. 2) Documenting what enable flags are actually on for given ports as shipped. Probably hard to gather this info, but might be useful input for the WebKit community. 3) Changing build systems to enable compiling "nightly" and "stable" versions from the same tree, so both modes are documented in trunk. Requires some coding for various build systems. I like (2) and (3), but I don't think they replace the usefulness of (1). I think the mention of "the feature-table page" is blending (2) and (1), which would serve different purposes. Regards, Maciej On Feb 13, 2012, at 4:21 PM, Hajime Morrita wrote: > (Re-sending from the right address...) > > I'd +1 Adam's point. > > It would be great if we can do something like "webkit-build --gtk > --stable", "webkit-build --chromium --canary" or "webkit-build > --nightly" where the script read the central configuration file and > find an appropriate configuration. In this way, there would be no > duplication we should maintain. > > Even though some ports currently don't support switches through > build-webkit, we can gradually switch over to the central list-based > configuration settings by, for example, generating features.gypi, > FeatureDefines.xcconfig or a set of flags for autoconf. > > Also the feature-table page could be generated from the list. We can > even start from simply generating an HTML from the machine-readable > configuration file, then integrate it to each build system. > > Although it might be overkill, I personally prefer this kind of "don't > repeat youself" direction. > -- > morrita > > On Tue, Feb 14, 2012 at 8:11 AM, Maciej Stachowiak wrote: >> >> On Feb 13, 2012, at 1:21 PM, Ryosuke Niwa wrote: >> >> On Mon, Feb 13, 2012 at 1:02 PM, Maciej Stachowiak wrote: >>> >>> I think you raise a good point. Another point worth mentioning is that >>> sometimes a feature can be complete and useful in one port, but half-baked >>> in another (for example, fullscreen API was shipped in Safari and at the >>> same time present but non-functional in Chrome). >>> >>> I think in the past, port owners have made clear that they want to own the >>> final decisions on what features are enabled in their ports. >>> >>> But we as a community could do better, by having a shared recommendation >>> of what features we think should be enabled in shipping releases. In some >>> cases, this may not match the settings on trunk, as some features may be >>> desirable to enable for experimental builds, but not in shipping product. >>> For features that we recommended disabling, ideally we'd identify a reason. >>> And in some cases, those might be port-specific issues. >> >> >> Right. Even just having a list of new features with flag(s) to >> enable/disable and the status (e.g. list of outstanding bugs) on wiki page >> will be helpful. >> >> For example, vertical writing mode doesn't work on Windows, Chromium, etc... >> but port owners may not necessarily realize that the feature is enabled by >> default and each port needs to modify the code that draws text. >> >> >> I personally think such a page would be a good idea. I'd love to hear input >> from more folks on whether this is a good idea and what the right approach >> is. >> >> Cheers, >> Maciej >> >> ___ >> 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 -- TAMURA Kent Software Engineer, Google -- TAMURA Kent Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] NPAPI plugin crashes while calling npnfuncs->invoke in GtkLauncher
Hi, I am trying to load my NPAPI plugin in GtkLauncher ( built from source version-1.6.1 under Ubuntu 10.10). The plugin is used to communicate with a native shared library. Although I am able to load the plugin ( Got NP_Initialize and NP_GetEntryPoints calls on the console ) and make successful calls to my native shared library from Java Scripts (through my plugin), but when I am trying to call a java script function "from" my plugin using : err = npnfuncs->invoke(npp_, console, id, args_temp, sizeof(args_temp) / sizeof(args_temp[0]), &voidResponse); I am observing a segmentation fault. This is always happenning. Note : I have found our plug-in to work fine with Firefox. Can some one please throw some light on this and tell me if I am missing something here? Do I have to build by NPAPI plug-in using some webkit specific primitive? Thanks and Regards, Souvik Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
