Kentaro Hara | 1 Jan 02:07 2012

Re: Enable the [Supplemental] IDL on all build systems

> I suppose that by GTK/GObject you are talking about the GObject DOM bindings
> of the GTK port? This is built and tested by all the GTK bots, so the
> problem you mention is not exactly accurate, at least in GTK's case.

Thank you very much for the information! Then I might be able to write
a patch by myself. I filed a bug for GTK/GObject
(https://bugs.webkit.org/show_bug.cgi?id=75411). Let me try to upload
a first patch.

Also, I filed a bug for AppleWin
(https://bugs.webkit.org/show_bug.cgi?id=75412) and BlackBerry
(https://bugs.webkit.org/show_bug.cgi?id=75413). In a few days I'll
upload a WIP patch that illustrates "this might not build but this is
what I want to do", so I would be happy if someone would help me to
make it work.

--

-- 
Kentaro Hara, Tokyo, Japan (http://haraken.info)
Gyuyoung Kim | 2 Jan 02:43 2012
Picon

Re: [webkit-dev] Announcement of Coding Style Change in WebKit EFL port

Ok, I'm going to file a bug for style checker. And, add you guys to CC. :-)


Thank you,
Gyuyoung.

On Sat, Dec 31, 2011 at 7:09 AM, David Levin <levin <at> google.com> wrote:
Feel free to patch the style checker as appropriate. I suspect there may be some changes needed here:

Best wishes,
dave

On Tue, Dec 27, 2011 at 11:54 PM, Gyuyoung Kim <gyuyoung.kim <at> samsung.com> wrote:

Hello WebKit folks,


As you may know, I have changed the coding style of EFL port via Bug 68209. This is to eliminate unnecessary difficulties

that reviewers have experienced when they review EFL bugs, due to EFL specific coding style.

 

Bug 68209 - [EFL] Change WebKit EFL coding style 

(https://bugs.webkit.org/show_bug.cgi?id=68209)

 

Major changes are as below,

 

1. Use full variable name instead of abbreviation name.

2. Use standard boolean type instead of EFL boolean type.

3. Place '*' operator immediately after the data type. (For example, use char* userAgent. instead of char *userAgent.)

4. Use C++ type casting instead of C type casting.

5. Remove void parameter from internal functions.

6. Use camelCase instead of  underbar(_) in variable names.

 

I made a wiki page for this rule.  I will update this page whenever EFL port coding style guide is changed.

(http://trac.webkit.org/wiki/EFLWebKitCodingStyle)

 

To sum up, EFL port adheres to WebKit coding style except for public header from now.

(Because public header is used by EFL applications, public header will continue to follow the coding style rule of EFL.)

 

We hope that reviewing of EFL port patches will be much easier after this change.

 

Happy new year !!

 

Regards,

Gyuyoung Kim.


_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev



_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


<div>
<p>Ok, I'm going to file a bug for style checker. And, add you guys to CC. :-)</p>
<div><br></div>
<div>Thank you,</div>
<div>Gyuyoung.<br><br><div class="gmail_quote">On Sat, Dec 31, 2011 at 7:09 AM, David Levin <span dir="ltr">&lt;<a href="mailto:levin <at> google.com" target="_blank">levin <at> google.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">Feel free to patch the style checker as appropriate. I suspect there may be some changes needed here:<div><a href="http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/style/checker.py#L180" target="_blank">http://trac.webkit.org/browser/trunk/Tools/Scripts/webkitpy/style/checker.py#L180</a></div>

<div><br></div>
<div>Best wishes,</div>
<div>dave<br><br><div class="gmail_quote">
<div><div>On Tue, Dec 27, 2011 at 11:54 PM, Gyuyoung Kim <span dir="ltr">&lt;<a href="mailto:gyuyoung.kim <at> samsung.com" target="_blank">gyuyoung.kim <at> samsung.com</a>&gt;</span> wrote:<br>
</div></div>
<blockquote class="gmail_quote">
<div><div>

<div>
<span>
<p>Hello WebKit folks,</p>
<p><br></p>
<p>As you may know, I have changed the coding style of EFL port via Bug 68209. This is to eliminate unnecessary difficulties</p>
<p>that reviewers have experienced&nbsp;when they review EFL bugs, due to EFL specific coding style.</p>
<p>&nbsp;</p>
<p>Bug 68209 - [EFL] Change WebKit EFL coding style&nbsp;</p>
<p>(<a href="https://bugs.webkit.org/show_bug.cgi?id=68209" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=68209</a>)</p>
<p>&nbsp;</p>
<p>Major changes are as below,</p>
<p>&nbsp;</p>
<p>1. Use full variable name instead of abbreviation name.</p>
<p>2. Use standard boolean type instead of EFL boolean type.</p>
<p>3. Place '*' operator immediately after the data type. (For example, use char* userAgent. instead of char *userAgent.)</p>
<p>4. Use C++ type casting instead of C type casting.</p>
<p>5. Remove void parameter from internal functions.</p>
<p>6. Use camelCase instead of &nbsp;underbar(_) in variable names.</p>
<p>&nbsp;</p>
<p>I made a wiki page for this rule. &nbsp;I will update this page whenever EFL port coding style guide is changed.</p>
<p>(<a href="http://trac.webkit.org/wiki/EFLWebKitCodingStyle" target="_blank">http://trac.webkit.org/wiki/EFLWebKitCodingStyle</a>)</p>
<p>&nbsp;</p>
<p>To sum up, EFL port adheres to WebKit coding style except for public header from now.</p>
<p>(Because public header is used by EFL applications, public header will continue to follow the coding style rule of EFL.)</p>
<p>&nbsp;</p>
<p>We hope that reviewing of EFL port patches will be much easier after this change.</p>
<p>&nbsp;</p>
<p>Happy new year !!</p>
<p>&nbsp;</p>
<p>Regards,</p>
<p>Gyuyoung Kim.</p></span>
</div>
<br>
</div></div>
<div>_______________________________________________<br>
webkit-dev mailing list<br><a href="mailto:webkit-dev <at> lists.webkit.org" target="_blank">webkit-dev <at> lists.webkit.org</a><br><a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br><br>
</div>
</blockquote>
</div>
<br>
</div>
<br>_______________________________________________<br>
webkit-dev mailing list<br><a href="mailto:webkit-dev <at> lists.webkit.org" target="_blank">webkit-dev <at> lists.webkit.org</a><br><a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br><br>
</blockquote>
</div>
<br>
</div>
</div>
Osztrogonac Csaba | 2 Jan 11:34 2012
Picon

Re: Tools/Scripts/build-webkit --gtk --debug --makeargs="-j1" taking up to 80% of memory

Hi All,

32 bit debug build is impossible long time ago, because linker runs
out of 4Gb address space. Maybe cross compiling on a 64 bit machine
can solve this problem. Is there anyone interested in 32 bit build?

br,
Ossy

Zeno Albisser írta:
> Hi Sachin,
> 
> We had the same/a similar problem with QtWebKit.
> Ranlib ran out of memory on a 32bit system when building debug, because the library got bigger than 4GB.
> I dont think there is a proper solution for this problem. The only thing that would help would be to reduce
the size of WebCore. For now we just disabled debug builds on 32bit systems. I heard some people managed to
build debug by disabling SVG. - never tried it myself though.
> 
> Best Regards
> 
> -- Zeno
> 
> On Dec 27, 2011, at 6:45 AM, sachin nikam <sknikam <at> gmail.com> 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 of memory.
>> I suspect i will still the get the same error with --makeargs="-j1".
>> Is there any other flag where we can restrict the memory usage?
>> Regards
>> Sachin
Philippe Normand | 2 Jan 11:40 2012

Re: Tools/Scripts/build-webkit --gtk --debug --makeargs="-j1" taking up to 80% of memory

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 of memory.
> I suspect i will still the get the same error with --makeargs="-j1".
> Is there any other flag where we can restrict the memory usage?
> Regards
> Sachin

Can you try with the GNU Gold linker? We use it on the GTK Debug bot.

Philippe
_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Soo-Hyun Choi | 3 Jan 04:20 2012
Picon

Re: Tools/Scripts/build-webkit --gtk --debug --makeargs="-j1" taking up to 80% of memory

Philippe,

On Mon, Jan 2, 2012 at 19:40, Philippe Normand <philn <at> igalia.com> wrote:
> 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 of memory.
>> I suspect i will still the get the same error with --makeargs="-j1".
>> Is there any other flag where we can restrict the memory usage?
>> Regards
>> Sachin
>
> Can you try with the GNU Gold linker? We use it on the GTK Debug bot.

I have tried GNU gold linker (Version: 2.20.1-3ubuntu7.1) on Ubuntu
10.04 (32-bit) without success. Could you let us know how you have
been successful to build WebKit Debug on 32-bit machines in more
detail? I have tried building Efl Debug, by the way.

Kind regards,
Soo-Hyun

>
> Philippe
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev <at> lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
Nikolas Zimmermann | 3 Jan 09:21 2012
Picon
Picon
Picon

Re: Tools/Scripts/build-webkit --gtk --debug --makeargs="-j1" taking up to 80% of memory


Am 03.01.2012 um 04:20 schrieb Soo-Hyun Choi:

> Philippe,
> 
> On Mon, Jan 2, 2012 at 19:40, Philippe Normand <philn <at> igalia.com> wrote:
>> 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 of memory.
>>> I suspect i will still the get the same error with --makeargs="-j1".
>>> Is there any other flag where we can restrict the memory usage?
>>> Regards
>>> Sachin
>> 
>> Can you try with the GNU Gold linker? We use it on the GTK Debug bot.
> 
> 
> I have tried GNU gold linker (Version: 2.20.1-3ubuntu7.1) on Ubuntu
> 10.04 (32-bit) without success. Could you let us know how you have
> been successful to build WebKit Debug on 32-bit machines in more
> detail? I have tried building Efl Debug, by the way.

Just a side note: I'm building 32bit release builds on my 32bit MBP from 2006 with a set of specific xcode hack
that I'm maintaining locally:
Add all {Editing|Render|DOM}AllInOne.cpp files to build, remove all files from WebCore target that are
referenced in those files.
This allows to use build-webkit, with all default features enabled.

I tried this the last time 2 weeks ago, and it worked fine.
I'm not sure if its worth investigating to maintain two Xcode project files, just for that. If one really
wants it, its possible with this trick.

Cheers,
Niko
Martin Robinson | 3 Jan 19:03 2012

Re: Tools/Scripts/build-webkit --gtk --debug --makeargs="-j1" taking up to 80% of memory

On Mon, Jan 2, 2012 at 7:20 PM, Soo-Hyun Choi <s.choi <at> computer.or.kr> wrote:
> I have tried GNU gold linker (Version: 2.20.1-3ubuntu7.1) on Ubuntu
> 10.04 (32-bit) without success. Could you let us know how you have
> been successful to build WebKit Debug on 32-bit machines in more
> detail? I have tried building Efl Debug, by the way.

Another thing you could try is to do a clean build using thin
archives. First remove your build directory and then run the following
in a fresh build directory.

$ AR_FLAGS="cruT" ../../autogen.sh
$ make

--Martin
David Hyatt | 3 Jan 21:41 2012
Picon

Re: Making overflow clipping cheaper

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. In the future I envision overflow sections being more justified in having
layers by virtue of the fact that they would always be composited. In a non-composited world, I can see why
you might be tempted to yank overflow functionality out of RenderLayer, but in a composited world, having
RenderLayers created for these objects makes more sense.

dave
(hyatt <at> apple.com)

On Dec 29, 2011, at 5:49 PM, Julien Chaffraix wrote:

>> Wouldn't it be better to implement better searching and paint-segmentation in
>> RenderLayers then? It could also provide the same speed up for many other big
>> cases.
> 
> That would be worth investigating more for sure (do you mind filing a
> bug about it?). The paint search and segmentation algorithm is very
> close between RenderLayer and most RenderObjects - tables being an
> exception here as their structure enables better searching algorithms
> - which means that it would benefit everyone. I haven't spend enough
> time looking at generic scalability issues to say if there won't be
> others more important bottlenecks.
> 
> I still see some upsides in attacking the reduced use case of overflow
> clips independently of what you are proposing:
> * RenderLayer has become a class handling far too many tasks so moving
> some functionality out of it is good by itself.
> * RenderObject has a better knowledge of its own structure, something
> as generic as RenderLayer would not need to be aware of.
> 
> Thanks,
> Julien
> _______________________________________________
> webkit-dev mailing list
> webkit-dev <at> lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Eric Seidel | 3 Jan 22:45 2012

Seeking Reproductions

We've had several reports of hitting an ASSERT I added back in
November (relating to plugin creation):
https://bugs.webkit.org/show_bug.cgi?id=50312

Unfortunately, none of them reproduce for me.  They're likely all
caused by certain flash ads on those pages (which are certainly
changed by now).

If anyone hits this ASSERT, I would very much appreciate an update on
the bug (with url).

Thank you.

-eric
Adam Barth | 4 Jan 00:00 2012

chromium-cg-mac results

Hi Elliot,

It looks like Chromium Mac has successfully moved to Skia.  Should we
remove the CG expectations for the Chromium Mac port?

Thanks,
Adam

Gmane