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

Debugging support #125

Open
davidanthoff opened this Issue Dec 22, 2016 · 9 comments

Comments

Projects
None yet
4 participants
@davidanthoff
Collaborator

davidanthoff commented Dec 22, 2016

Currently we are waiting for some more work upstream. See this discussion.

@davidanthoff davidanthoff added this to the Backlog milestone Dec 22, 2016

@ZacLN

This comment has been minimized.

Collaborator

ZacLN commented Sep 23, 2017

@davidanthoff

This comment has been minimized.

Collaborator

davidanthoff commented Sep 28, 2017

I think to do this right we need out-of-process debugging support, i.e. ideally there would be one julia process that implements the VS Code debug adapter protocol, and then the user code that we want to debug would actually run in another julia process. I think @Keno was working on an out-of-process debugger at some point?

@ZacLN

This comment has been minimized.

Collaborator

ZacLN commented Sep 28, 2017

Can we not just control it by Stdin/out?

@davidanthoff

This comment has been minimized.

Collaborator

davidanthoff commented Sep 28, 2017

I think we need to be able to respond to messages even while some client code is running... There are also things like attaching to a running instance etc. But it has been a while that I looked at the debug protocol, might be worth taking a second look.

@KristofferC

This comment has been minimized.

Contributor

KristofferC commented Sep 28, 2017

ASTInterpreter2 will only be able to step through code and will not have breakpoint support. AFAIU, breakpoint support will likely take quite some time so I don't think you need to rush this. Of course, getting the pieces into place is a good thing though.

@ZacLN

This comment has been minimized.

Collaborator

ZacLN commented Sep 28, 2017

My thoughts were (pre-breakpoint support) to evaluate an automatically modified version of code w/ @enter inserted at the start of the function enclosing the breakpoint to at least allow you to get variable info and limited step-through functionality (within that closure).

I'm aware we'd have to provide some sort of protection against nested calls but could this feasibly work? If it did then it'd allow us to get all the infrastructure into place for when proper breakpoints are supported

@davidanthoff

This comment has been minimized.

Collaborator

davidanthoff commented Sep 28, 2017

@Keno what is your current thinking about an out-of-process debugger? I kind of feel a lot depends on the plans for that, given how different the whole design would be if we had that.

@szalmaf

This comment has been minimized.

szalmaf commented May 14, 2018

@davidanthoff Just curious, is there any new activity on a debugger in VS Code. It'd be so nice to have one.

@davidanthoff

This comment has been minimized.

Collaborator

davidanthoff commented May 14, 2018

No progress so far. My best guess is that we'll have to wait until julia 1.0 ships and the core julia teams starts to work on the debugger again. But that is a guess, I have no inside info.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment