Debugger status and future plans?

Meanwhile, my sense is that explaining to users the options that are available would go a long way.

We have Debugger.jl, MixedModeDebugger.jl, Infiltrator.jl plus a few other options that are probably less used (e.g., MagneticReadHead.jl). Plus we have IDE like interfaces that hook into these packages.

The typical user will likely have limited understanding of the strengths and limitations of each package. Few users will know about push!(JuliaInterpreter.compiled_modules, ...).

The end result is that a user who just needs a simple breakpoint to inspect the state of some long running code will try Debugger.jl and find that it apparently hangs, while a simple @infiltrate might have solved the problem.

(A comment like this implies that I should get working on what Iā€™m proposing, but I doubt that I have a good enough understanding of the various options.)

5 Likes

Sorry to reopen the debate three months later. I just found this on the internet because Iā€™m having problems with Juliaā€™s debugger. I am really interested on this topic so I would like to leave my opinion.

IMHO, if Julia wants to be competitive w.r.t. other languages, it needs a good debugger (such as Matlab, e.g.). Actually, debugging is about 70% of the development time of the code. If that 70% is painful and slower than in Matlab, many people will still prefer Matlab than Julia.

Perhaps many people perfectly deal debugging short functions with the REPL. However, each programmer has its own way to program. Many people prefer to make long scripts with less function calls, and they have the right to do so. I do not want to discuss which way is best. I just think that Julia should adapt to these people as well if it wants to be competitive.

I do finite elements and I have a long (but well structured code) with many variables. When I try the debugger, it does not start up in less than 5 minutes. Thus, when something goes wrong, I have to successively insert ackward sentences like if(insan(x)); error(""); end or display("This step has been completed") because there is no other way to track errors. Of course, each time I insert a new sentence I have to wait until Julia compiles and execute again. Debugging like this is painful.

I am worried about this because I really like Julia (itā€™s been a turning point in my PhD), but I see that very little effort is being done w.r.t. serious debugging, which in my opinion is as important as run-time efficiency and parallelization.

6 Likes

Note that just because you canā€™t see it doesnā€™t mean it isnā€™t happening. :slight_smile:
Its true nothing is happening fast right now because people are busy.

A while ago several people involved had a meeting on the debugger.
I thought it was posted back here but it seems not

My recollection of the outcome. and maybe @davidanthoff can correct me,
the outcome was:

  1. Longer term solution: build a thing that basically does what MixedModeDebugger does, but with none-of the downsides, such that you can still have break-on-error etc. A designed was I think written up somewhere for this a long time ago, and there is a compiler feature that needs to be developed that lets one interupt a compiler frame and start interpretting it. But that feature has been developed for other languages, and we want it anyway for some other reasons i donā€™t recall.
  2. Shorter-Term solution: Investigate making a kind of smarter version of JuliaInterpretter.compiled_modules for Base/StdLins, which would be compiled for everything except for higher-order functions (basically by hardcoding those as exceptions.)

To my knowledge no progress on either front, yet.
But itā€™s not forgotten

10 Likes

Are you using Revise? I often debug by inserting @shows and error()s, and I donā€™t find that I need to wait any noticeable amount of time for compilation of the revised code.

3 Likes

Just a note, Julia is already ā€œcompetitiveā€ with other languages, it is quickly becoming the first choice of programming language for a lot of people. Also, argumentation like ā€œyou should do this or you will not be successfulā€ tend to be quite inefficient because you have to remember that:

a. Julia is already very successful :slight_smile:
b. You are talking with people who have been here for 5-10 years working on this. We know pretty well what the pain-points of the language are and what people tend to complain about. Saying ā€œJulia needs a debugger to be successfulā€ is just one entry in the list of things people claim are absolutely crucial to be ā€œcompetitiveā€.

You are among friends here :slight_smile:

etc

Julia (and programming languages) are not entities that magically adapt to feature requests. They get developed from people doing work because they either get paid to do it, they have a need for something, or for the fun of it. Which people are you addressing with this post?

The debugger is known to be slow and you will not be able to run a full-scale FEM code through it. However, for debugging it is usually enough to run stuff on a very small model. The same code tends to execute if you run with 10 elements or 10 million.

Have you tried Revise.jl? Itā€™s a game-changer.

12 Likes

As someone who primarily cares about inspecting the stack after some exception was thrown, it occurred to me that a really simple solution would be

@debuggable function foo(vec)
    for x in vec
        ...
    end
end

macroexpanding into

function foo(vec)
    try
        for x in vec
            ...
        end
    catch e
        push!(Debuggable.stack, FunctionState(built from @locals etc.))
        rethrow()
    end
end

The runtime cost would be negligible for most functions I care to debug. Best of all, it would be ā€œalways-onā€ like Pythonā€™s debugger: just sprinkle @debuggable around your package on all non-trivial functions, then when you hit an exception, you can dive right into the stacktrace. No need to start a debugger and rerun the code in some ā€œspecial debugger modeā€.

2 Likes

I have Revise ofc but it doesnā€™t work when debugging from VSC. There, every time i make a change, I need to kill and restart a new console.

Iā€™d recommend using VSCodeā€™s @enter/@run macros for debugging in an already running process.

If you want a short-term solution until devs have time/resources to improve the debugger, GitHub - JuliaDebug/Infiltrator.jl: No-overhead breakpoints in Julia and https://github.com/antoine-levitt/Exfiltrator.jl have been useful for me and my coworkers. Theyā€™re not full-fledged debuggers, but they allow you to quickly inspect and play with variables in a context without stepping through.

2 Likes

I do use the @run ... macro, but no magic Reviseology

I would question your numbers: I have never needed/used a debugger with Julia, and Iā€™ve written ~100,000 lines of code (Edit: in Julia).

The key is IMO Test-Driven Development. Write small function, test them thoroughly, and compose bigger things from well-tested small ones.

9 Likes

Well, when I wrote ā€œcompetitiveā€ I was thinking in ā€œmore competitiveā€. I know Julia is successful and competitive and indeed it is also my first option.

Julia developers are doing an amazing job and I am very grateful to them for that. Nevertheless, as a user, I feel that actually the debugger is far not as well-developed as other features. And for me, as well as for many of my colleagues, a good debugger is essential, so the lack of a good debugger is unfortunately a reason not to use Julia, as @tue has pointed along this post.

I have no doubt that the developers already know a debugger is very important, but I was wondering if Julia lacks a good debugger because they do not consider it a priority or just because it is too complicated to develop. If the former, I suggest to take it more seriously because IMHO it is a very strong disadvantage (I know many people that would not even give it a try) that somehow limits all the great and huge effort done to develop this language. If the latter, then I will wait patiently (I wish I had time and knowledge to contribute instead of making suggestions).

To the developers (some of you, right?)

I am using a toy example.

Thanks for the advice! I have given it a try, but I donā€™t see the difference. Perhaps Iā€™m not using it correctly. I will look carefully the documentation and let you know in another post if it does not work as expected.

I prefer to write long scripts with a clear structure. I use many variables, so a long script allows me to access them more easily. It is also more comfortable when you follow a trial and error procedure to develop a code and you have to introduce many changes. As you say, I would have to write quite a lot of functions and change their arguments and body each time I want to introduce changes in my code.

Anyway, although that is not your case, I think that quite a lot of people need a debugger, irrespective the way in which they program.

To each his own, no doubt. I am just pointing out the (admittedly anecdotal) evidence that small functions/TDD may obviate the need for a debugger and enable composition of complex software.

5 Likes

A technique I found useful when prototyping code with many variables but still wanting to divide it into more manageable functions, is to pass around collections of variables as dicts or named tuples. This way, you donā€™t need to keep changing function signatures before your code ā€œsettlesā€. @unpack from GitHub - mauro3/Parameters.jl: Types with default field values, keyword constructors and (un-)pack macros is useful for writing functions in this style.
I believe itā€™s also less error-prone then explicitly naming arguments in you function signature, since youā€™re less likely to accidentally depend on global state which should have been a function argument (e.g. when moving code from global scope into a function).

1 Like

This is and old arguing. I disagree with it. Not that itā€™s false per se but because itā€™s not an universal truth. I also have written > 100 klines (most not in Julia) and there are codes that simply need an excellent debugger. For example, my GMT.jl is mainly parsing input, interfacing with C libs, trying to guess good defaults and convert to a lower level syntax. It implies lots of conditional branches. Fixing mal-behaviors without a good debugger is a hell (and have been there many times).

As you say, what I stated is not a universal truth. But the type of software you mentioned is quite different from typical FEA code.

Iā€™ve also written hundreds of thousands of lines of code in Matlab. It felt like I spent the whole time in the debugger when programming in that environment!

Julia rules!

1 Like

Thanks @yha. I have had a look and it seems it could be very useful for me.

I keep hearing that and letā€™s say youā€™re right.
What about code of a 3rd party Iā€™m trying to follow and understand?

Really, it is like people would say ~2020 technology isnā€™t needed as people lived pretty well in ~1990 as well. While it is true, it is not a good case against making a progress.
Each individual with his own preferences.

Julia needs a good Debugger as it is important tool for a language targeting the masses.
There has been a great progress on that in the past years and it is still being actively improved. Naturally it will be better in a year. The nice thing, once it gets to the required level. thatā€™s it.
The OP should be assured this is a vector taken care of.

2 Likes