>"Attila Szegedi" <[email protected]> wrote in message >news:mailman.2861.1246687829.5555.dev-tech-js-engine-rh...@lists.mozilla.org... > > 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 > 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
