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/sh
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
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
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
> 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. Typ
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
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.
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 s
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 http
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,U
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'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
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
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
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?
- Ryo
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 wor
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
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.Level
"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/lat
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
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
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
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
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/mailma
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 Tu
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 success
26 matches
Mail list logo
