* Bump rules_nodejs
rules_nodejs finally added support for module remapping via js_library
so we can kill our custom rule for that.
changelog_begin
changelog_end
* Fix windows
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
This is necessary to at least attempt an upgrade to 2.13 and
generally, I want to keep our rulesets up2date. rules-scala forces the
version of scalatest so we have to bump that at the same time.
This requires changes to basically all Scala test suites since the
import structure has changed and a bunch of things (primarily
scalacheck support) got split out.
Apologies for the giant PR, I don’t see a way to keep it smaller.
changelog_begin
changelog_end
* Add multi-party submissions to the ledger API
CHANGELOG_BEGIN
* [Ledger API] Command submission requests now contain new optional
fields used for multi-party submissions. Such submissions currently
return UNIMPLEMENTED errors, they will be enabled in the future.
CHANGELOG_END
* Adapt Haskell bindings
* Handle the new ledger API fields
* Fix SubmitAndWaitDummyCommand
* Remove unused methods
* Redesign multi-party auth tests
* Remove direct access of request party
* Apply review comments
* Improve protobuf comments
* Multi-party tracker map
* Fix validation logic
* Consistent metric naming
We add the daml-types/daml-ledger libraries as peer-dependencies instead
of dependencies. This will assure that the library is provided by the
importing library and avoid the situation when two different versions of
these libraries are imported by the generated and the user code.
This fixes#8101.
CHANGELOG_BEGIN
CHANGELOG_END
This PR adds coverage for the package management endpoints of the JSON
API.
CHANGELOG_BEGIN
- [JavaScript Client Libraries] The Ledger object (returned by
`useLedger` through the React bindings) has three new methods covering
the package management API: `listPackages` returns a list of all known
packageIDs, `getPackage` returns the binary data of the corresponding
DALF, and `uploadDarFile` takes binary data and uploads it to the
ledger. Note that `uploadDarFile` requires admin access.
CHANGELOG_END
This PR adds TS bindings coverage for the party management methods of
the JSON API.
CHANGELOG_BEGIN
- [JavaScript Client Libraries] The Ledger object (returned by
`useLedger` through the React bindings) has three new methods covering
the Party management API: `getParties` allows users to, based on a
party id (or party ids, as the name suggests) fetch more information
about the party or check for its existence; `listKnownParties` will
return a list of all known parties, and `allocateParty` will allocate
a new party.
CHANGELOG_END
* ledger-api: Use `proto_jars`.
CHANGELOG_BEGIN
- [Ledger API] The Scala JARs containing the gRPC definitions no longer
contain the *.proto files used to generate the ScalaPB-based classes.
CHANGELOG_END
* Create a source JAR for *.proto files in `proto_jars`.
* ledger-api: Publish the protobuf sources as "ledger-api-proto".
CHANGELOG_BEGIN
- [Ledger API] The *.proto files containing the gRPC definitions are now
provided by a new Maven Central artifact, with the group "com.daml"
and the artifact name "ledger-api-proto".
CHANGELOG_END
* release: We don't need the "main-jar" option.
* Bazel: Proto JARs will always have a Maven artifact suffix.
* Bazel: Simplify Protobuf source file TAR and JAR targets.
* Bazel: Extract out Protobuf functions.
* kvutils: Use ScalaPB to generate a Scala JAR for daml_kvutils.proto.
* Bazel: Delete the unused `da_java_binary` rule, and inline `_wrap_rule`.
* Bazel: Factor out Java/Scala protobuf class generation into a helper.
CHANGELOG_BEGIN
CHANGELOG_END
* daml-lf/archive: Use `proto_jars`.
* Bazel: Remove the visibility modifier from `proto_jars`.
It's too confusing. Just make everything public.
* daml-lf/archive: Push protobuf source tarballs into `proto_jars`.
* Bazel: Add comments to the various parts of `proto_jars`.
* daml-assistant: Do unpleasant things with `location` in Bazel.
Addresses security advisory. I upgraded typedoc as well since that
pulls in the older version of highlight.js and I dont like breaking bounds.
changelog_begin
changelog_end
The stream from the JSON API is split into two sections:
1. The unordered section of ACS events.
2. The ordered transaction stream after the live event.
Our assertions assume that we only get 2 but currently we don’t wait
before sending commands so depending on timing, some of the events can
be delivered as part of the ACS section in a different order causing
very confusing assertion failures.
This test fixes this by waiting for the live event indicating the end
of section 1 and thereby forcing everything to come via the ordered
transaction stream.
Verified that this fixes the flakiness with --runs_per_test=50 which
reproduced it fairly reliable before (on CI, never managed to hit it
locally).
changelog_begin
changelog_end
ts/daml-ledger: createAndExercise
Fixes#7966.
CHANGELOG_BEGIN
JavaScript Client Libraries: The Ledger object (defined in daml-ledger,
returned by useLedger in daml-react) now sports an additional method
`createAndExercise`, which lets JS users create a contract and exercise
a choice on it in the same transaction.
CHANGELOG_END
* daml ledger: add a max-inbound-message-size flag for grpc
This new flag allows to set the maximal accepted inbound message size
when using gRPC to interact with a legger.
CHANGELOG_BEGIN
CHANGELOG_END
* added a test
This PR adds encoders to the various types defined in `@daml/types`. The
serde mechanism did not need one so far because all of the types we're
currently exposing map one-to-one to an appropriate (or, I suppose,
tolerable) JS equivalent. This will not be the case anymore with generic
maps, which means that if we want to provide our users with decent types
(I do), we'll need some real encoding/decoding moving forward.
CHANGELOG_BEGIN
CHANGELOG_END
* Haskell: Add hlint rule to suggest foldl' over foldl
`foldl` is lazy in a way that almost never is what you want since it
can cause space leaks without any benefit. `foldl'` does not have this
problem. See https://www.well-typed.com/blog/2014/04/fixing-foldl/ for
more details.
CHANGELOG_BEGIN
CHANGELOG_END
* Fix all existing occurrences of foldl
CHANGELOG_BEGIN
CHANGELOG_END
* Bump timeouts in build-and-lint’s
We’ve seen some timeouts on CI so let’s bump everything to 100ms and
see if that fixes it. If it doesn’t, we can increase those 100ms as well.
changelog_begin
changelog_end
* Fix race on registering open event
changelog_begin
changelog_end
Fixes#7846.
CHANGELOG_BEGIN
- JavaScript Client Libraries: The family of React hooks `useStream*`
was logging every `close` event as an error. However, there are
legitimate cases for the connection to be closed (e.g. the component has
been unmounted). The default behaviour will now be to log only
unexpected disconnects and be silent on deliberate connection closes. The
behaviour can be customized by passing a `onClose` callback; we
strongly recommend passing such a callback to handle connection errors
gracefully.
CHANGELOG_END
* Amend docs to introduce the concept of DAML Connect
CHANGELOG_BEGIN
CHANGELOG_END
* Slightly change how Sandbox is positioned in the app-arch
* Mention integrated drivers in app arch docs
* Lowercase DAML network
This follows up on #7066 and exposes the new underlying multi-key and
multi-query stream functions through the React bindings. Following the
same reasoning as in #7066, we therefore deprecate the existing
functions (with no intention of removing them) as they become redundant.
CHANGELOG_BEGIN
* JavaScript Client Libraries: Updated React bindings to expose the
recent addition of multi-key and multi-query streams in @daml/ledger.
The singular versions are marked as deprecated as they have become
redundant.
The upgrade path for `useStreamQuery` is very straightforward: the
query factory remains optional, but if specified it should return an
array of queries instead of a single query. The array may be empty,
which will return all contracts for that template (similar as not
passing in a query factory). The return values of `useStreamQuery` and
`useStreamQueries` are the same type.
```
useStreamQuery(T) --> useStreamQueries(T)
useStreamQuery(T, () => query, ...) --> useStreamQueries(T, () => [query], ...)
```
The upgrade path for `useStreamFetchByKey` is only slightly more
involved as the return type of `useStreamFetchByKeys` is a new type
called `FetchByKeysResult` instead of the existing `FetchResult`.
`FetchByKeysResult` differs from `FetchResult` in that it contains a
`contracts` field with an array of contracts instead of a singular
`contract` field. (It differs from `QueryResult` in that each element of
the returned array can also be `null`, if there is no corresponding
active contract.) Call sites can be updated as follows:
```
const {loading, contract} = useStreamFetchByKey(T, () => k, ...);
-->
const {loading, contracts} = useStreamFetchByKeys(T, () => [k], ...));
const contract = contracts[0];
```
CHANGELOG_END
* language: `daml ledger` commands against JSON API
This is the first step in offering the JSON API to run `daml ledger`
commands. First, only the `list-parties` command is implemented. The
other `daml ledger` commands will follow in separate PR's.
CHANGELOG_BEGIN
[Assistant] The `daml ledger list-parties` command can now query the
ledger via the HTTP JSON API instead the gRPC API for known parties on
the ledger.
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>
* @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
* add silent_annotations option to da scala bazel functions
* use silent_annotations for several scala targets
* use silencer_plugin instead when the lib isn't used
* use silent_annotations for several more scala targets
* use silencer_lib for strange indirect requirement for running tests
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
* silent_annotations support for scaladoc
* react: let user specify reconnectThreshold
Requested by a user on [the forum].
[the forum]: https://discuss.daml.com/t/usestreamquery-disconnecting/1325
CHANGELOG_BEGIN
* JavaScript Client Libraries: Users of the React wrapper can now
specify the `reconnectThreshold` parameter of the underlying Ledger
through LedgerProps. This adds an optional attribute to the
LedgerProps type, so existing code does not need any change to keep
working as before (i.e. using the default 30s value).
CHANGELOG_END
* add test
As requested on [the forum].
[the forum]:
https://discuss.daml.com/t/usestreamquery-disconnecting/1325
CHANGELOG_BEGIN
* JavaScript Client Libraries: `useStreamQuery` and
`useStreamFetchByKey` now accept an optional `closeHandler` callback,
which will be called if the underlying WebSocket connection fails.
CHANGELOG_END
A user has [asked on the forum] how their application could handle
WebSocket errors. The unfortunate response at the moment is that they
can't: our React bindings will just spit out an error log, and that's
it. The current code seems to just assume the stream will eventually
reconnect, but the underlying stream does stop trying if it fails two
times in a row faster than `reconnectThreshold`.
[asked on the forum]: https://discuss.daml.com/t/usestreamquery-disconnecting/1325
In trying to address this, and with the context of at some point
expanding the React bindings to the multi-{key,query} API, I realized
that, given the current structure of the code, I might end up having to
solve this issue four times, so I decided to first factor out the stream
handling logic in the existing code, and I believe this makes sense as a
separate PR.
I should note, however, that this is _not_ a refactoring: as indicated
by the amended tests, this PR actually changes the behaviour of
`useStreamFetchByKey`. I believe this counts as a bugfix, but welcome
any pointer as to why the behaviours of `useStreamQuery` and
`useStreamFetchByKey` should differ with respect to the `live` event.
CHANGELOG_BEGIN
* JavaScript Client Libraries: fix a bug where the `useStreamFetchByKey`
hook would, in some circumstances, report a "ready" state (i.e.
`loading: false`) even though the underlying connection had not yet been
fully established.
CHANGELOG_END
* Fix Numeric encoding and decoding in Scala bindings
fixes#7474
There are a few issues here:
1. We used toString which produces an exponential notation in some
cases which is not supported by the ledger API.
2. On the other hand, we used BigDecimal.exact for decoding which
isn’t completely wrong but more lax than what the ledger API supports
1 and 2 are fixed by switching to the respective functions in
daml-lf/data
3. The tests in ValueSpec were never executed! The tests are split
into a scala_library and a scala_test_suite and ValueSpec ended up in
the library. I’ve split out the utilities from the actual code.
4. The generator for Numeric produced things that are not valid
numerics (e.g. 92233720368547758070000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
showed up in one test) which now fails with the more strict requirements.
changelog_begin
changelog_end
* Apply suggestions from code review
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
* Address review feedback
changelog_begin
changelog_end
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
With the introduction of the standalone JAR, we cannot rely on the
assistant anymore to pass the default logback config. Users can still
override the logback config with `-Dlogback.configurationFile` if they
need something else but this provides a more sensible default logging
config than seeing a ton of debug logs from netty.
changelog_begin
changelog_end
The notion of `close` on `Stream` seems a bit confused at the moment. As
the code stands (without this PR), if you register a listener for
`'close'` events, you get notified when the underlying WebSocket closes
(even though the stream will then try to open a new one and, if it
manages to reconnect, will keep sending `'change'` events), and you do
not get notified when the stream itself gets closed (by calling
`.close()` on it), because the code in `.close()` removes the listeners
before closing the WebSocket connection, and so also before trying to
send a message to `'close'` listeners. Further, calling `.close()` also
does not seem to work as expected, or at least as I would expect: it
will remove all listeners and close the WebSocket connection, but then
it will immediately open it up again (provided that `reconnectThreshold`
milliseconds have elapsed since the WS was last opened), leaking an open
WebSocket connection.
As part of the same confusion, the current implementation also expects
`'close'` listeners on the stream to receive a WebSocket close event, i.e.
of the form `{code, reason}`.
This PR changes the behaviour such that listeners on the _stream_
`'close'` event:
* do not get notified if the WS connection drops but manages to
reconnect.
* do get notified if the stream closes due to a connection error we
cannot recover from, with a `4001` status code.
* do get notified if the stream is closed by calling the `.close()`
method, with a `4000` status code.
This PR also changes the WS termination logic such that calling the
`.close()` method on the stream actually closes the underlying WebSocket
connection.
CHANGELOG_BEGIN
* JavaScript Client Libraries: fix a bug where, upon closing a stream,
the underlying WebSocket connection may not be properly closed.
CHANGELOG_END
This is an attempt to address #7034 & #7036. Strictly speaking, this
does not match their acceptance criteria, as this only supports multiple
queries, not mixed templates.
Because the two new functions can cover the exact same use cases (and
more) as the existing `streamQuery` and `streamFetchByKey`, the latter
are deprecated. The deprecation cycle I suggest is to deprecate them
immediately by annotating them as such in the documentation (done on
this PR).
That's it. I do not think we ever need to actually remove them, nor to
make them print annoying warnings or anything. There is nothing wrong
with the functions as they stand, they just don't fit in the API
anymore.
We could, at some point, move them to a separate documentation page, or
to the boottm of the existing one, but I feel even removing them from
the documentation is unnecessary.
CHANGELOG_BEGIN
- [JavaScript Client Libraries] Two new methods have been added to
`daml-ledger`: `streamQueries` and `streamFetchByKeys`. They are
similar to the existing singular versions, except they can take
multiple queries and multiple keys, respectively, and return a union
of what the corresponding individual queries/keys would have. Because
these new functions can do everything the existing ones can, we are
deprecating the latter, though there is no plan to remove them.
Upgrade path is straightforward:
```
streamQuery(t); => streamQueries(t, []);
streamQuery(t, undefined); => streamQueries(t, []);
streamQuery(t, q); => streamQueries(t, [q]);
streamFetchByKey(t, k); => streamFetchByKey(t, [k]);
```
There is one caveat, though: `streamFetchByKeys` is a little bit less
lenient in the format in which it expects the key. If your existing
code was conforming to the generated TypeScript code we provide,
everything should keep working, but if you were using plain JS or
bypassing the TS type system, it is possible that you used to
construct keys that will no longer be accepted. The new function
requires all keys to be given in the _output_ format of the JSON API,
which is a little bit more strict than the general JSON <-> LF
conversion rules.
CHANGELOG_END
* ledger-api-client: Add integration tests for the simple stuff.
* sandbox-common: Make `SandboxFixtureWithAuth` a mixin.
This makes it useful with `SandboxNextFixture` as well as
`SandboxFixture`.
Also, add types to non-private fields and methods, and make more fields
protected rather than public.
* ledger-api-client: Add tests to make sure the token is passed through.
CHANGELOG_BEGIN
CHANGELOG_END
* sandbox-common: Tokens are for auth, not auth.
The issue in #6940 has been fixed so in theory this should no longer
fail or at least fail with a different error that we haven’t seen yet
:)
changelog_begin
changelog_end
* Add a useFetch.
CHANGELOG_BEGIN
Add a useFetch hook to the @daml/react bindings for when the user knows
a contractId.
CHANGELOG_END
* Update language-support/ts/daml-react/defaultLedgerContext.ts
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
We allow the `offset` field of a websocket message send in response to a
`streamQuery` request to be `null`. Previously this would cause an
exception to be thrown.
CHANGELOG_BEGIN
CHANGELOG_END
Unfortunately, we still have an error that's cropping up fairly
persistently. While we know what the problem is, until this is fixed,
I'd like to mark the tests as `flaky` to make sure that other builds
aren't held up.
CHANGELOG_BEGIN
CHANGELOG_END
I have to imagine this is a typo: there currently is no way to
unsubscribe from a stream without closing it, as the `off` method we
expose actually redirects to an `on` method internally, which means that
instead of the method no longer being called, it now gets called twice
(or rather, one more time) on each event.
That seems a bit rude.
CHANGELOG_BEGIN
- [JavaScript Client Libraries] Bugfix: calling the `off` method of
event streams returned by `streamQuery` and `streamFetchByKey` now
correctly removes the given listener, rather than adding it again.
CHANGELOG_END
* add -Ywarn-unused to all scalac options
* remove some unused arguments
* remove some unused definitions
* remove some unused variable names
* suppress some unused variable names
* changeExtension doesn't use baseName
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
* work around no plugins in scenario interpreter perf tests
* remove many more unused things
* remove more unused things, restore some used things
* remove more unused things, restore a couple signature mistakes
* missed import
* unused argument
* remove more unused loggingContexts
* some unused code in triggers
* some unused code in sandbox and kvutils
* some unused code in repl-service and daml-script
* some unused code in bindings-rxjava tests
* some unused code in triggers runner
* more comments on silent usages
- suggested by @cocreature; thanks
* fix missing reference in TestCommands
* more unused in triggers
* more unused in sandbox
* more unused in daml-script
* more unused in ledger-client tests
* more unused in triggers
* more unused in kvutils
* more unused in daml-script
* more unused in sandbox
* remove unused in ledger-api-test-tool
* suppress final special case for codegen unused warnings
.../com/daml/sample/mymain/ContractIdNT.scala:24: warning: parameter value ev 0 in method ContractIdNT Value is never used
implicit def `ContractIdNT Value`[a_a1dk](implicit `ev 0`: ` lfdomainapi`.Value[a_a1dk]): ` lfdomainapi`.Value[_root_.com.daml.sample.MyMain.ContractIdNT[a_a1dk]] = {
^
.../com/daml/sample/mymain/ContractIdNT.scala:41: warning: parameter value eva_a1dk in method ContractIdNT LfEncodable is never used
implicit def `ContractIdNT LfEncodable`[a_a1dk](implicit eva_a1dk: ` lfdomainapi`.encoding.LfEncodable[a_a1dk]): ` lfdomainapi`.encoding.LfEncodable[_root_.com.daml.sample.MyMain.ContractIdNT[a_a1dk]] = {
^
* one more unused in daml-script
* special scaladoc rules may need silencer, too
* unused in compatibility/sandbox-migration
* more commas, a different way to `find`
- suggested by @remyhaemmerle-da; thanks
* help Scala codegen output by passing actor along
* don't generate unused ` view` variables
* macroexpansion replaces _ with a variable name; avoid this
* be explicit about scope of generated PackageIDs object, to avoid warning
* remove silent annotations, which aren't used yet
CHANGELOG_BEGIN
CHANGELOG_END
* Factor out tar/gzip reproducibility flags
* use mktgz in package-app
* Bazel managed tar/gzip
* Remove quiet = True
As stated in the comment this is no longer required with Bazel >= 3.0.
* Build package-app as a sh_binary
This way Bazel will manage the runtime dependencies tar, gzip, mktgz,
and patchelf.
package-app.sh changes directory so it needs to make sure that all paths
are absolute and that the runfiles tree/manifest location is forwarded
to programs called by package-app.sh.
* Avoid file path too long errors
* Fix readlink -f on MacOS
* Document abspath
changelog_begin
changelog_end
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* Use Bazel builtin pkg_tar rule
* Use @rules_pkg//:pkg.bzl%pkg_tar
The pkg_tar rule builtin to Bazel has been deprecated.
See https://docs.bazel.build/versions/master/be/pkg.html
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* add -Xlint:doc-detached
- reverts 1feae964e3 from #6798
* attach several scaladocs where they'll actually be included
* no changelog
* attach several more scaladocs where they'll actually be included
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
This fixes 3 issues:
1. Switch the order in which we assign to `$proc` and
`waitOn`. Without this the cleanup will not do anthing if `beforeAll`
fails since the variable has not been assigned. This results in jest
hanging forever until we hit the Bazel timeout.
2. Increase the timeout on `beforeAll` since we occasionally hit this
on CI.
3. Allocate 2 CPUs to reflect the number of resources required by this test.
changelog_begin
changelog_end
We currently use two different mechanisms for breaking loops in the
`Serializable` companion objects generated for each type:
1. Explicit thunks of the form `() => Decoder<A>`, e.g., in the
definition of the `Serializable` interface itself.
2. the `lazyMemo` combinator, e.g. in enum types, `Optional`s and lists.
This is inconsistent and leads to the introduction of more loop
breakers than actually needed.
This PR changes the situation to use the `lazyMemo` combinator as the
only loop breaker. To this end, we change the definition of the
`Serializable` interface and related similar interfaces to use `Decoder`
directly rather than the thunked up version. This is a *breaking change*
of the affected interfaces. However, the libraries `@daml/ledger` and
`@daml/react` are updated accordingly and hence nothing breaks when
using `daml2js` in combination with these libraries. Furthermore, the
exact definition of the decoder types is considered an implementation
detail since we don't want to tie ourselves long-term to the use of the
`json-type-validation` library, which is mostly unmaintained.
Using `lazy` as the only loop breaker effectively pushes all loop
breakers to the top-level and allows for removing those nested more
deeply in types.
This change should not negatively impact the performance of the
decoding process since it only replaces thunks by memoized thunks and
removes a few calls to `lazyMemo` completely. In fact, we should gain
performance since the decoders in the companion objects are now
memoized.
CHANGELOG_BEGIN
CHANGELOG_END
Currently, if you have a record type `T` with a field of type, say,
`Optional S` and you're decoding a list of type `[T]`, then the decoder
for `S` has to be reconstructed for each element of the list. This is
because the `lazy` combinator from the `json-type-validation` does not
memoize the decoder it receives as a thunk.
This PR adds a new combinator `lazyMemo` which behaves like `lazy` but
also memoizes the decoder on its first invocation. All use sites of the
old `lazy` combinator are then replaced with `lazyMemo`.
We could consider upstreaming `lazyMemo` but I'm not sure how much
effort this is given that `json-type-validation` seems to be in
maintenance mode rather than active development.
CHANGELOG_BEGIN
CHANGELOG_END
Not quite sure why this didn’t fail on the PR but now it complains
that the version of @bazel/typescript and rules_nodejs are
incompatible.
changelog_begin
changelog_end
Currently, the decoders for the container types `List` and `TextMap` use
`jtv.lazy` _within_ their container decoders `jtv.array` and `jtv.dict`.
Since `jtv.lazy` does not memoize its result, this has the disadvantage
that the thunk producing the decoder for the element type is invoked
for each element of the container rather than once for the whole
container. This is a potential performance bottleneck.
This PR moves the use of `jtv.lazy` one level further out in oder to
avoid the potential performance issues without adding any further
downsides.
CHANGELOG_BEGIN
CHANGELOG_END
* Extend `daml new` to accept template as an option
The two positional arguments keep confusing users so this PR changes
things to allow the template to be passed via `--template`. Using a
positional argument still works so this is not breaking.
I’ve updated all docs to use the less confusing syntax.
changelog_begin
- [DAML Assistant] You can now use ``daml new project-name
--template=template-name`` instead of ``daml new project-name
template-name``. The old CLI syntax continues to be supported.
changelog_end
* Update docs/source/getting-started/index.rst
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
I think testing that constructing the decoders doesn't loop deserves
its own very targeted test on top of the more intergration style test
we already have.
CHANGELOG_BEGIN
CHANGELOG_END
* daml-on-sql: Pull out a new `Main` object that wraps sandbox-classic.
CHANGELOG_BEGIN
CHANGELOG_END
* daml-on-sql: Fail if a JDBC URL is not provided or not for PostgreSQL.
* sandbox-classic: Rename the conformance test H2 database.
* daml-on-sql + sandbox-classic: Report configuration errors cleanly.
This means letting `ProgramResource` catch the errors, log, and exit.
* daml-on-sql: Change the name logged on startup.
* daml-on-sql: Change the default participant ID.
* sandbox-common: Give the ledger name its own tagged string type.
* sandbox-classic: Generate random ledger IDs using the ledger name.
* daml-on-sql: Remove the banner, replacing it with a blank line.
* daml-on-sql: Enable strong seeding by default.
And weak seeding in the conformance tests.
* sandbox-classic: Move the ledger name to a separate parameter.
It's not really configurable.
* sandbox-classic: Move LedgerName from sandbox-common.
* daml-on-sql: Remove "-participant" from the participant ID.
* daml-on-sql: Use `Name` where possible.
* daml-on-sql: Make the ledger ID mandatory.
* Revert "sandbox-classic: Move LedgerName from sandbox-common."
This reverts commit 0dad1584a7.
* daml-on-sql: Print "DAML-on-SQL" in the CLI help, not "Sandbox".
* daml-on-sql + sandbox + sandbox-classic: Split out custom CLI parsing. (#6846)
* participant-state: Simplify naming the seeding modes.
The examples and the comment are hopefully obvious enough. Builtin
types can also produce terminating recursion so we need to make them
lazy.
changelog_begin
- [@daml/daml-types library] Fix an issue where some recursive types
resulted in a stackoverflow.
changelog_end
This PR bumps the akka request timeout in the JSON API which we hit
occasionally in the tests which leads to a 503 error
and the tests timing out.
In addition to bumping the timeout, I’ve also changed the logback file
of the JSON API so we don’t get tons and tons of netty debugging
output and updated the token format since the JSON API warns about the
outdated one.
changelog_begin
changelog_end
* sandbox-common: Move the ledgerIdMode up in the configuration.
* sandbox-classic: Move the configuration from sandbox-common.
CHANGELOG_BEGIN
CHANGELOG_END
* Fix miscellaneous warnings caught by IntelliJ IDEA.
* set many extra scalac -Xlint options for all Scala projects
CHANGELOG_BEGIN
CHANGELOG_END
* move NoCopy to its own file
package.scala:18: warning: it is not recommended to define classes/objects inside of package objects.
If possible, define trait NoCopy in package data instead.
trait NoCopy {
^
* move more traits, classes, and objects to proper packages
- note that `package` is itself a scoping construct, so if your reason
is the apparent aesthetic of placing a bunch of things in one `package
object`, that is easily remedied by deleting the `object` keyword
* fix some type-parameter-shadow warnings
- I'm generally in favor of sensible name-shadowing, following the
"deliberately hide variables that should not be accessed here" school
of thought. But I think type name shadowing isn't quite as valuable
and more likely to confuse than general variable shadowing, so have
experimentally linted it out.
Example warning:
EventsTableFlatEventsRangeQueries.scala:11: warning: type parameter
Offset defined in trait EventsTableFlatEventsRangeQueries shadows class
Offset defined in package v1. You may want to rename your type
parameter, or possibly remove it.
private[events] sealed trait EventsTableFlatEventsRangeQueries[Offset] {
^
* fix more package-object-classes warnings
* fix an inaccessible warning
ContractsService.scala:197: warning: method searchDb in class ContractsService references private class ContractsFetch.
Classes which cannot access ContractsFetch may be unable to override searchDb.
def searchDb(dao: dbbackend.ContractDao, fetch: ContractsFetch)(
^
* enable -Xlint:infer-any
- continuing the saga of #6116, #6132
* enable -explaintypes for more detailed type errors
* missed header for NoCopy; probably should have left it in the package file
* misspelling in comment
* revert -Xlint:doc-detached
- there are a lot of these fixes, and they are noisy, so shifting to a
separate PR
- thanks to @leo-da for pointing out
* Move public code into daml-integration-api
CHANGELOG_BEGIN
[DAML Integration Kit]: Removed sandbox specific code from the API intended to be used by ledger integrations. Use the maven coordinates ``com.daml:participant-integration-api:VERSION`` instead of ``com.daml:ledger-api-server`` or ``com.daml:sandbox``.
CHANGELOG_END
lodash released a non-broken version now and while dependabot isn’t
smart enough to realize this one has a vulnerability it still seems
like a good idea to bump it.
changelog_begin
changelog_end
I accidentally broke this when I added the types (very sorry about
that). Unfortunately while the tests should actually have caught this,
they didn’t because they are also broken. The `&&` results in bash
assuming the exit code is handled and `set -e` doesn’t kick in so
despite an error things proceeded just fine.
The change turns
```
Add2: (<a_a1Ag>(a_a1Ag: damlTypes.Serializable<a_a1Ag>) => damlTypes.Serializable<Expr2.Add2>);
```
into
```
Add2: (<a_a1Ag>(a_a1Ag: damlTypes.Serializable<a_a1Ag>) => damlTypes.Serializable<Expr2.Add2<a_a1Ag>>);
```
which is obviuosly what we want and also fixes the test. I did verify
that the tests fail afterwards without the change to daml2js.
changelog_begin
changelog_end
Turns out you can easily intersect function types with object literals
to get what we want here.
While I am very annoyed by it, I don’t know how to write a test for
this. Afaik I can only test this by writing something that hits the
decoder directly but that doesn’t work since it’s impossible (afaik)
to write DAML code that generates DAML-LF that uses the nested type
directly in some API-relevant position (choice arg/return type, key
type, …). Of course, I could handwrite some DAML-LF but only Rémy is
allowed to do that.
changelog_begin
changelog_end
* include DefTemplate's key types under the Ty type variable
* note that contract key types are included by folding over DefTemplates' Tys
- the topo sort from --root now correctly includes contract keys
* test that contract key dependencies get included in the Scala codegen plan
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
* Generate JS + typings to speed up dam2js
This speeds up daml2js to the point where it’s basically instant on
the GSG (based on 3 runs before and after it’s somewhere between a
40-50x speedup).
Most of this is fairly straightforward. I looked at the generated code
from typescript and the docs for declaration files and adapted things.
There is one interesting point here:
We set the TypeScript configuration to commonjs + ES5. While ES6
modules work fine via `yarn start`, they unfortunately work less fine
in nodejs and in particular in jest. I spent some time trying to fix
it and in the end decided that this is not worth doing since all our
users have to do the same which sucks.
Therefore, the codegen also emits ES5 + commonjs so this is not a
breaking change.
The tests pass and I went through the GSG manually to check things
still work and also verified that types show up correctly in VSCode.
What I was sadly unable to do is to keep the ESLint test for the .d.ts
files. typescript-eslint really wants everything to belong to a
typescript project with a tsconfig.json which doesn’t make sense
here. I don’t think that’s a huge loss. We still have ESLint for the
JS files.
changelog_begin
- [daml2js] daml2js now generates JS + typescript declaration files
directly instead of generating TypeScript code and invoking `yarn` to
generate the JS + the declaration files. This does not require any
changes to your code but it brings a significant speedup and removes the
dependency on `yarn` for running `daml codegen js`.
changelog_end
* Update language-support/ts/codegen/src/TsCodeGenMain.hs
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* Update language-support/ts/codegen/src/TsCodeGenMain.hs
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* declare key type in Scala codegen output
* add `key` type and function to TemplateCompanion
* template key exercise* case
* test idiomatic ExerciseByKey creation
* add changelog
CHANGELOG_BEGIN
- [Scala Codegen] Support for creating exercise-by-key commands, using same
exercise functions as exist for contract-IDs and the ``.createAnd`` pattern.
See `issue #6466 <https://github.com/digital-asset/daml/pull/6466>`_.
CHANGELOG_END
The default cache directories in yarn don’t work in the Bazel
sandbox. This results in Yarn creating tons of temp directories for
each test that are never cleared up.
This PR changes this to create actual temp directories that are
properly cleaned up.
changelog_begin
changelog_end
* replace traverseU and sequenceU with traverse and sequence
- with -Ypartial-unification on, the extra Unapply typeclass lookup is
unnecessary
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
* limit imports; we only need *> and void
* Update rules_haskell
- Fixes the issue where a `sh_test` wrapping a `haskell_binary` couldn't
add runfiles as is the case with other Bazel rules.
CHANGELOG_BEGIN
CHANGELOG_END
* Save the runfiles environment at start-up
To work around the fact that `withProgName` overwrites `argv[0]`.
See https://gitlab.haskell.org/ghc/ghc/-/issues/18418.
* damlc_compile_test include damlc runfiles
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
Previously, daml2js generated Text without any intermediate
representation. This both made the code pretty messy and it makes it
super hard to implement things like generating JS source + TS typings
instead of generating typescript.
This PR addresses this by first generating intermediate types which
are then rendered into Text in a separate step. This should hopefully
make it almost trivial to generate JS source + typings in the future
my implementing two rendering functions.
The types are somewhat adhoc atm. I expect that they will probably
change a bit anyway once we switch to JS + typings so I would like to
avoid bikeshedding the exact definitions too much.
I didn’t bother to preserve the pretty printing exactly as before. If
we really care about pretty output (why should we?), I would suggest
to switch to a proper pretty printing library (in a separate PR).
I apologize for the large PR. Not quite sure how to make it smaller.
changelog_begin
changelog_end
Buildifier now comes with a handy attachment to catch single `\`
characters inside strings and replace them with `\\` if the escape
sequence is invalid. Skylark/Python will do this at runtime anyway; this
just makes it clearer what the actual behavior is.
I needed to change `\` characters at the end of lines to `\\` manually
in order to stop Buildifier from simply concatenating the lines
together. Everything else was automatic.
CHANGELOG_BEGIN
CHANGELOG_END
* add -Xsource:2.13, -Ypartial-unification to common_scalacopts
* add now-referenced scalaz-core where needed
* work around bad type signatures in scalatest Aggregating, Containing
* unused Any suppression
* work around bad partial-unification wrought by type alias
* remove unused Conversions import
- not required in 4f68cfc480 either, so unsure how it's survived this long
* work around Future.traverse; remove unused show import
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
* remove unused bounds
* remove -Ypartial-unification and -Xsource:2.13 where they were explicitly passed
* longer comment on what the options do
- suggested by @stefanobaghino-da; thanks
* forget Future.traverse, just use scalaz, it knows how to do this
* bindings-rxjava: Return the `Disposable` from `Bot.wire`.
And in `BotTest`, dispose of the connection.
We are seeing some spurious errors in runs of BotTest due to connections
shutting down in the wrong order. By explicitly disposing of the wiring
before shutting down the ledger client, we can hopefully suppress these
errors.
They're not causing test failures, but they do often obscure the real
failure.
CHANGELOG_BEGIN
- [RxJava Bindings] `Bot.wire` and `Bot.wireSimple` now return a
`Disposable`, which can be used to shut down the flows. You are
encouraged to call `.dispose()` before terminating the client.
CHANGELOG_END
* bindings-rxjava: Don't run `awaitTermination` in a loop.
When shutting down the ledger client, instead of calling
`channel.awaitTermination` in a loop, we just call it once with an
approximately-infinite timeout.
* bindings-rxjava: Use the loan pattern for disposing in BotTest.
* bindings-rxjava: Simplify BotTest a little further.
CHANGELOG_BEGIN
Export Ledger context and hook creation to enable nested interaction,
with different parties or different ledgers, within one React app.
CHANGELOG_END
* Group context and hook creation so that it is exportable.
* Use undefined as default state to avoid cast
* Word choice
* Document new functions
* Revert commit to build script
* Test nesting of contexts
* Document extra feature in README
* Reorganize code to preserve individual function documentation.
* Correct names to starting with lowercase in build.
* Single quote imports and spacing style
* Add copyright notice
* Spacing around useReload
* Use a good variable name
* Do not export by default
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* LF: rename library transaction-scalacheck to transaction-test-lib
CHANGELOG_BEGIN
CHANGELOG_END
* move files in com/daml
* missing change in release/artifacts.yaml
* remove 'com/dam' from the path
fixes#6353fixes#6352
This fixes the program name to refer to `daml codegen js` and changes
the behavior to show help if the parser fails. Putting things together
running `daml codegen js` without arguments now looks as follows:
```
Missing: DAR-FILES -o DIR
Usage: daml codegen js DAR-FILES -o DIR [-s SCOPE]
Generate TypeScript bindings from a DAR
Available options:
DAR-FILES DAR files to generate TypeScript bindings for
-o DIR Output directory for the generated packages
-s SCOPE The NPM scope name for the generated packages;
defaults to daml.js
-h,--help Show this help text
```
changelog_begin
changelog_end
* update various lock files
CHANGELOG_BEGIN
CHANGELOG_END
Signed-off-by: Brian Healey <brian.healey@digitalasset.com>
* further version upticks from yarn upgrade
* Add option based constructor for LedgerIdRequirement
changelog_begin
changelog_end
* Make option based consructor the default, deprecate old constructor
* Update with review comments
Having them set to `false` when they will immediately bet set to `true`
does not make too much sense. This allows for simplifying uses of
`useFetchByKey` where the key is know to always be present since you
can now operate under the assumption that the contract is never `null`
when the loading indicator is `false`.
This fixes#6171.
CHANGELOG_BEGIN
- @daml/react: Initialize the loading indicators of ``useQuery``,
``useFetchByKey`` and their streaming variants with ``true``. This
removes a glitch where the loading indicator was ``false`` for a very
brief moment when components using these hooks were mounted although
no data had been loaded yet. Code using these hooks does not need to
adapted in response to this change.
CHANGELOG_END
* Remove older isLoading function calls.
* Clarify omitting of query argument to use(Stream)Query
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* disable Any wart
* first pass removal of Any suppressions for false positives
* second pass removal of Any suppressions for false positives
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
* third pass removal of Any suppressions for false positives
* fourth pass removal of Any suppressions for false positives
* reformat newly single-suppressions into single lines
- suggested by @SamirTalwar-DA; thanks
