On Tuesday, 30 September 2014 at 00:19:00 UTC, deadalnix wrote:
>
> It has been mentioned in the comment already, but log4j like
> approach seems better. Also, it is sad that output range are not
> leveraged to format/sample/filter/select output of the logger.

yeah log4j is totally awesome and shows IMO how pretty something can be build on top of std.logger. Even though it uses the non-range LogEntry from std.logger.

I haven't tested it yet, but have two questions anyway:

1. I did not see any reference to the use of Clock.currTime(), which on the last round accounted for about 90% of the total time spent in a log call.  Reference: https://issues.dlang.org/show_bug.cgi?id=13433 .  (This is the difference between logging-and-filtering ~100k logs/sec and ~1M logs/sec for loggers that use criteria other than logLevel for filtering messages.)  Same question for this cycle:  Does std.logger API need a method for clients or subclasses to change/defer/omit the call to Clock.currTime?  Or defer for a change in std.datetime?

2. We have Tid in the API.  What about Fiber and Thread?  If we can only pick one, I would vote for Thread rather than Tid, as Tid's currently have no way to be uniquely identified in a logging message.  Reference: https://issues.dlang.org/show_bug.cgi?id=6989

General comment: very nice to see continued progress!

On Wednesday, 1 October 2014 at 10:50:54 UTC, Kevin Lamonte wrote:
> I haven't tested it yet, but have two questions anyway:
>
> 1. I did not see any reference to the use of Clock.currTime(), which on the last round accounted for about 90% of the total time spent in a log call.  Reference: https://issues.dlang.org/show_bug.cgi?id=13433 .  (This is the difference between logging-and-filtering ~100k logs/sec and ~1M logs/sec for loggers that use criteria other than logLevel for filtering messages.)  Same question for this cycle:  Does std.logger API need a method for clients or subclasses to change/defer/omit the call to Clock.currTime?  Or defer for a change in std.datetime?
>

maybe I should add a disableGetSysTime switch

> 2. We have Tid in the API.  What about Fiber and Thread?  If we can only pick one, I would vote for Thread rather than Tid, as Tid's currently have no way to be uniquely identified in a logging message.  Reference: https://issues.dlang.org/show_bug.cgi?id=6989
>
> General comment: very nice to see continued progress!

I'm gone take a closer look

On Wednesday, 1 October 2014 at 10:50:54 UTC, Kevin Lamonte wrote:
> 2. We have Tid in the API.  What about Fiber and Thread?  If we can only pick one, I would vote for Thread rather than Tid, as Tid's currently have no way to be uniquely identified in a logging message.  Reference: https://issues.dlang.org/show_bug.cgi?id=6989

In my opinion only solution that scales is to provide same ID as one used by std.concurrency - it can be thread, fiber, process or pretty much anything. There are many possible threading abstractions and all can't be easily supported, makes sense to stick to one considered standard.

Am Wed, 01 Oct 2014 12:49:29 +0000
schrieb "Robert burner Schadek" <rburners@gmail.com>:

> maybe I should add a disableGetSysTime switch

CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST should be explored.
On Linux you can't expect finer resolution than the kernel Hz,
for FreeBSD I only found mention of 10ms resolution.
If you format log messages with 2 digits time precision
anyway, you don't need the precise version.

If you disable time completely, what would the LogEntry contain as the time stamp? SysTime.init?

-- 
Marco

On Wednesday, 1 October 2014 at 14:24:52 UTC, Marco Leise wrote:
> Am Wed, 01 Oct 2014 12:49:29 +0000
> schrieb "Robert burner Schadek" <rburners@gmail.com>:
>
>> maybe I should add a disableGetSysTime switch
>
> CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST should be explored.

good pointer, but what about Win and Mac

>
> If you disable time completely, what would the LogEntry
> contain as the time stamp? SysTime.init?

That was my first idea.

Am Wed, 01 Oct 2014 15:05:53 +0000
schrieb "Robert burner Schadek" <rburners@gmail.com>:

> On Wednesday, 1 October 2014 at 14:24:52 UTC, Marco Leise wrote:
> > Am Wed, 01 Oct 2014 12:49:29 +0000
> > schrieb "Robert burner Schadek" <rburners@gmail.com>:
> >
> >> maybe I should add a disableGetSysTime switch
> >
> > CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST should be explored.
> 
> good pointer, but what about Win and Mac

Windows 2000 had some function that returns 4ms accurate time,
I hope it is implemented like CLOCK_REALTIME_COARSE.
OS X ... oh well. Don't know. Just declare the "fast timer" a
hint, I guess. Like when you ask for anti-aliasing in OpenGL
and the implementation is free to decide if it can or want's
to deliver. So it turns into: "I need a sub-second
timestamp, but make it as fast as possible on the target OS".
Maybe some day Apple will copy CLOCK_REALTIME_FAST from
FreeBSD.

> >
> > If you disable time completely, what would the LogEntry contain as the time stamp? SysTime.init?
> 
> That was my first idea.



-- 
Marco

On 10/1/14 11:53 AM, Marco Leise wrote:
> Am Wed, 01 Oct 2014 15:05:53 +0000
> schrieb "Robert burner Schadek" <rburners@gmail.com>:
>
>> On Wednesday, 1 October 2014 at 14:24:52 UTC, Marco Leise wrote:
>>> Am Wed, 01 Oct 2014 12:49:29 +0000
>>> schrieb "Robert burner Schadek" <rburners@gmail.com>:
>>>
>>>> maybe I should add a disableGetSysTime switch
>>>
>>> CLOCK_REALTIME_COARSE / CLOCK_REALTIME_FAST should be explored.
>>
>> good pointer, but what about Win and Mac
>
> Windows 2000 had some function that returns 4ms accurate time,
> I hope it is implemented like CLOCK_REALTIME_COARSE.

I think it wouldn't be prudent to explore Windows options until we prove the windows currTime is slow like the Linux version.

On Mac, gettimeofday is used. I don't know that it's necessarily slow, but I don't know of a better way to get the wall clock time.

-Steve

On Wednesday, 1 October 2014 at 13:37:43 UTC, Dicebot wrote:
> On Wednesday, 1 October 2014 at 10:50:54 UTC, Kevin Lamonte wrote:
>> 2. We have Tid in the API.  What about Fiber and Thread?  If we can only pick one, I would vote for Thread rather than Tid, as Tid's currently have no way to be uniquely identified in a logging message.  Reference: https://issues.dlang.org/show_bug.cgi?id=6989
>
> In my opinion only solution that scales is to provide same ID as one used by std.concurrency - it can be thread, fiber, process or pretty much anything. There are many possible threading abstractions and all can't be easily supported, makes sense to stick to one considered standard.

Long-term this sounds very reasonable.  But the problem at the moment is that std.concurrency provides nothing that can be used to distinguish threads in a log file.  Tid cannot be converted to a unique string or vice versa, nor can one Tid.join() to ensure that a child Thread has completed before closing the log file(s) and exiting main().  For boring end-user applications Threads are today's most common denominator.

Would PR https://github.com/D-Programming-Language/phobos/pull/1910 provide a way given a Tid to determine: a) What underlying concurrency model it is using (Thread, Fiber, process, future)? b) Uniquely identify that structure (Thread ID string, Fiber address string, process ID, something else)?  c) Be capable of using that identifying immutable (because it needs to be send()able to another Tid writing to network/file/etc) string-representable thing to find the original Tid again?  A+B is necessary for using std.logger to debug concurrent applications, C is a very nice-to-have that comes up periodically.

On Wednesday, 1 October 2014 at 16:10:41 UTC, Steven Schveighoffer wrote:
> I think it wouldn't be prudent to explore Windows options until we prove the windows currTime is slow like the Linux version.
>
> On Mac, gettimeofday is used. I don't know that it's necessarily slow, but I don't know of a better way to get the wall clock time.

x86 has a builtin time stamp counter, executes faster than the fastest system call.

http://en.wikipedia.org/wiki/Time_Stamp_Counter

http://en.wikipedia.org/wiki/High_Precision_Event_Timer