Source: haskell-broadcast-chan Maintainer: Debian Haskell Group Uploaders: Clint Adams Priority: optional Section: haskell Build-Depends: debhelper (>= 10), haskell-devscripts-minimal | haskell-devscripts (>= 0.13), cdbs, ghc (>= 9.4), ghc-prof, libghc-unliftio-core-dev (>= 0.1.1), libghc-unliftio-core-dev (<< 0.3), libghc-unliftio-core-prof, Build-Depends-Indep: ghc-doc, libghc-unliftio-core-doc, Standards-Version: 4.7.0 Homepage: https://github.com/merijn/broadcast-chan X-Description: closable, fair, leak-avoidant, single-wakeup channel A closable, fair, single-wakeup channel that avoids the 0 reader space leak that Control.Concurrent.Chan from base suffers from. . The Chan type from Control.Concurrent.Chan consists of both a read and write end combined into a single value. This means there is always at least 1 read end for a Chan, which keeps any values written to it alive. This is a problem for applications/libraries that want to have a channel that can have zero listeners. Package: libghc-broadcast-chan-dev Architecture: any Depends: ${haskell:Depends}, ${misc:Depends}, ${shlibs:Depends}, Recommends: ${haskell:Recommends}, Suggests: ${haskell:Suggests}, Conflicts: ${haskell:Conflicts}, Provides: ${haskell:Provides}, Description: ${haskell:ShortDescription}${haskell:ShortBlurb} ${haskell:LongDescription} . ${haskell:Blurb} Package: libghc-broadcast-chan-prof Architecture: any Depends: ${haskell:Depends}, ${misc:Depends}, Recommends: ${haskell:Recommends}, Suggests: ${haskell:Suggests}, Conflicts: ${haskell:Conflicts}, Provides: ${haskell:Provides}, Description: ${haskell:ShortDescription}${haskell:ShortBlurb} ${haskell:LongDescription} . ${haskell:Blurb} Package: libghc-broadcast-chan-doc Architecture: all Section: doc Depends: ${haskell:Depends}, ${misc:Depends}, Recommends: ${haskell:Recommends}, Suggests: ${haskell:Suggests}, Conflicts: ${haskell:Conflicts}, Description: ${haskell:ShortDescription}${haskell:ShortBlurb} ${haskell:LongDescription} . ${haskell:Blurb}