I am currently writing a prototype of a debugger server for Servo that
works with the Chrome Debugging Protocol:
https://github.com/ejpbruel/servo/tree/acceptor
The Chrome Debugging Protocol works by first sending a HTTP request to
http://localhost:/json (where is the remote debugging
port).
-- Forwarded message --
From: Eddy Bruel <ejpbr...@mozilla.com>
Date: Mon, Sep 19, 2016 at 5:45 PM
Subject: Maintaining a list of debugging targets in the debugger.
To: Jim Blandy <j...@mozilla.com>, se...@mozilla.com
Cc: Patrick Brosset <pbros...@mozilla.com>
>
> So whichever tool you use for this, please make sure that the API
> encourages the correct behavior.
>
> Cheers,
> David
>
> On 16/11/16 14:16, Eddy Bruel wrote:
> > For the Servo debugger, now that we've begun landing the Rust interface
> to
> > the Debug
For the Servo debugger, now that we've begun landing the Rust interface to
the Debugger API, we can also started working on the next step, which is an
IPC client/server on top of that Rust interface. This IPC server will allow
the main debugger server, which lives in a separate process, to talk to
For the Servo debugger, we need some kind of IPC layer:
The debugger server (i.e. the thing that talks the Chrome debugging
protocol) needs to live in the same process (and perhaps even the same
thread) as the constellation; it needs to work closely with the
constellation to figure out which
Hello!
I am sure most of you are already aware of this, but for those of you who
are not: the devtools team is taking its first steps towards implementing a
JS debugger for Servo!
As part of this process, we started working on a Rust interface for the
SpiderMonkey debugger API a couple of weeks
6 matches
Mail list logo
