I reviewed the V8 debugger protocol wire format, and it's fairly
similar to the format I have - the concept of commands/responses, and
asynchronous events when breakpoints are hit are actually the same.
There's one feature of V8 debugger protocol though that make it a no-
go. Namely, they're using data points named "ref" in it, which is
basically an identifier for uniquely identifying an object. It's used
in results of evaluations (i.e. if an object has a property whose
value is another object, it'll contain a ref. I suspect "ref" will be
a value derived from the object's memory pointer within the runtime,
maybe mangled using some automorphic transform.
Now, we could create a "ref" from an object in Rhino - just take the
Java object, and apply System.identityHashCode(). The problem is in
the other direction - given a "ref", we can't resolve it back to an
object. Not unless we have a global map tracking the objects, which'd
be quite unfeasible, even in debugger scenarios, I think.
So, I can make the wire protocol as similar to V8's as possible if
that's desirable (as I said, it's already fairly similar, so it's a
matter of renaming identifiers), but it'll at best be an incompatible
dialect.
Also, my debugger protocol has some capabilities V8 doesn't have,
namely, debugging in presence of continuations, as well as using
regular expressions for identifying script URLs for breakpoints, as
well as watchpoints (conditional breakpoints without assigned line
number). Again, I can try to keep it close in spirit and syntax to
theirs.
Attila.
On 2009.06.03., at 17:25, Simon Kaegi wrote:
Also, any thoughts on http://code.google.com/p/v8/wiki/
DebuggerProtocol
"Simon Kaegi" <[email protected]> wrote in message
news:[email protected]...
Attila,
Add me to the list of people who would really like to see this.
I work on the Eclipse project and am currently working on support for
writing plugins in JavaScript/Rhino. We really need debug support
and had
been looking at JSR45. I'm about ready to throw in the towel with
that
approach and look more closely at coming up with a remote API to
allow use
of Rhino's interpreter mode debug stuff. It would be great to not
re-invent the wheel here and ideally build on something by someone
in the
know.
I've also been chatting with our debug folk and it sounds like we
could do
something very interesting in the debug UI where we have a split
Java /
JavaScript model that's smart enough to know which language we're
in at
various points on the stack.
Anyway, it would be great to see what you or others have done on a
remote
api to the debugger.
-Simon
"Attila Szegedi" <[email protected]> wrote in message
news:mailman.292.1241256119.22264.dev-tech-js-engine-rh...@lists.mozilla.org
...
Been there, done that just two months ago (it's a remote debugger
with a
command-line interface). It's moderately involved... I did it as
a day
job project at my company, so can't provide source code (and it
has some
proprietary parts anyway, particularly the definition of a script
execution instance, as well as support for debugging across
continuation
restarts). For what's it worth, the solution I created has a
separate
server side and client side, and I created a simple network
protocol
where the parties pass JSON messages through a TCP connection, so
it
would be possible to use the protocol and fit a GUI at the other
end
instead of the CLI.
If there's enough interest, I might try to strip out the proprietary
stuff and obtain permission to release it as open source (the
company is
fortunately fairly friendly to open source).
Attila.
On 2009.05.01., at 23:15, SCWells72 wrote:
We're embedding Rhino in our system as an extensibility tool and
that's going very well. I imagine it would be very useful for
extenders of our system to be able to debug their scripts in a
high-
level symbolic debugger. I found the Rhino debugger here:
http://www.mozilla.org/rhino/debugger.html
but it looks like that's intended to be used against a script
file or
some other direct input.
I was wondering if anyone had any experience with using this
debugger
against an embedded Rhino engine successfully. I imagine it's too
much to ask for remote debugging, but minimally if I could tell the
app to bring up the debugger window when (certain) scripts are
executing and allow me to set breakpoints, step through execution,
etc.
I searched the Rhino pages, this forum, and Google in general and
didn't find a clear answer. I apologize if this has been asked/
answered before.
Thanks!
Scott
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
