A Sparse Logger Wiki
Michael Betancourt
Bob Carpenter
https://github.com/stan-dev/stan/wiki/Consolidated-Output-for-Sample,-Optimize,-ADVI,-and-Diagnose
While the logger could wrap writers, I don't see the point.
I think it just needs something like:
logger.level() << msgs;
or
logger << LEVEL << msgs
if people think that's cleaner. I like the former, as we can
have logger.level() be a std::ostream so all our favorite I/O will
work.
If we need things like time stamps, process & thread IDs (two typical
things found in log messages), then those might be possible to include
implicitly by configuring logger properly (time stamp arises from
logger.level(), thread ID from environment, etc.)
So I really want to hear from Krzysztof what he was thinking in
terms of structure here, or what Jiqiang and Ben might be able to use
in RStan.
I think files vs. terminal vs. elsewhere is something we want to
abstract here. I'd think logging to file would be desirable for
multiple jobs running in parallel. Often loggers tee their output
and put one kind of message to file and other messages to console.
It's the usual way loggers work and if you want to follow
their streaming output, you do tail -f.
- Bob
> On Apr 26, 2016, at 4:20 PM, Michael Betancourt <betan...@gmail.com> wrote:
>
> Just to begin the conversation.
> https://github.com/stan-dev/stan/wiki/Logging-Spec
>
> You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
Krzysztof Sakrejda
> Just to begin the conversation.
> https://github.com/stan-dev/stan/wiki/Logging-Spec
My thoughts:
- interface_callback::writer should stay separate from a logger. It's a really straightforward interface and works well in the context of messages and other output.
- I don't think we need to decide whether a logger wraps interface_callbacks::writer. If I were implementing a logger for an interface I might do it that way but at the stan-dev/services level I don't know what would work best. One thing we get by assuming that the logger wraps interface_callbacks::writer is that we automatically know what kind of output can get sent to the logger and that should simplify defining the interface consistently at the services level.
- If we do wrap interface_callbacks::writer then logger::level() could just do its bit (add timestamp/etc...) and pass the arguments on to a writer.
- I like the function call format (if we wrap writers in the logger) because it makes it clear how they are being called. I don't have a strong opinion on it.
- If we want to (and I think we do) abstract out the "files vs. terminals vs. elsewhere" issue I think we should stick with wrapping interface_callbacks_writer since that interface already lets us abstract out the issue.
At the c++/CmdStan level it's easy to imagine constructing a logger from the usual stuff---filenames/streams/etc... to echo Bob's question, what do the other interfaces need to be able to send output to?