logo
首页技术栈工具库讨论
auto
auto
(Up to date documentation is maintained at https://mstksg.github.com/auto) Read the README first! https://github.com/mstksg/auto/blob/master/README.md , for motivating examples, and concrete explanations of things described here. auto is a Haskell DSL and platform providing declarative, compositional, denotative semantics for discrete-step, locally stateful, interactive programs, games, and automations, with implicitly derived serialization. It is suited for any domain where either the input or the output can be described as a stream of values: a stream of input events, output views, etc. auto works by providing a type that encapsulates value stream transformers, or locally stateful functions; by specifying your program as a (potentially cyclic) graph of relationships between value streams, you create a way of declaring a system based simply on static relationships between quantities. Instead of a state monad type solution, where all functions have access to a rigid global state, auto works by specifying relationships which each exist independently and on their own, without any global state. A more fuller exposition is in the README.md, in this project directory and also online at https://github.com/mstksg/auto/blob/master/README.md; you can get started by reading the tutorial, which is also in this project directory in the tutorial directory, and also incidentally online at https://github.com/mstksg/auto/blob/master/tutorial/tutorial.md. Also, check out the auto-examples repository on github for plenty of real-world and toy examples to learn from; I've also done a blog series on this library, with examples and full tutorials! Support available on freenode's #haskell-auto, #haskell-game, and also on the github issue tracker for the source repository. Import Control.Auto to begin!
cabal-constraints
cabal-constraints
Repeatable builds for cabalized Haskell projects 'cabal-constraints' provides repeatable builds for cabalized Haskell projects by "freezing" the exact versions of the dependencies selected by 'cabal-install'. All build environments for the project, such as the test or staging build environments, or other developers collaborating on the project, will then use the same dependency versions. It is designed to be used alongside 'cabal-install' sandboxes, in which case isolated, repeatable builds can be achieved. Using cabal-constraints 'cabal-constraints' should be run from the root directory of a cabalized Haskell project and given the path to the setup-config file to use. It will print out all dependencies of the project in a format suitable for use in a cabal-install config file. For example, running 'cabal-constraints' against itself produces the following: A single mandatory argument must be provided which is the path to the setup-config file to use. The file will be located under the dist directory. Usually there will be a single setup-config file which can be found by running find dist -name setup-config from the root directory of the project. If your project has more than one such file, it is likely because you have built it either with and without sandboxes or with multiple sandboxes. You probably want the most recently modified file which can be found with ls -tr $( find dist -name setup-config ) | tail -n1. To use these constraints for reproducible builds, one should make use of the new sandbox feature of cabal-install 1.18. The constraints can be redirected to cabal.config and committed to your code repository. When the project is built, the same set of dependency versions will be resolved by cabal-install ensuring repeatable builds. If cabal.config contains no other information the simplest solution is to overwrite it: If cabal.config contains information that needs to be preserved, the following will replace the constraints section and everything following it with the new constraints. If you ensure that the constraints section is the last section of the file, all other information in it will be kept.