# Debugger status and future plans?

**URL:** <https://discourse.julialang.org/t/debugger-status-and-future-plans/43638>\
**Category:** Community\
**Tags:** question, debug\
**Created:** [July 24, 2020, 9:07pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638 "2020-07-24T21:07:21Z")\
**Posts on this page:** 20\
**Page:** 4

<div class="post-metadata">

**Author:** ![hendri54](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/hendri54/32/9621_2.png) [@hendri54](https://discourse.julialang.org/u/hendri54)\
**Post date:** [July 29, 2020, 3:46pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/61 "2020-07-29T15:46:40Z")

</div>

> [@StefanKarpinski](#):
>
> While it’s great that this _can_ be done, I think that the default experience needs to be improved because most people just won’t figure out how to tinker with this.

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.)

---

<div class="post-metadata">

**Author:** ![mancolric](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mancolric/32/21799_2.png) [@mancolric](https://discourse.julialang.org/u/mancolric)\
**Post date:** [October 8, 2020, 10:44am UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/62 "2020-10-08T10:44:43Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [October 8, 2020, 11:39am UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/63 "2020-10-08T11:39:50Z")

</div>

> [@mancolric](#):
>
> 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:

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

---

<div class="post-metadata">

**Author:** ![yha](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yha/32/3502_2.png) [@yha](https://discourse.julialang.org/u/yha)\
**Post date:** [October 8, 2020, 11:44am UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/64 "2020-10-08T11:44:37Z")

</div>

> [@mancolric](#):
>
> Of course, each time I insert a new sentence I have to wait until Julia compiles and execute again. Debugging like this is painful.

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

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [October 8, 2020, 12:07pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/65 "2020-10-08T12:07:23Z")

</div>

> [@mancolric](#):
>
> MHO, 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.

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”.

> [@mancolric](#):
>
> I do finite elements and I have a long (but well structured code) with many variables.

You are among friends here 🙂

> **[GitHub - KristofferC/JuAFEM.jl: Finite element toolbox for Julia](https://github.com/KristofferC/JuAFEM.jl)**
>
> Finite element toolbox for Julia . Contribute to KristofferC/JuAFEM.jl development by creating an account on GitHub.

> **[GitHub - gridap/Gridap.jl: Grid-based approximation of partial differential...](https://github.com/gridap/Gridap.jl)**
>
> Grid-based approximation of partial differential equations in Julia - GitHub - gridap/Gridap.jl: Grid-based approximation of partial differential equations in Julia

> **[GitHub - PetrKryslUCSD/FinEtools.jl: Finite Element tools in Julia](https://github.com/PetrKryslUCSD/FinEtools.jl)**
>
> Finite Element tools in Julia. Contribute to PetrKryslUCSD/FinEtools.jl development by creating an account on GitHub.

etc

> [@mancolric](#):
>
> I just think that Julia should adapt to these people as well if it wants to be competitive.

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?

> [@mancolric](#):
>
> 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.

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.

> [@mancolric](#):
>
> Of course, each time I insert a new sentence I have to wait until Julia compiles and execute again.

Have you tried Revise.jl? It’s a game-changer.

---

<div class="post-metadata">

**Author:** ![cstjean](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cstjean/32/1444_2.png) [@cstjean](https://discourse.julialang.org/u/cstjean)\
**Post date:** [October 8, 2020, 12:14pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/66 "2020-10-08T12:14:28Z")

</div>

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

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

```

macroexpanding into

```julia
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”.

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [October 8, 2020, 12:31pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/67 "2020-10-08T12:31:05Z")

</div>

> [@kristoffer.carlsson](#):
>
> > [@mancolric](#):
> >
> > Of course, each time I insert a new sentence I have to wait until Julia compiles and execute again.
> 
> Have you tried Revise.jl? It’s a game-changer.

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.

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [October 8, 2020, 12:43pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/68 "2020-10-08T12:43:20Z")

</div>

I’d recommend using VSCode’s `@enter`/`@run` macros for debugging in an already running process.

---

<div class="post-metadata">

**Author:** ![ianfiske](https://avatars.discourse-cdn.com/v4/letter/i/58f4c7/32.png) [@ianfiske](https://discourse.julialang.org/u/ianfiske)\
**Post date:** [October 8, 2020, 12:44pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/69 "2020-10-08T12:44:31Z")

</div>

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](https://github.com/JuliaDebug/Infiltrator.jl) and [https://github.com/antoine-levitt/Exfiltrator.jl](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.

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [October 8, 2020, 1:00pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/70 "2020-10-08T13:00:06Z")

</div>

> [@pfitzseb](#):
>
> I’d recommend using VSCode’s `@enter` / `@run` macros

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

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [October 8, 2020, 2:01pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/71 "2020-10-08T14:01:19Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mancolric](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mancolric/32/21799_2.png) [@mancolric](https://discourse.julialang.org/u/mancolric)\
**Post date:** [October 8, 2020, 3:13pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/72 "2020-10-08T15:13:55Z")

</div>

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).

> [@kristoffer.carlsson](#):
>
> Which people are you addressing with this post?

To the developers (some of you, right?)

> [@kristoffer.carlsson](#):
>
> However, for debugging it is usually enough to run stuff on a very small model.

I am using a toy example.

> [@yha](#):
>
> Are you using `Revise` ?

> [@kristoffer.carlsson](#):
>
> Have you tried Revise.jl?

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.

---

<div class="post-metadata">

**Author:** ![mancolric](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mancolric/32/21799_2.png) [@mancolric](https://discourse.julialang.org/u/mancolric)\
**Post date:** [October 8, 2020, 3:25pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/73 "2020-10-08T15:25:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [October 8, 2020, 3:28pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/74 "2020-10-08T15:28:42Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![yha](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/yha/32/3502_2.png) [@yha](https://discourse.julialang.org/u/yha)\
**Post date:** [October 8, 2020, 3:36pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/75 "2020-10-08T15:36:31Z")

</div>

> [@mancolric](#):
>
> 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.

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](https://github.com/mauro3/Parameters.jl) 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).

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [October 8, 2020, 3:36pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/76 "2020-10-08T15:36:37Z")

</div>

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).

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [October 8, 2020, 3:40pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/77 "2020-10-08T15:40:11Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [October 8, 2020, 3:44pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/78 "2020-10-08T15:44:58Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![mancolric](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mancolric/32/21799_2.png) [@mancolric](https://discourse.julialang.org/u/mancolric)\
**Post date:** [October 8, 2020, 3:50pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/79 "2020-10-08T15:50:09Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![RoyiAvital](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/royiavital/32/571_2.png) [@RoyiAvital](https://discourse.julialang.org/u/RoyiAvital)\
**Post date:** [October 8, 2020, 6:57pm UTC](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638/80 "2020-10-08T18:57:19Z")

</div>

> [@PetrKryslUCSD](#):
>
> 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.

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.

[Previous page](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638.md?page=3)

[Next page](https://discourse.julialang.org/t/debugger-status-and-future-plans/43638.md?page=5)