On 2009.06.19., at 16:22, Simon Kaegi wrote:
That's great -- really looking forward to seeing it. We're at the
point now
where we have the transport and wire protocol support in place and are
working on the debugger model and the runtime command set. FWIW
we're using
the v8 debugger protocol for response, request and event envelopes
and are
now writing command tests and documenting.
FWIW, my work-in-progress is accessible in my "dynalang" project on
SourceForge if you wish to take a look at it.
Subversion is at <https://dynalang.svn.sourceforge.net/svnroot/dynalang
>. You can also browse the SVN at <http://dynalang.svn.sourceforge.net/viewvc/dynalang/trunk/
>. The modules you want are "debug" (language independent stuff - SPI
classes and the V8-implementing TCP service) and "debug-rhino" (SPI
implementation for Rhino).
The easiest way to get at it is to just check it all out, then delete
the "mop", "mop-rhino", and "jython" modules from it. That leaves you
with "debug" and "debug-rhino" modules, "ivy" directory for dependency
management, and the master "build.xml". Then execute "ant publish-
all". Both projects have Eclipse project files in them. All the stuff
I release is Apache-licensed, and I'm the sole copyright holder, so
it's easy to collaborate.
Notes on current state of affairs:
1. V8 protocol is poorly documented on <http://code.google.com/p/v8/wiki/DebuggerProtocol
>, so I had to make assumptions and wild guesses in places (most
notably, the stack frames format is completely undocumented). If you
have access to more detailed V8 docs, that'd be welcome.
2. Some V8 requests are still not implemented, as I didn't have
equivalents in my original debugger implementation. Most notably:
frame, scope, scopes, scripts, source. Also, "function" type
breakpoints aren't supported yet, only "script".
3. I have some capabilities beyond V8, which for now live as
proprietary extensions. I.e. I also have an "exception" breakpoint
type for defining exception breakpoints.
4. There are not yet any tests. The current codebase evolved from a
stable and working debugger codebase I wrote for my employer, but the
rewrite from our internal JSON wire format to V8 wire format
undoubtedly broke a thing or two. Don't assume it's really functional
yet.
5. I also have a simple command-line debugger client, but I haven't
adapted it for V8 protocol yet.
6. There's an unfortunate coupling of V8 wire protocol in the
implementation of evaluate() for Rhino adapter. I'm thinking of ways
to eliminate that.
I'm working on it as my time permits; mostly putting in few hours into
it on weekends. Let me know what you think.
The ref/handle problem you mention in the other thread is
interesting and
something I'll take a deeper look at as I believe our current debug
model
needs it. You're right that it has potential to be simply horrible
as we
don't want to be in a situation where we track every object on the
debug
runtime side. I'll ask around as the problem (and good approaches)
might be
already well understood from work in other languages.
Actually, it's not bad. The lifetime of the IDs is a single debug
event (i.e. a single suspension between steps). So you only need to
number objects as you hand them out to the debugger client, and ditch
the mapping as soon as execution resumes.
-- Attila.
-Simon
"Attila Szegedi" <[email protected]> wrote in message
news:mailman.1493.1245408260.5555.dev-tech-js-engine-rh...@lists.mozilla.org
...
Just a heads up that I got a green light to publish my debugger
implementation. I'm sorting out the source code now, will keep you
posted.
Attila.
On 2009.06.03., at 17:14, Simon Kaegi wrote:
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
