Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inline evlauation during debugging #264

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

inline evlauation during debugging #264

wants to merge 1 commit into from

Conversation

aviatesk
Copy link
Member

@aviatesk aviatesk commented Feb 9, 2020

@codecov
Copy link

codecov bot commented Feb 9, 2020

Codecov Report

Merging #264 into master will decrease coverage by 0.21%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #264      +/-   ##
==========================================
- Coverage   55.18%   54.97%   -0.22%     
==========================================
  Files          42       43       +1     
  Lines        2399     2412      +13     
==========================================
+ Hits         1324     1326       +2     
- Misses       1075     1086      +11     
Impacted Files Coverage Δ
src/debugger/eval.jl 0.00% <0.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 97483de...f75e172. Read the comment docs.

@pfitzseb
Copy link
Member

pfitzseb commented Feb 9, 2020

What happens if you change and re-eval a function (or even the currently debugged function)? Does the debugger pick up on that?

@aviatesk
Copy link
Member Author

What happens if you change and re-eval a function (or even the currently debugged function)? Does the debugger pick up on that?

If you evaluate the other function (i.e. which is not currently debugged), it won't be evaluated by interpreter by this check.
If you evaluate the function itself, it will be evaluated in interpreter and result in defining a local function within a debugging scope.
(E.g. if we evaluate strlimit in the above example, it will introduce Atom.var"#strlimit#322"() in the debug scope, and the original (debugged) strlimit won't change.)

Well, the check to decide whether evaluate a code in interpreter or our usual eval scheme is in interpret_string, and it has an obvious problem as before -- it can't handle the changes that are not yet evaluated before and after starting debug. But this applies to most of the other debugger features we have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants