[LTB-37] log: Rustic logging for lazy people #22
Conversation
kirelagin
force-pushed
the
kirelagin/ltb37-rustic-log
branch
from
0df761e
to
c5b9226
Compare
kirelagin
changed the title
| -- | Down to earth logging for the lazy ones | ||
| -- | ||
| -- No configuration, just use functions from this module instead of @putStrLn@ | ||
| -- and they will do the rest. All messages above @Debug@ are printed to @stderr@. |
There was a problem hiding this comment.
I'd rather use global variable to control this behaviour. We can present a function setDebug :: IO () that enables debug output by enabling a parameter inside MVar. Is this approach any better?
There was a problem hiding this comment.
Well, I was thinking about it and I am not sure tbh. My view on this is that having a global variable no longer feels that dumb-simple and pure, while the only benefit it gives is a sort of dynamic configuration, e.g. with a command-line switch, and if you want this, it probably means that it’s time to switch to a proper logging implementation. This one is meant only for the simplest things, one-off scripts, etc.
There was a problem hiding this comment.
Compilation flags look scary to me -- of course, they are easy to configure, but I need to look up the exact way to do it. Instead, adding a line of hs code enabling debug output is straightforward. The user doesn't need to know how exactly it is implemented under the bonnet.
There was a problem hiding this comment.
I really think that for simplest things and one-off scripts it's not the compilation flag which should be used, but an environment variable. If you're quickly prototyping something, you really don't want to recompile the thing to enable some debug logs for the next run.
There was a problem hiding this comment.
CPP also looks scary to me, because I need to compile a library with -DDEBUG, not my application, AFAIU. Even if I am wrong, even the need to think about it doesn't sound good.
+1 to environment variable.
|
We need more opinions on this 🤔 |
kirelagin
requested review from
gromakovsky,
epicallan,
pva701,
artemohanjanyan and
kevroletin
|
@kirelagin this PR is actually very good, could we move forward? I still insist on adding the option to change parameters from the code directly, because I find both env var and compilation flag to be complex (first forces me to export some flag in every console I launch my program in, the second one is even more difficult). |
| what the `caps` framework is meant to do. The only thing `loot-log` has to do is provide | ||
| access to the configuration and then you will simply use `adjustCap`. | ||
| by any code called by a specific function? Hopefully, you’ll be able to do this | ||
| somehow, but this functionality is currently in the works. |
There was a problem hiding this comment.
How is it related to rustic logging?
Stupid logging backend compatible with the
loot-loginterface but not requiring anything except forMonadIO. Use it in your throw-away tools.