2010/1/18 Søren Gjesse <[email protected]> > Hi Peter > > What you are suggesting is that when there is no active JavaScript > execution and the embedder calls v8::Debug::ProcessDebugMessages() the > embedder can enter a context before the call, and the commands will be > processed in this context. I think that sounds fine. However I am not sure > whether the call to suspend is actually required for this to work. Should > that be required for commands like "setbreakpoint" which can also include > evaluating an expression? In my initial design I >
Maybe I said it too restrictive. Anyway, I don't think "setbreakpoint" command or similar requires suspend. I would call them "asynchronous" commands, because they may be handled equally successfully in any moment. As for evaluate, I am not going to restrict anything, at least for now. However, I would suggest that "evaluate" normally should be issued when debugger is in suspend state; I see 2 reasons here: 1. As I understand, "refs" are only while we are staying on suspend. This probably means that lookup subproperties we should be suspended. 2. Debugger UI frameworks may expect that expressions are only evaluated in suspend state and be reluctant to evaluate them in other states. What I actually wanted to say, that I am going to have "suspend" command properly handled even when V8 is not active. When user sends us "suspend", embedder calls the usual "ProcessDebugMessages", which blocks on suspend until user sends "continue". This way we deal nicely with both issues above. I don't expect myself to say something really original or new here. I just wanted to give a small specification just in case. Peter > mandated that V8 was suspended before any commands could be processed, but > was convinced it change it and add the "auto break" processing. It will of > cause be fine that a debugger restricts its use of the protocol to something > that makes sense for how it work. > > /Søren > > On Fri, Jan 15, 2010 at 21:43, Peter Rybin <[email protected]> wrote: > >> Hi Søren >> >> Let me share the idea of "global evaluate" implementation. >> >> Use case 1: >> Some web application is open in Chrome browser. Programmer wishes to >> inspect a value of some global variable without any JavaScript code actually >> running (e.g. his web-page has only one function, and this function will >> trigger drawbridge opening over the river Neva). >> Debugger should allow checking a global variable. >> >> Use case 2: >> Some application occasionally employs some user scripting. Programmer >> wishes to call GetEmbedderConfiguration() function and inspect an object it >> returns with its properties and subproperties. Making application run actual >> user script is a long non-automated routine, that has to be done manually. >> Debugger should allow calling any global function. >> >> Use case 3 (optional): >> Some application support several V8 contexts. While application is idle, >> programmer wishes to check initial data in all contexts. >> When application is idle, debugger should give access to all contexts >> (because we cannot explicitly choose a particular one). >> >> >> Here's my approach. >> When application is idle (or simply V8 is not called) programmer presses >> "suspend" button. "Suspend" debug command arrives to V8 and embedder calls >> v8::Debug::ProcessDebugMessages(). V8 suspends and send back "suspended" >> event. In this situation V8 is suspended, but there are no frames. Everybody >> is cool about this. Debugger application (e.g. Eclipse) sees that we are >> suspended and evaluates required expressions. V8 is can correctly evaluate >> expressions, because it is suspended and therefore all data is static and >> may be inspected. >> >> I have tried to implement this, it seems to require quite a few simple >> modifications. >> >> Embedder is responsible for choosing a context to >> call v8::Debug::ProcessDebugMessages(). For use case #3 I would suggest that >> embedder creates an auxiliary context, that keeps references to all user >> contexts. This way programmer will be able to inspect all contexts in this >> manner: >> expression1 = "this.rybin_context.GetConfiguration()" >> expression2 = "this.apavlov_context.window" >> >> I'm going to complete/submit this in a near future. >> Do you think this may sound reasonable? >> >> Peter >> > >
-- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
