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.
> 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'
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 p
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
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,
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
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 comman
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
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
trea
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 S
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 paramete
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 "
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
don
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
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 archiv
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 [Optio
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 f
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
> interna
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-
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, an
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
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
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 ex
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 other
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/RenderBlockLineLa
25 matches
Mail list logo
