Debugging tips?

Questions / Help
,
1

Hey, I’m following along with Dave’s awesome “Elixir for Programmers” courses and I’m really working on my own building stuff to get good practice in.

One thing is I’ve noticed a significantly more challenging to debug than, say, ruby…

I suppose it gets more problematic when pids/processes are involved.

For example, the first thing is I’ll struggle with harder to read error messages (I’m sure I’ll get used to that). That’s not really a problem, just something getting used to.

Then, I’ll try using pry but it will crash processes at even the slightest problem/mistype. This causes all the processes to crash and reboot, so all the pids are dead, so I need to respawn them manually in the console to get a fresh pid or reboot the entire pry session.

Some things I type, like module constants, or some methods, will generate other errors so I have to manually change tons of code while debugging to make it ‘fit’ within pry so it won’t error (for example Ill have to say Agent.update(pid, ...) instead of Agent.update(@me, ...). There’s been times where I’ll get 4 separate erlang errors in a row that look like deep deep exceptions, but it won’t seem to be related to anything I just typed (more like things/processes failing?)

Worst of all, once it crashes and I restart IEX, it doesnt remember any my console history, so I literally have to RETYPE every single thing from scratch. This one is probably the absolute worst, and causes major headache. I have to keep a whole text file scratchpad open of lines I can copy and paste in. I think if there was one thing to fix it would be this.

If I’m missing anything here I’d love to figure out what I could improve, or what I’m missing to make this easier. Things that would take 45 seconds in ruby are taking me like an hour just struggling with fussy processes and retyping.

Thanks!

1 Like
2

For anyone else in similar shoes, I did find this thread: https://stackoverflow.com/questions/45405070/how-do-i-save-iex-history

I notice some of the commands don’t show up for some reason, but it (mostly) works so this is good.

1 Like
3

Another tip I found from docs: <C-\> aborts IEx without having to push <C-c> twice

1 Like
4

Do you have examples?

Usually the core team tries to make error messages as clear as possible, they try to keep them short concise though. No letters of love as in elm.

I usually do not use pry or even the BEAM-debugger. I feel much more comfortable with properly placed Logging statements.

This is not worst, this is a really cool feature I think. I really love having a clean state, I’m jumping around projects though and the interleaved histories would annoy me, so I completely rely on tab-completion.

But with OTP 20 there is an experimental feature which grants you a persistent history.

I really never had this problem, but in ruby I didn’t in process-debugging as well. I used properly placed debug-messages there as well.

To be honest, I prefer them in any language I use. A technique I can transfer easily, while I had to learn other tools for every language anew (while I have to say, that I really like the idea of rr-debugger, where you can step backwards as well after you have recorded an execution sample).

1 Like
5

For me its easier to hit CTRL-c twice than hitting CTRL-ALT GR-ß once. Also, CTRL-c-menu provides you with some tools

1 Like
6

It’s funny how every one has it’s preferred way :slight_smile: I’m used to ctrl+c followed by a. And I much prefer that, than having to write exit in ruby shell, or exit() in python shell.

1 Like
7

Maybe this would be helpful. IEx — IEx v1.16.0
Add the commands to that file and every time you start iex it will be evaluated.

Personally I never needed to use pry. Then again I haven’t done anything with processes yet.

1 Like
8

If I’m missing anything here I’d love to figure out what I could improve, or
what I’m missing to make this easier. Things that would take 45 seconds in
ruby are taking me like an hour just struggling with fussy processes and
retyping.

If you write tests first there’s no “retyping” necessary, you refresh
your environment cleanly on each run (and Elixir tests run fast!) and
you can jump in with Pry as necessary.

9

tl;dr I use CTRL-g instead.

I’ve experienced a funny side effect of getting trained to hit CTRL-c twice rapidly.

For development across applications we use heroku local, which is modeled after the foreman tool but it runs through Node. The parent process spawns various sub-processes, and when you hit CTRL-c it starts to shut them down. Killing heroku local while it is in the process of shutting down will often leave dangling processes, which then need to be found and killed manually.

1 Like
10

I’ll try to generate an error today, they looked like Erlang errors though, not elixir… so they looked way more obscure than the average error I was used to seeing. I’ll look again to be sure.

11

Heres an example

21:49:54.022 [error] [wx: :error, message: 'wxWidgets Assert failure: ./src/generic/listctrl.cpp(3422): "litem >= 0 && (size_t)litem < GetItemCount()" in SetItemState() : invalid list ctrl item index in SetItem']

12

Hello,

I occurred the same error when run :observer.start in iex.

16:10:31.141 [error] [wx: :error, message: 'wxWidgets Assert failure: ./src/generic/listctrl.cpp(3422): "litem >= 0 && (size_t)litem < GetItemCount()" in SetItemState() : invalid list ctrl item index in SetItem']

16:10:31.142 [error] [wx: :error, message: 'wxWidgets Assert failure: ./src/generic/listctrl.cpp(3422): "litem >= 0 && (size_t)litem < GetItemCount()" in SetItemState() : invalid list ctrl item index in SetItem']

and then see the following info populated in iex shell:

2020-06-30 16:14:14.742 beam.smp[5853:139420] imkxpc_getApplicationProperty:reply: called with incorrect property value 4, bailing.
2020-06-30 16:14:14.742 beam.smp[5853:139420] Text input context does not respond to _valueForTIProperty:
2020-06-30 16:14:14.742 beam.smp[5853:139420] imkxpc_getApplicationProperty:reply: called with incorrect property value 4, bailing.
2020-06-30 16:14:14.742 beam.smp[5853:139420] Text input context does not respond to _valueForTIProperty:
2020-06-30 16:14:15.463 beam.smp[5853:139420] imkxpc_getApplicationProperty:reply: called with incorrect property value 4, bailing.
2020-06-30 16:14:15.463 beam.smp[5853:139420] Text input context does not respond to _valueForTIProperty:

I checked my local wxmac is the latest version wxmac-3.0.5.1_1 before upgrade, after I upgraded erlang@22 via brew upgrade erlang@22 resolve this issue for me.

Here are some upgrade info via brew

==> Upgrading 1 outdated package:
erlang@22 22.3.4.1 -> 22.3.4.2
==> Upgrading erlang@22 22.3.4.1 -> 22.3.4.2
==> Downloading https://homebrew.bintray.com/bottles/wxmac-3.0.5.1_1.catalina.bottle.tar.gz
==> Downloading from https://akamai.bintray.com/11/110aa0b2134d8bff1647de0cd8500f160133794b347f789bba3e1894b991b788?__gda__=exp=1593506229~hmac=40598a00712c2de00859797cbaa5bca7075f7a14d91cac975ffef9947eb62bf8&response-content-disposition=attachment%3Bfilename%3D%22wxmac-3.0.5.1_1.c
######################################################################## 100.0%
==> Downloading https://homebrew.bintray.com/bottles/erlang%4022-22.3.4.2.catalina.bottle.tar.gz
==> Downloading from https://akamai.bintray.com/ae/ae50a728ad458fe9378e9c2d90028851363d5cacef137070af0493c6aa863899?__gda__=exp=1593506266~hmac=10de3ea12b64542dca66ec58bfd1afec80960e2fb17efa9a3a8b35b87c63366e&response-content-disposition=attachment%3Bfilename%3D%22erlang%4022-22.3.
######################################################################## 100.0%
==> Installing dependencies for erlang@22: wxmac
==> Installing erlang@22 dependency: wxmac
==> Pouring wxmac-3.0.5.1_1.catalina.bottle.tar.gz
🍺  /usr/local/Cellar/wxmac/3.0.5.1_1: 810 files, 23.0MB
==> Installing erlang@22
==> Pouring erlang@22-22.3.4.2.catalina.bottle.tar.gz

Hope the above is useful for you.

1 Like