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.)
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.
Note that just because you canāt see it doesnāt mean it isnāt happening.
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:
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.
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
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.
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
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
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.
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ā.
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.
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).
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).
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!
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.
