-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log immediately to file #176
Comments
@mb720 Thanks for opening the issue! I see how this can be inconvenient. I believe one of the solutions to this problem is to use hFlush after logging something. This sounds like a good thing to do by default, so we'll make sure this change will be included in the next withLogTextFile :: forall m r . MonadIO m => FilePath -> (LogAction m T.Text -> IO r) -> IO r
withLogTextFile path action = withFile path AppendMode $ action . logTextFlushHandle
where
logTextFlushHandle :: Handle -> LogAction m T.Text
logTextFlushHandle handle = LogAction $ \msg -> liftIO $ do
TIO.hPutStrLn handle msg
hFlush handle |
Thanks a lot, this worked like a charm after adding these imports:
Yes, I agree that making this the default is a good idea! |
* [#176] Add an action to flush a handle Problem: during logging one often wants data to reach destination immediately, but logging actions provided out of the box do not flush handles they log to. Solution: we add a new action to `co-log-core`. This action does not _write_ anything, but flushes the handler. We call it `logFlush` for consistency with other `log*` actions. It can be used as `logPrintStderr <> logFlush stderr`. * fixup! [#191] Export showTime (#192) * [#176] Automatically flush file handles Problem: if we use builtin logging actions that log to files, you will often notice that your messages appear in files with delay due to buffering. File handles are usually block-buffered and do not flush on newlines. We find that behavior confusing to end users and think that it's better to flush file handles on each log action by default. Note that the same problem may occur with other handles (e. g. stderr) as well, but it's less likely because they normally have line buffering (but it's not guaranteed and is not always the case). Solution: first of all we checked performance overhead of additional `hFlush` call. For vanilla `putStrLn` it varies from "more than 4x" for short messages to negligible for long messages. On average we roughly assess it as 2x (that really depends on your use case). Based on that we make the following trade-off: 1. Actions that write to files now also automatically flush output buffers using `logFlush`. That's more expensive, but without flushing behavior is quite confusing for the library users. 2. Actions that write to an arbitrary `Handle` or standard handles do not flush by default to avoid overhead. Usually flushing will happen automatically because of line bufferring. * [#176] Clarify lack of flushing in default actions * fixup! [#176] Automatically flush file handles
Hi!
Based on the tutorial code here and here, I'm attempting to log to a file in my app.
I'm currently facing the issue that I can't get co-log to log to the file while the program is running. The log message ends up in the file only after the program is finished.
Here's my code:
The log message is printed to standard out right away but only shows up in the log file at the end of the program (after the five seconds delay).
As you might have guessed from the
Env
, I'd like to useco-log
for a web server where it's important to have logs during the web server's execution.I was wondering if there's some way to configure the log action to log to the file immediately.
Thanks a lot! :-)
My Stack resolver is lts-14.16.
The text was updated successfully, but these errors were encountered: