<commit_before>homepage: ''
changelog-type: markdown
hash: 1ad8accf1c99430d7007e6d10ca4e1e53f5467db6980526b81f64235ce5c039d
test-bench-deps: {}
maintainer: <EMAIL>
synopsis: An event-oriented observability library
changelog: |
  # Revision history for eventuo11y

  ## 0.3.1.0 -- 2022-10-04

  Add causedEventBackend

  ## 0.3.0.0 -- 2022-10-03

  Add single-modifier exports from BackendModification

  ## 0.2.0.0 -- 2022-10-03

  Relax text upper and lower bounds

  ## 0.2.0.0 -- 2022-10-03

  - Add Observe.Event.BackendModification DSL
  - Generalize newOnceFlagIO to newOnceFlagMVar

  ## 0.1.0.1 -- 2022-09-30

  Relax aeson lower bound

  ## 0.1.0.0 -- 2022-09-28

  Initial release
basic-deps:
  exceptions: ^>=0.10
  bytestring: '>=0.10 && <0.12'
  base: '>=4.14 && <4.17'
  time: '>=1.9 && <1.12'
  text: '>=1.2 && <2.1'
  uuid: ^>=1.3
  unliftio-core: ^>=0.2
  resourcet: ^>=1.2
  aeson: ^>=2.0.2.0
  primitive: ^>=0.7
all-versions:
- 0.1.0.0
- 0.1.0.1
- 0.2.0.0
- 0.2.0.1
- 0.3.0.0
- 0.3.1.0
author: <NAME>
latest: 0.3.1.0
description-type: haddock
description: |-
  Instrument your Haskell codebase with wide, semantically meaningful events.
  This library is designed with separating the following concerns in mind:

  [@Writing instrumentation@] When instrumenting code, I want to think in terms of my
  application domain and report any information I might need to infer internal
  application-level state and understand the behavior of my program/library.

  [@Consuming instrumentation@] When consuming instrumentation, I want to think in
  terms of the API fo the specific backend I'm supporting (writing to @stderr@,
  serving a @Prometheus@ page, posting to @OpenTelemetry@) and what is needed to
  render to that API.

  [@Initializing instrumentation in an application@] When I'm ready to tie it all
  together, I want to identify the specific backends I want to post to and provide
  the bridge code to render the domain-specific instrumentation as needed for those
  backends. I also want to handle concerns like sampling or client-side aggregation
  of domain-specific instrumentation to keep usage manageable.

  See "Observe.Event" for detailed documentation on instrumenting your code.

  See "Observe.Event.Backend" for documentation on writing an
  @EventBackend@.

  See [Example.hs](https://github.com/shlevy/eventuo11y/tree/v0.3.1.0/Example.hs) for an example.

  See [eventuo11y-batteries](https://hackage.haskell.org/package/eventuo11y-batteries) for miscellaneous
  framework-specific helpers.
license-name: Apache-2.0<commit_msg>Update from Hackage at 2022-10-04T21:43:48Z<commit_after>homepage: ''
changelog-type: markdown
hash: 21607fc3d1df294a06a572e380d8f6a5ca3236efaef29a3fcb8a964768d27aee
test-bench-deps: {}
maintainer: <EMAIL>
synopsis: An event-oriented observability library
changelog: |
  # Revision history for eventuo11y

  ## 0.3.2.0 -- 2022-10-04

  Add hoistEvent

  ## 0.3.1.0 -- 2022-10-04

  Add causedEventBackend

  ## 0.3.0.0 -- 2022-10-03

  Add single-modifier exports from BackendModification

  ## 0.2.0.0 -- 2022-10-03

  Relax text upper and lower bounds

  ## 0.2.0.0 -- 2022-10-03

  - Add Observe.Event.BackendModification DSL
  - Generalize newOnceFlagIO to newOnceFlagMVar

  ## 0.1.0.1 -- 2022-09-30

  Relax aeson lower bound

  ## 0.1.0.0 -- 2022-09-28

  Initial release
basic-deps:
  exceptions: ^>=0.10
  bytestring: '>=0.10 && <0.12'
  base: '>=4.14 && <4.17'
  time: '>=1.9 && <1.12'
  text: '>=1.2 && <2.1'
  uuid: ^>=1.3
  unliftio-core: ^>=0.2
  resourcet: ^>=1.2
  aeson: ^>=2.0.2.0
  primitive: ^>=0.7
all-versions:
- 0.1.0.0
- 0.1.0.1
- 0.2.0.0
- 0.2.0.1
- 0.3.0.0
- 0.3.1.0
- 0.3.2.0
author: <NAME>
latest: 0.3.2.0
description-type: haddock
description: |-
  Instrument your Haskell codebase with wide, semantically meaningful events.
  This library is designed with separating the following concerns in mind:

  [@Writing instrumentation@] When instrumenting code, I want to think in terms of my
  application domain and report any information I might need to infer internal
  application-level state and understand the behavior of my program/library.

  [@Consuming instrumentation@] When consuming instrumentation, I want to think in
  terms of the API fo the specific backend I'm supporting (writing to @stderr@,
  serving a @Prometheus@ page, posting to @OpenTelemetry@) and what is needed to
  render to that API.

  [@Initializing instrumentation in an application@] When I'm ready to tie it all
  together, I want to identify the specific backends I want to post to and provide
  the bridge code to render the domain-specific instrumentation as needed for those
  backends. I also want to handle concerns like sampling or client-side aggregation
  of domain-specific instrumentation to keep usage manageable.

  See "Observe.Event" for detailed documentation on instrumenting your code.

  See "Observe.Event.Backend" for documentation on writing an
  @EventBackend@.

  See [Example.hs](https://github.com/shlevy/eventuo11y/tree/v0.3.2.0/Example.hs) for an example.

  See [eventuo11y-batteries](https://hackage.haskell.org/package/eventuo11y-batteries) for miscellaneous
  framework-specific helpers.
license-name: Apache-2.0
{'fraction_non_alphanumeric': 0.11126005361930295, 'fraction_numerical': 0.07813098429720414, 'mean_word_length': 3.597711267605634, 'pattern_counts': {'":': 0, '<': 15, '<?xml version=': 0, '>': 27, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 32, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4863574', 'n_tokens_mistral': 2045, 'n_tokens_neox': 1796, 'n_words': 560}