On Fri, Jan 25, 2013 at 9:30 AM, William Siegrist wrote:
> Here are the largest results sets on the master in GB. We currently store
> 6.8TB of total results, going back 14 months, and 1.1TB of archives going
> back 1 week.
>
> 1500Apple MountainLion (Leaks)
> 1018Chromium Mac Release (Tes
If Chromium DRT crashes, it will leak temp files. Maybe run-webkit-tests
should try to clean these up?
On Thu, Jan 24, 2013 at 10:15 AM, Adam Barth wrote:
> Thanks for the note. We seem to have a temp file leak in
> run-webkit-tests. I'm rebuilding the machines now.
>
> Adam
>
>
> On Thu, Ja
On Tue, Nov 13, 2012 at 12:09 PM, Glenn Adams wrote:
> On Tue, Nov 13, 2012 at 1:02 PM, Tony Chang wrote:
>
>> I don't think we should support port specific ref test results. That
>> kind of misses the point of using a ref test in the first place. I mean,
>>
On Tue, Nov 13, 2012 at 12:04 PM, Darin Adler wrote:
> On Nov 13, 2012, at 12:02 PM, Tony Chang wrote:
>
> > I don't think we should support port specific ref test results. That
> kind of misses the point of using a ref test in the first place. I mean,
> you may as well
On Tue, Nov 13, 2012 at 11:35 AM, Dirk Pranke wrote:
> On Tue, Nov 13, 2012 at 11:29 AM, Glenn Adams wrote:
> >
> > On Tue, Nov 13, 2012 at 12:09 PM, Dirk Pranke
> wrote:
> >>
> >> We don't currently support port-specific reftests (or at least, not
> >> very well), and we certainly should be tr
On Wed, Sep 26, 2012 at 2:35 PM, Brady Eidson wrote:
> On Sep 26, 2012, at 2:05 PM, Adam Barth wrote:
>
> [re-sent from the proper address]
>
> On Wed, Sep 26, 2012 at 2:00 PM, Adam Barth wrote:
>
>> On Wed, Sep 26, 2012 at 1:53 PM, Brady Eidson wrote:
>>
>>> On Sep 26, 2012, at 1:48 PM, Ryosu
On Thu, Jul 19, 2012 at 11:35 AM, Oliver Buchtala <
oliver.bucht...@googlemail.com> wrote:
> On 19.07.2012 20:26, Maciej Stachowiak wrote:
>
>> On Jul 19, 2012, at 11:01 AM, Oliver Buchtala <
>> oliver.buchtala@googlemail.**com > wrote:
>> FWIW, there is a gdb python API for changing the behavior.
In your test case, you should be able to use window.resizeTo to change the
size of the window.
On Fri, Feb 24, 2012 at 5:01 AM, Mayur K wrote:
> Hi,
> I want to specify the window size/view size in DumpRenderTree, so that
> rendertree, can reflect the structure according to the new window size.
The change you suggest for VCSUtils.pm seems fine to me, but if you use
'webkit-patch upload', it'll generate a diff that svn-apply can
successfully apply.
On Wed, Nov 30, 2011 at 5:42 PM, Alan Stearns wrote:
> David,
>
> This is a bug where I accidentally turned on a pixel result, then neede
17, 2011 at 5:17 PM, Dirk Pranke wrote:
> > On Thu, Nov 17, 2011 at 5:06 PM, Eric Seidel wrote:
> >> On Thu, Nov 17, 2011 at 4:53 PM, Tony Chang wrote:
> >>> new-run-webkit-httpd imports common/host.py which imports lots of stuff
> >>> including common/net/
tempted to just make the change and see what breaks. We can
> > always roll it out if things are really bad.
> >
> > I'll prepare an updated patch.
> >
> > -eric
> >
> > On Thu, Nov 17, 2011 at 4:37 PM, Tony Chang wrote:
> >> Only new-run-web
Only new-run-webkit-tests uses python 2.7 on the leopard bots. There are
other bot steps in chromium that would break. I mention a couple cases
here:
http://code.google.com/p/chromium/issues/detail?id=103266#c6
Alternately, we could try to fully switch the leopard bots to 2.7 (
http://crbug.com/
On Tue, Nov 8, 2011 at 12:00 PM, Elliot Poger wrote:
> Perhaps I should approach this from a different angle:
>
> What is the recommended procedure for:
> - generating new baseline images for a few dozen failing tests, on various
> platforms
>
webkit-patch rebaseline-expectations
> - visually
Are you sure? This output has references
to System/Library/Frameworks/Python.framework/Versions/2.5. I also thought
that's why NRWT was slow on the Leopard bots: python 2.5 doesn't have the
multiprocess module.
http://build.chromium.org/p/chromium.webkit/builders/Webkit%20Mac10.5%20%28dbg%29%281
One difference with the chromium port is that we try to use a single
test_expectations.txt that covers all platforms and OS versions (win xp,
vista, 7, mac leopard, snow leopard, linux 32, 64, GPU vs CPU, Debug vs
Release). The tokens to the left of the test name specify what
configuration the exp
Err, ENABLE_NEW_FLEXBOX.
On Mon, Jun 13, 2011 at 9:37 AM, Tony Chang wrote:
> Sure, no problem. I'll rename it to ENALBE_NEW_FLEXBOX.
>
>
> On Fri, Jun 10, 2011 at 6:12 PM, Sam Weinig wrote:
>
>> Since it is confusing to me (and may be to others), perhap
e old flexbox code as a rough guide, but be aware of its issues,
> e.g., too much layout when flexing, box-ordinal stuff is very slow, etc. I
> think some of the bugs you tried to fix already should inform this somewhat.
>
> Definitely keep rendering experts in the loop on this and have f
On Thu, Jun 9, 2011 at 3:55 PM, Maciej Stachowiak wrote:
>
> On Jun 9, 2011, at 3:00 PM, Tony Chang wrote:
>
> On Thu, Jun 9, 2011 at 1:19 PM, Sam Weinig wrote:
>
>> If the issue is the syntax for describing flexing, perhaps the spec should
>> be written in a bac
superset of features provided by the old syntax.
I think it's possible to implement the old flexbox on top of the new
flexbox implementation and that seems like a worthwhile goal, but it'll
probably easier to see the similarities for refactoring after the code has
been written.
>
; >> stable. I expect that in implementing this we'll find areas of the
> spec
> >> >> that
> >> >> need reworking, but at this point it's mainly blocked on
> implementation
> >> >> experience.
> >> >> I'm not
>> months.
> >>
> >> Ojan
> >> On Wed, Jun 8, 2011 at 11:21 AM, Adam Barth wrote:
> >>>
> >>> Can't we just define ENABLE_FLEXBOX on one or more of the commonly
> >>> used ports and use the regular bots?
> >>>
Hi webkit-dev,
I wanted to let you know that Ojan and I plan to add flexbox layout support
to WebCore. WebCore already supports an older flexbox implementation
(display: box), but the new spec is designed to be easier for developers to
understand and more powerful. The old flexbox will still rem
Perhaps, but in practice, it's not enough. Here's an ahem pixel test that
is slightly different on Mac and Chromium Linux:
http://trac.webkit.org/browser/trunk/LayoutTests/platform/mac/fast/block/basic/010-expected.png
http://trac.webkit.org/browser/trunk/LayoutTests/platform/chromium-linux/fast/b
I've just committed the change to run-webkit-tests (old and new) to have it
ignore .checksum files and instead read image checksums from png files.
This is why there were big checkouts during the last few days as I was
updating the old .png files to have checksums embedded. I'll be doing a
follow
Yes, reading the checksum is the same speed as before. We write the png
comment at the beginning of the file and only scan the first 2k of the file
for the checksum. I also tried converting about 200 tests to use embedded
checksums and found no speed difference.
I've already updated new-run-webk
I propose that we move away from checking in separate .checksum files for
pixel tests and instead embed the checksum in the .png file as a comment.
There are two main benefits of doing this:
1) Less files in the tree -> faster git/svn operations. Currently, in
LayoutTests, 32,650 out of 141,170 f
On Tue, Oct 5, 2010 at 9:27 AM, Alexey Proskuryakov wrote:
> So far, the only accurate use case that I've seen was developing a UI for a
> back-end that doesn't support non-ASCII characters in some fields. I don't
> think we should extend the Web platform just to support apps that aren't
> i18n-a
Hi Chris,
I'm curious what elements the UIRequestEvents apply to. Does it fire at the
document level or does it fire for specific elements like textareas? The
addition of undo/redo is similar to the proposal to add this to the
textInput event. There was some discussion of that here:
http://list
I removed all of chromium's duplicate results, which was a bulk of the
duplicates. I think there were a total of about 670 duplicate files and I
deleted about 500 or so. The remaining duplicates are mostly cases where
the same result file is in mac and mac-leopard. I can delete those on
Monday.
Yes: https://bugs.webkit.org/show_bug.cgi?id=31387 . I will update the
Skipped file to include a link to the bug.
On Fri, Jun 25, 2010 at 2:14 AM, Alexey Proskuryakov wrote:
>
> 23.06.2010, в 19:54, t...@chromium.org написал(а):
>
> --- trunk/LayoutTests/platform/mac/Skipped2010-06-24 02:21
30 matches
Mail list logo
