Re: [webkit-dev] Platform LayoutTests are out of control

[Brent Fulgham]

Sent from my iPhone

On Apr 20, 2011, at 10:41 PM, Andy Estes  wrote:

> In the case of updating, isn't it more interesting to look at which ports 
> update expectations more often?

You are right. That's the better question.

> Presumably you paid the cost of the initial checkout some time ago.
>> 

One would hope so. I find that if I let my home machine go for a few days 
without updating, it can take nearly an hour to update.

I think it's just been especially bad the last few days.___
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

[Brent Fulgham]

> 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?  :)

Oh sure, Peter -- ruin my nice rant with the opportunity to DO something about 
it!

I guess I've made my bed.  I'll ping you off list for details or ideas.

Thanks,

-Brent

Sent from my iPhone
___
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

[Cameron McCormack]

Jian Li:
> > 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.

Ryosuke Niwa:
> Doesn't that mean the current behavior (i.e. treating undefined as 0) is
> correct since that's what other browsers do?

The File API spec currently says:

  Blob slice(in optional long long start,
 in optional long long end,
 in optional DOMString contentType);

and Web IDL says that if you call

  blob.slice(10, undefined);

then this is calling the function with two arguments, where the second
argument will be converted to 0 due to how the conversion of JS
undefined to an IDL long long value is defined.  This is not the same as
calling

  blob.slice(10);

Whenever some optional arguments are omitted, the prose for the
definition of the operation defines what that means; it’s not
automatically “convert from undefined”.

There is no way in Web IDL to state that when undefined is passed as an
argument explicitly that it is handled differently from the rules in
http://dev.w3.org/2006/webapi/WebIDL/#es-type-mapping (although the
authors of the File API spec could include this additional requirement
in prose, overriding Web IDL, if they wanted).

-- 
Cameron McCormack ≝ http://mcc.id.au/
___
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

[Maciej Stachowiak]

This probably won't be a huge improvement given your numbers, but 
platform/mac-tiger could be deleted at this point.

Regards,
Maciej

On Apr 20, 2011, at 9:33 PM, Brent Fulgham 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

[Peter Kasting]

On Wed, Apr 20, 2011 at 10:46 PM, Ryosuke Niwa wrote:

> On Wed, Apr 20, 2011 at 10:41 PM, Peter Kasting wrote:
>>
>> * 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

Re: [webkit-dev] Platform LayoutTests are out of control

[Ryosuke Niwa]

On Wed, Apr 20, 2011 at 10:41 PM, Peter Kasting  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

[Peter Kasting]

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

[Andy Estes]

Sent from my iPhone

On Apr 20, 2011, at 21:33, Brent Fulgham  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] Optional parameter in IDL and undefined JS value

[Anton Muhin]

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  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  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.
>>          PassRefPtr bar(long long start = 0, long long end =
>> std::numeric_limits::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_cast(asObject(thisValue));
>>     Foo* imp = static_cast(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_cast> 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_cast> 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] Optional parameter in IDL and undefined JS value

[Jian Li]

On Wed, Apr 20, 2011 at 9:58 PM, Ryosuke Niwa  wrote:

> On Wed, Apr 20, 2011 at 9:37 PM, Jian Li  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

[Ryosuke Niwa]

On Wed, Apr 20, 2011 at 9:37 PM, Jian Li  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"?

- 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

[Ryosuke Niwa]

On Wed, Apr 20, 2011 at 9:33 PM, Brent Fulgham  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] Platform LayoutTests are out of control

[Dirk Pranke]

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  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] Optional parameter in IDL and undefined JS value

[Jian Li]

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  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.
>  PassRefPtr bar(long long start = 0, long long end =
> std::numeric_limits::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_cast(asObject(thisValue));
> Foo* imp = static_cast(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_cast 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_cast 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] Platform LayoutTests are out of control

[Brent Fulgham]

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

Re: [webkit-dev] Optional parameter in IDL and undefined JS value

[Maciej Stachowiak]

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.
>  PassRefPtr bar(long long start = 0, long long end = 
> std::numeric_limits::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_cast(asObject(thisValue));
> Foo* imp = static_cast(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_cast 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_cast(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] Optional parameter in IDL and undefined JS value

[Jian Li]

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.
 PassRefPtr bar(long long start = 0, long long end =
std::numeric_limits::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_cast(asObject(thisValue));
Foo* imp = static_cast(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_cast(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_cast(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] WebKit unit test framework

[David Levin]

On Wed, Apr 20, 2011 at 4:59 PM, Darin Fisher  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  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

Re: [webkit-dev] WebKit unit test framework

[David Levin]

On Wed, Apr 20, 2011 at 4:01 PM, Sam Weinig  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

[Darin Fisher]

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  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 
> mentionedon
>  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

[Sam Weinig]

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

[David Levin]

On Wed, Apr 20, 2011 at 3:00 PM, Timothy Hatcher  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 
> mentionedon
>  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

[Timothy Hatcher]

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

[Adam Barth]

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  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  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 Text Rendering

[Eric Seidel]

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  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 * wrote:
>
>
> From: Eric Seidel 
> 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 > 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 
>
> ___
> 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