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:
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:
- Elixir
- VS Code
- Plugin ElixirLS: Elixir support and debugger (wymaga Erlanga 19 w zwyż)
- Projekt stworzony w mix
- 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:
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?
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.