Hoogle Search

Within LTS Haskell 24.6 (ghc-9.10.2)

Note that Stackage only displays results for the latest LTS and Nightly snapshot. Learn more.

package cryptonite

Cryptography Primitives sink A repository of cryptographic primitives.
- Symmetric ciphers: AES, DES, 3DES, CAST5, Blowfish, Twofish, Camellia, RC4, Salsa, XSalsa, ChaCha.
- Hash: SHA1, SHA2, SHA3, SHAKE, MD2, MD4, MD5, Keccak, Skein, Ripemd, Tiger, Whirlpool, Blake2
- MAC: HMAC, KMAC, Poly1305
- Asymmetric crypto: DSA, RSA, DH, ECDH, ECDSA, ECC, Curve25519, Curve448, Ed25519, Ed448
- Key Derivation Function: PBKDF2, Scrypt, HKDF, Argon2, BCrypt, BCryptPBKDF
- Cryptographic Random generation: System Entropy, Deterministic Random Generator
- Data related: Anti-Forensic Information Splitter (AFIS)
If anything cryptographic related is missing from here, submit a pull request to have it added. This package strives to be a cryptographic kitchen sink that provides cryptography for everyone. Evaluate the security related to your requirements before using. Read Crypto.Tutorial for a quick start guide.
package old-time

Time library This package provides the old time library. For new projects, the newer time library is recommended.
package path-io

Interface to ‘directory’ package for users of ‘path’ Interface to ‘directory’ package for users of ‘path’.
package tasty-smallcheck

SmallCheck support for the Tasty test framework. SmallCheck support for the Tasty test framework.
package hspec-discover

Automatically discover and run Hspec tests Automatically discover and run Hspec tests https://hspec.github.io/hspec-discover.html
package microlens-th

Automatic generation of record lenses for microlens This package lets you automatically generate lenses for data types; code was extracted from the lens package, and therefore generated lenses are fully compatible with ones generated by lens (and can be used both from lens and microlens). This package is a part of the microlens family; see the readme on Github.
package tasty-expected-failure

Mark tasty tests as failure expected With the function Test.Tasty.ExpectedFailure.expectFail in the provided module Test.Tasty.ExpectedFailure, you can mark that you expect test cases to fail, and not to pass. This can for example be used for test-driven development: Create the tests, mark them with Test.Tasty.ExpectedFailure.expectFail, and you can still push to the main branch, without your continuous integration branch failing. Once someone implements the feature or fixes the bug (maybe unknowingly), the test suite will tell him so, due to the now unexpectedly passing test, and he can remove the Test.Tasty.ExpectedFailure.expectFail marker. The module also provides Test.Tasty.ExpectedFailure.ignoreTest to avoid running a test. Both funtions are implemented via the more general Test.Tasty.ExpectedFailure.wrapTest, which is also provided.
package text-short

Memory-efficient representation of Unicode text strings This package provides the ShortText type which is suitable for keeping many short strings in memory. This is similiar to how ShortByteString relates to ByteString. The main difference between Text and ShortText is that ShortText doesn't support zero-copy slicing (thereby saving 2 words), and, compared to text-1.*, that it uses UTF-8 instead of UTF-16 internally. Consequently, the memory footprint of a (boxed) ShortText value is 4 words (2 words when unboxed) plus the length of the UTF-8 encoded payload.
package JuicyPixels

Picture loading/serialization (in png, jpeg, bitmap, gif, tga, tiff and radiance) This library can load and store images in PNG,Bitmap, Jpeg, Radiance, Tiff and Gif images.
package inspection-testing

GHC plugin to do inspection testing Some carefully crafted libraries make promises to their users beyond functionality and performance. Examples are: Fusion libraries promise intermediate data structures to be eliminated. Generic programming libraries promise that the generic implementation is identical to the hand-written one. Some libraries may promise allocation-free or branch-free code. Conventionally, the modus operandi in all these cases is that the library author manually inspects the (intermediate or final) code produced by the compiler. This is not only tedious, but makes it very likely that some change, either in the library itself or the surrounding eco-system, breaks the library’s promised without anyone noticing. This package provides a disciplined way of specifying such properties, and have them checked by the compiler. This way, this checking can be part of the ususal development cycle and regressions caught early. See the documentation in Test.Inspection or the project webpage for more examples and more information.

Page 16 of many | Previous | Next