This is a framework for creating commandline applications. It provides various features which give a polished feel to your application.
It is designed to encourage you to provide clear documentation and working examples. It implements default 'help' and 'man' commands for your application, which will layout help text and generate Unix-style man pages.
It provides special handling for applications of the form ''program command args'', the style of interaction common in revision control systems. It will dispatch to handler functions that you provide for each command, and also provide command-specific help to the user.
This package lets you easily query various facts about the system that your code is running on. Currently, it reports whether the operating system is "Windows" or "Unix", and also the name and version of the Haskell compiler used.
This package implements lots of complicated trickery to determine the build environment. Once built, other packages can query this information without needing to do complex trickery themselves.
See also the included ReadMe.xhtml file.
* If the configure step fails to detect the OS type, the configure step now fails.
* A new file Manual.hs allows you to override the auto-detected platform values with whatever you want. (See ReadMe.xhtml for details.)
* All the platform queries no longer return Maybe values. (This breaks API compatibility, hence the version bump.)
Some simple interactive programs for sending MIDI control messages via ALSA. The GUI uses wxHaskell. Currently we provide these programs:
* Send All Notes Off and All Sounds Off events.
* Show several sliders, that trigger sending MIDI controller messages.
* Show a list widget, that triggers MIDI program changes.
Consume attoparsec parsers via conduit.
This language is a demonstration of the Epic compiler API. It is a dynamically typed language with higher order functions and system interaction (specifically graphics). Requires SDL and SDL_gfx libraries, and their C headers.
Base64-encode and decode streams of bytes.
The binary-conduit package. Allow binary serialization using iterative conduit interface.
Bitstream support for Conduit
This library provides an abstraction of buffered output of byte streams and several convenience functions to exploit it. For example, it allows to efficiently serialize Haskell values to lazy bytestrings with a large average chunk size. The large average chunk size allows to make good use of cache prefetching in later processing steps (e.g. compression) and reduces the sytem call overhead when writing the resulting lazy bytestring to a file or sending it over the network.
Convert streams of builders to streams of bytestrings.
This package integrates the builders from the blaze-builder package with the enumerator package. It provides infrastructure and enumeratees for incrementally executing builders and pass the filled chunks to a bytestring iteratee.
Includes utilities for checking the host platform, running tests, capturing output, handling errors, comparing runtimes against a baseline, sending mail, running events to a schedule etc.
Tools for working with buildbox benchmark result files.
Buildwrapper is an alternative to scion. It provides services to configure, build and give information on source files to help IDEs manage Haskell projects. You can use buildwrapper to build project and retrieve errors, get outline for each module source, get the type of something inside a source file, get lexer tokens, etc. Buildwrapper is used in the EclipseFP project (Eclipse plugins for Haskell development)
Streaming compression/decompression via conduits.
Interactive user interface for computer algebra systems
Turn Data.Serialize Gets and Puts into Sources, Sinks, and Conduits.
0.7: Upgrade to conduit 1.0.0
conduit instances for classy-prelude
conduit is a solution to the streaming data problem, allowing for production, transformation, and consumption of streams of data in constant memory. It is an alternative to lazy I/O which guarantees deterministic resource handling, and fits in the same general solution space as enumerator/iteratee and pipes. For a tutorial, please visit https://haskell.fpcomplete.com/user/snoyberg/library-documentation/conduit-overview.
1.0: Simplified the user-facing interface back to the Source, Sink, and Conduit types, with Producer and Consumer for generic code. Error messages have been simplified, and optional leftovers and upstream terminators have been removed from the external API. Some long-deprecated functions were finally removed. 0.5: The internals of the package are now separated to the .Internal module, leaving only the higher-level interface in the advertised API. Internally, switched to a Leftover constructor and slightly tweaked the finalization semantics. 0.4: Inspired by the design of the pipes package: we now have a single unified type underlying Source, Sink, and Conduit. This type is named Pipe. There are type synonyms provided for the other three types. Additionally, BufferedSource is no longer provided. Instead, the connect-and-resume operator, $$+, can be used for the same purpose. 0.3: ResourceT has been greatly simplified, specialized for IO, and moved into a separate package. Instead of hard-coding ResourceT into the conduit datatypes, they can now live around any monad. The Conduit datatype has been enhanced to better allow generation of streaming output. The SourceResult, SinkResult, and ConduitResult datatypes have been removed entirely. 0.2: Instead of storing state in mutable variables, we now use CPS. A Source returns the next Source, and likewise for Sinks and Conduits. Not only does this take better advantage of GHC's optimizations (about a 20% speedup), but it allows some operations to have a reduction in algorithmic complexity from exponential to linear. This also allowed us to remove the Prepared set of types. Also, the State functions (e.g., sinkState) use better constructors for return types, avoiding the need for a dummy state on completion. 0.1: BufferedSource is now an abstract type, and has a much more efficient internal representation. The result was a 41% speedup on microbenchmarks (note: do not expect speedups anywhere near that in real usage). In general, we are moving towards BufferedSource being a specific tool used internally as needed, but using Source for all external APIs. 0.0: Initial release.
Show more results