This module provides access to the BSD socket interface. This module is generally more efficient than the String based network functions in Socket. For detailed documentation, consult your favorite POSIX socket reference. All functions communicate failures by converting the error number to IOError.
This module is made to be imported with Socket like so:
> import Network.Socket hiding (send, sendTo, recv, recvFrom)
> import Network.Socket.ByteString
POSIX support with ByteString file paths and environment strings.
This module exports exactly the same API as System.Posix, except that all file paths and environment strings are represented by ByteString instead of String. The System.Posix API implicitly translates all file paths and environment strings using the locale encoding, whereas this version of the API does no encoding or decoding and works directly in terms of raw bytes.
Note that if you do need to interpret file paths or environment strings as text, then some Unicode encoding or decoding should be applied first.
String-based POSIX directory support
Dynamic linker support through dlopen()
DLOpen support, old API Derived from GModule.chs by M.Weber & M.Chakravarty which is part of c2hs I left the API more or less the same, mostly the flags are different.
POSIX environment support
Functions defined by the POSIX standards for manipulating and querying the file system. Names of underlying POSIX functions are indicated whenever possible. A more complete documentation of the POSIX functions together with a more detailed description of different error conditions are usually available in the system's manual pages or from http://www.unix.org/version3/online.html (free registration required).
When a function that calls an underlying POSIX function fails, the errno code is converted to an IOError using errnoToIOError. For a list of which errno codes may be generated, consult the POSIX documentation for the underlying function.
POSIX IO support. These types and functions correspond to the unix functions open(2), close(2), etc. For more portable functions which are more like fopen(3) and friends from stdio.h, see System.IO.
POSIX process support. See also the System.Cmd and System.Process modules in the process package.
POSIX temporary file and directory creation functions.
POSIX Terminal support
Make strict ByteStrings an instance of Stream with Char token type.
This provides ByteString instances for RegexMaker and RegexLike based on Text.Regex.Posix.Wrap, and a (RegexContext Regex ByteString ByteString) instance.
To use these instance, you would normally import Text.Regex.Posix. You only need to import this module to use the medium level API of the compile, regexec, and execute functions. All of these report error by returning Left values instead of undefined or error or fail.
The ByteString will only be passed to the library efficiently (as a pointer) if it ends in a NUL byte. Otherwise a temporary copy must be made with the 0 byte appended.
An efficient compact, immutable byte string type (both strict and lazy) suitable for binary or 8-bit character data.
The ByteString type represents sequences of bytes or 8-bit characters. It is suitable for high performance use, both in terms of large data quantities, or high speed requirements. The ByteString functions follow the same style as Haskell's ordinary lists, so it is easy to convert code from using String to ByteString.
Two ByteString variants are provided:
* Strict ByteStrings keep the string as a single large array. This makes them convenient for passing data between C and Haskell.
* Lazy ByteStrings use a lazy list of strict chunks which makes it suitable for I/O streaming tasks.
The Char8 modules provide a character-based view of the same underlying ByteString types. This makes it convenient to handle mixed binary and 8-bit character content (which is common in many file formats and network protocols).
The Builder module provides an efficient way to build up ByteStrings in an ad-hoc way by repeated concatenation. This is ideal for fast serialisation or pretty printing.
There is also a ShortByteString type which has a lower memory overhead and can can be converted to or from a ByteString, but supports very few other operations. It is suitable for keeping many short strings in memory.
ByteStrings are not designed for Unicode. For Unicode strings you should use the Text type from the text package.
These modules are intended to be imported qualified, to avoid name clashes with Prelude functions, e.g.
> import qualified Data.ByteString as BS
This is the bytestring builder that is debuting in bytestring-0.10.4.0, which should be shipping with GHC 7.8, probably late in 2013. This builder has several nice simplifications and improvements, and more out-of-box functionality than the older blaze-builder.
Note that this package detects which version of bytestring you are compiling against, and if you are compiling against bytestring-0.10.4 or later, will be an empty package.
This package lets the new interface and implementation be used with most older compilers without upgrading bytestring, which can be rather problematic. In conjunction with blaze-builder-0.4 or later, which offers an implementation of blaze-builder in terms of bytestring-builder, this should let most people try the new interface and implementation without causing undue compatibility problems with packages that depend on blaze-builder.
GHC 7.6 did debut an almost identical interface and implementation, but with slightly different module names and organization. Trying to re-export/rename the builder provided with 7.6 did not turn out to be very practical, because this interface includes new functions that rely on Builder internals, which are not exported in 7.6. Furthermore, these module names should be deprecated in 7.10.
In theory, this allows the design of more data-agnostic APIs.
Parse CSV formatted data efficiently
Compute a patch between two ByteStrings which can later be applied to the first to produce the second. This can be used to save bandwidth and disk space when many strings differing by a small number of bytes need to be transmitted or stored.
The underlying implementation is written in C, and can also be found at http://ccodearchive.net/info/bdelta.html.
Currently, a patch does not save any space when two strings differ by more than 1000 bytes. This arbitrary limit serves to keep applications from spiking in memory and CPU usage, as the algorithm uses quadratic space and time with respect to the length of the patch. A better algorithm may be introduced in a future version of bytestring-delta.
Show more results