Jump to page: 1 2
Thread overview
std.experimental.logger default log level is everything
May 28, 2021
SealabJaster
May 28, 2021
SealabJaster
May 28, 2021
ikod
May 28, 2021
Alexandru Ermicioi
May 28, 2021
singingbush
May 31, 2021
Mathias LANG
May 31, 2021
Robert Schadek
Jun 06, 2021
Robert Schadek
May 28, 2021
This code outputs "tracing":

```d
void main()
{
    import std.experimental.logger;
    sharedLog.trace("tracing");
}
```

Why does this happen, because the default log level is `all`.

Why would this be a problem? Because if I'm writing a library, what I want to put into tracing is stuff like protocol packet contents, very, very fine grained checks/internal state, etc.

If someone uses my library, then they get tracing messages to stderr *by default*.

IMO, the default level should be either `off` (no logging) or `fatal`. I shouldn't see trace messages without opting in to logging.

It makes std.experimental.logger unusable inside a public library, or else I have to stick it behind a special dub configuration to enable it.

Thoughts?

-Steve
May 28, 2021
On Friday, 28 May 2021 at 17:29:48 UTC, Steven Schveighoffer wrote:
> Thoughts?
>
> -Steve

I like how it's handled in C#'s Microsoft logging library. Without some form of being able to distinguish between "log from app" and "log from library X/Y/Z", std.logger doesn't seem usable inside of libraries (maybe if the library is a framework, then you could get away with it possibly).

https://docs.microsoft.com/en-us/dotnet/core/extensions/logging
May 28, 2021
On Friday, 28 May 2021 at 17:57:27 UTC, SealabJaster wrote:
> https://docs.microsoft.com/en-us/dotnet/core/extensions/logging

Here's another, probably more up-to-date link https://docs.microsoft.com/en-us/aspnet/core/fundamentals/logging/?view=aspnetcore-5.0

May 28, 2021
On 5/28/21 1:57 PM, SealabJaster wrote:
> On Friday, 28 May 2021 at 17:29:48 UTC, Steven Schveighoffer wrote:
> 
> I like how it's handled in C#'s Microsoft logging library. Without some form of being able to distinguish between "log from app" and "log from library X/Y/Z", std.logger doesn't seem usable inside of libraries (maybe if the library is a framework, then you could get away with it possibly).
> 
> https://docs.microsoft.com/en-us/dotnet/core/extensions/logging

Unfortunately, std.experimental.logger doesn't seem to have a mechanism to filter logs based on source. I think adding a separate filtering system (I've used similar things like log4j, and written some myself) would be a huge undertaking.

-Steve
May 28, 2021
On Friday, 28 May 2021 at 18:48:56 UTC, Steven Schveighoffer wrote:
> On 5/28/21 1:57 PM, SealabJaster wrote:
>> On Friday, 28 May 2021 at 17:29:48 UTC, Steven Schveighoffer wrote:
>> 
...

> Unfortunately, std.experimental.logger doesn't seem to have a mechanism to filter logs based on source. I think adding a separate filtering system (I've used similar things like log4j, and written some myself) would be a huge undertaking.
>
> -Steve

In my libraries I usually call tracing/loging with debug's like:
   debug(mylibrary) tracef(...);

so by default library user will not see any log messages from library code. User have to enable debug=mylibrary in dub config or in makefile, so he become aware of the consequences.

May 28, 2021
On 5/28/21 3:09 PM, ikod wrote:

> In my libraries I usually call tracing/loging with debug's like:
>     debug(mylibrary) tracef(...);
> 
> so by default library user will not see any log messages from library code. User have to enable debug=mylibrary in dub config or in makefile, so he become aware of the consequences.
> 

Sure, but you shouldn't have to do that. It's trivial to change the default log level in phobos and then libraries have a choice on how to support logging.

Plus, things like info logging might not be correct to put behind a debug statement.

For example, vibe-d always has logging enabled, but the default is reasonable.

-Steve
May 28, 2021
On Friday, 28 May 2021 at 18:48:56 UTC, Steven Schveighoffer wrote:
> On 5/28/21 1:57 PM, SealabJaster wrote:
>> On Friday, 28 May 2021 at 17:29:48 UTC, Steven Schveighoffer wrote:
>> 
>> I like how it's handled in C#'s Microsoft logging library. Without some form of being able to distinguish between "log from app" and "log from library X/Y/Z", std.logger doesn't seem usable inside of libraries (maybe if the library is a framework, then you could get away with it possibly).
>> 
>> https://docs.microsoft.com/en-us/dotnet/core/extensions/logging
>
> Unfortunately, std.experimental.logger doesn't seem to have a mechanism to filter logs based on source. I think adding a separate filtering system (I've used similar things like log4j, and written some myself) would be a huge undertaking.
>
> -Steve

You can still implement custom logger, that will allow filtering by source,check the documentation: https://dlang.org/phobos/std_experimental_logger.html

It indeed might be useful to have a logger configurable by some file as a package in dub, and it can actually be integrated with existing api. It can either replace main logger or expose a custom logger, if necessary.

Best regards,
Alexandru.
May 28, 2021
On Friday, 28 May 2021 at 17:29:48 UTC, Steven Schveighoffer wrote:
> IMO, the default level should be either `off` (no logging) or `fatal`. I shouldn't see trace messages without opting in to logging.

I agree, defaulting to LogLevel.all was a bad choice. I also think that std.experimental.logger shouldn't setup a logger by default. It's very easy for a user to opt in using `sharedLog = new MyLogger();` I'm happy for phobos to include a Logger implementation but the default behaviour should be to not output anything unless a Logger has been explicitly assigned to sharedLog.


May 31, 2021

On Friday, 28 May 2021 at 17:29:48 UTC, Steven Schveighoffer wrote:

>

[...]

IMO, the default level should be either off (no logging) or fatal. I shouldn't see trace messages without opting in to logging.

Expectations vary depending on the developer. I, for one, would expect Info to be the default level, but would be surprised if I wrote code and it did nothing by default.

>

It makes std.experimental.logger unusable inside a public library, or else I have to stick it behind a special dub configuration to enable it.

Thoughts?

-Steve

I think what makes std.experimental.logger unusable inside a public library is the lack of hierarchy. Tango had loggers that were object and hierarchical.
Ocean has them too: https://github.com/sociomantic-tsunami/ocean/blob/v6.x.x/src/ocean/util/log/Logger.d

We use them a lot in our app, e.g. having this.log = Log.lookup(__MODULE__); in the class' ctor. They can be configured to output to stdout, file(s), or any other output (e.g. Ocean has syslog support). In our unit tests, we save all log output to a circular buffer, which we print if an assert is triggered, this way we don't clutter the output of the run, but still provide detailed informations on (possibly spurious) failure.

They can also be configured: https://github.com/bosagora/agora/blob/2809791954133da4c352d612d7347ee667e65312/doc/config.example.yaml#L172-L222
In our server app, we even have a control interface (bound to localhost) which allow us to dynamically reconfigure them. E.g. there was a bug recently, I just SSH into the machine and run curl -X POST '127.0.0.1:3000/admin/logger?name=root&level=Trace&console=true' (https://github.com/bosagora/agora/blob/2809791954133da4c352d612d7347ee667e65312/source/agora/api/Admin.d#L36-L42) and voila, everything is being logged out.

Oh, and you can set a buffer that is to be used, so they don't keep on allocating.

May 31, 2021

On Monday, 31 May 2021 at 00:42:50 UTC, Mathias LANG wrote:

>

On Friday, 28 May 2021 at 17:29:48 UTC, Steven Schveighoffer wrote:

>

[...]

IMO, the default level should be either off (no logging) or fatal. I shouldn't see trace messages without opting in to logging.

The amount of bug reports that lib would have gotten if it were off be default
would properly be very large.

To be frank, I would assume everybody replying to this thread, would have made
a better job implementing a logger than I did all that time back, would be able to
read the docs and insert a:

void main() {
    globalLogLevel = LogLevel.off;
}

:-)

>

I think what makes std.experimental.logger unusable inside a public library is the lack of hierarchy. Tango had loggers that were object and hierarchical.
Ocean has them too: https://github.com/sociomantic-tsunami/ocean/blob/v6.x.x/src/ocean/util/log/Logger.d

The docu is properly bad, but you can build hierarchies with MultiLogger.

« First   ‹ Prev
1 2