"Attila Szegedi" <[email protected]> wrote in message news:mailman.1551.1245450618.5555.dev-tech-js-engine-rh...@lists.mozilla.org... > 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. > To be honest we're doing both right now but are imagining the majority of 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. > Attila. > > 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. >> >> 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" <[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
