15. des. 2014 kl. 11:12 skrev Joakim Hove <[email protected]>: > > > 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. > > Certainly – that was also part of the reason the name OpmLog gave slightly > positive connotations.
I see that, but in my opinion placing it in namespace Opm is sufficient. > > 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, > > Why not – that is my ambition? At least in a production setting the simulator > will be run in queue system and all output must/will be redirected to a file. > By having multiple backends we can send messages many places, including > stdout with a common use pattern in the client code. My (maybe unrealistic > ??) hope is that the logging system is so good that Joe Developer will rather > sprinkle the code with a couple of “Log::addMessage()” instead “std::cout” > while debugging/developing. Having thought a little more about this now, I think I agree with you. If absolutely every output goes through the log system it will make it easier to customize output for particular uses/users. So consider my objection withdrawn. > > > Apart from disagreeing with the API proposed (let's not use new if we do not > have to) I support this. > > Sure. > > > > > 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. > > What I mean; (which might still be a bad idea ?) is : > > 1. The global log handler manages a set of log levels (i.e. Warning, > Error, Message, ….) dynamically. The default will of course be built in, but > it should be possible from clientcode to say something like: > > > size_t message_id = Log::addMessageType(); > … > … > Log::addMessage(message_id , “This message is tagged with the new message_id > tag”); > > 2. When a backend is instantiated it is instantiated with a mask of the > message types it accepts, i.e. > > ErrorBackend backend( Log.ERROR ); > MessageBackend backend( Log.ERROR || Log.MESSAGE || message_id ); // Will > include the new message type > > > Then we call Log::addMessage( message_type , “Message ….”) > > Each backend will make it’s own decision whether to include > the message. > > Point 2, i.e. that each backend does It’s own filtering decision I am quite > certain is a good idea, point 1 is maybe overengineering? I think the message_id tag is problematic, it increases the coupling between code parts (solver internals vs. the main function). It may be over-engineering things, yes. Each backend filtering messages is of course ok. Atgeirr _______________________________________________ Opm mailing list [email protected] http://www.opm-project.org/mailman/listinfo/opm
