* SandboxSQL fixture + fixing various issues
WIP - playing around with Resources to support Sandbox Fixture with Postgres
Sandbox with Postgres fixture works - LedgerIdentityServiceGivenIT PASSES
adding guards for empty collections in PostgresLedgerDao
CommandCompletionServiceITi passed for both fixtures
fixing EventID formatting problem
another formatting fix
changed wrong autoCommit behaviour
CommandStaticTimeIT passed on both ledgers
rolling back transaction on duplicates
dealing with duplicate commands in postgres
fixing mismapped record_time
adding extra logging for fatal errors
disabling sql support as it's not finished yet
cleanup
removed unnecessary test classes
cleanup
formatting
* ADT was missing Product with Serializable
* fixed the compilation error
* Attempt to move template to rst
* Removing pandoc from export
* Get rst tables working
* Move proto comments into rst format
* More tidying up proto docs to work in rst
* Remove unnecessary whitespace
* Add back some necessary whitespace
* Correcting rst whitespace, again
* Remove processing script
* Clean up proto files
* Remove broken link from pdf toc
* Reinstate post-process script
* Try to fix process script
* Fix permissions issue
I'm moving the sentence to follow the instructions of the installer
output to a separate bullet, so that it is a bit harder to miss this
quite important point.
* HOTFIX damlc: allow for passing options to the underlying GHC
As `damlc` is based on GHC, it "understands" all options that GHC understands.
This PR introduces a way to use GHC options that are not exposed by the `damlc`
driver, by passing any number of `--ghc-option CUSTOM_OPTION` on the command line.
The code uses the GHC function which parses options inside files, so
prohibiting a few options that we would not want to expose (package db, output
file, etc).
All warnings that GHC emits during flag processing are presented to the user.
If an option contradicts a DAML compiler setting, the compilation will be
aborted with a GHC exception (calls makeDynFlagsConsistent internally).
* HOTFIX damlc: small clean-up
* Use global SDK version for release tarballs.
* Use semver for sdk versions.
* Update daml-assistant/BUILD.bazel
* Code comments pt 1
* Switch to lens
* Update daml-assistant/BUILD.bazel
Finishes the work started in #324:
- drops deprecated `name` in identifiers, adopting `moduleName` and `entityName`
- use string to represent `timestamp`s to avoid a loss of precision
- use string for `date`s too for consistency and future-proofness
The work unconvered a quite serious bug caused by the lack of coverage
on the validation of timestamps: the model was expecting timestamps to
be of type timestamp, whereas in Ledger API values they are represented
by numbers.
* Inline all aliasing let bindings generated during conversion to DAML-LF
Inlining the aliases generated for record wildcards is a prerequisite for
the maintainer clauses of our contract keys syntax to work.
Inlining all other aliases doesn't seem to be a bad idea as well.
* Address Neil's comments
* nix: add the more providers to terraform
* docs: make tarballs more reproducible
* ci: use the linux-pool pool
* ci: tweak the nix installation
handle the case where the user is root and on ubuntu
* infra: terraform fmt
* infra: add Azure Pipeline agents
* ci: only enable linux-pool for internal PRs
Currently, the logic for when to inline let bindings is duplicated in two
places. This PR centralizes it in one place. It is also a preparation for
doing more of this inlining, which is a prerequisite for our intended
surface syntax for contract key maintainers to work properly.
* Allow for record wildcards in key expression
Right now, instances of `TemplateKey` must define `key` to be something like
```
key this = ...
```
With this change, we can also write
```
key Foo{..} = ...
```
and even
```
key this@Foo{..} = ...
```
This is required for the desugaring of the surface syntax for contract keys.
* Clean up
* Add filepath as a dependency of proto3-suite
* Make path splitting work on Windows
* Add directory as a dependency
* Avoid generating new files each time with proto-buf
* Add the libraries to Bazel too
* Implement legacy DAR support, #308
if MANIFEST.MF is not present filter zip entries by .dalf extension,
expect one main DALF and one optional *-prim* DALF, fail in other cases
* Implement legacy DAR support, #308
if MANIFEST.MF is not present filter zip entries by .dalf extension,
expect one main DALF and one optional *-prim* DALF, fail in other cases
* comments, naming
* Fetch status.proto from remote, simplify JS gRPC codegen
Fetch the `status.proto` file (part of the standard gRPC distribution)
from a distribution channel. _Moreover_, use the recently introduced
`proto_gen` rule to simplify how the gRPC code for the Node.js bindings
are generated (and remove the need to have `google/rpc/status.proto`
locally in the repository.
* Add plugin_runfiles option to proto_gen
This allows use to add additional files to the bazel sandbox so that
plugins can refer to them. This will subsequently be used by the
protoc-gen-doc plugin.
Also, pass the plugin options via --name_opt parameter.
* Add missing status.proto dependency /language-support/java and /ledger
* Build proto docs using the proto_gen rule
To make this work, I had to turn on the bazel build flag
`--protocopt=--include_source_info` because we cannot turn enable this
flag only for specific build rules.
* Make /ledger-api/grpc-definitions:docs public again
* Revert to the old style of passing plugin arguments to --name_out=options:path
* Suppress output of unzipping
* Fix link for google.rpc.Status in proto-docs
* Change contract key maintainers to have template argument in scope
More precisely, change the contract key type class we desugar the surface
syntax to such that the maintainers function has the template argument
in scope instead of the key. The compiler rewrites all references to the
template argument into references to the key and fails whenever that is
not possible.
* Add TemplateKey class to desugaring module
* Make template key check slightly more lenient
* Fix TODO descriptions
