September 20, 2014
On Friday, 19 September 2014 at 11:48:28 UTC, Marco Leise wrote:
> By the way, does anyone else use
> std.experimental.logger yet? Dicebot?

No, I provide purely management service here, aggregating reviews/opinions of other community members.
September 20, 2014
Seeing how MultiLogger passes on the payload to its child
loggers by ref, I tried to make it const, so that no Logger
implementation can "correct" any of the values and spoil it
for the others in the list.
Then I noticed, that isn't possible because the payloads
contain indirections and one logger takes payloads apart into
separate variables (FileLogger) while others build payloads
from separate variables. Catch 22. You cannot have:

    protected void beginLogMsg(string file, int line, string funcName,
        string prettyFuncName, string moduleName, LogLevel logLevel,
        Tid threadId, SysTime timestamp, Logger logger)
        @trusted
    {
        static if (isLoggingActive)
        {
            header = LogEntry(file, line, funcName, prettyFuncName,
                moduleName, logLevel, threadId, timestamp, null, logger);
        }
    }

and

    override void writeLogMsg(const ref LogEntry payload)
    {
        this.beginLogMsg(payload.file, payload.line, payload.funcName,
            payload.prettyFuncName, payload.moduleName, payload.logLevel,
            payload.threadId, payload.timestamp, payload.logger);
        …
    }
.

Also I wonder if Tid is the correct information to pass in. It is actually just an MBox from std.concurrency. The real thread handle is the Thread, which also contains its name, which might be more useful for logging. What do you think?

-- 
Marco

September 20, 2014
On Saturday, 20 September 2014 at 10:24:30 UTC, Marco Leise wrote:
> Also I wonder if Tid is the correct information to pass in.
> It is actually just an MBox from std.concurrency. The real
> thread handle is the Thread, which also contains its name,
> which might be more useful for logging. What do you think?

See also https://github.com/D-Programming-Language/phobos/pull/2482

For std.log I think Tid more useful because it clearly denotes execution context while thread ID is more of an implementation detail (considering message-passing is promoted as a standard D thing)
September 20, 2014
Ok, then here are my thread-safety changes for std.logger:

https://github.com/burner/logger/pull/19

-- 
Marco

September 21, 2014
Moved to: https://github.com/burner/phobos/pull/2

I did some simple benchmark, logging "Hello world" 1_000_000
times with the default logger. (DMD with release settings).
Comparing the version before the thread-safety changes with
the one afterwards. The timings are: 6.67s and 6.66s - so it
is -0.15% slower now. :p
Yes, I'm just trying to confuse you. Within margin of error
the performance stays the same.

The default logger is using lockingTextWriter() for optimum performance. I compared it with a logger I wrote a while ago and which I ported to std.experimental.logger.core.Logger, but extends it by honoring the system locale for terminal output:

Assuming LC_ALL=de_DE.iso88591 it
* formats the message using Phobos' formattedWrite(...)
* converts UTF-8 to UTF-16
* passes it to ICU for normalization (to combine accents)
* transcodes the NFC UTF-16 with ICU to system local
* uses POSIX write() to dump it to the terminal

With all the overhead it still takes only 2.26s for the same 1_000_000 messages. If I use a UTF-8 terminal and skip string conversion it will be 2.03s. So on the one hand it means string transcoding accounts for ~10% and on the other that there is 228% overhead with the default logger. :) Some of which might be low hanging fruit. But that should not be part of this review (which is about API). It was just an observation I wanted to share.

-- 
Marco

October 24, 2014
On Friday, 8 August 2014 at 09:16:11 UTC, Robert burner Schadek wrote:
> could you elaborate please? Currently I use the version statements in two template functions. I'm not sure why one would brand this negatively as a leak into the library.
>
For example we don't reinstatiate templates if they are instantiated in an imported module. But that module might have been compiled with different settings.

> Thank you for taking the time, but I found several conceptional problems with that POC. The worst being that if I make the LogLevel inside the TestLogger anything other than a enum it fails, as it is used in the template constraint. That would mean the LogLevel is fixed at CT.

Well if your test logger only knows it's log level at runtime, then you obviously can do the comparison only at runtime. You can solve this by checking whether minLogLevel is a compile time constant in the log constraints adding another overload for runtime configurable log levels.

11 12 13 14 15 16 17 18 19 20 21
Next ›   Last »