When one thread fails, concurrently_ cancels the other thread; this
raises AsyncCancelled in that thread.
We don't want this behaviour. One thread should not have to handle the
exceptions from other thread.
Just use forkIO for getting back to reasonable behaviour. In future I
might want to manage these threads in a saner manner.
- Introduced `forEvery` to run a Shake action over a pattern of files when they change.
- Removed `buildHtmlMulti` (use `forEvery` with `buildHtml` instead)
Just have the user pass around one of the pandoc reader
functions (re-exported in Rib.Parser.Pandoc) directly instead of having
to know to use a custom wrapper type.
buildHtml was incorrectly named; it should have actually been called
writeHtml. This commit also actually implements buildHtml, which is like
buildHtmlMulti but operating on a single file.
During the initial full generation we are not handing exceptions from
Shake (which can happen due to parser errors from user code). This
change handles it.
Useful in user code when wanting to read a single source file, as
opposed to a pattern of them. The other difference to buildHtmlMulti is
that readSource merely parses the source, but does not write HTML of it.
Example:
```haskell
blurb <- Rib.readSource MMark.parse [relfile|fragments/index.md|] >>= \case
Left e -> fail $ toString e
Right v -> pure v
```
This will allow us to do Shake-y things in our readers. For example,
parsing our Dhall files may require `need`'ing its dependent .dhall
files, doing which ensures that when those files change rib will
re-generate our site accordingly.
Code example:
```haskell
parseIO :: FromDhall a => Path b File -> Action (Either Text a)
parseIO (toFilePath -> f) = do
inputDir <- ribInputDir
let dhallDeps =
[ [relfile|Entry.dhall|],
[relfile|Metric.dhall|]
]
need $ fmap (toFilePath . (inputDir </>)) dhallDeps
s <- toText <$> readFile' f
e <-
liftIO $ withCurrentDirectory (toFilePath inputDir) $
input auto s
pure $ Right e
```
