On Mon, 2011-12-26 at 21:45 -0800, sachin nikam wrote:
> I synced up the latest webkit code base and am trying to build webkit
> gtk on ubuntu 11.10 with 4gb of RAM and 4 CPUs
>
> I tried with --makeargs="-j2" but still got "ld process terminated
> signal[9]" error ?which indicates that it ran out
I agree that it is reasonable (and a good idea) to remove the
chromium-cg-mac expectations from WebKit now, and I am willing to take the
lead on doing so (although I will need help from WebKit committers).
Please let me know if anyone agrees/disagrees with the following steps to
do so:
1. remove
5. Moving forward, reviewers and committers take care not to re-add
expectations when committing pending patches. While I expect svn will warn
in most cases, I doubt that it will catch everything.
6. "Won't fix" any bugs related to chromium-cg results.
Stephen.
On Wed, Jan 4, 2012 at 9:10 AM, El
On Wed, Jan 4, 2012 at 6:10 AM, Elliot Poger wrote:
> I agree that it is reasonable (and a good idea) to remove the
> chromium-cg-mac expectations from WebKit now, and I am willing to take the
> lead on doing so (although I will need help from WebKit committers).
Sounds like a good plan. I'm hap
Filed https://bugs.webkit.org/show_bug.cgi?id=75548 ('[rollup] remove
chromium-cg-mac baselines')
On Wed, Jan 4, 2012 at 10:37 AM, Adam Barth wrote:
> On Wed, Jan 4, 2012 at 6:10 AM, Elliot Poger wrote:
> > I agree that it is reasonable (and a good idea) to remove the
> > chromium-cg-mac expect
> I'd be careful in how I approach this. Some platforms are going to want
> compositing of overflow sections eventually for fast scrolling of those
> sections. RenderLayer has become the natural tie-in point for GraphicsLayer
> connections.
This is something I don't want to prevent.
That said
On Jan 4, 2012, at 2:36 PM, Julien Chaffraix wrote:
>> namely RenderLayer is too generic for most cases and ends
> up hurting performance.
In what way?
Overflow clips create layers, but they do not paint or hit test at the layer
level unless they are self-painting layers. They only become sel
What is it that causes some tests to require baseline images (and not text
files) for comparison, while others require text and not image baselines?
(I know that I can specifically SKIP comparison against IMAGE and/or TEXT
using test_expectations.txt... but even without the use of
test_expectation
This is probably more appropriate for webkit-help but...
In general, tests that call layoutTestController.dumpAsTest()
or layoutTestController.dumpAsTest(false) and ref tests don't have
expected.png files.
I'm not aware of tests that don't require expected.txt however. Maybe
they're specific to s
On Wed, Jan 4, 2012 at 3:39 PM, Elliot Poger wrote:
> What is it that causes some tests to require baseline images (and not text
> files) for comparison, while others require text and not image baselines?
>
> (I know that I can specifically SKIP comparison against IMAGE and/or TEXT
> using test_e
i am running ubuntu 11.10 64 bit. I was able to eventually build with
--makeargs="-j1".
I will try increase the swap space and see if it helps.
Regards
Sachin
On Wed, Jan 4, 2012 at 3:55 AM, John Yani wrote:
> On Mon, 2011-12-26 at 21:45 -0800, sachin nikam wrote:
>> I synced up the latest webkit
Not to pick on anyone in particular, but when reading bugmail I
occasionally see messages like "pinging for review." I review a lot
of patches, but I don't find these messages particularly helpful
because I don't know whether I'm supposed to review the patch.
Another approach that might work bett
12 matches
Mail list logo
