You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 6, 2019. It is now read-only.
From #37 (comment) and ongoing discussion, it was discussed to split this package since the interpreter itself is likely useful even outside the debugging functionality. The exact way things should be split is yet to be determined but I made an initial (WIP) attempt.
The packages ASTInterpreter2 got split out into JuliaInterpreter.jl (which include the interpreter part) and Debugger.jl (which includes debuggerframework and the debugging part from JuliaInterpreter). They can be found at:
There are currently methods in JuliaInterpreter that are only used in Debugger so they could technically be moved, however, we need to define the API to expose from JuliaInterpreter that is consumed by Debugger to know exactly what should live where. In order to reduce the coupling between the packages I think we should be quite hard on not using too many internals of JuliaInterpreter in Debugger.
Great! I was hoping to make progress on this over the weekend but had more urgent deadlines. I am making good progress on a Revise rewrite based on the interpreter; I'll switch it over to JuliaInterpreter and see how it works.
And yes, let's try to define the API. Some thoughts:
plain: I think we can get rid of that. For a while I explored a wrapper to handle "weird AST elements" (back when I introduced a LocalMethodTable type) but that breaks enough things that I've retreated to using conventional lowered AST and adding extra fields to JuliaFrameCode and JuliaStackFrame.
do all those really need to be import or can some be using? (I would wager the majority are not being specialized?)
While there is still way too much coupling between the two packages, that hopefully is just internal and can be refactored as we get more experience what API is needed.
Also, perhaps Debugger.jl should be tested as part of the tests in JuliaInterpreter while the packages are so coupled.
From #37 (comment) and ongoing discussion, it was discussed to split this package since the interpreter itself is likely useful even outside the debugging functionality. The exact way things should be split is yet to be determined but I made an initial (WIP) attempt.
The packages ASTInterpreter2 got split out into JuliaInterpreter.jl (which include the interpreter part) and Debugger.jl (which includes debuggerframework and the debugging part from JuliaInterpreter). They can be found at:
https://github.com/JuliaDebug/JuliaInterpreter.jl
https://github.com/JuliaDebug/Debugger.jl
There are currently methods in JuliaInterpreter that are only used in Debugger so they could technically be moved, however, we need to define the API to expose from JuliaInterpreter that is consumed by Debugger to know exactly what should live where. In order to reduce the coupling between the packages I think we should be quite hard on not using too many internals of JuliaInterpreter in Debugger.
The full API used by Debugger from JuliaInterpreter can be seen from the imports: https://github.com/JuliaDebug/Debugger.jl/blob/bc8741d653930f1aa6d04b3be9a7aa4848fc5732/src/Debugger.jl#L18-L20. This is clearly too large and some methods should likely be moved from one package to the other.
The text was updated successfully, but these errors were encountered: