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 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 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 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 updates all of the `README`s to:
* centralize all of the build/install/develop information in the
top-level `README`
* get the nested `README`s to use a consistent style
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`.
Fixes https://github.com/dhall-lang/dhall-haskell/issues/645
Fixes https://github.com/dhall-lang/dhall-lang/issues/216
This updates the `README` with the following changes:
* Points to the language-agnostic `README` in the `dhall-lang` repository
* Retains only Haskell-specific sections of interest
* Removes the embedded LICENSE now that GitHub auto-recognizes the project
license (#644)
* Changes the Quick Start instructions to use Nix
* Adds instructions for project development using Nix
The latter two points entailed refactors to the Nix logic to simplify the
user experience:
* `default.nix` was moved to `shared.nix` and replaced with a new `default.nix`
that works out-of-the-box with `nix-build`
* There is a new `nix/test-dhall.nix` which users can use to create a
`nix-shell` with Dhall as a dependency