* Fix redirects, java-bindings javadoc, and live-preview.sh
- javadoc_library now supports sources from filegroups as well
- //language-support/java:javadoc now generates javadoc for ledger-api, java bindings, rxjava bindings
- live-preview.sh refers to the correct javadoc target //language-support/java:javadoc
- removed leading / from redirects.map
* Only generate daml-lf javadocs if not on windows
CHANGELOG_BEGIN
CHANGELOG_END
* language: update on daml2js in app-arch section.
Update on the app-arch section in respect to daml2js. This is slightly
more precise about the contents of the generated libraries.
CHANGELOG_BEGIN
CHANGELOG_END
* Update docs/source/app-dev/app-arch.rst
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Update docs/source/app-dev/app-arch.rst
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* language: remove file globs from ts library BUILD files
We replace them with toplevel `sources` definition, since sadly
filegroups don't work here.
CHANGELOG_BEGIN
CHANGELOG_END
* update app-arch section regarding daml2js
* remove files field in tsconfigs
Packages com.digitalasset.daml and com.daml have been unified under com.daml
Ledger API and DAML-LF DEV protos have also been moved from `com/digitalasset`
to `com/daml` on the file system.
Protos for already released DAML LF versions (1.6, 1.7, 1.8) stay in the
package `com.digitalasset`.
CHANGELOG_BEGIN
[SDK] All Java and Scala packages starting with
``com.digitalasset.daml`` and ``com.digitalasset`` are now consolidated
under ``com.daml``. Simply changing imports should be enough to
migrate your code.
CHANGELOG_END
* move JSON API doc to "Building applications"
* stop describing JSON API as experimental; limit to calling WebSocket endpoints alpha
* remove "(experimental)" from daml json-api docstring
* add changelog
CHANGELOG_BEGIN
- [JSON API] First stable version of the ``/v1`` endpoints, with
the exception of the WebSocket endpoints, which remain in alpha.
See `issue #4458 <https://github.com/digital-asset/daml/issues/4458>`_.
CHANGELOG_END
* move json-api in PDF ToC, adapting to #5411c496e2bf05
- pointed out by @cocreature; thanks
I've completely removed the possibility to call `daml codegen ts`. I'm
happy to add in back in a followup PR once I've seen that all our tests
pass without it existing.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* Move quickstart to java bindings section
* Change title of quickstart to Getting Started with ...
* Move GSG to Getting Started (and rename in index)
* Rewrite a bunch of references to quickstart
* Update reference and give more specific name
changelog_begin
- [Docs] Replace IOU quickstart with full stack Getting Started Guide
changelog_end
* Replace daml-ledger link
* Use getting started guide in redirects
I've completely removed the possibility to call `daml codegen ts`. I'm
happy to add in back in a followup PR once I've seen that all our tests
pass without it existing.
CHANGELOG_BEGIN
CHANGELOG_END
CHANGELOG_BEGIN
- Move daml2ts, bindings-ts and JSON API out of experimental section in docs
- Rename Experimental to Early Access in docs and assistant
- Reorganise the docs a little bit to de-emphasise the Ledger API
CHANGELOG_END
This PR removes the code for publishing to Bintray and updates the
documentation to point to github releases or Maven central.
I had to slightly change the docs formatting since trying to use
markup in code blocks results in a horrible layout and I don’t want to
fix that atm.
I’ve removed all artifacts that were only published to Bintray.
changelog_begin
changelog_end
Our plan for `daml2js` is to populate the `name` and `version` field
of the generated `package.json` files with the name and version of
the input DALF. Once this is done, you would expect to refer to the
package generated from `create-daml-app-0.1.0.dar` via
```typescript
import ... from '@daml.js/create-daml-app';`
```
Since we currently depend on the package by file paths anyway, we can
already pretend to have the right behavior in place.
In this style you can also depend on two different versions of the same
DAML package. This will happen during upgrades, a situation we're
already facing in DAVL. There it can be solved via the following two
lines in the `dependencies` field of the `package.json`:
```
...
"davl-v4": "file:../daml.js/davl-0.0.4",
"davl-v5": "file:../daml.js/davl-0.0.5",
...
```
CHANGELOG_BEGIN
CHANGELOG_END
As expected, the `puppeteer` library used to demonstrate how to test
DAML apps end-to-end, causes issues in CI. It is not very unlikely
that users of the getting started guide would run into the same issues.
In addition, `puppeteer` is a _huge_ dependency, we should probably not
shove down everybody's throat who just wants to walk throught the GSG.
Thus, this PR moves everything related to testing out of
`create-daml-app` and exclusively into the docs. This is completly
lacking tests, but since it wasn't tested before either, I consider
this acceptable. My manual tests succeeded.
Since merging this might unblock quite a few other PRs, I defer test
into a followup PR.
CHANGELOG_BEGIN
CHANGELOG_END
* Copy templates into docs build directory to reference in code snippets
changelog_begin
changelog_end
* Remove ui-before code copies
* Rename daml folder to daml-after and remove tags for before code
* Fix a link and wording
* REPL parse import statements
* Factor parsing out of handleLine
* Pull binding and error handling into handleStmt
This is specific to the case of handling a statemt and does not overlap
with handling imports.
* Track module imports as ImportDecl
* Add new module imports
* Validate module imports
* Add REPL interaction test for import
* REPL document import declarations
CHANGELOG_BEGIN
- [DAML REPL - Experimental] You can now use import declarations at the
REPL prompt to bring additional modules into scope.
CHANGELOG_END
* ReplState strict fields
* Use semigroupoids Alt to simplify parseReplInput
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
Change the output directory given to `daml codegen ts` from `daml-ts`
to `daml.js`. This is naming is in line with the fact that `daml2ts`
puts all generated packages into the `@daml.js` scope. A renaming of
`daml2ts` into `daml2js` is immiment.
This PR also changes a few small documentation issues the
search-and-replace has surfaced.
CHANGELOG_BEGIN
CHANGELOG_END
* non empty set of template IDs in domain.GetActiveContractsRequest
* Updating expected error message
changelog_begin
changelog_end
* Adding warnings field to domain.ErrorResponse
* Error messages constants
* using domain.AsyncResponse
* added todo
* Updating examples
changelog_begin
changelog_end
* Updating examples
* Fixing the case when head is part of the tail, as pointed by @S11001001
* Fixing the domain.SynResponse JSON reader,
report deserialization error when both 'errors' and 'result' fields
present, as pointed by @S11001001
* Addressing code review comments
* Limit memory usage of scenario service in tests
Previously the scenario service used over 2GB of memory during
//compiler/damlc/tests:integration-dev for absolutely no reason.
This PR adds an option to pass JVM options when starting the scenario
service and sets them to 200MB for the Shake tests and the damlc
integration tests which seems to be more than sufficient.
These option can also be set in `daml.yaml`. I did not change the
defaults since this is shipped to users where I’d rather have high
memory usage than a crashing scenario service and on certain large
DAML codebases we might actually use a fair bit.
changelog_begin
changelog_end
* Update docs/source/tools/assistant.rst
Co-Authored-By: Samir Talwar <samir.talwar@digitalasset.com>
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
* Initial commit with create-daml-app master
* Include create-daml-app in build rule
* Make daml.yaml a template in version and project name
* Remove git attributes
* Remove license and azure config
* Remove scripts
* Don't overwrite config files in build rule
* Template version numbers in package.json, to be replaced by the assistant
* Rename to package.json.template
changelog_begin
changelog_end
* Add copyright headers
* Do template substitutions in all .template files
And don't special case daml new create-daml-app (so it treats it as a
regular template).
* Add create-daml-app to integration tests
* Remove WIP warning
* Move towards setup that works on head
* Make local copies of the TS libs in the templates tarball
* Hardcode project name for now
* Use isExtensionOf
* Remove service worker
* remove robots.txt (don't even know what it is)
* Revert "Make local copies of the TS libs in the templates tarball"
This reverts commit 1289581fb4a82af3ab534baf978a2c6ed895d538.
* Retemplatize TS lib versions. For head builds these will be installed using npm
* Remove daml/ledger from resolutions for daml-ts
* Comment about test secret
* Remove special create-daml-app assistant command and test that won't work anymore
* Remove redundant imports and export
* Remove old create-daml-app tests
* Remove yarn.lock
* Clean up integration test (just daml new and build atm)
* Add daml/ledger as a resolution for daml-ts
* Remove top level package.json
* Update daml.js version
* Use new import scheme for generated TS
* Update readme with new codegen and build steps
* Use start-navigator in daml.yaml
* Increase a couple of timeouts in tests (either sandbox or TS lib is a bit slower?)
* Update GSG intro with new build steps
* Remove daml2ts -p flag and --start-navigator flag from GSG instructions
* Don't use start-navigator flag in ui tests
* Temporary readme describing how to manually test the create-daml-app template
* Update code samples in app arch section of GSG
* Update code samples in testing doc
* Remove copied create-daml-app code
* Indent docs markers to be more subtle
* Update visible code in Messages (after) section
This needs to be kept up to date properly somehow.
* Update text to useLedger
* Restore code/ui-before copies until the Bazel magic is figured out
We need to make the template code a dependency in the Bazel rule as
otherwise we can't find the files in the docs build.
* Update create-daml-app/readme and make templates/readme more detailed
* Use jsx comments for docs markers so they don't show up in the app
* Improve handling of exposed-modules with data-dependencies
Previously, we tried to rename all modules of a dependency via
--package. This fails if some of those modules are not exported. This
was trivial to hit as a user since the ``daml-trigger`` library made
use of this.
This PR adds a few things to improve the situation:
1. We only rename modules that are exposed. This fixes the issue if
you don’t actually reference a non-exposed module from your
data-dependency.
2. I’ve removed the exposed-modules from daml-trigger. I don’t think
they are essential here given that the module name has `Internal`
in the name and it’s too easy to have something that actually
references the non-exposed module since the types are reexported.
3. I’ve added documentation that mentions this issue.
4. I’ve added a warning if your exposed-modules are excluding some
modules. Maybe worth turning this into an error in the future.
changelog_begin
changelog_end
* Update compiler/damlc/lib/DA/Cli/Damlc/Packaging.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
Co-authored-by: associahedron <231829+associahedron@users.noreply.github.com>
* Use com.daml as groupId for all artifacts
CHANGELOG_BEGIN
[SDK] Changed the groupId for Maven artifacts to ``com.daml``.
CHANGELOG_END
* Add 2 additional maven related checks to the release binary
1. Check that all maven upload artifacts use com.daml as the groupId
2. Check that all maven upload artifacts have a unique artifactId
* Address @cocreature's comments in https://github.com/digital-asset/daml/pull/5272#pullrequestreview-385026181
* report UnknownTemplateIds warning before sending an error
if no template IDs resolved, send warning before the error, this is for
consistency with the case when at least one ID resolved (we continue
processing request in this case).
changelog_begin
changelog_end
* adding an error message example
* change title
* clarifying what on-message means.
* formatting
* Addressing code review comments
* minor refactoring in preparation for the next test case
* allow only one input request + test, WIP
* allow only one input request + test, WIP
* Error when multiple requests coming over the same websocket connection
This never worked, we never returned anything when 2nd request received,
now we return an error and drop the connection.
changelog_begin
changelog_end
* update docs
* Fixing copyright header
* changing test description
* trying to clean wsMessageHandler up
* Reverting getTransactionSourceForParty changes
Using `on` to add event listeners is a Node.js idiom. In the brosers,
it's `addEventListener`, which works in Node.js too.
CHANGELOG_BEGIN
CHANGELOG_END
* Turn warnings for module name/record name mismatches into errors
The module name warning existed for ages. We started warning about the
record name mismatch in 0.13.55 so I’d like to turn it into an error
before 1.0
changelog_begin
- [DAML Compiler] File names must now match up with module names. This
already produced a warning in previous releases.
- [DAML Compiler] It is now an error to define a record with a single
constructor where the constructor does not match the type
name. To fix the error you need to change ```data X = Y { … }``` to
```data X = X { … }```. This restriction only applies to
single-constructor records. Variants and enums are not affected.
This already produced a warning in 0.13.55.
changelog_end
* Fix integration tests
* Fix docs
* Fix lsp tests
* Remove documentation for a removed option
CHANGELOG_BEGIN
- [DAML Integration Kit] The CLI option command-submission-ttl-scale-factor was
removed, as the LET/MRT/TTL fields have recently been removed
from the command submission service.
CHANGELOG_END
* Minor renaming
Semicolons at the end of every line seem to be good style. Logging to
the console does not help with the example. The `WebSocket` class is
built-in in the browser and you only need a package like `ws` on
Node.js.
CHANGELOG_BEGIN
CHANGELOG_END
* ContractKeyStreamRequest with different types for whether offset-preceded or not
- should replace EnrichedContractKey as the WS StreamQuery type
* add the ContractKeyStreamRequest layer everywhere
* split StreamQuery parse from the other steps
* make StreamQuery type depend on the input JsValue
* only StreamQueryReader is a typeclass now
* scalafmt
* wrong type arg
* letting the request data and phantom archive removal choice flow
- from work with @leo-da
* finish threading request-derived phantom state to removal flow
- from work with @leo-da
* make it clear that hints are contract IDs in StreamQuery
- from work with @leo-da
* treat StreamQueryReader's type parameter fully as a phantom
- from work with @leo-da
* remove unused type alias
- from work with @leo-da
* test fetch resume, with and without various offsetHints
* document offsetHints
* missing ` in rst
- thanks @hurryabit
* rename offsetHint to contractIdAtOffset
CHANGELOG_BEGIN
- [JSON API - Experimental] New field ``contractIdAtOffset`` for fetch-by-key streams
to restore proper archive filtering.
See `issue #4511 <https://github.com/digital-asset/daml/issues/4511>`_.
CHANGELOG_END
* we never unify the two ContractKeyStreamRequest types
* doc update for contractIdAtOffset
changelog_begin
[JSON API - Experimental]
Remove ``ledgerEffectiveTime`` and ``maximumRecordTime`` fields from command ``meta``. Remove ``--default-ttl`` command line argument. The ledger time and TTL are automatically computed by the submission service now. See #5090.
changelog_end
Contributes to #4194.
Closes#4231.
Closes#5022.
CHANGELOG_BEGIN
- [Ledger API] The protobuf fields ledger_effective_time and maximum_record_time have been removed from
command submission. These fields were previously deprecated following the introduction
of a new ledger time model. See issue `#4194 <https://github.com/digital-asset/daml/issues/4194>`__.
[Java Bindings] removed the usage of ledgerEffectiveTime and
maximumRecordTime, and instead added minLedgerTimeAbsolute and
minLedgerTimeRelative in CommandSubmissionClient and CommandClient
CHANGELOG_END
* Streaming API error handling
* Stopping the stream after emitting the 1st error
* Cleaning up test cases, stricter type for non empty streaming fetch
* Update docs.
changelog_begin
[JSON API - Experimental] Change Streaming API error format to match synchronous API:
``{"status": <400 | 401 | 404 | 500>, "errors": <JSON array of strings> }``. See #4521
changelog_end
* a few words about warnings in the Streaming API
* a few words about warnings in the Streaming API
* Updating command formatting in the JavaScript example.
* Integrate create-daml-app into the assistant
fixes#4868
changelog_begin
- [DAML Assistant] Add a new ``daml create-daml-app`` command for creating a project based on
`create-daml-app <https://github.com/digital-asset/create-daml-app>`_.
changelog_end
* Try random things hoping to fix windows
* Try random things hoping to fix things on macos
* remove `src` subdir from codgen command
If you don't do this, running `yarn install` will complain:
```
error Couldn't find package "@daml-ts/create-daml-app-0.1.0@0.13.55" required by "create-daml-app@0.1.0" on the "npm" registry.
```
This was with yarn v1.22.4 - can someone please double-check this.
* Update codegen command and some surrounding explanation
Unfortunately also removed a bunch of trailing whitespace due to my
editor settings, which is fine but makes reviewing harder :(
changelog_begin
changelog_end
* Warn that workspaces run build takes ages
Co-authored-by: Rohan Jacob-Rao <rohanjr@gmail.com>
* First draft of guide to UI testing
changelog_begin
changelog_end
* Address Nemanja's feedback
* Add copyright headers
* Cut down intro and description of Jest/Puppeteer
* Shorten a bit more
* Sandbox: Reveal contract id seeding flag
CHANGELOG_BEGIN
- [Sandbox] Add support for random contract identifiers. See section
`Contract Identifiers Generation` section in
docs/source/tools/sandbox.rst
CHANGELOG_END
* Allow controlling navigator startup in daml.yaml
While I’m not entirely convinced the default atm is right, making it
configurable seems like an easier solution than bikeshedding the default.
changelog_begin
- [DAML Assistant] You can now disable starting navigator as part of
``daml start`` in your ``daml.yaml`` file by adding ``start-navigator: false``.
changelog_end
* Update docs/source/tools/assistant.rst
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Use --start-navigator=true in the docs
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* remove List and TextMap support from the JSON query language
CHANGELOG_BEGIN
- [JSON API - Experimental] Removed support for maps and lists from the query language.
See `issue #4855 <https://github.com/digital-asset/daml/issues/4855>`_.
CHANGELOG_END
* GenMap won't be supported in general, remove FIXME
- thanks @leo-da
* more documentation on unsupported query types
- as suggested by @hurryabit; thanks
* Getting started guide: Invoke daml start directly
Since we no can configure arguments we wish to pass to DAML Sandbox
when running `daml start` in `daml.yaml`, we don't need the mysterious
`daml-start.sh` script anymore. That's why
https://github.com/digital-asset/create-daml-app/pull/78
removes the script from `create-daml-app`.
This PR adjust the getting started guide accordingly.
This fixes#4295.
CHANGELOG_BEGIN
CHANGELOG_END
* Fix expected message when daml start successful
* Support partial patterns in DAML repl
This PR improves the support for partial patterns in DAML repl by
making sure that they fail on the line itself rather than some
subsequent line and avoids the partial pattern match warnings on all
following lines.
changelog_begin
changelog_end
* Fix tests
* Support complex patterns in DAML REPL
Previously, we only supported simple variable patterns in DAML
repl. This PR extends this to support pretty much all patterns. The
main complexity here is in handling shadowing correctly but I’m
reasonably confident the solution here is sensible.
What doesn’t work properly yet is partial patterns. I’ve added a
comment describing the issue and a potential solution. Given that this
isn’t a regression apart from maybe a slightly worse error message, I
think it makes sense to merge this PR and fix that separately.
changelog_begin
- [DAML REPL - Experimental] You can now use more complex patterns in
statements, e.g., ``(x,y) <- pure (1,2)``.
changelog_end
* Update compiler/damlc/daml-compiler/src/DA/Daml/Compiler/Repl.hs
Co-Authored-By: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Update compiler/damlc/daml-compiler/src/DA/Daml/Compiler/Repl.hs
Co-Authored-By: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Improve error messages
* update documentation
Co-authored-by: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Follower terminology in the docs
Changed the docs to a more twitter/Instagram like terminology where we use 'follower' relationship instead of 'friend'. Resolves#5015
CHANGELOG_BEGIN
CHANGELOG_END
* Update docs/source/getting-started/index.rst
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Update docs/source/getting-started/index.rst
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Update docs/source/getting-started/index.rst
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Update docs/source/getting-started/app-architecture.rst
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Update docs/source/getting-started/app-architecture.rst
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Update docs/source/getting-started/first-feature.rst
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Update docs/source/getting-started/first-feature.rst
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Update docs/source/getting-started/first-feature.rst
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Update docs/source/getting-started/first-feature.rst
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Update docs/source/getting-started/first-feature.rst
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
Avoiding `damlc compile/package` commands (which we would like to deprecate), and replace with plain `damlc build` together with a post dar->dalf extraction step in the couple of places where we actually want the .dalf for testing.
changelog_begin
changelog_end
* sandbox: Fail to start if a time mode is not explicitly specified.
CHANGELOG_BEGIN
- [Sandbox] Sandbox is switching from Static Time mode to Wall Clock
Time mode as the default. To ensure that our users know about this,
for one version, there will be no default time mode. Instead, users
will have to explicitly select their preferred time mode by means of
the `--static-time` or `--wall-clock-time` switches. In the next
release, Wall Clock Time will become the default, and users who are
happy with the defaults will no longer need to specify the time mode.
CHANGELOG_END
* daml-script|triggers: Specify time mode when testing against Sandbox.
* daml-assistant: Default the Sandbox to wall clock time.
CHANGELOG_BEGIN
- [DAML Assistant] Initializing a new DAML project adds a switch to
``daml.yaml`` to ensure Sandbox can continue to start with ``daml
start``::
sandbox-options:
- --wall-clock-time
CHANGELOG_END
* docs: Update the DAML Script and Triggers docs to use Wall Clock time.
It's now what Sandbox will use by default when using `daml init`.
* docs: Change the Quickstart to run Sandbox in wall clock time.
This explains why the contract IDs may vary.
It also updates the manual release testing script to match.
* Simplify docs, use mapped types for enums.
changelog_begin
changelog_end
* remove serializale check
* add 'keys' property to enums
* Simplify docs just a little bit more
* Support authentication and TLS in DAML repl
changelog_begin
- [DAML Repl - Experimental] You can now connect to a ledger via TLS
by passing ``--tls`` to ``daml repl``
- [DAML Repl - Experimental] You can now connect to a ledger with
authentication by passing the token via ``--access-token-file`` to
``daml repl``.
changelog_end
* try to fix linking on windows
* windows is weird
* gnah
* Allocate party JSON API endpoint
changelog_begin
[JSON API - Experimental]
Allocate party endpoint added: ``/v1/parties/allocate``. See #4638.
changelog_end
* cleanup
* Update ledger-service/http-json/src/main/scala/com/digitalasset/http/LedgerClientJwt.scala
Co-Authored-By: Stephen Compall <stephen.compall@daml.com>
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
* capture the pattern of an optional stream input prefix
* allow LiveBegins to be appended
- should have been included with #4593
* StreamQuery will parse JsValues instead of Strings
* shortcut in HttpServiceTestFixture; clean up InsertDeleteStepTest
* compatibly add withOptPrefix stage to WS input
* parsing the offset argument
* add offset parsing to input stream, but drop it on the floor
* another form of the two cases
* percolate the starting offset to the next step
* percolate the starting offset to the next step
* percolate the starting offset to the next step
* use transactionsFollowingBoundary in ContractsService if begin offset specified
* integration test for scan from offset in WS query
* tool for catching the first offset in a stream
* documentation
* add changelog entry
CHANGELOG_BEGIN
- [JSON API - Experimental] WebSocket endpoints now support an optional offset argument.
See `issue #4509 <https://github.com/digital-asset/daml/issues/4509>`_.
CHANGELOG_END
* move offset argument doc to later
- suggested by @hurryabit; thanks
* remove stray TODO
- pointed out by @leo-da; thanks
* redesign withOptPrefix to make the usage a little easier to follow
- suggested by @leo-da; thanks
* GSG info on restarting the ledger and making changes
CHANGELOG_BEGIN
CHANGELOG_END
* Update docs/source/getting-started/first-feature.rst
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update docs/source/getting-started/first-feature.rst
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Changed the explanation for why we need to run './daml-start.sh' again
* Update docs/source/getting-started/first-feature.rst
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update docs/source/getting-started/first-feature.rst
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update docs/source/getting-started/first-feature.rst
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Solves #4841
* Added info for successfull daml-start.sh script run
* fix syntax
changelog_begin
changelog_end
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Resolves#4304
Added highlighting to the application architecture section
Highlighter that works
The latest highlighter
* Added the lexer to pdf and html and restructured how conf.py is called within the theme
* Added copyright headers
* add typescript.py to srcs
changelog_begin
changelog_end
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Currently sandbox only supports TLS if you also enable client
authentication. There is no reason for why this has to be the case and
for things like DABL we want TLS without client authentication so it’s
useful to be able to test this in sandbox. This PR introduces a
`--client-auth` flag that allows you to configure the behavior. The
default is the current one of requiring client authentication.
This PR does not yet update Java clients, however, the Haskell client
supports this already and is used to test this functionality.
I’ve also added a section in the documentation on TLS (there were no
docs at all so far).
changelog_begin
- [DAML Sandbox] When Sandbox is run with TLS enabled, you can now
configure the requirement for client authentication via
``--client-auth``. See
https://docs.daml.com/tools/sandbox.html#running-with-tls for more information.
changelog_end
* Capture lastSeenOffset in the @volatile var
CHANGELOG_BEGIN
[JSON API - Experimental] Websocket stream now emits last seen offset instead of the heartbeat message.
``{"heartbeat": "ping"}`` is replaced by ``{"events":[],"offset":"<last seen offset>"}``. See #4510.
CHANGELOG_END
* updating docs
* moving the last seen offset into the stream, WIP
* adding in-stream state
* minor docs
* cleanup the heartbeat logic
* minot cleanup
* Change live and heartbeat msg handling + some debug logging (to be removed)
* fixing ts tests, cleaning up
* Adding todo with the reference to the follow-up ticket
* Adding todo with the reference to the follow-up ticket
This PR adds TLS support to DAML helper both via client certs and
without (although the latter is not tested so far since atm this is
not supported by sandbox). The CLI options follow the scheme used by
navigator/extractor/… with the addition that you can just pass `--tls`
which will turn on TLS without custom root certs or client certs.
changelog_begin
- [DAML Assistant] You can now connect to ledger via TLS for ``daml
deploy`` and ``daml ledger`` commands. See
https://docs.daml.com/deploy/generic_ledger.html for more information.
changelog_end
* Rename EC auth cmdline options in line with the standard and document them.
CHANGELOG_BEGIN
CHANGELOG_END
* 📝 Fix doc
* Auth docs: change `RSA DSA` -> `RSA Signature` (clashed with DSA algo)
As proposed by @SamirTalwar-DA
CHANGELOG_BEGIN
[Sandbox] Rename the `--auth-jwt-ec256-crt` command line option to `--auth-jwt-es256-crt` as well as `--auth-jwt-ec256-crt` to `--auth-jwt-es256-crt` and fix their docs
CHANGELOG_END
This includes the generated docs for the typescipt libraries daml-react,
daml-ledger and daml-types in the documentation presented on
docs.daml.com. Next step is to create better readmes in this libraries.
CHANGELOG_BEGIN
CHANGELOG_END
* Split upgrade models into a separate package
This PR splits the upgrade example into 3 packages instead of 2 which
avoids a dependency from the model on the old model. This is explained
in the documentation.
changelog_begin
changelog_end
* Fix typo
Dependencies on other DAML projects are declared with the `dar_dict` attribute of the build rule. This attribute also declares the names by which the `.dar` files are known in the client project, corresponding to the references in the `daml.yaml` config.
The new rule is used build & test the upgrade documentation example code.
changelog_begin
changelog_end
* Deprecate ledger initialization with scenarios
CHANGELOG_BEGIN
[Sandbox] Initializing the sandbox with scenarios is now deprecated in
favor of using DAML Script. The scenario parameter will be removed in
the near future. A warning is logged on startup.
The DAML SDK templates and quickstart guide are using DAML Script.
See the DAML Script migration guide for more information:
https://docs.daml.com/daml-script/index.html#using-daml-script-for-ledger-initialization
CHANGELOG_END
changelog_begin
- [DAML Assistant] You can now specify options for
Sandbox/Navigator/the HTTP JSON API in ``daml.yaml`` via
``sandbox-options``/``navigator-options``/``json-api-options``. These
options will be picked up by running ``daml start``. This is
particularly useful for specifying ``--wall-clock-time`` and for
specifying a fixed ledger ID during development.
changelog_end
fixes#2993
The only remaining thing that I wanted to get in before doing that was
overloading ``submit`` which has now happened. I’m sure we can come up
with tons of improvements but I don’t expect breaking changes to the
current state.
changelog_begin
- [DAML Script] DAML Script is no longer experimental.
changelog_end
fixes#4615
This introduces a `HasSubmit` typeclass (following the naming scheme
of `HasCreate`, …) and instances for `Scenario` and `Script`. This
avoids the need to hide `submit` in every single DAML script.
changelog_begin
- [DAML Standard Library] ``submit`` and ``submitMustFail`` are now
overloaded so that they can be used in both scenarios and DAML script.
changelog_end
This PR adds a first version of update documentation and removes the
existing docs which were talking about `damlc migrate`.
So far the docs focus on the high-level approach to upgrades taken in
DAML and give an example of how to structure upgrade contracts.
What is not covered so far (and I’d like to leave that for a separate
PR) is:
1. Technical details: How are things split up into packages, which
restrictions apply to data-dependencies, …
2. Deployment and Running the upgrade via triggers/daml script/…
3. Common patterns for handling this in UIs (e.g. “locking” old contracts)
changelog_begin
changelog_end
* Use yarn installation link instead of homepage
* Indentation of Messages segment
* Update git link to downloads page
* Explain why you see friends of friends in the network
* Tweak wording
* Descibe how to run new app more explicitly
* Make change to ui folder more obvious
* Add next steps
changelog_begin
changelog_end
* Fix title levels
* Update create-daml-app code
* Remove reference to infix elem
* Remove the licenses from the code we tell users to copy
* Tweak conclusion
changelog_begin
changelog_end
* move BeginBookmark to util
* adding offsets to steps
* offsetAfter belongs in Txn, not InsertDeleteStep
* make transaction stream a ContractStreamStep.Txn stream
* add several ContractStreamStep append cases
* rewrite 'render' to emit offset in the right places
* make ContractStreamStep#append total again
* check for offset in a few tests
* revert useless whitespace changes
* missed argument
* simpler mapPreservingIds
* rewrite states for new "live" format
* remove invalidated "events" block structure assertions
* make shutdown in withHttpService deterministic, to try to catch race condition
* exhaustiveness checking somehow disabled; fixed fetch flow and all is well
* documentation and changelog
CHANGELOG_BEGIN
- [JSON API - Experimental] Remove ``{"live": true}`` marker from websocket streams;
instead, live data is indicated by the presence of an "offset".
See `issue #4593 <https://github.com/digital-asset/daml/pull/4593>`_.
CHANGELOG_END
* be more specific about what liveness marker may be in docs
* fix daml2ts websocket tests
* mention type rules for all cases in offset documentation
* Extend /party endpoint to allow specifying party ids
* Extend /party endpoint to allow specifying party ids
* Update docs
CHANGELOG_BEGIN
[JSON API - Experimental] Fetch Parties by their Identifiers. See #4512
``/v1/parties`` endpoint supports POST method now, which expects
a JSON array of party identifiers as an input.
CHANGELOG_END
* minor update
* minor update
* Use type alias
* Add warnings to the sync response
* test cases
* update docs, add test case for an empty input
* cleanup
* cleanup
* Addressing code review comments
This disables the PDF docs builds on MacOS on CI (they are still built
locally by default) and removes them from the Nix closure by
introducing a separate ci-cached attribute that filters out texlive.
Since we built `nix-build nix -A tools -A cached` on CI, I’ve also
removed all the Tex stuff from tools which only means that it ends up
in PATH which nobody seems to care about.
changelog_begin
changelog_end
* Copy App component from create-daml-app
* Introduce App component and start changing explanation of MainView
changelog_begin
changelog_end
* Elaborate on MainView, esp useStreamQuery
* Show where to find components and rearrange introduction of hooks
* ts
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Tweak context description
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Don't talk about []
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Address rest of comments
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* Change method of opening DAML files with VSCode
* More explanation of AddFriend choice
changelog_begin
changelog_end
* Contract not contract instance
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Remove 'instance' and explain nonconsuming better
* Fix file navigation and more wording
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Context
=======
After multiple discussions about our current release schedule and
process, we've come to the conclusion that we need to be able to make a
distinction between technical snapshots and marketing releases. In other
words, we need to be able to create a bundle for early adopters to test
without making it an officially-supported version, and without
necessarily implying everyone should go through the trouble of
upgrading. The underlying goal is to have less frequent but more stable
"official" releases.
This PR is a proposal for a new release process designed under the
following constraints:
- Reuse as much as possible of the existing infrastructure, to minimize
effort but also chances of disruptions.
- Have the ability to create "snapshot"/"nightly"/... releases that are
not meant for general public consumption, but can still be used by savvy
users without jumping through too many extra hoops (ideally just
swapping in a slightly-weirder version string).
- Have the ability to promote an existing snapshot release to "official"
release status, with as few changes as possible in-between, so we can be
confident that the official release is what we tested as a prerelease.
- Have as much of the release pipeline shared between the two types of
releases, to avoid discovering non-transient problems while trying to
promote a snapshot to an official release.
- Triggerring a release should still be done through a PR, so we can
keep the same approval process for SOC2 auditability.
The gist of this proposal is to replace the current `VERSION` file with
a `LATEST` file, which would have the following format:
```
ef5d32b7438e481de0235c5538aedab419682388 0.13.53-alpha.20200214.3025.ef5d32b7
```
This file would be maintained with a script to reduce manual labor in
producing the version string. Other than that, the process will be
largely the same, with releases triggered by changes to this `LATEST`
and the release notes files.
Version numbers
===============
Because one of the goals is to reduce the velocity of our published
version numbers, we need a different version scheme for our snapshot
releases. Fortunately, most version schemes have some support for that;
unfortunately, the SDK sits at the intersection of three different
version schemes that have made incompatible choices. Without going into
too much detail:
- Semantic versioning (which we chose as the version format for the SDK
version number) allows for "prerelease" version numbers as well as
"metadata"; an example of a complete version string would be
`1.2.3-nightly.201+server12.43`. The "main" part of the version string
always has to have 3 numbers separated by dots; the "prerelease"
(after the `-` but before the `+`) and the "metadata" (after the `+`)
parts are optional and, if present, must consist of one or more segments
separated by dots, where a segment can be either a number or an
alphanumeric string. In terms of ordering, metadata is irrelevant and
any version with a prerelease string is before the corresponding "main"
version string alone. Amongst prereleases, segments are compared in
order with purely numeric ones compared as numbers and mixed ones
compared lexicographically. So 1.2.3 is more recent than 1.2.3-1,
which is itself less recent than 1.2.3-2.
- Maven version strings are any number of segments separated by a `.`, a
`-`, or a transition between a number and a letter. Version strings
are compared element-wise, with numeric segments being compared as
numbers. Alphabetic segments are treated specially if they happen to be
one of a handful of magic words (such as "alpha", "beta" or "snapshot"
for example) which count as "qualifiers"; a version string with a
qualifier is "before" its prefix (`1.2.3` is before `1.2.3-alpha.3`,
which is the same as `1.2.3-alpha3` or `1.2.3-alpha-3`), and there is a
special ordering amongst qualifiers. Other alphabetic segments are
compared alphabetically and count as being "after" their prefix
(`1.2.3-really-final-this-time` counts as being released after `1.2.3`).
- GHC package numbers are comprised of any number of numeric segments
separated by `.`, plus an optional (though deprecated) alphanumeric
"version tag" separated by a `-`. I could not find any official
documentation on ordering for the version tag; numeric segments are
compared as numbers.
- npm uses semantic versioning so that is covered already.
After much more investigation than I'd care to admit, I have come up
with the following compromise as the least-bad solution. First,
obviously, the version string for stable/marketing versions is going to
be "standard" semver, i.e. major.minor.patch, all numbers, which works,
and sorts as expected, for all three schemes. For snapshot releases, we
shall use the following (semver) format:
```
0.13.53-alpha.20200214.3025.ef5d32b7
```
where the components are, respectively:
- `0.13.53`: the expected version string of the next "stable" release.
- `alpha`: a marker that hopefully scares people enough.
- `20200214`: the date of the release commit, which _MUST_ be on
master.
- `3025`: the number of commits in master up to the release commit
(included). Because we have a linear, append-only master branch, this
uniquely identifies the commit.
- `ef5d32b7ù : the first 8 characters of the release commit sha. This is
not strictly speaking necessary, but makes it a lot more convenient to
identify the commit.
The main downsides of this format are:
1. It is not a valid format for GHC packages. We do not publish GHC
packages from the SDK (so far we have instead opted to release our
Haskell code as separate packages entirely), so this should not be an
issue. However, our SDK version currently leaks to `ghc-pkg` as the
version string for the stdlib (and prim) packages. This PR addresses
that by tweaking the compiler to remove the offending bits, so `ghc-pkg`
would see the above version number as `0.13.53.20200214.3025`, which
should be enough to uniquely identify it. Note that, as far as I could
find out, this number would never be exposed to users.
2. It is rather long, which I think is good from a human perspective as
it makes it more scary. However, I have been told that this may be
long enough to cause issues on Windows by pushing us past the max path
size limitation of that "OS". I suggest we try it and see what
happens.
The upsides are:
- It clearly indicates it is an unstable release (`alpha`).
- It clearly indicates how old it is, by including the date.
- To humans, it is immediately obvious which version is "later" even if
they have the same date, allowing us to release same-day patches if
needed. (Note: that is, commits that were made on the same day; the
release date itself is irrelevant here.)
- It contains the git sha so the commit built for that release is
immediately obvious.
- It sorts correctly under all schemes (modulo the modification for
GHC).
Alternatives I considered:
- Pander to GHC: 0.13.53-alpha-20200214-3025-ef5d32b7. This format would
be accepted by all schemes, but will not sort as expected under semantic
versioning (though Maven will be fine). I have no idea how it will sort
under GHC.
- Not having any non-numeric component, e.g. `0.13.53.20200214.3025`.
This is not valid semantic versioning and is therefore rejected by
npm.
- Not having detailed info: just go with `0.13.53-snapshot`. This is
what is generally done in the Java world, but we then lose track of what
version is actually in use and I'm concerned about bug reports. This
would also not let us publish to the main Maven repo (at least not more
than once), as artifacts there are supposed to be immutable.
- No having a qualifier: `0.13.53-3025` would be acceptable to all three
version formats. However, it would not clearly indicate to humans that
it is not meant as a stable version, and would sort differently under
semantic versioning (which counts it as a prerelease, i.e. before
`0.13.53`) than under maven (which counts it as a patch, so after
`0.13.53`).
- Just counting releases: `0.13.53-alpha.1`, where we just count the
number of prereleases in-between `0.13.52` and the next. This is
currently the fallback plan if Windows path length causes issues. It
would be less convenient to map releases to commits, but it could still
be done via querying the history of the `LATEST` file.
Release notes
=============
> Note: We have decided not to have release notes for snapshot releases.
Release notes are a bit tricky. Because we want the ability to make
snapshot releases, then later on promote them to stable releases, it
follows that we want to build commits from the past. However, if we
decide post-hoc that a commit is actually a good candidate for a
release, there is no way that commit can have the appropriate release
notes: it cannot know what version number it's getting, and, moreover,
we now track changes in commit messages. And I do not think anyone wants
to go back to the release notes file being a merge bottleneck.
But release notes need to be published to the releases blog upon
releasing a stable version, and the docs website needs to be updated and
include them.
The only sensible solution here is to pick up the release notes as of
the commit that triggers the release. As the docs cron runs
asynchronously, this means walking down the git history to find the
relevant commit.
> Note: We could probably do away with the asynchronicity at this point.
> It was originally included to cover for the possibility of a release
> failing. If we are releasing commits from the past after they have been
> tested, this should not be an issue anymore. If the docs generation were
> part of the synchronous release step, it would have direct access to the
> correct release notes without having to walk down the git history.
>
> However, I think it is more prudent to keep this change as a future step,
> after we're confident the new release scheme does indeed produce much more
> reliable "stable" releases.
New release process
===================
Just like releases are currently controlled mostly by detecting
changes to the `VERSION` file, the new process will be controlled by
detecting changes to the `LATEST` file. The format of that file will
include both the version string and the corresponding SHA.
Upon detecting a change to the `LATEST` file, CI will run the entire
release process, just like it does now with the VERSION file. The main
differences are:
1. Before running the release step, CI will checkout the commit
specified in the LATEST file. This requires separating the release
step from the build step, which in my opinion is cleaner anyway.
2. The `//:VERSION` Bazel target is replaced by a repository rule
that gets the version to build from an environment variable, with a
default of `0.0.0` to remain consistent with the current `daml-head`
behaviour.
Some of the manual steps will need to be skipped for a snapshot release.
See amended `release/RELEASE.md` in this commit for details.
The main caveat of this approach is that the official release will be a
different binary from the corresponding snapshot. It will have been
built from the same source, but with a different version string. This is
somewhat mitigated by Bazel caching, meaning any build step that does
not depend on the version string should use the cache and produce
identical results. I do not think this can be avoided when our artifact
includes its own version number.
I must note, though, that while going through the changes required after
removing the `VERSION` file, I have been quite surprised at the sheer number of
things that actually depend on the SDK version number. I believe we should
look into reducing that over time.
CHANGELOG_BEGIN
CHANGELOG_END
* GSG: Explain Sandbox and JSON API better and improve wording in intro
Also adapt to lack of sign up.
changelog_begin
changelog_end
* Address comments
* Add documentation for DAML repl and advertise it
This PR adds some simple docs for ``daml repl`` and adds it to the
release notes.
changelog_begin
- [DAML Repl - Experimental] A new ``daml repl`` command that allows
you to use the ``DAML Script`` API interactively. Take a look at the
`documentation <https://docs.daml.com/daml-repl/>`_ for more
information.
changelog_end
* Update docs/source/daml-repl/index.rst
Co-Authored-By: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* s/Repl/REPL/
Co-authored-by: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Rework description of using the app with recent changes
changelog_begin
changelog_end
* Formatting
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Wording
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Address more comments
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Explain UI better in app arch section
Still rough but better than the void of information there currently.
changelog_begin
changelog_end
* Finish sentence
* Reword introduction and explanation of codegen
CHANGELOG_BEGIN
CHANGELOG_END
* Say DAR instead of archive
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Remove 'i'll explain later'
* Include links to sections of this guide
* More links
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update MainView in App Arch section
* Update Feed to MessageList
* Update MessageEdit and MainView components and description in First Feature section
CHANGELOG_BEGIN
CHANGELOG_END
* Underline length
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Add more tests to default run of Ledger API Test Tool
Furthermore, drop TimeIT, which is a sandbox-only property (and tested already as part of its integration tests)
CHANGELOG_BEGIN
[DAML Ledger Integration Kit] Ledger API Test Tool default tests modified. Use --list for the updated list of default tests. Time service test dropped from the suite.
CHANGELOG_END
* Address https://github.com/digital-asset/daml/pull/4561#discussion_r380635979
* Address https://github.com/digital-asset/daml/pull/4561#discussion_r380636989
* Optimize imports
* Only run semantic tests on Canton
* Fix UI intro para
* Tweak UI explanation
* Address some feedback about the intro text
* More changes to wording about DAML
* Small wording fixes to feature section
changelog_begin
changelog_end
* Start drafting new quickstart guide
* Show how to run the app
* Very rough instructions for playing with the app
* Explain core of User template
* Start explaining UI code
* Example of daml react hook (useQuery for allUsers)
* Talk about daml2ts and start describing the new feature
* Start talking about DAML for posts feature
* Add ui file referenced in text
* Start describing changes to UI for Post feature
* Rework feature section wording as Messaging instead of Posts
* Write about additions to MainController
* Talk about new components before the view and controller (bottom up style)
* Describe additions to MainView (may change if we inline MainView into MainController)
* Adapt to create-daml-app removing MainController
* Fix code snippet and try to highlight tsx but fail
* Split guide into sections and rename some sections
* Improve start of app arch section
* Minor edits to code snippets and wording
* Update setup instructions with codegen step
* Update UI components in 'before' code
* Move and update section explaining TS codegen
* Copy in new DAML files
* Update UI code for messaging feature and some of the explanatory text
* Start reworking DAML feature section
* Redo DAML feature section
* Edit initial section
* Edit intro para of arch section
* Edit start of DAML explanation
* Edit template explanation
* Minor edit to UI explanation
* Improve wording of DAML explanation
* Rework sig/obs explanation
* Update User.daml file from create-daml-app and label AddFriend choice
* Explain AddFriend choice better
* Move new GSG to experimental features section
* Undo accidental change to vscode settings
changelog_begin
changelog_end
* Copyright headers
* Revert unwanted change
* Remove typescript highlighting which doesn't work
* Tweak explanation of code generation
* Remove driven
If you click on a section title, we hijack the link to animate
it. However, we did not update the location hash. This makes it quite
annoying to copy links to a specific section.
This PR sets the jquery animate callback to update the hash as
well. I’ve also included a small fix for the link on the section title
which previously produced an error in the JS console since "#" is not
a valid jquery selector.
changelog_begin
changelog_end
* Inserts alias
* ContractStreamStep, extending InsertDeleteStep with a boundary
* partitionBimap, an IDS utility for partitionMap on both inserts and deletes
* make the flow setup of acsFollowingAndBoundary a little clearer
* use partitionBimap to simplify websocket response stream
* make the flow setup of transactionsFollowingBoundary a little clearer
* acsFollowingAndBoundary becoming a ContractStreamStep producer
* insertDeleteStepSource also becomes a ContractStreamStep producer
* porting StepAndErrors to ContractStreamStep
* remove Acs constructor of ContractStreamStep
- it's an interesting idea for future potential features, but not useful
right now so just a needless complication
* adapt convertFilterContracts to presence of LiveBegin marker
* adapt removePhantomArchives to presence of LiveBegin marker
* test that live marker is emitted in the right place
* document liveness marker
* add changelog
CHANGELOG_BEGIN
- [JSON API - Experimental] Add ``{"live": true}`` to WebSocket streams
to mark the beginning of "live" data. See `issue #4461
<https://github.com/digital-asset/daml/issues/4461>`_.
This marker is a placeholder feature; `issue #4509 bookmarks in query
streams <https://github.com/digital-asset/daml/issues/4509>`_ will
obsolete this marker, after which it will no longer be emitted. When
building features on the marker, be aware of this forthcoming
replacement.
CHANGELOG_END
* be a little more prepared for offsets
This should provide a better migration path for people that still rely
on static time by forcing them to make this explicit. Given that both
DAML script and DAML triggers are still experimental, I’m not marking
this as a breaking change
changelog_begin
- [DAML Script - Experimental] The time mode must now always be
specified explicitly. Use ``--static-time`` to recover the previous
default time mode.
- [DAML Triggers - Experimental] The time mode must now always be
specified explicitly. Use ``--static-time`` to recover the previous
default time mode.
changelog_end
* expand documentation on WebSockets subprotocols to a more-visible section
CHANGELOG_BEGIN
CHANGELOG_END
* combine reference in websocket section to auth section
* resection
* subprotocols sometimes called protocols
- suggested by @hurryabit; thanks
We've created a cool video that happens to have the wrong link in it
(missin l in the extension), and changing videos is more expensive than
changing text files.
Also, the current URL is a tad long, so I've added a shorter one.
Note: as this is part of the docs bundle (actually generating an HTML
redirect page), this won't be live until next version is published.
CHANGELOG_BEGIN
CHANGELOG_END
* Support multiple-packages in `damlc ide`
changelog_begin
- [DAML Studio] You can now open DAML Studio in the root of a
multi-package project instead of opening it separately for each
package. Take a look at the documentation for details on how to set
this up.
changelog_end
There are a few caveats here:
1. You need a ``daml.yaml`` in the root of your project directory. I
think this is somewhat sensible but we should add a warning to VSCode
if you open it in a directory that does not have a ``daml.yaml`` (in a
separate PR).
2. Changes are not picked up accross dependencies. This is a larger
undertaking and given the current setup simply impossible (we don’t
know that the source files of one package belong to the DAR referenced
in the ``dependencies`` field of the other package. We can make this a
bit better by at least detecting that the ``.dar`` has changed but
let’s do that separately.
3. Since ``daml init`` runs once on startup, it will run in the root
directory instead of initializing the package db of the individual
packages. This is fixable but will conflict with #4391 so let’s
address this separately.
I’ve added docs to the daml studio section that explain the caveats.
* Use the proper sdk version in lsp-tests
* move InsertDeleteStep to util
* turn append cid argument into a typeclass
* use Cid for appendForgettingDeletes as well
* add secondary data to the deletes in InsertDeleteStep with new covariant tparam
* make StepAndErrors hold ArchivedContracts so ws archives look like exercise archives
* add changelog
CHANGELOG_BEGIN
- [JSON API - Experimental] The format of ``archived`` responses from WebSocket endpoints
has changed to include template IDs, similar to exercise responses.
See `issue #4383 <https://github.com/digital-asset/daml/issues/4383>`_.
CHANGELOG_END
* rename "contracts" to "events" in JSON API exercise response
CHANGELOG_BEGIN
- [JSON API - Experimental] Exercise response field "contracts" renamed to "events".
See `issue #4385 <https://github.com/digital-asset/daml/issues/4385>`_.
CHANGELOG_END
* more events in doc
- pointed out by @leo-da; thanks
* Remove phantom archive when streaming events filtered by contract key
* Add fetch test cases, WIP
* Add fetch test cases, WIP
* Add fetch test cases, WIP
* Add fetch test cases, WIP
* Test case to validate phantom archive filter for stream/fetch
* Use `scan` instead of `statefulMapConcat` to filter out phantom archives
advantage(???) immutable state vs mutable
* make `com.digitalasset.http.WebsocketEndpoints.handleWebsocketRequest` public
so DABL can call it directly, `private[http]` does not work since DABL
is under com.projectdabl, see #4190
* Fixing typos
* Scalafmt
* Scalafmt
* Removing unused function
* Update docs
* Remove unused type alias
* CHANGELOG_BEGIN
[JSON API - Experimental]
- Added streaming version of fetch by key: ``/stream/fetch``. See #4075.
CHANGELOG_END
* Address code review comments
* Add test case with todo to address consistent handling of empty requests
* Fixing merge conflicts
* Addressing code review comments
* Addressing code review comments
Use `partition` instead of consecutive intersect and diff
[JSON API - Experimental]
Added a command line option to allow overriding default TTL.
``--default-ttl <value>`` Optional Time to Live interval to set if not provided in the command. Examples: 30s, 1min, 1h. Defaults to 30 seconds
CHANGELOG_END
* add SearchForeverRequest with one-or-many JSON model
* the least structured way to flatten a query union into a single stream
* add somewhere for indices to go in StreamQuery
* unzipMap utility
* doc Positive
* collect indices for SearchForever predicate, and use only one Map
* interface for rendering positions
* finish propagating positives from the predicate to the rendering phase
* add matchedQueries to every `created` in the searchForever results
* test that matchedQueries indices are included in query stream blocks
* document query union
* add changelog
CHANGELOG_BEGIN
- [JSON API - Experimental] ``/contracts/searchForever`` accepts multiple queries,
and includes with each ``created`` result the ``matchedQueries`` indicating which
queries matched.
See `issue #4363 <https://github.com/digital-asset/daml/pull/4363>`_.
CHANGELOG_END
* remove unused unzipMap
* ensure archive of a key happens to left of create of same key in each WebSocket result block
CHANGELOG_BEGIN
- [JSON API - Experimental] In websocket endpoints, if a 'created' and 'archived' contract
in the same result array share a contract key, the 'archived' is guaranteed to occur
earlier in the array than the 'created'.
See `issue #4354 <https://github.com/digital-asset/daml/issues/4354>`_.
CHANGELOG_END
* by key I mean contract key
- suggested by @hurryabit; thanks
In the integrity concepts, a party is defined as `C`, but referenced
later as `A`. As the rest of the docs use `A` for the party and `C` for
the contract, this seems to be a mistake. This corrects that
inconsistency.
This commit also clarifies a sentence and fixes a typo.
CHANGELOG_BEGIN
CHANGELOG_END
* Updated roadmap for Jan. 2020
* Removed Canton update
* Wording fixes
CHANGELOG_BEGIN
Removed previous roadmap (September 2019)
Added new one for January 2020
CHANGELOG_END
* Release 0.13.50
changelog_begin
changelog_end
* force clean build on Windows
apparently our cache is borked again …
* undo windows changes
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* in searchForever, warn on unknown template IDs as long as at least one is known
* remove unused resolveTemplateId
* factor out WS request parts in WS integration test
* factor out IOU create
* test early template ID warning in searchForever stream
* document warnings case for searchForever
CHANGELOG_BEGIN
- [JSON API - Experimental] Precede stream with warnings of unknown template IDs, if any,
rather than failing outright.
See `issue #4290 <https://github.com/digital-asset/daml/issues/4290>`_.
CHANGELOG_END
Before, we didn't mention in the docs that sum-types need to derive from
(Eq,Show) if they are to be used as arguments of templates or choices.
Now we do.
CHANGELOG_BEGIN
CHANGELOG_END
* Introduce new JWT payload format
... the reader still supports old formats
CHANGELOG_BEGIN
[Sandbox] The sandbox uses a new payload format for authentication tokens (JWTs).
The old format is deprecated, but still works.
[JSON API] The HTTP JSON API now uses the same payload format for authentication tokens as the sandbox.
The old format is deprecated, but still works.
CHANGELOG_END
* Add helper function for getting token party
* Support sandbox tokens in JSON API
* Add warning for deprecated formats
* Update documentation
* Add explicit test for new format
* Update JSON API documentation
* Fix test
Prohibit contract IDs in contract keys and add key maintainers to exercises
CHANGELOG_BEGIN
- [DAML-LF] Prohibit contract IDs in contract keys completely. Previously, creating keys containing absolute (but not relative) contract IDs was allowed, but `lookupByKey` on such a key would crash.
CHANGELOG_END
Co-authored-by: Remy <remy.haemmerle@daml.com>
Co-authored-by: Stephen Compall <scompall@nocandysw.com>
The docs build is currently not reproducible as it include to-the-minute
time-of-build information. It also includes some Sphinx binary caches
which I suppose will also not be reproducible (though I have not checked
the details there).
This commit attempts to remove all sources of non-reproducibility from
the docs build, though this is hard to test without having a stable,
older release to compare with.
CHANGELOG_BEGIN
CHANGELOG_END
* Implement exercise by key
ExerciseCommand got a new required element: `reference` of polymorphic type.
* Add test case: exercise Archive by contractKey
* Add test case for ExerciseCommand JSON protocol
* flatten contract reference in ExerciseCommand JSON protocol
* formatting
* Update exercise by key
* Update documentation
CHANGELOG_BEGIN
- [JSON API - Experimental] Support Exercise by Key. See #4009.
CHANGELOG_END
* Address code review comments
* for searchForever, use a similar response format to exercise results
CHANGELOG_BEGIN
- [JSON API - Experimental] Response format in ``searchForever`` changed to be more like ``exercise``.
See `issue #4072 <https://github.com/digital-asset/daml/issues/4072>`__.
CHANGELOG_END
* typo left from add->created replacement
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* in query argument, rename %templates to templateIds, and nest query under 'query' field
CHANGELOG_BEGIN
- [JSON API - Experimental] In 'search' endpoint arguments, %templates is now templateIds.
Additionally, all contract query fields must occur under 'query'.
See `issue #3450 <https://github.com/digital-asset/daml/issues/3450>`__.
CHANGELOG_END
* fix other old query format usages
* minor improvements on websocket and add websocketIT
* add it for websocket, and support config args
* add one more test case
* make ws config optional
* avoid fromTryCatchNonFatal when derivative already exists
* spelling and missing type parameter
* use richer Matchers in WebsocketServiceIntegrationTest
* scalafmt
* IDEs may love braces but we don't
* utility for simplifying FanOutShape2s; use in ContractsService
* split matSecondOut into generalization; make compile again
* match matSecondOut utility with standard utility methods
* spelling
* getCreatesAndArchivesSince doesn't need to query the transaction boundary
* boolean newtype utility
* split up transactionMessageHandler into components
* decodeAndParsePayload passes through the Jwt
* clean up config and default WS config
* take multiple template IDs for insertDeleteStepSource
* replace websocket return with {errors, add, remove}, based on acsFollowingAndBoundary
* parse ValuePredicate in websocket
* remove unused lfvToJson
* nominal internal state for emitted WS steps-and-errors
* missing copyright headers
* add filtering to convertFilterContracts
* add step conflation to websocket output
* move conflation to static function
* rename /transactions endpoint to /contracts/searchForever
* empty requests are not allowed; numConns is per-service
* option for GetCreatesAndArchiveSince to not terminate; use in WebsocketService
* start of searchForever documentation
* stub searchForever longer test
* use valueOr
* don't run all other tests again with WebsocketServiceIntegrationTest
* start of websocket delta test
* solve init order problem with AbstractHttpServiceIntegrationTestFuns
- previous order caused test set to be cleared; mutation is intuitive
for sure!
* full flow test, fails for lack of create/exercise yet
* passing full flow test
* full documentation examples
* rename add/remove to created/archived
* cleaner NewBoolean.Named
* document heartbeats
* document subprotocols for searchForever
* note about the tests mysteriously terminating
* ensure create has happened before attempting query in tests
* reorganize multi-step WS test so its states and assertions are clearer
* filter out heartbeats in raw string tests
* factor out ContractDelta
* make exercisePayload easier to read
* filter out heartbeats in conversation test
* remove type lambda
* accept chunked queries
- clients may not be in control of how query bodies are delivered to the
server, so we should be agnostic in that respect
* add changelog
CHANGELOG_BEGIN
- [JSON API - Experimental] WebSocket contract search at ``/contracts/searchForever``.
See `issue #3936 <https://github.com/digital-asset/daml/pull/3936>`_.
CHANGELOG_END
* adapt to #3991 template ID strings
* adapt to #3971 argument -> payload
* fix create command for test (string template ID redux)
* adapt to #4014 ResolveTemplateId change
* update copyright headers
* rebuild WS example output to match latest changes
- thanks @leo-da
* SeqOps is not a safe name
* don't need breakOut anymore
* use util library form of partitionMap
- thanks @leo-da for pointing it out
Co-authored-by: lima-da <54044170+lima-da@users.noreply.github.com>
* WIP
* test cases updated
* `PackageService.resolveTemplateId` returns `Option[TemplateId]` now
used to return `Error \/ TemplateId`. There are scenarios when unresolved
TemplateID is a warning and not an error, which was the initial design
* CHANGELOG_BEGIN
[JSON API - Experimental]
``/contracts/search`` endpoint reports unresolved template IDs as warnings, see #3771::
{
"warnings": {
"unknownTemplateIds": ["UnknownModule:UnknownEntity"]
},
"result": [{...}, ...],
"status": 200
}
CHANGELOG_END
* Addressing codereview comments
* `partitionMap` is now part of `http.util.Collections.SeqOps`
* Implement heartbeat messages in trigger runner.
* Add heartbeat to Daml.Trigger
CHANGELOG_BEGIN
- [DAML Triggers - Experimental] DAML triggers can now configure a heartbeat message to be sent at regular time interval.
CHANGELOG_END
* Add DAML trigger heartbeat test-case
* ./fmts.h
Co-authored-by: Andreas Herrmann <andreash87@gmx.ch>
* test cases: domain.TemplateId JSON serialization to JsString
* JSON protocol updated
* Fixing json-api test cases
* test cases: domain.TemplateId JSON serialization to JsString
* JSON protocol updated
* Fixing json-api test cases
* Adapt daml2ts and support libraries
* Update documentation
CHANGELOG_BEGIN
[JSON API - Experimental]
- Use JSON string to encode template IDs. Use colon (``:``) to separate parts of the ID.
The request format, with optional package ID:
- "<module>:<entity>"
- "<package ID>:<module>:<entity>"
The response always contains fully qualified template ID in the format:
- "<package ID>:<module>:<entity>"
See #3647.
CHANGELOG_END
* Minor documentation formatting changes.
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* ECDA512 algorithm support
* ECDA512
* happy day test for ECDA512 algorithm
* failure test for wrong key for ECDA512 algorithm
* add ability to use EC cert file
* update docs
* scalafmt
* Correct documentation
CHANGELOG_BEGIN
[Ledger API Authorization] Support elliptic curve algorithm for JWT verification
CHANGELOG_END
Signed-off-by: Brian Healey <brian.healey@digitalasset.com>
* correct docs warning
* Aligning DB contract table with domain.ActiveContract class
adding key,signatories, observers and agreement_text to DB contract table
removing witnessParties
Reading signatories and observers from contracts table
Updating doc, removing witnessParties
Address code review comments, thanks @S11001001
CHANGELOG_BEGIN
[JSON API - Experimental]
- Align ``contract`` table with ``domain.ActiveContract`` class.
The database schema has changed, if using ``--query-store-jdbc-config``,
you must rebuild the database by adding ``,createSchema=true``. See #3754.
- ``witnessParties`` field is removed from all JSON responses.
CHANGELOG_END
* Fix TypeScript domain models
remove witnessParties and workflowId fields. workflowId has be removed
from JSON output a while ago.
* Add Zsh completions for the assistant
This is slightly more annoying for users since at least on Linux there
doesn’t seem to be a user-writable directory that is in `$fpath` by
default. I think on Zsh we could probably write them to
/usr/local/share/zsh/site-functions but I’d rather avoid platform
specific logic here. I would expect that Zsh users are usually
somewhat comfortable with modifying the config and this also matches
other installation instructions, e.g.,
https://github.com/zsh-users/zsh-completions#manual-installation.
On the plus side, the completions look significantly nicer in Zsh
since they include the description of commands.
CHANGELOG_BEGIN
- [DAML Assistant] Zsh completions for the DAML Assistant are now
installed as part of ``daml install``. To activate them you need to
add ``~/.daml/zsh`` to your ``$fpath``, e.g., by adding
``fpath=(~/.daml/zsh $fpath)`` to the beginning of your ``~/.zshrc``
before you call ``compinit``.
CHANGELOG_END
* Fix tests
* Update daml-assistant/src/DA/Daml/Assistant/Install/Completion.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
Co-authored-by: associahedron <231829+associahedron@users.noreply.github.com>
* Improve bash completions for daml-assistant.
* Install bash completion script automatically
* Better default logic for bash completions
* specifically -> explicitly
* Copyright headers
* Better hook logic and refactoring
* Handle non-standard installations more robustly.
* Handle CI env & add changelog note.
CHANGELOG_BEGIN
- [DAML Assistant] Bash completions for the DAML assistant are now
available via ``daml install``. These will be installed automatically
on Linux and Mac. If you use bash and have bash completions installed,
these bash completions let you use the tab key to autocomplete
many DAML Assistant commands, such as ``daml install`` and
``daml version``.
CHANGELOG_END
* Mention bash completion in assistant docs
* Remove promises
* Change variant json encoding,
adding integration test
* Add DamlLfTypeLookup dependencies
* Add MetadataReader
* Add test WIP
* Add serialize test cases
* Add serialize test cases, WIP
* Test for variant encoding decoding
* Solving merge conflicts
* Updating roundtrip test
* Minor cleanup
* Addressing code review comments
Add JsonVariant custom matcher
* Update specification
* Update link
* Add test case, WIP
* Add proper template key resolution
* Got rid of choice record ID resolution, resolving choice type and key type
* Fixing logging
* Add Contract Key decoding tests
* cleanup
* cleanup
* Update JSON variant encoding tests
* Add more contract key JSON decoding tests
* Fix variant JSON encoding
* Change value predicate to support new variant encoding
* Change value predicate to support new variant encoding
* Add lookup by contract key test case
where contract key contains variant and record
Add `requiredResource` to bazel utils
CHANGELOG_BEGIN
- [JSON API - Experimental] Change variant JSON encoding. The new format is ``{ tag: data-constructor, value: argument }``.
For example, if we have: ``data Foo = Bar Int | Baz``, these are all valid JSON encodings for values of type Foo:
- ``{"tag": "Bar", "value": 42}``
- ``{"tag": "Baz", "value": {}}``
See #3622
- [JSON API - Experimental] Fix ``/contracts/lookup` find by contract key.
- [JSON API - Experimental] Fix ``/command/exercise`` to support any LF type as a choice argument.
See #3390
CHANGELOG_END
* minor cleanup
* Fix copy/paste
* Renaming
* Got rid of DAML LF identifier resolution
resolving DAML LF Type based on command type
* Address code review comments, thanks @S11001001
* Address code review comments, thanks @S11001001
Do not include any error handling here; this partial function should
only match the successful case, JsonVariant.
* Address code review comments, thanks @S11001001
comment
* Address code review comments, thanks @S11001001
using `JsonVariant` for variant encoding/decoding
* Address code review comments, thanks @S11001001
replace `find` and `map` chain with collectFirst
* Update docs/source/json-api/lf-value-specification.rst
Co-Authored-By: Stephen Compall <stephen.compall@daml.com>
Co-authored-by: Stephen Compall <scompall@nocandysw.com>
* Update ledger-api-test-tool readme instructions for daml docs
* remove STDERR / STDOUT pipe to file examples
* address review feedback
* Add commentary on tests which can be excluded for an --all-tests run because of clock, stress or mutation issues
* Add time to Trigger update function
CHANGELOG_BEGIN
- [DAML Triggers - Experimental] Expose timestamp in triggers.
See `#3612 <https://github.com/digital-asset/daml/issues/3612>`__.
CHANGELOG_END
* Add triggers time test
* Update trigger docs
* Lookup by Contract ID and Contract Key is WIP
* factor out "contract ID or key" JSON decoding
- adapted from fc132253 (#2695)
* Resolving conflicts
* Resolving conflicts
* Lookup by contract ID works
* Testing new contract created by IOU_Transfer can be looked up
* error if key and contractId specified for lookup at the same time
* Lookup by contract key test
* Lookup docs
* re-format with `./fmt.sh`
* minor cleanup
CHANGELOG_BEGIN
- [JSON API - Experimental] Fix and document ``/contracts/lookup`` endpoint. See #3755.
CHANGELOG_END