* Expand the reference for the TypeScript library
The content is more or less there, I expanded some explanations and added a
reference to `create-daml-app`.
changelog_begin
changelog_end
* Fix link
* Update docs/source/app-dev/bindings-ts/index.rst
Co-authored-by: carrielaben-da <91496516+carrielaben-da@users.noreply.github.com>
* Update docs/source/app-dev/bindings-ts/index.rst
Co-authored-by: carrielaben-da <91496516+carrielaben-da@users.noreply.github.com>
* Update docs/source/app-dev/bindings-ts/index.rst
Co-authored-by: carrielaben-da <91496516+carrielaben-da@users.noreply.github.com>
Co-authored-by: Jennifer Whyte <42810081+jwhyte-da@users.noreply.github.com>
Co-authored-by: carrielaben-da <91496516+carrielaben-da@users.noreply.github.com>
* add getContractTypeId to Contract
* add getContractTypeId to Template
* generate getCompanion methods for every Template
* hide ContractId#getCompanion
* test getting from interface Contract
* test getting from template and template contract
* add changelog
CHANGELOG_BEGIN
- [Java codegen] Template payloads and contract instances (including for
interface views) now support a ``getContractTypeId`` method that
returns the template or interface ID.
CHANGELOG_END
The problem is that `damlcForTarget tools depLfVer` could return an older damlc
than needed for `targetLfVer`.
The reason this didn't fail before is that the legacy damlc supports up to
LF=1.14, and `lfVersionTestPairs` never had `depLfVer < 1.14 && targetLfVer > 1.14`
changelog_begin
changelog_end
* 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>
