41161aa390
* Rewriting Dhall.LSP.Backend.Dhall: Implement new API The old "backend" consisted of a random collection of ways to invoke Dhall: - runDhall :: FilePath -> Text -> IO (Expr Src X) - runDhallSafe :: FilePath -> Text -> IO (Maybe (Expr Src X)) - loadDhallExprSafe :: FilePath -> Text -> IO (Maybe (Expr Src X)) The new backend exposes a slightly more though-out API. This also lays the foundation for performance improvements in the dhall lsp server via caching. * Reorder code in Dhall.LSP.Backend.Dhall * Remove unused constructor * Rewrite and document Backend.Formatting * Refactor Dhall.LSP.Backend.Linting * Refactor Dhall.LSP.Backend.ToJSON * Adapt Diagnostics backend to the new Dhall API * Remove old Dhall backend API * Implement caching; revamp LSP frontend This commit implements caching of Dhall expressions: we only need to fetch, typecheck and normalise each import once per session, unless they change! This means that `dhall-lsp-server` is now viable for non-trivial Dhall projects, for example probing around in `dhall-nethack` everything feels near-instantaneous once the imports have been resolved. This implementation currently has a bug: we don't invalidate imports transitively, i.e. if A.dhall loads B.dhall and B.dhall changes we do not discard the cached version of A.dhall. This should be reasonably easy to fix given some time with Dhall's import graph. Furthermore, there is some cleaning up left to do: - Fix warnings - Reorganise things in a less ad-hoc way - Make the code a bit prettier * Fix caching of errors * Use `bimap` instead of `first` and `second` * Re-export `Dhall.lint` rather than aliasing Rids us of some boilderplate * Use MVar instead of TVar for server state The main benefit is that we get to use `modifyMVar_` which does updating of the shared state for us (and gracefully handles any uncaught exceptions). * Don't invalidate hashed imports Fixes a misinterpretation on my end of the correct behaviour regarding the caching of imports. Quoting @Gabriel439: > A hashed import is valid indefinitely once it is successfully > resolved, even when the underlying import later becomes broken. That's > why missing sha256:… works so long as the cache has that import cached > (and this behavior is part of the standard). * Cleanup Dhall.LSP.Backend.Dhall a little bit * Add note about fixing cache invalidation * Use TemplateHaskell to generate state lenses * Make types of `typeAt` and `annotateLet` more expressive Both assume the input to be well-typed; by using `WellTyped` rather than `Expr Src X` as the type of their input we can make this explicit. This change exposed a bug (also fixed in this commit) in the type-on-hover functionality: we run `typeAt` only if the input was well-typed _the last time we checked it_ (which was at the last save); this means that if the code changed without being written to disk we would happily try to normalise (in `typeAt`) non-well-typed code... * Fix type of typecheck Typecheck returned the well-typed _type_ of a given expression, while I was assuming it would certify the input to be well-typed. Silly indeed. * Remove `checkDhall` from Dhall.Backend.Diagnostics Removes the left-over stub from the change to the new Dhall backend. * Update comments and remove TODO note * Remove superfluous parentheses * Simplify MonadState code via lens combinators * Use `guard` instead of matching on True * Remove more superfluous parentheses |
||
---|---|---|
dhall | ||
dhall-bash | ||
dhall-json | ||
dhall-lsp-server | ||
dhall-nix | ||
dhall-text | ||
dhall-try | ||
nix | ||
.gitignore | ||
.gitmodules | ||
.travis.yml | ||
appveyor.yml | ||
cabal.project | ||
default.nix | ||
LICENSE | ||
README.md | ||
release.nix | ||
shell.nix | ||
stack-lts-6.yaml | ||
stack-lts-12.yaml | ||
stack.yaml |
dhall-haskell
You will probably want to read the language-agnostic README
here:
This repository focuses on the Haskell bindings to Dhall and contains the following packages:
dhall
-dhall-bash
-dhall-json
-dhall-nix
-dhall-text
-
Navigate to each package's directory for their respective README
s
Pre-built binaries
You can download pre-built binaries for Windows and Linux on the release page:
For OS X, use brew
to install the desired package. For example:
$ brew install dhall-json
You can also install pre-built Linux binaries for master
using Nix using
Nix's channel mechanism by following the instructions at this link:
To install the Nix build products without a channel, configure your machine to
use cache.dhall-lang.org
, as described in the nix section and then
visit one of the following links:
- https://hydra.dhall-lang.org/job/dhall-haskell/master/linux-dhall/latest
- https://hydra.dhall-lang.org/job/dhall-haskell/master/linux-dhall-bash/latest
- https://hydra.dhall-lang.org/job/dhall-haskell/master/linux-dhall-json/latest
- https://hydra.dhall-lang.org/job/dhall-haskell/master/linux-dhall-nix/latest
- https://hydra.dhall-lang.org/job/dhall-haskell/master/linux-dhall-lsp-server/latest
- https://hydra.dhall-lang.org/job/dhall-haskell/master/linux-dhall-text/latest
You can then click the "Help" button in the bottom right corner, which will
show you a nix-env
command that you can run to install the prebuilt
executable.
If you have the jq
command-line tool installed then you can do this in one
command by running:
$ nix-env -i "$(curl -L https://hydra.dhall-lang.org/job/dhall-haskell/master/linux-dhall/latest/api/get-info | jq -r .outPath)"
These instructions also work for any pull request, too, by replacing master
with the pull request number for any of the above URLs.
Pre-built containers
Prebuilt containers for the latest release available from Docker Hub:
... but if you want to obtain containers for bleeding-edge builds, you can download image archives for each package using the following URLs:
- https://hydra.dhall-lang.org/job/dhall-haskell/master/image-dhall/latest/download/1/docker-image-dhall.tar.gz
- https://hydra.dhall-lang.org/job/dhall-haskell/master/image-dhall-bash/latest/download/1/docker-image-dhall-bash.tar.gz
- https://hydra.dhall-lang.org/job/dhall-haskell/master/image-dhall-json/latest/download/1/docker-image-dhall-json.tar.gz
- https://hydra.dhall-lang.org/job/dhall-haskell/master/image-dhall-lsp-server/latest/download/1/docker-image-dhall-lsp-server.tar.gz
- https://hydra.dhall-lang.org/job/dhall-haskell/master/image-dhall-nix/latest/download/1/docker-image-dhall-nix.tar.gz
- https://hydra.dhall-lang.org/job/dhall-haskell/master/image-dhall-text/latest/download/1/docker-image-dhall-text.tar.gz
You can then load and run one of these archives like so:
$ NAME="dhall"
$ curl --location --remote-name "https://hydra.dhall-lang.org/job/dhall-haskell/master/image-${NAME}/latest/download/1/docker-image-${NAME}.tar.gz"
$ docker load < "docker-image-${NAME}.tar.gz"
...
Loaded image: dhall:vx95jiijmp2i07f5ynl8h6sllf34jggz
$ docker run -i dhall:vx95jiijmp2i07f5ynl8h6sllf34jggz dhall <<< '2 + 2'
4
These instructions also work for any pull request, too, by replacing master
with the pull request number for any of the above URLs.
Building from source
For all of the following instructions, make sure to first check out the
dhall-lang
submodule:
$ git submodule init
$ git submodule update
cabal
You can build all of the packages by running:
$ cabal new-build all
And each of them with cabal new-build <package-name>
, for example:
$ cabal new-build dhall
... or you can run cabal new-build
within each package directory.
nix
You will probably want to use the shared cache hosted at cache.dhall-lang.org
when doing Nix development. This is not required, but this will save you a lot
of time so that you don't have to build as many dependencies from scratch the
first time.
If your operating system is NixOS then you can add the cache using these NixOS configuration options to access dhall packages from your declarative configuration file:
nix = {
binaryCaches = [ "https://cache.nixos.org" "https://cache.dhall-lang.org" ];
binaryCachePublicKeys = [
"cache.dhall-lang.org:I9/H18WHd60olG5GsIjolp7CtepSgJmM2CsO813VTmM="
];
};
If you want to install these packages imperatively using nix-env
,
regardless of whether you use NixOS, set the following options in your
/etc/nix/nix.conf
file.
Using Nix 2.0 or later:
trusted-public-keys = cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY= cache.dhall-lang.org:I9/H18WHd60olG5GsIjolp7CtepSgJmM2CsO813VTmM=
substituters = https://cache.nixos.org https://cache.dhall-lang.org
Using earlier Nix versions (i.e. Nix 1.*
):
binary-cache-public-keys = cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY= cache.dhall-lang.org:I9/H18WHd60olG5GsIjolp7CtepSgJmM2CsO813VTmM=
binary-caches = https://cache.nixos.org https://cache.dhall-lang.org
You can build all of the packages by running:
$ nix-build
... or you can run nix-build
within each package's respective directory to
build just that one package.
You can install all of the packages by running:
$ nix-env --install --file default.nix
... or you can run the same command within each package's respective directory to install just that one package.
If you prefer installing the binaries locally in a nix shell environment instead, just run nix-shell
in the top-level directory.
This option provides additional flexibility with respect to overriding some of the default parameters e.g. the compiler version, which makes it particularly useful for developers.
You can develop any package by navigating to that package's directory and running:
$ nix-shell
[nix-shell]$ cabal configure
[nix-shell]$ cabal build
[nix-shell]$ cabal test
... or you can add nix: True
to your ~/.cabal/config
file and then you can
run the same cabal
commands without an explicit nix-shell
:
$ cabal configure
$ cabal build
$ cabal test
stack
You can build all of the packages with
$ stack build
And each of them with stack build <package-name>
, for example:
$ stack build dhall-json
Profiling
Say you want to profile the dhall-to-json
executable.
Build the containing package with profiling options:
$ stack build --profile --library-profiling dhall-json
Run the executable on your input. For example:
$ stack exec --profile --rts-options -p -- dhall-to-json <<< 'True && False'
This generates a dhall-to-json.prof
file in your current directory.
Build the website
Building the website from source is currently only supported for Nix on Linux.
You can build the static assets by running:
$ nix-build --attr website
... then open ./result/index.html
in your browser.
You can also download an archive containing the pre-built website from CI using this link:
Contributing
Read the following guide if you would like to contribute: