* queryContractId and queryContractKey, trivially
* add changelog
CHANGELOG_BEGIN
- [Triggers] Two new functions are available for querying the ACS:
``queryContractId``, for looking up a contract by ID, and ``queryContractKey``
for looking one up by key.
See `issue #7726 <https://github.com/digital-asset/daml/pull/7726>`__.
CHANGELOG_END
* more efficient, direct queryContractId implementation
* flip getContractById's arguments, avoid 'flip'
* test queryContractKey
* test queryContractId
* dev-env: Add a symlink, `dev-env/jdk`, to the current JDK.
This makes configuring IntelliJ IDEA to use the correct JDK much easier.
CHANGELOG_BEGIN
CHANGELOG_END
* dev-env: Document setting up the JDK in IntelliJ IDEA.
GitHub requests that when we use the API without a token, which is what
we do here, we use a user-agent header that allows them to contact us in
case there is an issue they need to discuss. This PR updates that
address, and cleans-up a bit of duplication around it.
CHANGELOG_BEGIN
CHANGELOG_END
This is pretty much a verbatim copy of
https://github.com/digital-asset/daml/pull/7740, but for updates of
structural records instead of projections.
This has no immediate performance impacts since the DAML compiler does
_currently_ not produce any structural record updates. Having both,
projections and updates, have the same runtime characteristics seems to
be a desirable property nevertheless, simply to avoid nasty surprises
should we ever start to use these updates.
Since the compiler does not produce any structural record updates, I
have no way to benchmark this. However, since the code is changed here
in the same way it was changed in the PR mentioned above, I expect the
same saving, which were roughly 80 ns per operation, where the previous
cost of an operation was _at most_ 210 ns.
CHANGELOG_BEGIN
CHANGELOG_END
* resources: Move builders into //ledger/ledger-resources.
Keep the actual constructors in a trait, but instantiate it when working
with ledger code.
This allows us to later introduce an extra "context" type parameter to
ResourceOwner.
* resources-akka: Move the builders in to //ledger/ledger-resources.
* resources: Introduce an abstract `Context` parameter for owners.
This replaces the concrete `ExecutionContext`. While it _can_ be an
execution context, it really doesn't matter as long as we can get at one
somehow.
This is being introduced so we can wrap the context in a container,
either for type tagging or to include extra information.
Because our current context _is_ `ExecutionContext`, and an implicit is
provided to extract it, we can end up with two ways to get the same
value. We use shadowing to prevent this. This problem should go away in
the near future when a new context type is added.
CHANGELOG_BEGIN
- [Integration Kit] The `ResourceOwner` type is now parameterized by a
`Context`, which is filled in by the corresponding `Context` class in
the _ledger-resources_ dependency. This allows us to pass extra
information through resource acquisition.
CHANGELOG_END
* ledger-resources: Move `ResourceOwner` here from `resources`.
* ledger-resources: Remove dependencies from outside //ledger.
* ledger-resource: Wrap the acquisition execution context in `Context`.
So we can add a logging context to it.
* resources: Pass the Context, not the ExecutionContext, to Resource.
* Avoid importing `HasExecutionContext`.
* ledger-resources: Publish to Maven Central.
* resources: Make the small changes suggested by @stefanobaghino-da.
Co-Authored-By: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* ledger-resources: Pull out a trait for test resource contexts.
Saves a few lines of code.
* Restore some imports that were accidentally wildcarded.
* resources: Replace an `implicit def` with a couple of imports.
* participant-integration-api: Simplify the JdbcLedgerDaoBackend tests.
Try and use the right execution context where possible.
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Speed up projections of structural records
Currently, for every projection of a structural record, we first do a
linear search through the field names to find the index of the field
value in the record value. Then we use this index to get the actual
value. However, since we started sorting the fields in alphabetic order
both in types and in values, this lookup will always yield the same
result for a fixed record type and a fixed field name, regardless of the
value of the record.
This PR changes the AST node for structural record projection to
contain the index of the field within the record as well. This
information is not contained in the DAML-LF archive itself and must
hence be filled in by the DAML-LF type checker.
The only context in which we use structural record prejections are
typeclass method invocations, which do a little bit more than just the
projection. Unfortunately, typeclass method invocations are the small
unit of work I can benchmark using the setup I have. In the end, they
are also the feature our users really care about.
My benchmarks show that the time a single typeclass method invocation
takes has dropped from ca. 210ns to ca. 130ns. That's a speedup of
ca. 1.6x.
CHANGELOG_BEGIN
[DAML Interpreter] Typeclass method invocation is now 1.6x faster.
CHANGELOG_END
* Apply Remy's suggestions
Co-authored-by: Remy <remy.haemmerle@daml.com>
* Make it compile again
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Remy <remy.haemmerle@daml.com>
PR #7732 illustrated a bug in our current changelog check: it only worked
if the PR was up-to-date with `master` at the time of pushing. This was
not the intention. Fortunately, the fix is fairly easy: check out the PR
commit before running the check, rather than run it from the merge
commit (as Azure does by default).
CHANGELOG_BEGIN
CHANGELOG_END
* Functional dependency support in data-dependencies
(WIP)
* Add test.
changelog_begin
- [DAML Compiler] Functional dependencies are now saved
by the DAML compiler in the DALF file / DAR package. When
importing a file with the functional dependency data via
data-dependencies, these will be picked up automatically.
changelog_end
* Move CallStack, HasCallStack docs to DA.Stack
This PR only modifies the docs. In particular, it:
- moves the `CallStack` and `HasCallStack` docs to `DA.Stack`
- gives an example of adding the `HasCallStack` constraint
- hides the rest of `GHC.Stack.Types` from the docs
Rationale: `GHC.Stack.Types` has a lot of `TextLit` stuff that
we don't want people to use directly, and we want people to
import `DA.Stack` instead anyway.
changelog_begin
changelog_end
* commit unsaved changes, doh
* grammar
Updating the expected dignostics for `damlc`'s integration tests can
be quite tedious. This PR adds a `sed` script to simplify it a bit.
See the included readme for details.
CHANGELOG_BEGIN
CHANGELOG_END
Haskell allows for promoting types to the kind level with the
`DataKinds` extension. Since DAML-LF has no similar concept (and
frankly speaking should't have one), this does not work well with
data-dependencies. Unfortunately, we need to enable the `DataKinds`
extension by default in `damlc` since our record system and the
`Numeric` type depend on it. Thus, issuing a warning that the
`DataKinds` is not supported with data-dependencies is not an option
and we need more refined warnings.
Most uses of promoted kinds won't even compile to DAML-LF and there's
no need to warn about those since they cause hard failures. However,
we need some limited support for type-level strings and the `Symbol`
kind, for type-level numbers and the `Nat` kind, as well as for some
stuff from `DA.Generics`. Type-level numbers and the `Nat` kind work
reasonable well since we have them in DAML-LF too. The `Symbol` kind,
and the types and kinds from `DA.Generics` are "erased" during
conversion to DAML-LF by replacing them with either a special `Erased`
type or the star kind. Thus, these entities are not restored properly
with data-dependencies. In combination with type classes this leads
easily to instances that for different types in the original code but
are at conflict during interface reconstruction. Long story short,
erased types/kinds and type classes don't work with data-dependencies.
We have a hack to somehow preserve type-level string since we need that
for our record system and the `HasField` type class. I have no desire
to support this hack for arbitrary type classes coming from the user.
Thus, I consider type-level strings to be erased as well here.
This PR adds a warning whenever a user is attempting to define a type
class that involves a kind that will be erased or an instance that
involves a type that will be erased. The warning tells the user that
this does not work with data-dependencies and is hence not upgradable.
There is one caveat: the `HasField` instances produced by the
propressor fall in the category we should warn about as well. Since not
supporting them would make our record system unusable, we need to give
them special treatment in data-dependencies. Thus, warning about them
would be unjustified noise and we explicitly exclude them in the code
producing the warnings.
CHANGELOG_BEGIN
[DAML Compiler] Issue warning when advanced types are with type classes
in a way that is supported by data-dependencies.
CHANGELOG_END
Stop emitting warnings about un-upgradability when our users use the
`InstanceSigs` or `MultiWayIf` extensions. These are safe.
Also don't issue warnings for `Cpp`, which can only be used internally.
CHANGELOG_BEGIN
[DAML Compiler] Add `InstanceSigs` and `MultiWayIf` to the list of
language extensions that don't cause problems with data-dependencies.
CHANGELOG_END
* Authorize trigger service on middleware
changelog_begin
changelog_end
* Trigger service auth callback handler
* Forward token
* Do not pin the application ID in the access token
The trigger service will assign an individual application ID to each
trigger based on its UUID. Requiring tokens on the granularity of
application IDs would break the idea of storing the token in a cookie to
be able to use it across multiple requests.
changelog_begin
changelog_end
* todo persist trigger token
* Add a state parameter to middleware login
* add documentation comments
* typo
* fmt
* Align Party type between middleware and trigger service
The middleware was using `com.daml.lf.data.Ref.Party` while the trigger
service is using `com.daml.ledger.api.refinements.ApiTypes.Party` which
requires conversions. This aligns the types to avoid such conversions.
* optional application id in oauth2 test server
* align party types
* configure auth middleware in trigger service tests
* handle empty cookie header
* follow redirects in trigger service tests
* keep track of cookies
* keep track of cookies
* Replace any previous Cookie header
Otherwise on old daml-ledger-token cookie might persist and be preferred
over a newly added instance.
* DEBUG
* Configure test ledger client readAs claims
* fmt
* docstrings
* remove debug output
* Avoid endless redirect loops
When the replay still fails to authorize on the middleware then we do
not want to attempt another login flow.
* Store callback routes in authCallbacks
* fmt
* Push AuthTestConfig into test target
https://github.com/digital-asset/daml/pull/7654#discussion_r506510193
* Unbind oauth2 server after middleware
https://github.com/digital-asset/daml/pull/7654/files#r506513251
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
daml-sdk-head: add optional sha information
This PR add an option, `--sha`, to `daml-sdk-head` so that it produces a
more accurate version number including the current git sha.
The main consequence is that calling `daml-sdk-head --sha` take
significantly longer than calling `daml-sdk-head`, because it needs to
recompile everything that depends on the version number.
> ## Wait, but why??
I started this work in support of an internal project that needed to
test against unreleased, and possibly unmerged, daml versions. However,
after further discussion I believe there is a better option for their
use-case. I've decided to still open this PR because the work was done
and there is no downside to it. It may still be useful if one wanted to
be able to maintain more than one non-released local version of daml.
CHANGELOG_BEGIN
CHANGELOG_END
* set doobie version to 0.9.2 and rerun maven pin
* port extractor and some of JSON API
* repin maven
* use doobie's own builder compatibility where required
* use probably bad derivations to supply Blockers where transactEC was required
- The point of using Blocker instead of ExecutionContext seems to be to
especially emphasize to API users that it isn't appropriate to use an
ExecutionContext with ordinary behavior. That is what we have done, which
should probably change, but just compiling for now.
* fix fragment inspection test for internal restructuring
- This test depends on implementation details of Doobie, so naturally it must be
altered when that runs. Fortunately, it's been made easier by the changes
in this upgrade.
* allow 256 blockers for navigator transaction blocker, like the global EC
* allow as many blockers as the pool size for trigger service
- The transactor shouldn't share ExecutionContext for transactions with the
caller, so we set up a new one based on configured pool size.
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
Removed ad hoc usages of UUID in ledger-api-test-tool for id generation for commands and keys.
This change should facilitate debugging.
CHANGELOG_BEGIN
CHANGELOG_END
There are two reasons for this:
1. 2018 was a long time ago and there seems to be no particular reason
for sticking to that version.
2. We have seen a bunch of issues where we get 404s when fetching msys
packages. The newer version has a larger mirrorlist which might help
with this. We could in principle try to patch the mirrorlist for
the old version but given that upgrading seems like a good idea
anyway, this seems easier.
changelog_begin
changelog_end
* Warn when importing DA.Generics
The module `DA.Generics` is hidden from the docs of `daml-stdlib`
because we consider it experimental. On top of that, the comments at the
top of the module make it clear that this module does _not_ work across
different SDK versions. Nevertheless, let's make it crystal clear that
`DA.Generics` does not work with data-dependencies and will stop you
from upgrading your package.
I've decided against using the a `{-# WARNING ... #-}` annotation
on the `DA.Generics` module declaration since that issues a warning for
every single time an enitity from the module is used rather than once
when importing the module. To me, that's a bit over the top since it is
conceivable that people still want to use the module during some stages
of their development. Another thing we might need to consider soon is a
`-fno-data-dependencies-warnings` flag which suppresses warning related
to data-dependencies. This would be impossible with a
`{-# WARNING ... #-}` annotation.
CHANGELOG_BEGIN
[DAML Stdlib] Issue a warning when importing the `DA.Generics` module,
which does not work with data-dependencies.
CHANGELOG_END
* Fix typo
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Unfortunately, diagnostics use 0-based ranges internally but render
them 1-based when showing them to users. This has caused a lot of
confusion in the `damlc` integration tests because we communicate
with our own devs in a mixture of the user facing 1-based format and
the 0-based internal format. On top of that, we had a bug where the
column numbers were off by 1.
Let's put this to an end and display all ranges in the 1-based format
meant for humans. To make sure our parser and renderers for ranges
are in sync, and not again off by 1, we also add a couple of tests to
check that they roundtrip.
CHANGELOG_BEGIN
CHANGELOG_END
The new version of `ghcide` fixes a bug in the pretty printer for
diagnostics. So far, the column number for an error/warning you would
be shown by `daml build` was always be one smaller than in DAML
Studio. Now, we show the same locations across the command line tools
and the IDE.
We also bring our test files in sync with the ranges the command line
tools print now.
CHANGELOG_BEGIN
[DAML Compiler] Show the correct column numbers in error locations
produced by command line tools like `daml build`.
CHANGELOG_END
* Warn on potentially un-upgradable language extensions
We issue a warning whenever a module is compiled with a language
extension enabled for which we are not certain that it works with
data-dependencies. Currently, we consider all extensions except for
the ones enables by default, `ApplicativeDo` and
`PartialTypeSignatures` problematic in this regard. The list of
extensions that work fine with data-dependencies might extend over
time but we need to do further research and add further tests before we
add any extensions.
The warning is always put at the location of the module name regardless
of where the `{-# LANGUAGE ... #-}` pragma is actually used. This is due
to the fact that the `ParsedModule` we get from GHC does not contain
the location information of these pragmas. We should probably improve
this over time but I think it is acceptable for now.
CHANGELOG_BEGIN
[DAML Compiler] Warn when a module uses a language extension that
might not work with data-dependencies.
CHANGELOG_END
* Make the warning less polite :)
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Bump the version of ghcide we use
The new version gives access to the `ParsedModule` instead of only the
`ParsedSource` in the preprocessor. See
https://github.com/digital-asset/daml-ghcide/pull/3
for details.
We also need to fix a few things in `bazel-haskell-deps.bzl` to reflect
that we use our fork of `ghcide`, which lives in
`digital-asset/daml-ghcide`, instead of the old
`digital-asset/ghcide`, which we handed ove to the community, now.
CHANGELOG_BEGIN
CHANGELOG_END
* Update to use fixed ghcide version
CHANGELOG_BEGIN
CHANGELOG_END
* Add functional dependency metadata in LF.
This PR adds a new value definition during LF conversion, for type classes with functional dependencies. The binding is a representation of the functional dependency, so we can later pick it up in data-dependencies.
For example, given a typeclass `Foo a b c` with the functional dependency `a -> b, c -> a b` will give rise to a new value definition `$fdFoo` (`$$fdFoo` after name mangling) of type:
```
forall (a : *) (b : *) (c : *).
{ _1: {_1: a} -> {_1: b}
, _2: {_1: c} -> {_1: a, _2: b}
}
```
where the `{ ... }` are LF structs. This is a simple encoding of the underlying representations for functional dependencies (which is `[([TyVar], [TyVar])]`).
The PR also adds a test to make sure the functional dependency metadata is exposed, and handles kinds other than kind star correctly. The use of this metadata in data-dependencies is left to a separate PR.
changelog_begin
changelog_end
* Add comment
This fixes a bug in the Speedy interpreter. With this change, the
interpreter crashes if it attempts to fetch using a contract key that
has an empty set of maintainers. This propagates to exerciseByKey as
this command is compiled using fetchByKey speedy built-in.
This is a breaking change approved by @bame-da .
CHANGELOG_BEGIN
[LF] (Bug fix) enforce non-empty maintainers in contract key during fetchByKey and exericiseByKey.
CHANGELOG_END
This PR allows the script to run without GCP credentials. It will
obviously then skip the bits that require GCP credentials, but that
still leaves it with plenty of things to do.
Because checking all releases can still be quite long (around an hour on
CI, and my personal connection is a bit slower), this also introduces a
new parameter that restricts the number of releases to test.
CHANGELOG_BEGIN
CHANGELOG_END
* @daml/types: Improve Unit type
tl;dr: If we ever want to fix the `Query<T>` type from `@daml/ledger`,
we need a better definition of `Unit`.
TypeScript's type system may not be particularly sound, but the type
`{}` still sticks out as being a very special mess. I _think_ it is
something along the lines of
```typescript
type {} = Exclude<object, null> | string | number | boolean;
```
It is definitely not the type of all records or the type of only the
empty record.
I think it is reasonable to expect that the type relation defined by
```typescrupt
type Equiv<T, U> = T extends U ? U extends T ? true : false : false;
```
is extensional equality of types. Unfortunately, it isn't. For
instance, we have
```typescript
Equiv<{}, {[key: string]: string}> == true
```
but the value `{x: 1}` is assignable to type `{}` but not to type
`{[key: string]: string}`.
The type defined by the interface
```typescript
interface Unit {}
```
is a similarly hot mess as the type `{}`. Although they might seem to
be the same, particularly since we have
```typescript
Equiv<{}, Unit> == true and Equiv<Unit, {}> == true
```
here's a way to tell them apart:
```typescript
Equiv<Unit, {[key: string]: string}> == false
```
Thus, I would say the `Unit` type is mildly saner than the `{}` type.
Why does this matter? If we ever want to fix the query `Query<T>` type,
we need to be able to tell the unit type and `TextMap<_>` apart on the
type level. As demonstrated above, this seems impossible if we use `{}`
as the unit type but it is possible if we use the `Unit` type defined
above as the unit type.
Since I couldn't find a single value that is assignable to only one of
`{}` and `Unit` but not the other, this change should not break
anything at all. That said, I'll refrain from a changelog entry.
CHANGELOG_BEGIN
CHANGELOG_END
* Make eslint happy
CHANGELOG_BEGIN
CHANGELOG_END
* Spell out bazel directories in .gitignore
With the old `/bazel-*` pattern in there, `rg` also ignores files like
`bazel-haskell-deps.bzl`, which is quite inconvenient.
I obtained the list of what should be hidden by uncommenting the
`/bazel-*` line and adding evering `git status` showed as new files.
Thus, the list is hopefully complete.
We have a similar issue with `/compatibility/bazel-haskell-deps.bzl`.
Since I could figure out what exactly we want to ignore there, I just
added an un-ignore for that single file.
CHANGELOG_BEGIN
CHANGELOG_END
* Go with the unignore approach everywhere
CHANGELOG_BEGIN
CHANGELOG_END
This PR shuffles things around a bit to make it easier to test and
adds `--query-store-jdbc-config-env` which specifies the name of an
environment variable containing the jdbc URL. The UX for this is
modeled after #7660.
Added a test for the different formats.
fixes#7667
changelog_begin
- [JSON API] The JDBC url can now also be specified via
`--query-store-jdbc-config-env` which reads it from the given
environment variable.
changelog_end
@robin-da is taking care of 1.7.0-snapshot.20201013.5418.0.bda13392 (#7676), so they get pushed back to the end of the line.
Please do not merge this before #7676.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* allow updating user state from high-level trigger rule
* fix tests and examples for new rule signature
* fix doc for new rule signature
* add changelog
CHANGELOG_BEGIN
- [Triggers] ``rule`` can now ``get`` and ``put`` the user-defined state just
like ``updateState`` does. It no longer accepts the state as an argument.
You can port your rule function types by replacing ``s -> TriggerA`` with
``TriggerA s``, removing the last argument from the function, and using
``get`` to retrieve the state at the beginning of the ``rule``'s ``do`` block,
if needed.
See `issue #7674 <https://github.com/digital-asset/daml/pull/7674>`__.
CHANGELOG_END
* test that rule userState changes propagate all the way out
* adapt compatibility filtering to #7681
Small comment: This is technically not completely backwards compatible
since it messes with type inference. But to hit that you are doing
something sufficiently advanced that you should be able to add the
type annotation that is required
fixes#7635
changelog_begin
- [DAML Script] `query`, `queryContractId` and `queryContractKey` now
accepts multiple parties using the `IsParties` abstraction used by
`signatory`, `observer` and other fields. They will return all
contracts for which any of the given parties is a stakeholder. Since
`Party` is an instance of `IsParties`, this is fully backwards
compatible.
changelog_end
