Ninigi
Is there a way to inspect a list of integers without accidentally ending up with a charlist?
Story
skip this if you are not interested in the Why
Today I was working on a rewrite of a feature, heavily relying on a 3rd Party HTTP API response, no tests available yet, so I decided to bite the bullet and do what I felt like I had to do. Fortunately all the API connections are done in a way, so at least parts of the return values can be mocked, and no actual request has to be made, but you need to provide a valid response.
The response in this case happened to be a big map - 140+x lines of code after parsing the JSON response and running it through the Elixir Formatter. So I thought I was clever, and ran a real example, writing the response to a txt file, and using File.write!(path, inspect(response), so I could copy-paste a real response into a fixture. The problem was that one part %{..., something_ids: Enum.map(raw["something"], & &1["id"]), ... returned [123], which everyone intuitively knows equals to '{' when inspected, because ?{ == [123].
I was running into weird bugs, because '{' was passed down to an ecto query, which would of course find nothing with those ids, and I was banging my head against the wall, why the hell the changeset error was “invalid association” (a lot more going on behind the scenes, but you get the idea). So, I put IEx.pry into multiple places, and saw the error in the fixture. I did not think much about it, replaced it with the value I knew it should be and… It still did not work.
Of course I put IO.inspect(something_ids) in multiple places and always got '{'. At that time I was already stressed out, because that was NOT the bug I was hunting, this was something in my test setup!
After some more head-banging-against-the-wall, I pasted a screen recording into our developer chat, asking what’s going on, and only 1 minute later someone said "does this explain anything? ?{ #=> [123], and I was very ready to bang my head even more, this time voluntarily, for being such an idiot.
Problem
I think I have a basic understanding of why a list of integers might be displayed as a string, but it gave us problems debugging multiple time now - in fact the guy who gave me the clue, was someone I had given the same clue a few months ago.
Not only debugging tends to get harder, if your outputs are displayed differently than what you would expect, but also admin UIs: I frequently use inspect in interfaces, for example to display exq failed jobs and the arguments, error message etc.
Question
I understand this might be a problem with internal representations, but is there any way to display a list of integers (that could, or could not) be a list of characters?
Sidenote
The universe decided to give me a headache with this, because incidentally, the original bug had the same error message.
Marked As Solved
nathanl
Take a look at Inspect.Opts and the :charlists option.
[123, 124] |> IO.inspect(charlists: :as_charlists) # => '{|'
[123, 124] |> IO.inspect(charlists: :as_lists) # => [123, 124]
[123, 124] |> IO.inspect(charlists: :infer) # => '{|'
When the default
:infer, the list will be printed as a charlist if it is printable, otherwise as list. SeeList.ascii_printable?/1to learn when a charlist is printable.
Also Liked
NobbZ
You can pipe into everything… And the nice thing about IO.inspect is, its an identity function. It will return exactly what you gave it. Together with the :label option, its ideal to do ad-hoc debugging of pipelines:
1
|> IO.inspect(label: "before")
|> Kernel.+(1)
|> IO.inspect(label: "after")
NobbZ
You shouldn’t use IEx.i/1 from within code…
NobbZ
Why should I?
I use IEx.i/1 from iex, while I use IO.inspect/2 from within my code.
NobbZ
i/1 is a helper in iex, it describes the data it sees and prints this description into the terminal, and nothing else. And because some magic in iex its return value is omitted.
Though by doing exactly that, piping the result of i/1 into IO.inspect I’ve learned that it returns :"do not show this result in output".
Popular in Questions
Other popular topics
Latest on Elixir Forum
Sponsor Spotlight
Courses that'll move you from confusion to "Aha, now I get it!"
Categories:
Sub Categories:
Forums
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Develop your skills with books, videos, and courses.
Producing high quality Elixir screencasts since 2017.
Enabling companies to succeed by building software people love.
Courses that'll move you from confusion to "Aha, now I get it!"