Atom.jl
Atom.jl copied to clipboard
inline evlauation during debugging
addresses:
- https://github.com/JunoLab/Juno.jl/issues/362#issuecomment-569125114
- the second idea of https://github.com/JunoLab/Juno.jl/issues/362#issue-493724338
image:

Codecov Report
Merging #264 into master will decrease coverage by
0.21%. The diff coverage isn/a.
@@ 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 dataPowered by Codecov. Last update 97483de...f75e172. Read the comment docs.
What happens if you change and re-eval a function (or even the currently debugged function)? Does the debugger pick up on that?
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.