Optional Progress

[mileslucas]

A somewhat common scenario for me while I'm writing package code is optional progress bars, for example

function f(...; progress=true)
	# if progress:
	@progress for ...
    end
end

I know there are a couple ways to accomplish this, one of the ways the Turing folks do it is by wrapping the with progress macro https://github.com/TuringLang/AbstractMCMC.jl/blob/master/src/logging.jl

To avoid code duplication/replication, would it make sense to offer a similar macro directly within ProgressLogging? e.g. @progressif bool_expr ...?

I realize an appropriate counterpoint would be that users can use logging filters and custom loggers to properly show the progress or not, but that is pretty inconvenient. I have some exploratory code that has nested progress bars and it would be infinitely easier to use a keyword argument to control the inner loop's progress bar than a full-blown custom logger.

If there is an easier/better way of accomplishing the same thing, I'd love to hear it, too, but if not, I think this is the right repo to put a solution.

[pfitzseb]

An added benefit of @progressif is that you can use it to work around any potential overhead introduced by the logging code, which isn't possible by changing/disabling the log handler.

[c42f]

Of course, I think the ideal solution to this is to improve the REPL logger config experience, and to do an iteration of performance tuning if there's any performance concerns ;-)

There's certainly a few things we could do to improve the REPL logger config UX. But I do think that having a convenient UX for filtering in the REPL is actually pretty tricky. The available tools for interactivity are pretty bad in a terminal, especially on windows.

But more fundamentally, the user likely cares about log messages arising from some context of a project they're editing right now, and not about other code in the system. Communicating this "project editing context" from the user's UI to the log filtering mechanism is the really tricky thing. (Or perhaps it's only tricky for weird users like myself who have a very loosely coupled development environment where the editor and REPL are started separately.) For a more IDE-like experience like the VSCode plugin, it would be much more simple to only display @info level messages from the files/modules which are currently being edited?