debugger

[pao]

Debugging code is currently print() based. This isn't a particularly great solution.

Spun this issue off of #502 so maybe we can put that one back on topic. (My fault for bringing it up)

[pao]

Is there still a work item for an integrated debugger, or does the Debug package reflect the desired approach?

[JeffBezanson]

We want to have the ability to enter a debugger, say, at the point where an exception is raised, and inspect the environment, without performance loss.

[StefanKarpinski]

So no, the Debug package, while very useful, doesn't do everything we'd want. But I'm pretty sure we don't need an issue to know that. Although it may be a good place to discuss.

[pao]

Figured as much; just looking through my old open issues.

[vtjnash]

what features are absolutely required that can't be added later as updates to the Debug package?

I'm thinking we implement an @trace macro to surround suspect functions that just instruments every possible line with @show, and then close this issue as invalid (not a specific, targetable issue)

[JeffBezanson]

We need to be able to run at full speed, then poke around in the stack when
something unexpected happens.
On Feb 1, 2013 10:21 AM, "Jameson Nash" notifications@github.com wrote:

what features are absolutely required that can't be added later as updates
to the Debug package?

I'm thinking we implement an @trace https://github.com/trace macro to
surround suspect functions that just instruments every possible line with
@show https://github.com/show, and then close this issue as invalid
(not a specific, targetable issue)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/505#issuecomment-13006723.

[vtjnash]

ok, let me be more specific. what (if anything) is required for 0.1?

[timholy]

A recent LLDB bug report pointed me to (or reminded me of) this. I'm a little out of my depth when it comes to many of these matters, so let me just ask, might we not be that far away from being able to use GDB as an external-process debugger?

There is also this LLDB-dev thread which seems potentially relevant.

Having personally sunk a lot of time into truncated backtraces (#3469) before declaring defeat, I am quite prepared to believe that getting a debugger working may be a huge job, one that no one is yet ready to tackle. I'd be interested in any assessments from people better-informed than myself about how far they think we might be from this goal.

[stuinzuri]

Yes, it is a huge job. We (Forio) have brought on @keesvp to take up the development of JuliaStudio full time. His primary mandate is to implement a visual debugger for JuliaStudio. As such he'll need to dig deep into Julia. Expect to hear from him here on github, including PRs, and on the mailing lists. "Soon."

[timholy]

That's awesome news. I may not be typical, but I do think the lack of a really great debugger is one of the few remaining serious roadblocks for widespread adoption.

@keesvp, wind to your sails!

[keesvp]

Thanks. I still am only an egg.

[stevengj]

The MCJIT work (#3922 and #5433) for integration with LLDB, and efforts to emit DWARF info (#5354) to integrate with gdb, should be relevant here.

[tpapp]

@stuinzuri: will the debugger be tied to JuliaStudio, or is there going to be an exposed API that other IDEs (eg Emacs) can potentially use?

[vchuravy]

@tpapp Keno discussed his progress with the debugger at JuliaCon https://www.youtube.com/watch?v=Wkw2gmzfm1Q

[malmaud]

And again at this year's JuliaCon.

[ViralBShah]

@Keno Did you mean to close this?

[Keno]

Once the METADATA PR is merged.

[ViralBShah]

The PR is green. Anything holding it?

[dhoegh]

How far is Windows support?

[timholy]

Whoa.

[StefanKarpinski]

Bravo, @Keno.

[ViralBShah]

I believe Windows support is coming soon, but needs some non-trivial work.