date:20101019

That does not sound expected or desired. Could you point me to which
Chromium builders are responsible for so much data?

I suspect this is an artifact of new-run-webkit-tests or how the
Chromium builders are set up.

On Tue, Oct 19, 2010 at 9:12 AM, William Siegrist wsiegr...@apple.com wrote:
Right now, /results/ is served from the new storage and is receiving test
results data since a day or two ago. For anything older, you will get
redirected to /old-results/ which is on the old storage. This probably breaks
your code if you are trying to load /results/ and walk backwards in
revisions. We should probably look at adding some sort of map to the
/json/builders/ data instead.

On a side note, Chromium test results account for 75% of the 700GB of result
data, SnowLeopard is 11%, then everyone else. I assume Chromium generating so
much more data than everyone else is expected and desired?

-Bill

On Oct 18, 2010, at 5:04 PM, Eric Seidel wrote:

The most frequent consumer of the historical data is webkit-patch,
which uses it to map from revisions to builds:
http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/net/buildbot.py#L109

It's used when we're walking back through revisions trying to find
when the build broke, or when the user passes us a revision and
expects us to know build information about such.

It's possible we could move off that map with some re-design.

One thing which would *hugely* speed up webkit-patch failure-reason
(and sherriff-bot, and other commands which use the
build_to_revision_map) is if we could make the results/ pages
paginated. :)

I would be nice to keep all the build data for forever. Even if after
some date in the past its on a slower server.

-eric

On Sat, Oct 16, 2010 at 12:38 AM, William Siegrist wsiegr...@apple.com
wrote:
On Oct 14, 2010, at 10:13 AM, William Siegrist wrote:

On Oct 14, 2010, at 9:27 AM, William Siegrist wrote:

I am in the process of moving buildbot onto faster storage which should
help with performance. However, during the move, performance will be even
worse due to the extra i/o. There will be a downtime period in the next
few days to do the final switchover, but I won't know when that will be
until the preliminary copying is done. I am trying not to kill the master
completely, but there have been some slave disconnects due to the load
already this morning. I'll let everyone know when the downtime will be
once I know.

The copying of data will take days at the rate we're going, and the server
is exhibiting some strange memory paging in the process. I am going to
reboot the server and try copying with the buildbot master down. The
master will be down for about 15m, if I can't get the copy done in that
time I will schedule a longer downtime at a better time. Sorry for the
churn.

Most of build.webkit.org is now running on the newer/faster storage.
However, the results data[1] is hundreds of gigabytes, going back 6 months,
and the new storage is not big enough. Does anyone have any opinion on how
much data to keep in results? Does anyone ever look back more than a month
or two? For now, the results will still come up a slowly, but hopefully the
rest of buildbot is a little more responsive. We're still planning to move
all of webkit.org to better hardware soon, but we hit some delays in that
process.

[1] http://build.webkit.org/results/

Thanks
-Bill

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Buildbot Performance

On Tue, Oct 19, 2010 at 9:20 AM, Ryosuke Niwa ryosuke.n...@gmail.comwrote:

Ins't this due to the fact Chromium bots run pixel tests and others don't?

- Ryosuke

On Tue, Oct 19, 2010 at 9:17 AM, Eric Seidel e...@webkit.org wrote:

That does not sound expected or desired. Could you point me to which
Chromium builders are responsible for so much data?

I suspect this is an artifact of new-run-webkit-tests or how the
Chromium builders are set up.

On Tue, Oct 19, 2010 at 9:12 AM, William Siegrist wsiegr...@apple.com
wrote:
Right now, /results/ is served from the new storage and is receiving
test results data since a day or two ago. For anything older, you will get
redirected to /old-results/ which is on the old storage. This probably
breaks your code if you are trying to load /results/ and walk backwards in
revisions. We should probably look at adding some sort of map to the
/json/builders/ data instead.

On a side note, Chromium test results account for 75% of the 700GB of
result data, SnowLeopard is 11%, then everyone else. I assume Chromium
generating so much more data than everyone else is expected and desired?

-Bill

On Oct 18, 2010, at 5:04 PM, Eric Seidel wrote:

The most frequent consumer of the historical data is webkit-patch,
which uses it to map from revisions to builds:

http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/net/buildbot.py#L109

It's used when we're walking back through revisions trying to find
when the build broke, or when the user passes us a revision and
expects us to know build information about such.

It's possible we could move off that map with some re-design.

One thing which would *hugely* speed up webkit-patch failure-reason
(and sherriff-bot, and other commands which use the
build_to_revision_map) is if we could make the results/ pages
paginated. :)

I would be nice to keep all the build data for forever. Even if after
some date in the past its on a slower server.

-eric

On Sat, Oct 16, 2010 at 12:38 AM, William Siegrist
wsiegr...@apple.com wrote:
On Oct 14, 2010, at 10:13 AM, William Siegrist wrote:

On Oct 14, 2010, at 9:27 AM, William Siegrist wrote:

I am in the process of moving buildbot onto faster storage which
should help with performance. However, during the move, performance will be
even worse due to the extra i/o. There will be a downtime period in the next
few days to do the final switchover, but I won't know when that will be
until the preliminary copying is done. I am trying not to kill the master
completely, but there have been some slave disconnects due to the load
already this morning. I'll let everyone know when the downtime will be once
I know.

The copying of data will take days at the rate we're going, and the
server is exhibiting some strange memory paging in the process. I am going
to reboot the server and try copying with the buildbot master down. The
master will be down for about 15m, if I can't get the copy done in that time
I will schedule a longer downtime at a better time. Sorry for the churn.

[1] http://build.webkit.org/results/

Thanks
-Bill

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] New requirement for building on Windows coming

2010-10-19 Thread 胡慧鋒

Apparently DirectX SDK is now a required tool to get building on Windows.  I
fought for 2 days with my build before stumbling across this old thread.
 Are you still planning to add this to webkit.org/building/tools.html?  Or,
tell me how and I'll update that page.

Thanks,
Jenn



On Tue, Nov 24, 2009 at 4:19 PM, Chris Marrin cmar...@apple.com wrote:


 On Nov 24, 2009, at 11:12 AM, Alexey Proskuryakov wrote:

 
  On 24.11.2009, at 9:46, Adam Roben wrote:
 
  On second thought, even if we soft-link, we'll still have dependencies
 on the D3D headers...
 
 
  Can we make a local copy of those?

 I've used the DXSDK_DIR env var to handle both the include and lib
 locations. This all seems to work fine and will only require the DX SDK when
 we turn on ACCELERATED_COMPOSITING. Given that, do we still need
 soft-linking or a local copy of the headers?

 -
 ~Chris
 cmar...@apple.com




 ___
 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] Buildbot Slave Umask

2010-10-19 Thread William Siegrist

If you do not own a build slave for build.webkit.org, you can stop reading. 

If you maintain a buildbot slave for build.webkit.org, please make sure the 
umask is set to 022. By default, the umask is 077 and this makes the results 
only readable by the user that uploads them to the master. We need them to be 
world readable. To do this, go to your slave directory and edit buildbot.tac. 
The umask line should read umask = 022. The 0 is important. If you have to 
change buildbot.tac, then you also need to stop and restart your buildbot 
process. 

Once you've done that, please email me (without CCing the list) telling me 
which slave(s) were changed and which were already set to 022. 

Thanks
-Bill

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] New requirement for building on Windows coming

Submit a patch to modify this page:
http://trac.webkit.org/browser/trunk/WebKitSite/building/tools.html

- Ryosuke

On Tue, Oct 19, 2010 at 9:30 AM, Jenn Braithwaite (胡慧鋒) je...@google.comwrote:

 Apparently DirectX SDK is now a required tool to get building on Windows.
  I fought for 2 days with my build before stumbling across this old thread.
  Are you still planning to add this to webkit.org/building/tools.html?
  Or, tell me how and I'll update that page.

 Thanks,
 Jenn




 On Tue, Nov 24, 2009 at 4:19 PM, Chris Marrin cmar...@apple.com wrote:


 On Nov 24, 2009, at 11:12 AM, Alexey Proskuryakov wrote:

 
  On 24.11.2009, at 9:46, Adam Roben wrote:
 
  On second thought, even if we soft-link, we'll still have dependencies
 on the D3D headers...
 
 
  Can we make a local copy of those?

 I've used the DXSDK_DIR env var to handle both the include and lib
 locations. This all seems to work fine and will only require the DX SDK when
 we turn on ACCELERATED_COMPOSITING. Given that, do we still need
 soft-linking or a local copy of the headers?

 -
 ~Chris
 cmar...@apple.com




 ___
 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] Buildbot Performance

2010-10-19 Thread Dimitri Glazkov

I would venture to guess that's probably it.

:DG

On Tue, Oct 19, 2010 at 9:21 AM, Ryosuke Niwa rn...@webkit.org wrote:

On Tue, Oct 19, 2010 at 9:20 AM, Ryosuke Niwa ryosuke.n...@gmail.com
wrote:

Ins't this due to the fact Chromium bots run pixel tests and others don't?

- Ryosuke

On Tue, Oct 19, 2010 at 9:17 AM, Eric Seidel e...@webkit.org wrote:

That does not sound expected or desired. Could you point me to which
Chromium builders are responsible for so much data?

I suspect this is an artifact of new-run-webkit-tests or how the
Chromium builders are set up.

On Tue, Oct 19, 2010 at 9:12 AM, William Siegrist wsiegr...@apple.com
wrote:
Right now, /results/ is served from the new storage and is receiving
test results data since a day or two ago. For anything older, you will get
redirected to /old-results/ which is on the old storage. This probably
breaks your code if you are trying to load /results/ and walk backwards in
revisions. We should probably look at adding some sort of map to the
/json/builders/ data instead.

On a side note, Chromium test results account for 75% of the 700GB of
result data, SnowLeopard is 11%, then everyone else. I assume Chromium
generating so much more data than everyone else is expected and desired?

-Bill

On Oct 18, 2010, at 5:04 PM, Eric Seidel wrote:

The most frequent consumer of the historical data is webkit-patch,
which uses it to map from revisions to builds:

http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/net/buildbot.py#L109

It's used when we're walking back through revisions trying to find
when the build broke, or when the user passes us a revision and
expects us to know build information about such.

It's possible we could move off that map with some re-design.

One thing which would *hugely* speed up webkit-patch failure-reason
(and sherriff-bot, and other commands which use the
build_to_revision_map) is if we could make the results/ pages
paginated. :)

I would be nice to keep all the build data for forever. Even if after
some date in the past its on a slower server.

-eric

On Sat, Oct 16, 2010 at 12:38 AM, William Siegrist
wsiegr...@apple.com wrote:
On Oct 14, 2010, at 10:13 AM, William Siegrist wrote:

On Oct 14, 2010, at 9:27 AM, William Siegrist wrote:

I am in the process of moving buildbot onto faster storage which
should help with performance. However, during the move, performance
will be
even worse due to the extra i/o. There will be a downtime period in
the next
few days to do the final switchover, but I won't know when that will
be
until the preliminary copying is done. I am trying not to kill the
master
completely, but there have been some slave disconnects due to the load
already this morning. I'll let everyone know when the downtime will
be once
I know.

The copying of data will take days at the rate we're going, and the
server is exhibiting some strange memory paging in the process. I am
going
to reboot the server and try copying with the buildbot master down. The
master will be down for about 15m, if I can't get the copy done in
that time
I will schedule a longer downtime at a better time. Sorry for the
churn.

Most of build.webkit.org is now running on the newer/faster storage.
However, the results data[1] is hundreds of gigabytes, going back 6
months,
and the new storage is not big enough. Does anyone have any opinion on
how
much data to keep in results? Does anyone ever look back more than a
month
or two? For now, the results will still come up a slowly, but hopefully
the
rest of buildbot is a little more responsive. We're still planning to
move
all of webkit.org to better hardware soon, but we hit some delays in
that
process.

[1] http://build.webkit.org/results/

Thanks
-Bill

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Buildbot Performance

2010-10-19 Thread William Siegrist

Linux, Mac, and Win Release Tests. Note the size of the ZIP files at the bottom
of these pages:

http://build.webkit.org/old-results/Chromium%20Linux%20Release%20%28Tests%29/

versus:

http://build.webkit.org/old-results/SnowLeopard%20Intel%20Leaks/

If it's useful data, I'll store it for you. I have plenty of disk space. It is
just that when the directory list gets so large, accessing/iterating gets
slower, and the larger disk array is not our fastest media.

-Bill

On Oct 19, 2010, at 9:17 AM, Eric Seidel wrote:

That does not sound expected or desired. Could you point me to which
Chromium builders are responsible for so much data?

I suspect this is an artifact of new-run-webkit-tests or how the
Chromium builders are set up.

On Tue, Oct 19, 2010 at 9:12 AM, William Siegrist wsiegr...@apple.com wrote:
Right now, /results/ is served from the new storage and is receiving test
results data since a day or two ago. For anything older, you will get
redirected to /old-results/ which is on the old storage. This probably
breaks your code if you are trying to load /results/ and walk backwards in
revisions. We should probably look at adding some sort of map to the
/json/builders/ data instead.

On a side note, Chromium test results account for 75% of the 700GB of result
data, SnowLeopard is 11%, then everyone else. I assume Chromium generating
so much more data than everyone else is expected and desired?

-Bill

On Oct 18, 2010, at 5:04 PM, Eric Seidel wrote:

It's used when we're walking back through revisions trying to find
when the build broke, or when the user passes us a revision and
expects us to know build information about such.

It's possible we could move off that map with some re-design.

One thing which would *hugely* speed up webkit-patch failure-reason
(and sherriff-bot, and other commands which use the
build_to_revision_map) is if we could make the results/ pages
paginated. :)

I would be nice to keep all the build data for forever. Even if after
some date in the past its on a slower server.

-eric

On Sat, Oct 16, 2010 at 12:38 AM, William Siegrist wsiegr...@apple.com
wrote:
On Oct 14, 2010, at 10:13 AM, William Siegrist wrote:

On Oct 14, 2010, at 9:27 AM, William Siegrist wrote:

I am in the process of moving buildbot onto faster storage which should
help with performance. However, during the move, performance will be
even worse due to the extra i/o. There will be a downtime period in the
next few days to do the final switchover, but I won't know when that
will be until the preliminary copying is done. I am trying not to kill
the master completely, but there have been some slave disconnects due to
the load already this morning. I'll let everyone know when the downtime
will be once I know.

The copying of data will take days at the rate we're going, and the
server is exhibiting some strange memory paging in the process. I am
going to reboot the server and try copying with the buildbot master down.
The master will be down for about 15m, if I can't get the copy done in
that time I will schedule a longer downtime at a better time. Sorry for
the churn.

Most of build.webkit.org is now running on the newer/faster storage.
However, the results data[1] is hundreds of gigabytes, going back 6
months, and the new storage is not big enough. Does anyone have any
opinion on how much data to keep in results? Does anyone ever look back
more than a month or two? For now, the results will still come up a
slowly, but hopefully the rest of buildbot is a little more responsive.
We're still planning to move all of webkit.org to better hardware soon,
but we hit some delays in that process.

[1] http://build.webkit.org/results/

Thanks
-Bill

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Buildbot Performance

2010-10-19 Thread Ojan Vafai

It's that combined with the fact that Chromium runs some tests that are
expected to fail. As the number of tests chromium is failing and runs
shrinks, the storage growth will shrink as well.

Do we store results for tests that are marked WONTFIX? We probably
shouldn't. IMO we shouldn't even run them.

Ojan

On Tue, Oct 19, 2010 at 9:46 AM, Dimitri Glazkov dglaz...@chromium.orgwrote:

I would venture to guess that's probably it.

:DG

On Tue, Oct 19, 2010 at 9:21 AM, Ryosuke Niwa rn...@webkit.org wrote:

On Tue, Oct 19, 2010 at 9:20 AM, Ryosuke Niwa ryosuke.n...@gmail.com
wrote:

Ins't this due to the fact Chromium bots run pixel tests and others
don't?

- Ryosuke

On Tue, Oct 19, 2010 at 9:17 AM, Eric Seidel e...@webkit.org wrote:

That does not sound expected or desired. Could you point me to which
Chromium builders are responsible for so much data?

I suspect this is an artifact of new-run-webkit-tests or how the
Chromium builders are set up.

On Tue, Oct 19, 2010 at 9:12 AM, William Siegrist wsiegr...@apple.com

wrote:
Right now, /results/ is served from the new storage and is receiving
test results data since a day or two ago. For anything older, you
will get
redirected to /old-results/ which is on the old storage. This
probably
breaks your code if you are trying to load /results/ and walk
backwards in
revisions. We should probably look at adding some sort of map to the
/json/builders/ data instead.

On a side note, Chromium test results account for 75% of the 700GB of
result data, SnowLeopard is 11%, then everyone else. I assume
Chromium
generating so much more data than everyone else is expected and
desired?

-Bill

On Oct 18, 2010, at 5:04 PM, Eric Seidel wrote:

The most frequent consumer of the historical data is webkit-patch,
which uses it to map from revisions to builds:

http://trac.webkit.org/browser/trunk/WebKitTools/Scripts/webkitpy/common/net/buildbot.py#L109

It's used when we're walking back through revisions trying to find
when the build broke, or when the user passes us a revision and
expects us to know build information about such.

It's possible we could move off that map with some re-design.

One thing which would *hugely* speed up webkit-patch failure-reason
(and sherriff-bot, and other commands which use the
build_to_revision_map) is if we could make the results/ pages
paginated. :)

I would be nice to keep all the build data for forever. Even if
after
some date in the past its on a slower server.

-eric

On Sat, Oct 16, 2010 at 12:38 AM, William Siegrist
wsiegr...@apple.com wrote:
On Oct 14, 2010, at 10:13 AM, William Siegrist wrote:

On Oct 14, 2010, at 9:27 AM, William Siegrist wrote:

I am in the process of moving buildbot onto faster storage which
should help with performance. However, during the move,
performance will be
even worse due to the extra i/o. There will be a downtime period
in the next
few days to do the final switchover, but I won't know when that
will be
until the preliminary copying is done. I am trying not to kill
the master
completely, but there have been some slave disconnects due to the
load
already this morning. I'll let everyone know when the downtime
will be once
I know.

The copying of data will take days at the rate we're going, and
the
server is exhibiting some strange memory paging in the process. I
am going
to reboot the server and try copying with the buildbot master
down. The
master will be down for about 15m, if I can't get the copy done in
that time
I will schedule a longer downtime at a better time. Sorry for the
churn.

Most of build.webkit.org is now running on the newer/faster
storage.
However, the results data[1] is hundreds of gigabytes, going back 6
months,
and the new storage is not big enough. Does anyone have any opinion
on how
much data to keep in results? Does anyone ever look back more than
a month
or two? For now, the results will still come up a slowly, but
hopefully the
rest of buildbot is a little more responsive. We're still planning
to move
all of webkit.org to better hardware soon, but we hit some delays
in that
process.

[1] http://build.webkit.org/results/

Thanks
-Bill

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing

Re: [webkit-dev] disable selection of text and images

2010-10-19 Thread Efan...

Hi All unfortunately I can not use JAVA script or any thing like that cause
my application is totally c++ , QT based.
I need to make the change in webkit src code I guess.

On Tue, Oct 19, 2010 at 8:39 AM, Simon Fraser simon.fra...@apple.comwrote:

 Put
 * {
  -webkit-user-select: none;
 }

 in your user-agent stylesheet?

 Simon

 On Oct 18, 2010, at 10:12 PM, Efan... wrote:

  Hi
  I am totally new to this group.
 
  I want to disable selection of Text and graphics in my QWebView, it seems
 that there is no way via Qt i can do this , so only option I am left with is
 to modify webkit code.
  I am new to webkit code too, but I am willing to put my time and effort
 to do this, Can any one please suggest what file/function should I be
 modifying in webkit?? Or does any one has any other solution other than
 modifying webkit?
 
  I will highly appreciate any input on this.




-- 
Efan Harris
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] disable selection of text and images

2010-10-19 Thread Dan Bernstein


On Oct 19, 2010, at 10:07 AM, Efan... wrote:

 Hi All unfortunately I can not use JAVA script or any thing like that cause 
 my application is totally c++ , QT based.
 I need to make the change in webkit src code I guess.

Note that this is already supported (with no source changes) on Mac OS X via 
the editing delegate method 
-webView:shouldChangeSelectedDOMRange:toDOMRange:affinity:stillSelecting:. 
Perhaps Qt WebKit is missing an equivalent to that delegate interface (a 
cursory look in EditorClientQt.cpp suggest that it is).

 
 On Tue, Oct 19, 2010 at 8:39 AM, Simon Fraser simon.fra...@apple.com wrote:
 Put
 * {
  -webkit-user-select: none;
 }
 
 in your user-agent stylesheet?
 
 Simon
 
 On Oct 18, 2010, at 10:12 PM, Efan... wrote:
 
  Hi
  I am totally new to this group.
 
  I want to disable selection of Text and graphics in my QWebView, it seems 
  that there is no way via Qt i can do this , so only option I am left with 
  is to modify webkit code.
  I am new to webkit code too, but I am willing to put my time and effort to 
  do this, Can any one please suggest what file/function should I be 
  modifying in webkit?? Or does any one has any other solution other than 
  modifying webkit?
 
  I will highly appreciate any input on this.
 
 
 
 
 -- 
 Efan Harris
 ___
 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] Focus Crash Relating to MathML

2010-10-19 Thread Alex Milowski

On Mon, Oct 18, 2010 at 8:22 PM, Alex Milowski a...@milowski.org wrote:
 In cases where specialized render objects (typically with display
 inline-block) are used  (e.g. an operator), the assert fires:

 a href='#'
  math xmlns='http://www.w3.org/1998/Math/MathML'mox/mo/math
 /a


The culprit in this particular case turns out to be a call to
destroyLeftoverChildren() during
the layout.  The RenderMathMLOperator class potentially re-stacks the glyphs and
that causes the children to be destroyed.  During that process, the
container ancestors
are marked as having a child needing layout.  At the end of the
ancestor's layout()
method, the MathML rendering objects have all sorted themselves out
and no longer
need layout.

The result is that the tree is inconsistent.  If the ancestors can
easily be marked
as having a child needing layout during the descendant's layout()
process, shouldn't
each ancestor check the consistency between if m_normalChildNeedsLayout and
their actual children before leaving layout()?


-- 
--Alex Milowski
The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered.

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] disable selection of text and images

Hi,

I think I talked with this person on IRC last night, and I suggested him to
modify EditorClientQt::shouldChangeSelectedRange to always return false.
 FYI, there is a bug to add this feature on Qt ports:
https://bugs.webkit.org/show_bug.cgi?id=38520

- Ryosuke

On Tue, Oct 19, 2010 at 10:17 AM, Dan Bernstein m...@apple.com wrote:


 On Oct 19, 2010, at 10:07 AM, Efan... wrote:

 Hi All unfortunately I can not use JAVA script or any thing like that cause
 my application is totally c++ , QT based.
 I need to make the change in webkit src code I guess.


 Note that this is already supported (with no source changes) on Mac OS X
 via the editing delegate method
 -webView:shouldChangeSelectedDOMRange:toDOMRange:affinity:stillSelecting:.
 Perhaps Qt WebKit is missing an equivalent to that delegate interface (a
 cursory look in EditorClientQt.cpp suggest that it is).


 On Tue, Oct 19, 2010 at 8:39 AM, Simon Fraser simon.fra...@apple.comwrote:

 Put
 * {
  -webkit-user-select: none;
 }

 in your user-agent stylesheet?

 Simon

 On Oct 18, 2010, at 10:12 PM, Efan... wrote:

  Hi
  I am totally new to this group.
 
  I want to disable selection of Text and graphics in my QWebView, it
 seems that there is no way via Qt i can do this , so only option I am left
 with is to modify webkit code.
  I am new to webkit code too, but I am willing to put my time and effort
 to do this, Can any one please suggest what file/function should I be
 modifying in webkit?? Or does any one has any other solution other than
 modifying webkit?
 
  I will highly appreciate any input on this.


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] New requirement for building on Windows coming

2010-10-19 Thread 胡慧鋒

Thanks, Ryosuke.

Done.  https://bugs.webkit.org/show_bug.cgi?id=47911

Jenn

On Tue, Oct 19, 2010 at 9:37 AM, Ryosuke Niwa rn...@webkit.org wrote:

 Submit a patch to modify this page:
 http://trac.webkit.org/browser/trunk/WebKitSite/building/tools.html

 - Ryosuke


 On Tue, Oct 19, 2010 at 9:30 AM, Jenn Braithwaite (胡慧鋒) 
 je...@google.comwrote:

 Apparently DirectX SDK is now a required tool to get building on Windows.
  I fought for 2 days with my build before stumbling across this old thread.
  Are you still planning to add this to webkit.org/building/tools.html?
  Or, tell me how and I'll update that page.

 Thanks,
 Jenn




 On Tue, Nov 24, 2009 at 4:19 PM, Chris Marrin cmar...@apple.com wrote:


 On Nov 24, 2009, at 11:12 AM, Alexey Proskuryakov wrote:

 
  On 24.11.2009, at 9:46, Adam Roben wrote:
 
  On second thought, even if we soft-link, we'll still have dependencies
 on the D3D headers...
 
 
  Can we make a local copy of those?

 I've used the DXSDK_DIR env var to handle both the include and lib
 locations. This all seems to work fine and will only require the DX SDK when
 we turn on ACCELERATED_COMPOSITING. Given that, do we still need
 soft-linking or a local copy of the headers?

 -
 ~Chris
 cmar...@apple.com




 ___
 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

[webkit-dev] Closing the loop on flaky tests (was Re: Flaky test hit list)

On Tue, Oct 19, 2010 at 8:42 AM, Alexey Proskuryakov a...@webkit.org wrote:
15.10.2010, в 07:39, Eric Seidel написал(а):

BTW, the commit-queue has started complaining publicly about flaky tests:

https://bugs.webkit.org/show_bug.cgi?id=47698#c5

Hopefully this will bring further awareness to the issue.

I find this extremely annoying and offensive. Half of my bugmail is already
about bugs that I'm not interested in.

Sorry Alexey, I certainly didn't intend to offend you.

The problem we're trying to solve is currently there is no feedback
loop for authors of flaky tests. If someone writes a flaky test,
there's no mechanism for them to find out about it. It just sticks
around and causes pain for everyone else. The idea behind this change
is to create a feedback loop whereby authors of flaky tests can
discover that their tests are flaky.

Looking back at the history since this feature was enabled, it looks
like you were CCed on 3 of the 4 bugs that encountered flaky tests.
Here are the tests that flaked out:

1x
http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/appcache/404-manifest.html
2x
http://trac.webkit.org/browser/trunk/LayoutTests/http/tests/appcache/insert-html-element-with-manifest-2.html

According to SVN, you did write both of these tests, so the tool is
accurately computing the author. This triggering more often than we
expected. I'm not sure whether that's a statistical aberration.
Here's how we calculated how much traffic this tool would generate:

According to webkit-patch find-flaky-tests, the flakiest test fails
about 7 times per 2000 revisions, which means it fails for 0.3% of
test runs. The commit-queue lands about 30 patches per day, so that
means the author of the flakiest test should get CCed on about one bug
every ten days. Also, these bugs are close to the end of their
lifecycle (because their patch is about to land), so they shouldn't
generate more than 3 or 4 emails each. That boils down to about one
or two emails per week for the flakiest test.

Now, that calculation is a very rough approximation, and we might have
missed some important factors. We're certainly open to other
suggestions for how to close the loop on flaky tests if this approach
generates too much email.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Focus Crash Relating to MathML

2010-10-19 Thread David Hyatt

(1) Make sure any layout methods you call do setNeedsLayout(false) at the end 
of them.
(2) Look for any early returns in any of your layout methods, since maybe you 
did an early return causing the setNeedsLayout(false) to be missed.
(3) Make sure you aren't dirtying a child for a re-layout without immediately 
doing that re-layout, e.g., don't call setChildNeedsLayout(true, false) on some 
child and then bail without doing a layout.

dave

On Oct 18, 2010, at 10:22 PM, Alex Milowski wrote:

 Most of the MathML rendering objects have a display style property value
 of inline-block.  Whenever these rendering objects are used, somehow the
 parent container gets marked as having children in need of layout.  The
 MathML math rendering object completes its layout and marks itself as
 not needing layout.  In the end, the container (e.g. the anchor element)
 render object has itself in a state where m_normalChildNeedsLayout is
 true but no child is marked as needing layout.
 
 I've gone through the MathML rendering objects and remove all uses
 of markContaingBlocksForLayout() and setNeedsLayoutPrefWidthsRecalc()
 which generally cause the container to be marked with a child needing
 layout.  These calls were unnecessary and the resulting code should be
 more efficient.
 
 In situations where the MathML does not contain a rendering object
 that is an inline-block, everything works fine.  For example:
 
 a href='#'
  math xmlns='http://www.w3.org/1998/Math/MathML'mix/mi/math
 /a
 
 Keep in mind, in the above, the 'mi' element just uses RenderInline as it
 has no special semantics as of yet.
 
 In cases where specialized render objects (typically with display
 inline-block) are used  (e.g. an operator), the assert fires:
 
 a href='#'
  math xmlns='http://www.w3.org/1998/Math/MathML'mox/mo/math
 /a
 
 At this point, I don't think my code is directly causing the anchor to
 get marked
 with a child needing layout.  I do rely on RenderBlock::layout() within most
 of the rendering objects to handle the actual layout after adjustments.
 
 I've tried making sure that the parent or container schedule a re-layout but
 that hasn't really helped.
 
 You can see all these adjustments and optimizations in the patch for:
 
   https://bugs.webkit.org/show_bug.cgi?id=43462
 
 Any ideas of what to look at next would be appreciated.
 
 
 -- 
 --Alex Milowski
 The excellence of grammar as a guide is proportional to the paucity of the
 inflexions, i.e. to the degree of analysis effected by the language
 considered.
 
 Bertrand Russell in a footnote of Principles of Mathematics
 ___
 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] Closing the loop on flaky tests (was Re: Flaky test hit list)

2010-10-19 Thread Alexey Proskuryakov


19.10.2010, в 11:16, Adam Barth написал(а):

 Also, these bugs are close to the end of their
 lifecycle (because their patch is about to land), so they shouldn't
 generate more than 3 or 4 emails each.  That boils down to about one
 or two emails per week for the flakiest test.


One e-mail (per week?) would perhaps make sense, even though flaky test is 
sometimes flaky code, so the blame becomes misplaced. Getting 3-4 automated 
e-mails per bug seems over the board.

I agree that raising awareness of which tests or code areas are flaky seems 
useful. One problem I personally had was with digging up data on flakiness. The 
link for a dashboard that I found was 
http://test-results.appspot.com/dashboards/flakiness_dashboard.html - the URL 
was freezing my browser for several minutes on each move, and I couldn't make 
sense of what it was telling me UI-wise quickly enough. I'm not even sure how 
it's related to flakiness seen by commit queue, as it seems to be about 
chromium.

Is there a better data source that I missed?

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Closing the loop on flaky tests (was Re: Flaky test hit list)

2010-10-19 Thread Ojan Vafai

On Tue, Oct 19, 2010 at 11:44 AM, Alexey Proskuryakov a...@webkit.org wrote:

 I agree that raising awareness of which tests or code areas are flaky seems
 useful. One problem I personally had was with digging up data on flakiness.
 The link for a dashboard that I found was 
 http://test-results.appspot.com/dashboards/flakiness_dashboard.html - the
 URL was freezing my browser for several minutes on each move, and I couldn't
 make sense of what it was telling me UI-wise quickly enough. I'm not even
 sure how it's related to flakiness seen by commit queue, as it seems to be
 about chromium.


That dashboard currently only supports the Chromium bots. If other bots
successfully switch over to new-run-webkit-tests, we'll be able to easily
add them to that dashboard.

The freezing issue is a recent one I plan on looking into soon. WebKit is
ridiculously slow at rendering this HTML for some reason (it's a single
large table).

The UI is very dense and confusing, but it gives you quite a bit of useful
information. Here's some limited documentation on making sense of the
dashboard UI:
http://sites.google.com/a/chromium.org/dev/developers/testing/flakiness-dashboard

Ojan
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Focus Crash Relating to MathML

2010-10-19 Thread Alex Milowski

On Tue, Oct 19, 2010 at 11:29 AM, David Hyatt hy...@apple.com wrote:
 (1) Make sure any layout methods you call do setNeedsLayout(false) at the end 
 of them.
 (2) Look for any early returns in any of your layout methods, since maybe you 
 did an early return causing the setNeedsLayout(false) to be missed.
 (3) Make sure you aren't dirtying a child for a re-layout without immediately 
 doing that re-layout, e.g., don't call setChildNeedsLayout(true, false) on 
 some child and then bail without doing a layout.

While this is helpful, the current code (in the patch) follows these
principles (except when RenderBlock::layout() is called last and so
setNeedsLayout(false) is already done).  The problem I have is an
*ancestor* is marked as having a child needing layout during the
layout process.  When then MathML layout finishes, the MathML
rendering objects do not need layout but the parent is marked with
m_normalChildNeedsLayout set to true.

This only becomes a problem when the parent of the RenderMathMLMath
rendering object is a RenderInline instance as the a RenderBlock will
call setNeedsLayout(false) on itself at the very end of layout.  To
me, although I have yet to confirm this, it seems like
setNeedsLayout(false) is called during the layout of the inline flow
from RenderBlock::layoutInlineChildren() on the RenderInline instance
and then the RenderInline is marked with a child needing layout.
Unfortunately, none of the above suggestions are going to fix that.

I think the call to destroyLeftoverChildren() is also something we
should reconsider.  In my very simple example, this is what is causing
the RenderInline instance to be marked with a child needing layout as
it causes a traversal through the ancestors.  I know why it is there
but it doesn't necessarily seem like the right way (or place) to
reorganize the operator stacking.

-- 
--Alex Milowski
The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered.

Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] disable selection of text and images

The bug 38520 https://bugs.webkit.org/show_bug.cgi?id=38520 addresses the
exact problem.

- Ryosuke

On Tue, Oct 19, 2010 at 11:28 AM, Efan... efanhar...@gmail.com wrote:

 Ah might be Raving Jason would have had word with you, he is my colleague
 he told me on skype today to do the same, return false from that method,

 But that will permanently disable it I am just looking some way to enable
 disable this when ever developer want using some api at Qt level or
 somewhere else. May be would like to have implementation like
 shouldChangeSelectedDOMRange as in OSX.




 On Tue, Oct 19, 2010 at 10:27 AM, Ryosuke Niwa rn...@webkit.org wrote:

 Hi,

 I think I talked with this person on IRC last night, and I suggested him
 to modify EditorClientQt::shouldChangeSelectedRange to always return false.
  FYI, there is a bug to add this feature on Qt ports:
 https://bugs.webkit.org/show_bug.cgi?id=38520

 - Ryosuke

 On Tue, Oct 19, 2010 at 10:17 AM, Dan Bernstein m...@apple.com wrote:


 On Oct 19, 2010, at 10:07 AM, Efan... wrote:

 Hi All unfortunately I can not use JAVA script or any thing like that
 cause my application is totally c++ , QT based.
 I need to make the change in webkit src code I guess.


 Note that this is already supported (with no source changes) on Mac OS X
 via the editing delegate method
 -webView:shouldChangeSelectedDOMRange:toDOMRange:affinity:stillSelecting:.
 Perhaps Qt WebKit is missing an equivalent to that delegate interface (a
 cursory look in EditorClientQt.cpp suggest that it is).


 On Tue, Oct 19, 2010 at 8:39 AM, Simon Fraser simon.fra...@apple.comwrote:

 Put
 * {
  -webkit-user-select: none;
 }

 in your user-agent stylesheet?

 Simon

 On Oct 18, 2010, at 10:12 PM, Efan... wrote:

  Hi
  I am totally new to this group.
 
  I want to disable selection of Text and graphics in my QWebView, it
 seems that there is no way via Qt i can do this , so only option I am left
 with is to modify webkit code.
  I am new to webkit code too, but I am willing to put my time and
 effort to do this, Can any one please suggest what file/function should I 
 be
 modifying in webkit?? Or does any one has any other solution other than
 modifying webkit?
 
  I will highly appreciate any input on this.




 --
 Efan Harris

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Closing the loop on flaky tests (was Re: Flaky test hit list)

webkit-patch find-flaky-tests can also show you what tests are
recently flaky, but its not as nice as the dashboard.

-eric

On Tue, Oct 19, 2010 at 12:06 PM, Ojan Vafai o...@chromium.org wrote:
 On Tue, Oct 19, 2010 at 11:44 AM, Alexey Proskuryakov a...@webkit.org wrote:

 I agree that raising awareness of which tests or code areas are flaky
 seems useful. One problem I personally had was with digging up data on
 flakiness. The link for a dashboard that I found was
 http://test-results.appspot.com/dashboards/flakiness_dashboard.html - the
 URL was freezing my browser for several minutes on each move, and I couldn't
 make sense of what it was telling me UI-wise quickly enough. I'm not even
 sure how it's related to flakiness seen by commit queue, as it seems to be
 about chromium.

 That dashboard currently only supports the Chromium bots. If other bots
 successfully switch over to new-run-webkit-tests, we'll be able to easily
 add them to that dashboard.
 The freezing issue is a recent one I plan on looking into soon. WebKit is
 ridiculously slow at rendering this HTML for some reason (it's a single
 large table).
 The UI is very dense and confusing, but it gives you quite a bit of useful
 information. Here's some limited documentation on making sense of the
 dashboard
 UI: http://sites.google.com/a/chromium.org/dev/developers/testing/flakiness-dashboard
 Ojan
 ___
 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] Focus Crash Relating to MathML

2010-10-19 Thread David Hyatt

On Oct 19, 2010, at 2:07 PM, Alex Milowski wrote:

 On Tue, Oct 19, 2010 at 11:29 AM, David Hyatt hy...@apple.com wrote:
 (1) Make sure any layout methods you call do setNeedsLayout(false) at the 
 end of them.
 (2) Look for any early returns in any of your layout methods, since maybe 
 you did an early return causing the setNeedsLayout(false) to be missed.
 (3) Make sure you aren't dirtying a child for a re-layout without 
 immediately doing that re-layout, e.g., don't call setChildNeedsLayout(true, 
 false) on some child and then bail without doing a layout.
 
 While this is helpful, the current code (in the patch) follows these
 principles (except when RenderBlock::layout() is called last and so
 setNeedsLayout(false) is already done).  The problem I have is an
 *ancestor* is marked as having a child needing layout during the
 layout process.  When then MathML layout finishes, the MathML
 rendering objects do not need layout but the parent is marked with
 m_normalChildNeedsLayout set to true.
 

Ok, just speculating from eyeballing the code  I think layoutInlineChildren 
should do setNeedsLayout(false) on inlines when the end of the inline is 
encountered rather than the start of it.

The iteration order is start of inline - contents of inline - end of inline, 
and we do setNeedsLayout(false) at the start of the inline.  If the contents of 
the inline end up causing a dirtying up the chain, then this will not be caught 
and cleared.

else if (o-isText() || (o-isRenderInline()  !endOfInline)) {
if (fullLayout || o-selfNeedsLayout())
dirtyLineBoxesForRenderer(o, fullLayout);
o-setNeedsLayout(false);
if (!o-isText())
toRenderInline(o)-invalidateVerticalPosition(); // FIXME: 
Should do better here and not always invalidate everything.
}

In that code above I think !endOfInline should maybe just become endOfInline 
instead.

dave
(hy...@apple.com)

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Closing the loop on flaky tests (was Re: Flaky test hit list)

On Tue, Oct 19, 2010 at 11:44 AM, Alexey Proskuryakov a...@webkit.org wrote:
 19.10.2010, в 11:16, Adam Barth написал(а):
 Also, these bugs are close to the end of their
 lifecycle (because their patch is about to land), so they shouldn't
 generate more than 3 or 4 emails each.  That boils down to about one
 or two emails per week for the flakiest test.

 One e-mail (per week?) would perhaps make sense, even though flaky test is 
 sometimes flaky code, so the blame becomes misplaced. Getting 3-4 automated 
 e-mails per bug seems over the board.

Maybe the thing to do is CC the author of the flaky test for the one
bug comment and then immediately unCC them.  That way they don't see
the rest of the traffic on the bug.

Adam


 I agree that raising awareness of which tests or code areas are flaky seems 
 useful. One problem I personally had was with digging up data on flakiness. 
 The link for a dashboard that I found was 
 http://test-results.appspot.com/dashboards/flakiness_dashboard.html - the 
 URL was freezing my browser for several minutes on each move, and I couldn't 
 make sense of what it was telling me UI-wise quickly enough. I'm not even 
 sure how it's related to flakiness seen by commit queue, as it seems to be 
 about chromium.

 Is there a better data source that I missed?

 - WBR, Alexey Proskuryakov


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Closing the loop on flaky tests (was Re: Flaky test hit list)

2010-10-19 Thread Alexey Proskuryakov


19.10.2010, в 12:33, Adam Barth написал(а):

 Maybe the thing to do is CC the author of the flaky test for the one
 bug comment and then immediately unCC them.  That way they don't see
 the rest of the traffic on the bug.


That would still be two e-mails about a bug the person otherwise doesn't want 
to know about. I don't think that CC'ing is the right approach.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Closing the loop on flaky tests (was Re: Flaky test hit list)

On Tue, Oct 19, 2010 at 12:41 PM, Alexey Proskuryakov a...@webkit.org wrote:
 19.10.2010, в 12:33, Adam Barth написал(а):
 Maybe the thing to do is CC the author of the flaky test for the one
 bug comment and then immediately unCC them.  That way they don't see
 the rest of the traffic on the bug.

 That would still be two e-mails about a bug the person otherwise doesn't want 
 to know about. I don't think that CC'ing is the right approach.

Do you see changes to bugs when you get removed from the CC?  Do you
have another suggestion for how to providing feedback to authors of
flaky tests?

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Closing the loop on flaky tests (was Re: Flaky test hit list)

2010-10-19 Thread Ojan Vafai

On Tue, Oct 19, 2010 at 1:30 PM, Adam Barth aba...@webkit.org wrote:

 On Tue, Oct 19, 2010 at 12:41 PM, Alexey Proskuryakov a...@webkit.org
 wrote:
  19.10.2010, в 12:33, Adam Barth написал(а):
  Maybe the thing to do is CC the author of the flaky test for the one
  bug comment and then immediately unCC them.  That way they don't see
  the rest of the traffic on the bug.
 
  That would still be two e-mails about a bug the person otherwise doesn't
 want to know about. I don't think that CC'ing is the right approach.

 Do you see changes to bugs when you get removed from the CC?  Do you
 have another suggestion for how to providing feedback to authors of
 flaky tests?


Email the author directly? Doesn't need to go through bugs.webkit.org, does
it?
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Focus Crash Relating to MathML

2010-10-19 Thread David Hyatt

Also, if your pattern of code in a layout method is

(1) Call base class RenderBlock::layout
(2) Do other stuff that might cause dirtying

Then you should really bulletproof that code by adding

(1) Call base class RenderBlock::layout
(2) Do a setChildNeedsLayout(true, false) on yourself just to make yourself 
already dirty.
(3) Do other stuff that might cause dirtying
(4) Do a setNeedsLayout(false)

We don't really have a good setup for calling base class layout methods... 
technically you should stay dirty throughout the lifetime of your own layout 
method, but the base class method will mark you as clean.  We should come up 
with something better at some point, but for now I think if you just dirty for 
the rest of the code you want to run and then mark yourself clean at the end, 
you'd stop the problem as well.

dave

On Oct 19, 2010, at 2:07 PM, Alex Milowski wrote:

 On Tue, Oct 19, 2010 at 11:29 AM, David Hyatt hy...@apple.com wrote:
 (1) Make sure any layout methods you call do setNeedsLayout(false) at the 
 end of them.
 (2) Look for any early returns in any of your layout methods, since maybe 
 you did an early return causing the setNeedsLayout(false) to be missed.
 (3) Make sure you aren't dirtying a child for a re-layout without 
 immediately doing that re-layout, e.g., don't call setChildNeedsLayout(true, 
 false) on some child and then bail without doing a layout.
 
 While this is helpful, the current code (in the patch) follows these
 principles (except when RenderBlock::layout() is called last and so
 setNeedsLayout(false) is already done).  The problem I have is an
 *ancestor* is marked as having a child needing layout during the
 layout process.  When then MathML layout finishes, the MathML
 rendering objects do not need layout but the parent is marked with
 m_normalChildNeedsLayout set to true.
 
 This only becomes a problem when the parent of the RenderMathMLMath
 rendering object is a RenderInline instance as the a RenderBlock will
 call setNeedsLayout(false) on itself at the very end of layout.  To
 me, although I have yet to confirm this, it seems like
 setNeedsLayout(false) is called during the layout of the inline flow
 from RenderBlock::layoutInlineChildren() on the RenderInline instance
 and then the RenderInline is marked with a child needing layout.
 Unfortunately, none of the above suggestions are going to fix that.
 
 I think the call to destroyLeftoverChildren() is also something we
 should reconsider.  In my very simple example, this is what is causing
 the RenderInline instance to be marked with a child needing layout as
 it causes a traversal through the ancestors.  I know why it is there
 but it doesn't necessarily seem like the right way (or place) to
 reorganize the operator stacking.
 
 -- 
 --Alex Milowski
 The excellence of grammar as a guide is proportional to the paucity of the
 inflexions, i.e. to the degree of analysis effected by the language
 considered.
 
 Bertrand Russell in a footnote of Principles of Mathematics
 ___
 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] Closing the loop on flaky tests (was Re: Flaky test hit list)

2010-10-19 Thread Maciej Stachowiak


On Oct 19, 2010, at 1:30 PM, Adam Barth wrote:

 On Tue, Oct 19, 2010 at 12:41 PM, Alexey Proskuryakov a...@webkit.org wrote:
 19.10.2010, в 12:33, Adam Barth написал(а):
 Maybe the thing to do is CC the author of the flaky test for the one
 bug comment and then immediately unCC them.  That way they don't see
 the rest of the traffic on the bug.
 
 That would still be two e-mails about a bug the person otherwise doesn't 
 want to know about. I don't think that CC'ing is the right approach.
 
 Do you see changes to bugs when you get removed from the CC?  Do you
 have another suggestion for how to providing feedback to authors of
 flaky tests?

It looks like the bot is adding a comment to the bug with the patch that was 
being processed when flakiness was detected, not the one that originally landed 
the tests believed to be flaky. Is that right? If so, that doesn't seem like a 
great way to notify the author of the original test. It seems like it would be 
better to comment in the bug that added the test. To be fair, it's also 
possible that the new patch caused the flakiness, so a separate comment there 
could be useful. Perhaps it would be useful to determine if the test in 
question has a track record of flakiness. If not, then maybe the presumption 
should be that the patch is the problem, not the test. On the other hand, if 
the test has always been flaky, then the new patch probably has nothing to do 
with it.

Regards,
Maciej

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Closing the loop on flaky tests (was Re: Flaky test hit list)

On Tue, Oct 19, 2010 at 1:45 PM, Maciej Stachowiak m...@apple.com wrote:
 On Oct 19, 2010, at 1:30 PM, Adam Barth wrote:
 On Tue, Oct 19, 2010 at 12:41 PM, Alexey Proskuryakov a...@webkit.org 
 wrote:
 19.10.2010, в 12:33, Adam Barth написал(а):
 Maybe the thing to do is CC the author of the flaky test for the one
 bug comment and then immediately unCC them.  That way they don't see
 the rest of the traffic on the bug.

 That would still be two e-mails about a bug the person otherwise doesn't 
 want to know about. I don't think that CC'ing is the right approach.

 Do you see changes to bugs when you get removed from the CC?  Do you
 have another suggestion for how to providing feedback to authors of
 flaky tests?

 It looks like the bot is adding a comment to the bug with the patch that was 
 being processed when flakiness was detected, not the one that originally 
 landed the tests believed to be flaky. Is that right? If so, that doesn't 
 seem like a great way to notify the author of the original test. It seems 
 like it would be better to comment in the bug that added the test. To be 
 fair, it's also possible that the new patch caused the flakiness, so a 
 separate comment there could be useful. Perhaps it would be useful to 
 determine if the test in question has a track record of flakiness. If not, 
 then maybe the presumption should be that the patch is the problem, not the 
 test. On the other hand, if the test has always been flaky, then the new 
 patch probably has nothing to do with it.

Another option is to file a new bug about the flakiness and ping that
bug when we observe the test flake out.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Closing the loop on flaky tests (was Re: Flaky test hit list)

On Tue, Oct 19, 2010 at 1:51 PM, Adam Barth aba...@webkit.org wrote:
 Another option is to file a new bug about the flakiness and ping that
 bug when we observe the test flake out.

I've considered this before.  We'd have to write a bit of bugzilla.py
code to make this work though. :)

That's probably the best long term solution.  We could then add links
to these bugs in our sorry we're slow, tests are flaky messages too.

-eric
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Closing the loop on flaky tests (was Re: Flaky test hit list)