Re: [webkit-dev] WebKit Text Rendering
Honestly, I don't know. At least not w/o reading findNextLineBreak. It's not a part of the code I've had to look into in great detail yet. You can ask on #webkit, but it's better if you just read the source yourself: http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderBlockLineLayout.cpp#L1676 -eric On Wed, Apr 20, 2011 at 11:13 AM, Soheil Servati Beiragh sserv...@yahoo.com wrote: Ok Eric but Can you also tell me in brief how it decides to go to the next line? Does the function uses glyph metrics to for example calculate the width of each character and the decides how many will reach the limit? Or there so kind of approximation? Also if it do use glyph metrics can you guide to the variable to pointer to where it gets its needed info? I'm going through the function but I'm at beginning of the road. *Soheil Servati Beiragh* *PhD Candidate, ECE Department, * *Research Center for Integrated Microsystems,* *University of Windsor.* Room 268 Essex Hall 401 Sunset Avenue Windsor, Ontario Canada, N9B 3P4 Phone: 519-253-3000 Ext 3396 Email: serv...@uwindsor.ca --- On *Tue, 19/4/11, Eric Seidel e...@webkit.org* wrote: From: Eric Seidel e...@webkit.org Subject: Re: [webkit-dev] WebKit Text Rendering To: sserv...@yahoo.com Cc: webkit-dev@lists.webkit.org Date: Tuesday, 19 April, 2011, 10:56 AM Line breaking is done in findNextLineBreak in RenderBlockLineLayout. There is a talk on Youtube from me which touches on some of this. The RenderTexts get broken into lines, then the bidi algorithm is run and then line boxes are created. The text contents of the line boxes are passed individually to the paint functions at paint time. -eric On Tue, Apr 19, 2011 at 7:48 AM, Soheil Servati Beiragh sserv...@yahoo.com http://mc/compose?to=sserv...@yahoo.com wrote: Hi I'm working on text rendering of WebKit. I tried to find my path through it and I was a bit successful but I'm wondering in a gtk build when there is a large paragraph of text to be shown on screen where does the length of each line decided? I know that to show text a drawText function in the Font.cpp is called but the issue is it gets a string for each line, my question is for a large paragraph where does the code cuts the text in lines and decides the length and prepare it for drawText function? Thanks *Soheil Servati Beiragh* *PhD Candidate, ECE Department, * *Research Center for Integrated Microsystems,* *University of Windsor.* Room 268 Essex Hall 401 Sunset Avenue Windsor, Ontario Canada, N9B 3P4 Phone: 519-253-3000 Ext 3396 Email: serv...@uwindsor.ca http://mc/compose?to=serv...@uwindsor.ca ___ webkit-dev mailing list webkit-dev@lists.webkit.orghttp://mc/compose?to=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] WebKit unit test framework
Looks like folks don't have a strong opinion about this topic. I'd recommend just picking something that works and giving it a try. I suspect many different frameworks would all work fine. Adam On Mon, Apr 18, 2011 at 11:48 AM, Dirk Pranke dpra...@chromium.org wrote: I'd add maintained to your list, but otherwise it looks pretty good :) It would also be nice if the testing framework supported parallel or distributed execution, but not many do. -- Dirk On Mon, Apr 18, 2011 at 11:36 AM, David Levin le...@chromium.org wrote: Issue: There has been a long standing bug to add unit tests to WebKit (https://bugs.webkit.org/show_bug.cgi?id=21010). It was also mentioned on webkit-dev that it would be helpful in various cases. Landscape: Surveying WebKit, it is looks like there are at least three testing frameworks being used: TestWebKitAPI/WebKitAPITest (in Tools), QTest, gtest (in Source/WebKit/chromium/). However, only one TestWebKitAPI has been used so far (as far as I can tell) for testing core WebKit items like WTF (though I was unaware of TestWebKitAPI until Friday). It seems like a good way to think about the issue of which to use in general in WebKit would be to decide on what would be desired in our framework and then see how each matches up. Here's my take on this. (It may be biased toward what I am familiar with but I welcome others to add their own criteria.) Criteria Musts: Compatible license with WebKit Builds/Can be built on the many platforms and build systems supported by WebKit (ideally without extra installs). Useful: Easy to write tests Hackable to suit our needs Well tested features (to support hackability/stability) Supports filtering of tests so you can run just the test you care about (and easily listing the tests). Supports writing out values when there is test failure. (For example, if the is verifying that A == B but that is not true, then the values of A and B should be printed.) Well documented thanks, dave ___ 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] WebKit unit test framework
I think having something the WebKit community owns and controls is preferred over importing and using a third-party library. So that makes me prefer TestWebKitAPI (or something built from/on it) over gtest. And TestWebKitAPI already has a very simple test for WTF::Vector — just begging to be expanded. On Apr 18, 2011, at 11:36 AM, David Levin wrote: Issue: There has been a long standing bug to add unit tests to WebKit (https://bugs.webkit.org/show_bug.cgi?id=21010). It was also mentioned on webkit-dev that it would be helpful in various cases. Landscape: Surveying WebKit, it is looks like there are at least three testing frameworks being used: TestWebKitAPI/WebKitAPITest (in Tools), QTest, gtest (in Source/WebKit/chromium/). However, only one TestWebKitAPI has been used so far (as far as I can tell) for testing core WebKit items like WTF (though I was unaware of TestWebKitAPI until Friday). It seems like a good way to think about the issue of which to use in general in WebKit would be to decide on what would be desired in our framework and then see how each matches up. Here's my take on this. (It may be biased toward what I am familiar with but I welcome others to add their own criteria.) Criteria Musts: Compatible license with WebKit Builds/Can be built on the many platforms and build systems supported by WebKit (ideally without extra installs). Useful: Easy to write tests Hackable to suit our needs Well tested features (to support hackability/stability) Supports filtering of tests so you can run just the test you care about (and easily listing the tests). Supports writing out values when there is test failure. (For example, if the is verifying that A == B but that is not true, then the values of A and B should be printed.) Well documented thanks, dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit unit test framework
On Wed, Apr 20, 2011 at 3:00 PM, Timothy Hatcher timo...@apple.com wrote: I think having something the WebKit community owns and controls is preferred over importing and using a third-party library. So that makes me prefer TestWebKitAPI (or something built from/on it) over gtest. And TestWebKitAPI already has a very simple test for WTF::Vector — just begging to be expanded. I agree that this sounds attractive at first. However, it feels like there is a bigger picture. There is a lot of work already done in gtest which would be nice to have (-- some of which will likely be necessary). Here's a list right off the top of my head (from what I've seen of both): - TestWebKitAPI doesn't print out values when a test fails. (gtest has this support.) - I don't think there is any documentation for TestWebKitAPI (For, gtest there is http://code.google.com/p/googletest/wiki/Documentation). - I don't there are any test for the framework in TestWebKitAPI -- to be hackable in WebKit with confidence, this is needed. (gtest has extensive testing.) - TestWebKitAPI seems to only run one test at a time. When the ability is added to run all test, it would also be good to add the ability to run a set of test (gtest already has this). - In addition, gtest has a nice output (including a nice color output when supported by the terminal as well as output options which integrate better with automation -- see generating an xml report in http://code.google.com/p/googletest/wiki/AdvancedGuide). - The SetUp/TearDown functionality is a nice way isolate this type of stuff out of the way of tests. - In addition, the design of the api has gone through lots of discussion by concerned parties to work well. (This is more attention that we'd be able to expend on this.) Someone could add these items to TestWebKitAPI eventually and some of these items may never get done due to the cost/benefit ratio of doing them for something just used in WebKit project. In short, it seems to me that the effort to do any of this would be better invested in other places where there isn't already something that works for us. fwiw, we could go with what we do with bugzilla where we start with gtest and people change the code if needed. dave On Apr 18, 2011, at 11:36 AM, David Levin wrote: *Issue: *There has been a long standing bug to add unit tests to WebKit ( https://bugs.webkit.org/show_bug.cgi?id=21010). It was also mentionedhttp://lists.macosforge.org/pipermail/webkit-dev/2009-January/006359.htmlon webkit-dev that it would be helpful in various cases. *Landscape:* Surveying WebKit, it is looks like there are at least three testing frameworks being used: TestWebKitAPI/WebKitAPITest (in Tools), QTest, gtest (in Source/WebKit/chromium/). However, only one TestWebKitAPI has been used so far (as far as I can tell) for testing core WebKit items like WTF (though I was unaware of TestWebKitAPI until Friday). It seems like a good way to think about the issue of which to use in general in WebKit would be to decide on what would be desired in our framework and then see how each matches up. Here's my take on this. (It may be biased toward what I am familiar with but I welcome others to add their own criteria.) Criteria Musts: - Compatible license with WebKit - Builds/Can be built on the many platforms and build systems supported by WebKit (ideally without extra installs). Useful: - Easy to write tests - Hackable to suit our needs - Well tested features (to support hackability/stability) - Supports filtering of tests so you can run just the test you care about (and easily listing the tests). - Supports writing out values when there is test failure. (For example, if the is verifying that A == B but that is not true, then the values of A and B should be printed.) - Well documented thanks, dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev — Timothy Hatcher ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit unit test framework
I am really not an expert on testing frameworks, and just put together something that met my needs (as has been the tradition in this project). That said, the only features I like about TestWebKitAPI is that I know how it works and can hack it to do what I want, and that it has the ability to run each test in its own invocation (I also like the color output from the tests, because it's is in color!) So, my questions for people who have used gtest is, Is it hackable? What kind of changes have you had success making? Is a death test as scary as it sounds? -Sam On Apr 18, 2011, at 11:36 AM, David Levin wrote: Issue: There has been a long standing bug to add unit tests to WebKit (https://bugs.webkit.org/show_bug.cgi?id=21010). It was also mentioned on webkit-dev that it would be helpful in various cases. Landscape: Surveying WebKit, it is looks like there are at least three testing frameworks being used: TestWebKitAPI/WebKitAPITest (in Tools), QTest, gtest (in Source/WebKit/chromium/). However, only one TestWebKitAPI has been used so far (as far as I can tell) for testing core WebKit items like WTF (though I was unaware of TestWebKitAPI until Friday). It seems like a good way to think about the issue of which to use in general in WebKit would be to decide on what would be desired in our framework and then see how each matches up. Here's my take on this. (It may be biased toward what I am familiar with but I welcome others to add their own criteria.) Criteria Musts: Compatible license with WebKit Builds/Can be built on the many platforms and build systems supported by WebKit (ideally without extra installs). Useful: Easy to write tests Hackable to suit our needs Well tested features (to support hackability/stability) Supports filtering of tests so you can run just the test you care about (and easily listing the tests). Supports writing out values when there is test failure. (For example, if the is verifying that A == B but that is not true, then the values of A and B should be printed.) Well documented thanks, dave ___ 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] WebKit unit test framework
I believe both maruel and jcivelli have had experience contributing changes to gtest. While I wouldn't characterize its code as simple, I haven't had trouble understanding it. It is a fairly mature project, having been used internally at Google for ages. It seems to be fairly well maintained, and the code is clean to my eyes. Chances are good that it already has solutions for much of what you may wish of a unit testing framework. By the way, I was originally not in favor of using gtest for Chromium. It seemed too complicated at first blush. I had created a very simple testing framework that I liked for all the reasons you state below. That was ~5 years ago. However, I quickly became more than convinced that it was worth it to use an established tool for unit testing. It has so many nice features--features I didn't even know I would appreciate. It was also really easy to use. -Darin On Wed, Apr 20, 2011 at 4:01 PM, Sam Weinig wei...@apple.com wrote: I am really not an expert on testing frameworks, and just put together something that met my needs (as has been the tradition in this project). That said, the only features I like about TestWebKitAPI is that I know how it works and can hack it to do what I want, and that it has the ability to run each test in its own invocation (I also like the color output from the tests, because it's is in color!) So, my questions for people who have used gtest is, Is it hackable? What kind of changes have you had success making? Is a death test as scary as it sounds? -Sam On Apr 18, 2011, at 11:36 AM, David Levin wrote: *Issue: *There has been a long standing bug to add unit tests to WebKit ( https://bugs.webkit.org/show_bug.cgi?id=21010). It was also mentionedhttp://lists.macosforge.org/pipermail/webkit-dev/2009-January/006359.htmlon webkit-dev that it would be helpful in various cases. *Landscape:* Surveying WebKit, it is looks like there are at least three testing frameworks being used: TestWebKitAPI/WebKitAPITest (in Tools), QTest, gtest (in Source/WebKit/chromium/). However, only one TestWebKitAPI has been used so far (as far as I can tell) for testing core WebKit items like WTF (though I was unaware of TestWebKitAPI until Friday). It seems like a good way to think about the issue of which to use in general in WebKit would be to decide on what would be desired in our framework and then see how each matches up. Here's my take on this. (It may be biased toward what I am familiar with but I welcome others to add their own criteria.) Criteria Musts: - Compatible license with WebKit - Builds/Can be built on the many platforms and build systems supported by WebKit (ideally without extra installs). Useful: - Easy to write tests - Hackable to suit our needs - Well tested features (to support hackability/stability) - Supports filtering of tests so you can run just the test you care about (and easily listing the tests). - Supports writing out values when there is test failure. (For example, if the is verifying that A == B but that is not true, then the values of A and B should be printed.) - Well documented thanks, dave ___ 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] WebKit unit test framework
On Wed, Apr 20, 2011 at 4:01 PM, Sam Weinig wei...@apple.com wrote: Is a death test as scary as it sounds? :) Useful if you want to verify that the program crashes. fwiw, chromium uses this to verify that asserts fire in debug in particular scenarios. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebKit unit test framework
On Wed, Apr 20, 2011 at 4:59 PM, Darin Fisher da...@chromium.org wrote: I believe both maruel and jcivelli have had experience contributing changes to gtest. While I wouldn't characterize its code as simple, I haven't had trouble understanding it. It is a fairly mature project, having been used internally at Google for ages. It seems to be fairly well maintained, and the code is clean to my eyes. Chances are good that it already has solutions for much of what you may wish of a unit testing framework. By the way, I was originally not in favor of using gtest for Chromium. It seemed too complicated at first blush. I had created a very simple testing framework that I liked for all the reasons you state below. That was ~5 years ago. However, I quickly became more than convinced that it was worth it to use an established tool for unit testing. It has so many nice features--features I didn't even know I would appreciate. It was also really easy to use. -Darin On Wed, Apr 20, 2011 at 4:01 PM, Sam Weinig wei...@apple.com wrote: So, my questions for people who have used gtest is, Is it hackable? What kind of changes have you had success making? Darin's email said it so well that I hate to follow up with this, but in the interest of full disclosure, I'll include this info even though it may make folks feel less comfortable. (Before Darin's email) I talked to two people from chromium land who did changes to it. I believe those changes were to add support for FLAKY_ and FAILS_. Here's what those two people had to say to me about hacking gtest: Person 1: The codebase was somewhat hackable. The people maintaining it were not welcoming though. Most of the patches I tried to send ended up being R- because it was not important for them. However, they ended up writing a plugin API for it, and with that API it is a lot easier to make the needed improvement to gtest without having to do gtest changes. Person 2: gtest makes heavy use of templates and has many levels of indirection both of which made the code more difficult to deal with. Using it is fine. Hacking on it is definitely harder. In short, if we really need to make changes in gtest itself, it sounds pretty possible to do them. Getting them upstreamed may be harder, but we could always fork if needed. dave ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Optional parameter in IDL and undefined JS value
Hi,
I've just found a problem in our generated code for handling optional
parameters. Suppose we define a method with optional parameter in numeric
type, like the following in IDL:
Foo bar(in [Optional] long long start, in [Optional] long long
end);
And we declare our C++ method as the following. Note that the default value
of the 2nd parameter is not 0.
PassRefPtrFoo bar(long long start = 0, long long end =
std::numeric_limitslong long::max());
If we call the JS method with only 1 parameter, everything works as
expected. However, if we call the JS method with 2 parameters and pass
'undefined' as the 2nd parameter, we trigger the problem.
By looking into the generated JSC code below, I found out that we are
converting undefined JS value to 0 and pass it to the function. As the
result, the default parameter value in the declaration is not respected.
EncodedJSValue JSC_HOST_CALL jsFooPrototypeFunctionFoo(ExecState* exec)
{
JSValue thisValue = exec-hostThisValue();
if (!thisValue.inherits(JSFoo::s_info))
return throwVMTypeError(exec);
JSFoo* castedThis = static_castJSFoo*(asObject(thisValue));
Foo* imp = static_castFoo*(castedThis-impl());
int argsCount = exec-argumentCount();
if (argsCount = 0) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar()));
return JSValue::encode(result);
}
long long start(static_castlong
long(exec-argument(0).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
if (argsCount = 1) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start)));
return JSValue::encode(result);
}
long long end(static_castlong
long(exec-argument(1).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start, end)));
return JSValue::encode(result);
}
One solution is to add the default value support in IDL. For example, we can
change the above definition of bar to something like:
Foo bar(in [Optional, DefaultValue=0] long long start, in
[Optional, DefaultValue=2147483647] long long end);
Or the other way is to add a bool parameter for each optional parameter in
the class method declaration, that is used to indicate if the passing
parameter is defined or not. This would involve the change to both code
generator scripts and the existing implementations.
How do you think? Personally I like the 1st approach since it is simpler.
Thanks,
Jian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
On Apr 20, 2011, at 6:16 PM, Jian Li wrote:
Hi,
I've just found a problem in our generated code for handling optional
parameters. Suppose we define a method with optional parameter in numeric
type, like the following in IDL:
Foo bar(in [Optional] long long start, in [Optional] long long end);
And we declare our C++ method as the following. Note that the default value
of the 2nd parameter is not 0.
PassRefPtrFoo bar(long long start = 0, long long end =
std::numeric_limitslong long::max());
If we call the JS method with only 1 parameter, everything works as expected.
However, if we call the JS method with 2 parameters and pass 'undefined' as
the 2nd parameter, we trigger the problem.
Is it actually a bug that explicitly passing undefined acts like passing 0,
instead of like an omitted parameter? I think it's correct per Web IDL. What's
the specific case where this is a problem?
Regards,
Maciej
By looking into the generated JSC code below, I found out that we are
converting undefined JS value to 0 and pass it to the function. As the
result, the default parameter value in the declaration is not respected.
EncodedJSValue JSC_HOST_CALL jsFooPrototypeFunctionFoo(ExecState* exec)
{
JSValue thisValue = exec-hostThisValue();
if (!thisValue.inherits(JSFoo::s_info))
return throwVMTypeError(exec);
JSFoo* castedThis = static_castJSFoo*(asObject(thisValue));
Foo* imp = static_castFoo*(castedThis-impl());
int argsCount = exec-argumentCount();
if (argsCount = 0) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar()));
return JSValue::encode(result);
}
long long start(static_castlong
long(exec-argument(0).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
if (argsCount = 1) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start)));
return JSValue::encode(result);
}
long long end(static_castlong long(exec-argument(1).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start, end)));
return JSValue::encode(result);
}
One solution is to add the default value support in IDL. For example, we can
change the above definition of bar to something like:
Foo bar(in [Optional, DefaultValue=0] long long start, in [Optional,
DefaultValue=2147483647] long long end);
Or the other way is to add a bool parameter for each optional parameter in
the class method declaration, that is used to indicate if the passing
parameter is defined or not. This would involve the change to both code
generator scripts and the existing implementations.
How do you think? Personally I like the 1st approach since it is simpler.
Thanks,
Jian
___
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] Optional parameter in IDL and undefined JS value
I am referring to Blob.slice(start, end) that mimics Array.slice. Where in
WebIDL has this behavior defined? Sorry I can't find it in the spec.
For Array.slice(start, end), both Safari and Chrome treat passing undefined
as omitted parameter, while Firefox and IE treat passing undefined as 0. If
it is true that passing undefined should be treated as 0, we do not have a
bug in JSC and V8 bindings layer. However, we do have a bug in JSC and V8
internals.
On Wed, Apr 20, 2011 at 7:28 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 20, 2011, at 6:16 PM, Jian Li wrote:
Hi,
I've just found a problem in our generated code for handling optional
parameters. Suppose we define a method with optional parameter in numeric
type, like the following in IDL:
Foo bar(in [Optional] long long start, in [Optional] long long
end);
And we declare our C++ method as the following. Note that the default value
of the 2nd parameter is not 0.
PassRefPtrFoo bar(long long start = 0, long long end =
std::numeric_limitslong long::max());
If we call the JS method with only 1 parameter, everything works as
expected. However, if we call the JS method with 2 parameters and pass
'undefined' as the 2nd parameter, we trigger the problem.
Is it actually a bug that explicitly passing undefined acts like passing 0,
instead of like an omitted parameter? I think it's correct per Web IDL.
What's the specific case where this is a problem?
Regards,
Maciej
By looking into the generated JSC code below, I found out that we are
converting undefined JS value to 0 and pass it to the function. As the
result, the default parameter value in the declaration is not respected.
EncodedJSValue JSC_HOST_CALL jsFooPrototypeFunctionFoo(ExecState* exec)
{
JSValue thisValue = exec-hostThisValue();
if (!thisValue.inherits(JSFoo::s_info))
return throwVMTypeError(exec);
JSFoo* castedThis = static_castJSFoo*(asObject(thisValue));
Foo* imp = static_castFoo*(castedThis-impl());
int argsCount = exec-argumentCount();
if (argsCount = 0) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar()));
return JSValue::encode(result);
}
long long start(static_castlong
long(exec-argument(0).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
if (argsCount = 1) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start)));
return JSValue::encode(result);
}
long long end(static_castlong
long(exec-argument(1).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start, end)));
return JSValue::encode(result);
}
One solution is to add the default value support in IDL. For example, we
can change the above definition of bar to something like:
Foo bar(in [Optional, DefaultValue=0] long long start, in
[Optional, DefaultValue=2147483647] long long end);
Or the other way is to add a bool parameter for each optional parameter in
the class method declaration, that is used to indicate if the passing
parameter is defined or not. This would involve the change to both code
generator scripts and the existing implementations.
How do you think? Personally I like the 1st approach since it is simpler.
Thanks,
Jian
___
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] Platform LayoutTests are out of control
Hi Brent, I think we should consider sharding the PNG's out into different archives. I think another option would be to make a concerted effort to convert some of these tests into reftests. It would be interesting for someone to sample some of platform-specific tests and see how many could be done as reftests (or some other sort of programmatic test) instead of simply comparing pixels. Perhaps there are other options as well? -- Dirk On Wed, Apr 20, 2011 at 9:33 PM, Brent Fulgham bfulg...@gmail.com wrote: As I sat tonight, waiting for my local repository to update (~1 hour and counting at this point), I had a bit of free time to contemplate the ever-growing size of the platform results of the layout test archive. Over the last couple of years, the amount of time spent waiting for my local archive to sync with the main repository has grown considerably. And no wonder, we have a great number of new ports and variants using WebKit, all with their own quirks and unique results. It's wonderful diversity, and a great metric of how vibrant and enthusiastic a community we have. But to be honest, I'm TIRED of the huge update times! My initial knee-jerk reaction was to blame this on the multitude of Chromium layout archives (16 at last count). Clearly this is needless bloat -- after all, what could possibly be the difference between chromium-linux-x86_64 and google-chrome-linux64. Why are these even distinct entities? ;-) But my initial bias was not fact-based. While there are a great number of directories, they only weight in at 784 MB of data. The bulk of the results is due to Apple's various ports (although limited to a relatively parsimonious 8 directories); they total a bit over 1 GB of data. Gtk at Qt are downright tiny, at 366 MB and 229 MB (respectively). All told we have over 2 GB of data that has to be downloaded to each developer's machine before they get the first line of compilable code. Very few of us ever use more than a handful of these different platform results. I have a crappy DSL connection, so it's slow. Since I don't have metered bandwidth, the amount of data doesn't matter that much from a price standpoint, but it's quite annoying from a wasted time standpoint. I also feel very bad for anyone trying to work on WebKit from behind a metered network connection. Is there any way we can tame this explosive growth? Could platform results be located in a separate archive, so that they don't have to be constantly synced across all platforms? Help! Thanks, -Brent === As of 4-20-2011 == android: 56 KB (12 files) android-v8: 56 KB (20 files) chromium: 7.25 MB (400 files) chromium-gpu: 504 KB (78 files) chromium-gpu-linux: 5.36 MB (313 files) chromium-gpu-mac: 5.68 MB (251 files) chromium-gpu-win: 6.98 MB (469 files) chromium-linux: 274 MB (12,139 files) chromium-linux-x86_64: 2.99 MB (155 files) chromium-mac: 83.2 MB (2,582 files) chromium-mac-leopard: 87.9 MB (2,391 files) chromium-win: 293 MB (17,739 files) chromium-win-vista: 1.19 MB (163 files) chromium-win-xp: 2.12 MB (265 files) google-chrome-linux32: 12.9 MB (523 files) google-chrome-linux64: 972 KB (56 files) TOTAL: 784 MB (37,556 files) gtk: 366 MB (17,396 files) mac: 604 MB (20,686 files) mac-leopard: 389 MB (10,169 files) mac-snowleopard: 592 KB (103 files) mac-tiger: 9.61 MB (311 files) mac-wk2: 480 KB (86 files) win: 15.9 MB (972 files) win-wk2: 432 KB (89 files) win-xp: 1.26 MB (111 files) TOTAL: 1.02 GB (32,527 files) qt: 229 MB (11,876 files) qt-linux: 24.0 KB (8 files) qt-mac: 16.0 KB (3 files) qt-win: 16.0 KB (3 flles) qt-wk2: 305 KB (3 files) TOTAL: 229 MB (11,893 files) ___ 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] Platform LayoutTests are out of control
On Wed, Apr 20, 2011 at 9:33 PM, Brent Fulgham bfulg...@gmail.com wrote: My initial knee-jerk reaction was to blame this on the multitude of Chromium layout archives (16 at last count). Clearly this is needless bloat -- after all, what could possibly be the difference between chromium-linux-x86_64 and google-chrome-linux64. Why are these even distinct entities? ;-) I don't know the difference between those two but one of the reasons chromium has many platforms is that we run pixel tests on our bots. Because pixel results may be different depending on how numbers are rounded, 32-bit and 64-bit will have slightly different results. It's worth nothing that Chromium port's bots caught quite few rendering regressions because certain things such as caret (a.k.a. insertion point) isn't recorded anywhere in render tree dumps and certain regressions such as actual painting can only be tested by pixel tests. But given that all other ports don't run pixel tests on bots, I'm not certain how useful they are. Of course, some people are running them manually on their machines but it's a debatable whether it's worth the latency for everyone to always have png/checksum files. Is there any way we can tame this explosive growth? Could platform results be located in a separate archive, so that they don't have to be constantly synced across all platforms? I'm not sure about the actual size but svn-up time might improve if we get rid of checksum files and embed them in png files as Tony proposed earlier this month. Also, there are many old tests that can be converted to dump-as-text and dump-as-markup tests and converting them will certainly eliminate needs for png/checksum files. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
On Wed, Apr 20, 2011 at 9:58 PM, Ryosuke Niwa rn...@webkit.org wrote: On Wed, Apr 20, 2011 at 9:37 PM, Jian Li jia...@chromium.org wrote: I am referring to Blob.slice(start, end) that mimics Array.slice. Where in WebIDL has this behavior defined? Sorry I can't find it in the spec. For Array.slice(start, end), both Safari and Chrome treat passing undefined as omitted parameter, while Firefox and IE treat passing undefined as 0. Doesn't that mean the current behavior (i.e. treating undefined as 0) is correct since that's what other browsers do? If it is true that passing undefined should be treated as 0, we do not have a bug in JSC and V8 bindings layer. However, we do have a bug in JSC and V8 internals. I don't get what you mean here. If there are no bugs in JSC/V8 bindings, then what are you trying to fix? I mean we need to fix Array.slice behavior in JSC and V8 since Array.slice is not defined in our IDL. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Optional parameter in IDL and undefined JS value
Just my two cents.
There is an elaborate specification how Array.prototype.slice should
treat undefined parameters, see ECMAScript 5, 15.4.4.10. Please, note
that the spec treats undefined start and end differently: start is
converted with ToInteger which turns undefined into 0, while end is
treated as len if it's undefined.
Alas, we don't have such an elaborate spec for DOM methods. I
personally find different behaviour of foo() vs. foo(undefined)
somewhat counterintuitive, but technically one can use
arguments.length to implement such a dispatch in pure JS, so IMHO it's
fine (cf. though with Array.slice which doesn't use arguments.length
and AFAIK no other functions in ECMAScript, at least not one for
arrays.)
yours,
anton.
On Wed, Apr 20, 2011 at 9:37 PM, Jian Li jia...@chromium.org wrote:
I am referring to Blob.slice(start, end) that mimics Array.slice. Where in
WebIDL has this behavior defined? Sorry I can't find it in the spec.
For Array.slice(start, end), both Safari and Chrome treat passing undefined
as omitted parameter, while Firefox and IE treat passing undefined as 0. If
it is true that passing undefined should be treated as 0, we do not have a
bug in JSC and V8 bindings layer. However, we do have a bug in JSC and V8
internals.
On Wed, Apr 20, 2011 at 7:28 PM, Maciej Stachowiak m...@apple.com wrote:
On Apr 20, 2011, at 6:16 PM, Jian Li wrote:
Hi,
I've just found a problem in our generated code for handling optional
parameters. Suppose we define a method with optional parameter in numeric
type, like the following in IDL:
Foo bar(in [Optional] long long start, in [Optional] long long
end);
And we declare our C++ method as the following. Note that the default
value of the 2nd parameter is not 0.
PassRefPtrFoo bar(long long start = 0, long long end =
std::numeric_limitslong long::max());
If we call the JS method with only 1 parameter, everything works as
expected. However, if we call the JS method with 2 parameters and pass
'undefined' as the 2nd parameter, we trigger the problem.
Is it actually a bug that explicitly passing undefined acts like passing
0, instead of like an omitted parameter? I think it's correct per Web IDL.
What's the specific case where this is a problem?
Regards,
Maciej
By looking into the generated JSC code below, I found out that we are
converting undefined JS value to 0 and pass it to the function. As the
result, the default parameter value in the declaration is not respected.
EncodedJSValue JSC_HOST_CALL jsFooPrototypeFunctionFoo(ExecState* exec)
{
JSValue thisValue = exec-hostThisValue();
if (!thisValue.inherits(JSFoo::s_info))
return throwVMTypeError(exec);
JSFoo* castedThis = static_castJSFoo*(asObject(thisValue));
Foo* imp = static_castFoo*(castedThis-impl());
int argsCount = exec-argumentCount();
if (argsCount = 0) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar()));
return JSValue::encode(result);
}
long long start(static_castlong
long(exec-argument(0).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
if (argsCount = 1) {
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start)));
return JSValue::encode(result);
}
long long end(static_castlong
long(exec-argument(1).toInteger(exec)));
if (exec-hadException())
return JSValue::encode(jsUndefined());
JSC::JSValue result = toJS(exec, castedThis-globalObject(),
WTF::getPtr(imp-bar(start, end)));
return JSValue::encode(result);
}
One solution is to add the default value support in IDL. For example, we
can change the above definition of bar to something like:
Foo bar(in [Optional, DefaultValue=0] long long start, in
[Optional, DefaultValue=2147483647] long long end);
Or the other way is to add a bool parameter for each optional parameter in
the class method declaration, that is used to indicate if the passing
parameter is defined or not. This would involve the change to both code
generator scripts and the existing implementations.
How do you think? Personally I like the 1st approach since it is simpler.
Thanks,
Jian
___
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] Platform LayoutTests are out of control
Sent from my iPhone On Apr 20, 2011, at 21:33, Brent Fulgham bfulg...@gmail.com wrote: As I sat tonight, waiting for my local repository to update (~1 hour and counting at this point), I had a bit of free time to contemplate the ever-growing size of the platform results of the layout test archive. Over the last couple of years, the amount of time spent waiting for my local archive to sync with the main repository has grown considerably. And no wonder, we have a great number of new ports and variants using WebKit, all with their own quirks and unique results. It's wonderful diversity, and a great metric of how vibrant and enthusiastic a community we have. But to be honest, I'm TIRED of the huge update times! My initial knee-jerk reaction was to blame this on the multitude of Chromium layout archives (16 at last count). Clearly this is needless bloat -- after all, what could possibly be the difference between chromium-linux-x86_64 and google-chrome-linux64. Why are these even distinct entities? ;-) But my initial bias was not fact-based. While there are a great number of directories, they only weight in at 784 MB of data. The bulk of the results is due to Apple's various ports (although limited to a relatively parsimonious 8 directories); they total a bit over 1 GB of data. In the case of updating, isn't it more interesting to look at which ports update expectations more often? Presumably you paid the cost of the initial checkout some time ago. -Andy Gtk at Qt are downright tiny, at 366 MB and 229 MB (respectively). All told we have over 2 GB of data that has to be downloaded to each developer's machine before they get the first line of compilable code. Very few of us ever use more than a handful of these different platform results. I have a crappy DSL connection, so it's slow. Since I don't have metered bandwidth, the amount of data doesn't matter that much from a price standpoint, but it's quite annoying from a wasted time standpoint. I also feel very bad for anyone trying to work on WebKit from behind a metered network connection. Is there any way we can tame this explosive growth? Could platform results be located in a separate archive, so that they don't have to be constantly synced across all platforms? Help! Thanks, -Brent === As of 4-20-2011 == android: 56 KB (12 files) android-v8: 56 KB (20 files) chromium: 7.25 MB (400 files) chromium-gpu: 504 KB (78 files) chromium-gpu-linux: 5.36 MB (313 files) chromium-gpu-mac: 5.68 MB (251 files) chromium-gpu-win: 6.98 MB (469 files) chromium-linux: 274 MB (12,139 files) chromium-linux-x86_64: 2.99 MB (155 files) chromium-mac: 83.2 MB (2,582 files) chromium-mac-leopard: 87.9 MB (2,391 files) chromium-win: 293 MB (17,739 files) chromium-win-vista: 1.19 MB (163 files) chromium-win-xp: 2.12 MB (265 files) google-chrome-linux32: 12.9 MB (523 files) google-chrome-linux64: 972 KB (56 files) TOTAL: 784 MB (37,556 files) gtk: 366 MB (17,396 files) mac: 604 MB (20,686 files) mac-leopard: 389 MB (10,169 files) mac-snowleopard: 592 KB (103 files) mac-tiger: 9.61 MB (311 files) mac-wk2: 480 KB (86 files) win: 15.9 MB (972 files) win-wk2: 432 KB (89 files) win-xp: 1.26 MB (111 files) TOTAL: 1.02 GB (32,527 files) qt: 229 MB (11,876 files) qt-linux: 24.0 KB (8 files) qt-mac: 16.0 KB (3 files) qt-win: 16.0 KB (3 flles) qt-wk2: 305 KB (3 files) TOTAL: 229 MB (11,893 files) ___ 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] Platform LayoutTests are out of control
Hi Brent, In a past thread, I noted that we could do a couple of things to reduce platform-specific results, and the overall size of layout test results. In order of increasing difficulty: * Convert pixel tests to dumpAsText tests when pixel output is unnecessary (merely requires adding a command to the test file) * Avoid printing text onscreen in pixel tests unless critical to the tests -- use comments in the code instead * Convert tests to reftests These got general support, but no one actively interested in going through our existing tests to see where they could be applied. Would you be interested in helping organize such an effort? :) PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Platform LayoutTests are out of control
On Wed, Apr 20, 2011 at 10:41 PM, Peter Kasting pkast...@google.com wrote: * Convert pixel tests to dumpAsText tests when pixel output is unnecessary (merely requires adding a command to the test file) I actively work on this effort for LayoutTests/editing. I don't necessarily spend all of my working hours converting tests but whenever I find tests that don't require pixel results, I convert them. * Convert tests to reftests I don't think we should do this until all ports start using new-run-webkit-tests on their bots. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Platform LayoutTests are out of control
On Wed, Apr 20, 2011 at 10:46 PM, Ryosuke Niwa ryosuke.n...@gmail.comwrote: On Wed, Apr 20, 2011 at 10:41 PM, Peter Kasting pkast...@google.comwrote: * Convert tests to reftests I don't think we should do this until all ports start using new-run-webkit-tests on their bots. It's the most labor-intensive choice anyway, so the lowest-hanging fruit is in the other two changes for sure. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
