Thanks. Comments below. On Sun, May 29, 2011 at 12:44 PM, Andrei Alexandrescu <seewebsiteforem...@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 >