Dobra, miało być o czymś innym, ale ostatnio zrobiłem reinstalkę i tak instaluje powoli wszystkie elementy w tym i edytor oraz pluginy do elixir i nagle natrafiłem na coś takiego…to jest screen zrobiony przeze mnie:

Debuggowanie Elixir z poziomu VS Code
Debuggowanie Elixir z poziomu VS Code

Z zamiarem opisania debuggera zbieram się już od wielu tygodni… i chyba pora to przyspieszyć. Dziś zaś krótko o tym, że w VS Code możemy! debuggować kod napisany w elixir – dosłownie, jak ktoś z was jest C# dev to na pewno doceniał tę funkcję w Visual Studio. Jak była potrzebna to można było dzięki niej zdziałać cuda.

Tutaj zaś może mamy ograniczoną wersję, ale mamy. Jak coś nam nie działa to nie musimy odpalać metodę z różnymi parametrami i logować wszystko by potem sprawdzić co poszło nie tak. Możemy po prostu odpalić aplikację i sobie sprawdzić co poszło nie tak :)

Dobra, ale co jest potrzebne do tego by zdebuggować kod w elixir z pomocą VS Code? Ogólnie 5 rzeczy:

  1. Elixir
  2. VS Code
  3. Plugin ElixirLS: Elixir support and debugger (wymaga Erlanga 19 w zwyż)
  4. Projekt stworzony w mix
  5. Mała konfiguracja (prosta)

Zakładam, że pierwsze trzy rzeczy z listy nie stanowią problemu.

Stworzenie projektu pod test debugowania

Na początku trzeba stworzyć jakiś prosty projekt, w tym celu w terminalu wpisujemy:

Gutek-Mac$ mix new test_proj
* creating README.md
* creating .gitignore
* creating mix.exs
* creating config
* creating config/config.exs
* creating lib
* creating lib/test_proj.ex
* creating test
* creating test/test_helper.exs
* creating test/test_proj_test.exs

Your Mix project was created successfully.
You can use "mix" to compile it, test it, and more:

    cd test_proj
    mix test

Run "mix help" for more commands.

To nam stworzy katalog test_proj, wejdźmy do niego i otwórzmy code:

Gutek-Mac$ code .

Fajnie by było mieć jakiś kod, który można przetestować. Ja wziąłem bencode.ex z mojego repo. Ten plik wgrałem do katalogu lib i tak go zostawiłem.

“Mała” konfiguracja

Przy debugowaniu mamy dwie opcje, albo będziemy debugować testy albo aplikację.

Debugowanie testów

Jeżeli testy, to do pliku test_proj_test.exs dodajmy test/albo zmodyfikujmy istniejący test tak by wywoływał on Bencode.decode("i1l"):

defmodule TesProjTest do
  use ExUnit.Case
  doctest TesProj

  test "the truth" do
    Bencode.decode("i1e")
  end
end

Debugowanie aplikacji

Tutaj, jeżeli nie mamy aplikacji, która działa i się odpala, to zróbmy mały trick. Otwórzmy plik mix.exs i zmodyfikujmy linijkę 18:

[extra_applications: [:logger]]

na

[mod: {TestProj , []}, applications: []]

Następnie zmodyfikujmy plik lib\test_proj.ex:

defmodule TestProj do
  use Application

  def start(_type, _args) do
    Bencode.decode("i1e")
  end
end

To wystarczy. Przy odpaleniu z miejsca zostanie wykonana metoda start/2 która wykona nasz decode/1. Nie przejmujcie się, że to nie jest jakieś super dobre i działające rozwiązanie. Robi swoje – czyli daje wam możliwość testowania kodu.

Break Pointy

Pora ustawić break pointy. W zależności od tego jaką opcję wybraliśmy możemy jest ustawić albo w pliku testowym albo w aplikacyjnym albo po prostu w metodzie Bencode.decode/1. Jak wolimy.

Ustawienie break pointu jest możliwe po kliknięciu po lewej od numeru linii albo za pomocą F9.

Debuggowanie

Mając tak ustawione breakpointy możemy odpalić debuggowanie. W tym celu klikamy F5 albo z menu wybieramy Debug | Start Debugging. Pierwsze odpalenie nic nam nie da, zostanie utworzony zaś plik lanuch.json:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "mix_task",
            "name": "mix (Default task)",
            "request": "launch",
            "projectDir": "${workspaceRoot}"
        },
        {
            "type": "mix_task",
            "name": "mix test",
            "request": "launch",
            "task": "test",
            "taskArgs": [
                "--trace"
            ],
            "projectDir": "${workspaceRoot}",
            "requireFiles": [
                "test/**/test_helper.exs",
                "test/**/*_test.exs"
            ]
        }
    ]
}

Który daje nam dwie opcje debugowania – mix (Default task) i mix test. W zależności od tego jaką drogę obraliśmy, musimy wybrać odpowiedni task. By to zrobić otwieramy View | Debugger i tam na górze wybieramy odpowiedni task:

Wybór akcji debuggowania :)
Wybór akcji debuggowania :)

Teraz jak ponownie odpalimy test już nam wszystko powinno zadziałać tak jak trzeba.

Podsumowanie

Dobra, to był szybki tutorial, ale jak to zobaczyłem to naprawdę rzuciłem to co pisałem i to opisałem :) tak bardzo mi się ta funkcja podoba. Może to spowoduje, że zostanę przy VS Code jeszcze trochę? :) zobaczymy.

Znaliście tę funkcję? Ten plugin? Podoba się wam?

2 KOMENTARZE

  1. Z debugowaniem w Elixirze wiąże się pewne ryzyko. Debugger stopuje pojedynczy proces na czas inspekcji, ale cała reszta systemu cały czas działa. W Elixirze nie ma czegoś takiego jak “zatrzymaj świat”. Oznacza to że jak debuggujesz jakiś proces a ktoś próbuje się z nim komunikować, to ryzykujesz śmierć procesów z powodu timeoutu. Jako alternatywe do debuggowania stosuje się _tracing_ w którym nasłuchujesz na komunikację między procesami bez ich zatrzymywania. Pomocne są tutaj Erlangowe narzędzia takie jak Redbug albo Recon.

    • Jasne, masz racje! Debugger jest tutaj ograniczony. Ale fajnie ze można z niego skorzystać z poziomu vs code. Przy nauce zaś i próbie zrozumienia co i jak jest wyświetlane może okazać sie bardzo ale to bardzo przydatny.

Comments are closed.