On Friday, 18 October 2013 at 15:29:09 UTC, ilya-stromberg wrote:
> About syntax - we can use something like this:
> log!(user, server, errorCode)(LOGIN_FAILED_UUID, "Couldn't log in");

That will be template instance bloat disaster for something used as commonly as log function (comparing to a typical few dozen `render` calls per web application at most)

On Friday, 18 October 2013 at 16:01:30 UTC, Dicebot wrote:
> On Friday, 18 October 2013 at 15:29:09 UTC, ilya-stromberg wrote:
>> About syntax - we can use something like this:
>> log!(user, server, errorCode)(LOGIN_FAILED_UUID, "Couldn't log in");
>
> That will be template instance bloat disaster for something used as commonly as log function (comparing to a typical few dozen `render` calls per web application at most)

Yes, you are right. I forgot about this.

Also, Tango have log module:
https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/util/log/Log.d

For example, "Funkwerk IT Karlsfeld" use it because Phobos haven't got logger:
http://dconf.org/talks/rohe.html

On 10/20/2013 08:52 AM, ilya-stromberg wrote:
> Also, Tango have log module: https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/util/log/Log.d
I looked through the source and IMO the tango logger is my logger + ( configuration and more default logger) or the other way round. And this thread had that discussion.

On Sunday, 20 October 2013 at 10:56:44 UTC, Robert Schadek wrote:
> On 10/20/2013 08:52 AM, ilya-stromberg wrote:
>> Also, Tango have log module:
>> https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/util/log/Log.d
> I looked through the source and IMO the tango logger is my logger + (
> configuration and more default logger) or the other way round. And this
> thread had that discussion.

I just put attention on it.
Link to the documentation:
http://siegelord.github.io/Tango-D2/

On Wednesday, 16 October 2013 at 07:18:39 UTC, ilya-stromberg wrote:
>
> Disagree. We need a log rotation support.
> As I can see, available options could be:
>
> * rotating conditions
>  - by date (rotate every hour, day (default), week, month, year)
>  - by file size (rotate if file size more than ... Mb)
>  - by count log lines (rotate if log contains more than ... log lines)
>  - combination of previous conditions (for example, rotate every day or rotate if file size more than 100 Mb)
>
> * file names after rotation
>  - by numbers (my.log, my.log.0, my.log.1, ...)
>  - by ISO date and time (my-2013-10-16-00-00-00.log)
>
> * ability to use system log rotation utility

I really like that Boost::Log also provides an option to replace old log files (instead of creating new ones) when disk capacity reaches a certain threshold.  It might also be worth providing an option to simply limit the max log file count to N, which then replaces oldest first.  In some unexpected situations I've seen the disk fill from a badly behaved program, and these are a nice safeguard.

On Sunday, 20 October 2013 at 15:34:50 UTC, Sean Kelly wrote:
> On Wednesday, 16 October 2013 at 07:18:39 UTC, ilya-stromberg wrote:
>>
>> Disagree. We need a log rotation support.
>> As I can see, available options could be:
>>
>> * rotating conditions
>> - by date (rotate every hour, day (default), week, month, year)
>> - by file size (rotate if file size more than ... Mb)
>> - by count log lines (rotate if log contains more than ... log lines)
>> - combination of previous conditions (for example, rotate every day or rotate if file size more than 100 Mb)
>>
>> * file names after rotation
>> - by numbers (my.log, my.log.0, my.log.1, ...)
>> - by ISO date and time (my-2013-10-16-00-00-00.log)
>>
>> * ability to use system log rotation utility
>
> I really like that Boost::Log also provides an option to replace old log files (instead of creating new ones) when disk capacity reaches a certain threshold.  It might also be worth providing an option to simply limit the max log file count to N, which then replaces oldest first.  In some unexpected situations I've seen the disk fill from a badly behaved program, and these are a nice safeguard.

+1
* delete old files when:
 - you have more than N files
 - size of all log files more than ... Mb

* support compress rotated files (for examle, in zip or gzip format)

On Sunday, 20 October 2013 at 16:05:47 UTC, ilya-stromberg wrote:
> On Sunday, 20 October 2013 at 15:34:50 UTC, Sean Kelly wrote:
>> On Wednesday, 16 October 2013 at 07:18:39 UTC, ilya-stromberg wrote:
>>>
>>> Disagree. We need a log rotation support.
>>> As I can see, available options could be:
>>>
>>> * rotating conditions
>>> - by date (rotate every hour, day (default), week, month, year)
>>> - by file size (rotate if file size more than ... Mb)
>>> - by count log lines (rotate if log contains more than ... log lines)
>>> - combination of previous conditions (for example, rotate every day or rotate if file size more than 100 Mb)
>>>
>>> * file names after rotation
>>> - by numbers (my.log, my.log.0, my.log.1, ...)
>>> - by ISO date and time (my-2013-10-16-00-00-00.log)
>>>
>>> * ability to use system log rotation utility
>>
>> I really like that Boost::Log also provides an option to replace old log files (instead of creating new ones) when disk capacity reaches a certain threshold.  It might also be worth providing an option to simply limit the max log file count to N, which then replaces oldest first.  In some unexpected situations I've seen the disk fill from a badly behaved program, and these are a nice safeguard.
>
> +1
> * delete old files when:
>  - you have more than N files
>  - size of all log files more than ... Mb

Addition:
* delete old files afrer ... days (hours)

> * support compress rotated files (for examle, in zip or gzip format)

On Tuesday, 15 October 2013 at 08:47:00 UTC, Robert Schadek wrote:
> On 10/15/2013 09:32 AM, Sönke Ludwig wrote:
>> Am 15.10.2013 09:08, schrieb Jacob Carlborg:
>>> On 2013-10-14 23:22, Dicebot wrote:
>>>
>>>> If we need to care about that, D module system is a failure.
>>>> But I don't think it is a valid concern.
>>>
>>> People already complain about conflict function names in Phobos.
>>>
>>
>> And I'd agree with them. At least inside of a library, care IMO should
>> be taken to minimize overlap (of course functionally equivalent ones
>> in different overload sets are fine, though). But in case of "logXXX"
>> this seems to be very unlikely, much in contrast to "log" (std.math.log).
> yes and no. Of course does logXXX create less conflict, but I like to
> simply write log and don't care about the LogLevel. So again pros and cons

I for once have never seen any log API with
log.level = INFO;
Logger.log("Here be dragons");

And this I believe for a good reason: in 99% of production code I've seen, several log levels are mixed, i.e INFO, CRITICAL and DEBUG for instance, so the case where a single log level is used, even in the same method, just never happens. The proposed solution looks extremely inconvenient to me as it will almost always necessit two lines of code instead of one.

I am with Sönke on this one, as well as the need for multi logger output. That's the absolute minimum requirement. If this doesn't exist, what will happen is, someone will make something better.

On Monday, 14 October 2013 at 13:25:00 UTC, Robert Schadek wrote:
> On 10/14/2013 02:51 PM, Andrea Fontana wrote:
>> Just for comparison, on Android you can write something like:
>> FileLogger.w(...)  instead of FileLogger.log(LogLevel.Warning...)
>>
>> (and there's a "wtf" loglevel for "temporary" debugging)
>>
> hm, I don't really like it. To me it sounds like, "I'm don't care about
> log level just print this". Maybe changing the LogLevel type to an int
> like "debug(int) { " would be an idea and than providing some immutable
> int Info = 1, Debug = 256, Error = 1024 ...  would be a idea.

IMHO, Andrea's suggestion is still a million times better.
And in any case, logger.info(...) is much better than logger.log(Logger.INFO, ...), which is uselessly redundant and quite ugly.