I just wanted to ask about the state of the debugger in Julia. I am coming from Matlab and the debugger there is quite important for me to see where something is going wrong. For example, using NLsolve is a bit of a black box for me. If it does not work, I don’t know where to start to look for the problem. In contrast, in the meantime I copied the code to Matlab and could stop during the the execution of fsolve and check what is going wrong. Now it works in Matlab, but still it does not in Julia, although the code should be 1:1 equivalent.
I just would like to know if there is a plan on the development of the debugger.
While you’re asking for a debugger, you could also post the NLsolve question here on discourse (there’s not really a dedicated sub, but you could maybe try Optimization (Mathematical) - JuliaLang ). I’ll be happy to assist!
Thank you for all the replies. I will definitely follow it more closely and see how it plays out with 0.6.
Also thanks to pkofod, I might actually post there something next week as I get back to Uni. I am kind of curious to know, why it does not work in Julia at the moment.
ASTInterpreter2.jl works quite well in my experience, but doesn’t provide any breakpoints and stuff. Juno integration should hopefully be ready soonish (no promises though).
The development of a debugger is somewhat independent of the Julia version, because it is simply another package. Also, notice that I said a debugger, because it is possible for there to be many different julia debuggers, each with a different approach. To my knowledge, the only Julia 1.0 compatible debugger is Rebugger.jl, but I’m sure more are on the way.
Due to the closure of a related thread, I choose to ask my questions here - Is an official Julia-v1.0-compatible debugger being considered/planned at the moment? By ‘official’, I mean a debugger like the one (ASTIntepreter2) which works with v0.6 and can be embedded in JuliaPro. If so, when will it be available? I know that an exact date is impossible. So I’m asking for a (very, or very very) rough estimate, which, at least, can give me a hope. I really really really depend on a reliable debugger to work with large packages written by others. So any info is much appreciated!!!
Since the thread about debuggers (here) was closed, I’m adding my answer to it here -
I rely heavily on debuggers and the lack of a proper debugger for Julia and Juno is one of the main reasons I don’t switch to Julia.
I use breakpoints, most of all, as a way of finding my own mistakes - I can write a very readable code in Julia, but even in the most readable code it is easy to miss a displaced minus sign, an edge case not handled in some inner function etc. When working with a large code divided to many sections, breakpoints can save hours looking for the problem, and an uncountable amount of frustration!
Same goes for when using someone else’s code, especially when this code is meant to create abstraction of the methods I eventually plan to use - in general I’m not even trying to understand this code (otherwise, it wouldn’t be abstraction), but when something is not working as I expect, I need all the help I can get understanding it.
I agree. Especially in looping code that doesn’t error but produces an incorrect result, being able to track down how the loop is misbehaving is critical.
I’ve tried Rebugger.jl but it keeps telling me what I’m trying to look at is “unavailable”. There seems to be some stepping functions in Juno but they don’t seem to do anything.
People posting here may be interested in Compiler work priorities in which I’ve outlined the rough priorities for compiler-related work, including tools like debuggers.
You probably all know about Rebugger. I haven’t had any time to work on it lately, and probably won’t for a couple more months. I’d like to encourage people who are impatient for a debugger to jump in and help make it better. Here are reasons to consider this:
Rebugger and Revise (upon which Rebugger is based) are pretty extensively documented, even down to the internals. I did this precisely to make it easier for others to contribute, but if anything it’s had the opposite effect.
Rebugger is tiny: the core src/debug.jl file is currently 600 lines of code and, other than Revise, has no significant dependencies.
Rebugger does not interact with call stacks; everything is done in terms of julia expressions. That means anyone who has written or edited a macro or otherwise worked with Julia expressions has the background needed to pitch in—this is not rocket science.
I’ve outlined solutions to things like how to add breakpoints. Once breakpoints are added, I think it can interact with graphical debuggers (aka, Juno).
The Julia compiler team’s priorities linked above by Stefan (which is a fantastic list, and ordered the same way I’d order it) suggests it will be a while before there’s another solution, unless someone outside the team picks up Gallium on their own.
Here are some of the most impactful ways to help out:
I am not sure about causality here — I think you may not be getting contributions because people assume you will just fix things anyway It’s good that you made your plans clear for the near future, which could change this.
Personally, while I find Rebugger very nice, I find Revise so powerful that I almost never need it. I have never grokked debuggers, and with Julia I developed a programming style that doesn not need it. This is possible because in Julia there is no penalty for writing small functions that do one thing, and those can easily be tested.
As a newcomer, I’m just not sure how to use these tools to accomplish what I need. I believe you all that together these can do a lot of what a debugger would do, but I just don’t get how to use them.
I did Esc E with Rebugger on a function and couldn’t interpret what it was showing me or how to continue from there. What am I supposed to do with the @eval block it generates at the prompt?
I did figure out that the “untracked” error I mentioned before meant I had to load code via incluedt.
It’s good that you made your plans clear for the near future, which could change this.