>
> D unit of encapsulation is module. Any other "namespace" solutions must
>>> die after proper torture.
>>>
>>
>> Just use this in the next release!
>>
>> extern(C++, log)
>> {
>> extern(D):
>>   ... functions ...
>> }
>>
>
> Not helping :grumpy:
>

Is this where I talk about hierarchical logging?

There was some talk in the original review thread about having each log import create or tag the log with the module, so one could refer to and filter by modules.  In java land you get a logger instance per class, in a tree based on package hierarchy, and can then configure output levels differently for various places in the hierarchy - very useful (esp. with runtime configuration).

While discussing the proper way to namespace/import logger, can you make it such that doing so gives hierarchical logging?

On Monday, 14 July 2014 at 17:44:37 UTC, Jeremy Powers via Digitalmars-d wrote:
> Is this where I talk about hierarchical logging?
>
> There was some talk in the original review thread about having each log
> import create or tag the log with the module, so one could refer to and
> filter by modules.  In java land you get a logger instance per class, in a
> tree based on package hierarchy, and can then configure output levels
> differently for various places in the hierarchy - very useful (esp. with
> runtime configuration).
>
> While discussing the proper way to namespace/import logger, can you make it
> such that doing so gives hierarchical logging?

Replacing `import log = std.logger` with something like this:

```
import std.logger.modulelog;
auto log = new ModuleLogger;
```

should do the trick as far as I understand the current design - this assumes that module/package name filters are implemented as static ModuleLogger fields.

While trying to use logger i've found that this doesn't work. The execution stalls and thread is not executed, while eith writeln it works fine.

import std.logger;
import std.parallelism;

void worker()
{
	log("in worker");
}

void main()
{
	auto pool = taskPool;
	pool.put(task!worker);
}

On Monday, 14 July 2014 at 17:02:59 UTC, Jeremy Powers via Digitalmars-d wrote:
> The stated goal of this log library is to provide a base with common useful
> functionality, in a way that can be extended to fit more complicated use
> cases.  I'd argue that what you are talking about fits into the 'more
> complicated' - the log API should definitely allow this, in a way that it
> can be plugged in without log using code having to change, but I don't
> believe the functionality needs to be in the base library (at this time).

Getting things changed is more difficult than getting it right from the start. As far as I am concerned it is crucial in the sense that if it does not support severity levels and easy integration with existing logging services then I probably won't use it.

On 7/13/14, 9:02 AM, Dragos Carp wrote:
> This is a library: you can always add names, but it is very hard
> to remove them. If next version of std.logger should support
> something like logFirstN or logEveryN (ideas from Google log
> library). How this should look like? logfnf, logenf...?

There were some nice ideas about that in the previous proposal. -- Andrei

On Monday, 14 July 2014 at 18:12:44 UTC, MrSmith wrote:
> While trying to use logger i've found that this doesn't work. The execution stalls and thread is not executed, while eith writeln it works fine.
>
> import std.logger;
> import std.parallelism;
>
> void worker()
> {
> 	log("in worker");
> }
>
> void main()
> {
> 	auto pool = taskPool;
> 	pool.put(task!worker);
> }

can you make an issue out of it here https://github.com/burner/logger, so we
don't lose track

On 7/13/14, 11:45 AM, Dragos Carp wrote:
>> On the conditional log methods: +1 to not having them, I believe that
>> they
>> are more complicating than useful.
>
> +1 for not having the conditional log

Not so sure about that. -- Andrei

On Monday, 14 July 2014 at 18:54:35 UTC, Robert burner Schadek wrote:
> On Monday, 14 July 2014 at 18:12:44 UTC, MrSmith wrote:
>> While trying to use logger i've found that this doesn't work. The execution stalls and thread is not executed, while eith writeln it works fine.
>>
>> import std.logger;
>> import std.parallelism;
>>
>> void worker()
>> {
>> 	log("in worker");
>> }
>>
>> void main()
>> {
>> 	auto pool = taskPool;
>> 	pool.put(task!worker);
>> }
>
> can you make an issue out of it here https://github.com/burner/logger, so we
> don't lose track

Here it is https://github.com/burner/logger/issues/10

>
> Getting things changed is more difficult than getting it right from the start.


Very true.  The logging API needs to be right before it goes into std and has to be locked down.  But then, no API is ever right the first time, needs banging on to expose the weaknesses so they can be fixed.



> As far as I am concerned it is crucial in the sense that if it does not support severity levels and easy integration with existing logging services then I probably won't use it.
>

The logging API in the standard library needs to be able to support this kind of thing.  Doesn't mean it actually needs to be included in the base implementation.  I would recommend trying to see if you can implement what you want given the existing framework - and if not, yell so it can be changed.  What is missing from the existing stuff that keeps this from working as an extension?

On Monday, 14 July 2014 at 17:18:05 UTC, Jeremy Powers via Digitalmars-d wrote:
>
> We can argue about these things forever, but ultimately all that really
> matters is: does it do what we need?  As long as the API works, and lets
> one build fancier functionality underneath, it is good.  (Though, in my
> experience, any API written will be wrong the first try)
>
>
> That said, my bikeshed preferences are:
>  - namespaced log.info, log.warning, etc
>  - info(f) matching write(f)
>  - conditionals as an extension/wrapper, not part of base

My vote goes for:

- vibe.d names (logDebug/logInfo)
- info(f) matching write(f)
- conditionals as an extension/wrapper, not part of base