[Digital Asset](https://www.digitalasset.com). Daml is an open-source smart contract language for building future-proof distributed applications on a safe, privacy-aware runtime. The SDK is a set of tools to help you develop applications based on Daml.
* This is a *multi-user installation* (there is no single-user installation option for macOS). Because of this, you need to configure `/etc/nix/nix.conf` to use Nix caches:
1. Add yourself as a nix trusted user by running `echo "extra-trusted-users = $USER" | sudo tee -a /etc/nix/nix.conf`
2. Restart the `nix-daemon` by running `sudo launchctl stop org.nixos.nix-daemon && sudo launchctl start org.nixos.nix-daemon`
2. Enter `dev-env` by running: `eval "$(dev-env/bin/dade assist)"`
If you don't want to enter `dev-env` manually each time using `eval "$(dev-env/bin/dade assist)"`,
you can also install [direnv](https://direnv.net). This repo already provides a `.envrc`
file, with an option to add more in a `.envrc.private` file.
Note that after a macOS update it can appear as if Nix is not installed. This is because macOS updates can modify shell config files in `/etc`, which the multi-user installation of Nix modifies as well. A workaround for this problem is to add the following to your shell config file in your `$HOME` directory:
```
# Nix
if [ -e '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh' ]; then
We have a single script to build most targets and run the tests. On Linux and Mac run `./build.sh`. On Windows run `.\build.ps1`. Note that these scripts may take over an hour the first time.
To just build do `bazel build //...`, and to just test do `bazel test //...`. To read more about Bazel and how to use it, see [the Bazel site](https://bazel.build).
On Mac if building is causing trouble complaining about missing nix packages, you can try first running `nix-build -A tools -A cached nix` repeatedly until it completes without error.
On Linux and Mac run `daml-sdk-head` which installs a version of the SDK with version number `0.0.0`. Set the `version:` field in any Daml project to 0.0.0 and it will use the locally installed one.
On macOS at least, it looks like our setup does not always properly close the
resources PostgreSQL uses. After a number of test runs, you may encounter an
error message along the lines of:
```
FATAL: could not create shared memory segment: No space left on device
DETAIL: Failed system call was shmget(key=5432001, size=56, 03600).
HINT: This error does *not* mean that you have run out of disk space. It occurs either if all available shared memory IDs have been taken, in which case you need to raise the SHMMNI parameter in your kernel, or because the system's overall limit for shared memory has been reached.
The PostgreSQL documentation contains more information about shared memory configuration.
child process exited with exit code 1
```
In this case, this is a memory leak, so increasing `SHMNI` (or `SHMALL` etc.)
as suggested will only delay the issue. You can look at the existing shared
memory segments on your system by running `ipcs -mcopt`; this will print a line
per segment, indicating the process ID of the last process to connect to the
segment as well as the last access time and the number of currently connected
processes.
If you identify segments with no connected processes, and you are confident you
can remove them, you can do so with `ipcrm $sid`, where `$sid` is the process
ID displayed (as the second column) by `ipcs`. Not many macOS applications use
shared memory segments; **if you have verified that all the existing memory
segments on your machine need to be deleted**, e.g. because they have all been
created by PostgreSQL instances that are no longer running, here is a Bash
invocation you can use to remove all shared memory segments from your system.
**This is a dangerous command. Make sure you understand what it does before
running it.**
```
for shmid in $(ipcs -m | sed 1,3d | awk '{print $2}' | sed '$d'); do ipcrm -m $shmid; done
