On Monday, 14 July 2014 at 18:59:45 UTC, MrSmith wrote:
>>
>> 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

fixed

On Monday, 14 July 2014 at 20:45:29 UTC, Jeremy Powers via Digitalmars-d wrote:
> 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.

Will you then be able to get fully inlined low overhead ringbuffer logging throughout the application and used frameworks? E.g. do low level logging to a ringbuffer that is only saved/mailed upon fatal crashes. This is useful for online services.

>> +1 for not having the conditional log
>
> Not so sure about that. -- Andrei

I agree that the conditional could be useful. But I think that the current API definition where we already have some strange letter combinations ('l', 'c', 'f') is an one-way street, that throws away some good possibilities to extend it later. Should we keep adding cryptic letters? That is the reason why I think it is better to let out the conditional log for now.

errorIf - looks D-like
errorc  - is at most C-like

The argument that writef/-ln also contain some cryptic letters have historical reasons and should not motivate us to add some more.

On Tuesday, 15 July 2014 at 07:31:39 UTC, Dragos Carp wrote:
>>> +1 for not having the conditional log
>>
>> Not so sure about that. -- Andrei
>
> I agree that the conditional could be useful. But I think that the current API definition where we already have some strange letter combinations ('l', 'c', 'f') is an one-way street, that throws away some good possibilities to extend it later. Should we keep adding cryptic letters? That is the reason why I think it is better to let out the conditional log for now.
>
> errorIf - looks D-like
> errorc  - is at most C-like
>
> The argument that writef/-ln also contain some cryptic letters have historical reasons and should not motivate us to add some more.

I wouldn't call them cryptic, they are in fact very easy.

l = LogLevel
c = conditional
f = printf

what is so difficult about them. Sure errorIf looks easier, but what
about errorLogLevelIfPrintfFormat in comparison to errorlcf

On Tuesday, 15 July 2014 at 03:22:46 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 14 July 2014 at 20:45:29 UTC, Jeremy Powers via Digitalmars-d wrote:
>> 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.
>
> Will you then be able to get fully inlined low overhead ringbuffer logging throughout the application and used frameworks? E.g. do low level logging to a ringbuffer that is only saved/mailed upon fatal crashes. This is useful for online services.

Yes, apart from the inlined part, I'm not sure what the compiler does with virtual functions.

I would you can do that in <=15 lines of code

What does 'errorlcf' mean?

You specify log level 'error' and then you specify another log level ('l):
which log level wins?

The order of these modifier letters has to be 'lcf', not 'cfl', ...?

On Tuesday, 15 July 2014 at 08:01:12 UTC, Robert burner Schadek wrote:
> I wouldn't call them cryptic, they are in fact very easy.
>
> l = LogLevel
> c = conditional
> f = printf
>
> what is so difficult about them. Sure errorIf looks easier, but what
> about errorLogLevelIfPrintfFormat in comparison to errorlcf

On Tuesday, 15 July 2014 at 10:33:24 UTC, linkrope wrote:
> What does 'errorlcf' mean?
>
> You specify log level 'error' and then you specify another log level ('l):
> which log level wins?
>
> The order of these modifier letters has to be 'lcf', not 'cfl', ...?
>

good point one l to much its errorcf

now I feel stupid

>
> Will you then be able to get fully inlined low overhead ringbuffer logging
>> throughout the application and used frameworks? E.g. do low level logging to a ringbuffer that is only saved/mailed upon fatal crashes. This is useful for online services.
>>
>
> Yes, apart from the inlined part, I'm not sure what the compiler does with virtual functions.
>

But can you do it without modifying the user code?

Ideally, one could control how logging happens without having to change the code that requests the logging.  This is important for cases like when you have a library that uses logging, and you need to make it conform without digging into its guts.

I believe to do this with the current setup, you would need some standard 'dispatcher' logger, and have every user of logging use it.  Then could configure the dispatcher as needed for your case without modifying all the code to use a different logger.

Ideally this standard setup would be the default/recommended way to use the logging library - any thoughts on how to do this properly (and maybe get inlining/templating)?

On Tuesday, 15 July 2014 at 17:41:09 UTC, Jeremy Powers via Digitalmars-d wrote:
> I believe to do this with the current setup, you would need some standard
> 'dispatcher' logger, and have every user of logging use it.  Then could
> configure the dispatcher as needed for your case without modifying all the
> code to use a different logger.

If there is a standard dispatcher with calling conventions that all libraries use (e.g. logging.debug(), logging.info(), logging.error() etc) then I guess I could use textual search and replace to retrofit the standard API with my own inlined logger. Customization of the logging API or too many variations could make that difficult or impossible.

Virtual functions, locking etc should be avoided so that you can do very low overhead full logging on a live server that is under attack. Basically just writing some bytes to a set of thread local ring-buffers with timing information, then collect and merge them on a crash for analysis so you can get the gory details that lead to the crash and do emergency patching asap.

On Tuesday, 15 July 2014 at 17:41:09 UTC, Jeremy Powers via Digitalmars-d wrote:
>>
>> Will you then be able to get fully inlined low overhead ringbuffer logging
>>> throughout the application and used frameworks? E.g. do low level logging
>>> to a ringbuffer that is only saved/mailed upon fatal crashes. This is
>>> useful for online services.
>>>
>>
>> Yes, apart from the inlined part, I'm not sure what the compiler does with
>> virtual functions.
>>
>
> But can you do it without modifying the user code?
>
> Ideally, one could control how logging happens without having to change the
> code that requests the logging.  This is important for cases like when you
> have a library that uses logging, and you need to make it conform without
> digging into its guts.

If the user uses the defaultLogger it is trivial. Otherwise if you get the logger by calling a factory function you maintain. It is also trival.

>
> I believe to do this with the current setup, you would need some standard
> 'dispatcher' logger, and have every user of logging use it.  Then could
> configure the dispatcher as needed for your case without modifying all the
> code to use a different logger.

Sounds like a MultiLogger as defaultLogger
>
> Ideally this standard setup would be the default/recommended way to use the
> logging library - any thoughts on how to do this properly (and maybe get
> inlining/templating)?

I think the default way depends on your use case. If it is forced its properly to flexible enough