headers
Young Han Lee | 2 Aug 2011 03:22
Picon

Re: Remote Debugging v8 - Android

Hi, Jose.

Our team had implemented the remote debugging feature on our custom Android port.
This[1] is a brief article about that.
I hope it will be helpful.
(It is under development, so you cannot get the code yet)

Regards,
Young Han.



On Thu, Jul 7, 2011 at 3:46 PM, JOSE MANUEL CANTERA FONSECA <jmcf <at> tid.es> wrote:

Hi there,

 

I have two technical questions concerning the Webkit Remote Debugging Protocol.

 

a/ What is the difference / relationship between this protocol and the v8 remote debugging capabilities?

 

b/ How this protocol could be enabled for an Android device?

 

all the best

 

thanks

 


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

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


_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Permalink | Reply | 1 comment |
headers
Pavel Feldman | 2 Aug 2011 11:35

Re: Remote Debugging v8 - Android

Note that this solution is using V8-based protocol that we are deprecating in Chrome. Chrome DevTools for Java (Eclipse plugin being discussed) will support both: V8 protocol (for Node and other V8-based solutions) and WebKit Remote Debugging Protocol (for WebKit-based browsers) going forard. I would recommend using the latter for the complete remote debugging of the embedded browser.


Regards
Pavel

On Tue, Aug 2, 2011 at 5:22 AM, Young Han Lee <joybro201 <at> gmail.com> wrote:
Hi, Jose.

Our team had implemented the remote debugging feature on our custom Android port.
This[1] is a brief article about that.
I hope it will be helpful.
(It is under development, so you cannot get the code yet)

Regards,
Young Han.



On Thu, Jul 7, 2011 at 3:46 PM, JOSE MANUEL CANTERA FONSECA <jmcf <at> tid.es> wrote:

Hi there,

 

I have two technical questions concerning the Webkit Remote Debugging Protocol.

 

a/ What is the difference / relationship between this protocol and the v8 remote debugging capabilities?

 

b/ How this protocol could be enabled for an Android device?

 

all the best

 

thanks

 


Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

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



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


_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Permalink | Reply | 0 comments |
headers
g4@novadsp.com | 2 Aug 2011 12:50
Favicon

Re: Request for Update to Windows Development Environment

Hello Patrick

On 13/07/2011 22:28, Patrick Gansterer wrote:
>
> I've created already a CMake based version of AppleWindows port. I've compiled it with VS2010, but it
should work with the other version too.
> The main reason why I din't created a patch with my changes is, that the Windows port has some "uncool"
dependencies. E.g. the QuickTime project needs a different include path, because it's not compatible
with the Core* libraries.
>
Are the cmake scripts available?

Thx
Permalink | Reply | 0 comments |
headers
Scott Graham | 2 Aug 2011 23:53

Loader debug viewing in gdb

Hi,


I've been trying to debug some lifetime issues in Loader-related code. I was finding it quite challenging to visualize how the objects connect and interrelate, especially as links change over time. To help a bit, I wrote a small python script for gdb that displays a graph of related objects. https://bugs.webkit.org/show_bug.cgi?id=65574

The dump/view part of it is written somewhat generically and takes a map of types to operate on. It allows for collapsing logically connected objects into one graph node in the diagram to avoid huge sprawl. (see attached diagram where e.g. m_ptr RefPtrs are collapsed into their containing object).

I've only defined the type map for a viewer for Loader-related objects ("viewloadergraph" in gdb) but it should be obvious how to add a similar command for other subsystems. Perhaps it will be useful to someone, or someone'll have an idea to make it more useful.

scott


_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Permalink | Reply | 1 comment |
headers
Adam Barth | 2 Aug 2011 23:59
Favicon

Re: Loader debug viewing in gdb

Here's a diagram of the relation between these objects that I drew a while back:

https://docs.google.com/drawings/d/1V3JZltHfNU0HN9bPlLrHOC_yYTriPgv4Dv-LRamymFU/edit?hl=en_US

It might not be 100% accurate anymore.

Adam

On Tue, Aug 2, 2011 at 2:53 PM, Scott Graham <scottmg <at> chromium.org> wrote:
> Hi,
> I've been trying to debug some lifetime issues in Loader-related code. I was
> finding it quite challenging to visualize how the objects connect and
> interrelate, especially as links change over time. To help a bit, I wrote a
> small python script for gdb that displays a graph of related
> objects. https://bugs.webkit.org/show_bug.cgi?id=65574
> The dump/view part of it is written somewhat generically and takes a map of
> types to operate on. It allows for collapsing logically connected objects
> into one graph node in the diagram to avoid huge sprawl. (see attached
> diagram where e.g. m_ptr RefPtrs are collapsed into their containing
> object).
> I've only defined the type map for a viewer for Loader-related objects
> ("viewloadergraph" in gdb) but it should be obvious how to add a similar
> command for other subsystems. Perhaps it will be useful to someone, or
> someone'll have an idea to make it more useful.
> scott
>
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev <at> lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
Permalink | Reply | 0 comments |
headers
Martin Robinson | 3 Aug 2011 00:22
Favicon
Gravatar

Committer Nomations: Amruth Raj and Ravi Phaneendra Kasibhatla

I'd like to nominate both Amruth Raj and Ravi Phaneendra Kasibhatla as
WebKit committers. Amruth and Ravi worked together to create the
foundation of the GTK+ WebKit 2 port. Ravi Phaneendra Kasibhatla has
13 commits (of which 11 are shared commits between himself and
Amruth), while Amruth has 15 commits. Their commits have been reviewed
by myself, Darin Adler, and Kenneth Rohde Christiansen.

--Martin
Permalink | Reply | 1 comment |
headers
Martin Robinson | 3 Aug 2011 00:27
Favicon
Gravatar

Re: Committer Nomations: Amruth Raj and Ravi Phaneendra Kasibhatla

On Wed, Aug 3, 2011 at 12:22 AM, Martin Robinson <mrobinson <at> webkit.org> wrote:
> I'd like to nominate both Amruth Raj and Ravi Phaneendra Kasibhatla as
> WebKit committers. Amruth and Ravi worked together to create the
> foundation of the GTK+ WebKit 2 port. Ravi Phaneendra Kasibhatla has
> 13 commits (of which 11 are shared commits between himself and
> Amruth), while Amruth has 15 commits. Their commits have been reviewed
> by myself, Darin Adler, and Kenneth Rohde Christiansen.

I would like to apologize for sending this to the wrong list. Please
disregard this message.

--Martin
Permalink | Reply | 0 comments |
headers
TAMURA, Kent | 5 Aug 2011 03:40

More feature flags for input types (Re: New Feature Flag Proposal: INPUT_COLOR)

Like INPUT_COLOR, I'd like to introduce feature flags for date, datetime, datetime-local, month, time, and week types.

* We're going to implement dedicated UIs for them, and will want to disable it temporarily.
* Their current implementations are insufficient and one might not want to ship them in browsers, but they were already shipped in some browsers.

On Tue, May 24, 2011 at 09:57, Keishi Hattori <keishi <at> webkit.org> wrote:
Hi webkit-dev,

I just wanted to notify everyone that I will be adding a new feature
flag, INPUT_COLOR. http://webkit.org/b/61273

This flag will enable <input type=color>

I need this flag because the color picker UI needs to be implemented
individually for each platform, and it is going to take some time.

Also the current text field implementation will be disabled. This is
to avoid feature detection so that web pages can fall back to JS color
pickers.

Thanks!

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



--
TAMURA Kent
Software Engineer, Google 



_______________________________________________
webkit-dev mailing list
webkit-dev <at> lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Permalink | Reply | 3 comments |
headers
Darin Adler | 5 Aug 2011 20:05
Picon
Favicon

Re: More feature flags for input types (Re: New Feature Flag Proposal: INPUT_COLOR)

On Aug 4, 2011, at 6:40 PM, TAMURA, Kent wrote:

> Like INPUT_COLOR, I'd like to introduce feature flags for date, datetime, datetime-local, month, time,
and week types.
> * We're going to implement dedicated UIs for them, and will want to disable it temporarily.
> * Their current implementations are insufficient and one might not want to ship them in browsers, but they
were already shipped in some browsers.

These are both good reasons to have a feature flag and I think it’s critical we do that. But is there any
grouping we can do? Does each need a separate feature flag?

    -- Darin
Permalink | Reply | 2 comments |
headers
Darin Adler | 5 Aug 2011 20:12
Picon
Favicon

Current legacy argument refactoring -- behavior changes?

Hi Mark.

I assume that the legacy argument refactoring you are doing right now has a goal of no behavior changes. But
I’ve noticed some cases where arguments are not marked optional in a few of the patches. Possibly I
misunderstood the patch. One example was arguments in canvas rendering context functions.

If you we want to make behavior changes, I think it would be done in a patch without other refactoring. I’m
sure we’ll want to change at least some, but not mixed in with the refactoring under “accidental cover
of darkness”.

I have two questions:
- Did any of the recent refactoring patches change behavior?
- Do you know if have test coverage for the optional arguments?

    -- Darin
Permalink | Reply | 6 comments |

Gmane