I'll prepare stubbed out lol headers in a separate CL (coming soon).
http://codereview.chromium.org/6351007/diff/1/src/d8.js File src/d8.js (right): http://codereview.chromium.org/6351007/diff/1/src/d8.js#newcode592 src/d8.js:592: // Remember the handle requested in a global variable. On 2011/01/19 08:36:40, Søren Gjesse wrote:
Maybe change handle to id here to keep the distinction between # and @
numbers. This comment is a cut-and-paste error from the # case. I removed it. http://codereview.chromium.org/6351007/diff/1/src/debug-debugger.js File src/debug-debugger.js (right): http://codereview.chromium.org/6351007/diff/1/src/debug-debugger.js#newcode2053 src/debug-debugger.js:2053: response.body = MakeMirror(%GetLOLObj(obj_id)); On 2011/01/19 08:36:40, Søren Gjesse wrote:
I think we should be able to unify the handles ids used by the
debugger and the
object ids used in lols.
What do you think about this:
If lol is enabled then the debugger should just use the lol id instead
of
generating its own handle id. That will make the ids persistent
between debugger
invocations as long as lol is activated. That way we don't need both
the @ and
the # ids.
This unification can be done in a separate change it it can work.
The problem with that is that the @ids only work if one has captured a lol. Whereas the #handle# can be used whenever the debugger breaks and the user inspects a var. If we unify it, then we need to fore the capture of lols every time the user inspects a var in the debugger. This will interfere with the user's usage of lols because the debugger will be automatically capturing the lols where the user didn't request any. If we try to hide these implicitly captured lols, there are other issues with the deletion of lols where the user may delete all lols, but we may not want to delete the implicit ones. Also, it introduces inconsistencies in the behavior of the merged #handles# when lols are not in use. @ids do not keep the GC from collecting an object, while #handle#s do. Hence, the user will be getting a different experience depending on whether lols are in use or not. This can be confusing to the user. I think it is better to be consistent and transparent about the difference between the 2. http://codereview.chromium.org/6351007/diff/1/src/debug-debugger.js#newcode2387 src/debug-debugger.js:2387: DebugCommandProcessor.prototype.lolCaptureRequest_ = function(request, response) { On 2011/01/19 08:36:40, Søren Gjesse wrote:
We try to split the long lines when possible, e.g. JSONProtocolSerializer.prototype.serializeReferenceWithDisplayData_
and
JSONProtocolSerializer.prototype.serialize_ in mirror-debugger.js
Done. http://codereview.chromium.org/6351007/diff/1/src/debug-debugger.js#newcode2392 src/debug-debugger.js:2392: DebugCommandProcessor.prototype.lolDeleteRequest_ = function(request, response) { On 2011/01/19 08:36:40, Søren Gjesse wrote:
Ditto.
Done. http://codereview.chromium.org/6351007/diff/1/src/debug-debugger.js#newcode2437 src/debug-debugger.js:2437: DebugCommandProcessor.prototype.lolRetainersRequest_ = function(request, response) { On 2011/01/19 08:36:40, Søren Gjesse wrote:
Ditto.
Done. http://codereview.chromium.org/6351007/diff/1/src/runtime.cc File src/runtime.cc (right): http://codereview.chromium.org/6351007/diff/1/src/runtime.cc#newcode45 src/runtime.cc:45: #include "liveobjectlist.h" On 2011/01/19 08:36:40, Søren Gjesse wrote:
This suggests that the actual lol implementation lands before this
change. Or
should we have an "empty" class LiveObjectList in liveobjects.h added
to this
change?
Mikhail's suggested division of the commits was to land the liveobjectlist files first. If you want to land the liveobjectlist files last, I can prepare another CL with stubbed out liveobjectlist.h and -inl.h. http://codereview.chromium.org/6351007/ -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev
