Docstring updates, guide improvements.

[cpfiffer]

Adds some meager docstrings for the distributions we have, and tacks them onto the API page. I've also changed the name from Library to API for the page that shows off our docstrings.

It doesn't really seem like the docs are being built automatically -- @KDr2 do you know what's up with that?

[KDr2]

Hi @cpfiffer, the document will only be automatically built on the master branch or on a commit tagged with a v* tag (see https://github.com/TuringLang/Turing.jl/blob/master/.travis.yml#L112). After the building, the docs will be pushed to the gh-pages branch.

Only allowing master-branch or release tag building could prevent docs in a not-yet-approved commit being published. If you want to preview the update, you can build it on the local machine by run julia ./docs/make.jl, then start a simple web server which treats the docs directory as its root dir:

$cd docs
$ python -mSimpleHTTPServer
Serving HTTP on 0.0.0.0 port 8000 ...

The point the browser to http://localhost:8080/dev/ to preview the updates.

After the docs being merged into the master branch, it will be automatically built and published.

[KDr2]

The CI job is triggered, but there's an error. I will check it ASAP.
https://travis-ci.org/TuringLang/Turing.jl/jobs/590813375

[trappmartin]

It doesn't seem that the update of the webpage actually worked, e.g. Library is still called Library instead of API as changed by Cameron through this PR. I suppose something went wrong.

[trappmartin]

Side question: Why do we need DynamicHMC to build the docs? This seem strange to me.

[trappmartin]

For reference:

Turing.jl/.travis.yml

Line 116 in 4dbb817

- julia -e 'using Pkg; Pkg.add("Documenter"), Pkg.add("DocumenterMarkdown"), Pkg.add("DynamicHMC")'

and

Turing.jl/docs/make.jl

Line 1 in 4dbb817

using Documenter, DocumenterMarkdown, DynamicHMC, Turing

[cpfiffer]

Side question: Why do we need DynamicHMC to build the docs? This seem strange to me.

We require DynamicHMC in order to show the docstring on the website, because we dynamically load our DynamicHMC code if someone has called using DynamicHMC. If we don't include them, the docstring never shows up and will actually throw an error.

[trappmartin]

Which docstring requires this? Would it make sense to get rid of it? It feels wrong that our documentation build depends on DynamicHMC. But maybe thats just me.

[cpfiffer]

Well, ignore me, I guess. I was referring to this docstring

Turing.jl/src/contrib/inference/dynamichmc.jl

Line 9 in 4dbb817

DynamicNUTS()

but we don't appear to be exporting it to the website, so the documentation build step probably doesn't need to include DynamicHMC. Unless we want to export the docstring.