Re: [webkit-dev] Frédéric Wang is now a WebKit reviewer

[Gyuyoung Kim]

Congratulation Fred 

Gyuyoung.

On Tue, Sep 26, 2017 at 9:57 AM, Mark Lam  wrote:

> Hi everyone,
>
> I would like to announce that Frédéric Wang (nick: fredw) is now a WebKit
> reviewer.  Frédéric has worked on MathML, frame sandboxing, and scrolling.
> He is also a committer in Gecko and Chromium projects.  Please congratulate
> him, and send him some patches to review.
>
> Thanks.
>
> Mark
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] EFL port?

[Gyuyoung Kim]

Hi Konstantin and Gustavo,

I'm gonna upload latest WebKit source code to the repo.
Let me use the methods you guys recommend(script or git command) in order
to make EFL tarball.

Gyuyoung.


On Thu, Feb 16, 2017 at 12:18 AM, Gustavo Sverzut Barbieri <
barbi...@profusion.mobi> wrote:

> On Wed, Feb 15, 2017 at 12:48 PM, Konstantin Tokarev <annu...@yandex.ru>
> wrote:
> >
> >
> > 15.02.2017, 17:18, "Gustavo Sverzut Barbieri" <barbi...@profusion.mobi>:
> >> On Wed, Feb 15, 2017 at 3:19 AM, Gyuyoung Kim <gyuyoung@webkit.org>
> wrote:
> >>>  Hi,
> >>>
> >>>  If there is no other active maintainer for EFL port, unfortunately I
> have to
> >>>  agree to drop EFL port in mainline
> >>>  because EFL port should not be an obstacle. I will maintain WebKitEFL
> like
> >>>  the QT port in
> >>>  https://github.com/Gyuyoung/ewebkit and http://www.ewebkit.org.
> >>
> >> Okay, we can continue based on that.
> >>
> >> Just a small observation for your fork is to avoid releases to remove
> >> non-EFL port files like was done for 1.18, instead keep just our
> >> patchset on top and if you want to produce smaller archives just use
> >> git-archive ignore files (which can be in the git repo)... likely good
> >> to produce smaller downloads without layouttests and the likes.
> >
> > There is small but very useful script, Tools/gtk/make-dist.py. It allows
> to remove
> > unwanted files by using patterns, listed in manifests file (like
> Tools/gtk/manifest.txt.in)
> >
> > For Qt port I use this script both to make release tarballs and for
> snapshots repo [1].
> > This allows me to have full-fledged main repo with all tests and
> sources, and users
> > can clone small snapshots repo to get latest updates.
> >
> > [1] https://github.com/annulen/qtwebkit-snapshots
>
> well, cpack could do that kind of stuff, no? I recall the first port
> of cmake used that.
>
> I'm not sure why Gyuyoung did that approach, likely to get the
> tarballs-from-git-tags feature of github in a lightweight mode... then
> using git-archive features may do (it's kinda of simple to blacklist
> tests stuff and slim the tarball to 50mb or so)
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN, GTalk, FaceTime: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (16) 99354-9890
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] EFL port?

[Gyuyoung Kim]

Hi,

If there is no other active maintainer for EFL port, unfortunately I have
to agree to drop EFL port in mainline
because EFL port should not be an obstacle. I will maintain WebKitEFL like
the QT port in
https://github.com/Gyuyoung/ewebkit and http://www.ewebkit.org.

Gyuyoung.

On Wed, Feb 15, 2017 at 6:25 AM, Alex Christensen 
wrote:

>
> Konstantin Tokarev maintains a Qt port at https://github.com/annulen/
> webkit - sounds like you could do something like that.
>
> We have accepted the upstreaming of many patches from this repository into
> WebKit.  That reduces Konstantin’s maintenance burden and makes WebKit
> better organized without holding back our development.
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] EFL port?

[Gyuyoung Kim]

Hi,

I agree that we should have enough people to keep EFL port on upstream.

Unfortunately I guess there will be no enough people to maintain EFL port
even If I've done my internal work.
So, If other maintainers or volunteers put their hand up for EFL port, it
seems to me that EFL port has a time to go downstream.

Gyuyoung.


On Tue, Feb 14, 2017 at 3:35 AM, Alex Christensen <achristen...@apple.com>
wrote:

> Are there enough people working on EFL that we could ping someone with a
> desired architecture improvement and have them do significant code redesign
> in a reasonable amount of time?  We can add stubs and do minor things
> blindly, but sometimes bigger tasks require cooperation.  For example,
> https://bugs.webkit.org/show_bug.cgi?id=167096 should also be done on the
> EFL WebGL implementation.
>
> On Feb 13, 2017, at 3:08 AM, Gustavo Sverzut Barbieri <
> barbi...@profusion.mobi> wrote:
>
> Hi guys,
>
> I have a small team working with WebKit-EFL as well, we're working on
> a different platform supported by EFL but not WebKit-EFL, so it's a
> series of minor patches to allow WebKit-EFL to run on Fbdev and
> without GL stack.
>
> Patches will reach bugs.webkit.org soon.
>
>
> On Sat, Feb 11, 2017 at 2:10 AM, Joonghun Park <sypjh0...@hotmail.com>
> wrote:
>
> Hi, Anders.
>
>
> You could count me as a member of EFL port too.
>
> I couldn't get in touch with EFL port because of some internal works,
>
> but I'm planning to work in it.
>
>
> Some other people of EFL port is in the same situation, but I think they'll
> get back sooner or later.
>
>
>
> - Joonghun (jh718.p...@samsung.com)
>
>
>
>
> 
> From: webkit-dev-boun...@lists.webkit.org
> <webkit-dev-boun...@lists.webkit.org> on behalf of Anders Carlsson
> <ander...@apple.com>
> Sent: Friday, February 10, 2017 6:21 PM
> To: Gyuyoung Kim
> Cc: WebKit-Dev Development
> Subject: Re: [webkit-dev] EFL port?
>
> Hi,
>
> Are you the only one working on the EFL port?
>
> - Anders
>
> On Feb 10, 2017, at 1:40 AM, Gyuyoung Kim <gyuyoung@webkit.org> wrote:
>
> Hello,
>
> To be honest, very few people have worked for EFL port recently. In my case
> it was hard to maintain EFL port because of internal work.
> However I have a plan to improve EFL port after I finish the work. Even I
> opened a website for EWebKit. http://www.ewebkit.org.
> Besides I released EWebKit 1.18 version[1] for EFL 1.18 official release.
> Could you give me more time for EFL port ?
>
> Gyuyoung.
>
>
> [1] EWebKit 1.18 release announcement.
>
> https://phab.enlightenment.org/w/efl_and_elementary_1_18_
> release_announcement/
>
> EWebkit
>
> Together with this release we are happy to announce that the EWebkit team
> is
> doing a
> release with their work matching the efl 1.18.
> It contains various webkit core as well as EWebkit specific enhancements.
> See the
> NEWS file for details and the http://www.ewebkit.org page for further
> instructions on
> building. We hope to keep future releases of EWebkit aligned with the EFL
> release schedule.
>
>
>
>
>
>
>
> On Fri, Feb 10, 2017 at 9:42 AM, Anders Carlsson <ander...@apple.com>
> wrote:
>
>
> Hello,
>
> Looks like the EFL port isn’t really being worked on anymore. Is this
> true? Can we rip it out?
>
> - Anders
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN, GTalk, FaceTime: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (16) 99354-9890
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] EFL port?

[Gyuyoung Kim]

Hello,

To be honest, very few people have worked for EFL port recently. In my case
it was hard to maintain EFL port because of internal work.
However I have a plan to improve EFL port after I finish the work. Even I
opened a website for EWebKit. http://www.ewebkit.org.
Besides I released EWebKit 1.18 version[1] for EFL 1.18 official release.
Could you give me more time for EFL port ?

Gyuyoung.


[1] EWebKit 1.18 release announcement.

https://phab.enlightenment.org/w/efl_and_elementary_1_18_release_announcement/
EWebkit

Together with this release we are happy to announce that the EWebkit team
is doing a
release  with
their work matching the efl 1.18.
It contains various webkit core as well as EWebkit specific enhancements.
See the
NEWS file  for
details and the http://www.ewebkit.org page for further instructions on
building. We hope to keep future releases of EWebkit aligned with the EFL
release schedule.






On Fri, Feb 10, 2017 at 9:42 AM, Anders Carlsson  wrote:

> Hello,
>
> Looks like the EFL port isn’t really being worked on anymore. Is this
> true? Can we rip it out?
>
> - Anders
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Proposal: Remove Battery Status API code

[Gyuyoung Kim]

Hi Brady,

The battery status API has been used by EFL port so far. As far as I know
the feature was added to support
web application. But I'm not sure how many web applications have used it so
far.(Personally I guess it might be
used by few applications.) Besides  unfortunately nobody maintains it now.
If there is concern to keep the feature
and other ports don't want to use it anymore, It looks I can't object to
remove it.

Gyuyoung.

On Mon, Oct 31, 2016 at 9:54 AM, Simon Fraser 
wrote:

> I support the proposal to remove.
>
> Simon
>
> > On Oct 30, 2016, at 5:14 PM, Brady Eidson  wrote:
> >
> >
> > There's code in the tree to support the W3C Battery Status API.
> >
> > A recent study showed the extent of the risk (discussion and link to
> study https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.
> lukaszolejnik.com_battery-2Dstatus-2Dreadout-2Das-2Da-
> 2Dprivacy-2Drisk_=CwICAg=Hw-EJUFt2_D9PK5csBJ29kRV40HqSDXWTLPyZ6W8
> u84=gEUmSR3VtC-5Q3Im6T2Js1aXwjJK4RExonGEvDq2twI=
> ZKSbJXtXvUd44zKls9LfZwY1fsH0NRSg8KxOY7clZdI=8c9qMq7SAf9mAh8t9oHbJE45_
> tXRsbZBMid46hd9UXs= ) which led to Mozilla first making the API less
> precise (https://bugzilla.mozilla.org/show_bug.cgi?id=1124127) but then
> eventually removing it altogether (https://bugzilla.mozilla.org/
> show_bug.cgi?id=1313580)
> >
> > Apple has never enabled this on their ports, one reason being concern
> for abuse in fingerprinting/tracking.
> > The study seems to be a strong second opinion backing this concern.
> > Mozilla's actions demonstrate another vendor not seeing the API being
> useful enough to outweigh the user concern.
> >
> > As one of the voices for Apple's ports I think the above episode further
> cements our concern in ever enabling the API.
> >
> > As one of the voices for WebKit as a whole I think above episode
> suggests we should just remove the code from the tree altogether.
> >
> > What to other Apple folks think? What do port maintainers who enable the
> API think?
> >
> > Thanks,
> > ~Brady
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] On/Off selection gap painting during the text selection

[Gyuyoung Kim]

Hi Rego,

Thank you for pointing issues out when removing gaps painting. The issues
probably heads up
when gaps painting is disabled. In newline issue case, I'm able to refer to
the chrome's fix. Let me check it.
In second issue case, although it looks there is no critical issue with new
layout methods yet
I think I need to check it further. But the issues won't appear on port
which uses gaps painting.

gyuyoung.

On Tue, May 3, 2016 at 10:58 PM, Manuel Rego Casasnovas <r...@igalia.com>
wrote:

> Hi,
>
> On 03/05/16 15:24, Gyuyoung Kim wrote:
> > I upload a patch to add a preference API in order to enable/disable the
> > selection gap painting feature.
>
> BTW, this has been removed from Chrome too past year:
>
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/6Iu5oIbAGbI/PsJlNvJPhfMJ
>
> Note that in the discussion they pointed to an issue that happens when
> you remove gaps paining, you don't know if you've selected a newlines or
> not: https://bugs.chromium.org/p/chromium/issues/detail?id=474759
>
> > Add WKPreference for SelectionPaintingWithoutSelectionGaps
> > https://bugs.webkit.org/show_bug.cgi?id=156900
>
> As pointed out by Darin on the bug, an issue with selection gaps is what
> happens with the new layout methods like Flexbox and specially Grid
> Layout, where the visual order and the DOM order can be completely
> different.
>
> My 2 cents,
>   Rego
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Joanmarie Diggs is now a WebKit reviewer

[Gyuyoung Kim]

Congrats Joanmarie !

Gyuyoung.

On Tue, Mar 29, 2016 at 2:38 AM, Mark Lam  wrote:

> Hi everyone,
>
> Just want to announce that Joanmarie Diggs is now a reviewer.  Joanmarie
> primarily works on GTK accessibility and is a current editor of the ARIA
> spec (https://www.w3.org/TR/wai-aria-1.1/).
>
> Congratulations, Joanmarie.
>
> Mark
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Please enable the SVG -> OTF Font Converter on your port!

[Gyuyoung Kim]

EFL patch is done ! If EFL needs to do rebaseline after landing EFL patch
[2], let me do it.

Gyuyoung.

On Wed, Mar 9, 2016 at 6:57 AM, Myles C. Maxfield 
wrote:

> Hello!
>
> As of r197145, the SVG -> OTF Font Converter is enabled on the OS X, iOS,
> and Apple Windows ports. This converter replaces our old, invasive,
> error-prone, and security-hole-ridden SVG font support in WebKit. The
> converter is much faster (read: at least 3 orders of magnitude) and
> produces much better results (subpixel-antialiased text) than the old code
> path, as well as having significantly fewer security vulnerabilities.
>
> As soon as we get all the ports on the converter, I’d love to be able to
> delete all the old code. However, GTK and EFL are still using the old code
> path. Turning the converter on should be simple: I’ve posted patches for
> GTK [1] and EFL [2] to flip the switch. Note that some tests may need to be
> rebaselined; the underlying graphics system will likely provide differently
> quantized glyph metrics than the existing code path. There are also some
> known bugs; if you want to learn more about them, please feel free to reach
> out to me.
>
> Please reply by Tuesday, March 15 so I can go ahead with this project!
>
> Thanks!
>
> 1. https://bugs.webkit.org/show_bug.cgi?id=155191
> 2. https://bugs.webkit.org/show_bug.cgi?id=155192
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Removing ENABLE(DATA_TRANSFER_ITEMS)

[Gyuyoung Kim]

Chris and Alexey seem to want to keep the feature because it is part of w3c
spec. I don't want to remove it if someone has any plan to use|enable it in
future.

Gyuyoung.

On Sat, Jan 30, 2016 at 2:51 AM, Chris Dumez <cdu...@apple.com> wrote:

> Hi,
>
> It is part of the HTML specification:
>
> https://html.spec.whatwg.org/multipage/interaction.html#the-datatransferitemlist-interface
> https://html.spec.whatwg.org/multipage/interaction.html#datatransferitem
>
> Chrome seems to support it. It is also covered by the W3C web-platform
> tests.
> Should we work on enabling this feature rather than removing it?
>
> Kr,
> --
>  Chris Dumez
>
>
>
>
> On Dec 21, 2015, at 10:02 PM, Gyuyoung Kim <gyuyoung@webkit.org>
> wrote:
>
> Hello,
>
> It looks like no ports have used a data transfer items feature. Even the
> feature hasn't been updated since 2011. If anyone doesn't have a plan to
> use it in future, I plan to remove it. Any objections ?
>
> Gyuyoung.
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Xabier Rodriguez-Calvar and Michael Catanzaro are now WebKit reviewers

[Gyuyoung Kim]

Congrats Xabier and Michael !

Gyuyoung.

On Wed, Dec 23, 2015 at 2:58 AM, Mark Lam  wrote:

> Hi everyone,
>
> With pleasure, I would like to announce that Xabier Rodriguez-Calvar and
> Michael Catanzaro are now WebKit reviewers.
>
> Congratulations to Xabier and Michael.
>
> Mark
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Removing ENABLE(DATA_TRANSFER_ITEMS)

[Gyuyoung Kim]

> DataTransfer.items is part of the spec, so it seems like we should
support it. Are you saying that the code that's currently in trunk is not
useful enough to help with eventually adding full support?

No, current implementation seems to support the spec. If some ports want to
use it, current implementation is enough to be useful. I meant that the
feature hasn't been maintained for a long time and nobody uses it now. But
if you have a plan to use it in future as well as supporting it, the
current implementation should be kept.

Gyuyoung.

On Wed, Dec 23, 2015 at 2:02 AM, Alexey Proskuryakov <
aproskurya...@gmail.com> wrote:

>
> 21 дек. 2015 г., в 22:02, Gyuyoung Kim <gyuyoung@webkit.org>
> написал(а):
>
> It looks like no ports have used a data transfer items feature. Even the
> feature hasn't been updated since 2011. If anyone doesn't have a plan to
> use it in future, I plan to remove it. Any objections ?
>
>
> DataTransfer.items is part of the spec, so it seems like we should support
> it. Are you saying that the code that's currently in trunk is not useful
> enough to help with eventually adding full support?
>
> - Alexey
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Removing ENABLE(DATA_TRANSFER_ITEMS)

[Gyuyoung Kim]

Hello,

It looks like no ports have used a data transfer items feature. Even the
feature hasn't been updated since 2011. If anyone doesn't have a plan to
use it in future, I plan to remove it. Any objections ?

Gyuyoung.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Mac CMake

[Gyuyoung Kim]

I succeed to build the Mac port with --cmake option locally. Great !

Gyuyoung.

On Sun, Nov 1, 2015 at 1:58 AM, Yusuke SUZUKI  wrote:

> Awesome!
>
> ---
> Regards,
> Yusuke Suzuki
>
> On Sat, Oct 31, 2015 at 6:32 AM, Geoffrey Garen  wrote:
>
>> 
>>
>> On Oct 30, 2015, at 2:17 PM, Alex Christensen 
>> wrote:
>>
>> I got the Mac CMake build to the point where it can compile and link
>> frameworks successfully.  We will get a buildbot up soon, but in the
>> meantime please try to add and remove files in the CMake build.Let me know
>> if you have any questions or concerns or want to help out.  I don’t think
>> it can be used to run Safari yet, but that’s hopefully coming soon.
>>
>> If you want to try it out, run this command:
>> Tools/Scripts/build-webkit --cmake
>>
>> Alex
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org
>> https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Lucas Forschler is now a WebKit reviewer

[Gyuyoung Kim]

Congrats ! Lucas.

Gyuyoung

On Fri, Sep 25, 2015 at 12:41 AM, Mark Lam  wrote:

> Hi everyone,
>
> Just want to announce that Lucas Forschler is now a reviewer.
> Congratulations, Lucas.
>
> Mark
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Svn server is very slow to get full code.

[Gyuyoung Kim]

Some my PCs also have same problem when using svn. I don't know why it is
too slow suddenly.

Gyuyoung.

On Tue, Aug 25, 2015 at 12:27 PM, 조진철 jincheol...@navercorp.com wrote:

 Hi webkit-dev.

 I am getting webkit full source through svn.
 But the svn server is so slow that I cannot get it.
 It looks like something wrong.

 WebKit-Git works as well.

 Could anybody check it?

 Thanks.
 ___

 Jincheol Jo
 Naver Labs / Software Engineer.


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


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

Re: [webkit-dev] Switching servers for EWS and flakiness dashboard

[Gyuyoung Kim]

Hi Aakash,

I will support to switch to the new server for efl-ews bots tomorrow.

Gyuyoung.

On Thu, Jul 30, 2015 at 4:10 PM, Aakash Jain aakash_j...@apple.com wrote:

 Hi All,

 We are planning to switch to new servers for two of the apps: EWS(
 webkit-queues.appspot.com) and flakiness dashboard (
 http://webkit-test-results.appspot.com/dashboards/flakiness_dashboard.html).
 It would be good to restart all the bots communicating with these apps to
 ensure that they switch to new server. We will be handling most of the
 bots, except the ones which we don't have the admin access to (e.g.:
 efl-wk2-ews and gtk-wk2-ews). It would be great if the admins for these
 bots can do the necessary.

 We plan to commit the patch to switch the servers tomorrow early afternoon
 (July 30, PST timezone) and restart the bots soon after. You can see more
 details at https://bugs.webkit.org/show_bug.cgi?id=147178

 For those who are interested in knowing more, we are switching the servers
 since Google is depreciating one of the datastore model : master/slave
 datastore (
 https://cloud.google.com/appengine/docs/deprecations/ms_datastore) which
 these Apps were using. Going forward, we will be using AppScale which is an
 open-source alternative to Google App Engine.

 Thanks
 Aakash

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

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

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

[Gyuyoung Kim]

The custom protocol handler feature of the WebKit2 API is for the
embedding native application to provide raw data to resource loads directly.
While tangentially related to how registerProtocolHandler would work for
some uses, there’s numerous differences.

If so, custom protocol handler feature is different with role of
registerProtocolHandler. Thank you for your explanation about it.


One key example: Since it was implemented for the native embedding
application (which is, of course, trusted) none of the normal web security
concerns have been taken into account.
Also, since they’re for special-use native apps instead of a general web
browser, none of Sam’s concerns had to be accounted for:

For more detailed scenario in addition to Brady's explanation, I consider
below call sequence to use registerProtocolHandler.

 1. Custom scheme is registered by registeredProtocolHandler() in JS
 2. The registered scheme will be filtering in WebCore. (If unsupported
scheme is requested, security error happens.)
 3. Filtered scheme will be passed to application side (of course, which is
web browser or similar things)
 4. The application will register passed custom scheme and a callback to
call the native embedding application to WK2's network
 using custom protocol handler feature, which was implemented in
WebKit2.

Thus, in my humble opinion, registerProtocolHandler will use the custom
protocol instead of complicating it.


Gyuyoung.

On Tue, Jul 7, 2015 at 1:56 AM, Brady Eidson beid...@apple.com wrote:


 On Jul 1, 2015, at 7:42 PM, Gyuyoung Kim gyuyoung@webkit.org wrote:

 WebKit2 already has a similar feature, which is so-called *custom
 protocol* enabled by Mac, Gtk and EFL ports. However the custom protocol
 feature supports to register custom scheme
 through API layer instead of JavaScript. The registerProtocolHandler() is
 to support to register the custom scheme by means of JavaScript. I don't
 know yet why we can't support to register it
 from JavaScript.


 The custom protocol handler feature of the WebKit2 API is for the
 embedding native application to provide raw data to resource loads directly.

 While tangentially related to how registerProtocolHandler would work for
 some uses, there’s numerous differences.

 One key example: Since it was implemented for the native embedding
 application (which is, of course, trusted) none of the normal web security
 concerns have been taken into account.

 Also, since they’re for special-use native apps instead of a general web
 browser, none of Sam’s concerns had to be accounted for:

 On Jul 4, 2015, at 10:24 AM, Sam Weinig wei...@apple.com wrote:

 My concern with the registerProtocolHandler() API is that it complicates
 an already the very complicated area of custom protocols and a good
 implementation requires configuration UI (to choose which of potentially
 multiple apps/websites you want a specific protocol to go to) that I am not
 sure users are in the position make.
 ...
 From an implementation perspective I also have concerns.  How is this
 should the registration data be managed? Can it fit in the WebSiteData
 model we are using for other data? Does it account for non-persistent
 sessions?  And lastly, can we get the code size of supporting a feature
 like this to be smaller?


 I’m not crafting this reply as an argument against
 registerProtocolHandler, but rather to dispel the notion that exposing WK2
 custom protocols” to JS is all we need to do to get registerProtocolHandler.

 ~Brady

 Gyuyoung.

 On Tue, Jun 16, 2015 at 10:43 AM, Gyuyoung Kim gyuyoung@webkit.org
 wrote:

 On Mon, Jun 8, 2015 at 9:39 AM, Darin Adler da...@apple.com wrote:

 Sam, Anders, you haven’t replied to the thread since Maciej made his
 remarks two weeks ago. He asked what you dislike about the API.


 It seems that some people hope to listen why you guys dislike about this
 API as well as I want.

 Gyuyoung.

 On Thu, Jun 11, 2015 at 10:06 AM, Gyuyoung Kim gyuyoung@webkit.org
 wrote:

 On Mon, Jun 8, 2015 at 12:02 PM, Michael Catanzaro 
 mcatanz...@igalia.com wrote:

 On Sun, 2015-06-07 at 17:39 -0700, Darin Adler wrote:
  As one next step in the discussion, is there anyone that wants to
  present a use case for a protocol other than mailto?

 irc:// would be useful for those who don't like desktop clients.


 geo: would be useful for people who want to use map application as
 well.

 Gyuyoung.



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



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

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

[Gyuyoung Kim]

On Mon, Jun 8, 2015 at 9:39 AM, Darin Adler da...@apple.com wrote:

 Sam, Anders, you haven’t replied to the thread since Maciej made his
 remarks two weeks ago. He asked what you dislike about the API.


It seems that some people hope to listen why you guys dislike about this
API as well as I want.

Gyuyoung.

On Thu, Jun 11, 2015 at 10:06 AM, Gyuyoung Kim gyuyoung@webkit.org
wrote:

 On Mon, Jun 8, 2015 at 12:02 PM, Michael Catanzaro mcatanz...@igalia.com
 wrote:

 On Sun, 2015-06-07 at 17:39 -0700, Darin Adler wrote:
  As one next step in the discussion, is there anyone that wants to
  present a use case for a protocol other than mailto?

 irc:// would be useful for those who don't like desktop clients.


 geo: would be useful for people who want to use map application as well.

 Gyuyoung.


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

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

[Gyuyoung Kim]

On Mon, Jun 8, 2015 at 12:02 PM, Michael Catanzaro mcatanz...@igalia.com
wrote:

 On Sun, 2015-06-07 at 17:39 -0700, Darin Adler wrote:
  As one next step in the discussion, is there anyone that wants to
  present a use case for a protocol other than mailto?

 irc:// would be useful for those who don't like desktop clients.


geo: would be useful for people who want to use map application as well.

Gyuyoung.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

[Gyuyoung Kim]

In order to support the use case on Epiphany browser, we need to support
this feature on WK2 first.
Besides, as far as I know, EFL browser will have similar use-case by using
this feature. Thus, in my humble opinion, similar use cases
can be more required in near future.

Gyuyoung.

On Tue, Jun 2, 2015 at 9:21 PM, Michael Catanzaro mcatanz...@igalia.com
wrote:

 On Wed, 2015-05-20 at 10:31 +0900, Gyuyoung Kim wrote:
  I would like to listen what do you think to support
  'registerProtocolHandler' in WebKit2.
 
  This feature is to execute web content through registered custom
  protocol.

 Hi,

 I think this would be useful for GNOME. One of our goals is for the
 user to be able to set GMail as the default mail application in System
 Settings. If the user visits gmail.com and it attempts to register
 itself as a mailto:// handler, I envision the WebKitGTK+ would fire a
 signal that would trigger Epiphany to display an info bar to ask the
 user for approval. If the user approves the registration, we would go
 one step further: we'd create a new web application for GMail and in
 the desktop file indicate support for the MIME type x-scheme
 -handler/mailto (or if the user already has a GMail web application,
 modify the desktop file to add that MIME type). The user would then be
 able to set the GMail web app as the default mail application
 systemwide.

 We would restrict this functionality to HTTPS sites only. I'd greatly
 prefer that restriction to be enforced by WebKit rather than
 implementing that policy in Epiphany.

 Michael
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

[Gyuyoung Kim]

It seem to me there are both agreements and objections to support this
feature in WebKit2.
It looks many web contents have already used some custom schemes as
'mailto://',
and In my humble opinion, the feature
will be able to improve the usage of the custom scheme. Besides we can
control the supported custom schemes because
the feature only supports pre-defined custom schemes. Web content is only
able to use the pre-defined custom schemes.
In my opinion, it would be good if the feature is supported by WebKit2
although it is added as an experimental feature using #ifdef.

However If WK2 owners still think this feature needs to be more stable, I
will wait until they agree it.

Gyuyoung.

On Sat, May 23, 2015 at 12:36 PM, Gyuyoung Kim gyuyoung@webkit.org
wrote:

 Hi Anne,

 I need to verify the behaviour using the patch though, I think the
 registered URL isn't fetched under current patch of Bug 92749.
 However I need to check if the registered URL is passed to application
 under the patch's implementation. If this feature will be landed to WK2,
 it would be good if we add a test to check it. Let me do it.

 Gyuyoung.

 On Sat, May 23, 2015 at 9:55 AM, Anne van Kesteren ann...@annevk.nl
 wrote:

 On Fri, May 22, 2015 at 6:43 PM, Gyuyoung Kim gyuyoung@webkit.org
 wrote:
  Current implementation doesn't hook to HTML's navigation directly. We
  delegate the html navigation(or call native application) to application.
  Application is able to decide to navigate the given html page or execute
  native application through the patch. As far as I know, Chrome also has
  similar implementation.

 Okay, so

   img src=mailto:...

 results in a network error and not a fetch to the registered URL?


 --
 https://annevankesteren.nl/



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

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

[Gyuyoung Kim]

Hi Anne,

I need to verify the behaviour using the patch though, I think the
registered URL isn't fetched under current patch of Bug 92749.
However I need to check if the registered URL is passed to application
under the patch's implementation. If this feature will be landed to WK2,
it would be good if we add a test to check it. Let me do it.

Gyuyoung.

On Sat, May 23, 2015 at 9:55 AM, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, May 22, 2015 at 6:43 PM, Gyuyoung Kim gyuyoung@webkit.org
 wrote:
  Current implementation doesn't hook to HTML's navigation directly. We
  delegate the html navigation(or call native application) to application.
  Application is able to decide to navigate the given html page or execute
  native application through the patch. As far as I know, Chrome also has
  similar implementation.

 Okay, so

   img src=mailto:...

 results in a network error and not a fetch to the registered URL?


 --
 https://annevankesteren.nl/

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

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

[Gyuyoung Kim]

 Quickly scanning the bug I couldn't figure out whether you added hooks
 to HTML's navigate algorithm or Fetch' fetch algorithm. In particular,
 see the discussion in this bug:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=24091

 My personal opinion is that these schemes should only have an effect
 if you navigate to them, not if you fetch them (the latter should
 result in a network error in my opinion).

Current implementation doesn't hook to HTML's navigation directly. We
delegate the html navigation(or call native application) to application.
Application is able to decide to navigate the given html page or execute
native application through the patch. As far as I know, Chrome also has
similar implementation.

If this feature can be landed, I have a plan to test this scenario based on
mock implementation.

Gyuyoung.

On Fri, May 22, 2015 at 5:52 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, May 22, 2015 at 1:50 PM, Gyuyoung Kim gyuyoung@webkit.org
 wrote:
  I also don't want to support the content handler feature at the moment.
  The feature might be more clear and mature. The patch of Bug 92749 only
  supports registerProtocolHandler,
  and unregisterProtocolHandler and isProtocolHandlerRegistered are
 supported
  as optional.
 
   https://bugs.webkit.org/show_bug.cgi?id=92749

 Quickly scanning the bug I couldn't figure out whether you added hooks
 to HTML's navigate algorithm or Fetch' fetch algorithm. In particular,
 see the discussion in this bug:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=24091

 My personal opinion is that these schemes should only have an effect
 if you navigate to them, not if you fetch them (the latter should
 result in a network error in my opinion).


 --
 https://annevankesteren.nl/

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

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

[Gyuyoung Kim]

 Quickly scanning the bug I couldn't figure out whether you added hooks
 to HTML's navigate algorithm or Fetch' fetch algorithm. In particular,
 see the discussion in this bug:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=24091

 My personal opinion is that these schemes should only have an effect
 if you navigate to them, not if you fetch them (the latter should
 result in a network error in my opinion).

Current implementation doesn't hook to HTML's navigation directly. We
delegate the html navigation(or call native application) to application.
Application is able to decide to navigate the given html page or execute
native application through the patch. As far as I know, Chrome also has
similar implementation.

If this feature can be landed, I have a plan to test this scenario based on
mock implementation.

Gyuyoung.


On Fri, May 22, 2015 at 5:52 PM, Anne van Kesteren ann...@annevk.nl wrote:

 On Fri, May 22, 2015 at 1:50 PM, Gyuyoung Kim gyuyoung@webkit.org
 wrote:
  I also don't want to support the content handler feature at the moment.
  The feature might be more clear and mature. The patch of Bug 92749 only
  supports registerProtocolHandler,
  and unregisterProtocolHandler and isProtocolHandlerRegistered are
 supported
  as optional.
 
   https://bugs.webkit.org/show_bug.cgi?id=92749

 Quickly scanning the bug I couldn't figure out whether you added hooks
 to HTML's navigate algorithm or Fetch' fetch algorithm. In particular,
 see the discussion in this bug:

   https://www.w3.org/Bugs/Public/show_bug.cgi?id=24091

 My personal opinion is that these schemes should only have an effect
 if you navigate to them, not if you fetch them (the latter should
 result in a network error in my opinion).


 --
 https://annevankesteren.nl/

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

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

[Gyuyoung Kim]

Hi Benjamin,

 Looks llke nobody objects. Please make sure to #ifdef everything and
disable the feature on OS X and iOS.

Ok, let me add #ifdef guard for WK2 ports which don't use this feature.


There are already basic test cases for this feature. But I think this isn't
enough to test all use cases.
  -
http://trac.webkit.org/browser/trunk/LayoutTests/fast/dom/NavigatorContentUtils

After landing WK2 implementation, I'm going to improve the test cases or
add new tests for some use cases.

Thanks,
Gyuyoung.


On Thu, May 21, 2015 at 3:32 PM, Benjamin Poulain benja...@webkit.org
wrote:

  Looks llke nobody objects. Please make sure to #ifdef everything and
 disable the feature on OS X and iOS.

 What is your plan for testing?


 On 5/19/15 6:31 PM, Gyuyoung Kim wrote:

  Hello,

  I would like to listen what do you think to support
 'registerProtocolHandler' in WebKit2.

  This feature is to execute web content through registered custom
 protocol.
 - For example, web content can register mailto custom protocol using
 this feature,
 script
 navigator.registerProtocolHandler(mailto,
   https://mail.naver.com/;,
   Web Mail);
 /script

  html
 head
 titleWeb Protocol Handler Sample - Test/title
 /head
 body
 pSend an email : a href=mailto://;this !/a/p
 /body
 /html

  Besides this feature has been supported by Mozilla and Chromium (From
 Mozilla 3.0, Chromium 13).
   -
 https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler
   - https://developer.mozilla.org/en/docs/Web-based_protocol_handlers

  The feature is included in the W3C recommendation 28 released on Oct.
 2014.
   - W3C spec : http://www.w3.org/TR/html5/webappapis.html#custom-handlers

  IIRC, some WebKit1 ports supported this feature though, those ports were
 deprecated. Now WebKit port supports this feature no more.

  There is a very old bug to support this feature though, it wasn't
 maintained so far. Recently I updated it based on latest WebKit.
 - https://bugs.webkit.org/show_bug.cgi?id=92749

  Feel free to give me any feedback about this feature.

  Gyuyoung.


 ___
 webkit-dev mailing 
 listwebkit-dev@lists.webkit.orghttps://lists.webkit.org/mailman/listinfo/webkit-dev



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


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

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

[Gyuyoung Kim]

Hi Anders,

yes, Sam didn't like to support this feature. However, as I said, I think
this feature has been shipped by Firefox and Chrome browsers.
Besides It seems to me that web application will need to use this feature
in near future. However I know we can't support new feature
without WK2 owner's agreement.

I wonder if it is impossible to add new feature to WK2 as an experimental
feature with #ifdef guard or other better method.

Gyuyoung.

On Fri, May 22, 2015 at 1:25 AM, Anders Carlsson ander...@apple.com wrote:


 On May 20, 2015, at 11:32 PM, Benjamin Poulain benja...@webkit.org
 wrote:

  Looks llke nobody objects.


 That’s not true. From the bug:

 Sam Weinig s...@webkit.org 2015-05-15 10:12:54 PDT

 Support for navigator.registerProtocolHandler/unregisterProtocolHandler is 
 not something we want to support in WebKit2 at this time as we are not 
 confident it is a good Web API. This might be a good conversation for 
 webkit-dev.



 I agree with Sam.

 - Anders



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


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

Re: [webkit-dev] Support registerProtocolHandler in WebKit2

[Gyuyoung Kim]

On the face of it, the registerProtocolHandler API seems more general than
necessary, but the actual spec for it has a whitelist of specific schemes,
most of which seem reasonable for this kind of purpose:
https://html.spec.whatwg.org/#custom-handlers

Yes, the custom-handlers specification only allows us to use specific
schemes, and current WebCore implementation was implemented based on the
spec.
Current supported schemes are only below,

bitcoin, geo, im, irc, ircs, magnet, mailto, mms,
news, nntp, sip, sms, smsto, ssh, tel, urn, webcal,
wtai, xmpp


 (I am more dubious of the content handler aspect.)

Agreed, especially as it requires the service to download the resource
again. For that use case we need something smarter where you can pass
along an object/stream of sorts I think.

I also don't want to support the content handler feature at the moment.
The feature might be more clear and mature. The patch of Bug 92749 only
supports registerProtocolHandler,
and unregisterProtocolHandler and isProtocolHandlerRegistered are supported
as optional.

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

Gyuyoung.


On Fri, May 22, 2015 at 12:50 PM, Anne van Kesteren ann...@annevk.nl
wrote:

 On Fri, May 22, 2015 at 12:26 PM, Maciej Stachowiak m...@apple.com wrote:
  (I am more dubious of the content handler aspect.)

 Agreed, especially as it requires the service to download the resource
 again. For that use case we need something smarter where you can pass
 along an object/stream of sorts I think.


 --
 https://annevankesteren.nl/
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] Support registerProtocolHandler in WebKit2

[Gyuyoung Kim]

Hello,

I would like to listen what do you think to support
'registerProtocolHandler' in WebKit2.

This feature is to execute web content through registered custom protocol.
- For example, web content can register mailto custom protocol using this
feature,
script
navigator.registerProtocolHandler(mailto,
  https://mail.naver.com/;,
  Web Mail);
/script

html
head
titleWeb Protocol Handler Sample - Test/title
/head
body
pSend an email : a href=mailto://;this !/a/p
/body
/html

Besides this feature has been supported by Mozilla and Chromium (From
Mozilla 3.0, Chromium 13).
  -
https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler
  - https://developer.mozilla.org/en/docs/Web-based_protocol_handlers

The feature is included in the W3C recommendation 28 released on Oct. 2014.
  - W3C spec : http://www.w3.org/TR/html5/webappapis.html#custom-handlers

IIRC, some WebKit1 ports supported this feature though, those ports were
deprecated. Now WebKit port supports this feature no more.

There is a very old bug to support this feature though, it wasn't
maintained so far. Recently I updated it based on latest WebKit.
- https://bugs.webkit.org/show_bug.cgi?id=92749

Feel free to give me any feedback about this feature.

Gyuyoung.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] *.webkit.org network issues

[Gyuyoung Kim]

Hi,

I also couldn't get any bugzilla mail 2 hours ago in Korea. But now I
got bugzilla mails as Michael.
Problems look like resolved !

Gyuyoung.

On Tue, May 19, 2015 at 8:34 AM, Michael Catanzaro mcatanz...@igalia.com
wrote:

 On 05/18/2015 03:37 PM, Michael Catanzaro wrote:

 I haven't noticed any network issues, but I've had no mail from Bugzilla
 since Saturday, which seems highly improbable.

 I just got all the (backdated) bugmail within the past hour or two, so I
 guess that problem's been resolved.

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

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

Re: [webkit-dev] Proposal: Remove TextureMapperImageBuffer

[Gyuyoung Kim]

Hello Martin,

I and Ossy have maintained EFL bots and EWS so far. Recently WebGL feature
has been broken on EFL port since we bumped EFL version to 1.11.2. That's
why we skipped to run WebGL tests on EFL layout test. -
https://trac.webkit.org/changeset/167345.

But, unfortunately I'm not sure when we can fix it for EFL port. Thus I
agree to disable the accelerated compositing and skip related tests
in order not to block your work.

If any EFL folks know better solution for now, please let us know.

Gyuyoung.

On Fri, Apr 24, 2015 at 5:38 AM, Martin Robinson mrobin...@webkit.org
wrote:

 I'd love to coordinate with whoever is running the EFL bots to get a
 configuration that can run these tests with OpenGL. The WebKitGTK+
 bots use llvmpipe to make this happen.

 --Martin

 On Thu, Apr 23, 2015 at 1:15 PM, Benjamin Poulain benja...@webkit.org
 wrote:
  It seems undesirable to use a completely different stack for testing and
 for
  shipping.
 
  Wouldn't it be possible to use Mesa on the EFL bots?
 
 
  On 4/23/15 12:10 PM, Martin Robinson wrote:
 
  A slight update on this issue. It's already been attempted here:
  https://bugs.webkit.org/show_bug.cgi?id=143561
 
  The issue is that WebKitEFL is using the TextureMapperImageBuffer to
  run tests on their bots, because the EFL bots don't support OpenGL
  tests. My suggestion is that we disable accelerated compositing
  completely for WebKitEFL (if possible) and skip those tests. Once the
  bots have the ability to run tests that use OpenGL, we can re-enable
  that code path for WebKitEFL.
 
  --Martin
 
  On Thu, Apr 23, 2015 at 11:12 AM, Martin Robinson mrobin...@webkit.org
 
  wrote:
 
  Background: There currently exists a fallback TextureMapper
  implementation that does not use OpenGL to composite and project
  layers, but instead relies on 2D rasterization. This does not work
  correctly for Cairo, since Cairo only supports affine transformations.
  I believe this path is only used by GTK+ (and perhaps WinCairo) now.
 
  Proposal: I would like to remove TextureMapperImageBuffer and make
  TextureMapperGL the only implementation of TextureMapper. Not only
  will this simplify the code, it will remove a build flag
  (TEXTURE_MAPPER_GL). The current path isn't (or really shouldn't) be
  enabled by default.
 
  Please speak up if you are opposed. :)
 
  --Martin
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] WebCore/platform standalone library

[Gyuyoung Kim]

Platform Interface and Testing Abstraction.

- R. Niwa

*P*latform *A*bstract *I*nterface ? Sound like delicious pie :)

Gyuyoung


On Sat, Mar 21, 2015 at 2:18 AM, Ryosuke Niwa rn...@webkit.org wrote:



 On Friday, March 20, 2015, Simon Fraser simon.fra...@apple.com wrote:

 On Mar 20, 2015, at 9:27 AM, Darin Adler da...@apple.com wrote:

  On Mar 19, 2015, at 2:49 PM, Maciej Stachowiak m...@apple.com wrote:
 
  This almost makes me want to suggest a jokey name for Platform. I
 can’t off the top of my head think of a good expansion of OMG, though. Or
 BBQ.
 
  I am not a pro at this, but here are a few tries: Lower-level Object
 Library. Algorithm Reuse Framework. New Framework for WebCore, New System
 Framework for WebCore.

 Platform Obfuscation Source.


 Platform Interface and Testing Abstraction.

 - R. Niwa







 --
 - R. Niwa

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


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

Re: [webkit-dev] Running new/modified tests on EWS bots

[Gyuyoung Kim]

Hi,

Though I really like to support to run tests on EWS like Mac port, it can
often block to land a patch if tests on EFL or GTK aren't green. So I think
we need to find methods which don't annoy patch owner or reviewer. In this
light, if we're able to check if there is different between last test
result and new test result with a patch as Carlos suggested, it seems to be
more realistic approach. If someone tries to support it, I will also help
to try it If I can.

Gyuyoung.


On Fri, Mar 20, 2015 at 2:41 AM, Carlos Alberto Lopez Perez 
clo...@igalia.com wrote:

 On 19/03/15 16:46, youenn fablet wrote:
  Hi,
 
  Related to the webkit contributor meeting discussion related to ports,
  I would find it useful if EWS bots (gtk, efl, win, ios) were running
  the tests that are modified/created by a patch.
 
  The idea would be to turn yellow the port bubble whenever one of these
  tests do not pass. Results would be uploaded to bugzilla.
 
  This would give an incentive for patch developers to try fixing the
  tests on these ports.
  That may reduce (slightly? noticeably?) port maintainers gardening
 effort.
  That would also be valuable when importing test suites.
 
  Any potential issue? objection to move that forward?
  Anyone willing to help? Thoughts?
 

 I think that having an EWS running only the tests that the patch touches
 is of limited value because a patch can break unrelated tests.

 However running all the tests requires to have the tree green and this
 is not possible for GTK or EFL because it will require more manpower
 than the currently available.

 An idea that comes to mind for running all the tests without requiring
 to have the tree green is the following:

 1) EWS either run all the tests without the patch or download from
 https://build.webkit.org/results the results from the bot for the
 revision if they are available.
 2) EWS run all the tests with the patch.
 3) EWS gets the diff from 1. and 2.
 4) EWS runs only the tests that broke from 1 to 2 several times, in
 order to discard the ones that are flaky and only report the ones that
 on every run fail now.

 If I'm not overlooking something, I think that this would allow to
 identify what tests a given patch breaks and it won't require to have
 the tree green, neither it will be affected by flaky tests.


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


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

Re: [webkit-dev] Let's get bmalloc working on Linux (and delete TCMalloc)

[Gyuyoung Kim]

Hello Geoffrey,

EFL and GTK folks agreed that GTK port enables bmalloc first, then EFL port
will enable it after the bmalloc begins to support memory stats. Until
then, GTK port wants to refer to memory stats on EFL port one in the
meanwhile. However, as you commented on Bug 141247 Comment #2, if it is
hard to support memory stats on bmalloc at the moment, I agree to remove
TCMalloc first.

To help to go ahead, I upload a patch to enable bmalloc on EFL port as well
as to remove TCMaclloc in CMake.

Bug 141459 - [EFL] Enable bmalloc for EFL port.
https://bugs.webkit.org/show_bug.cgi?id=141459

Gyuyoung.

On Fri, Feb 13, 2015 at 9:35 AM, Geoffrey Garen gga...@apple.com wrote:

 It’s been about a month since I sent this notice, and it looks like
 bmalloc works on at least one version of Linux, so I’m going to remove
 TCMalloc in the next few days.

 Regards,
 Geoff

  On Jan 6, 2015, at 4:00 PM, Geoffrey Garen gga...@apple.com wrote:
 
  Hi folks.
 
  We’ve been using bmalloc on Mac and iOS for some time now, and it is
 fast and stable.
 
  Is there a Linux maintainer who would like to take on enabling bmalloc
 on Linux? The implementation is Unix-y, so it should “just work”. I can
 advise on this project, but I don’t have a Linux build  test environment.
 
  I plan to remove TCMalloc soon.
 
  Regards,
  Geoff

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

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

Re: [webkit-dev] Let's get bmalloc working on Linux (and delete TCMalloc)

[Gyuyoung Kim]

Hello Geoffrey,

Could you take a look Bug 140162 again ?

I hope to use bmalloc on EFL and GTK port soon.

Bug 140162 - [EFL][GTK] Use bmalloc instead of tcmalloc
https://bugs.webkit.org/show_bug.cgi?id=140162

Gyuyoung.

On Fri, Jan 9, 2015 at 3:44 PM, Gyuyoung Kim gyuyoung@webkit.org
wrote:

 Looks like nice improvement ! Let me try to use bmalloc for EFL port soon.

 Gyuyoung.


 On Friday, January 9, 2015, Geoffrey Garen gga...@apple.com wrote:

 From https://bugs.webkit.org/show_bug.cgi?id=132629:

 MallocBench result vs TCMalloc:

 geometric mean speedup: 2.11x faster
 biggest speedup (list_allocate): 4.09x faster

 Results from perf bots:

 OSMemoryTesting/Snap2FinishedLoadingPost:Allocations:Total: 0% (no 
 regression)

 PLT: 5%

 DOM/GetElement: 42.84%
 jslib-attr-jquery: 18.1%
 dromaeo-object-string: 13.3%
 dom-modify: 12.3%
 cssquery-jquery: 5%
 cssquery-prototype: 4.8%
 cssquery-dojo: 3.8%
 dromaeo-object-array: 3.4%
 jslib-style-jquery: 3.2%
 DYEB: 2.4%
 Parser/HTML5-8266-FullRender: 4%
 Parser/HTML5-8266-ParseOnly: 5.6%
 css-parser-yui: 10.2%
 Parser/html-parser: 6.5%
 Parser/textarea-parsing: 11.22%
 Layout/floats_100_100: 7.22%
 Layout/floats_100_100_nested: 9.32%
 Layout/floats_20_100: 11.42%
 Layout/floats_20_100_nested: 13.86%
 Layout/layers_overlap_2d: 6.69%
 Layout/auto-grid-lots-of-data: 4.3%
 Layout/chapter-reflow-once-random: 3.8%
 Layout/fixed-grid-lots-of-data: 5.92%
 Interactive/window-resize: 2%
 Animation/balls:FrameRate: 4%
 DOM/CloneNodes: 13.93%
 DOM/DOMDivWalk: 10.7%
 DOM/GetElement: 42.84%
 DOM/ModifyAttribute: 8.7%

 On Jan 7, 2015, at 4:51 PM, Gyuyoung Kim gyuyoung@webkit.org wrote:

 By the way, do you have any number how much is bmalloc faster than
 TCMalloc ?

 If you have it, could you let us know ?

 Gyuyoung

 On Wednesday, January 7, 2015, Gyuyoung Kim gyuyoung@webkit.org
 wrote:

 Hello Geoff,

 EFL port has used TCMalloc. To use bmalloc on EFL port, I file a new bug
 140162 for now.
 When patch is ready, I will upload it to the bug.

 Thanks,
 Gyuyoung

 On Wednesday, January 7, 2015, Geoffrey Garen gga...@apple.com wrote:

 Hi folks.

 We’ve been using bmalloc on Mac and iOS for some time now, and it is
 fast and stable.

 Is there a Linux maintainer who would like to take on enabling bmalloc
 on Linux? The implementation is Unix-y, so it should “just work”. I can
 advise on this project, but I don’t have a Linux build  test environment.

 I plan to remove TCMalloc soon.

 Regards,
 Geoff
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev



 --
 Sent from Gyuyoung Iphone



 --
 Sent from Gyuyoung Iphone




 --
 Sent from Gyuyoung Iphone

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

Re: [webkit-dev] EFL EWS bot failures [Caution: Message contains Suspicious URL content]

[Gyuyoung Kim]

Hi Ossy,

New machine's worked for EFL EWS since last night. I think it will be fine
to support EFL EWS.
https://webkit-queues.appspot.com/queue-status/efl-wk2-ews

If there is any similar issue on that, please let me know.

Gyuyoung.

On Thu, Jan 15, 2015 at 9:04 AM, Gyuyoung Kim gyuyoung@webkit.org
wrote:

 Hi Ossy,

 I restart EFL EWS now. It will be fine soon.  Anyway new machine is coming
 to me.
 I expect to use it until this weekend.

 Gyuyoung

 On Thu, Jan 15, 2015 at 8:48 AM, Osztrogonác Csaba o...@inf.u-szeged.hu
 wrote:

 EFL EWS is down since 16.5 hours. Any news about the upgrade?

 Gyuyoung Kim írta:

 Now I'm trying to replace a poor performance machine with new one.
 I hope EFL EWS bot will be fine soon.

 Thank you for your notification.
 Gyuyoung.

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



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

Re: [webkit-dev] EFL EWS bot failures [Caution: Message contains Suspicious URL content]

[Gyuyoung Kim]

Hi Ossy,

I restart EFL EWS now. It will be fine soon.  Anyway new machine is coming
to me.
I expect to use it until this weekend.

Gyuyoung

On Thu, Jan 15, 2015 at 8:48 AM, Osztrogonác Csaba o...@inf.u-szeged.hu
wrote:

 EFL EWS is down since 16.5 hours. Any news about the upgrade?

 Gyuyoung Kim írta:

 Now I'm trying to replace a poor performance machine with new one.
 I hope EFL EWS bot will be fine soon.

 Thank you for your notification.
 Gyuyoung.

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

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

Re: [webkit-dev] EFL EWS bot failures

[Gyuyoung Kim]

Hi Chris,

Now I'm trying to replace a poor performance machine with new one.
I hope EFL EWS bot will be fine soon.

Thank you for your notification.
Gyuyoung.

On Wed, Jan 14, 2015 at 9:09 AM, Chris Dumez cdu...@apple.com wrote:

 FYI, this still seems to be happening:
 https://webkit-queues.appspot.com/results/6182699735711744

 Kr,
 --
 Chris Dumez - Apple Inc.
 Cupertino, CA

 On Jan 9, 2015, at 6:55 AM, Gyuyoung Kim gyuyoung@webkit.org wrote:

 Hello Ossy,

 Now I'm running two machines for EFL EWS and buildbot. However one of the
 machines has poor performance.
 It looks the poor machine has caused this problem so far. Unfortunately
 I'm not able to replace it with new machine now.
 But let me try to replace/upgrade the poor performance machine in near
 future.

 Thank you for your effort and notification about this issue.

 br,
 Gyuyoung.


 On Fri, Jan 9, 2015 at 8:52 PM, Osztrogonác Csaba o...@inf.u-szeged.hu
 wrote:

 Hi Gyuyoung,

 thanks for fixing the bots.

 I noticed similar problem on the EFL EWS and buildbot many times.
 Unfortunately it can cause not only orange bubbles, but false
 positive redness too.

 I saw the same error long long time ago locally, and the reason
 was OOM on one of an overloaded icecc slave many times. And once
 a memory module error caused the same error.

 Nowadays I noticed another strange error on the EFL buildbot (2 or 3
 times):  kill old processes buildstep stucked in an infinite loop
 and killed after the 20 minutes timeout for several builds.

 Is there any chance to check and fix/replace the hardware of
 the EFL EWS and buildbot to make it as stable as previously?

 br,
 Ossy

 Gyuyoung Kim írta:

 Hello Darin,

 I'm sorry for the inconvenience about that. EFL EWS seems to work again.

 Gyuyoung.

 On Fri, Jan 9, 2015 at 4:02 AM, Darin Adler da...@apple.com mailto:
 da...@apple.com wrote:

 A lot of times recently the EFL bot has reported a failure that
 shows up as an orange bubble:

 c++: internal compiler error: Killed (program cc1plus)

 Like in this bug https://bugs.webkit.org/show_bug.cgi?id=140166.
 What's going on with that? Is there someone who can fix it?

 --- Darin

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


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



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

Re: [webkit-dev] EFL EWS bot failures

[Gyuyoung Kim]

Hello Ossy,

Now I'm running two machines for EFL EWS and buildbot. However one of the
machines has poor performance.
It looks the poor machine has caused this problem so far. Unfortunately I'm
not able to replace it with new machine now.
But let me try to replace/upgrade the poor performance machine in near
future.

Thank you for your effort and notification about this issue.

br,
Gyuyoung.


On Fri, Jan 9, 2015 at 8:52 PM, Osztrogonác Csaba o...@inf.u-szeged.hu
wrote:

 Hi Gyuyoung,

 thanks for fixing the bots.

 I noticed similar problem on the EFL EWS and buildbot many times.
 Unfortunately it can cause not only orange bubbles, but false
 positive redness too.

 I saw the same error long long time ago locally, and the reason
 was OOM on one of an overloaded icecc slave many times. And once
 a memory module error caused the same error.

 Nowadays I noticed another strange error on the EFL buildbot (2 or 3
 times):  kill old processes buildstep stucked in an infinite loop
 and killed after the 20 minutes timeout for several builds.

 Is there any chance to check and fix/replace the hardware of
 the EFL EWS and buildbot to make it as stable as previously?

 br,
 Ossy

 Gyuyoung Kim írta:

 Hello Darin,

 I'm sorry for the inconvenience about that. EFL EWS seems to work again.

 Gyuyoung.

 On Fri, Jan 9, 2015 at 4:02 AM, Darin Adler da...@apple.com mailto:
 da...@apple.com wrote:

 A lot of times recently the EFL bot has reported a failure that
 shows up as an orange bubble:

 c++: internal compiler error: Killed (program cc1plus)

 Like in this bug https://bugs.webkit.org/show_bug.cgi?id=140166.
 What's going on with that? Is there someone who can fix it?

 --- Darin

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

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

Re: [webkit-dev] Let's get bmalloc working on Linux (and delete TCMalloc)

[Gyuyoung Kim]

Looks like nice improvement ! Let me try to use bmalloc for EFL port soon.

Gyuyoung.

On Friday, January 9, 2015, Geoffrey Garen gga...@apple.com wrote:

 From https://bugs.webkit.org/show_bug.cgi?id=132629:

 MallocBench result vs TCMalloc:

 geometric mean speedup: 2.11x faster
 biggest speedup (list_allocate): 4.09x faster

 Results from perf bots:

 OSMemoryTesting/Snap2FinishedLoadingPost:Allocations:Total: 0% (no regression)

 PLT: 5%

 DOM/GetElement: 42.84%
 jslib-attr-jquery: 18.1%
 dromaeo-object-string: 13.3%
 dom-modify: 12.3%
 cssquery-jquery: 5%
 cssquery-prototype: 4.8%
 cssquery-dojo: 3.8%
 dromaeo-object-array: 3.4%
 jslib-style-jquery: 3.2%
 DYEB: 2.4%
 Parser/HTML5-8266-FullRender: 4%
 Parser/HTML5-8266-ParseOnly: 5.6%
 css-parser-yui: 10.2%
 Parser/html-parser: 6.5%
 Parser/textarea-parsing: 11.22%
 Layout/floats_100_100: 7.22%
 Layout/floats_100_100_nested: 9.32%
 Layout/floats_20_100: 11.42%
 Layout/floats_20_100_nested: 13.86%
 Layout/layers_overlap_2d: 6.69%
 Layout/auto-grid-lots-of-data: 4.3%
 Layout/chapter-reflow-once-random: 3.8%
 Layout/fixed-grid-lots-of-data: 5.92%
 Interactive/window-resize: 2%
 Animation/balls:FrameRate: 4%
 DOM/CloneNodes: 13.93%
 DOM/DOMDivWalk: 10.7%
 DOM/GetElement: 42.84%
 DOM/ModifyAttribute: 8.7%

 On Jan 7, 2015, at 4:51 PM, Gyuyoung Kim gyuyoung@webkit.org
 javascript:_e(%7B%7D,'cvml','gyuyoung@webkit.org'); wrote:

 By the way, do you have any number how much is bmalloc faster than
 TCMalloc ?

 If you have it, could you let us know ?

 Gyuyoung

 On Wednesday, January 7, 2015, Gyuyoung Kim gyuyoung@webkit.org
 javascript:_e(%7B%7D,'cvml','gyuyoung@webkit.org'); wrote:

 Hello Geoff,

 EFL port has used TCMalloc. To use bmalloc on EFL port, I file a new bug
 140162 for now.
 When patch is ready, I will upload it to the bug.

 Thanks,
 Gyuyoung

 On Wednesday, January 7, 2015, Geoffrey Garen gga...@apple.com wrote:

 Hi folks.

 We’ve been using bmalloc on Mac and iOS for some time now, and it is
 fast and stable.

 Is there a Linux maintainer who would like to take on enabling bmalloc
 on Linux? The implementation is Unix-y, so it should “just work”. I can
 advise on this project, but I don’t have a Linux build  test environment.

 I plan to remove TCMalloc soon.

 Regards,
 Geoff
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev



 --
 Sent from Gyuyoung Iphone



 --
 Sent from Gyuyoung Iphone




-- 
Sent from Gyuyoung Iphone
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] EFL EWS bot failures

[Gyuyoung Kim]

Hello Darin,

I'm sorry for the inconvenience about that. EFL EWS seems to work again.

Gyuyoung.

On Fri, Jan 9, 2015 at 4:02 AM, Darin Adler da...@apple.com wrote:

 A lot of times recently the EFL bot has reported a failure that shows up
 as an orange bubble:

 c++: internal compiler error: Killed (program cc1plus)

 Like in this bug https://bugs.webkit.org/show_bug.cgi?id=140166. What’s
 going on with that? Is there someone who can fix it?

 — Darin
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Let's get bmalloc working on Linux (and delete TCMalloc)

[Gyuyoung Kim]

By the way, do you have any number how much is bmalloc faster than TCMalloc
?

If you have it, could you let us know ?

Gyuyoung

On Wednesday, January 7, 2015, Gyuyoung Kim gyuyoung@webkit.org wrote:

 Hello Geoff,

 EFL port has used TCMalloc. To use bmalloc on EFL port, I file a new bug
 140162 for now.
 When patch is ready, I will upload it to the bug.

 Thanks,
 Gyuyoung

 On Wednesday, January 7, 2015, Geoffrey Garen gga...@apple.com
 javascript:_e(%7B%7D,'cvml','gga...@apple.com'); wrote:

 Hi folks.

 We’ve been using bmalloc on Mac and iOS for some time now, and it is fast
 and stable.

 Is there a Linux maintainer who would like to take on enabling bmalloc on
 Linux? The implementation is Unix-y, so it should “just work”. I can advise
 on this project, but I don’t have a Linux build  test environment.

 I plan to remove TCMalloc soon.

 Regards,
 Geoff
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev



 --
 Sent from Gyuyoung Iphone



-- 
Sent from Gyuyoung Iphone
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Let's get bmalloc working on Linux (and delete TCMalloc)

[Gyuyoung Kim]

Hello Geoff,

EFL port has used TCMalloc. To use bmalloc on EFL port, I file a new bug
140162 for now.
When patch is ready, I will upload it to the bug.

Thanks,
Gyuyoung

On Wednesday, January 7, 2015, Geoffrey Garen gga...@apple.com wrote:

 Hi folks.

 We’ve been using bmalloc on Mac and iOS for some time now, and it is fast
 and stable.

 Is there a Linux maintainer who would like to take on enabling bmalloc on
 Linux? The implementation is Unix-y, so it should “just work”. I can advise
 on this project, but I don’t have a Linux build  test environment.

 I plan to remove TCMalloc soon.

 Regards,
 Geoff
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org javascript:;
 https://lists.webkit.org/mailman/listinfo/webkit-dev



-- 
Sent from Gyuyoung Iphone
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Announcing WebKit for Wayland

[Gyuyoung Kim]

Hello,

 Do you know what are the plans for GTK and EFL?

As far as I know, EFL community has tried to support wayland. Thus some
folks of WebKit EFL port seem to plan to support the wayland based of EFL
support when it is ready.

Gyuyoung.

On Wednesday, December 10, 2014, Benjamin Poulain benja...@webkit.org
wrote:

 Hi Žan,

 Thanks for announcing this project here.

 Can you explain a bit why you decided to use the UIProcess directly inside
 the compositor?

 I am a bit concerned about the security of this model because the
 UIProcess becomes an attack vector for the compositor. Sharing the memory
 space with the compositor would prevent aggressive sandboxing.

 Great Wayland support seems like an important target for WebKit on Linux.
 Do you know what are the plans for GTK and EFL?

 Benjamin


 On 12/9/14 7:44 AM, Žan Doberšek wrote:

 Hi,

 now with proper formatting, Igalia is happy to announce the Wayland port
 of WebKit.

 This port avoids using traditional GUI toolkits in favor of directly
 operating with the Wayland display protocol. Leveraging the WebKit2
 multi-process architecture, the UIProcess is implemented as a shared
 library and loaded by the Wayland compositor, enabling the WebProcess to
 act as a direct client of the compositor while still being controlled by
 the UIProcess.

 EGL, the Wayland EGL platform, and OpenGL ES are used for
 hardware-accelerated compositing of the rendered Web content. GLib,
 Libsoup and Cairo are used under the hood.

 The port serves as a good base for building systems and environments
 that are mostly or completely relying on the Web platform technologies
 for building the desired interface.

 Overall the port is still in its early days, with some basic
 functionality (e.g. functional keyboard and mouse input support) and
 many other Web platform features still not supported. But with Wayland
 EGL support constantly growing in graphics drivers for different GPUs,
 it can already be tested on devices like the Raspberry Pi or the Jetson
 TK1 development board.

 In terms of supported Wayland compositors, for the moment we only
 support Weston (the reference Wayland compositor implementation), which
 is also used for development purposes. It's also used for running the
 layout tests by again pushing WebKitTestRunner functionality into a
 shared library, though all that is still in very early stages.

 The code is available on GitHub. There are also short instructions for
 building the dependencies and the port, and how to run it.
 https://github.com/WebKitForWayland/webkit

 There's also additional repositories there (for Cairo, Weston),
 containing changes that haven't yet been pushed upstream. In the
 following days we'll also be providing Buildroot configurations that can
 be used for cross-compiling the whole software stack for the supported
 hardware.

 We look forward to continuing evolving this work, enabling further
 features and improving performance on the software side and adding
 support for additional devices. As with all open-source projects,
 contributions are welcome.

 Regards,
 Zan Dobersek


 On Tue, Dec 9, 2014 at 7:28 AM, Žan Doberšek zandober...@gmail.com
 mailto:zandober...@gmail.com wrote:

 Hi,
 Igalia is happy to announce the Wayland port of WebKit.
 This port avoids using traditional GUI toolkits in favor of directly
 operating with the Wayland display protocol. Leveraging the WebKit2
 multi-process architecture, the UIProcess is implemented as a shared
 library and loaded by the Wayland compositor, enabling the
 WebProcess to act as a direct client of the compositor while still
 being controlled by the UIProcess.
 EGL, the Wayland EGL platform, and OpenGL ES are used for
 hardware-accelerated compositing of the rendered Web content. GLib,
 Libsoup and Cairo are used under the hood.
 The port serves as a good base for building systems and environments
 that are mostly or completely relying on the Web platform
 technologies for building the desired interface.
 Overall the port is still in its early days, with some basic
 functionality (e.g. functional keyboard and mouse input support) and
 many other Web platform features still not supported. But with
 Wayland EGL support constantly growing in graphics drivers for
 different GPUs, it can already be tested on devices like the
 Raspberry Pi or the Jetson TK1 development board.
 In terms of supported Wayland compositors, for the moment we only
 support Weston (the reference Wayland compositor implementation),
 which is also used for development purposes. It's also used for
 running the layout tests by again pushing WebKitTestRunner
 functionality into a shared library, though all that is still in
 very early stages.
 The code is available on GitHub. There are also short instructions
 for building the dependencies and the port, and how to run
 

Re: [webkit-dev] Is commit-queue broken ?

[Gyuyoung Kim]

commit-queue works again now. Someone seems to fix it.

Thanks,
Gyuyoung.

On Thu, Nov 27, 2014 at 11:07 AM, Tim Horton timothy_hor...@apple.com
wrote:

 I think the necessary emails have been sent to resolve it, but everyone is
 on vacation :(

 I can't commit manually either.

  On Nov 26, 2014, at 19:33, Gyuyoung Kim gyuyoung@webkit.org wrote:
 
  Hello,
 
  It looks WebKit queue doesn't work now. Does anyone check it ?
 
  Gyuyoung.
 
 
 
  --
  Sent from Gyuyoung Iphone
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev

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

[webkit-dev] Is commit-queue broken ?

[Gyuyoung Kim]

Hello,

It looks WebKit queue doesn't work now. Does anyone check it ?

Gyuyoung.



-- 
Sent from Gyuyoung Iphone
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is anyone using the LevelDB backend to IndexedDB?

[Gyuyoung Kim]

Hi,


LevelDB was removed in r172883. If there is any problem, please let me know.

http://trac.webkit.org/changeset/172883


Gyuyoung.



On Thu, Jul 17, 2014 at 1:15 PM, Gyuyoung Kim gyuyoung@webkit.org
wrote:

 EFL and GTK already dropped own WK1 port. It seems to me there is no
 WK1 maintained port except for Mac and Window ports.

 Gyuyoung


 On Thursday, July 17, 2014, Brady Eidson beid...@apple.com wrote:

 Are there any WebKit1’s left besides Apple’s Mac and Windows ports?

 If not, we can drop the LevelDB source and start simplifying.

  Brady

 On Jul 16, 2014, at 8:59 PM, Gyuyoung Kim gyuyoung@webkit.org
 wrote:

 Hello Nataraj,

 Though there is a meta bug as well as some following bugs, there are no
 patches yet.

 [EFL][META] Enable IndexedDB
 https://bugs.webkit.org/show_bug.cgi?id=87661

 Some webkit-efl folks are interested in supporting it though, AFAIK, it
 is not started yet.

 Gyuyoung

 On Thursday, July 17, 2014, Nataraj Bukkambudi natarajb...@gmail.com
 wrote:

 Dear Gyuyoung,

 Is there anywork around patch going on to support indexedDB based on
 sqlite for EFL WK2 port also ?



 On Tue, Apr 29, 2014 at 8:39 AM, Gyuyoung Kim gyuyoung@webkit.org
 wrote:

 Hi Brady,

  Gyuyoung is there a bugzilla for that?

 I just file a bug for it.

 [EFL][WK1] Support indexedDB based on sqlite directly
 (https://bugs.webkit.org/show_bug.cgi?id=132317)

 My co-worker will upload  patches to support indexedDB based on sqlite
 for EFL WK1.

 Gyuyoung.


 On Mon, Apr 28, 2014 at 11:42 PM, Brady Eidson beid...@apple.com
 wrote:


 On Apr 28, 2014, at 5:40 AM, Steven Coul (scoul) sc...@cisco.com
 wrote:

  Is there an alternative to levelDB without going to webkit2 ?


 Not at this time, but apparently EFL is planning to make it work
 (per Gyuyoung’s email to this thread)

 Gyuyoung is there a bugzilla for that?

 Thanks,
  Brady


  Steve Harry Coul
 sc...@cisco.com



  On Apr 28, 2014, at 4:20 AM, ryuan Choi ryuan.c...@webkit.org
 wrote:

  WebKit/Efl dropped level db dependency (and disabled leveldb)


 2014-04-28 16:44 GMT+09:00 Raphael Kubo da Costa rak...@webkit.org:

 Darin Adler da...@apple.com writes:

  On Apr 25, 2014, at 1:05 AM, Raphael Kubo da Costa 
 rak...@webkit.org wrote:
 
  Sam Weinig wei...@apple.com writes:
 
  Hello,
 
  Is anyone using the LevelDB backend to IndexedDB?
 
  The EFL and GTK+ ports are.
 
  Are you sure?
 
  Since the GTK+ port is now WebKit2-only, then it can’t be using the
  LevelDB back end at this time, because I believe nobody has made it
  work in WebKit2 yet.

  Right, so it's only the build system that sets WTF_USE_LEVELDB to 1
 and
 builds the LevelDB stuff in ThirdParty.

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


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


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



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



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




 --
 Nataraj,
 Samsung india,
 Bangalore.



 --
 Sent from Gyuyoung Iphone




 --
 Sent from Gyuyoung Iphone

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

Re: [webkit-dev] Heads up: Incremental build issue on cmake (GTK/EFL) ports

[Gyuyoung Kim]

Hello Ossy,

Thank you. I also restart efl ews with clean build.

Gyuyoung

On Thursday, August 7, 2014, Osztrogonác Csaba o...@inf.u-szeged.hu wrote:

 Of course, I used the Force Clean build checkbox on
 build.webkit.org as you mentioned. ;) So the buildbots
 are happy now.

 I sent this mail to let the developers know what should
 they do if they run into this problem on local builds.

 But unfortunately we aren't able to clean the EFL EWS,
 only its maintainer can do it. Gyuyoung, could you kick
 this bot please? (It seems GTK guys already fixed their EWS)

 br,
 Ossy

 Ryosuke Niwa írta:

 You should be able to trgger clean builds on build.webkit.org 
 http://build.webkit.org once you login.  Or are you talking about
 downstream bots GTK/EFL bots?

 On Wednesday, August 6, 2014, Osztrogonác Csaba o...@inf.u-szeged.hu
 mailto:o...@inf.u-szeged.hu wrote:

 Hi,

 r171961 changed the path of the generated inspector files (because
 of r171942) from WebKitBuild/Release/__DerivedSources/JavaScriptCore
 to WebKitBuild/Release/__DerivedSources/JavaScriptCore/__inspector

 But unfortunately the old generated files remained in the old
 path which caused the following strange incremental build error
 after r172129:

 In file included from
 /home/oszi/webkit/Source/__JavaScriptCore/inspector/__
 agents/InspectorAgent.h:35:0,
  from
 /home/oszi/webkit/Source/__JavaScriptCore/inspector/__
 JSGlobalObjectInspectorControl__ler.cpp:35:
 /home/oszi/webkit/WebKitBuild/__Release/DerivedSources/__
 JavaScriptCore/__InspectorJSBackendDispatchers.__h:89:18:
 note:virtual void
 Inspector::__InspectorRuntimeBackendDispatc__herHandler::__
 getRuntimeTypeForVariableInTex__tRange(Inspector::ErrorString*__,
 const WTF::String, const WTF::String, int, int, int, int,
 WTF::String*)

 To solve this problem, you should simple remove the following files
 from WebKitBuild/Release/__DerivedSources/JavaScriptCore:
 InspectorJSBackendDispatchers.__cpp
 InspectorJSBackendDispatchers.__h
 InspectorJSFrontendDispatchers__.cpp
 InspectorJSFrontendDispatchers__.h
 InspectorJSTypeBuilders.cpp
 InspectorJSTypeBuilders.h

 I triggered clean build on the buildbots to fix this issue, but
 these files should be removed on the GTK and EFL EWS bots too.

 br,
 Ossy
 _
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/__mailman/listinfo/webkit-dev
 https://lists.webkit.org/mailman/listinfo/webkit-dev



 --
 Ryosuke Niwa



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



-- 
Sent from Gyuyoung Iphone
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is anyone using the LevelDB backend to IndexedDB?

[Gyuyoung Kim]

Hello Nataraj,

Though there is a meta bug as well as some following bugs, there are no
patches yet.

[EFL][META] Enable IndexedDB
https://bugs.webkit.org/show_bug.cgi?id=87661

Some webkit-efl folks are interested in supporting it though, AFAIK, it is
not started yet.

Gyuyoung

On Thursday, July 17, 2014, Nataraj Bukkambudi natarajb...@gmail.com
wrote:

 Dear Gyuyoung,

 Is there anywork around patch going on to support indexedDB based on
 sqlite for EFL WK2 port also ?



 On Tue, Apr 29, 2014 at 8:39 AM, Gyuyoung Kim gyuyoung@webkit.org
 javascript:_e(%7B%7D,'cvml','gyuyoung@webkit.org'); wrote:

 Hi Brady,

  Gyuyoung is there a bugzilla for that?

 I just file a bug for it.

 [EFL][WK1] Support indexedDB based on sqlite directly
 (https://bugs.webkit.org/show_bug.cgi?id=132317)

 My co-worker will upload  patches to support indexedDB based on sqlite
 for EFL WK1.

 Gyuyoung.


 On Mon, Apr 28, 2014 at 11:42 PM, Brady Eidson beid...@apple.com
 javascript:_e(%7B%7D,'cvml','beid...@apple.com'); wrote:


 On Apr 28, 2014, at 5:40 AM, Steven Coul (scoul) sc...@cisco.com
 javascript:_e(%7B%7D,'cvml','sc...@cisco.com'); wrote:

  Is there an alternative to levelDB without going to webkit2 ?


 Not at this time, but apparently EFL is planning to make it work
 (per Gyuyoung’s email to this thread)

 Gyuyoung is there a bugzilla for that?

 Thanks,
  Brady


  Steve Harry Coul
 sc...@cisco.com javascript:_e(%7B%7D,'cvml','sc...@cisco.com');



  On Apr 28, 2014, at 4:20 AM, ryuan Choi ryuan.c...@webkit.org
 javascript:_e(%7B%7D,'cvml','ryuan.c...@webkit.org'); wrote:

  WebKit/Efl dropped level db dependency (and disabled leveldb)


 2014-04-28 16:44 GMT+09:00 Raphael Kubo da Costa rak...@webkit.org
 javascript:_e(%7B%7D,'cvml','rak...@webkit.org');:

 Darin Adler da...@apple.com
 javascript:_e(%7B%7D,'cvml','da...@apple.com'); writes:

  On Apr 25, 2014, at 1:05 AM, Raphael Kubo da Costa rak...@webkit.org
 javascript:_e(%7B%7D,'cvml','rak...@webkit.org'); wrote:
 
  Sam Weinig wei...@apple.com
 javascript:_e(%7B%7D,'cvml','wei...@apple.com'); writes:
 
  Hello,
 
  Is anyone using the LevelDB backend to IndexedDB?
 
  The EFL and GTK+ ports are.
 
  Are you sure?
 
  Since the GTK+ port is now WebKit2-only, then it can’t be using the
  LevelDB back end at this time, because I believe nobody has made it
  work in WebKit2 yet.

  Right, so it's only the build system that sets WTF_USE_LEVELDB to 1 and
 builds the LevelDB stuff in ThirdParty.

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 javascript:_e(%7B%7D,'cvml','webkit-dev@lists.webkit.org');
 https://lists.webkit.org/mailman/listinfo/webkit-dev


  ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 javascript:_e(%7B%7D,'cvml','webkit-dev@lists.webkit.org');
 https://lists.webkit.org/mailman/listinfo/webkit-dev


  ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 javascript:_e(%7B%7D,'cvml','webkit-dev@lists.webkit.org');
 https://lists.webkit.org/mailman/listinfo/webkit-dev



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 javascript:_e(%7B%7D,'cvml','webkit-dev@lists.webkit.org');
 https://lists.webkit.org/mailman/listinfo/webkit-dev



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 javascript:_e(%7B%7D,'cvml','webkit-dev@lists.webkit.org');
 https://lists.webkit.org/mailman/listinfo/webkit-dev




 --
 Nataraj,
 Samsung india,
 Bangalore.



-- 
Sent from Gyuyoung Iphone
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is anyone using the LevelDB backend to IndexedDB?

[Gyuyoung Kim]

EFL and GTK already dropped own WK1 port. It seems to me there is no
WK1 maintained port except for Mac and Window ports.

Gyuyoung

On Thursday, July 17, 2014, Brady Eidson beid...@apple.com wrote:

 Are there any WebKit1’s left besides Apple’s Mac and Windows ports?

 If not, we can drop the LevelDB source and start simplifying.

  Brady

 On Jul 16, 2014, at 8:59 PM, Gyuyoung Kim gyuyoung@webkit.org
 javascript:_e(%7B%7D,'cvml','gyuyoung@webkit.org'); wrote:

 Hello Nataraj,

 Though there is a meta bug as well as some following bugs, there are no
 patches yet.

 [EFL][META] Enable IndexedDB
 https://bugs.webkit.org/show_bug.cgi?id=87661

 Some webkit-efl folks are interested in supporting it though, AFAIK, it
 is not started yet.

 Gyuyoung

 On Thursday, July 17, 2014, Nataraj Bukkambudi natarajb...@gmail.com
 javascript:_e(%7B%7D,'cvml','natarajb...@gmail.com'); wrote:

 Dear Gyuyoung,

 Is there anywork around patch going on to support indexedDB based on
 sqlite for EFL WK2 port also ?



 On Tue, Apr 29, 2014 at 8:39 AM, Gyuyoung Kim gyuyoung@webkit.org
 wrote:

 Hi Brady,

  Gyuyoung is there a bugzilla for that?

 I just file a bug for it.

 [EFL][WK1] Support indexedDB based on sqlite directly
 (https://bugs.webkit.org/show_bug.cgi?id=132317)

 My co-worker will upload  patches to support indexedDB based on sqlite
 for EFL WK1.

 Gyuyoung.


 On Mon, Apr 28, 2014 at 11:42 PM, Brady Eidson beid...@apple.com
 wrote:


 On Apr 28, 2014, at 5:40 AM, Steven Coul (scoul) sc...@cisco.com
 wrote:

  Is there an alternative to levelDB without going to webkit2 ?


 Not at this time, but apparently EFL is planning to make it work
 (per Gyuyoung’s email to this thread)

 Gyuyoung is there a bugzilla for that?

 Thanks,
  Brady


  Steve Harry Coul
 sc...@cisco.com



  On Apr 28, 2014, at 4:20 AM, ryuan Choi ryuan.c...@webkit.org wrote:

  WebKit/Efl dropped level db dependency (and disabled leveldb)


 2014-04-28 16:44 GMT+09:00 Raphael Kubo da Costa rak...@webkit.org:

 Darin Adler da...@apple.com writes:

  On Apr 25, 2014, at 1:05 AM, Raphael Kubo da Costa 
 rak...@webkit.org wrote:
 
  Sam Weinig wei...@apple.com writes:
 
  Hello,
 
  Is anyone using the LevelDB backend to IndexedDB?
 
  The EFL and GTK+ ports are.
 
  Are you sure?
 
  Since the GTK+ port is now WebKit2-only, then it can’t be using the
  LevelDB back end at this time, because I believe nobody has made it
  work in WebKit2 yet.

  Right, so it's only the build system that sets WTF_USE_LEVELDB to 1
 and
 builds the LevelDB stuff in ThirdParty.

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


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


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



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



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




 --
 Nataraj,
 Samsung india,
 Bangalore.



 --
 Sent from Gyuyoung Iphone




-- 
Sent from Gyuyoung Iphone
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] EFL and GTK EWS bots having issues

[Gyuyoung Kim]

Hi,

I fixed the EFL EWS. EFL EWS is working again. Sorry for inconvenience.

Gyuyoung.


On Sat, Jul 12, 2014 at 5:48 AM, Christophe Dumez dch...@gmail.com wrote:

 Hi,

 I believe Gyuyoung Kim (in cc) is maintaining the EFL EWS.


 Kr,


 On Fri, Jul 11, 2014 at 4:38 PM, Joseph Pecoraro pecor...@apple.com
 wrote:

 It seems the EFL and GTK EWS bots are having trouble for a few days now:
 http://webkit-queues.appspot.com

 - GTK EWS bot has Unable to build without patch” with:
 ninja: error: build.ninja:3225: lexing error

 - EFL EWS bot doesn’t seem to be processing patches.

 Who would be best to look into these issues? I thought there used to be a
 list of EWS maintainers, but I couldn’t find it.

 Having these EWS bots to test CMake build changes is awesome, but with
 the bots down I’m stuck.

 - Joe

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




 --
 Christophe DUMEZ

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


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

[webkit-dev] Alex Christensen is now a reviewer

[Gyuyoung Kim]

Congrats Alex !


On Tue, Jul 8, 2014 at 7:10 PM, Yusuke SUZUKI utatane@gmail.com
javascript:_e(%7B%7D,'cvml','utatane@gmail.com'); wrote:

 Congrats!

 ---
 Regards,
 Yusuke Suzuki


 On Wed, Jul 2, 2014 at 9:44 AM, Benjamin Poulain benja...@webkit.org
 javascript:_e(%7B%7D,'cvml','benja...@webkit.org'); wrote:

 Hi WebKittens,

 After much deliberation around Alex's inability to eat his own head, Alex
 is now becoming a WebKit reviewer.

 Alex is experienced in many core areas of WebKit. He has been hacking on
 the CSS JIT, WebGL, Web Timing, and Pointer Lock. He is also one of the
 courageous souls who fix Windows issues.

 Congratulations Alex!

 Benjamin
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 javascript:_e(%7B%7D,'cvml','webkit-dev@lists.webkit.org');
 https://lists.webkit.org/mailman/listinfo/webkit-dev



 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 javascript:_e(%7B%7D,'cvml','webkit-dev@lists.webkit.org');
 https://lists.webkit.org/mailman/listinfo/webkit-dev




-- 
Sent from Gyuyoung Iphone
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Drop EFL WK1 port

[Gyuyoung Kim]

Hello WebKittens,

As discussed on webkit-efl mailing list, we decided to stop EFL WK1 port
since we don't use EFL WK1 port anywhere now and future. We will focus on
EFL WK2 port. We're going to remove EFL WK1 source code as well as EWS and
buildbot for EFL WK1.

EFL mailing thread regarding EFL WK1 removal -
https://lists.webkit.org/pipermail/webkit-efl/2014-June/000608.html

Gyuyoung.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Zoltan Horvath is now a WebKit reviewer

[Gyuyoung Kim]

Congrats ! Zoltan !

Gyuyoung
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Remove ENABLE_NETWORK_INFO ?

[Gyuyoung Kim]

Hi Philippe,

Sad to remove the feature. However, Network Information API spec. has still
many issues to support bandwidth and with providing useful information. So,
I should agree to remove it. However, if the specification is resurrected
in future, I would like to support it again.

Gyuyoung.


On Fri, Apr 18, 2014 at 5:43 PM, Philippe Normand ph...@igalia.com wrote:

 Hi,

 I think that feature should be removed from WebKit. The spec[1] clearly
 states:

 Work on this document has been discontinued and it should not be
 referenced or used as a basis for implementation.

 Anyone against removing the networkinfo Module? It seems this feature
 was initially implemented for the EFL port.

 Philippe

 [1] https://dvcs.w3.org/hg/dap/raw-file/tip/network-api/Overview.html

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

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

Re: [webkit-dev] Remove USE_DYNAMIC_ANNOTATIONS?

[Gyuyoung Kim]

AFAIK, EFL port doesn't use it.

Gyuyoung

2014년 4월 17일 목요일, Simon Frasersimon.fra...@apple.com님이 작성한 메시지:

 Does any port define USE_DYNAMIC_ANNOTATIONS? It’s adding header pollution
 and no-one seems to use it.

 Simon

 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org javascript:;
 https://lists.webkit.org/mailman/listinfo/webkit-dev



-- 
Sent from Gyuyoung Iphone
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Enabling CSS JIT on Linux x86_64 for EFL and GTK?

[Gyuyoung Kim]

Hi Benjamin,

I upload a patch to fix build breaks on EFL port when enabling the CSS JIT.
Besides it enables the CSS JIT for EFL port.

[CMake][EFL] Enable CSS JIT
(https://bugs.webkit.org/show_bug.cgi?id=131010)

I think GTK based on CMake will be able to use the patch as well.

Thanks,
Gyuyoung.


On Tue, Apr 1, 2014 at 6:09 AM, Benjamin Poulain benja...@webkit.orgwrote:

 Hi,

 Now that EFL and GTK use CMake, can someone look at what is missing to
 enable the CSS JIT on Linux x86_64?

 Last time I tried, there were some issues with the headers. It is likely
 trivial to fix with a local build.

 I would be happy to fix any problem with the compiler if it does not work
 on Linux.

 Benjamin
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] CMake for WebKitGTK+

[Gyuyoung Kim]

CMake build files have been enhanced since the GTK+ port contributions !
Thanks a lot.

Gyuyoung.


On Wed, Mar 26, 2014 at 5:12 AM, Benjamin Poulain benja...@webkit.orgwrote:

 On 3/25/14, 10:52 AM, Martin Robinson wrote:

 On Wed, Mar 5, 2014 at 7:30 PM, Martin Robinson mrobin...@webkit.org
 wrote:

 For a time, I kindly request that authors writing GTK+-specific
 patches consider both the autotools and CMake GTK+ builds in their
 patches. Hopefully within the next couple months, we can announce the
 complete removal of the autotools build. I'd like to apologize ahead
 of time for the inconvenience, as we iron out the final bugs. With
 luck, the future will be much simpler and smoother for everyone.


 After internal discussions, we decided to accelerate the removal of
 the autotools build. I have just removed it [1]. WebKit now has three
 build systems, which means we have shed five build systems in a little
 over a year.

 1. http://trac.webkit.org/changeset/166239


 That is awesome!

 Benjamin

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

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

Re: [webkit-dev] Credit change set author when merging changes

[Gyuyoung Kim]

Hi,

When we merge own blink patch into WebKit, should we credit the original
author in ChangeLog ?

Gyuyoung


On Fri, Feb 14, 2014 at 5:36 PM, Ryosuke Niwa rn...@webkit.org wrote:

 Hi,

 This is a friendly remainder that you should credit the original author
 and the relevant change set in blink when you're merging patches written by
 another author.

 e.g. http://trac.webkit.org/changeset/163528

 - R. Niwa


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


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

Re: [webkit-dev] Credit change set author when merging changes

[Gyuyoung Kim]

Thank you for you guys clarification. Let me follow that from now.

Gyuyoung.

2014년 2월 14일 금요일, Ryosuke Niwarn...@webkit.org님이 작성한 메시지:

 I don't think you need the author's name if you include an URL to the
 relevant SVN or Git commit log since anyone could simply follow the URL to
 find the original author.  It might be a nice gesture though.

 On the other hand, if we're simply mentioning a revision number without
 URL, then we should probably mention the author as well.

 On Friday, February 14, 2014, Osztrogonác Csaba 
 o...@inf.u-szeged.hujavascript:_e(%7B%7D,'cvml','o...@inf.u-szeged.hu');
 wrote:

 Hi,

 I checked the history of blink merges, but I haven't found too
 much credit for the original author, but much more references
 to the commit similar to the changeset you mentioned.

 Should we mention the author _and_ the changeset too in the future?

 Ossy

 On 02/14/2014 09:36 AM, Ryosuke Niwa wrote:

 Hi,

 This is a friendly remainder that you should credit the original author
 and the relevant change set in blink when you're merging patches written
 by another author.

 e.g. http://trac.webkit.org/changeset/163528

 - R. Niwa

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



 --
 - R. Niwa



-- 
Sent from Gyuyoung Iphone
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Sergio Villar Senin is now a WebKit reviewer!

[Gyuyoung Kim]

Congrats Sergio !!

Gyuyoung.


On Thu, Feb 13, 2014 at 8:19 AM, Philippe Normand ph...@igalia.com wrote:

 Hi,

 I'm happy to announce that Sergio (svillar) is now a WebKit reviewer!

 Sergio's areas of expertize span from WebCore (CSS Grid Layout, Parser,
 editing) to WebKit2 with a special dedication to the GTK port. Sergio
 also spends a lot of efforts on the libsoup networking backend.

 Thanks Sergio for all the work you have done so far and congratulations!

 Philippe

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

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

Re: [webkit-dev] EFL and GTK on Darwin

[Gyuyoung Kim]

Hello Dan,

 1. Is there a configuration of the EFL port that actually builds for
Darwin?

Unfortunately(?), AFAIK, WebKit EFL port doesn't support Darwin OS yet.

Gyuyoung.


On Tue, Feb 11, 2014 at 11:30 AM, Dan Bernstein m...@apple.com wrote:

 Hi everyone, and especially EFL and GTK contributors!

 In preparation for changing PLATFORM(MAC) to be false when building for
 iOS, I have been reviewing usage of PLATFORM(MAC) throughout our
 codebase. Some of these uses are really about targeting the Darwin OS.
 However, I could not simply replace PLATFORM(MAC) with OS(DARWIN),
 because the latter also encompasses the EFL and GTK platforms when building
 for Darwin (which the former does not). Therefore, thus far I have replaced
 relevant instances of PLATFORM(MAC) with (OS(DARWIN)  !PLATFORM(EFL) 
 !PLATFORM(GTK)).

 This is ugly and seems like a waste of time, so I was wondering:

 1. Is there a configuration of the EFL port that actually builds for
 Darwin?

 2. Is there a configuration of the GTK port that actually builds for
 Darwin?

 3. If such configuration(s) exist, would it be OK for them to use Darwin
 when building for Darwin?

 If the answer to 1 and 2 is no, or if the answer to 3 is yes, then I will
 simply use OS(DARWIN) to replace PLATFORM(MAC) where that is the intent,
 and, depending on the answers to 1 and 2, update the EFL and GTK build
 systems to include the Darwin-based implementations where needed.

 Thanks!

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


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

Re: [webkit-dev] EFL EWS Bot output

[Gyuyoung Kim]

Ah, I see. Thank you. I missed it. :)

Gyuyoung.


On Wed, Feb 5, 2014 at 5:29 PM, Osztrogonác Csaba o...@inf.u-szeged.huwrote:

 Hi,

 Fix already landed in http://trac.webkit.org/changeset/163167 ;)

 Ossy

 Gyuyoung Kim írta:

 Hello Oliver,

 I'm really sorry about the inconvenience to you. Let me try to fix it
 within a few days.
 Gyuyoung.


 On Wed, Jan 29, 2014 at 8:09 AM, Alexey Proskuryakov a...@webkit.orgmailto:
 a...@webkit.org wrote:


 28 ???. 2014 ?., ? 14:59, Oliver Hunt oli...@apple.com
 mailto:oli...@apple.com ???(?):


   Could whoever is responsible for the EFL EWS bot please make the
 bot set the correct mimetype on the build output.
  
   I've requested this before, but i'm trying again.  It is really
 annoying that it triggers a download rather than just opening in the
 browser like the output from every other bot.

 What needs to be fixed is that the output shouldn't have escape
 sequences. The MIME type of text/plain is set by webkit-queues
 server, but then networking code in the browser sees a resource
 without an extension and that has binary data in it, so it overrides
 the type.

 Another solution would be for webkitpy or webkit-queues to
 automagically strip escape sequences from the output.

 - WBR, Alexey Proskuryakov

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

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

[webkit-dev] EFL WK2 bot / ews start to work again

[Gyuyoung Kim]

Hi WebKitten,

First of all, I'm so sorry for broken EFL WK2 bot and ews during one week.
I didn't manage them during last week, because we was holidays.
Additionally my co-workers also couldn't maintain them due to some internal
issues. Now I restart them, and try to keep them work well.

Thanks,
Gyuyoung.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] EFL EWS Bot output

[Gyuyoung Kim]

Hello Oliver,

I'm really sorry about the inconvenience to you. Let me try to fix it
within a few days.

Gyuyoung.


On Wed, Jan 29, 2014 at 8:09 AM, Alexey Proskuryakov a...@webkit.org wrote:


 28 янв. 2014 г., в 14:59, Oliver Hunt oli...@apple.com написал(а):

  Could whoever is responsible for the EFL EWS bot please make the bot set
 the correct mimetype on the build output.
 
  I've requested this before, but i'm trying again.  It is really annoying
 that it triggers a download rather than just opening in the browser like
 the output from every other bot.

 What needs to be fixed is that the output shouldn't have escape sequences.
 The MIME type of text/plain is set by webkit-queues server, but then
 networking code in the browser sees a resource without an extension and
 that has binary data in it, so it overrides the type.

 Another solution would be for webkitpy or webkit-queues to automagically
 strip escape sequences from the output.

 - WBR, Alexey Proskuryakov

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

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

Re: [webkit-dev] Proposal: Stop EWS bot commenting in bugs

[Gyuyoung Kim]

+1, I would prefer to see EWS log only when I want to see it.

Gyuyoung.


On Thu, Jan 16, 2014 at 1:24 PM, Joseph Pecoraro pecor...@apple.com wrote:

 I would also like to see a reduction in EWS spam.

 It is not just the comment clutter, but also quite a bit of emails.

 - Joe

 On Jan 15, 2014, at 8:17 PM, Ryosuke Niwa rn...@webkit.org wrote:

 We could do that, or add some JS hack to Bugzilla so that it hides EWS
 comments by default but makes them expandable.

 - R. Niwa


 On Wed, Jan 15, 2014 at 8:09 PM, Sam Weinig wei...@apple.com wrote:

 Could we compromise for now, and remove all the non-test failing EWS
 comments (e.g. build failure, style failure)?

 - Sam

 On Jan 15, 2014, at 8:04 PM, Ryosuke Niwa rn...@webkit.org wrote:

 I find Mac EWS's listing the failing tests to be very useful especially
 because it uploads the results to Bugzilla.

 I do agree that comments about build failures are much less useful.

 - R. Niwa


 On Wed, Jan 15, 2014 at 7:54 PM, Sam Weinig wei...@apple.com wrote:

 Hi Everyone,

 I am becoming increasingly annoyed by the comments made in
 bugs.webkit.org bugs by our non-human helpers, the EWS bots.  I don’t
 find the addition of a comment indicating that a patch has failed on a bot,
 over the existing indication in the bubble, to be worth the noise it
 creates.

 I propose that we stop allowing the bots to comment, and leave that
 space for the developers.

 - Sam

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




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



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


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

Re: [webkit-dev] EFL bots for ARM architecture

[Gyuyoung Kim]

Hello Gabor,

Thank you so much !  BTW, is there any reason you attach the bots to your
build master (http://build.webkit.sed.hu) ?
Wouldn't it good to attach them to official WebKit buildbot master ?

Gyuyoung.


On Mon, Jan 13, 2014 at 11:13 PM, Gabor Rapcsanyi rga...@inf.u-szeged.huwrote:

 Hello WebKittens,

 I would like to annonunce our fresh new EFL Linux bots for ARM
 architecture. If you are interested, you can find them at:
 http://build.webkit.sed.hu/waterfall

 The bots:
  - EFL ARMv7 Linux Release (Build)
  - EFL ARMv7 Traditional Linux Release (Build)

 These bots are just builders but we are also planning to support jscore
 and layout testing as well later.

 Regards,
 Gabor Rapcsanyi
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] EFL bots for ARM architecture

[Gyuyoung Kim]

Hi Gabor,

Nice, if you attach them to the official master as existing EFL bots, we
may be able to help to maintain them from our side.

Many thanks,
Gyuyoung.


On Mon, Jan 13, 2014 at 11:44 PM, Gabor Rapcsanyi rga...@inf.u-szeged.huwrote:

  Hello Gyuyoung,

 Yes, it would be good but now our build master gives different
 environments to the dependency update and the compilation step due to a
 cross-compilation issue. Once we solve this, we can connect them to the
 official master.

 Gabor

  Hello Gabor,

  Thank you so much !  BTW, is there any reason you attach the bots to
 your build master (http://build.webkit.sed.hu) ?
 Wouldn't it good to attach them to official WebKit buildbot master ?

  Gyuyoung.


 On Mon, Jan 13, 2014 at 11:13 PM, Gabor Rapcsanyi 
 rga...@inf.u-szeged.huwrote:

 Hello WebKittens,

 I would like to annonunce our fresh new EFL Linux bots for ARM
 architecture. If you are interested, you can find them at:
 http://build.webkit.sed.hu/waterfall

 The bots:
  - EFL ARMv7 Linux Release (Build)
  - EFL ARMv7 Traditional Linux Release (Build)

 These bots are just builders but we are also planning to support jscore
 and layout testing as well later.

 Regards,
 Gabor Rapcsanyi
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev




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


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

Re: [webkit-dev] Bem Jones-Bey is now a reviewer

[Gyuyoung Kim]

Congrats !

Gyuyoung


On Sat, Dec 28, 2013 at 4:59 AM, Dirk Schulze k...@webkit.org wrote:

 Hi Webkittens,

 I am happy to announce that Bem (bemjb) is a WebKit reviewer now! Bem
 spend a lot of efforts on the layout code of WebCore. Especially Shapes,
 fragmentation and floats are his area of expertise.

 Thanks Bem for all the work you have done so far and congratulations!

 Dirk
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] You can force a clean build on build.webkit.org now

[Gyuyoung Kim]

Very nice functionality ! Thanks.

Gyuyoung.


On Sat, Nov 2, 2013 at 7:19 AM, Martin Robinson mrobin...@webkit.orgwrote:

 On Fri, Nov 1, 2013 at 2:57 PM, Ryosuke Niwa rn...@webkit.org wrote:
  I've added a Force clean build check box to the forced build field if
  you're logged in on build.webkit.org.
 
  It deletes the WebKitBuild directory by running
  Tools/BuildSlaveSupport/clean-build.
 
  Superfluous Platform.h and whitespace changes are dead!

 Great news! Thank you.

 --Martin
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Wink browser

[Gyuyoung Kim]

Can I run the wink browser now ? Though I tried to install it to my window7
PC using WinkInstaller.msi, installation was failed.

Gyuyoung.


On Fri, Oct 11, 2013 at 1:42 PM, Brent Fulgham bfulg...@gmail.com wrote:

 Fantastic work! I can't wait to see what you do with it.

 -Brent

 Sent from my iPad

  On Oct 10, 2013, at 6:08 PM, Alex Christensen 
 alex.christen...@flexsim.com wrote:
 
  With the removal of Chromium and Qt, there are no projects of which I am
 aware that allow Windows users to use WebKit with content from the open
 internet. I've started a web browser project I'm calling Wink to get the
 public to use WebKit on Windows, and I'm collecting crash reports with
 stack traces to allow me to locate and fix common crashes.
 
  I've created Winkbrowser.org and Winkbrowser.org/nightly.php as a start.
 Could whoever manages nightly.webkit.org please send me some example
 code? You might have noticed that writing aesthetically pleasing php isn't
 exactly my strength.
 
  I hope this will be seen as beneficial to the WebKit community.
 
  Alex Christensen
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] GCC version consistency on EFL bots?

[Gyuyoung Kim]

Hello,

We finished to upgrade EFL 32bit buildbot to Ubuntu 13.04. I will try that
all EFL bots have same gcc version.

Thanks,
Gyuyoung.


On Mon, Oct 7, 2013 at 12:33 PM, Gyuyoung Kim gyuyoung@webkit.orgwrote:

 Hello Karen,

 Thank you for good information. However, as Andreas said, it is important
 to have the same compiler version both on EWS and bots. So, I feel I need
 that the problem bot has the same gcc version as soon as possible. Because
 I don't want to do something against WebKit(or common) development trend
 and policy.

 Thanks,
 Gyuyoung.


 On Mon, Oct 7, 2013 at 11:35 AM, Karen Shaeffer 
 shaef...@neuralscape.comwrote:

 Hi Gyuyoung,

 Be aware:
 Ubuntu 12.10 (gnu 4.7.2) expires April 2014.
 Ubuntu 13.04 (gnu 4.7.3) expires Jan 2014.
 Ubunut 13.10 (gnu 4.8.1) scheduled release date Oct 17 2013. End of life
 Jul 2014.
 Ubuntu 14.04 (gnu 4.8.x) scheduled release date Apr 17 2014. LTS release

 I would avoid 13.04, because you'll need to upgrade twice more within
 months to
 get to 14.04 LTS. Either 12.10 or 13.10 allow you only 1 more upgrade to
 get to
 14.04 LTS. I guess the decision should be which compiler version you
 prefer.

 enjoy,
 Karen
 --
 Karen Shaeffer Be aware: If you see an obstacle in your
 path,
 Neuralscape Services   that obstacle is your path.Zen
 proverb

 On Mon, Oct 07, 2013 at 10:26:22AM +0900, Gyuyoung Kim wrote:
  Hi Andreas,
 
  Ah, I only talked on EFL ews bots. Yes, we're running an ubuntu 32bit
  machine only for a 32bit buildbot. And, it is based on Ubuntu 12.04 and
 has
  gcc 4.6.3 version. I think the 32bit buildbot needs to be upgraded. I
 will
  do it.
 
  Thanks,
  Gyuyoung.
 
 
  On Mon, Oct 7, 2013 at 10:07 AM, Andreas Kling akl...@apple.com
 wrote:
 
   Hi Gyuyoung,
  
   Then why is final/override working on EWS but not on the main build
 bots?
   Are they using different compiler flags?
  
   According to wtf/Compiler.h, GCC should support override control
 since at
   least 4.7.0.
  
   Errors here:
  
  
 http://build.webkit.org/builders/EFL%20Linux%2032-bit%20Release%20%28Build%29/builds/22628/steps/compile-webkit/logs/stdio
  
  
 /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:142:60:
   error: expected ';' at end of member declaration
  
 /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:142:62:
   error: 'override' does not name a type
  
 /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:143:87:
   error: expected ';' at end of member declaration
  
 /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:143:89:
   error: 'override' does not name a type
  
   -Andreas
  
   On Oct 7, 2013, at 2:01 AM, Gyuyoung Kim gyuyoung@webkit.org
 wrote:
  
Hi Andreas,
   
 Are the main/EWS bots running different versions of GCC?
   
No, EFL ews bots have same gcc version. EFL ews and buildbots are
 being
   ran on two machines. As far as I know, those are based on Ubuntu
 13.04 and
   have same gcc 4.7.3.
   
Thanks,
Gyuyoung.
   
   
On Mon, Oct 7, 2013 at 4:56 AM, Andreas Kling akl...@apple.com
 wrote:
Hi folks,
   
I recently landed a patch that makes use of lowercased “override”
and “final” in WebKit, and now the EFL build is failing.
   
The EFL EWS bots didn’t have any problem with the patch however,
which brings me to my question:
   
Are the main/EWS bots running different versions of GCC?
And if so, how soon can we make them use the same one?
   
-Kling
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
   
  
  

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

 --- end quoted text ---



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

Re: [webkit-dev] GCC version consistency on EFL bots?

[Gyuyoung Kim]

Hi Andreas,

 Are the main/EWS bots running different versions of GCC?

No, EFL ews bots have same gcc version. EFL ews and buildbots are being ran
on two machines. As far as I know, those are based on Ubuntu 13.04 and have
same gcc 4.7.3.

Thanks,
Gyuyoung.


On Mon, Oct 7, 2013 at 4:56 AM, Andreas Kling akl...@apple.com wrote:

 Hi folks,

 I recently landed a patch that makes use of lowercased “override”
 and “final” in WebKit, and now the EFL build is failing.

 The EFL EWS bots didn’t have any problem with the patch however,
 which brings me to my question:

 Are the main/EWS bots running different versions of GCC?
 And if so, how soon can we make them use the same one?

 -Kling
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] GCC version consistency on EFL bots?

[Gyuyoung Kim]

Hi Andreas,

Ah, I only talked on EFL ews bots. Yes, we're running an ubuntu 32bit
machine only for a 32bit buildbot. And, it is based on Ubuntu 12.04 and has
gcc 4.6.3 version. I think the 32bit buildbot needs to be upgraded. I will
do it.

Thanks,
Gyuyoung.


On Mon, Oct 7, 2013 at 10:07 AM, Andreas Kling akl...@apple.com wrote:

 Hi Gyuyoung,

 Then why is final/override working on EWS but not on the main build bots?
 Are they using different compiler flags?

 According to wtf/Compiler.h, GCC should support override control since at
 least 4.7.0.

 Errors here:

 http://build.webkit.org/builders/EFL%20Linux%2032-bit%20Release%20%28Build%29/builds/22628/steps/compile-webkit/logs/stdio

 /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:142:60:
 error: expected ';' at end of member declaration
 /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:142:62:
 error: 'override' does not name a type
 /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:143:87:
 error: expected ';' at end of member declaration
 /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:143:89:
 error: 'override' does not name a type

 -Andreas

 On Oct 7, 2013, at 2:01 AM, Gyuyoung Kim gyuyoung@webkit.org wrote:

  Hi Andreas,
 
   Are the main/EWS bots running different versions of GCC?
 
  No, EFL ews bots have same gcc version. EFL ews and buildbots are being
 ran on two machines. As far as I know, those are based on Ubuntu 13.04 and
 have same gcc 4.7.3.
 
  Thanks,
  Gyuyoung.
 
 
  On Mon, Oct 7, 2013 at 4:56 AM, Andreas Kling akl...@apple.com wrote:
  Hi folks,
 
  I recently landed a patch that makes use of lowercased “override”
  and “final” in WebKit, and now the EFL build is failing.
 
  The EFL EWS bots didn’t have any problem with the patch however,
  which brings me to my question:
 
  Are the main/EWS bots running different versions of GCC?
  And if so, how soon can we make them use the same one?
 
  -Kling
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
 


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

Re: [webkit-dev] GCC version consistency on EFL bots?

[Gyuyoung Kim]

Hello Karen,

Thank you for good information. However, as Andreas said, it is important
to have the same compiler version both on EWS and bots. So, I feel I need
that the problem bot has the same gcc version as soon as possible. Because
I don't want to do something against WebKit(or common) development trend
and policy.

Thanks,
Gyuyoung.


On Mon, Oct 7, 2013 at 11:35 AM, Karen Shaeffer shaef...@neuralscape.comwrote:

 Hi Gyuyoung,

 Be aware:
 Ubuntu 12.10 (gnu 4.7.2) expires April 2014.
 Ubuntu 13.04 (gnu 4.7.3) expires Jan 2014.
 Ubunut 13.10 (gnu 4.8.1) scheduled release date Oct 17 2013. End of life
 Jul 2014.
 Ubuntu 14.04 (gnu 4.8.x) scheduled release date Apr 17 2014. LTS release

 I would avoid 13.04, because you'll need to upgrade twice more within
 months to
 get to 14.04 LTS. Either 12.10 or 13.10 allow you only 1 more upgrade to
 get to
 14.04 LTS. I guess the decision should be which compiler version you
 prefer.

 enjoy,
 Karen
 --
 Karen Shaeffer Be aware: If you see an obstacle in your
 path,
 Neuralscape Services   that obstacle is your path.Zen
 proverb

 On Mon, Oct 07, 2013 at 10:26:22AM +0900, Gyuyoung Kim wrote:
  Hi Andreas,
 
  Ah, I only talked on EFL ews bots. Yes, we're running an ubuntu 32bit
  machine only for a 32bit buildbot. And, it is based on Ubuntu 12.04 and
 has
  gcc 4.6.3 version. I think the 32bit buildbot needs to be upgraded. I
 will
  do it.
 
  Thanks,
  Gyuyoung.
 
 
  On Mon, Oct 7, 2013 at 10:07 AM, Andreas Kling akl...@apple.com wrote:
 
   Hi Gyuyoung,
  
   Then why is final/override working on EWS but not on the main build
 bots?
   Are they using different compiler flags?
  
   According to wtf/Compiler.h, GCC should support override control since
 at
   least 4.7.0.
  
   Errors here:
  
  
 http://build.webkit.org/builders/EFL%20Linux%2032-bit%20Release%20%28Build%29/builds/22628/steps/compile-webkit/logs/stdio
  
  
 /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:142:60:
   error: expected ';' at end of member declaration
  
 /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:142:62:
   error: 'override' does not name a type
  
 /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:143:87:
   error: expected ';' at end of member declaration
  
 /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:143:89:
   error: 'override' does not name a type
  
   -Andreas
  
   On Oct 7, 2013, at 2:01 AM, Gyuyoung Kim gyuyoung@webkit.org
 wrote:
  
Hi Andreas,
   
 Are the main/EWS bots running different versions of GCC?
   
No, EFL ews bots have same gcc version. EFL ews and buildbots are
 being
   ran on two machines. As far as I know, those are based on Ubuntu 13.04
 and
   have same gcc 4.7.3.
   
Thanks,
Gyuyoung.
   
   
On Mon, Oct 7, 2013 at 4:56 AM, Andreas Kling akl...@apple.com
 wrote:
Hi folks,
   
I recently landed a patch that makes use of lowercased “override”
and “final” in WebKit, and now the EFL build is failing.
   
The EFL EWS bots didn’t have any problem with the patch however,
which brings me to my question:
   
Are the main/EWS bots running different versions of GCC?
And if so, how soon can we make them use the same one?
   
-Kling
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
   
  
  

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

 --- end quoted text ---

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

[webkit-dev] Type cast by using toFoo()

[Gyuyoung Kim]

Hello WebKittens,

I have focused on using toFoo() for SVG and CSS instead of using
static_cast.  Because I think there are some advantages when we use it.

  - Bad type cast can be detected by using ASSERTION in toFoo(). The
toFoo() function has an ASSERTION to check if source value is a proper
super class.
  - Unnecessary local variables can be removed. There are some local
variables, which are only used once in WebKit. In those cases, we don’t
need to use a local variable. Besides, we can remove unnecessary ASSERTION
because toFoo() already has it.
  - I believe toFoo() can improve code readability.

Currently, HTML, SVG Elements support toHTML|SVGFooElement() and CSSValue
also starts to support toCSSFooValue(). Please check if there is toFoo()
when you need to use static_cast in HTML, SVG and CSS module.

Finally I plan to add this toFoo() policy to the WebKit style checker.

Gyuyoung.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Type cast by using toFoo()

[Gyuyoung Kim]

My plan is to show style error when submitted patch doesn't use toFoo()
though toFoo exists. This idea was originated from blink commit. However,
it was reverted because of some regression.

http://src.chromium.org/viewvc/blink?view=revisionrevision=158059


If my understanding is correct, the toFoo() style checker checks if there
is toFoo() in a class. If uploaded patch uses static_cast instead of
toFoo() though there is toFoo(), style checker will generate style error.

Anyway, I think I need to investigate the commit and consider the idea
further.

Gyuyoung.


On Tue, Oct 1, 2013 at 3:20 AM, Ryosuke Niwa rn...@webkit.org wrote:

 On Mon, Sep 30, 2013 at 10:52 AM, Yong Li yong.li.web...@outlook.comwrote:


 Bottom line is turning on RTTI in debug build?


 Style checker analyzes the code statically.  It's nothing to do with
 runtime assertions.  If that wasn't clear enough, style check happens
 before WebKit is ever built.

 - R. Niwa


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


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

Re: [webkit-dev] New WebKit Reviewer: Mario Sanchez Prada

[Gyuyoung Kim]

Congrats Mario !!

Gyuyoung.


On Sat, Aug 24, 2013 at 5:14 AM, Romain Perier romain.per...@gmail.comwrote:

 350 patches in 3 years ~=1 patch all 3 days, nice !

 Congrats (beer, champagne, etc);)

 Le 23 août 2013 à 18:09, Denis Nomiyama d.nomiy...@samsung.com a écrit :

  Congrats Mario!
 
  -Original Message-
  From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-
  boun...@lists.webkit.org] On Behalf Of Brian Holt
  Sent: 23 August 2013 16:11
  To: webkit-dev@lists.webkit.org
  Subject: Re: [webkit-dev] New WebKit Reviewer: Mario Sanchez Prada
 
  Congratulations Mario!
 
  -Original Message-
  From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-
  boun...@lists.webkit.org] On Behalf Of Bruno de Oliveira Abinader
  Sent: 23 August 2013 16:07
  To: Christophe Dumez; webkit-dev@lists.webkit.org
  Subject: Re: [webkit-dev] New WebKit Reviewer: Mario Sanchez Prada
 
  Congrats, Mario! :-)
 
  From: Christophe Dumez ch.du...@sta.samsung.com
  Date: Friday, August 23, 2013 10:53 AM
  To: webkit-dev@lists.webkit.org webkit-dev@lists.webkit.org
  Subject: [webkit-dev] New WebKit Reviewer: Mario Sanchez Prada
 
 
 
  Hi WebKit folks,
 
  I am happy to announce that Mario Sanchez Prada
  mario.pr...@samsung.com is now a WebKit reviewer.
 
  Mario has contributed over 350 patches to WebKit over the past 3
  years, mostly around Accessibility and the WebKitGTK+2 API.
 
  Please join me in congratulating Mario for his new status!
 
  Kr,
 
  --
  Christophe Dumez - Samsung Telecommunications America
 
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
 
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

Re: [webkit-dev] Proposal: Remove Pointer Lock API

[Gyuyoung Kim]

Hi Andreas,

EFL port has not supported it yet. So, I think we don't mind to remove it.
However, it looks GTK port wants to enable it on Bug 99036.

Bug 99036 https://bugs.webkit.org/show_bug.cgi?id=99036 - [GTK] Enable
Pointer Lock feature
(https://bugs.webkit.org/show_bug.cgi?id=99036)

Gyuyoung.




On Sun, Aug 18, 2013 at 4:41 AM, Andreas Kling akl...@apple.com wrote:

 Hi WebKittens,

 I’d like to propose removing the Pointer Lock API code from WebKit. The
 code hasn’t been touched for 12 months, and AFAICT no ports are building
 with ENABLE(POINTER_LOCK).

 Is anyone currently building (and shipping / planning to ship) this API?

 Other thoughts?

 -Kling
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Remove CSS_IMAGE_ORIENTATION Feature Guard

[Gyuyoung Kim]

Hi,

I'm interested in this feature. So, I took Bug 92330 over. Though I rebased
the feature according to review comments, this feature doesn't work yet.
So, I have investigated why it doesn't work. However, unfortunately, I need
to have time a little further. If there is no big reason this patch should
be removed, I'd like to support this feature.

Gyuyoung.
 On Jun 5, 2013 9:45 AM, Mike Lawther mikelawt...@google.com wrote:

 Fwiw, the original author is no longer working on Blink, and the code has
 been removed from there.

 mike
 On Jun 5, 2013 1:24 AM, Brent Fulgham bfulg...@apple.com wrote:

 We have code in WebKit that is protected by the
 ENABLE(CSS_IMAGE_ORIENTATION) guard, but no active WebKit ports seem to
 enable this feature.

 Is anyone currently working on (or planning to work on) this feature?

 Since this CSS feature is currently in an early draft form, and is likely
 to change, we may not want to retain this dead code as it will most likely
 become obsolete very quickly.

 If no one wants to claim ownership of this feature in the next few days,
 I will submit a patch to remove the dead code.

 Thanks,

 -Brent
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 https://lists.webkit.org/mailman/listinfo/webkit-dev


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


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

Re: [webkit-dev] WebKit2 and ENABLE_PLUGIN_PROCESS

[Gyuyoung Kim]

I think EFL port will be fine to set ENABLE_PLUGIN_PROCESS unconditionally,
because the feature has been enabled on EFL WK2 with Netscape-plug-in.

Gyuyoung


On Tue, May 21, 2013 at 3:38 PM, Carlos Garcia Campos
carlo...@webkit.orgwrote:

 El lun, 20-05-2013 a las 15:15 -0700, Anders Carlsson escribió:
  Hello,
 
  is anyone building WebKit2 without ENABLE_PLUGIN_PROCESS set, running
 Netscape plug-ins in the web process?
 
  The reason I’m asking is that having two code paths complicates things
 and I’d like to remove the non-plug-in process code path.

 I think we removed the compile option in GTK port already.

  - Anders
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  https://lists.webkit.org/mailman/listinfo/webkit-dev
 


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

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

Re: [webkit-dev] Christophe Dumez is now a WebKit reviewer

[Gyuyoung Kim]

Congratulation !!! Chris !!

Gyuyoung


On Thu, May 9, 2013 at 5:22 PM, Laszlo Gombos laszlo.gom...@gmail.comwrote:

 Hi,

 I'm happy to announce that Christophe Dumez is now a WebKit reviewer.

 Chris has done great work on WebKit2 (test infrastructure, support for new
 device APIs) and one of the driving forces behind the EFL port. Lately he
 has been doing work on the Soup and GStreamer backends and the binding
 generators.

 Please join me in congratulating Chris !

 Thanks,
   Laszlo


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


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

Re: [webkit-dev] Sunsetting committership and reviewership

[Gyuyoung Kim]

+1

IMO, as Dirk suggested, the deactivation of the account is more reasonable
unless the reviewership or committership is revoked,

Gyuyoung


On Fri, Apr 5, 2013 at 4:10 PM, Dirk Schulze dschu...@adobe.com wrote:



 Sent from my iPhone

 On Apr 5, 2013, at 12:00 AM, Ryosuke Niwa rn...@webkit.org wrote:

 On Thu, Apr 4, 2013 at 11:53 PM, Kenneth Rohde Christiansen 
 kenneth.christian...@gmail.com wrote:

 I am not sure this is really needed. People sometimes disappear from
 working on trunk for extended periods of time due to internal products
 and downstream branches. It has happened multiple times to me. That
 doesn't mean that I won't come back and start working upstream later.

 Also it could be that some people working on Blink would like to
 contribute to WebKit in their spare time or in the future again.

 Part of being a reviewer is also knowing what and when to review, so I
 am not sure there really is an issue here.


 I'm not too concerned about the reviwership but more about committership
 from a security point of view.

 I don't think a lot of committers are going to monitor their old SVN
 accounts and update passwords periodically.  Having lots of inactive SVN
 accounts isn't that helpful.

 Maybe I didn't phrase it correctly, but I'm suggesting more of suspension
 so that we have a smaller attack surface for SVN credentials.


 Suggesting the deactivation of the SVN account is reasonable, as long as
 you get it back on request.

 Greetings
 Dirk


 - R. Niwa

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


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


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

Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files

[Gyuyoung Kim]

Hi,

It looks EFL port has ~ 60 test cases which say to do rebaseline in
TestExpectations file. I will remove them soon.

Gyuyoung.

On Thu, Mar 21, 2013 at 9:24 AM, Ryosuke Niwa rn...@webkit.org wrote:

 e.g. just in this afternoon, I was able to remove ~30 entries from
 platform/mac/TestExpectations.


 http://trac.webkit.org/changeset?new=146417%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectationsold=146296%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectations

 I bet there are a lot more entries in other platform/port's
 TestExpectations files.

 - R. Niwa


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


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

Re: [webkit-dev] Please don't leave entries for rebaseline in TestExpectation files

[Gyuyoung Kim]

I remove test cases which need to do rebaseline on EFL TestExpectations
file.
http://trac.webkit.org/changeset/146432

The removed test cases are going to be done rebaseline.

Gyuyoung.

On Thu, Mar 21, 2013 at 9:59 AM, Gyuyoung Kim gyuyoung@webkit.orgwrote:

 Hi,

 It looks EFL port has ~ 60 test cases which say to do rebaseline in
 TestExpectations file. I will remove them soon.

 Gyuyoung.

 On Thu, Mar 21, 2013 at 9:24 AM, Ryosuke Niwa rn...@webkit.org wrote:

 e.g. just in this afternoon, I was able to remove ~30 entries from
 platform/mac/TestExpectations.


 http://trac.webkit.org/changeset?new=146417%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectationsold=146296%40trunk%2FLayoutTests%2Fplatform%2Fmac%2FTestExpectations

 I bet there are a lot more entries in other platform/port's
 TestExpectations files.

 - R. Niwa


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



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

[webkit-dev] Is there a rule to use UNUSED_PARAM ?

[Gyuyoung Kim]

Hello WebKit folks,

There were build warning related to unused parameter nowadays. I think
there are three solutions. One is to remove parameter,
another is to use UNUSED_PARAM macro and the other is to use /* */ in
parameters.

I like to use UNUSED_PARAM macro except for primitive parameters
personally, for example

void foo(RenderObject* object, int /*width*/, int /*height*/) {
UNUSED_PARAM(object);
}

I'd like to know what webkittens think about this.

Cheers,
Gyuyoung
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is there a rule to use UNUSED_PARAM ?

[Gyuyoung Kim]

I think Dirk's explanation is reasonable. It seems to me that excessive
UNUSED_PARAM masses up codes. From a code readability perspective it is
good to use them commented out when parameter type or function name don't
stand for nothing. If Dirk's suggestion is best, IMHO, it would be good if
someone adds this(/* */) to #9 of webkit coding style Names as well.

Gyuyoung.

On Mon, Oct 1, 2012 at 11:07 PM, Dirk Schulze k...@webkit.org wrote:



 On Monday, October 1, 2012, Gyuyoung Kim wrote:

 Hello WebKit folks,

 There were build warning related to unused parameter nowadays. I think
 there are three solutions. One is to remove parameter,
 another is to use UNUSED_PARAM macro and the other is to use /* */ in
 parameters.

 I like to use UNUSED_PARAM macro except for primitive parameters
 personally, for example

 void foo(RenderObject* object, int /*width*/, int /*height*/) {
 UNUSED_PARAM(object);
 }

 I'd like to know what webkittens think about this.


 If it is crystal clear what the parameters stand for, omit them. If not,
 you find them commented out. UNUSED_PARAM is used when just some platforms
 of flagged features use parameters, others not.

 Dirk


 Cheers,
 Gyuyoung




-- 
Gyuyoung Kim
SW Engineer, WebKit EFL
Email : gyuyoung.kim at webkit.org
Phone : +82 10 9530 0209
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Is there a rule to use UNUSED_PARAM ?

[Gyuyoung Kim]

Thank you for kindly explanations. I will guide this according to this
mailing list.

Gyuyoung.

On Tue, Oct 2, 2012 at 3:33 AM, Ryosuke Niwa rn...@webkit.org wrote:

 On Mon, Oct 1, 2012 at 11:30 AM, Oliver Hunt oli...@apple.com wrote:


 On Oct 1, 2012, at 8:47 AM, Ryosuke Niwa rn...@webkit.org wrote:

 On Mon, Oct 1, 2012 at 7:07 AM, Dirk Schulze k...@webkit.org wrote:



 On Monday, October 1, 2012, Gyuyoung Kim wrote:

 Hello WebKit folks,

 There were build warning related to unused parameter nowadays. I think
 there are three solutions. One is to remove parameter,
 another is to use UNUSED_PARAM macro and the other is to use /* */ in
 parameters.

 I like to use UNUSED_PARAM macro except for primitive parameters
 personally, for example

 void foo(RenderObject* object, int /*width*/, int /*height*/) {
 UNUSED_PARAM(object);
 }

 I'd like to know what webkittens think about this.


 If it is crystal clear what the parameters stand for, omit them. If
 not, you find them commented out. UNUSED_PARAM is used when just some
 platforms of flagged features use parameters, others not.


 or only used in ASSERTs.


 That's what the ASSERT_UNUSED(variable, assertion) macro is for :D


 Yeah, just realized by reading Darin's reply.

 - Ryosuke


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




-- 
Gyuyoung Kim
SW Engineer, WebKit EFL
Email : gyuyoung.kim at webkit.org
Phone : +82 10 9530 0209
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New WebKit reviewer: Yuta Kitamura

[Gyuyoung Kim]

Wow, congratulation Yuta :-)

Gyuyoung

On Fri, Sep 14, 2012 at 1:01 PM, Adam Barth aba...@webkit.org wrote:

 Congrats Yuta!!

 Adam


 On Thu, Sep 13, 2012 at 8:56 PM, TAMURA, Kent tk...@chromium.org wrote:
  I'd like to announce that Yuta Kitamura yu...@chromium.org is now a
  WebKit reviewer.
 
  He has contributed to WebKit project for three years mainly in WebSocket
  area. He is a trustworthy authority on WebSocket area. If you worked on
  WebSocket issues, please involve him.
 
  --
  TAMURA Kent
  Software Engineer, Google
 
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev




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

Re: [webkit-dev] broken build.webkit.org?

[Gyuyoung Kim]

Thank you for your bug cc. I will also take a look this bug.

Gyuyoung

On Mon, Aug 6, 2012 at 7:43 PM, Osztrogonac Csaba o...@inf.u-szeged.huwrote:

 Hi,

 Your patch is unrelated to build.webkit.org breakage. Your patch only
 revealed a bug
 near watchlist. I filed a new bug for it: https://bugs.webkit.org/show_**
 bug.cgi?id=93250 https://bugs.webkit.org/show_bug.cgi?id=93250

 br,
 Ossy

 Gyuyoung Kim írta:

  Hello Ossy,

 I'm sorry. It looks  my commit made this problem. I just rolled out my
 r124728 in r124738.
 But, it is not adjust to buildbot first. Does anyone how to solve this
 problem?

 I'm sorry again.

 Gyuyoung.


  -Original Message-
 From: 
 webkit-dev-bounces@lists.**webkit.orgwebkit-dev-boun...@lists.webkit.org[mailto:
 webkit-dev-
 boun...@lists.webkit.org] On Behalf Of Osztrogonac Csaba
 Sent: Monday, August 06, 2012 4:17 PM
 To: WebKit Development
 Subject: [webkit-dev] broken build.webkit.org?

 Hi,

 It seems something happened with build.webkit.org. The latest build
 was 
 http://trac.webkit.org/**changeset/124728http://trac.webkit.org/changeset/124728on
  slaves. And now there
 are 7-10 pending builds on each slaves, but nothing happens. I think
 a master restart would solve this problem.

 Bill or Lucas, could you check what happened, please?

 br,
 Ossy
 __**_
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/**mailman/listinfo/webkit-devhttp://lists.webkit.org/mailman/listinfo/webkit-dev



 __**_
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/**mailman/listinfo/webkit-devhttp://lists.webkit.org/mailman/listinfo/webkit-dev




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

Re: [webkit-dev] EFL bot needs to rebuild WebCore derived sources

[Gyuyoung Kim]

Hello Geoffrey,

Thank you for your notification. I restart EFL buildbots which I maintain
with a clean build. Other bots are going to be fixed.

Gyuyoung.

On Fri, Aug 31, 2012 at 8:18 AM, Geoffrey Garen gga...@apple.com wrote:

 Hi folks.

 The EFL build is failing because the bot did not rebuild WebCore derived
 sources, despite a change to CodeGeneratorJS.pm.

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




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

Re: [webkit-dev] broken build.webkit.org?

[Gyuyoung Kim]

Hello Ossy,

I'm sorry. It looks  my commit made this problem. I just rolled out my
r124728 in r124738.
But, it is not adjust to buildbot first. Does anyone how to solve this
problem?

I'm sorry again.

Gyuyoung.


 -Original Message-
 From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-
 boun...@lists.webkit.org] On Behalf Of Osztrogonac Csaba
 Sent: Monday, August 06, 2012 4:17 PM
 To: WebKit Development
 Subject: [webkit-dev] broken build.webkit.org?
 
 Hi,
 
 It seems something happened with build.webkit.org. The latest build
 was http://trac.webkit.org/changeset/124728 on slaves. And now there
 are 7-10 pending builds on each slaves, but nothing happens. I think
 a master restart would solve this problem.
 
 Bill or Lucas, could you check what happened, please?
 
 br,
 Ossy
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org
 http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Question related to license in WK2 EFL port

[Gyuyoung Kim]

Thank you for your kind reply. My curiosities are solved. 
I will discuss which license we will use with my co-workers. 

Cheers,
Gyuyoung.

--- Original Message ---
Sender : Kenneth Rohde Christiansenkenneth.christian...@gmail.com
Date : 2012-07-25 18:46 (GMT+09:00)
Title : Re: [webkit-dev] Question related to license in WK2 EFL port

Hi,

The license is basically up to the contributor, though there might be
a few advantages using the BSD license.

Using BSD licensed code means that the code can be re-factored in the
future and parts can be moved into WebCore or elsewhere. If you use
LGPL you have to make sure to not reuse the code in any file licensed
as BSD.

Having the code licensed as BSD also means that your employer can
reuse code parts in other internal products. That is also possible if
the code is already under your copyright, but when other people start
contributing to it, it becomes less clear.

Cheers
Kenneth

On Wed, Jul 25, 2012 at 8:36 AM, Dumez, Christophe
wrote:
 Hi,

 This kind of decision is not easy to take and cannot necessarily be taken by
 us developers (our employers may favor one particular license).

 The WebKit project allows both Apple's new BSD or LGPL as far as I know. So,
 as long as contributors use one of those 2 licenses for WebKit-EFL, I don't
 see any problem with it.

 Kr,


 On Wed, Jul 25, 2012 at 8:50 AM, Gyuyoung Kim 
 wrote:

 Hello WebKit folks,

 I'd like to have your opinions on EFL port licensing. Currently it uses
 both LGPL and BSD, and there's no explicit rule in EFL port so far. So the
 license was decided by individual contributor when new file was submitted.
 Nowadays, some EFL contributors are confused which license should be used.

 I would like to know whether EFL folks can continue to choose which
 license to use. Or, is there any rule related to license?

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




 --
 Christophe Dumez
 Linux Software Engineer, PhD
 Intel Finland Oy - Open Source Technology Center


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




-- 
Kenneth Rohde Christiansen
Senior Engineer
Nokia Mobile Phones, Browser / WebKit team
Phone  +45 4093 0598 / E-mail kenneth at webkit.org

http://codeposts.blogspot.com ???
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Question related to license in WK2 EFL port

[Gyuyoung Kim]

Hello WebKit folks,
 
I'd like to have your opinions on EFL port licensing. Currently it uses both 
LGPL and BSD, and there's no explicit rule in EFL port so far. So the license 
was decided by individual contributor when new file was submitted. Nowadays, 
some EFL contributors are confused which license should be used.
 
I would like to know whether EFL folks can continue to choose which license to 
use. Or, is there any rule related to license?
 
Gyuyoung
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Is bugzilla down ?

[Gyuyoung Kim]

Hi webkit folks,

I can't aceess bugs.webkit.org now. It looks bugzilla system is not working 
correctly. Is bugzilla dead ?

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

Re: [webkit-dev] Is bugzilla down ?

[Gyuyoung Kim]

The notification was sent when I was sleeping. I read it now.

Thanks,
Gyuyoung.

 -Original Message-
 From: William Siegrist [mailto:wsiegr...@apple.com]
 Sent: Friday, July 20, 2012 10:36 AM
 To: gyuyoung@samsung.com
 Cc: webkit-dev@lists.webkit.org
 Subject: Re: [webkit-dev] Is bugzilla down ?
 
 See my earlier email about the migration.
 
 -Bill
 
 
 
 On Jul 19, 2012, at 6:31 PM, Gyuyoung Kim gyuyoung@samsung.com
wrote:
 
  Hi webkit folks,
 
  I can't aceess bugs.webkit.org now. It looks bugzilla system is not
 working correctly. Is bugzilla dead ?
 
  Gyuyoung.
  ___
  webkit-dev mailing list
  webkit-dev@lists.webkit.org
  http://lists.webkit.org/mailman/listinfo/webkit-dev

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

Re: [webkit-dev] Can protocol handler be moved to the modules ?

[Gyuyoung Kim]

I file a bug to extract a client interface for register protocol handler from 
ChromeClient.
 
- Bug 90940 - Add ProtocolHandlerClient.h to the Modules/protocolhandler
  (https://bugs.webkit.org/show_bug.cgi?id=90940)

In order to support this, the client needs to be supplementable first. I'm 
working in progress.

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

[webkit-dev] Can protocol handler be moved to the modules ?

[Gyuyoung Kim]

Hello folks,

I wonder whether protocol handler is able to be moved to the modules. I was 
told that protocol handler belonges Current Non-Modules Using Module-Related 
Techniques for Loose Coupling

== Current Non-Modules Using Module-Related Techniques for Loose Coupling ==
devicemotion
deviceoritentation
fileapi
html
notifications
protocolhandler
speechinput
svg
webgl
websql
workers
xml

http://lists.webkit.org/pipermail/webkit-dev/2012-February/019628.html

However, it seems to me protocol handler is now self-contained except for an 
interface which supports port implementation. In intents case, it also has 
similar interface in FrameLoaderClient.h.

Is there any reason that protocol handler can't be moved to the modules ?

I filed a bug for this and submitted a patch.
https://bugs.webkit.org/show_bug.cgi?id=90766

Cheers,
Gyuyoung.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] [webkit-efl] EFL Linux Debug Buildbot online

[Gyuyoung Kim]

Hi efl folks,

Great jobs !!

Why don't we make EFL category for our build bots ?
- http://build.webkit.org/

Cheers,
Gyuyoung.

2012/4/13 Dominik Röttsches dominik.rottsc...@linux.intel.com

  Hi,

 I am happy to inform you that the EFL Debug Buildbot got online tonight
 (EEST).
 By now it has completed its maiden build 0 :-)

 http://build.webkit.org/builders/EFL%20Linux%20Debug

 There's some tuning to do in the next few days, but it already gives us
 useful information.
 Let's continue to work on getting the bots green.

 Regards,

 Dominik

 --
 Dominik Röttsches dominik.rottsc...@linux.intel.com 
 dominik.rottsc...@linux.intel.com
 Intel Finland Oy
 Registered Address: PL 281, 00181 Helsinki
 Business Identity Code: 0357606 - 4


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




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

Re: [webkit-dev] EFL Debug Buildbot Green

[Gyuyoung Kim]

Wow, great !! EFL release bot will become green.

Gyuyoung.


On Fri, May 11, 2012 at 4:04 AM, Dirk Pranke dpra...@chromium.org wrote:

 +1 :).

 On Thu, May 10, 2012 at 12:01 PM, Ojan Vafai o...@chromium.org wrote:
  That's a great milestone. Congratulations!
 
  On Thu, May 10, 2012 at 8:43 AM, Dominik Röttsches
  dominik.rottsc...@intel.com wrote:
 
  Hi all,
 
  We're happy to share with you that yesterday the EFL Linux Debug
 Buildbot
  has turned green for the first time.
  http://build.webkit.org/builders/EFL%20Linux%20Debug
 
  This has been an example of a great team effort [1]. We'd like to thank
  the friendly reviewers and committers who helped us for their support!
 
  We'll keep a close eye on our buildbot lamp http://goo.gl/ei1gL from
 now
  and set up a gardening schedule to keep it green and tidy in the future.
 
  Dominik
 
  [1] http://wkb.ug/85601
 
  --
  Dominik Röttsches dominik.rottsc...@intel.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




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