On Tuesday, 28 October 2014 at 01:37:48 UTC, Martin Nowak wrote:
> On 10/28/2014 12:58 AM, Robert burner Schadek wrote:
>>
>> Disabling a version at CT of the lib has no consequence to compile units
>> that are not compiled with that version statement.
>
> Yes setting a version in my app has no effect on the library, that's the problem because I cannot disable logging in a library.
> So I'll always have to pay some runtime overhead even though I don't want to use logging.

Actually, that is only true for LogLevel given to a log call at runtime. calls to info, trace etc. are guarded with static if. So you're not paying any runtime overhead when calling log functions with LogLevel build in their name.

On Tuesday, 28 October 2014 at 01:42:12 UTC, Martin Nowak wrote:
> On 10/28/2014 01:01 AM, Robert burner Schadek wrote:
>> is different from the code that has been in the PR for quite some time.
>> And the code you show does exactly what you say and the current code
>> does something different.
>
> No it behaves the same.
>
> isLoggingActive is a template in phobos
>
> doSome is a function in a lib that performs logging and instantiates isLoggingActive
>
> main is a function in the app that performs logging and instantiates isLoggingActive and also calls doSome
>
> Now which of those functions actually logs depends on the compilation settings of the library, the compilation settings of the app and the logger that's being used.

The second two are wanted and disabling a LogLevel at CT of phobos should be banned anyway. But no the less, it is one more option the user has to manipulate the Logger.

On Tuesday, 28 October 2014 at 08:38:50 UTC, Robert burner
Schadek wrote:
> Actually, that is only true for LogLevel given to a log call at runtime. calls to info, trace etc. are guarded with static if.
> So you're not paying any runtime overhead when calling log functions with LogLevel build in their name.

If I cannot change the version identifiers that a library was
compiled with then the static if is always true. So you have to
perform the check at runtime. The only way around that is to make
each library function that performs logging a template, be it by
passing a Logger with CT LogLevel or by turning functions into
template functions so that the version identifiers leak into the
library.
The latter is more fragile because the compiler might omit
instatiating a template or it might inline a function.

On Tuesday, 28 October 2014 at 05:44:48 UTC, Andrei Alexandrescu wrote:
> Being able to select maximum logging level statically at client application level is a deal maker/breaker for me. The mechanics aren't important but it's likely they will affect the API. So I think that needs to be resolved now, not in a future pull request.
>
> Andrei

please elaborate. It is a must to be able to disable LogLevel when calling the compiler? Xor the opposite?

passing -version=StdLoggerDisableTrace when compiling the user code will yield empty functions (thank you static if) for every call to any function or method having the word "trace" in its name, like for example trace("My log call");

If you call something like log(computeMyLogLevelAtRuntime(), "my log data)
and that function returns LogLevel.trace and you haved passed -version=StdLoggerDisableTrace at CT of the user code you will have to pay for one if.

On Tuesday, 28 October 2014 at 09:39:24 UTC, Martin Nowak wrote:
> On Tuesday, 28 October 2014 at 08:38:50 UTC, Robert burner
> Schadek wrote:
>> Actually, that is only true for LogLevel given to a log call at runtime. calls to info, trace etc. are guarded with static if.
>> So you're not paying any runtime overhead when calling log functions with LogLevel build in their name.
>
> If I cannot change the version identifiers that a library was
> compiled with then the static if is always true. So you have to
> perform the check at runtime. The only way around that is to make
> each library function that performs logging a template, be it by
> passing a Logger with CT LogLevel or by turning functions into
> template functions so that the version identifiers leak into the
> library.

every log call is a template function or method already.

> The latter is more fragile because the compiler might omit
> instatiating a template or it might inline a function.

omitting the instantiation sound like undefined reference.
I don't see the problem with inlining. 1. there are no log functions only log templates. 2. The version statement will either leave empty template functions bodies, if(false) { ... } template functions bodies, or template function bodies that perform regular LogLevel checks on runtime LogLevel.

We're running in circles here. Lets find a new solution that allows us to
* dmd -version=StdLoggerDisableLogLevel -- disable a LogLevel at CT of user code
* that does not require a static Logger LogLevel
* does not leak version statements into phobos
* does not call log template functions where the LogLevel of the version statement is part of the name, or at least yields empty bodies for these template functions callls

On Tuesday, 28 October 2014 at 10:05:47 UTC, Robert burner Schadek wrote:
> On Tuesday, 28 October 2014 at 09:39:24 UTC, Martin Nowak wrote:
>> On Tuesday, 28 October 2014 at 08:38:50 UTC, Robert burner
>> Schadek wrote:
>>> Actually, that is only true for LogLevel given to a log call at runtime. calls to info, trace etc. are guarded with static if.
>>> So you're not paying any runtime overhead when calling log functions with LogLevel build in their name.
>>
>> If I cannot change the version identifiers that a library was
>> compiled with then the static if is always true. So you have to
>> perform the check at runtime. The only way around that is to make
>> each library function that performs logging a template, be it by
>> passing a Logger with CT LogLevel or by turning functions into
>> template functions so that the version identifiers leak into the
>> library.
>
> every log call is a template function or method already.
>
>> The latter is more fragile because the compiler might omit
>> instatiating a template or it might inline a function.
>
> omitting the instantiation sound like undefined reference.
> I don't see the problem with inlining. 1. there are no log functions only log templates. 2. The version statement will either leave empty template functions bodies, if(false) { ... } template functions bodies, or template function bodies that perform regular LogLevel checks on runtime LogLevel.
>
> We're running in circles here. Lets find a new solution that allows us to
> * dmd -version=StdLoggerDisableLogLevel -- disable a LogLevel at CT of user code
> * that does not require a static Logger LogLevel
> * does not leak version statements into phobos
> * does not call log template functions where the LogLevel of the version statement is part of the name, or at least yields empty bodies for these template functions callls

Yep, let's try that.

I think part of the misunderstanding is that I'm thinking of an app as user code plus a number of libraries all on top of phobos. Say I have an app using vibe.d and I want to enable logging in my app, but disable it in phobos.
Was it even a design goal that logging can be enabled on a per library level?

On Tuesday, 28 October 2014 at 09:00:54 UTC, Robert burner Schadek wrote:
> The second two are wanted and disabling a LogLevel at CT of phobos should be banned anyway. But no the less, it is one more option the user has to manipulate the Logger.

And this is where the leakage happens because there is no sharp border between app and library. Functions of the library may get unlined into the app, templates of the library are instantiated in the app and some instantiations that are already in the lib won't be reinstantiated in the app.

On Tuesday, 28 October 2014 at 11:11:09 UTC, Martin Nowak wrote:
>
> Yep, let's try that.
>
> I think part of the misunderstanding is that I'm thinking of an app as user code plus a number of libraries all on top of phobos. Say I have an app using vibe.d and I want to enable logging in my app, but disable it in phobos.
> Was it even a design goal that logging can be enabled on a per library level?

It is a design goal to disable certain LogLevel at CT of a compile unit (CU).
e.g. make all logs to trace function template do nothing

On 10/27/14 5:03 AM, Dicebot wrote:
> On Monday, 27 October 2014 at 08:23:48 UTC, Robert burner Schadek wrote:
>> On Monday, 27 October 2014 at 07:03:11 UTC, Dicebot wrote:
>>>
>>> I don't consider it a major issue as I don't think std.logger should
>>> be used inside Phobos at all.
>>
>> Yes, using std.logger inside of phobos is a no-no
>
> Ayway, let's come with an agreement/compromise with Martin and I'll
> start voting immediately after.

Agreed. Just to restate my position: so long as we don't have a way to statically control maximum logging level in the client, we don't have a logging library. There is no negotiation. -- Andrei

On Tuesday, 28 October 2014 at 16:05:19 UTC, Andrei Alexandrescu wrote:
> Agreed. Just to restate my position: so long as we don't have a way to statically control maximum logging level in the client, we don't have a logging library. There is no negotiation. -- Andrei

We have way to statically control logging level of the client from the client. Argument is mostly about precompiled 3d party libraries.