Thread overview
[Issue 24468] stdThreadLocalLog does not print `log` and `trace` logs
Mar 29
kinke
May 28
Forest
May 29
Forest
March 29
https://issues.dlang.org/show_bug.cgi?id=24468

kinke <kinke@gmx.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kinke@gmx.net

--- Comment #1 from kinke <kinke@gmx.net> ---
According to the docs (https://dlang.org/phobos/std_logger_core.html#.stdThreadLocalLog), `stdThreadLocalLog` just forwards to `sharedLog`. The latter has a default LogLevel of info. So in your example, you'd need to set the `sharedLog.logLevel` *before* logging to `stdThreadLocalLog` (which defaults to `LogLevel.all`, forwarding everything to the shared logger).

The key info is in the std.logger package docs
(https://dlang.org/phobos/std_logger.html):
> The LogLevel of the stdThreadLocalLog can be used to filter log calls before they reach the sharedLog Logger.

Perhaps this should be duplicated in the documentation for the `stdThreadLocalLog` property.

--
March 30
https://issues.dlang.org/show_bug.cgi?id=24468

--- Comment #2 from Tomoya Tanjo <ttanjo@gmail.com> ---
Thank you for the information.
It works when I set `Loglevel.all` to both logger before calling logging
methods  as follows.

```dlang
    ...
    (cast()sharedLog).logLevel = LogLevel.all;
    stdThreadLocalLog.logLevel = LogLevel.all;

    writeln("==== stdThreadLocalLog ====");
    stdThreadLocalLog.log("log");
    ...
```

> Perhaps this should be duplicated in the documentation for the `stdThreadLocalLog` property.

I guess the information of default logLevel in each logger should be in the `Thread Local Redirection` section in std.logger because most users read the documents in std.logger first.

Can I close this issue or leave it opened until the document is improved? If the case of latter, I will send a pull request for it.

--
May 28
https://issues.dlang.org/show_bug.cgi?id=24468

Forest <forestix@nom.one> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |forestix@nom.one

--- Comment #3 from Forest <forestix@nom.one> ---
The experience I had today as a newcomer to Phobos logging:

- Read the std.logger docs.
- Create a StdForwardLogger for each of my modules.
  (I want to control each module's log level separately.)
- Discover that trace log messages are silently discarded.
- Set my logger's log level.
- Discover that trace log messages are still silently discarded.
- Read the std.logger docs again.
- Set globalLogLevel.
- Discover that trace log messages are still silently discarded.
- Read the std.logger docs again.
- Set sharedLog.logLevel.
- Discover that the compiler won't let me
  (none of the overloads of `logLevel` are callable using a `shared` mutable
object)
- Read the std.logger docs again.
- Notice how much time this basic task is taking, and swear in exasperation.
- Grovel through the dlang forum archive in search of help.
- Find the magic incantation here:
  https://forum.dlang.org/post/mveqddfktkykwvhombsl@forum.dlang.org
  (cast()sharedLog).logLevel = LogLevel.all;
- Try the magic incantation.
- Discover that the compiler won't let me use it in @safe code.

A default log level higher than `trace` is no surprise; that's reasonably common in logging libraries. However, dealing with it in Phobos is surprisingly painful.

In particular, the solution has at least these problems:

- It's nonintuitive.
- It's not clearly documented.
- It's unreasonably awkward for something as common as logging.
- It doesn't work at all in @safe code.

After finally getting to the bottom of it (and nearly giving up on D because this is far from the first Phobos usability problem to bite me) I see that I could work around it in my own programs by using @trusted code. However, I'm writing a library, and I really don't want to require that its users resort to library-specific functions or @trusted shenanigans to control such basic functionality as logging.

It would be nice if this was either fixed by a revised std.logger design, or at least hidden behind a clearly documented standard interface.

--
May 29
https://issues.dlang.org/show_bug.cgi?id=24468

--- Comment #4 from Forest <forestix@nom.one> ---
Also, is `(cast()sharedLog).logLevel = LogLevel.all` thread-safe?

If so, how is the user supposed to know that?

If not, where is the thread-safe equivalent?

--