`cabal` seems to want to download a newer c2hs than what is available on path at
the current nixpkgs pin, and I haven't been able to figure out how to force it
to do otherwise (open to suggestions).
For now, we just cabal slurp it from Hackage rather than using the nixpkgs
version. /shrug
This is to prepare for an upcoming release to Hackage. I increased the
version to 0.1.0 to reflect what I believe is a breaking change in #117
(since `grpc-haskell` will now require a newer version of the C `grpc`
dependency).
35163c3 introduced a new use of `mask` which makes the server
process uninterruptible while waiting for a new incoming request.
This change fixes that by surrounding the logic that waits for a
new request with `unmask`. This new `unmask` should still
respect the finalization guarantees of the surrounding masked
code.
A bunch of files have been missing from the tarballs created by `cabal
sdist`. I’ve changed the nix config to check for this and also found
some examples that I forgot to update in a previous PR (sorry about
that).
Previously, grpc-haskell used a lot of code in the form of
```
do x <- acquireResource
f x `finally` releaseResource x
```
This is not safe since you can get killed after acquiring the resource
but before installing the exception handler via `finally`. We have
seen various gRPC assertion errors and crashes on shutdown when this
got triggered.
Note that even though we can now build grpc-haskell and grpc-haskell-core
with modern tasty, the environment in which we built those test programs
did not support actually running all them successfully, due to the need to test
generated code in the context of the appropriate libraries. We do not yet
know whether test programs built with new versions of tasty would succeed
in the appropriate environment. In principle this could be discovered, but
the work involved is far from trivial, and therefore we defer it to another
time. Tests built with the old tasty still succeed.
It was not obvious from the type how many times the
final field of ClientReaderRequest would be invoked.
(Assuming it is invoked once per stream increment
results in a hang, which can be confusing.)
* Fix the output of the nixpkgs derivation
* Use the fixed-output sha256 hash for builtins.fetchTarball
This change makes the nixpkgs pin forwards compatible with Nix 1.12.x
and Nix 2.0.
* Correct the phrasing of the code comment
