logo
首页技术栈工具库讨论
virthualenv
virthualenv
virthualenv is a tool (inspired by Python's virtualenv) to create isolated Haskell environments. virthualenv is deprecated, please use the hsenv tool. It creates a sandboxed environment in a .virthualenv/ directory, which, when activated, allows you to use regular Haskell tools (ghc, ghci, ghc-pkg, cabal) to manage your Haskell code and environment. It's possible to create an environment, that uses different GHC version than your currently installed. virthualenv is supposed to be easier to learn (and use) than similar packages (like cabal-dev or capri). Basic usage. First, choose a directory where you want to keep your sandboxed Haskell environment, usually a good choice is a directory containing your cabalized project (if you want to work on a few projects (perhaps an app and its dependent library), just choose any of them, it doesn't really matter). Enter that directory: Next, create your new isolated Haskell environment (this is a one time only (per environment) step): Now, every time you want to use this enviroment, you have to activate it: That's it! Now it's possible to use all regular Haskell tools like usual, but it won't affect your globalsystem's Haskell environment, and also your per-user environment (from ~.cabal and ~/.ghc) will stay the same. All cabal-installed packages will be private to this environment, and also the external environments (global and user) will not affect it (this environment will only inherit very basic packages - mostly ghc and Cabal and their deps). When you're done working with this environment, enter command deactivate, or just close the current shell (with exit). Advanced usage. The only advanced usage is using different GHC version. This can be useful to test your code against different GHC version (even against nightly builds). First, download binary distribution of GHC for your platform (e.g. ghc-7.0.4-i386-unknown-linux.tar.bz2), then create a new environment using that GHC Then, proceed (with [de]activation) as in basic case. Misc. virthualenv has been tested on i386 Linux systems, but it should work on any Posix platform. External (from tarball) GHC feature requires binary GHC distribution compiled for your platform, that can be extracted with tar and installed with "./configure --prefix=PATH; make install". For more info please consult "virthualenv --help" or the attached README file.
posix-api
posix-api
This library provides a very thin wrapper around POSIX APIs. It can be compiled on any operating system that implements the standard as specified in IEEE Std 1003.1 faithfully. It has similar goals as the unix package, but its design differs in several areas: ByteArray and Addr are used pervasively. There is no use of String in this library. Functions do not throw errors. This library uses `IO (Either Errno a)` in places where unix would use `IO a`. The numeric types from Foreign.C.Types and System.Posix.Types are used in the type signatures of functions so that a haskell function's type signature matches its underlying POSIX equivalent exactly. Flags are newtypes over CInt (or whatever integral type matches the posix specification) rather than enumerations. The data constructors are exported, making the types extensible for operating system that have additional flags. About a dozen other packages offers wrappers for some subset of the POSIX specification are strewn across hackage. They include regex-posix, posix-paths, posix-timer, posix-socket, posix-filelock, posix-acl, etc. This library differs from all off these in various ways. Here are some of the design guidelines followed here that distinguish this package from some or all of these others: Scope. Although this library does not include all APIs specified by POSIX, it welcomes as many of them as anyone is willing to implement. Monomorphization. Effectful functions in this library return their results in IO rather than using a type that involves MonadIO or MonadBaseControl. Typeclass avoidance. This library does not introduce new typeclasses. Overloading is eschewed in favor of providing multiple functions with distinct names. Minimality. Functions wrapping the POSIX APIs do little more than wrap the underlying functions. The major deviation here is that, when applicable, the wrappers allocate buffers are the underlying functions fill. This eschews C's characteristic buffer-passing in favor of the Haskell convention of allocating internally and returning. A more minor deviation is that for safe FFI calls, this library will perform additional work to ensure that only pinned byte arrays are handed over. Unlike network, this sockets API in this library does not integrate sockets with GHC's event manager. This is geared toward an audience that understands how to use threadWaitRead and threadWaitWrite with unsafe FFI calls to avoid blocking the runtime.