std.log available for viewing

[Jose Armando Garcia]

Thanks. Comments below.

On Sun, May 29, 2011 at 12:44 PM, Andrei Alexandrescu
<SeeWebsiteForEmail at erdani.org> wrote:
> On 5/28/11 6:40 PM, Jose Armando Garcia wrote:
>>
>> The implementation and documentation for std.log is ready for viewing.
>> You can take a look at the doc at
>> http://jsancio.github.com/phobos/phobos/std_log.html. The source code
>> is at https://github.com/jsancio/phobos/blob/master/std/log.d.
>>
>> I had to make some changes to druntime to get the thread id. The
>> module will work without the changes but you wont to see thread ids in
>> your log messages. I will look into sending a pull request to
>> druntime, in the meantime you can apply the attached patch to your
>> druntime if you want to see thread ids in the log.
>>
>> Let me know if you have any comments or suggestions! Thanks,
>> -Jose
>
> 1. The fatal log should never be stripped. This is because execution of code
> after using fatal depends on compile-time flags, which is unacceptable.
> Logging to fatal should terminate the application regardless of
> circumstances. Otherwise people would need to write things like:
>
> fatal("blah");
> assert(0, "Execution cannot continue even though logging is stripped");
>
> This is needless and bug-prone. Fatal is fatal.
>
Makes sense - will change.

> 2. A critical log that (always) throws might encourage disciplined use of
> exceptions - and with good messages. BTW the log message should be present
> in the exception object too!
>
Makes sense - will change.

> 3. Why doesn't vlog take the __LINE__ too?
>
vlog simply filters based on the verbose level and the file by
comparing it to the --vmodule and --v flags. For this reason it only
need the level and the file name. Message formatting is done in
another method.

> 4. initLogging and initializeLogging are highly confusing names. Overload
> them to share the same name, or rename one.
>
Yeah. I don't like this either but if I remember correctly D/dmd
doesn't let me overload a function with a template. I'll look into
this again. Maybe I can figure out a way to make initLogging a
template and hence rename initializeLogging.

> 5. Time should be not expressed as long.
>
Are you referring to LogMessage.time? Do you see an issue with
internally (things not expose to the client/user) being expressed as
long?

> 6. The riches of XxxConfig types form a sudden swell difficult to justify.
> What is the justification of FilterConfig, VerboseConfig, and LoggerConfig?
> They don't even make sense as nouns or noun phrases. Anyhow, a simple
> approach to design would be: if you need to configure some already-created
> object you'd do so by calling methods of that object, and if you need to
> configure an object just before creating it, some factory pattern might be
> of use. Probably configuration after construction is the election approach
> for this case.
>
I can probably merge FilterConfig and VerboseConfig into one
configuration object. I want to keep that separate from LoggerConfig
because the things in LoggerConfig are specific to a logger/writer
that writes to disk hence only useful to a file writer. The
configuration of a logger/writer that records log message to a
database may/will look different.

Now, to answer why do they even exist at all is that originally I
wanted to only allow configuration at creation time. Now I am thinking
of allowing configuration even after message have been logged. If that
is the case then I can probably remove FilterConfig and VerboseConfig.

I'll look into this and get back to you with a concrete answer...

> 7. The design pushes formatting down to the dynamic interface. That might be
> the right thing but prevents the front end from configuring formatting, thus
> complicating matters for the user. The implementer is also aggravated
> because they need to implement formatting code themselves. (As far as I can
> tell, formatting is not formally offered by the design.) This latter issue
> could be solved by inserting a lower-level interface that only transports
> strings, and a stock implementation of a formatting object; but that
> complicates the design.
>
I definitively don't want to do formatting in the front end to allow
the recording of structured/semi-structured log messages. I now of at
least one large datacenter that stores semi-structured log message on
a distributed database. I'll look into presenting this formatting
issue in a nice way to the writer of the backend.

>
> Thanks,
>
> Andrei
>