Hello! An Elixir neophyte here. I’d like to debug my code using VS Code. I saw in the ReadMe for ElixirLS you can sink breakpoints for one’s code and step through it, as one might with an IDE (or other language even in VS Code).
The code I am learning with I’ve compiled by running iex -S mix and I am invoking MyModule.my_function(someArg) but the breakpoint i placed in VS Code on some line in my_function is never hit. I do see that there is an open issue where one can’t debug in an iex -S mix session. So that brings me to my question: How do I hit this break point? Is there some setup in VS Code or something to pass to mix to enable debugging so I can hit the breakpoint in VS Code?
Hi @nonware, this isn’t answering your question directly I know, but I tend to use an IO.inspect (or friends) either side of a function call as my primary debugging tool. Elixir is a functional language and by and large you put data into a function and get transformed data out with no side effects so I find this style of debugging quite effective for me personally. In addition, code recompile and reload in a running system is generally very quick and just works in Phoenix, so moving a few IO.inspects around while the system is running is no trouble. I coded a lot of .Net in the past and made heavy use of the Visual Studio debugging tools, which were excellent, but I honestly haven’t found the same need for that style of debugging (yet) in Elixir. In over 2 years I haven’t even taken the time to try and set them up.
I’d be keen to hear informed responses though - it’s probably about time I learned about it!
I’m having similar trouble with getting the vs code debugger working with elixir-ls. Would love to hear how folks are able to get the debugger working with ExUnit tests.
I am with @mindok on this one.
In a mutable language where variables can be changed under your nose, breakpoints are more useful in my opinion.
If you have such a big elixir/erlang function that you cannot keep track of the values of variables - and a breakpoint is the best(?) way to verify the value/state is what you expect; I think you may want to consider breaking that function up, so it is easier to comprehend.
Tools like :observer are also quite useful for real time debugging - as a breakpoint in the IDE does little to assist in understanding the rest of the state of the runtime at that point in time. This is a result of erlangs actor model, and concurrency characteristics - that traditional imperative languages do not use.
Also the built in :debugger module that opens a window will struggle in certain environments, like VScode + WSL, as there is not a xdisplay for the window. Not sure if this is what the elixir-ls breakpoint stuff relies on, but if developing in an environment that does not have native GUI capabilities, the functionality might not work.
Am also interested to hear compelling use cases for using breakpoints in the beam, as I might be missing something!
Attaching debugger to code running elsewhere (e.g. in terminal iex -S mix session) is currently not supported.
In order to debug and be able to hit breakpoints you need to run your code with a debugger. In VSCode go to Run And Debug tab ans choose an appropriate launch config. Alternatively you can debug tests from Testing tab or right clicking on an icon next to test definition and selecting Debug Test.
