* Add intro page for off-ledger automation with Daml
This is meant as a page to introduce Daml Script (as an off-ledger automation
tool) and Daml Triggers. This will require this page to be added to the
table of contents in the appropriate place in a separate PR in the
documentation repository.
changelog_begin
changelog_end
* Apply suggestions from code review
Co-authored-by: carrielaben-da <91496516+carrielaben-da@users.noreply.github.com>
* Rephrase, reformat
Co-authored-by: carrielaben-da <91496516+carrielaben-da@users.noreply.github.com>
@dylant-da is taking care of [testing](https://github.com/digital-asset/daml/blob/main/release/RELEASE.md) today's release, so they get pushed back to the end of the line.
Please do not merge this before the release is fully tested.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines Daml Build <support@digitalasset.com>
* pre
* address Stephen's comments
* get command from Update<R>
* to public
* generateDeprecatedFlattenedStaticExerciseByKeyMethod
* Ensure interface generation uses package prefixes
CHANGELOG_BEGIN
- [BUGFIX] Interface generation now respects package prefixes argument. This means generated interfaces will now be placed in the right subpackages.
CHANGELOG_END
* packagePrefixes
* fix what exercise* returning update breaks
* doc
* format
* WIP
* address comments
* compile
* added 2 utility methods in CommandClient for getting the result of submitted commands to demonstrate value of Update R
* address some comments
* update line number
* rename
* fold for create and exercise cases
* move transaction logic to fold
* revert config
* argTypeDecoder
* add internal api doc
* rename to Choice
* quickstart doc
* use update
* address comment
* address comment on compactability issue
* move abstract static class FoldUpdate<Z> to Update<>
* change command clients to use List<? extends HasCommands> instead of List<Command>
* move fold to update
* compare commands
* Update docs/source/app-dev/bindings-java/quickstart.rst
Co-authored-by: Raymond Roestenburg <98821776+ray-roestenburg-da@users.noreply.github.com>
* address comments
* address comments
* add changelog
CHANGELOG_BEGIN
- [Java codegen] Replace return type to Update<R> of exercise and create methods in Java codegen
CHANGELOG_END
Co-authored-by: Fayi Femi-Balogun <fayimora.femibalogun@digitalasset.com>
Co-authored-by: Raymond Roestenburg <98821776+ray-roestenburg-da@users.noreply.github.com>
This allows additional chapters to be added in the future without disrupting existing pages.
[CHANGELOG_BEGIN]
[CHANGELOG_END]
Co-authored-by: carrie-laben <91496516+carrie-laben@users.noreply.github.com>
* Remove mention of FunctionalDependencies as data-dependencies caveat
FunctionalDependencies in data-dependencies have been supported since #7698
changelog_begin
changelog_end
* Remove mention of advanced type system features as data-dependencies caveat
module DA.Generics and language extension DeriveGeneric have long been removed
from the language, and I couldn't think of other similar "advanced type
system features" that work for plain dependencies but not for data-dependencies.
* Extend list of data dependable extensions
* use domain.Party instead of String in jwtForParties, headersWithPartyAuth
CHANGELOG_BEGIN
CHANGELOG_END
* use domain.Party instead of String in headersWithPartyAuth
* fix sharedAccountCreateCommand and some corners
The development of the Helm Chart halted after 1.18.x to make room
for other priorities, including a better documentation of operational
concerns as a way for users to bridge the gap we were originally
trying to fill with the Helm Chart. The pages remained in the
documentation as we were hoping for the feature to go back into
active development but since the feature is not actually working and
we do not have short term plans to revive it (and possibly not in
the current form) it is better to just yank the content until
we have a better understanding of where we want this to go.
If by any chance we want to restore the feature more or less in
its current form, restoring this document from a previous version
requires very little effort while simultaneously we do not cause
confusion by documenting a feature that does not work with the
current version.
changelog_begin
changelog_end
"ones whose values can be written in a text or binary format" is a very
misleading definition to give for "serializable types" in the context of
Daml.
When we say "serializable" in Daml, we *always* mean the formal Daml-LF
definition given in "Serializable types" in daml-lf-1.rst, i.e. ⊢ₛ τ, or
"τ derives from the rules S". That is also what we mean here.
There are many examples of types "whose values can be written in a text
or binary format", that are nevertheless *not* derivable from S.
As it says in daml-lf-1.rst, "serializable types are the types whose
values can be persisted on the ledger". So we copy over something like
that language.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: carrielaben-da <91496516+carrielaben-da@users.noreply.github.com>
* Provide an introduction to the Canton Console
The purpose of this page is to expose developers to the availability of the Canton Console
as part of the SDK to interact with the Sandbox, provide tips on how to consult the built-in
documentation and provide further pointers to the in-depth documentation page part of the
Canton user manual.
changelog_begin
changelog_end
* Apply suggestions from code review
Co-authored-by: carrielaben-da <91496516+carrielaben-da@users.noreply.github.com>
Co-authored-by: carrielaben-da <91496516+carrielaben-da@users.noreply.github.com>
* slf4j-api:1.7.36, logback:1.2.11
CHANGELOG_BEGIN
CHANGELOG_END
* Use HikariCP 4.x, as 5.x pulls in slf4j-api 2.x as well
* Revert Hikari CP to 3.4.5 since 4+ brings slf4j-api 2+
Co-authored-by: Tudor Voicu <tudor.voicu@digitalasset.com>
* move resolveTemplateId to ContractTypeIdMap
* replace the contractTypeIdMap with an interfaceIdMap
* remove ResolveContractTypeId's type parameter, replace with Overload relation
* define the ContractTypeId resolver to be overload, ctid-type-sensitive
* remove AnyKind usages
* remove resolveTemplateId argument-passing
* demonstrate very strange inserted cast
`x.packageId` inserts a cast on `x` to `ContractTypeId.Template`, for
which there is no local evidence
* fix compiler-inserted cast problem
- Why does this fix it? Who knows!
* failure of template ID resolution no longer fails later than we want
* fix resolution of interface IDs for websocket queries
CHANGELOG_BEGIN
- [JSON API] Some error messages have been corrected to no longer
confuse interface IDs with template IDs, based on what varieties of
contract type ID the endpoint in question supports.
CHANGELOG_END
* mention #15293 where relevant
* define templateId_ generically
* remove unused utilities for old resolver