* Attempt at fixing missing root certificate, #1491https://github.com/dhall-lang/dhall-haskell/issues/1491
* Remove extra comma in shared.nix
Co-Authored-By: Simon Jakobi <simon.jakobi@gmail.com>
* Update nix/shared.nix
Co-Authored-By: Gabriel Gonzalez <Gabriel439@gmail.com>
The "builtins.fetchTarball" function is not available in some restricted
environments such as build jobs of the latest Hydra. Make it possible to
pass nixpkgs and nixpkgsStaticLinux when evaulating default.nix and
release.nix to avoid importing them internally. This does not change the
result of evaulation if no parameters are passed.
This updates the `dhall` package to have 100% haddock coverage and
also updates CI to enforce this going forward.
This also includes a change to deprecate the `X` type synonym, which
I noticed along the way
Note that `dhall-nix` cannot be built on Windows due to its transitive
dependency on the `unix` package.
Also:
* Nix: Enable `-Werror` for `dhall-nix`
* Add support for `toMap` in `dhall-nix`:
\(x : { a : Bool }) -> toMap x
is translated as
x:
(kvs:
map (k:
{
mapKey = k;
mapValue = builtins.getAttr k kvs;
}) (builtins.attrNames kvs)) x
* Allow customization of remote import resolution
Makes the `Status` type more general; previously support for
`Network.HTTP.Client` was hardcoded. In short:
```
data Status = Status
{ _stack :: NonEmpty Chained
[...]
-- , _manager :: Maybe Dynamic
-- -- importing the same expression twice with different values
++ , _remote :: URL -> StateT Status IO Data.Text.Text
++ -- ^ The remote resolver, fetches the content at the given URL.
[...]
}
```
* Simplify and expose `toHeaders`
`toHeaders` will be needed for mock http testing
* Fix compilation without `with-http` flag
* Fix compilation with `with-http` flag
* Fix tests without `with-http` flag
Implements a mock http client that handles requests to:
- `https://raw.githubusercontent.com/dhall-lang/dhall-lang/master/`
- `https://test.dhall-lang.org/Bool/package.dhall`
- `https://httpbin.org/user-agent`
This allows tests involving remote imports to succeed even when compiled
without the `with-http` flag.
* Build `dhall` with HTTP support compiled out in CI
... to prevent regressions from occurring in the future
Since we only want to ensure that the benchmarks continue to
work, we use the following benchmark arguments to run them
as quickly as possible:
- `--quick` ensures that gauge runs only a single sample.
- `--min-duration=0` sets the number of iterations per sample to 1.
- `--include-first-iter` causes gauge to accept that one iteration
instead of discarding it and running a second one.
This also removes the dhall-command benchmark:
This was a non-standard benchmark that failed when run
without input from stdin. To replace this profiling tool,
I have added instructions for profiling the main executables
to the README.
This adds a new `Dhall.Test.Util.discover` utility for auto-generating
a `TestTree` from a directory tree. This simplifies keeping up to date
with changes to the standard test suite.
This no longer tests dependencies, mainly to lower my maintenance burden. In
particular, this makes it easier for me to test bumping dependencies for
Stackage-related bounds changes.
These aren't fully static executables (they still have some
`/nix/store` references), but they at least compile Haskell dependencies
statically. That means that they can be `nix-env --install`ed side-by-side
with other Haskell executables, which would otherwise conflict with an
error like this one:
```
error: packages '/nix/store/hrxnlwlsiw5jjjkq5v6ihcwb0shx4fga-dhall-1.20.1/lib/li
nks/libHSbasement-0.0.8-8QjArDsw3GWCcbHE5iqtz3-ghc8.4.3.dylib' and '/nix/store/d
2y5373anwf1q3h86ar3lljk11k1lq0h-dhall-json-1.2.6/lib/links/libHSbasement-0.0.8-8
QjArDsw3GWCcbHE5iqtz3-ghc8.4.3.dylib' have the same priority 5; use 'nix-env --s
et-flag priority NUMBER INSTALLED_PKGNAME' to change the priority of one of the
conflicting packages (0 being the highest priority)
```
A refactor of the Nix build accidentally removed the `-Werror` flag, which
caused some warnings to get past CI. This change fixes that and removes the
warnings.
This adds four new sections to the page after the live demo which highlight
the common themes that I notice people use when communicating the value of
Dhall to others on social media:
* The first section emphasizes the element of delight in using the language for
people who are into elegance and quality
* The second section focuses on more pragmatic people who are sick of YAML and
just want a reasonable alternative that they can convince their manager to
adopt
* The third section appeals to the LangSec crowd that wants an uncompromising
and secure foundation for what they are buliding
* The last section targeted at the skeptic who thinks that Dhall is an ivory
tower language not suited for real-world problems.
The second crowd (YAML emigrants) is the audience that I'm targeting the
most strongly at the moment, but I didn't want to lead with a negative reason
adopt by focusing on the limitations of YAML, so I put the section on delight
first so that we could start with a more positive tone.
This moves the type annotation into a separate tab, both to avoid
the type cluttering the default output tab and to allow a display
mode that focuses on highlighting just the type.
This also adds a "YAML" output tab to gently suggest to the user
that Dhall is intended to be an alternative to YAML. Unfortunately,
we can't use the Haskell `yaml` package to render to YAML when
building with GHCJS, but we can still perform the JSON-to-YAML
conversion in JavaScript.
This expands the "Try dhall" page to serve as a functional home page for
"dhall-lang.org" in the short term by making the following changes:
* Adding a navigation bar to the top that links to useful resources and
official integrations
* Adding a quick summary explaining what Dhall is
This change sthe layout to a side-by-side split-pane output
and also adds tabs for each pane:
* Tabs for the left pane let you switch between examples
* Tabs for the right pane let you switch between output modes
This adds three new Nix build products:
* `try-dhall-static` - The static assets for "Try Dhall"
* `try-dhall-server` - A script which serves the static assets for local
debugging
* `tarball-try-dhall` - A tarball of the static assets
This is powered by a new small `dhall-try` package which is also included
in this change.
This adds a GHCJS build for Dhall so that:
* We can build a `try.dhall-lang.org` to try Dhall in the
browser until the PureScript implementation comes online
* We can document how to build `dhall` using GHCJS
* We can verify that new changes to `dhall` or its dependencies
don't break GHCJS support
* CI can build and cache GHCJS-related dependencies
This simplifies mass disabling of tests or jailbreaking of packages,
typically in order to test builds against latest versions of
dependencies for Stackage.
This ensures that all of the `dhall-*` libraries build against
GHC 8.6.1, but still generates tarballs using GHC 8.4.3 and
uses GHC 8.4.3 for development
The motivation for this change is:
* To catch build failures in downstream packages whenever we make a breaking
change to the `dhall` API
* To reduce the amount of work I need in order to cut a release for all of
these packages
* To better share Nix/CI-related logic between the projects
Note that I have not yet migrated `dhall-nix` in. I'm waiting for
https://github.com/dhall-lang/dhall-nix/issues/17 to be fixed since
`dhall-nix` is incompatible with later versions of `megaparsec` due to
`hnix`.
Simon Jakobi
David Francoeur
Sergei Dolgov
Ehmry -
Gabriel Gonzalez
Patrick Mylund Nielsen
Frederik Ramcke
quasicomputational
antislava
Stephen Paul Weber