-
-
Notifications
You must be signed in to change notification settings - Fork 43
Behavior of next / stepOver #144
Comments
Which is most likely related to how the code is executed in
|
I wonder if this behavior does not come from the way we initialize ptvsd. Indeed, I can observe the same behavior even if the last statement is not an expression to evaluate. I've also played a bit with the backend, the following change doe snot fix the issue: std::string filename = get_cell_tmp_file(code);
register_filename_mapping(filename, execution_count);
// Parse code to AST
py::object code_ast = ast.attr("parse")(code, filename, "exec");
py::list expressions = code_ast.attr("body"); |
That is also one possibility yes. |
This issue is definitely due to the backend implementation. It seems that ptvsd doe snot support interactive mode yet (see microsoft/ptvsd#201). The result is that we have too stackframes, one from the interactive mode and one from the code that hit the breakpoints. When we reach the end of the file containing the code of the cell, it comes back to the interactive frame. This is the same behavior when the code is stoppe don the last line of a funciton and we click the next button: it commes back to the call site. |
Related PR in |
jupyter-xeus/xeus-python#169 already is a good improvement for the behavior of next / stepOver. Thanks @JohanMabille for this! However there seems to be something else related to the status of kernel (busy / idle) when the Leaving the issue open so we can track this. |
Moving that one to the next release as this is not a blocker for 0.1.0. |
We should check what it happening when the
stepOver
(next
) command is being used.In the screencast below we would expect to advance to the line 2, then 3 and then 4 when doing several calls to
stepOver
.The text was updated successfully, but these errors were encountered: