Skip to content
This repository has been archived by the owner on Dec 6, 2019. It is now read-only.

Split into Interpreter + Debugger. #46

Closed
KristofferC opened this issue Feb 4, 2019 · 2 comments
Closed

Split into Interpreter + Debugger. #46

KristofferC opened this issue Feb 4, 2019 · 2 comments

Comments

@KristofferC
Copy link
Member

KristofferC commented Feb 4, 2019

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.

@timholy
Copy link
Member

timholy commented Feb 4, 2019

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?)

@KristofferC
Copy link
Member Author

I did some updates and enabled CI on the repos.

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.

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

No branches or pull requests

2 participants