Slog - prints multiple values as string for debugging (feedback requested)

Your Libraries & OS Mentoring Libraries
1

Slog is an experimental module to print anything (single/multiple values) as string for debugging. Slog takes a list of values or a single value that is printed as string for debugging. Any value (string, atom, map, list, struct, keyword list …) except functions can be printed as string with slog.

Github Link - https://github.com/palerdot/slog
Hex Docs Link - https://hexdocs.pm/slog/readme.html

For now it is recommended to use only in :dev, :test environments.

Feedbacks appreciated.

1 Like
2

I have not much to say, but I have to ask what this gives me over logger? In logger I have full control about how values are rendered and I am able to easily guard all the debugstuff behind a severity filter. Also the metadata printed is a huge help in debugging (line number, Module and function name, filename, etc.).

Aside from that, I wanted to check how you handle binaries, as strings came out without quotes, and well, they break your output:

iex(1)> Slog.log ["asd", <<1,23,4>>]
<<97, 115, 100, 32, 1, 23, 4>>
2 Likes
3

Also I just realise, it doesn’t print anything, it only returns a string which one needs to print manually then…

2 Likes
4

How does this really differ, aside from maybe output format, from just using Kernel.inspect/2?

3 Likes
5

Thanks for reporting this. My main intention is to print multiple types (lists, maps, structs, atoms, strings …) together instead of using IO.inspect manually multiple times. Not sure how logger handles this. Right now, binaries are not printed the way it should. Will check it out.

6

I mainly created this to not to use IO.inspect manually for printing multiple values. Like able to print multiple types like lists, map, string together

7

You don’t need IO.inspect multiple times, just do IO.puts "asd #{inspect <<1,2,3>>}", or even better use Logger.debug in :dev with all metadata enabled, and you’ll get an output which helps with debugging even more, as it tells you exactly what caused the logging.

8

I think it a library like that has a place. Right now the implementation of inspect is not focused on speed - and rightfully so - it’s primarily used for debugging, so the output should be “nice” and not "fast. That’s usually not what you want for logging - for logging the conversion should be as fast as possible and often some “niceties” can be abandoned.

If the library focused on the speed of conversion and was comprehensible in handling all the types (probably also protocol-based), I think it could be useful.

3 Likes