I agree, for the scenario Arno describes, using the tracing tools is a more appropriate approach rather than logging, as you almost certainly want to only trace messages matching a certain pattern to prevent overload. I'm not sure I think a trace log level makes much sense when for the things you would use it for, are tracing activities that you would use the tracing tools for instead. This is a bit of a switch from say Java, where you don't have the runtime tracing tools that OTP has, and it makes sense to have tracing logs to fill the gap.
Paul On Sun, Dec 10, 2017 at 1:57 PM, Michał Muskała <[email protected]> wrote: > Logs such as every message to a GenServer (any any other OTP behaviour) > are already provided by OTP and can be enabled without any changes to code > with > > :sys.trace(pid, true) > > There's also the VM function & process tracing. I don't think adding logs > for things like that is actually useful when we have such powerful tools > provided by the runtime. > > Michał. > > On 10 Dec 2017, 20:52 +0100, Arno Mittelbach <[email protected]>, wrote: > > Having recently made the journey from Java to Elixir I was also struck by > the inflexibility of the built-in logging framework. The inability to > configure log levels per module/application lead me to create FlexLogger ( > https://hex.pm/packages/flex_logger) which, however, is a crude > substitute for a built-in solution with compile-time purging as it performs > run-time checks. > > Besides, I would also like to argue for an extra log level for trace > messages. While usually the existing log levels are sufficient there are > cases where you would like to have the ability to, for example, log every > single message coming to a genserver. For most cases this would be a total > overkill of messages and in particular the high amount might lead to logs > being unreadable. But for understanding what goes on in this particular > genserver these kinds of logs could be invaluable. For now, I am usually > commenting out debug messages of the trace type (or most often I am > actually deleting them once I think everything is fine) and add them back > when needed. So I for one would be very happy with an additional log level > (especially in combination with module/application specific setting of log > levels). > > Arno > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/elixir-lang-core/b108e778-e883-4ab3-99d6- > 6f1bb215123c%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/b108e778-e883-4ab3-99d6-6f1bb215123c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/elixir-lang-core/7da2b127-bd8f-4121-ae02-c25215cd4a98%40Spark > <https://groups.google.com/d/msgid/elixir-lang-core/7da2b127-bd8f-4121-ae02-c25215cd4a98%40Spark?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK%3D%2B-Tu6u3S9UeyaNP22o4GF-S%2B1sxYuC2LTO9uRrWccuVLXKg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
