add test-coverage.sh

[jonlawlor]

fixes #10

[jonlawlor]

PTAL @kortschak

[kortschak]

LGTM

Thank you.

[jonlawlor]

You're welcome!

I noticed that the coverage and build status flair are for any branch instead of just the master branch. Do you want me to change them?

Also, the repo description "quad implements a set of quadrature routines for the Go language" is a little redundant. Wouldn't something like "Quadrature routines for the Go Language" be better?

[kortschak]

I noticed that the coverage and build status flair are for any branch instead of just the master branch. Do you want me to change them?

I think so.

Also, the repo description "quad implements a set of quadrature routines for the Go language" is a little redundant. Wouldn't something like "Quadrature routines for the Go Language" be better?

@btracey ?

[btracey]

The source package documentation is "Package quad provides numerical evaluation of definite integrals of single-variable functions.". I could change the repo documentation to that.

This seems like a decent place to bring something up on the sly. Right now, if one searches on google for "golang stats" we're not even on the first three pages of results. I may be overproud, but I think we have a decent set of functions. Is there a classy way for us to do some search engine optimization and add "golang" somewhere to help the keywords?

[jonlawlor]

Personally I like the style used by gonum/matrix: "Matrix packages for the go language" and I would drop the "Package quad provides" to leave it just "Numerical evaluation of definite integrals of single-variable functions [for the go language]"

Regarding golang stats, there is an unfortunate collision with the unrelated os.File stat. I don't think putting golang in the description would make a difference. If we want it to show up higher in search results then I think a good approach would be to make a few blog posts on how to do statistics in go (using gonum...) and then link to it on reddit and go-nuts. That isn't SEO, it is just making it more relevant to people, and then the rankings will hopefully work themselves out.

So, uh... how about a gonum.github.io blog?

[sbinet]

+1 for a gonum.github.io/blog

[kortschak]

@jonlawlor Any idea why coveralls is either being very slow or failing to perform the coverage analysis when the tests have been run (not just this repo)?

[jonlawlor]

Coveralls takes about the same amount of time to run as go -test, so there can be a bit of a delay (for example, in gonum/matrix it takes ~20s, roughly the same as go -test). I think that if a branch is merged while the coverage is running then it will produce an error in the build status on github. Is there a more egregious case that I am missing?

[kortschak]

I think it's just very long delays. I had a look through and all the ones that were pending for ~15-30min are now done.

[jonlawlor]

That is more likely to be on the travis side. The worst delays are going to come from the blas and lapack packages, where we need to use the old non-container based infrastructure on travis and have to build the OpenBLAS library every time. If we can switch from using the OpenBLAS master branch to using an Ubuntu package then it would be much faster. The last time I checked the OpenBLAS package on the Ubuntu version they used was a bit out of date and some of our tests failed because of problems on the OpenBLAS end. However, travis has a new Ubunty "Trusty" build environment which might work.