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 aba...@webkit.org wrote:
This sounds related to the recent addition of
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,
if converting a JS argument to the type declared in the IDL file throws an
exception, the auto-generated code will throw a TYPE_MISMATCH_ERR. so i
think we just need to change toJS/toV8 to throw exceptions when conversions
fails instead of returning NULL (toString(), toInt32(), etc. already do
Are there currently any plans for simplifying the situation regarding build
systems? I haven't seen any threads for a while, which I assume means no.
Is there any low hanging fruit out there? Since many of the build systems
are little more than lists of files, it really seems like we should be
In addition, has anyone ever looked at simplifying the mac port's xcode
project? It's _by far_ the heaviest burden on the project given that you
pretty much need to use xcode (which is mac only...no other port requires
this), exported linker symbols are in a separate file, extra effort to
On Aug 9, 2010, at 3:48 PM, ext Pavel Feldman wrote:
Hi guys,
As some of you know, we are working on a remote debugging feature in Web
Inspector. There are many good reasons behind the project including the
following:
- Debugging WebKit on embedded devices
- Shaping up a good protocol for
On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc d...@chromium.org wrote:
i completely agree with jeremy. is it possible to at least drop the cryptic
hashcodes/timestamps? without them, the .xcodeproj files should at least be
editable by hand.
Doesn't gyp already generate Xcode projects for
That should work too.
mo
On Thu, Aug 12, 2010 at 3:24 AM, Dumitru Daniliuc d...@chromium.org wrote:
so i think we just need to change toJS/toV8...
sorry, i meant toClass(), not toJS/toV8.
dumi
On Wed, Aug 11, 2010 at 11:10 PM, Mo, Zhenyao zhen...@gmail.com wrote:
Actually it's a
On Thu, Aug 12, 2010 at 7:18 AM, David Kilzer ddkil...@webkit.org wrote:
On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc d...@chromium.org wrote:
i completely agree with jeremy. is it possible to at least drop the
cryptic hashcodes/timestamps? without them, the .xcodeproj files should at
Let me re-iterate (because even some co-workers are getting confused): I'm
not secretly trying to get the mac port to start using GYP. (Or saying it's
a bad idea either, mind you.) I'm just concerned that the process
associated with adding a file (or adding a dependency between projects on
the
Hi Jeremy,
On Aug 12, 2010, at 7:37 AM, Jeremy Orlow wrote:
On Thu, Aug 12, 2010 at 7:18 AM, David Kilzer ddkil...@webkit.org wrote:
On Aug 12, 2010, at 3:54 AM, Dumitru Daniliuc d...@chromium.org wrote:
i completely agree with jeremy. is it possible to at least drop the cryptic
On Wed, Aug 11, 2010 at 10:58 PM, Darin Fisher da...@chromium.org wrote:
On Wed, Aug 11, 2010 at 10:37 PM, Sam Weinig sam.wei...@gmail.com wrote:
On Wed, Aug 11, 2010 at 10:29 PM, Cedric Vivier cedr...@neonux.comwrote:
On Thu, Aug 12, 2010 at 13:26, Sam Weinig sam.wei...@gmail.com wrote:
Eric and I discussed this recently. We think the easiest path forward
is to try to remove build systems incrementally. Each build system we
remove makes it easier to hack on the project because you have one
less build system to worry about. The easiest build system to remove
is probably the
An added benefit of removing the VS build system first would be that we'd be
able to build using VS2005 or VS2008.
On Thu, Aug 12, 2010 at 10:36 AM, Adam Barth aba...@webkit.org wrote:
Eric and I discussed this recently. We think the easiest path forward
is to try to remove build systems
Hardly. Right now we already do the type checking in the generated
toType(argument) functions. Instead of casting to null, we throw a
TypeError, which adds no extra cost if the type is correct.
Besides, where I looked, after toType(argument) call, exception is
checked. Only that currently
For what it's worth, I think this change should be made for all of the
DOM bindings, not just those for WebGL. The IDL code generators'
support for overloaded methods already generates TypeError when an
incoming argument doesn't implement any of the interfaces required by
the overloaded variants.
As I mentioned, I am not necessarily against ever changing the behavior, but
if we do, we should make sure to remove all the existing checks, as they
become an unnecessary branch. It just seems to me like that should be a
separate change than a bug due to ambiguity.
-Sam
On Thu, Aug 12, 2010 at
I was wondering if it would be a reasonable change to make accessing
location.href (and other location properties) throw SECURITY_ERR when
accessed across origins (https://webkit.org/b/43504). This initially was
reported on the Chrome side (http://crbug.com/17325), but it looks like
neither the
Matching IE and FF means we shouldn't suffer too much in terms of
incompatibilities. Of course, there could be some WebKit specific content
out there that would break.
This seems like a worthwhile change to try out.
-Darin
On Thu, Aug 12, 2010 at 8:08 PM, Mihai Parparita
19 matches
Mail list logo
