logo
首页技术栈工具库讨论
text-generic-pretty
text-generic-pretty
GenericPretty is a Haskell library that supports automatic derivation of pretty printing functions on user defined data types. The form of geenrics used is based on that introduced in the paper: Magalhaes, Dijkstra, Jeuring, and Loh, A Generic Deriving Mechanism for Haskell, 3'rd ACM Symposium on Haskell, pp. 37-48, September 2010, http://dx.doi.org/10.1145/1863523.1863529. Changes from the original paper in the GHC implementation are described here: http://www.haskell.org/haskellwiki/GHC.Generics#Changes_from_the_paper. This package requires the use of the new GHC.Generics features http://www.haskell.org/haskellwiki/GHC.Generics, present from GHC 7.2. Use of these features is indicated by the DeriveGeneric pragma. or the flag -XDeriveGeneric. Pretty printing produces values of type Text.PrettyPrint.Doc, using the Text.PrettyPrint library http://www.haskell.org/ghc/docs/latest/html/libraries/pretty-1.1.1.0/Text-PrettyPrint.html. The output provided is a pretty printed version of that provided by Prelude.show. That is, rendering the document provided by this pretty printer yields an output identical to that of Prelude.show, except for extra whitespace. For information about the functions exported by the package please see the API linked further down this page. For examples of usage, both basic and more complex see the README file and the haskell source code files in the TestSuite folder, both included in the package. Finally for installation instructions also see the README file or this page: http://www.haskell.org/haskellwiki/Cabal/How_to_install_a_Cabal_package
bytestring
bytestring
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.
freetype2
freetype2
Wrapper around FreeType 2 library. Relevant exerpts from the FreeType 2 website: What is FreeType 2? FreeType 2 is a software font engine that is designed to be small, efficient, highly customizable, and portable while capable of producing high-quality output (glyph images). It can be used in graphics libraries, display servers, font conversion tools, text image generation tools, and many other products as well. The following is a non-exhaustive list of features provided by FreeType 2. FreeType 2 provides a simple and easy-to-use API to access font content in a uniform way, independently of the file format. Additionally, some format-specific APIs can be used to access special data in the font file. Unlike most comparable libraries, FreeType 2 supports scalable font formats like TrueType or Type 1 natively and can return the outline data (and control instructions/hints) to client applications. By default, FreeType 2 supports the following font formats. TrueType fonts (and collections) Type 1 fonts CID-keyed Type 1 fonts CFF fonts OpenType fonts (both TrueType and CFF variants) SFNT-based bitmap fonts X11 PCF fonts Windows FNT fonts BDF fonts (including anti-aliased ones) PFR fonts Type 42 fonts (limited support) From a given glyph outline, FreeType 2 is capable of producing a high-quality monochrome bitmap, or anti-aliased pixmap, using 256 levels of gray. This is much better than the 5 levels used by Windows 9x/98/NT/2000 or FreeType 1. FreeType 2 supports all the character mappings defined by the TrueType and OpenType specification. It is also capable of automatically synthetizing a Unicode charmap from Type 1 fonts, which puts an end to the painful 'encoding translation' headache common with this format (of course, original encodings are also available in the case where you need them). The FreeType 2 core API provides simple functions to access advanced information like glyph names or kerning data. FreeType 2 provides information that is often not available from other similar font engines, like kerning distances, glyph names, vertical metrics, etc. FreeType 2 provides its own caching subsystem since release 2.0.1. It can be used to cache either face instances or glyph images efficiently.
hdis86
hdis86
hdis86 is an interface to the udis86 disassembler, which decodes machine code for 16-, 32-, and 64-bit x86 and x86-64 / AMD64 processors. hdis86 provides an instruction stream as a Haskell algebraic data type, suitable for inspection by pattern matching. It also provides metadata such as assembly syntax in Intel or AT&T flavors. This library exposes three layers of wrapping: The Pure module has the simplest interface, effectively ByteString -> [Instruction]. The IO module exposes an imperative API closely matching the udis86 state machine, while providing Haskellish types and automatic resource management. The C module is a direct import of the udis86 library, with C types and conventions. Many users can simply import Hdis86. The Incremental module provides disassembly of lazy ByteStrings, and a function for building other incremental operations. By default, hdis86 will statically link a built-in copy of udis86-1.7, which is provided by its author under a similar BSD license. See inside the tarball for more information. If you have udis86 installed on your system, you can instead link dynamically using cabal configure --flags=external-udis86. In that case see also doc/customizing.txt. This code is available on GitHub at https://github.com/kmcallister/hdis86. The udis86 project website is located at http://udis86.sourceforge.net/. New in version 0.2: Disassembly of lazy ByteStrings A function for building other incremental operations Record selectors on Instruction QuickCheck Arbitrary instances for Instruction and related types
cpsa
cpsa
The Cryptographic Protocol Shapes Analyzer (CPSA) attempts to enumerate all essentially different executions possibe for a cryptographic protocol. We call them the shapes of the protocol. Naturally occurring protocols have only finitely many, indeed very few shapes. Authentication and secrecy properties are easy to determine from them, as are attacks and anomalies. For each input problem, the CPSA program is given some initial behavior, and it discovers what shapes are compatible with it. Normally, the initial behavior is from the point of view of one participant. The analysis reveals what the other participants must have done, given the participant's view. The search is based on a high-level algorithm that was claimed to be complete, i.e. every shape can in fact be found in a finite number of steps. Further theoretical work showed classes of executions that are not found by the algorithm, however it also showed that every omitted execution requires an unnatural interpretation of a protocol's roles. Hence the algorithm is complete relative to natural role semantics. The package contains a set of programs used to perform and display the analysis. A standards complient browser, such as Firefox, Safari, or Chrome, is required to display the results. Program documentation is in the doc directory in the source distribution, and installed in the package's data directory. You can locate the package's data directory by typing "cpsa --help" to a command prompt. New users should start learning to use the tool from the manual, found at "cpsamanual.pdf" in the data directory. Examples referenced in the manual can be found in the data directory as well. It is suggested that users make an examples directory and copy "*.scm *.xhtml" to their local examples directory, both so that they may be modified and for ease of access. Serious Windows users should install MSYS so as to allow the use of make and script execution. The theory and algorithm used by CPSA was developed with the help of Joshua D. Guttman, John D. Ramsdell, Jon C. Herzog, Shaddin F. Doghmi, F. Javier Thayer, Paul D. Rowe, and Moses D. Liskov. John D. Ramsdell and Moses D. Liskov implemented the algorithm in Haskell. CPSA was designed and implemented at The MITRE Corporation.