For installation instructions, see the INSTALL file.
HaskellDB is a Haskell library for expressing database queries and
operations in a type safe and declarative way. HaskellDB compiles a
relational algebra-like syntax into SQL, submits the operations to the
database for processing, and returns the results as ordinary Haskell
values.
HaskellDB is written entirely in Haskell and works under both the
Glasgow Haskell Compiler (GHC) and the Hugs Haskell interpreter. The
library is designed to to support multiple database backends.
Currently supported database backends are:
* HSQL (http://htoolkit.sourceforge.net/). HSQL's bindings to ODBC, MySQL,
PostgreSQL and SQLite are currently supported.
* wxHaskell (http://wxhaskell.sourceforge.net/)
HaskellDB is intended to be platform independent. It should be
possible to use HaskellDB on any platform that has a supported Haskell
implementation and that is supported by the database backend.
HaskellDB was originally written by Daan Leijen and its design is
described in the paper Domain Specific Embedded Compilers, Daan Leijen
and Erik Meijer. 2nd USENIX Conference on Domain-Specific Languages
(DSL), Austin, USA, October 1999. That version of HaskellDB was
published in 1999 and has been available from
http://www.haskell.org/haskellDB/ since then.
The original version implements the entire HaskellDB combinator
library, but has some practical drawbacks. It requires certain
extensions (most notably the typed records extensions) which, in the
form that are used by HaskellDB, are only available in antiquated
versions of the Hugs interpreter. Furthermore, the original HaskellDB
only supports a Windows-specific ADO-based database backend.
The new version of HaskellDB was produced as a student project at
Chalmers University of Technology in Gothenburg, Sweden. The aim of the
project was to make HaskellDB a practically useful database library.
"Stable Hackage"（: creating a vetted set of packages from Hackage. This repository is for package authors and maintainers to get their packages into Stackage. If you simply want to use Stackage as an end user, please follow the instructions on https://www.stackage.org/.
We strongly recommend using the Haskell tool stack for doing builds, which includes built-in Stackage support: stack.
NOTE: There is an approximate 30 minute delay between a package uploading to Hackage and being available to the Travis build script to check upper bounds. If a pull request is marked as failed due to using an older version, please close and reopen the PR to retrigger a Travis build.
Other repos
The Stackage project consists of multiple repositories. This repository contains the metadata on packages to be included in future builds and some project information. In addition, we have the following repositories:
Generally, building the package set should be done only by the Stackage build machine by the Stackage curation team. If you're interested in trying this yourself, please check out the curator guide, though be aware that this is not a recommended practice and there likely will be problems you will need to debug yourself.
Docker
Note: This method has been disabled for now, but may be enabled again in the future.
If you'd like to check a build plan, or perform an entire build, without specially configuring your system, Docker may be a good approach. To check if some modifications to build-constraints.yaml are valid, try the following:
Create a local clone of the stackage repo
Make modifications to your local build-constraints.yaml
Inside the stackage working directory, run the following:
I have discovered after writing this article that Circle CI
has better built-in support for Haskell than Travis CI does. In
particular Circle will cache cabal build artifacts for you automatically
between builds. I’d recommend using Circle for all your Haskell
projects.
“Static sites are fast, secure, easy to deploy, and manageable using version control.” So states the webpage for Hakyll,
a great way to set up a static site or blog. It allows you to write
blog posts by simply editing markdown in git, all the while having
access to delicious Haskell for deeper customizations.
You can configure things to let you write blog posts directly on
Github’s interface and use Travis CI to deploy your changes. Most
day-to-day blogging will not require using Haskell at all or even having
the Haskell environment installed on the blogger’s machine.
I’ll show you how to set everything up, including an optimized Travis
config that can deploy changes in less than a minute. There is some
existing information online about doing this sort of thing, but it’s all
outdated in one way or another.
We’ll be using Github Pages to serve the final assets. I’ll assume you’re making a static site for a Github organization called myorg and want it to live at myorg.io.
Installation
Create a Github organization. E.g. myorg
Create a project myorg/myorg.github.io
The master branch will be repeatedly overwritten and committed later
on by Travis, so you won’t make any edits there directly. For now add a
file to the root of the master branch called CNAME containing the string myorg.io
Create two A records in the DNS for myorg.io pointing at 192.30.252.153 and 192.30.252.154 respectively.
Generate the base Hakyll project.
# in an empty directory of your choice# NOT in the git repo you've been usingcabal sandbox init
cabal install -j --disable-documentation hakyll
cabal exec hakyll-init myorg.github.io
Create an orphan source branch in your git repo and copy the generated files there.
Watch the deploy progress at https://travis-ci.org/myorg/myorg.github.io
Now you can create and edit blog posts right in Github and your changes get deployed automatically.
(optional) Generating a custom cabal sandbox for Travis
You can use my shared cabal sandbox
on Travis as done above, or you can build your own. It’s a little
trickier. Use this Travis config as a start. It takes advantage of
post-build deployment to S3.
$ travis login
We need your GitHub login to identify you.
This information will not be sent to Travis CI, only to api.github.com.
The password will not be displayed.
Try running with --github-token or --auto if you don't want to enter your password anyway.Username: xxx@xxx.xxxPassword for xxx@xxx.xxx: ***Successfully logged in as demo!
PHPWarning: require(/home/travis/build/stephencode/super-admin/bootstrap/../vendor/autoload.php): failed to open stream: No such file or directory in /home/travis/build/stephencode/super-admin/bootstrap/autoload.php on line 17
一看是自己项目的 composer 依赖包的 autoload.php 文件没找到，那应该是没有执行 composer up 之类的操作，结合网上找的资料，比较好的解决方式是在 install 层添加一行：
$ travis login
We need your GitHub login to identify you.
This information will not be sent to Travis CI, onlyto api.github.com.
The password will not be displayed.
Try runningwith--github-token or --auto if you don't want to enter your password anyway.
Username: xxx@xxx.xxx
Password for xxx@xxx.xxx: ***
Successfully logged inas demo!
$ travis encrypt-file ~/.ssh/id_rsa --add
Detected repository as xxx/xxx, isthis correct? |yes| yes
encrypting ~/.ssh/id_rsa for xxx/xxx
storing result as id_rsa.enc
storing secure env variables for decryption
Make sure to add id_rsa.enc to the git repository.
Make sure not to add ~/.ssh/id_rsa to the git repository.
Commit all changes to your .travis.yml.
在项目的 
