co-log-polysemy-formatting: A Polysemy logging effect for high quality (unstructured) logs.

[ bsd3, library, logging, program ] [ Propose Tags ]

co-log-polysemy-formatting builds on the co-log-polysemy package, adding terminal colours, log severity, timestamps, callers, thread ids, and a flexible log format with good defaults. It also allows you to use the formatting library for formatting your log messages.

[Skip to Readme]


Maintainer's Corner

Package maintainers

For package maintainers and hackage trustees


Versions [RSS],
Change log
Dependencies ansi-terminal (>=0.10.3 && <0.11), base (>= && <5), co-log (>= && <0.5), co-log-core (>= && <0.3), co-log-polysemy (>= && <0.1), co-log-polysemy-formatting, formatting (>=7.1.0 && <7.2), polysemy (>= && <1.6), polysemy-plugin (>= && <0.3), text (>= && <1.3), time (>= && <1.10) [details]
License BSD-3-Clause
Copyright 2020 Alex Chapman
Author Alex Chapman
Category Logging
Home page
Bug tracker
Source repo head: git clone
Uploaded by AlexChapman at 2020-12-10T07:08:09Z
Reverse Dependencies 1 direct, 0 indirect [details]
Executables example
Downloads 309 total (9 in the last 30 days)
Rating (no votes yet) [estimated by Bayesian average]
Your Rating
  • λ
  • λ
  • λ
Status Docs uploaded by user
Build status unknown [no reports yet]

Readme for co-log-polysemy-formatting-

[back to package description]

co-log-polysemy-formatting Build Status Hackage

co-log-polysemy-formatting gives you a Polysemy logging effect for high quality (unstructured) logs.

It does this by tying together several excellent packages:

To get started, see the haddock documentation.

Output format

The output format is customisable, but by default it includes:

  • The message severity,
  • a message timestamp, with nanosecond accuracy,
  • a thread Id,
  • a source location, and
  • your log message, formatted using formatting.

example output

The colours show up if your terminal supports them, otherwise it will fall back to greyscale, including if you pipe the output to a file.

formatting messages

Our logging functions, e.g. logInfo, take a formatting formatter rather than a String/Text/etc. This makes it quick and easy to build your log messages from whatever type you have at hand, and still allows you to directly log string literals thanks to the OverloadedStrings language extension:

{-# LANGUAGE OverloadedStrings #-}

myString :: String
myString = "this is my string"

myStrictText :: Data.Text.Text
myStrictText = "this is my strict text"

myLazyText :: Data.Text.Lazy.Text
myLazyText = "this is my lazy text"

-- These will all work:
logInfo "a string literal"
logInfo string myString
logInfo stext myStrictText
logInfo text myLazyText
logInfo (string % ", " % stext % ", " % text) myString myStrictText myLazyText

-- And logging structures is easy too:
data Person = Person { personName :: Text, personAge :: Int }

myPerson :: Person
myPerson = Person "Dave" 16

logInfo ("The person's name is " % accessed personName text <> ", and their age is " % accessed personAge int) myPerson

-- Or with lenses
data Person' = Person' { _personName :: Text, _personAge :: Int }
makeLenses ''Person'

myPerson' :: Person'
myPerson' = Person' "Dave" 16

logInfo ("The person's name is " % viewed personName text <> ", and their age is " % viewed personAge int) myPerson'

Why not just use co-log-polysemy?

co-log-polysemy is a generic logging effect that leaves many decisions up to you, such as your logging format and your logging message type. But if you want something that just works, with good defaults, then co-log-polysemy-formatting will get you there faster. And you're still using co-log-polysemy under the hood -- we even re-export some of its functions for you -- we've just added a few features on top.