Google Chrome Developer Tools for Eclipse Users

[Patrick Mueller]

Saw this last night:

blog post: http://blog.chromium.org/2009/08/google-chrome-developer-tools-for.html
project: http://code.google.com/p/chromedevtools/

Also refers to "Google Chrome Developer Tools Protocol", another
debugging (and other things) protocol:

http://code.google.com/p/chromedevtools/wiki/ChromeDevToolsProtocol

Patrick Mueller - http://muellerware.org/

[mcollins]

On Aug 5, 7:06 am, Patrick Mueller <pmue...@yahoo.com> wrote:
> Also refers to "Google Chrome Developer Tools Protocol", another  
> debugging (and other things) protocol:
>
>    http://code.google.com/p/chromedevtools/wiki/ChromeDevToolsProtocol
>
> Patrick Mueller -http://muellerware.org/

The "and other things" I think is the interesting part of this
protocol. The Dev Tools protocol essentially just wraps the V8
protocol for Javascript debugging, and adds support for finding out
information about Chrome tabs. I think it's an interesting design
choice. On the one hand, the V8 protocol remains simpler for anyone
who wants to use it as a debugger for Javascript outside of a web
browser context. On the other hand, you now have 2 separate projects/
places to collate the entire protocol if you are just interested in
debugging web pages. I assume that they plan to add more 'other
things ' in the near future though.

Mike

[Attila Szegedi]

Yep, I pulled it down and started to see how to fit it into the Rhino
remote debugger adapter I'm working on. The creation of an envelope
protocol around the V8 debugger protocol is indeed a clever idea for
two reasons: it allows extensibility, and by mandating the
transmission of a content length for each message, it makes finding
the end of an individual message easy (otherwise you'd need to parse
JSON as you read it until you come to the end of the top-level JSON
object literal for the message).

I'm still fairly frustrated at the incompleteness of the documentation
though - if you look at both <http://code.google.com/p/chromedevtools/wiki/ChromeDevToolsProtocol
> and <http://code.google.com/p/v8/wiki/DebuggerProtocol> you'll see
there's a fair bit of questions I posted in the comments. The
DebuggerProtocol page was updated recently though - before that, not
even the stack frame format was documented... At least now with Java
source code for the protocol client, I can try to reverse engineer few
things (and unfortunately, also come across its usage of further
undocumented fields... :-( )

Attila.

[Colin Fraser]

Hi Atilla,

On Aug 6, 5:36 pm, Attila Szegedi <szege...@gmail.com> wrote:
> Yep, I pulled it down and started to see how to fit it into the Rhino  
> remote debugger adapter I'm working on.

I'd like to know how you get on with the Rhino wrapper.

I was just considering whether something similar would be possible for
the embedded Spidermonkey engine we use in our products. Someone on
the ServerJS group (http://groups.google.com/group/serverjs) did
something similar already called Piston (http://code.google.com/p/
piston/) where they implemented an Eclipse plug-in for debugging
Spidermonkey JS over an HTTP connection but I suspect the google tools
will end up more fully featured.

The lack of documentation seems to be a common problem with all of
these debugger implementations.

Colin

[Sigbjorn Finne]

Hi Attila,

this is indeed another interesting effort and promising extension for the v8
protocol and API (as is your remote debugger for Rhino.) Has anyone
looked at
how it fits into the feature matrix that was posted a while ago &
whether there is
enough commonality to start working towards a unified arch and protocol?

cheers
--sigbjorn

[mcollins]

Just updated the google spreadsheet to add Piston to the protocols
matrix, hadn't heard of it before now. Looks like an interesting
project, and a good example of what the minimum functionality needs to
be to make a debugger useful.

Mike

[Attila Szegedi]

On 2009.08.07., at 12:00, Colin Fraser wrote:

>
> Hi Atilla,
>
> On Aug 6, 5:36 pm, Attila Szegedi <szege...@gmail.com> wrote:
>> Yep, I pulled it down and started to see how to fit it into the Rhino
>> remote debugger adapter I'm working on.
>
> I'd like to know how you get on with the Rhino wrapper.

I did progress with it a bit, but it's not in usable state right now.

I might need to decide on some architectural changes too; I originally
set out to create a generic debugger for dynamic languages on the JVM,
with modular separation of common stuff (transport, session handling,
breakpoint bookkeeping) and language specific stuff (responding to
breakpoints, generating stack traces, evaluating expressions). Reason
I did this is that my work originates from a remote debugger I
developed at my day job (with my own simple JSON-based TCP protocol),
and there I have a system where the language runtime is actually
pluggable, and the debugger works on a lower service infrastructure
level, and it would've been a bad architecture to introduce a reverse
dependency (from a lower layer to a higher layer).

This creates a bit of an impedance mismatch with a transition of the
wire protocol to V8 protocol, as V8 is decidedly a JS-specific
protocol (scopes, prototype reference in serialized format of objects,
etc.), and it caused enough suspiciously looking constructs in the
code that I'm seriously thinking of abandoning the language
independence (yes, it's a tradeoff; yes, I tried to marry the two in
the hope it'll work out okay, but it doesn't seem like it will).

I'm admittedly spread a bit thin - I have a day job, and I'm also
working on another project in my spare time (JVM Dynamic Languages
Metaobject Protocol) that I want to ready for the JVM Language Summit
that starts in a month. Both this and the remote Rhino debugger are
equally dear to my heart, but since I have a specific self-imposed
conference deadline with the MOP protocol, I'm giving it a priority
until it's done (which I'd like to think is close; for any Javaheads
out there, let me say that dynamically linking to a set of overloaded
methods, some of them with variable number of arguments is one tough
corner case to get right... anyway.) I was on a vacation for the two
weeks preceding this week, and that's when I made some progress on it.
Actually, the most of the problems I hit were due to the architectural
impedance mismatch I described above - producing an interface for
language-independent transfer of data for benefit of a language-
specific protocol just looks ugly. If I gave in and said, okay, let's
make this JS specific, I'd end up with a considerably simpler
architecture.

It's possible that I might go to the length of making the
architectural cleanup; I already have the handling of transport
specific bits implemented, plus few V8 commands. If I did that, it'd
be possible that someone else also joins the effort and then it no
longer only depends on my free time...

Attila.