On Sat, Aug 1, 2009 at 1:13 PM, David Kilzer wrote:
> Either we should change the review process to only set the review+ flag if
> the patch is ready to go with zero modifications, or we should use the
> commit+ flag to signify that.
>
> I could go either way on this. I don't like the idea of se
On Sat, Aug 1, 2009 at 12:53 PM, Jeremy Orlow wrote:
> Btw, I see one downside to a commit queue: When you manually commit
> something, you're supposed to watch the build bots for breakage. If the
> submit queue is running all the tests on all the platforms then it doesn't
> really matter, but if
> Nor do I think that we should block development on arbitrary features like
> nested workers
> because we think we need better tools. A better solution would be to roll out
> a "just barely good
> enough" solution, get developer feedback on real use cases, and improve the
> tools over time to
>
On Sat, Aug 1, 2009 at 4:23 PM, Eric Seidel wrote:
> Seems chromium tests are even slower: 10k * mean = 1,634s
>
For completeness sake, the Chromium numbers include the pixel tests.
> 50% (5000) of the tests are < 0.016s, assuming they all take that long,
> that's at most 80seconds.
> 40% (400
Seems chromium tests are even slower: 10k * mean = 1,634s
50% (5000) of the tests are < 0.016s, assuming they all take that long,
that's at most 80seconds.
40% (4000) of the tests are between 0.016 and 0.077, that's at most 311
seconds.
1,634 (total) - 80 - 311 leaves at least 1243 seconds accoun
OK, I really wanted to gloss over this, but now Jeremy's going to make me
elaborate :)
There are a few things I think we will eventually need to support worker
development:
1) Some way to print out the values of things in a worker's global scope.
2) Similar debugging support for workers that we ha
On Aug 1, 2009, at 10:52 AM, Ojan Vafai wrote:
Here's the times for the five slowest top-level directories:
LayoutTests\editing took 43.5 seconds to run 976 tests.
LayoutTests\svg took 53.7 seconds to run 891 tests.
LayoutTests\fast took 378.7 seconds to run 3695 tests.
LayoutTests\http took 39
On Saturday, August 1, 2009 11:45:43 AM, Ojan Vafai wrote:
>On Sat, Aug 1, 2009 at 2:08 PM, Adam Barth wrote:
>>On Sat, Aug 1, 2009 at 11:04 AM, David Kilzer wrote:
>>> Bugzilla has the ability to create additional 4-state flags at
>>> both the attachment level and at the bug level. (Note that
editing/selection/move-left-right.html has very similar script where we
return positions and compare entires in reverse order. Since there is no
setTimeout, we need to rewrite those scripts so that they run faster or
improve the performance of WebKit.
Ryosuke
On Sat, Aug 1, 2009 at 1:09 PM, Ryosu
For editing/selection/extend-selection.html,
It seems like the bottleneck is testExtendingSelection, in particular,
positionExtendingInDirection and checkSameOrder:
function positionsExtendingInDirection(sel, direction, granularity)
{
var positions = [];
while (true) {
positions.p
I think logging to all connected pages' console is fine for now, but I think
Michael's suggestion (or something similar) should be implemented in the not
too distant future. Definitely before shared workers are allowed to
communicate with each other.
J
On Sat, Aug 1, 2009 at 12:45 PM, Michael Nor
On Sat, Aug 1, 2009 at 11:45 AM, Ojan Vafai wrote:
> On Sat, Aug 1, 2009 at 2:08 PM, Adam Barth wrote:
>
>> On Sat, Aug 1, 2009 at 11:04 AM, David Kilzer wrote:
>> > Bugzilla has the ability to create additional 4-state flags at both the
>> attachment level and at the bug level. (Note that bugs
> it sounds like we have one vote for "just log them to the console for every
> connected document"
sgtm
On Sat, Aug 1, 2009 at 12:39 PM, Drew Wilson wrote:
> Yes, SharedWorkers will eventually be able to communicate with one another,
> as will DedicatedWorkers. So at some point we'll have a bi
Yes, SharedWorkers will eventually be able to communicate with one another,
as will DedicatedWorkers. So at some point we'll have a big connected graph
of workers that potentially might be interesting for people to traverse and
inspect their global contexts (I'm not sure - I don't think we know yet
On Sat, Aug 1, 2009 at 2:08 PM, Adam Barth wrote:
> On Sat, Aug 1, 2009 at 11:04 AM, David Kilzer wrote:
> > Bugzilla has the ability to create additional 4-state flags at both the
> attachment level and at the bug level. (Note that bugs.webkit.org does
> not have bug-level flags enabled.)
> >
>
On Sat, Aug 1, 2009 at 11:04 AM, David Kilzer wrote:
> Bugzilla has the ability to create additional 4-state flags at both the
> attachment level and at the bug level. (Note that bugs.webkit.org does not
> have bug-level flags enabled.)
>
> For example, we could create a "commit" attachment flag
On Saturday, August 1, 2009 10:16:39 AM, Adam Barth wrote:
> On Sat, Aug 1, 2009 at 8:43 AM, tonikitoo (Antonio Gomes)wrote:
> > Adam, as I suggedted previously, bugzilla supports KEYWORDs, so that
> > would be a matter of adding a special support for bugs where patches
> > are ready to go in.
> >
SUMMARY
I doubt there's much room for improvement in the test harness itself outside
of running tests in parallel. However, there's clearly a lot to be gained by
making individual tests faster. For Chromium runs, the median time to run a
test is ~16ms. It's not apples to apples, but I would be surp
Shared workers can also communicate directly with one another, is that
right? And its possible to have a shared worker whose only client is
another shared worker, is that right?
Feels like we should be working towards inspecting shared workers
directly. Where a page inspector would show which shar
On Sat, Aug 1, 2009 at 8:43 AM, tonikitoo (Antonio
Gomes) wrote:
> Adam, as I suggedted previously, bugzilla supports KEYWORDs, so that
> would be a matter of adding a special support for bugs where patches
> are ready to go in.
>
> 'checkin-needed' keyword would work , i believe. What do you think
Yeah, I stared a slowest run before going to bed, and got the following:
The 10 slowest tests:
9.58 secs: editing/selection/move-left-right.html
9.37 secs: fast/js/array-filter.html
7.71 secs: editing/selection/extend-selection.html
6.82 secs: fast/js/sort-randomly.html
6.25 secs: http/tests/cache
Hi all,
Currently, unhandled exceptions are sent from worker context over to the
parent page where they are logged to the console. This works fine for
dedicated workers, but not for shared workers which can have multiple active
windows.
The immediate solution that springs to mind is to broadcast t
I will be out of the office starting 07/31/2009 and will not return until
08/17/2009.
I will respond to your message when I return.___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Sat, Aug 1, 2009 at 11:43 AM, tonikitoo (Antonio Gomes) <
toniki...@gmail.com> wrote:
> > I went through the queue tonight and manually marked the bugs as
> > commit-ready by adding [commit+] to their titles. This worked well,
> > except that it made the bug titles ugly. I think a better solu
> I went through the queue tonight and manually marked the bugs as
> commit-ready by adding [commit+] to their titles. This worked well,
> except that it made the bug titles ugly. I think a better solution is
> to have flag analogous to r+ which is commit+.
Adam, as I suggedted previously, bugzi
> It reminds me a lot of the work Badros did circa 2000 [1].
>
That work added linear constraints to CSS and a variety of other languages.
It did not show how to do flow-based layout with linear constraints:
ultimately, the utility and applicability of their techniques to actual
layout system
26 matches
Mail list logo
