Re: [webkit-dev] On returning mutable pointers from const methods

2012-10-28 Thread Maciej Stachowiak
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 effectively would give access to mutable > internal state, then

Re: [webkit-dev] On returning mutable pointers from const methods

2012-10-28 Thread Peter Kasting
On Sun, Oct 28, 2012 at 3:12 PM, Filip Pizlo wrote: > The point is that a rule mandating const methods to return const pointers > prevents me from saying that getting a pointer from a container doesn't > change the container. > Um, yes, that's exactly the point. My argument was that it's very r

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

2012-10-28 Thread Alexey Proskuryakov
28.10.2012, в 12:25, Ami Fischman написал(а): > > To make concrete the cost/benefit tradeoff, would you add a random sleep() > into DRT execution to detect timing-related bugs? > It seems like a crazy thing to do, to me, but it would certainly catch > timing-related bugs quite effectively. >

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

2012-10-28 Thread Ryosuke Niwa
On Sun, Oct 28, 2012 at 4:37 PM, Dirk Pranke wrote: > On Sun, Oct 28, 2012 at 2:47 PM, Ryosuke Niwa wrote: > > On Sun, Oct 28, 2012 at 2:09 PM, Dirk Pranke > wrote: > >> > >> > On Oct 26, 2012, at 11:11 PM, Ryosuke Niwa wrote: > >> >> I’m sure Antti, Alexey, and others who have worked on the l

Re: [webkit-dev] Some stderr output missing when using run-webkit-tests

2012-10-28 Thread Dirk Pranke
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 least fail. It wouldn't be hard to change that somehow ... -- Dirk On Sun, Oct 28, 2012 at 4:29 PM, Terry Anderson wrote: > Hi webkit-dev, > > When I include fprintf(stder

Re: [webkit-dev] Some stderr output missing when using run-webkit-tests

2012-10-28 Thread Balazs Kelemen
On 10/29/2012 12:29 AM, Terry Anderson wrote: Hi webkit-dev, When I include fprintf(stderr, ...) statements in WebKit code that I expect to be executed when running a set of layout tests, the summary page of run-webkit-tests will sometimes only show a subset of these statements. However, when

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

2012-10-28 Thread Dirk Pranke
On Sun, Oct 28, 2012 at 2:47 PM, Ryosuke Niwa wrote: > On Sun, Oct 28, 2012 at 2:09 PM, Dirk Pranke wrote: >> >> > On Oct 26, 2012, at 11:11 PM, Ryosuke Niwa wrote: >> >> I’m sure Antti, Alexey, and others who have worked on the loader and >> >> other parts of WebKit are happy to write those tes

[webkit-dev] Some stderr output missing when using run-webkit-tests

2012-10-28 Thread Terry Anderson
Hi webkit-dev, When I include fprintf(stderr, ...) statements in WebKit code that I expect to be executed when running a set of layout tests, the summary page of run-webkit-tests will sometimes only show a subset of these statements. However, when I add a CRASH() somewhere in the code, the "missin

Re: [webkit-dev] On returning mutable pointers from const methods

2012-10-28 Thread Filip Pizlo
The point is that a rule mandating const methods to return const pointers prevents me from saying that getting a pointer from a container doesn't change the container. Hence with any such rule in place you risk there being fewer uses of const. -Filip Dnia 28 paź 2012 o godz. 14:40 Peter Kasti

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

2012-10-28 Thread Ryosuke Niwa
On Sun, Oct 28, 2012 at 2:09 PM, Dirk Pranke wrote: > > On Oct 26, 2012, at 11:11 PM, Ryosuke Niwa wrote: > >> I’m sure Antti, Alexey, and others who have worked on the loader and > other parts of WebKit are happy to write those tests or list the kind of > things they want to test. Heck, I don’t

Re: [webkit-dev] On returning mutable pointers from const methods

2012-10-28 Thread Peter Kasting
On Sun, Oct 28, 2012 at 2:29 PM, Filip Pizlo wrote: > It is useful to say that "getting a pointer to T from an object of type S > does not change S's state". > That's pretty much the definition of physical constness. PK ___ webkit-dev mailing list web

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

2012-10-28 Thread Balazs Kelemen
On 10/28/2012 08:25 PM, Ami Fischman wrote: We can live in one of two worlds: 1) LayoutTests that concern themselves with specific network/loading concerns need to use unique URLs to refer to static data; or 2) DRT clears JS-visible state between tests. The pros/cons see

Re: [webkit-dev] On returning mutable pointers from const methods

2012-10-28 Thread Filip Pizlo
It is useful to say that "getting a pointer to T from an object of type S does not change S's state". -F On Oct 28, 2012, at 2: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

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

2012-10-28 Thread Dirk Pranke
> On Oct 26, 2012, at 11:11 PM, Ryosuke Niwa wrote: >> I’m sure Antti, Alexey, and others who have worked on the loader and other >> parts of WebKit are happy to write those tests or list the kind of things >> they want to test. Heck, I don’t mind writing those tests if someone could >> make a

Re: [webkit-dev] On returning mutable pointers from const methods

2012-10-28 Thread Peter Kasting
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 effectively would give access to > mutable internal state, then what you say is definitely correct. But if the > const ob

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

2012-10-28 Thread Ami Fischman
> > We can live in one of two worlds: > 1) LayoutTests that concern themselves with specific network/loading > concerns need to use unique URLs to refer to static data; or > 2) DRT clears JS-visible state between tests. > The pros/cons seem clear to me: > Pro#1: loading/caching code is coincidental

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

2012-10-28 Thread Antti Koivisto
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 cases. Unfortunately it would also slow down testing significantly,

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

2012-10-28 Thread Maciej Stachowiak
On Oct 26, 2012, at 11:11 PM, Ryosuke Niwa wrote: > > I’m sure Antti, Alexey, and others who have worked on the loader and other > parts of WebKit are happy to write those tests or list the kind of things > they want to test. Heck, I don’t mind writing those tests if someone could > make a l

Re: [webkit-dev] On returning mutable pointers from const methods

2012-10-28 Thread Maciej Stachowiak
On Oct 26, 2012, at 7:21 PM, Rik Cabanier wrote: > > > On Fri, Oct 26, 2012 at 9:06 AM, Peter Kasting wrote: > On Fri, Oct 26, 2012 at 8:27 AM, Rik Cabanier wrote: > It is valid for a const method to return you a new object ie a const factory > object. > In that case, const-ness would not

Re: [webkit-dev] On returning mutable pointers from const methods

2012-10-28 Thread Maciej Stachowiak
On Oct 25, 2012, at 12:48 PM, Andreas Kling wrote: > > So, I propose that we allow only these two signature formats for raw pointers: > > - const Foo* foo() const; > - Foo* foo(); > > Moreover, for methods that return references to objects where call sites are > expected to take a strong ref

Re: [webkit-dev] DRT/WTR should clear the cache at the beginning of each test?

2012-10-28 Thread Balazs Kelemen
On 10/28/2012 05:08 AM, Alexey Proskuryakov wrote: 27.10.2012, ? 20:47, Ami Fischman > ???(?): There are lot of things remaining in the process across tests runs What "things" remain in the process across test runs that are visible to DRT/JS? Memory