On Jun 3, 8:25 am, "Simon Kaegi" <[email protected]> wrote:
> Also, any thoughts onhttp://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
>
>

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.
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino

Reply via email to