On Tuesday, 15 October 2013 at 14:09:36 UTC, ilya-stromberg wrote:
> I did not talk about additional external libraries. As I know, Vibe.d use OpenSSL to provide SSL streams. Since we haven't got encryption support in Phobos, we can provide only TCP streams.

For example, sending mail is clearly relying on external stuff and should never be in Phobos (again, std.net.curl was a terrible mistake)

On Tuesday, 15 October 2013 at 14:12:38 UTC, Sönke Ludwig wrote:
> Am 15.10.2013 15:52, schrieb Robert Schadek:
>> On 10/15/2013 03:21 PM, Sönke Ludwig wrote:
>>> Am 15.10.2013 10:41, schrieb Robert Schadek:
>>>> On 10/15/2013 02:44 AM, Kapps wrote:
>>>>> The simple act of logging a message is very verbose right now:
>>>>> log(LogLevel.trace, "Creating new pool") is a lot of boiler plate. I'd
>>>>> prefer something like log.trace("Creating new pool") and log("Creating
>>>>> new pool") where the latter would use opCall to forward to the default
>>>>> log level. If it's intentional that you can assign the result of log,
>>>>> this also helps that because log = new StdIOLogger would be possible
>>>>> (log being a property that returns a Logger, and so a setter could be
>>>>> made), but log("Creating new pool") = new StdIOLogger() would not be.
>>>> The LogLevel is optional. And always writing log.trace might become more
>>>> typing work and assigning a LogLevel and than calling log("..."). Both
>>>> have pros and cons
>>>
>>> What happens when a called function alters the default log level?
>> The default log level is altered.
>
> Believe it or not, for some reason I suspected as much.
>
>>>
>>> ---
>>> void func1() {
>>>     log.logLevel = LogLevel.debug;
>>>     log("This is a debug message");
>>>     func2();
>>>     log("This is supposed to be a debug message");
>>> }
>>>
>>> void func2() {
>>>     log.logLevel = LogLevel.warning;
>>>     log("This is a warning");
>>> }
>>> ---
>> If you don't specify a logger nor a LogLevel the currently set default
>> logger will log the message with its currently set LogLevel.
>
> Yes, but the point is that when looking only at func1, you might expect that all messages are logged as debug messages, but the last one will be logged as a warning instead. func2 may be hidden in library where the function body is not readily available.
>
>>>
>>>
>>> I don't think it's a good idea to use such kind of global state,
>>> especially for a logging framework that is supposed to be shared
>>> between libraries, so that it is difficult to predict what a
>>> particular function does. With a logger that is shared between
>>> threads, things get worse of course.
>> I think this is good, as it gives you a way to quite libraries down. The
>> idea behind the free standing "log" function is to provide an ultra easy
>> way to log. It is not meant to be used for the 2<<31 line program. In
>> that case you will properly have very specific needs on how to log.
>> Hence implement the abstract Logger class to your needs.
>
> But if it's available people _will_ use it in complex contexts. Also if the writer of a 2<<8 loc library uses it and the library is used by a large piece of software, that will also be affected. The point is that it is unhygienic and requires non-trivial extra work when using a logger in a multi-threaded environment. Some kind of scoped stack of default log levels would get around this issue, but that smells like over engineering.

+1
I dislike syntax:
log.logLevel = LogLevel.warning;
log("This is a warning");

Much better:
log.warning("This is a warning");

On 10/15/2013 04:12 PM, Sönke Ludwig wrote:
>
> Believe it or not, for some reason I suspected as much.
>
> Yes, but the point is that when looking only at func1, you might expect that all messages are logged as debug messages, but the last one will be logged as a warning instead. func2 may be hidden in library where the function body is not readily available.
Logging is the most unpure functionality I can think of. It is side effect heaven.
>
> But if it's available people _will_ use it in complex contexts. Also if the writer of a 2<<8 loc library uses it and the library is used by a large piece of software, that will also be affected. The point is that it is unhygienic and requires non-trivial extra work when using a logger in a multi-threaded environment. Some kind of scoped stack of default log levels would get around this issue, but that smells like over engineering.
>
>
> But these are two different concepts and it's hard for me to imagine why they should be conflated. But I guess it's time to stop complaining about the whole log("message") complex.
...

On Tuesday, 15 October 2013 at 14:13:53 UTC, Dicebot wrote:
> On Tuesday, 15 October 2013 at 14:09:36 UTC, ilya-stromberg wrote:
>> I did not talk about additional external libraries. As I know, Vibe.d use OpenSSL to provide SSL streams. Since we haven't got encryption support in Phobos, we can provide only TCP streams.
>
> For example, sending mail is clearly relying on external stuff and should never be in Phobos (again, std.net.curl was a terrible mistake)

I didn't know about it, sorry.

Am 15.10.2013 15:31, schrieb ilya-stromberg:
> On Tuesday, 15 October 2013 at 07:52:28 UTC, Robert Schadek wrote:
>> On 10/15/2013 04:06 AM, Eric Anderton wrote:
>>> On Monday, 14 October 2013 at 11:39:52 UTC, Dicebot wrote:
>>> Here's what I think is missing:
>>> - System log support (as others have mentioned).  This would be syslog
>>> or WEL, depending on environment.
>> This is sort of the idea of the design, I can't anticipate your needs
>> therefor I should not try. I should try to give you guidelines or a
>> framework to work against.
>
> Totally disagree. We need a powerful logger, not only file logger.
> I can implement a file logger myself for a few hours, and it will cover
> 90% of my needs. For other 10% I would like to have a standart logger
> with advanced features like speed and reliability.

In this case I do agree with Robert that it will be better to keep the std.log module basic and as dependency free as possible. The main advantage of it is to enhance interoperability of different libraries that use logging, but any advanced features can be implemented by external libraries just as well (at least at the beginning). But of course the general design allow for all complex use cases. And then over time it may well show that it makes sense to include more standard loggers. /IMHO

>
> If you need help, please tell us. For example, jkm already implemented
> syslog for Vibe.d with support files (via file streams) and the network
> (via TCP or SSL streams):
> https://github.com/rejectedsoftware/vibe.d/pull/294
> It's under the MIT license, that similar to the Boost license.
>
> Sönke Ludwig, can you allow to use syslog code for `std.logger` under
> the Boost license? Robert Schadek can use it as initial point.

Should this be needed, it would be absolutely no problem. MIT -> Boost works automatically and I would also happily transfer the code ownership if needed.

On Tuesday, 15 October 2013 at 14:20:15 UTC, Robert Schadek wrote:
> On 10/15/2013 04:12 PM, Sönke Ludwig wrote:
>>
>> Believe it or not, for some reason I suspected as much.
>>
>> Yes, but the point is that when looking only at func1, you might
>> expect that all messages are logged as debug messages, but the last
>> one will be logged as a warning instead. func2 may be hidden in
>> library where the function body is not readily available.
> Logging is the most unpure functionality I can think of. It is side
> effect heaven.

Yes, but we should minimise possible side effects.

On 10/15/2013 04:17 PM, ilya-stromberg wrote:
> On Tuesday, 15 October 2013 at 14:12:38 UTC, Sönke Ludwig wrote:
>> But if it's available people _will_ use it in complex contexts. Also if the writer of a 2<<8 loc library uses it and the library is used by a large piece of software, that will also be affected. The point is that it is unhygienic and requires non-trivial extra work when using a logger in a multi-threaded environment. Some kind of scoped stack of default log levels would get around this issue, but that smells like over engineering.
>
> +1
> I dislike syntax:
> log.logLevel = LogLevel.warning;
> log("This is a warning");
>
> Much better:
> log.warning("This is a warning");
You can also write log(LogLevel.warning, "This is a warning"); And that
also allows you to treat the LogLevel as a variable.
log(myComputedLogLevel, "..."); Anyway, functions should be verbs.

On 10/15/2013 04:23 PM, ilya-stromberg wrote:
> On Tuesday, 15 October 2013 at 14:20:15 UTC, Robert Schadek wrote:
>> Logging is the most unpure functionality I can think of. It is side effect heaven.
>
> Yes, but we should minimise possible side effects.
Of course, but having global state aka. a global default logger and no side effect are opposing design goals.

Am 15.10.2013 16:33, schrieb Robert Schadek:
> On 10/15/2013 04:23 PM, ilya-stromberg wrote:
>> On Tuesday, 15 October 2013 at 14:20:15 UTC, Robert Schadek wrote:
>>> Logging is the most unpure functionality I can think of. It is side
>>> effect heaven.
>>
>> Yes, but we should minimise possible side effects.
> Of course, but having global state aka. a global default logger and no
> side effect are opposing design goals.
>

"minimise" != "eliminate"

The global default logger will usually be a set-once thing, so it's far less problematic.

On Tuesday, 15 October 2013 at 14:25:55 UTC, Robert Schadek wrote:
> On 10/15/2013 04:17 PM, ilya-stromberg wrote:
>> On Tuesday, 15 October 2013 at 14:12:38 UTC, Sönke Ludwig wrote:
>>> But if it's available people _will_ use it in complex contexts. Also
>>> if the writer of a 2<<8 loc library uses it and the library is used
>>> by a large piece of software, that will also be affected. The point
>>> is that it is unhygienic and requires non-trivial extra work when
>>> using a logger in a multi-threaded environment. Some kind of scoped
>>> stack of default log levels would get around this issue, but that
>>> smells like over engineering.
>>
>> +1
>> I dislike syntax:
>> log.logLevel = LogLevel.warning;
>> log("This is a warning");
>>
>> Much better:
>> log.warning("This is a warning");
> You can also write log(LogLevel.warning, "This is a warning"); And that
> also allows you to treat the LogLevel as a variable.
> log(myComputedLogLevel, "..."); Anyway, functions should be verbs.

Yes, I know.
Idea: let all "as is" and just add `log.xxx("...");` functions. It looks like that solves all problems:
- we can log with configurable default log level (setup for all programm):
log("This is a warning");
- we can specify local log level (setup for class or function):
log(myComputedLogLevel, "...");
- and we can call log with specific log level:
log.warning("...");
or maybe
log.logWarning("..."); //yes, it is a verb