Rhino debugger against embedded engine
SCWells72
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
Johan Compagner
(and the rest like editor/formatter)
> _______________________________________________
> dev-tech-js-engine-rhino mailing list
> dev-tech-js-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
>
SCWells72
> The dltk project of eclipse has also a javascript debugger for rhino
> (and the rest like editor/formatter)
Thanks. I just installed DLTK and am trying to figure out exactly how
to get started with it. I've scanned the DLTK site and can't find
anything about how I could wire up remote debugging using DLTK against
a Rhino engine running elsewhere. Cursory searching makes it sound
like this might be possible. Any tips on how to get going there?
David P. Caldwell
> 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 run the debugger inside Tomcat -- not remotely, but locally, such that
the Tomcat process will literally pop up the GUI when I execute a script
inside the process. The code to do it is buried inside a big framework
of mine, but it looks like it's a few hundred lines of code and the
general approach is to instantiate
org.mozilla.javascript.tools.debugger.Dim and use its attachTo() method
to attach it to the context factory my embedding is using.
Interestingly, as I look at the code, I attach it twice, but I suspect
this is just bad coding.
I then attach an org.mozilla.javascript.tools.debugger.SwingGui to the
Dim. Then when executing a script we need to use the setScopeProvider()
method to set the scope and then show the GUI. We also need to tell the
GUI not to do System.exit() via setExitAction.
I also have a profoundly ugly way of setting breakpoints by starting a
JavaScript source line with >; I then parse these out when executing
scripts, removing them from the code and setting breakpoints in the
debugger using Dim.sourceInfo(). There may be a cleaner way but this
has worked for me.
So it's quite possible in principle, but at least for me, was not a
trivial task to set up the first time ... hope this helps you or someone
else curiously reading this thread.
-- David P. Caldwell
http://www.inonit.com/
Attila Szegedi
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.
wolffiex
+1 for this source code! I would find this invaluable!
A
Johan Compagner
(i am just checking it out directly from cvs)
But they should be here:
http://download.eclipse.org/technology/dltk/downloads/drops/R1.0/I-I200904280953-200904280953/
We are using that for our product,
The key is the code that sits in this eclipse
plugin: org.eclipse.dltk.javascript.rhino.dbgp
That code has the debugger api that runs in the client that you want to
debug.
remote debugging is not possible currently with the current code. I have a
patch on that that makes that possible
(that eclipse just connects to a debug process instead of wanting to start
one)
johan
Colin Fraser
I am in a similar situation - I've tried using the DLTK stuff but I don't
see how to connect it to my embedded Rhino engine. Did you manage to make
any progress with DLTK? If so have you any tips or useful links for getting
it running?
I have successfully used the standard Rhino debugger and that works well but
it would be nice if it debugging was integrated with the Eclipse IDE.
Thanks,
Colin
"SCWells72" <scott...@gmail.com> wrote in message
news:559e5c66-4268-4e93...@3g2000yqk.googlegroups.com...
Johan Compagner
rhino engine
By default if you want to run a js file you can say debug that js file and
then dltk will just do that
If you want to debug remotely a rhino engine that is there running then you
need to patch the dltk to support that
I have already that patch an bit old version is here:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=221825
that is currently not in the dltk because it is kind of an hack on top of
it.
And it is working for us now
But to connect to a rhino debug eninge you will need the:
org.eclipse.dltk.javascript.rhino.dbgp
plugin/jar besides your rhino code. Because that is the debugger
implementation.
see for example DefaultRhinoRunner what is exactly does.
johan
Terry Braun
couple of times and tried to get it to debug a simple js file and
failed. I selected the engine to use, then did "Debug" and I can see a
process that runs, but the breakpoints don't work as far as I can see -
anyone had any luck or know where there is some documentation on how to
use it?
Thanks
Terry
Johan Compagner
this one:
http://download.eclipse.org/technology/dltk/downloads/drops/R1.0/S-1.0M7-200905061301/
should work fine
i cant quickly test it for you because of the patched nature of my own
stuff. But for simple javascript files you should able to debug through
them just fine
On Wed, May 13, 2009 at 13:27, Terry Braun <t...@talking.com> wrote:
> I have the same problem with DLTK - I've installed the whole thing a couple
> of times and tried to get it to debug a simple js file and failed. I
> selected the engine to use, then did "Debug" and I can see a process that
> runs, but the breakpoints don't work as far as I can see - anyone had any
> luck or know where there is some documentation on how to use it?
>
> Thanks
> Terry
>
>
>
> Colin Fraser wrote:
>
Colin Fraser
"Johan Compagner" <jcomp...@gmail.com> wrote in message
news:mailman.23.1242212923.1636...@lists.mozilla.org...
>
> If you want to debug remotely a rhino engine that is there running then
> you
> need to patch the dltk to support that
> I have already that patch an bit old version is here:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=221825
>
Thanks for the link - your patch sounds exactly what I'm looking for. Do
you know if it is likely to make it into the upcoming Eclipse 3.5 release?
Colin
SCWells72
> Thanks for the link - your patch sounds exactly what I'm looking for. Do
> you know if it is likely to make it into the upcoming Eclipse 3.5 release?
>
> Colin
Agreed. I would love to see this as out-of-the-box behavior. I'm
curious, though...when you run against an embedded Rhino engine, does
the server transfer the script being executed to the debug client for
display? I ask because our embedded Rhino engine runs scripts that
aren't stored in a local project or anything...they're stored in the
database (and are authored by business users as part of application
configuration). I'm still not entirely clear here about how the
debugger works overall...
Thanks,
Scott
Johan Compagner
else you cant set breakpoints and so on
Its just like normal java debugging. You have to have the sources.
Simon Kaegi
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" <szeg...@gmail.com> wrote in message
news:mailman.292.1241256119.222...@lists.mozilla.org...
Simon Kaegi
"Simon Kaegi" <simon...@ca.ibm.com> wrote in message
news:yP6dnQ5hcbD-DrvX...@mozilla.org...
malcolm handley
> Also, any thoughts onhttp://code.google.com/p/v8/wiki/DebuggerProtocol
>
> "Simon Kaegi" <simon_ka...@ca.ibm.com> wrote in message
>
> news:yP6dnQ5hcbD-DrvX...@mozilla.org...
>
> > 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
>
Based on http://osdir.com/ml/mozilla.devel.jseng/2005-09/msg00077.html
I was able to attach a debugger to an embedded rhino instance without
difficulty.
Here's the gist of what I did:
If I want a debugger then I create my ContextFactory like this:
ContextFactory contextFactory =
org.mozilla.javascript.tools.shell.Main.shellContextFactory;
// This code is mostly copied from
//
org.mozilla.javascript.tools.debugger.Main#mainEmbeddedImpl. The
// difference is that we do not call main.doBreak(), which
would cause
// the debugger to stop on the first line of code that it
executes.
Main main = new Main("JS Debugger");
main.setExitAction(new Runnable() {
public void run() {
System.exit(0);
}
});
main.attachTo(contextFactory);
main.setScopeProvider(new ScopeProvider() {
public Scriptable getScope() {
throw new UnsupportedOperationException();
}
});
main.pack();
main.setSize(600, 460);
main.setVisible(true);
Otherwise I just do this:
contextFactory = Context.enter().getFactory();
Then I create a context. Note that the page that I linked to says that
Context#enter is dangerous but I'm calling ContextFactory#enterContext
anyway. That's because I couldn't see any other way to get a context
and it seems to work fine.
contextFactory.enterContext();
After that I execute the javascript just as before.
Attila Szegedi
implementation. I'm sorting out the source code now, will keep you
posted.
Attila.
Attila Szegedi
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.
Terry Braun
This is great news!
Thanks!
Attila Szegedi wrote:
> 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.
Simon Kaegi
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.
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.
-Simon
"Attila Szegedi" <szeg...@gmail.com> wrote in message
news:mailman.1493.1245408260.55...@lists.mozilla.org...
Attila Szegedi
client side? Because I'm now working on a Rhino-attached debugger
server-side TCP service that talks V8 debug protocol.
FWIW, in my design I could cleanly separate the wire protocol stuff
from the actual debugger implementation, so I can even have other non-
JS languages retrofitted very easily on the TCP service (as long as
they have interpretive mode where we can hook in for breakpoints,
inspect native stack and so on). V8 protocol does have some JS
specific tidbits though (i.e. scopes) that wouldn't necessarily apply...
Also, note that independently a thread on "Multi-language debugging"
arose on the jvm-languages list, see <http://groups.google.com/group/jvm-languages/browse_thread/thread/58be007df982924c
> if you're interested. I'll write there too to point to this thread
as it might be of mutual interest.
Attila.
Simon Kaegi
> Wait, are we duplicating effort here? Or are you focusing on the client
> side? Because I'm now working on a Rhino-attached debugger server-side
> TCP service that talks V8 debug protocol.
>
the work for us will be on the client side especially if something like V8DP
gains traction and is supported with other runtimes. The work we're doing on
server integration with the rhino runtime is a stop-gap measure as we
currently have nothing to work against. I'm less fussed about transort layer
stuff as we have an exisiting piece that abstracts that out however I'd be
really interested to see what you're doing in your Debugger and Listeners in
terms of generating events, answering requests, checking for breakpoints,
breaking, continuing etc. This is the piece we're least experienced with and
would benefit the most from working with and improving on an exisiting
implementation. It would be ideal if this found it's way into the Rhino
distribution.
> FWIW, in my design I could cleanly separate the wire protocol stuff from
> the actual debugger implementation, so I can even have other non- JS
> languages retrofitted very easily on the TCP service (as long as they
> have interpretive mode where we can hook in for breakpoints, inspect
> native stack and so on). V8 protocol does have some JS specific tidbits
> though (i.e. scopes) that wouldn't necessarily apply...
>
Yes. I totally agree that this protocol has potential for other languages;
as you pointed out in the other thread it's way easier than re-implementing
something like JDWP and the JDI connect stuff.
> Also, note that independently a thread on "Multi-language debugging"
> arose on the jvm-languages list, see
> <http://groups.google.com/group/jvm-languages/browse_thread/thread/58be007df982924c
> > if you're interested. I'll write there too to point to this thread
> as it might be of mutual interest.
>
Thanks. We're interested in a mixed-mode (e.g. multi-language) debugger
where we connect using JDWP on one port and V8DP on another and then have a
client side model that stitches them together into something sensible. I
spent some time with JSR45 and just felt it wasn't sufficient for producing
a decent js debugger for rhino without a huge effort.
Frank Gerhardt
I just tried it and could not get it to work either. I can see that a
second JVM is started but the debugger does not stop a my breakpoints.
When I pause the main thread, I see this stack trace:
hello.js [JavaScript]
JavaScript/JDT debugging engine [session id: dbgp_1246666995718]
RhinoRunner at localhost:2088
Thread [main] (Suspended)
Object.wait(long) line: not available [native method]
DBGPDebugger(Object).wait() line: 485
DefaultRhinoRunner.run(String[]) line: 33
RhinoRunner.main(String[]) line: 7
C:\Programme\Java\jdk1.6.0_11\bin\javaw.exe (04.07.2009 02:23:15)
Waiting...
Can anybody confirm that the debugger is working at all? And possibly
provide some instruction for debugging a hello world program?
I tried it with SDK 3.5 and DLTK 1.0RC5.
Frank.
Attila Szegedi
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 Kaegi
>
> 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).
>
Thanks Attila,
Here's a pointer to our work (EPL) in CVS.
Host: dev.eclipse.org
Repository path: /cvsroot/eclipse
Module:
e4/org.eclipse.e4.languages/bundles/org.eclipse.e4.languages.javascript.debug
--
I took a very quick look this morning at the api and doc for your code and
as expected we have lots of overlap. Some of the main differences I
noticed...
1) You have a sessionregistry where as we have one session that uses a
ContextListener to track different contexts
2) Your version has some javadoc -- ours well not so much.
3) We use suspend events when a new context is created and a script is
loaded. This is in line without JPDA works and has some advantages in terms
of locating and matching script locations. Your matching is using regular
expressions (I think)
4) We support frame serialization -- we're treating them like dumb objects
with just properties.
5) I haven't looked to deeply into the socket level details of your protocol
but we also send a content length in addition to the JSON messsage.
6) You have some language agnostic debug concepts built in. We don't yet but
are also interested in supporting othe JVM based languages eventually.
All in all pretty similar. At this stage both code bases are tiny so it
probably be good to select one as a base, integrate where it makes sense and
go from there.
For the remainder of the week we're really just writing unit tests and the
like and ensuring what we have so far is more or less complete. Next week
I'm hoping our client work will begin landing in the repo as I'm guessing
that's when we'll really find out what's missing from the debug protocol and
what's redundant. Our main goal is client centric and in a nutshell we're
trying to hammer out the details of a remote js debug protocol and reach
agreement with the other folk like firebug and dragonfly. I'm absolutely
game for collaborating on any of this work however am restricted on where
this work can be done. If you're still interested it would be great to have
you as a committer as you're the man and you have working code to boot. I'm
not at all married to our current code so if you think your version is a
better starting point that's fine with me and we could re-base from there.
-Simon
Johan Compagner
'The only problem is that i cant give direct instructions for you how to use
it
Because in our product we use a patch over the dltk to support remote debug
(what we really need)
johan