That would still be a bug, and still new to me :)
-- Dirk
On Mon, Oct 29, 2012 at 4:04 PM, Dana Jansens wrote:
> On Mon, Oct 29, 2012 at 6:59 PM, Dirk Pranke wrote:
>> If that's the case, it's a bug, and new to me.
>
> The output was present on the results page, but it would only include
> the
On Mon, Oct 29, 2012 at 6:59 PM, Dirk Pranke wrote:
> If that's the case, it's a bug, and new to me.
The output was present on the results page, but it would only include
the first, maybe, 60 lines or so.
- Dana
>
> -- Dirk
>
> On Mon, Oct 29, 2012 at 3:42 PM, Terry Anderson
> wrote:
>> I was
Thanks a lot for your work :) This is a huge improvement to our perf. test
infrastructure.
On Mon, Oct 29, 2012 at 3:01 PM, Zoltan Horvath wrote:
> Hi there,
>
> In the past few weeks I made some refactoring work on the PageLoad tests
> of the PerformanceTests, so now for your information, what
If that's the case, it's a bug, and new to me.
-- Dirk
On Mon, Oct 29, 2012 at 3:42 PM, Terry Anderson wrote:
> I was actually noticing that some of the stderr output was missing from a
> failing test, not a passing one.
>
> Terry
>
>
> On Sun, Oct 28, 2012 at 8:42 PM, Dirk Pranke wrote:
>>
>>
I was actually noticing that some of the stderr output was missing from a
failing test, not a passing one.
Terry
On Sun, Oct 28, 2012 at 8:42 PM, Dirk Pranke wrote:
> As Balazs said, we don't save the stderr output from tests that pass.
> So, you don't have to crash, but your tests have to at l
Hi there,
In the past few weeks I made some refactoring work on the PageLoad tests of
the PerformanceTests, so now for your information, what were accessible
under PerformanceTests/PageLoad/* now accessible only under
PerformanceTests/SVG. We have now a platform independent solution for the
'PageL
On Sun, Oct 28, 2012 at 8:26 PM, Alexey Proskuryakov wrote:
> when you run the same set of tests over and over, you get the same
> behavior.
>
Not the way n-w-r-t does it; in particular the time each test takes to
finish affects which process it gets run in, which gets you flakiness.
Which is wh
On Mon, Oct 29, 2012 at 4:17 AM, Maciej Stachowiak wrote:
>
> On Oct 28, 2012, at 3:30 PM, Antti Koivisto wrote:
>
>> We could clear the cache between tests but run each test twice in a row.
>> Second run will then happen with deterministically pre-populated cache. That
>> would both make thing
On Mon, Oct 29, 2012 at 5:48 AM, Maciej Stachowiak wrote:
>
> On Oct 28, 2012, at 10:09 PM, Dirk Pranke wrote:
>
>>
>> On Sun, Oct 28, 2012 at 6:32 AM, Maciej Stachowiak wrote:
>>>
>>> I think the nature of loader and cache code is that it's very hard to make
>>> tests which always fail determi
Michael, Thanks for your reply, now I understand it. :~)
于 2012年10月29日 23:16, Michael Saboff 写道:
The output of "undefined" is normal. It is the result of the expression you entered. jsc is
basically returning the result of the expressions you enter. Both var and print themselves evaluate to
The output of "undefined" is normal. It is the result of the expression you
entered. jsc is basically returning the result of the expressions you enter.
Both var and print themselves evaluate to "undefined". If you try "x = 1;"
you'll get 1 as that expression returns 1.
Concerning testing
On Oct 29, 2012, at 3:47 PM, Antti Koivisto wrote:
> I don't think the original proposal was meant to apply to the basic container
> types. Would this be a sensible rule to adopt for WebCore only for example?
>
> Like all our "blanket rules", this one should be ignored when it doesn't make
>
I don't think the original proposal was meant to apply to the basic
container types. Would this be a sensible rule to adopt for WebCore only
for example?
Like all our "blanket rules", this one should be ignored when it doesn't
make sense. If that kind of cases are expected to be very rare then the
Hi All,
I'm trying to add stop functionality in my application which is using
webkit on WIN port.
currently Play and Pause functions are available but no STOP function
is present , so in JsHTMLMediaElement.cpp I have added a new function:
jsHTMLMediaElementPrototypeFunctionStop(ExecState* exec
On Oct 28, 2012, at 10:09 PM, Dirk Pranke wrote:
>
> On Sun, Oct 28, 2012 at 6:32 AM, Maciej Stachowiak wrote:
>>
>> I think the nature of loader and cache code is that it's very hard to make
>> tests which always fail deterministically when regressions are introduced,
>> as opposed to rand
On Oct 28, 2012, at 3:30 PM, Antti Koivisto wrote:
> We could clear the cache between tests but run each test twice in a row.
> Second run will then happen with deterministically pre-populated cache. That
> would both make things more predictable and improve our test coverage for
> cached cas
hi, all, I try to port the webkit to a new platform(the platform is
linux based run with glibc & glib, but not gtk), now I have build the
jsc project successfully, but when I run the jsc program, something
happend show as below:
qing@HAHA:/data/project/webOS/WebKit/Source/JavaScriptCore/JavaScript
On Sun, Oct 28, 2012 at 11:16 PM, Maciej Stachowiak wrote:
> On Oct 28, 2012, at 10:09 PM, Peter Kasting wrote:
>
> On Sun, Oct 28, 2012 at 6:12 AM, Maciej Stachowiak wrote:
>
>> I am not sure a blanket rule is correct. If the Foo* is logically related
>> to the object with the foo() method and
18 matches
Mail list logo
