Before nailing things down with unit tests, I just wanted you guys to take a
second look to see if this looks good API wise.
Regarding duplication of code. The existing Stack Trace code in
top.cc,runtime.cc and messages.js is aimed mainly at string printing Stack
frames, and not at exposing API for programatically reading information
about
the stack. The API available in debug-debugger.js and mirror-debugger.js are
aimed at mainly supporting the interactive debugging use case, and are
actually
quite slow.
I think I could possible port some of the code in messages.js to use this
new
StackTrace API, but I would preferrably do that in a follow up patch. Also,
I
think they are different enough that the code duplication isn't so bad.
http://codereview.chromium.org/1694011/diff/9001/10002
File include/v8.h (right):
http://codereview.chromium.org/1694011/diff/9001/10002#newcode755
include/v8.h:755: static_cast<FrameOptions>(LINE_NUMBER | COLUMN_OFFSET
| SCRIPT_NAME | FUNCTION_NAME);
line length addressed locally.
http://codereview.chromium.org/1694011/diff/9001/10002#newcode2784
include/v8.h:2784: * property is present an empty handle is returned.
space removed locally.
http://codereview.chromium.org/1694011/show
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
