14. des. 2014 kl. 21:56 skrev Joakim Hove <[email protected]>: > Hello; > > earlier this autumn Andreas submitted a ParserLog class which has been used > in the Parser for some time. I would now like to promote this to a general > logging facility for OPM. I have thought quite a lot about it, but not > implemented much[1]. I will share my thoughts below, and hope you will > comment:
Thanks for starting this process, my thoughts are below. > > 1. The logging facility should be implemented as a singleton, i.e. it > should not be necessary to pass in a reference to a log class to all > methods/functions which might want to add a log message. I think this is a good idea, and in line with common usage of the singleton pattern. However, we should make a few things clear up front: 1a. This is not a universal logging facility in that we want to cover every possible use in any possible code, but tailored to what we need in OPM. In particular, we should make it clear that code run at static construction/destruction time can not use the logging facility (otherwise untangling this correctly is a lot of work, see Alexandrescu's book for example). Also, we must agree on correct (or at least a default) behaviour in an MPI setting. 1b. The logging facility should not be used for all communication with the user, only warnings/errors etc. I think that regular output should not be a part of this, even though that prompts more questions, for example should we write a file with all output (as if the user used foo | tee file) automatically. > 2. The logging facility should be based on thin frontend and a > collection of logging backends. That way we can have different backends > active at the same time: > > > auto streamBackend = new LogStreamBackend( stdout ); > auto emailBackend = new EmailBackend( … ); > > OpmLog::addBackend( streamBackend ); > OpmLog::addBackend( emailBackend ); > …. Apart from disagreeing with the API proposed (let's not use new if we do not have to) I support this. > > 3. The log levels, i.e. Warning, Error and so on should be dynamic; and > each backend should have it’s own loglevel. I do not quite understand what you mean by these being dynamic, and I do not think different backends should define their own. These levels are to be used in client code (simulators) where I can imagine such a thing as "Newton failure, report this at Warning level" is something the client would like to do. If the way to specify a Warning changes with the backend then there is no polymorphism here, so I fail to see how that could be done. Atgeirr _______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
