Do respect existing loggers

[devmotion]

This PR addresses some of the issues raised by @c42f in #450 (comment). It changes the default logger to a TeeLogger such that existing user-defined loggers are respected and the progress logger only handles progress logs. Additionally, instead of checking if Juno is active, it just checks if the current logger can handle logs of log level -1 (which is the case for the JunoProgressLogger).

Moreover, for now I set ConsoleProgressMonitor as the default logger on Windows and for Jupyter notebooks (see @tkf's comment #450 (comment) and the discussion in JuliaLogging/TerminalLoggers.jl#25).

[tkf]

LGTM

[c42f]

Thanks! So what do we need to do upstream to be able to remove these workarounds eventually?

It seems there's actually quite a few pieces to this puzzle:

• Get the ProgressLogging.Progress type into Logging once we're satisfied that the design will last.
• Replace Logging.ConsoleLogger with something more like TerminalLogger which knows how to handle Progress
• Fix TerminalLogger so that the sticky messages are less terrible on windows (should be doable in the near term I hope Make sticky messages work better on windows JuliaLogging/TerminalLoggers.jl#28)

Backward compat is going to be hard though until Logging itself can be upgraded separately from Base.

Doing all of the above only solves an instance of the general problem though, which is that we might want loggers to ignore certain types of log records by default if they can't process them "sensibly". This feels like a problem of generalizing shouldlog semantics, but there are many options for exactly how to do this. It could be be done based on message type, level, or @tkf has even suggested id...

[ChrisRackauckas]

And TerminalLogger should include the message information.

[tkf]

@ChrisRackauckas Do you mean the tooltip in Juno?

[ChrisRackauckas]

Yeah, it should be printing things like dt, umax, etc. It looks like @devmotion got AdvancedMC to do it, but I'm not sure if that's using the same progress bar?

[tkf]

I guess the only cross-platform way to do this, for now, is to put it as a part of the progress bar name. We are tracking the issue at JuliaLogging/ProgressLogging.jl#23

[tkf]

@c42f

It could be be done based on message type, level,

We can't use the message type (e.g., Progress) in shouldlog, right?

or @tkf has even suggested id...

Well, that's just a part of brainstorming :)

I now think doing this with level type is the way to go, provided that we can have something like supportedby(level::LevelType, logger): JuliaLang/julia#33960 (comment)

[c42f]

We can't use the message type (e.g., Progress) in shouldlog, right?

Ah, you're right of course :-/ The early filtering is necessary for high performance (eventually...) but man it's turning out to be a design annoyance.

[devmotion]

It looks like @devmotion got AdvancedMC to do it, but I'm not sure if that's using the same progress bar?

Unfortunately not, that's why I opened JuliaLogging/ProgressLogging.jl#23.