kazu-yamamoto / logger Goto Github PK

it might be reasonable to change the Nothing case of newLoggerSet to use stderr, because it's arguable more correct anyway.

what do you think?

edit: it's a bug in fast-logger

How do I add MonadLogger to my transformer stack?

data CraftDSL next
  = Exec  CraftEnv Command Args (Bool -> next)
  | FileRead CraftEnv FilePath (String -> next)
  | FileWrite CraftEnv FilePath String next
  deriving Functor


newtype Craft a = Craft { unCraft :: ReaderT CraftEnv (FreeT CraftDSL IO) a }
  deriving ( Functor, Monad, MonadIO, Applicative
           , MonadReader CraftEnv, MonadFree CraftDSL, MonadThrow)

I was able to add MonadThrow without issue; I was hoping adding MonadLogger would be just as easy.

I tried adding it and I get this error:

    No instance for (MonadLogger (FreeT CraftDSL IO))
      arising from the 'deriving' clause of a data type declaration

If I define an instance:

instance MonadLogger (FreeT CraftDSL IO) where
  monadLoggerLog a b c d = Trans.lift $ monadLoggerLog a b c d

I get this error:

    Could not deduce (MonadLogger IO)
      arising from a use of ‘monadLoggerLog’

Any ideas? Sorry, if this is not an appropriate place to ask this.

Hi.
I have found that the behavior of fast-logger had changed unexpectedly (for me) at version 2.2.0.

When execute below code, at 2.1.5, "log 1", "log 2", "log 3" and "log 4" are displayed.
However, at 2.2.0, only "log 1" is displayed and "log 2", "log3" and "log 4" are not displayed even if flush function is called explicitly.
Is it expected change of specification ?

import qualified System.Log.FastLogger as Log

main :: IO ()
main = do
    logger <- Log.newStdoutLoggerSet 4096
    Log.pushLogStr logger "log 1\n"
    Log.pushLogStr logger "log 2\n"
    Log.pushLogStr logger "log 3\n"
    Log.pushLogStr logger "log 4\n"
    Log.flushLogStr logger

My environment is haskell-platform-2014.2.0.0 for windows.

Hi,

When trying to compile with the head of GHC 8.0.1 (GHC-8.0 branch, version 8.0.1.20160919), I get a series of errors like this:

Control\Monad\Logger.hs:249:10: error:
* Couldn't match type 'm' with 'IdentityT m'
'm' is a rigid type variable bound by
the instance declaration at Control\Monad\Logger.hs:249:10
Expected type: IdentityT
m (Loc -> LogSource -> LogLevel -> LogStr -> IO ())
Actual type: IdentityT
(IdentityT m) (Loc -> LogSource -> LogLevel -> LogStr -> IO ())
* In the expression:
Control.Monad.Logger.$dmaskLoggerIO @IdentityT m
In an equation for 'askLoggerIO':
askLoggerIO = Control.Monad.Logger.$dmaskLoggerIO @IdentityT m
In the instance declaration for 'MonadLoggerIO (IdentityT m)'
* Relevant bindings include
askLoggerIO :: IdentityT
m (Loc -> LogSource -> LogLevel -> LogStr -> IO ())
(bound at Control\Monad\Logger.hs:249:10)

I am guessing this is related to the following patch in GHC:
http://git.haskell.org/ghc.git/commit/54b887b5abf6ee723c6ac6aaa2d2f4c14cf74060
(We were able to compile with GHC 8.0.1.20160901)

Full log is attached

I don't know that this is something which needs by GHC or here, but I wanted to record it for now.

Thanks,

EDIT: Further reading:
https://ghc.haskell.org/trac/ghc/ticket/12220
https://ghc.haskell.org/trac/ghc/ticket/12466

It looks like this isn't going to make it into 8.0.2, so I guess this is all irrelevant

fast-logger fails to build on ghcjs built with ghc 8. Might be a ghcjs problem, not sure:

    /tmp/stack26927/fast-logger-2.4.6/System/Log/FastLogger/File.hs:6:1: error:
        System.Directory: Can't be safely imported!
        The module itself isn't safe.

Tried with nightly-2016-07-17 snapshot. Please advice if we can remove the safe pragma or should we better reach out the ghcjs issue tracker. Thanks!

Hello,

Just want to check if it is possible for the logs to be rotated while live?

----------------------------------------
-- my usage of fast-logger
---------------------------------------
--   1 MiB = 1 mebibyte = 1,0242 bytes = 1,048,576 bytes
--   100 MiB = 1,048,576 * 100 bytes
logger :: Text -> TChan Text -> IO ()
logger logPrefix chan =
  do filename <- logFilename logPrefix
     let fileLogSpec =
           FileLogSpec (cs filename)
                       104857600
                       10
     withFastLogger (LogFile fileLogSpec 1048576)
                    (readAndLog fileLogSpec chan)

readAndLog
  :: FileLogSpec -> TChan Text -> (LogStr -> IO a) -> IO ()
readAndLog fileLogSpec chan f =
  atomically (readTChan chan) >>= f . (toLogStr :: Text -> LogStr) >>
  readAndLog fileLogSpec chan f
--------------------------------------------------

-- not sure how to use this. If I use it in readAndLog, it gives this
-- message
-- exe: /tmp/<filename.log>: openFile: resource busy (file is locked)
checkAndRotate :: FileLogSpec -> IO ()
checkAndRotate spec =
  do size <- getFileSize (log_file spec)
     when (size > log_file_size spec)
          (rotate spec)

getFileSize
  :: BasicPrelude.FilePath -> IO Integer
getFileSize path = withFile path ReadMode hFileSize

I have a log running process and it would be nice if fast-logger can auto-rotate the logs on reaching a certain size. The log filehandle is locked by fast-logger and I cannot read the size of the log file while fast-logger is running.

Thanks

The ghc 6.10.4 build fails as follows:

Preprocessing library fast-logger-0.0.2...
Building fast-logger-0.0.2...
ghc: unrecognised flags: -fno-warn-unused-do-bind
Usage: For basic information, try the `--help' option.
builder for `/nix/store/i044l63b5sljz9dxwyi0fcca7m42hyz9-haskell-fast-logger-ghc6.10.4-0.0.2.drv' failed with exit code 1

It's a shame that the package cannot be built because of an unsupported warning flag, i.e. a flag that is purely cosmetic in nature and doesn't influence the actual library code at all.

Would it maybe be possible to set that flag only for GHC versions that actually support it?

In our app we use a thread pool created with parallel-io to execute some tasks. Also we use fast-logger to log their execution. And we were surprised seeing "job XYZ finished" appearing in log files before "job XYZ started". It appears fast-logger doesn't deal correctly with threads migrating between Haskell capabilities (pustLogStr uses threadCapability when choosing buffer).
As a workaround I've forked parallel-io to support pools with bound threads - qrilka/parallel-io@19a9b18
But probably that's some known issue with fast-logger and there is some better way around this?

If I understand the description correctly, bytestring-builder should not be necessary on ghc 7.8. The package is supposed to be smart enough to be empty on those versions, but it would be nice if the packages here could be configured in such a way as to not require them it at all.

This is more of a question, than a real issue.

Would it not make more sense to define a general interface (class, types, etc.) using monad-logger, and then in turn have fast-logger depend on monad-logger and implement MonadLogger?

Are there use cases for using fast-logger without the monad-logger machinery?

As it is currently, monad-logger provides a nice abstraction for loggers in general, but since it has a hard dependency on fast-logger it's kind of useless as a general abstraction, since the logger is actually built-in so to speak.

What would be the easiest way to achive that? Frankly, @(<unknown>:<unknown> <unknown>:0:0) in logs doesn't carry much information.

My first choice was deriving instance Eq Loc, and then comparing the loc argument in defaultLogStr with defaultLoc, but then it looks like a hack.

Hi,

The example fail to compile with the following error:

wai_logger.hs:19:5:
    Couldn't match type ‘Network.Wai.Internal.Response’
                  with ‘IO Network.Wai.Internal.ResponseReceived’
    Expected type: ((Network.Wai.Internal.Response
                     -> IO Network.Wai.Internal.ResponseReceived)
                    -> ())
                   -> ((Network.Wai.Internal.Response
                        -> IO Network.Wai.Internal.ResponseReceived)
                       -> Network.Wai.Internal.Response)
                   -> (Network.Wai.Internal.Response
                       -> IO Network.Wai.Internal.ResponseReceived)
                   -> IO Network.Wai.Internal.ResponseReceived
      Actual type: ((Network.Wai.Internal.Response
                     -> IO Network.Wai.Internal.ResponseReceived)
                    -> ())
                   -> ((Network.Wai.Internal.Response
                        -> IO Network.Wai.Internal.ResponseReceived)
                       -> Network.Wai.Internal.Response)
                   -> (Network.Wai.Internal.Response
                       -> IO Network.Wai.Internal.ResponseReceived)
                   -> Network.Wai.Internal.Response
    In a stmt of a 'do' block: liftIO $ aplogger req status (Just len)
    In the expression:
      do { liftIO $ aplogger req status (Just len);
           return $ responseBuilder status hdr msg }
    In an equation for ‘logApp’:
        logApp aplogger req
          = do { liftIO $ aplogger req status (Just len);
                 return $ responseBuilder status hdr msg }
          where
              status = status200
              hdr = [("Content-Type", "text/plain"), ....]
              pong = "PONG"
              len = fromIntegral $ BS.length pong
              ....

wai_logger.hs:20:41:
    Couldn't match expected type ‘Data.ByteString.Builder.Internal.Builder’
                with actual type ‘LogStr’
    In the third argument of ‘responseBuilder’, namely ‘msg’
    In the second argument of ‘($)’, namely
      ‘responseBuilder status hdr msg’

GHC: 7.8.4
Warp: 3.0.13

Hi,

Is there some way to use MonadLogger using a filename instead of stdout/stderr?

Thanks

Minimal reproducing test case:

import System.Log.FastLogger
import System.IO

main = do
    logger <- mkLogger True stdout
    loggerPutStr logger [LS $ replicate 9096 'x']

Originally reported by cutsea110: https://groups.google.com/d/topic/yesodweb/3zog8_Q5XUE/discussion

I'd like to add following enhancements:

• generalise ApacheLoggerActions from wai-logger to something like FastLoggerActions with configurable auto-rotate and auto-log-timestamp capabilities, add these to fast-logger.

Motivation: timestamp logging is absolutely necessary, a lot of librarys doing this in a very inefficient way, for example, logging doing this with a system call and a directly show. The work you have done in wai-logger is awesome!

• add runFastLoggerLoggingT :: MonadIO m => FastLoggerActions -> LoggingT m a -> m a to monad-logger and re-export FastLoggerActions related functions from fast-logger.

Motivation: since monad-logger rely on fast-logger, we should provide ways to use it with MonadLogger.

Are these changes look good to you? I'd like send a pr with those enhancement : )

Currently, filterLogger :: (LogSource -> LogLevel -> Bool) -> LoggingT m a -> LoggingT m a. I'd like filterLogger :: MonadLogger m => (LogSource -> LogLevel -> Bool) -> m a -> m a.

Unfortunately, I can't see a way to do this without a breaking API change or a new typeclass.

Why do I want this? I have a function that's polymorphic on MonadLogger m, which invokes a library which has lots of log output. I'd like to silence some invocations of this library, but not others. I can do one of the following things:

• Make LoggingT explicit in the type, losing polymorphism, and causing me to plumb this decision all the way through all the callers.
• Create a new typeclass specifically for modifying the logger function.

The new typeclass could look something like this:

class LoggerLens m where
    loggerLens :: Lens' (m a) ((Loc -> LogSource -> LogLevel -> msg -> m ()) -> m a)

type Lens' s a = forall f. Functor f => (a -> f a) -> s -> f s

This would then allow polymorphic implementations of filterLogger and withChannelLogger. NoLoggingT would get an improper lens, but I think that's ok.

Personally, I'd prefer that this capability always be available to MonadLogger instances, but I realize the API breakage would be huge.

Thoughts? Maybe something like this can make it into the next major-major release?

We use log prefixes at work to help grep through logs. I've made a newtype instance that is sufficiently general that I'd like to make it available. If you'd like to have this in MonadLogger, then I'd be happy to submit a PR, otherwise I'll just upload it to Hackage.

This is the bulk of the code:

newtype LogPrefix m a = LogPrefix { runLogPrefix :: ReaderT Text m a }
    deriving (Functor, Applicative, Monad, MonadTrans)

instance MonadLogger m => MonadLogger (LogPrefix m) where
    monadLoggerLog loc src lvl msg = LogPrefix $ ReaderT $ \prefix ->
        monadLoggerLog loc src lvl (toLogStr prefix <> toLogStr msg)

prefixLogs :: MonadLogger m => Text -> LogPrefix m a -> m a
prefixLogs prefix action =
    flip runReaderT (mconcat ["[",prefix, "] "]) $ runLogPrefix action

with usage like

foo :: MonadLogger m => m ()
foo = $(logDebug) "foo"

lawl :: IO ()
lawl = do
    putStrLn "starting:"
    runStdoutLoggingT $ do
        foo
        "foo" `prefixLogs` do
            "nested" `prefixLogs` foo

which has the output

starting:
[Debug] foo
[Debug] [foo] [nested] foo

I'm currently working on getting Yesod working for ghc-8.0 which is pretty close to being formally released.

Building the git version of yesod-core against the git version of wai-logger I get:

Yesod/Core/Types.hs:52:54: error:
    Module ‘Network.Wai.Logger’ does not export ‘DateCacheGetter’

Should that be fixed in yesod-core or wai-logger?

On a fresh minimal ghc build, fast-logger-2.4.7 installs fine.
The error message:

Building fast-logger-2.4.8...
Preprocessing library fast-logger-2.4.8...

System\Log\FastLogger\FileIO.hs:15:0: error:
     error: macro names must be identifiers
     #ifdef !MIN_VERSION_win32(2,3,1,0)
     ^
`gcc.exe' failed in phase `C pre-processor'. (Exit code: 1)

Thank you for the nice logging library! I use it a lot :)

I end up writing this a lot. Would you be open to $log*T and $log*TS variants of the log functions which have the type:

$logDebugT :: (Show a, MonadLogger m) => a -> m ()

Instead of:

$logDebug :: MonadLogger m => Text -> m ()

If this is something you're willing to do, let me know and I will PR it. I'm not stuck on the naming either.

Hello,

I've been toying around with GHC 8s CallStack lately. Maybe this is something you are interested in as well! It eliminates the need for template haskell to have precise source location in your logs.

Here, a little example:

logWithCS :: (?callstack::CallStack, MonadLogger m, ToLogStr msg) => LogLevel -> msg -> m ()
logWithCS level msg =
  case getCallStack ?callstack of
    ((_, srcLoc):_)
      -> monadLoggerLog (Loc { loc_filename = srcLocFile srcLoc
                             , loc_package  = srcLocPackage srcLoc
                             , loc_module   = srcLocModule srcLoc
                             , loc_start    = (srcLocStartLine srcLoc, srcLocStartCol srcLoc)
                             , loc_end      = (srcLocEndLine srcLoc, srcLocEndCol srcLoc)
                             } ) "" level msg

Running

import Control.Monad.Logger

main :: IO ()
main = do

  runStdoutLoggingT $ do
    logWithCS LevelInfo "hello callstack"

results in : [Info] hello callstack @(main:Main main.hs:7:5)

I would like to change fast-logger as follows:

• Stop exporting logStrBuilder. This is because fast-logger uses blaze-builder's Builder or bytestring Builder depending on the version of bytestring. Such difference should be hidden.
• Provide necessary APIs such as toByteString.
• Hide FD from API since FD is specific to GHC internal. So, logOpen will be removed. newLoggerSet takes FilePath and opens FD internally.

@snoyberg what do you think?

Installing with unix-time 0.1.9 already installed gave me the following compile error:

Preprocessing library wai-logger-2.0.1...
[1 of 4] Compiling Network.Wai.Logger.IP ( Network/Wai/Logger/IP.hs, dist/build/Network/Wai/Logger/IP.o )
[2 of 4] Compiling Network.Wai.Logger.Date ( Network/Wai/Logger/Date.hs, dist/build/Network/Wai/Logger/Date.o )

Network/Wai/Logger/Date.hs:66:18:
    Couldn't match type `ByteString' with `IO ByteString'
    Expected type: unix-time-0.1.9:Data.UnixTime.Types.UnixTime
                   -> IO ByteString
      Actual type: unix-time-0.1.9:Data.UnixTime.Types.UnixTime
                   -> ByteString
    In the return type of a call of `formatUnixTime'
    In the first argument of `(.)', namely

Unregistering the package and installing 0.2.2 solved the problem.

I get the following error when trying to compile 2.4.6 and 2.4.7:
C:...\fast-logger-2.4.7\System\Log\FastLogger\FileIO.hs:25:26: error:
Ambiguous occurrence fILE_APPEND_DATA' It could refer to either System.Win32.File.fILE_APPEND_DATA',
imported from System.Win32.File' at System\Log\FastLogger\FileIO.hs:10:1-24 or System.Log.FastLogger.FileIO.fILE_APPEND_DATA',
defined at System\Log\FastLogger\FileIO.hs:18:1

It looks like this was added to Win32 in June:
haskell/win32@84b9663#diff-a99994770dbe04188c1176136aef3d32

Maybe delete the two lines:
https://github.com/kazu-yamamoto/logger/blob/fast-logger-2.4.6/fast-logger/System/Log/FastLogger/FileIO.hs#L17

Build log is here: https://gist.github.com/ilovezfs/c62fa40eb3f61569cb0e03f8cd3320a8

Several errors that look like

Control/Monad/Logger.hs:249:10: error:
    • Couldn't match type ‘m’ with ‘IdentityT m’
      ‘m’ is a rigid type variable bound by
        the instance declaration at Control/Monad/Logger.hs:249:10
      Expected type: IdentityT
                       m (Loc -> LogSource -> LogLevel -> LogStr -> IO ())
        Actual type: IdentityT
                       (IdentityT m) (Loc -> LogSource -> LogLevel -> LogStr -> IO ())

Commenting out https://github.com/kazu-yamamoto/logger/blob/master/monad-logger/Control/Monad/Logger.hs#L249-L264 seems to work around the problem.

Network/Wai/Logger/Date.hs imports System.Locale on Windows, so it needs to depend on old-locale on that platform. It also needs time, for Data.Time. With those dependencies added, it builds on windows.

hi,

for extensible effects i need a typeable instance for LogStr. Would you kindly upload a new version with it?

thanks in advance.

wai-logger does not specify any upper bounds on its dependencies on Hackage. This sometimes causes conflicts with other packages that rely on older versions of those dependencies. This is also contrary to the recommendation in the PVP.

Could upper bounds be added to the depedencies?

Do you folks happen to have examples of one would go about specifying what log level to use when using runStderrLoggingT or runStdoutLoggingT ? Couldn't find anything about it, and I'm not sure making own version of defaultOutput is the right way to go.

Tips?

wai-extras breaks due to the latest update,

Network\Wai\Middleware\RequestLogger.hs:85:64:
Not in scope: `logStrBuilder'

I notice it was in 2.0.0 http://hackage.haskell.org/package/fast-logger-2.0.0/docs/src/System-Log-FastLogger.html
but missing in 2.0.2, http://hackage.haskell.org/package/fast-logger-2.0.2/docs/src/System-Log-FastLogger.html

The following reproduces the problem (also available as a Gist):

-- Compiled with:
--
-- stack --resolver lts-6.17 ghc --package async --package fast-logger -- -threaded -rtsopts -with-rtsopts -N large-fast-logger.hs

{-# LANGUAGE OverloadedStrings #-}
import Control.Concurrent.Async (Concurrently (..))
import Control.Monad            (unless, zipWithM_)
import Data.Foldable            (traverse_)
import Data.Monoid              ((<>))
import Data.String              (fromString)
import System.Log.FastLogger    (LoggerSet, newFileLoggerSet, pushLogStr,
                                 rmLoggerSet)

main :: IO ()
main = do
    loggerSet <- newFileLoggerSet 16 "log.txt" -- really small on purpose
    runConcurrently $ traverse_ (Concurrently . run loggerSet) ['A'..'Z']
    rmLoggerSet loggerSet
    output <- readFile "log.txt"
    zipWithM_ checkLine [1..] (lines output)

run :: LoggerSet -> Char -> IO ()
run loggerSet c =
    pushLogStr loggerSet str
  where
    str = fromString (replicate 99 c) <> "\n"

checkLine :: Int -> String -> IO ()
checkLine lineNumber chars = do
    unless (length chars == 99)
        $ putStrLn $ "Does not have 99 characters: " ++ show lineNumber
    case chars of
        [] -> return () -- already mentioned above
        x:xs
            | any (/= x) xs ->
                putStrLn $ "Mismatched characters: " ++ show lineNumber
            | otherwise -> return ()

The issue appears to be that each thread's individual buffer fills up, and then the chunks are sent interleaved to the Handle.

The current API forces one to choose the log backend once and for all when runLoggingT is called. This may be undesirable, as you may want to add new log handlers dynamically afterwards.

The solution I'm currently using is to feed a broadcast TChan as a log backend, to which I can dynamically subscribe in as many log handlers as I want.

This is quite boilerplate as it seems monad-logger wasn't designed to be used in such a way, so I'm wondering: would you consider augmenting monad-logger to handle/facilitate that use case ?

Thank you.

Is there a chance to upload a new version of this package that fixes the following build error?

[4 of 4] Compiling Network.Wai.Logger ( Network/Wai/Logger.hs, dist/build/Network/Wai/Logger.o )

Network/Wai/Logger.hs:93:25:
    Not in scope: `hPutLogStr'
    Perhaps you meant `hPutStr' (imported from System.IO)

A complete build log is at http://hydra.cryp.to/build/144214/nixlog/1/raw.

I understand FastLogger :: LogStr -> IO () but don't understand the type of TimedFastLogger:: (FormattedTime -> LogStr) -> IO (). How do I pass the actual string to log to such a logger?

Compiling with exceptions 0.6 fails. This seems to fix it:

Index: habs/haskell-monad-logger/src/monad-logger-0.3.6/Control/Monad/Logger.hs
===================================================================
--- habs.orig/haskell-monad-logger/src/monad-logger-0.3.6/Control/Monad/Logger.hs
+++ habs/haskell-monad-logger/src/monad-logger-0.3.6/Control/Monad/Logger.hs
@@ -86,7 +86,7 @@ import Control.Monad.IO.Class (MonadIO (
 import Control.Monad.Trans.Resource (MonadResource (liftResourceT), MonadThrow, monadThrow)
 #if MIN_VERSION_resourcet(1,1,0)
 import Control.Monad.Trans.Resource (throwM)
-import Control.Monad.Catch (MonadCatch (..))
+import Control.Monad.Catch (MonadCatch (..), MonadMask (..))
 #endif

 import Control.Monad.Trans.Identity ( IdentityT)
@@ -276,6 +276,8 @@ instance MonadThrow m => MonadThrow (NoL
 instance MonadCatch m => MonadCatch (NoLoggingT m) where
     catch (NoLoggingT m) c =
         NoLoggingT $ m `catch` \e -> runNoLoggingT (c e)
+
+instance MonadMask m => MonadMask (NoLoggingT m) where
     mask a = NoLoggingT $ mask $ \u -> runNoLoggingT (a $ q u)
       where q u (NoLoggingT b) = NoLoggingT $ u b
     uninterruptibleMask a =
@@ -347,6 +349,7 @@ instance MonadThrow m => MonadThrow (Log
 instance MonadCatch m => MonadCatch (LoggingT m) where
   catch (LoggingT m) c =
       LoggingT $ \r -> m r `catch` \e -> runLoggingT (c e) r
+instance MonadMask m => MonadMask (LoggingT m) where
   mask a = LoggingT $ \e -> mask $ \u -> runLoggingT (a $ q u) e
     where q u (LoggingT b) = LoggingT (u . b)
   uninterruptibleMask a =

Location and source information occupies considerable amount of space in logs cluttering them and exposing application internals to external observers. Even if you use non-TH versions like log_N or log_NS, location information is still present in output with all fields set to "undefined" or zeros.

I would like to see versions of logging functions that do not include location/source completely.

fast-logger 2.4.4 has just been released to hackage, but it looks like the new version of wai-logger hasn't (yet), and the current version isn't source compatible.

Network/Wai/Logger.hs:230:11:
    Ambiguous occurrence ‘LogCallback’
    It could refer to either ‘Network.Wai.Logger.LogCallback’,
                             defined at Network/Wai/Logger.hs:108:16
                          or ‘System.Log.FastLogger.LogCallback’,
                             imported from ‘System.Log.FastLogger’ at Network/Wai/Logger.hs:60:1-28

I often find myself writing this function when I work with fast-logger:

pushLogStrLn :: LoggerSet -> LogStr -> IO ()
pushLogStrLn loggerSet logStr = pushLogStr loggerSet (logStr <> "\n")

Would this be a good addition to fast-logger?

fast-logger-0.3.0 cannot compile on Windows 7 and ghc-7.4.1.

System\Log\FastLogger\Date.hs:26:16: parse error on input `ut'

The source loc is here:

https://github.com/kazu-yamamoto/logger/blob/master/fast-logger/System/Log/FastLogger/Date.hs#L26

This syntax seems not be supported on ghc-7.4.1.
Is there on newer version?

While installing fast-logger 2.4.3 and 2.4.2 using cabal, I get the following error message:

Configuring fast-logger-2.4.3...
Building fast-logger-2.4.3...
Preprocessing library fast-logger-2.4.3...
[1 of 7] Compiling System.Log.FastLogger.LogStr ( System\Log\FastLogger\LogStr.hs, dist\build\System\Log\FastLogger\LogStr.o )
[2 of 7] Compiling System.Log.FastLogger.IORef ( System\Log\FastLogger\IORef.hs, dist\build\System\Log\FastLogger\IORef.o )
[3 of 7] Compiling System.Log.FastLogger.FileIO ( System\Log\FastLogger\FileIO.hs, dist\build\System\Log\FastLogger\FileIO.o )

System\Log\FastLogger\FileIO.hs:26:47:
Not in scope: fILE_SHARE_DELETE' Perhaps you meantfILE_SHARE_WRITE' (imported from System.Win32.File)
Failed to install fast-logger-2.4.3

$ cabal install fast-logger-2.4.2
Resolving dependencies...
Downloading fast-logger-2.4.2...
Configuring fast-logger-2.4.2...
Building fast-logger-2.4.2...
Preprocessing library fast-logger-2.4.2...
[1 of 7] Compiling System.Log.FastLogger.LogStr ( System\Log\FastLogger\LogStr.hs, dist\build\System\Log\FastLogger\LogStr.o )
[2 of 7] Compiling System.Log.FastLogger.IORef ( System\Log\FastLogger\IORef.hs, dist\build\System\Log\FastLogger\IORef.o )
[3 of 7] Compiling System.Log.FastLogger.FileIO ( System\Log\FastLogger\FileIO.hs, dist\build\System\Log\FastLogger\FileIO.o )

System\Log\FastLogger\FileIO.hs:22:47:
Not in scope: fILE_SHARE_DELETE' Perhaps you meantfILE_SHARE_WRITE' (imported from System.Win32.File)
Failed to install fast-logger-2.4.2
cabal.exe: Error: some packages failed to install:
fast-logger-2.4.2 failed during the building phase. The exception was:
ExitFailure 1

Version 2.4.1 is fine:

$ cabal install fast-logger-2.4.1
Resolving dependencies...
Downloading fast-logger-2.4.1...
Configuring fast-logger-2.4.1...
Building fast-logger-2.4.1...
Preprocessing library fast-logger-2.4.1...
[1 of 6] Compiling System.Log.FastLogger.LogStr ( System\Log\FastLogger\LogStr.hs, dist\build\System\Log\FastLogger\LogStr.o )
[2 of 6] Compiling System.Log.FastLogger.IORef ( System\Log\FastLogger\IORef.hs, dist\build\System\Log\FastLogger\IORef.o )
[3 of 6] Compiling System.Log.FastLogger.IO ( System\Log\FastLogger\IO.hs, dist\build\System\Log\FastLogger\IO.o )
[4 of 6] Compiling System.Log.FastLogger.Logger ( System\Log\FastLogger\Logger.hs, dist\build\System\Log\FastLogger\Logger.o )
[5 of 6] Compiling System.Log.FastLogger.File ( System\Log\FastLogger\File.hs, dist\build\System\Log\FastLogger\File.o )
[6 of 6] Compiling System.Log.FastLogger ( System\Log\FastLogger.hs, dist\build\System\Log\FastLogger.o )
[1 of 6] Compiling System.Log.FastLogger.LogStr ( System\Log\FastLogger\LogStr.hs, dist\build\System\Log\FastLogger\LogStr.p_o )
[2 of 6] Compiling System.Log.FastLogger.IORef ( System\Log\FastLogger\IORef.hs, dist\build\System\Log\FastLogger\IORef.p_o )
[3 of 6] Compiling System.Log.FastLogger.IO ( System\Log\FastLogger\IO.hs, dist\build\System\Log\FastLogger\IO.p_o )
[4 of 6] Compiling System.Log.FastLogger.Logger ( System\Log\FastLogger\Logger.hs, dist\build\System\Log\FastLogger\Logger.p_o )
[5 of 6] Compiling System.Log.FastLogger.File ( System\Log\FastLogger\File.hs, dist\build\System\Log\FastLogger\File.p_o )
[6 of 6] Compiling System.Log.FastLogger ( System\Log\FastLogger.hs, dist\build\System\Log\FastLogger.p_o )
In-place registering fast-logger-2.4.1...
Installing library in
C:\Users\laarpjljvd\AppData\Roaming\cabal\fast-logger-2.4.1\ghc-7.6.3
Registering fast-logger-2.4.1...
Installed fast-logger-2.4.1

installation info:

Ghc-7.6.3

cabal-install version 1.16.0.2
using version 1.16.0 of the Cabal library

Microsoft Windows [Version 6.1.7601]

Good luck solving this bug!

Added info:
Hi Pierre,

While installing fast-logger 2.4.3 and 2.4.2 using cabal, I get the
following error message:

Would you register this issue to github issues?

https://github.com/kazu-yamamoto/logger/issues

And write comment which notify to @drchaos? This code is from him:

https://github.com/kazu-yamamoto/logger/pull/79

Since I don't have Windows environment, I cannot help you. But I believe that @drchaos helps you.

--Kazu

Fails to install with the following error:

System/Log/FastLogger/Date.hs:34:18:
Couldn't match type ByteString' withIO ByteString'
Expected type: UnixTime -> IO ByteString
Actual type: UnixTime -> ByteString
In the return type of a call of formatUnixTime' In the first argument of(.)', namely
formatUnixTime "%d/%b/%Y:%T %z"' In theformatDate' field of a record
Failed to install fast-logger-0.3.2

A possible solution is to add a proper version bound to unix-time in the .cabal file

In #80, I noticed that when logging a long message, in toBufIOWith there comes around a Done with len == 0 as the first thing before the real data comes.

This issue is about investigating whether this is a bug, or whether it's expected, or whether it could be optimised away.

Sometimes I need to add logging facilities in pure code for debugging. I implement that by using StateT and Identity. When no debug is needed, I think I can use NoLoggingT and Identity, but MonadIO Identity requirement is in the way.

Is there any better way to do what I want? Am I wrong in something?

Thanks a lot.

Gilbert Fine

I upgraded to WAI 2 which required new versions of wai-logger and fast-logger. It works fine for our Yesod app, but we have other code that just uses monad-logger runStdoutLoggingT and this no longer works. When I back down to version 0.3.2.0 of monad-logger it works again. I will try to provide something to reproduce this with.

Probably not windows specific. This system probably has an old version of fast-logger, and you need to update the required version, to 2.0.0.

Preprocessing library monad-logger-0.3.3.0...
[1 of 1] Compiling Control.Monad.Logger ( Control\Monad\Logger.hs, dist\build\Control\Monad\Logger.o )

Control\Monad\Logger.hs:63:39:
Module System.Log.FastLogger' does not exportpushLogStr'

Control\Monad\Logger.hs:63:72:
Module System.Log.FastLogger' does not exportLoggerSet'

Control\Monad\Logger.hs:63:83:
Module System.Log.FastLogger' does not exportnewLoggerSet'

Control\Monad\Logger.hs:63:97:
Module System.Log.FastLogger' does not exportdefaultBufSize'

@snoyberg Since your definition of Logger is not suitable for wai-logger-prefork, I changed it. But API remains the same. Is this OK with you?

c1a6f9d

And I set the version of fast-logger to 0.2.0 because the versions of wai-logger and wai-logger-prefork is now 0.2.0.

If you like this commit, I will update document.

The fix for #119 fails on older versions of GHC (7.8.* and I assume lower, though I haven't checked) with the following errors:

Duplicate type signatures for `fILE_APPEND_DATA'
        at System\Log\FastLogger\FileIO.hs:17:1-16
           System\Log\FastLogger\FileIO.hs:22:1-16

Multiple declarations of `fILE_APPEND_DATA'
        Declared at: System\Log\FastLogger\FileIO.hs:18:1
                     System\Log\FastLogger\FileIO.hs:23:1

Issue's probably here

LogStr does not have an instance of Semigroup. This does not interact well with classy-prelude which provides (<>) operator defined in Semigroup.

Is there any reason to have this private?