On Aug 9, 2010, at 8:21 PM, Timothy Hatcher wrote:
> On Aug 9, 2010, at 7:52 PM, Dimitri Glazkov wrote:
>
>> I am very, very tempted to just get rid of them. As Ojan indicated,
>> the use cases for DOM Mutation events are extremely limited and to me,
>> most of them feel like we should be solvin
On Aug 10, 2010, at 2:26 PM, Alexey Proskuryakov wrote:
>
> 10.08.2010, в 14:00, Adam Barth написал(а):
>
>> A better long-term fix might be to finish new-run-webkit-tests so we
>> can run the tests in parallel.
>
>
> One reason to move the tests to run-javascriptcore-tests is that people
>
On Aug 10, 2010, at 11:39 PM, Xan Lopez wrote:
> For the GObject bindings I'm actually exposing the events directly.
This is a new feature, no other binding has this, and you will have to build
everything yourself. There’s nothing in IDL files, or in fact anywhere in the
project, that lists all
On Aug 7, 2010, at 8:59 PM, Eric Seidel wrote:
> How about we add a Ptr (or WeakPtr or AutoNull or whatever)
I worked on another project years ago where they had a template like this. The
issue is with a variety of built-in data types, not specific to pointers. Any
built-in data type such as a
If these tests are actually valuable, then maybe my question then
belongs: Why is Chromium no longer running these tests? (Assuming my
source is correct.)
-eric
On Wed, Aug 11, 2010 at 7:10 AM, Maciej Stachowiak wrote:
>
> On Aug 10, 2010, at 2:26 PM, Alexey Proskuryakov wrote:
>
>>
>> 10.08.20
> From: da...@apple.com
> Date: Wed, 11 Aug 2010 09:12:29 -0700
> To: e...@webkit.org
> CC: webkit-dev@lists.webkit.org
> Subject: Re: [webkit-dev] Ptr
>
> On Aug 7, 2010, at 8:59 PM, Eric Seidel wrote:
>
> > How about we add a Ptr (or WeakPtr or AutoNull
Just looking at the history, it looks like when the tests were originally
checked in, they had no expected results. So someone on the chromium team
skipped them all. There's a comment in
http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium/test_expectations.txtthat
"we probably don't
> http://themaninblue.com/experiment/AnimationBenchmark/canvas/
>
> Jumped from 37fps to 85fps.
Do you post the patch somewhere? Would be lovely to try this on QtWebKit...
--
Ariya Hidayat
http://www.linkedin.com/in/ariyahidayat
___
webkit-dev mailin
AutoNull sounds like a good idea, in addition to initializing to zero,
I would like it handle operator-> to not crash ! Something like
handling Java's NullPointerException
--
Chinmaya
On Sat, Aug 7, 2010 at 9:59 PM, Eric Seidel wrote:
> I just spent a while debugging an error in code I wrote.
>
Yeah I'll get it posted soon in a bug. I need to make get/PutImageData work
first. :)
dave
On Aug 11, 2010, at 12:35 PM, Ariya Hidayat wrote:
>> http://themaninblue.com/experiment/AnimationBenchmark/canvas/
>>
>> Jumped from 37fps to 85fps.
>
> Do you post the patch somewhere? Would be lovel
The V8 buildbots are running the sputnik tests and they do catch
regressions for us. In the V8 repository we have a list of V8 test
expectations for the sputnik tests.
http://build.chromium.org/buildbot/v8/waterfall
-- Mads
On Wed, Aug 11, 2010 at 7:32 PM, Ojan Vafai wrote:
> Just looking at th
Clearly I was misinformed. My apologies for using the webkit-dev list
to track down this chromium-specific issue.
On Wed, Aug 11, 2010 at 11:09 AM, Mads Sig Ager wrote:
> The V8 buildbots are running the sputnik tests and they do catch
> regressions for us. In the V8 repository we have a list of
No apologies necessary! This was illuminating to me too, even though I
_might have_ been the guy who put the "we probably don't want to run
these" comment in :P
:DG<
On Wed, Aug 11, 2010 at 11:19 AM, Eric Seidel wrote:
> Clearly I was misinformed. My apologies for using the webkit-dev list
> to
Maybe a comment in the text_expectations file to point out where they are
run might be a good idea.
Avi
On Wed, Aug 11, 2010 at 2:27 PM, Dimitri Glazkov wrote:
> No apologies necessary! This was illuminating to me too, even though I
> _might have_ been the guy who put the "we probably don't want
Given Maciej's and Adam's comments about these tests helping find
non-JS-engine-specific regressions, why not always run them?
On Wed, Aug 11, 2010 at 11:09 AM, Mads Sig Ager wrote:
> The V8 buildbots are running the sputnik tests and they do catch
> regressions for us. In the V8 repository we ha
On Wed, Aug 11, 2010 at 5:56 PM, Darin Adler wrote:
> On Aug 10, 2010, at 11:39 PM, Xan Lopez wrote:
>
>> For the GObject bindings I'm actually exposing the events directly.
>
> This is a new feature, no other binding has this, and you will have to build
> everything yourself. There’s nothing in
On Wed, Aug 11, 2010 at 8:39 AM, Xan Lopez wrote:
> On Wed, Aug 11, 2010 at 7:51 AM, Darin Adler wrote:
>> The bindings do not expose events directly, thus the IDL files don’t show
>> the events. The IDL files only show functions and attributes on the various
>> objects. Events are neither func
Currently for a function's signature in WebKit, if an argument's type
is a wrapper type (those JS objec ts that wrap c++ objects, for
example, JSWebGLProgram, JSCSSRule, etc.) and if the input object's
type does not match the signature, the input is casted to null and no
TypeError is raised.
Even
This sounds related to the recent addition of
[RequiresAllArguments=Raise]. Historically, we've been lax about
missing arguments. I think the specs want us to be stricter, but last
time we discussed the topic, the read I got was that the compatibility
pain might not be worth the benefit.
Adam
I am not sure this is true across the board, in many places we set the
exception code to TYPE_MISMATCH_ERR on null input in the implementation (the
first one I looked at was CanvasRenderingContext2D::drawImage). Can you go
into more detail about why the WebGL bindings need to be more strict than
th
For example,
webgl.useProgram("foo");
This should throw an error. However, current behavior will execute
webgl.useProgram(null)
instead, which will run through without even generating an gl error.
I saw a few TYPE_MISMATCH_ERROR in custom-binding. To me, whether
it's TYPE_MISMATCH_ER
Hi All,
I got the problem like, When I run the test code html file with google
chrome the out is as expected
.But if I run the same html file on gtkLauncher the output is different.
But When I run it through DRT(dumprenderTree) it shows PASS.
My expectation it should show Fail. I have paste bin t
For this specific case, it seems like you could easily check for a null
WebGLProgram* in WebGLRenderingContext::useProgram and set the
ExceptionCode.
-Sam
On Wed, Aug 11, 2010 at 8:54 PM, Mo, Zhenyao wrote:
> For example,
>
>webgl.useProgram("foo");
>
> This should throw an error. However,
On Thu, Aug 12, 2010 at 13:26, Sam Weinig wrote:
> For this specific case, it seems like you could easily check for a null
> WebGLProgram* in WebGLRenderingContext::useProgram and set the
> ExceptionCode.
Nope, null is a valid argument, it bounds to the initial program, which
means nothing will
On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier wrote:
> On Thu, Aug 12, 2010 at 13:26, Sam Weinig wrote:
>
>> For this specific case, it seems like you could easily check for a null
>> WebGLProgram* in WebGLRenderingContext::useProgram and set the
>> ExceptionCode.
>
>
> Nope, null is a valid a
On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig wrote:
> On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier wrote:
>
>> On Thu, Aug 12, 2010 at 13:26, Sam Weinig wrote:
>>
>>> For this specific case, it seems like you could easily check for a null
>>> WebGLProgram* in WebGLRenderingContext::useProgram
Actually it's a different issue. What we want to do is not enforcing
full arguments, but if an input argument is the wrong type, we raise a
TypeError.
Mo
On Wed, Aug 11, 2010 at 7:13 PM, Adam Barth wrote:
> This sounds related to the recent addition of
> [RequiresAllArguments=Raise]. Historica
The auto-generated code will look like
If (argument.isUndefinedOrNull() == false && toType(argument) == null)
raise(TypeError);
I really think we should do this universally. However, if there is a
good reason we really shouldn't, please let us know.
On Wed, Aug 11, 2010 at 11:10 PM, M
28 matches
Mail list logo
