* add phantom-tagged ExecutionContext and Future to scala-utils concurrent package
* many new operations for Futures
* Future, ExecutionContext combinators from porting ledger-on-sql
- picked from 546b84ab9cdf4de2d93ec5682bdee6cfd6b385f8
* move Future, ExecutionContext companions into normal package
* lots of new docs
* many new Future utilities
* working zipWith
* tests for ExecutionContext resolution, showing what will be picked under different scenarios
* even more tests for ExecutionContext resolution
* tests showing some well-typed and ill-typed Future combinator usage
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
* missed scalafmt
* one more doc note
* split concurrent package to concurrent library
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
* Add http-json-perf daily cron job
changelog_begin
changelog_end
* commenting out other jobs so we can manually test the new one
* commenting out other jobs so we can manually test the new one
* Fix the shell script
* Fixing the gs bucket, `gs://http-json bucket does not exist`
* uncomment the other jobs
* timestamp from git log
* get rid of DAR copying
* comment out the other jobs, so we can test it
* uncomment the other jobs
After discussion we have decided to introduce such popups through Google
Tag Manager, as the release schedule fo these sorts of JS tags does not
mesh well with the current release process of our docs site.
CHANGELOG_BEGIN
CHANGELOG_END
We've been saving data there but not doing anything with it. Ideally
this data would be used by some sort of automated process, but in the
meantime (or while developing said processes), having at least some
people with read access can help.
This is a Standard Change requested by @cocreature.
CHANGELOG_BEGIN
CHANGELOG_END
* Improve release instructions
- Add more notes on Remmina and how to use ad-hoc machines
- Fix Windows quickstart testing after change to template
changelog_begin
changelog_end
* Fix typo
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
The migration script from #7344 ensures that there are no more values
in Sandbox Classic DB encoded with Value version < 6. Hence, we do
not need anymore a special EngineConfig to maintain backward
compatibility of Sandbox classic DB.
CHANGELOG_BEGIN
CHANGELOG_END
* Add design doc for authentication in the trigger service
This is a draft of how I currently imagine authentication in the
trigger service to work. Since the authentication middleware has to be
pluggable in the end anyway we need public documentation in the end
anyway and I find this much easier to manage than a google doc outside
of the repo which just never sees updates.
changelog_begin
changelog_end
* Update triggers/service/authentication.md
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
In #7386 I inadvertently removed the default value for the argument
`check-changelog.sh` takes. This did not break CI because CI always
passes the argument explicitly, but it did break local workflows for
some developers.
Apologies.
CHANGELOG_BEGIN
CHANGELOG_END
There is generally little need to preview the PDF version of the docs.
Also, opening up the Python server on 0.0.0.0 (the default) triggers OS
warnings on macOS.
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
@stefanobaghino-da is taking care of 1.6.0-snapshot.20200915.5208.0.09014dc6 (#7410), so they get pushed back to the end of the line.
Please do not merge this before #7410.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
Please indulge my OCD.
And apologies to whoever was counting on these for their steganographed
[Whitespace] program.
[Whitespace]: https://esolangs.org/wiki/Whitespace
CHANGELOG_BEGIN
CHANGELOG_END
We reach the timeout on pretty much every release lately and we need to
retry to entire release process two or three times to get through. This
is us giving up on Maven, not Maven itself crashing, so I4d like to try
giving it more time.
CHANGELOG_BEGIN
CHANGELOG_END
Note that following the changed process for release notes which now
just point to the blog, this does not include an update to the release
notes in the rst file.
changelog_begin
changelog_end
* use GenMaps for trigger ACS
* Next removed for 1.dev
* temp port trigger test code to 1.dev only
* run trigger tests on 1.dev only
* move pending back to TextMap
* include trigger service in the 1.dev test lineup
- it takes >2min, so shouldn't be permanent
* add Ord TypeRep and Ord TemplateTypeRep when possible
* swap names in Internal to reduce the diff
* try to enable cpp for triggers compilation
$ bazel build //triggers/daml:daml-trigger-1.dev
<snip>
File: daml/Daml/Trigger/Internal.daml
Hidden: no
Range: 103:-1-103:-1
Source: CPP
Severity: DsError
Message: 22 in hpp-0.6.1:Hpp.CmdLine
File: daml/Daml/Trigger.daml
Hidden: no
Range: 103:-1-103:-1
Source: CPP
Severity: DsError
Message: 22 in hpp-0.6.1:Hpp.CmdLine
ERROR: Creation of DAR file failed.
<snip>
* remove problematic options for invoking cpp
hpp: Couldn't open input file: -Werror
CallStack (from HasCallStack):
error, called at src/Hpp/CmdLine.hs:103:22 in hpp-0.6.1:Hpp.CmdLine
* enough cpp so default and 1.dev triggers compile
* cpp needed for docs as well
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
* return trigger service to testing against sdk default lf version
* run trigger integration test against sdk default and LF 1.dev
* return trigger scenario test to SDK default LF version
* avoid import warnings in trigger lib
* Windows manifests a missing file differently. Hilarious
* Add --navigator-port option in daml start.
Fixes#5777
changelog_begin
- [DAML SDK] Added a ``--navigator-port`` option in ``daml start``,
allowing you to specify the port for navigator's web server.
changelog_end
* Perform defaulting in optparse-applicative
* Add a queryFor function to Daml.Script
`queryFor` combines `query` and filter. A very common pattern.
CHANGELOG_BEGIN
CHANGELOG_END
* Update daml-script/daml/Daml/Script.daml
CHANGELOG_BEGIN
CHANGELOG_END
Fixes#7381.
```
$ alias daml=~/.daml/sdk/0.0.0/daml/daml
$ daml version
DAML SDK versions:
0.0.0
1.4.0
1.5.0-snapshot.20200811.4959.0.bbc2fe56
1.5.0-snapshot.20200818.5027.0.1b33d374
1.5.0-snapshot.20200902.5118.0.2b3cf1b3 (default SDK version for new projects)
$ DAML_SDK_VERSION=invalid daml version
daml: Invalid value for environment variable DAML_SDK_VERSION.
context: Determining SDK version and path.
details: Invalid SDK version "invalid": Failed reading: takeWhile1
$ DAML_SDK_VERSION=1.4.4 daml version
DAML SDK versions:
0.0.0
1.4.0
1.4.4 (selected by env var DAML_SDK_VERSION, not installed)
1.5.0-snapshot.20200811.4959.0.bbc2fe56
1.5.0-snapshot.20200818.5027.0.1b33d374
1.5.0-snapshot.20200902.5118.0.2b3cf1b3 (default SDK version for new projects)
$ DAML_SDK_VERSION=1.4.0 daml version
DAML SDK versions:
0.0.0
1.4.0 (selected by env var DAML_SDK_VERSION)
1.5.0-snapshot.20200811.4959.0.bbc2fe56
1.5.0-snapshot.20200818.5027.0.1b33d374
1.5.0-snapshot.20200902.5118.0.2b3cf1b3 (default SDK version for new projects)
$ DAML_SDK_VERSION=1.5.0-snapshot.20200902.5118.0.2b3cf1b3 daml version
DAML SDK versions:
0.0.0
1.4.0
1.5.0-snapshot.20200811.4959.0.bbc2fe56
1.5.0-snapshot.20200818.5027.0.1b33d374
1.5.0-snapshot.20200902.5118.0.2b3cf1b3 (selected by env var DAML_SDK_VERSION, default SDK version for new projects)
$
```
CHANGELOG_BEGIN
CHANGELOG_END
* Fix missing date under/overflow in DA.Date.date
changelog_begin
- [DAML Standard Library] Bugfix: DA.Date.date
now raises an error when the day argument is
outside the valid range.
changelog_end
* Add test for underflow too
Previously, it was filtered out by accident since damlc considered it
to be an old-style typeclass. This PR fixes this by adding a dummy
field.
This is primarily useful in DAML REPL since all DARs there are
importad as data-dependencies atm. It’s not actually all that useful
across SDK versions since you end up with multiple daml-script
libraries but at least within an SDK you can use it and don’t have to
think about whether your project is a dependency or data-dependency.
changelog_begin
changelog_end
Before, we could in-place update the value of a var gauge. Now, we can not only set such a value but in-place update it atomically.
CHANGELOG_BEGIN
CHANGELOG_END
Currently, when Dependabot makes a PR, not only do we need to manually
trigger CI through `/azp run`, we also need to either change the commit
or add a new one to pass the changelog check. This addresses that second
part by making a exception for PRs signed by dependabot.
This is also a bit of an excuse to play with git signatures and gpg.
CHANGELOG_BEGIN
CHANGELOG_END
* Open sourcing gatling statistics reporter
Running gatling scenarios with `RunLikeGatling` from libs-scala/gatling-utils
* cleaning up
* Replace "\n" with System.lineSeparator
so the formatting test cases pass on windows
* Testing DurationStatistics Monoid laws
* Renaming RunLikeGatling -> CustomRunner
The version in nixpkgs is v2.12.10, which means that the Scala REPL we
used was not the same version as we use in our code.
CHANGELOG_BEGIN
CHANGELOG_END
CHANGELOG_BEGIN
Upgrade Jackson to 2.11.2 to address security vulnerabilities
CHANGELOG_END
Signed-off-by: Brian Healey <brian.healey@digitalasset.com>
* Add queryContractKey to DAML Script
This matches the behavior and the implementation of
`queryContractId`. We only return contracts for stakeholders and we
return an `Optional` so you can handle lookup failures. On the JSON
API and in DAML Studio this is fairly efficient, over the gRPC API it
degrades to a linear search.
changelog_begin
- [DAML Script] Add `queryContractKey` to the DAML Script API.
changelog_end
* Update daml-script/runner/src/main/scala/com/digitalasset/daml/lf/engine/script/LedgerInteraction.scala
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
It looks like #6761 broke our Terraform setup by upgrading the nixpkgs
snapshot. That this has not been caught earlier is, I suppose, a
testament to how stable our infrastructure has become nowadays.
This is the same issue we had with the Google providers in #6402, i.e.
we are trying to pin the provider versions both at the nix level and at
the terraform level, with no way to force them to stay in sync.
I don't have a good proposal for such a way, and it seems rare and
innocuous enough to not warrant the investment to fix this at a more
fundamental level.
CHANGELOG_BEGIN
CHANGELOG_END
* Generate hoogle docs for daml script/triggers
This PR switches over the documentation generation for daml script and
daml triggers to the multi-page format we already use for the standard
library and extends it to also generate hoogle documentation.
All 3 hoogle files are combined in a single hoogle_db.tar.gz archive.
Since the location in the multi-page format is different, I’ve added
redirects.
I verified locally, that I can generate the hoogle database and that
the links point to the right places.
changelog_begin
changelog_end
* Fix baseurl for daml-stdlib
changelog_begin
changelog_end
We want to be able to support more than one package in our [Hoogle]
instance. In order to not have to list each file individually, we assume
the collection of Hoogle text files will be published as a tarball.
Note: we keep trying the existing file for now, because the deployment
of this change needs to be done in separate, asynchronous steps if we
want everything to keep working with no downtime:
1. We deploy the new version of the Hoogle configuration, which supports
both the new and old file structure on the docs website (this PR).
2. After the next stable version (likely 1.6) is published, the docs
site actually changes to the new format.
3. We can then clean-up the Hoogle configuration.
Any other sequence will require turning off Hoogle and coordinating with
the docs update, which seems impractical.
[Hoogle]: https://hoogle.daml.com
CHANGELOG_BEGIN
CHANGELOG_END
