mirror of
https://github.com/digital-asset/daml.git
synced 2024-09-19 16:57:40 +03:00
Check closing quotes (#7528)
* Missing closing quote in docs CHANGELOG_BEGIN CHANGELOG_END * add Bash script to check missing quotes in docs CHANGELOG_BEGIN CHANGELOG_END * add whitelist * fix comment * add CI job CHANGELOG_BEGIN CHANGELOG_END * add CI job to azure pipeline * use devenv in azure-pipelines.yml Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> * remove unnecessary yml * fix quotes in Bifunctor.daml * add check to BUILD.bazel with extended whitelist * refactor: call bash script from BUILD.bazel * Revert "use devenv in azure-pipelines.yml" This reverts commit28ab2c70fb. * Revert "add CI job to azure pipeline" This reverts commit0eaa5188fe. * filter whitelist in output too * Update docs/scripts/check-closing-quotes.sh.whitelist Co-authored-by: Bernhard Elsner <40762178+bame-da@users.noreply.github.com> * fix Bifunctor.daml quotes * Update docs/scripts/check-closing-quotes.sh.whitelist Co-authored-by: Bernhard Elsner <40762178+bame-da@users.noreply.github.com> * use ~ instead of ` for section titles * rename to allowlist * revert Bifunctor quote changes back to 3 backticks * fix filename * Remove line breaks in quotes (#7550) * remove line breaks in quotes CHANGELOG_BEGIN CHANGELOG_END * remove line breaks in quotes CHANGELOG_BEGIN CHANGELOG_END * README: avoid line breaks * merge rename * revert: use triple backticks in Bifunctor Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> Co-authored-by: Bernhard Elsner <40762178+bame-da@users.noreply.github.com>
This commit is contained in:
Richard Kapolnai
GitHub
parent
e6c43c798f
commit
40c1cd5893
@ -395,6 +395,8 @@ genrule(
|
||||
"//templates:create-daml-app-docs",
|
||||
"//templates:create-daml-app-test-resources/index.test.ts",
|
||||
"@daml-cheat-sheet//:site",
|
||||
":scripts/check-closing-quotes.sh",
|
||||
":scripts/check-closing-quotes.sh.allow",
|
||||
],
|
||||
outs = ["html-only.tar.gz"],
|
||||
cmd = ("""
|
||||
@ -420,6 +422,10 @@ genrule(
|
||||
mkdir $$CODE_DIR/testing
|
||||
cp $(location //templates:create-daml-app-test-resources/index.test.ts) $$CODE_DIR/testing
|
||||
|
||||
if ! docs/scripts/check-closing-quotes.sh . docs/scripts/check-closing-quotes.sh.allow; then
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Build with Sphinx
|
||||
cd build
|
||||
sed -i "s,__VERSION__,"{sdk}"," docs/configs/html/conf.py
|
||||
|
||||
@ -13,6 +13,7 @@ To edit documentation:
|
||||
|
||||
Don't forget you need to add your file to the `toctree` in `/docs/source/index.rst` *and* `/docs/configs/pdf/index.rst`.
|
||||
- **Make sure you preview** before you push.
|
||||
- Don't insert line-breaks inside inline literals. Building preview will treat this as an error.
|
||||
|
||||
### Generated documentation
|
||||
|
||||
|
||||
37
docs/scripts/check-closing-quotes.sh
Executable file
37
docs/scripts/check-closing-quotes.sh
Executable file
@ -0,0 +1,37 @@
|
||||
#!/usr/bin/env bash
|
||||
# Copyright (c) 2020 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
|
||||
# SPDX-License-Identifier: Apache-2.0
|
||||
|
||||
# Check for invalid quote usage such as "variable `x``"
|
||||
|
||||
DIR="$1"
|
||||
ALLOWLIST="$2"
|
||||
|
||||
if [[ $# -ne 2 ]]
|
||||
then
|
||||
echo "Usage: $0 directory allow-list"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
if ! test -f "$ALLOWLIST"; then
|
||||
echo ERROR: Allow-list file not found: "$ALLOWLIST"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
ERRORS=0
|
||||
REGEX='^(?!([^`]*(((`[^`]*`)|(``[^`]*``))[^`]*)*)$$)'
|
||||
|
||||
while read FILE; do
|
||||
if grep --invert-match --file="$ALLOWLIST" "$FILE" | grep --quiet --perl-regexp "$REGEX"; then
|
||||
echo Quotation error in "\`$FILE'":
|
||||
grep --invert-match --file="$ALLOWLIST" "$FILE" | grep --perl-regexp "$REGEX"
|
||||
echo
|
||||
ERRORS=$((ERRORS+1))
|
||||
fi
|
||||
done <<< $(find "$DIR" -name '*.rst')
|
||||
|
||||
if [ $ERRORS -gt 0 ]; then
|
||||
echo "ERROR: $ERRORS file(s) found with errors, see above."
|
||||
echo "You can add lines to \`$ALLOWLIST' to ignore false positives."
|
||||
exit 1
|
||||
fi
|
||||
6
docs/scripts/check-closing-quotes.sh.allow
Normal file
6
docs/scripts/check-closing-quotes.sh.allow
Normal file
@ -0,0 +1,6 @@
|
||||
# Every line of this file is a regex. Each regex is ignored when checking unpaired quotes.
|
||||
# You can add comments to this file if the comment line is unlikely to match.
|
||||
# Just do not add too generic patterns (such as empty line) because they would filter out too many lines.
|
||||
_\\ \\/ _ `/ _ \\/ _ / _ \\/ _ \\\\ \\ /
|
||||
/ / _ `/ |/ / / _ `/ _ `/ __/ _ \\/ __/
|
||||
-- ```
|
||||
@ -32,8 +32,8 @@ architecture, providing you with an excellent starting point for your own applic
|
||||
Backend
|
||||
~~~~~~~
|
||||
|
||||
The backend for your application can be any DAML ledger implementation running your DAR (:ref:`DAML
|
||||
Archive <dar-file-dalf-file>`) file.
|
||||
The backend for your application can be any DAML ledger implementation running your DAR
|
||||
(:ref:`DAML Archive <dar-file-dalf-file>`) file.
|
||||
|
||||
We recommend using the :ref:`DAML JSON API <json-api>` as an interface to your frontend. It is
|
||||
served by the HTTP JSON API server connected to the ledger API server. It provides simple HTTP
|
||||
@ -49,17 +49,17 @@ with a JSON API server by running
|
||||
|
||||
in the root of the project. This is the most simple DAML ledger implementation. Once your
|
||||
application matures and becomes ready for production, the ``daml deploy`` command helps you deploy
|
||||
your frontend and DAML artifacts of your project to a production ledger. See :ref:`Deploying to DAML
|
||||
Ledgers <deploy-ref_overview>` for an in depth manual for specific ledgers.
|
||||
your frontend and DAML artifacts of your project to a production ledger. See
|
||||
:ref:`Deploying to DAML Ledgers <deploy-ref_overview>` for an in depth manual for specific ledgers.
|
||||
|
||||
Frontend
|
||||
~~~~~~~~
|
||||
|
||||
We recommended building your frontend with the `React <https://reactjs.org>`_ framework. However,
|
||||
you can choose virtually any language for your frontend and interact with the ledger via :ref:`HTTP
|
||||
JSON <json-api>` endpoints. In addition, we provide support libraries for :ref:`Java
|
||||
<java-bindings>` and :ref:`Scala <scala-bindings>` and you can also interact with the :ref:`gRPC API
|
||||
<grpc>` directly.
|
||||
you can choose virtually any language for your frontend and interact with the ledger via
|
||||
:ref:`HTTP JSON <json-api>` endpoints. In addition, we provide support libraries for
|
||||
:ref:`Java <java-bindings>` and :ref:`Scala <scala-bindings>` and you can also interact with the
|
||||
:ref:`gRPC API <grpc>` directly.
|
||||
|
||||
|
||||
We provide two libraries to build your React frontend for a DAML application.
|
||||
@ -165,14 +165,14 @@ between such eventually consistent Ledger API endpoints to tolerate server
|
||||
failures. You can do this using the following two steps.
|
||||
|
||||
First, your application must keep track of the last ledger offset received
|
||||
from the :ref:`transaction service <transaction-service>` or the :ref:`command
|
||||
completion service <command-completion-service>`. When switching to a new
|
||||
from the :ref:`transaction service <transaction-service>` or the
|
||||
:ref:`command completion service <command-completion-service>`. When switching to a new
|
||||
Ledger API endpoint, it must resume consumption of the transaction (tree)
|
||||
and/or the command completion streams starting from this last received
|
||||
offset.
|
||||
|
||||
Second, your application must retry on ``OUT_OF_RANGE`` errors (see `gRPC
|
||||
status codes <https://grpc.github.io/grpc/core/md_doc_statuscodes.html>`_)
|
||||
Second, your application must retry on ``OUT_OF_RANGE`` errors (see
|
||||
`gRPC status codes <https://grpc.github.io/grpc/core/md_doc_statuscodes.html>`_)
|
||||
received from a stream subscription -- using an appropriate backoff strategy
|
||||
to avoid overloading the server. Such errors can be raised because of eventual
|
||||
consistency. The Ledger API endpoint that the application is newly subscribing
|
||||
|
||||
@ -131,7 +131,7 @@ Connecting securely
|
||||
===================
|
||||
|
||||
The Java bindings library lets you connect to a DAML Ledger via a secure connection. The builders created by
|
||||
``DamlLedgerClient.newBuilder`` default to a plaintext connection, but you can invoke ``withSslContext` to pass an ``SslContext``.
|
||||
``DamlLedgerClient.newBuilder`` default to a plaintext connection, but you can invoke ``withSslContext`` to pass an ``SslContext``.
|
||||
Using the default plaintext connection is useful only when connecting to a locally running Sandbox for development purposes.
|
||||
|
||||
Secure connections to a DAML Ledger must be configured to use client authentication certificates, which can be provided by a Ledger Operator.
|
||||
|
||||
@ -454,7 +454,7 @@ The ``submit`` function used in this scenario tries to perform a transaction and
|
||||
.. Interact with the ledger through the command line
|
||||
*************************************************
|
||||
|
||||
All interaction with a DAML ledger, be it sandbox or any other implementation, happens via the :doc:`Ledger API </app-dev/ledger-api>``. It is based on `gRPC <https://grpc.io/>`_.
|
||||
All interaction with a DAML ledger, be it sandbox or any other implementation, happens via the :doc:`Ledger API </app-dev/ledger-api>`. It is based on `gRPC <https://grpc.io/>`_.
|
||||
|
||||
The Navigator uses this API, as will any :ref:`custom integration <quickstart-application>`.
|
||||
|
||||
@ -483,8 +483,7 @@ To compile the Java integration for the quickstart application, we first need to
|
||||
Once the code has been generated, we can now compile it using ``mvn compile``.
|
||||
|
||||
Now start the Java integration with ``mvn exec:java@run-quickstart``. Note that
|
||||
this step requires that the sandbox started :ref:`earlier
|
||||
<quickstart-sandbox>` is running.
|
||||
this step requires that the sandbox started :ref:`earlier <quickstart-sandbox>` is running.
|
||||
|
||||
The application provides REST services on port ``8080`` to perform basic operations on behalf on ``Alice``.
|
||||
|
||||
|
||||
@ -8,8 +8,8 @@ JavaScript Client Libraries
|
||||
|
||||
The JavaScript Client Libraries are the recommended way to build a frontend for a DAML application.
|
||||
The :doc:`JavaScript Code Generator <daml2js>` can automatically generate JavaScript containing metadata about DAML packages that is required to use these libraries.
|
||||
We provide an integration for the `React <https://reactjs.org>`_ framework with the `@daml/react
|
||||
<daml-react/index.html>`_ library. However, you can choose any JavaScript/TypeScript based framework
|
||||
We provide an integration for the `React <https://reactjs.org>`_ framework with the
|
||||
`@daml/react <daml-react/index.html>`_ library. However, you can choose any JavaScript/TypeScript based framework
|
||||
and use the `@daml/ledger <daml-ledger/index.html>`_ library directly to connect and interact with a
|
||||
DAML ledger via its :ref:`HTTP JSON API <json-api>`.
|
||||
|
||||
|
||||
@ -65,7 +65,7 @@ Then, `act'` happens after `act`.
|
||||
.. _da-model-contract-consistency:
|
||||
|
||||
Contract consistency
|
||||
````````````````````
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Contract consistency ensures that contracts are used after they have been created and before they are consumed.
|
||||
|
||||
@ -132,7 +132,7 @@ of contracts `Iou Bank P` and `PaintAgree P A`.
|
||||
.. _da-model-key-consistency:
|
||||
|
||||
Key consistency
|
||||
```````````````
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Contract keys introduce a key uniqueness constraint for the ledger.
|
||||
To capture this notion, the contract model must specify for every contract in the system whether the contract has a key and, if so, the key.
|
||||
@ -197,14 +197,14 @@ Key consistency extends to actions, transactions and lists of transactions just
|
||||
.. _da-model-ledger-consistency:
|
||||
|
||||
Ledger consistency
|
||||
``````````````````
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Definition »ledger consistency«
|
||||
A ledger is **consistent** if it is consistent for all contracts and for all keys.
|
||||
|
||||
|
||||
Internal consistency
|
||||
````````````````````
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
The above consistency requirement is too strong for actions and transactions
|
||||
in isolation.
|
||||
For example, the acceptance transaction from the paint offer example is not consistent as a ledger, because `PaintOffer A P Bank`
|
||||
@ -331,9 +331,9 @@ Authorization
|
||||
+++++++++++++
|
||||
|
||||
The last criterion rules out the last two problematic examples,
|
||||
:ref:`an obligation imposed on a painter
|
||||
<obligation-imposed-on-painter>`, and :ref:`the painter stealing
|
||||
Alice's money <painter-stealing-ious>`. The first of those is visualized below.
|
||||
:ref:`an obligation imposed on a painter <obligation-imposed-on-painter>`,
|
||||
and :ref:`the painter stealing Alice's money <painter-stealing-ious>`.
|
||||
The first of those is visualized below.
|
||||
|
||||
.. image:: ./images/invalid-obligation.svg
|
||||
:align: center
|
||||
@ -348,7 +348,7 @@ and imposed on the contract's *signatories*.
|
||||
.. _da-signatories-agreements-maintainers:
|
||||
|
||||
Signatories, Agreements, and Maintainers
|
||||
````````````````````````````````````````
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
To capture these elements of real-world contracts, the **contract model**
|
||||
additionally specifies, for each contract in the system:
|
||||
@ -403,7 +403,7 @@ signatories yields the image below.
|
||||
.. _da-ledgers-authorization-rules:
|
||||
|
||||
Authorization Rules
|
||||
```````````````````
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Signatories allow one to precisely state that the painter has an obligation.
|
||||
The imposed obligation is intuitively invalid because the painter did not
|
||||
@ -446,7 +446,7 @@ We lift this notion to ledgers, whereby a ledger is well-authorized exactly when
|
||||
|
||||
|
||||
Examples
|
||||
````````
|
||||
~~~~~~~~
|
||||
|
||||
An intuition for how the authorization definitions work is most easily
|
||||
developed by looking at some examples. The main example, the
|
||||
|
||||
@ -85,8 +85,8 @@ for, providing privacy to `A` and `P` with respect to the bank.
|
||||
|
||||
.. _def-informee:
|
||||
|
||||
As a design choice, DAML Ledgers show to observers on a contract only the :ref:`state changing
|
||||
<def-contract-state>` actions on the contract.
|
||||
As a design choice, DAML Ledgers show to observers on a contract only the
|
||||
:ref:`state changing <def-contract-state>` actions on the contract.
|
||||
More precisely, **Fetch** and non-consuming **Exercise** actions are not shown to the observers - except when they are
|
||||
the actors of these actions.
|
||||
This motivates the following definition: a party `p` is an **informee** of an action `A` if one of the following holds:
|
||||
@ -139,8 +139,8 @@ Examine each party's projection in turn:
|
||||
(again, recall that all consequences of an exercise action are a
|
||||
part of the action itself).
|
||||
|
||||
#. Alice is a stakeholder in both the `Iou Bank A` and `PaintOffer A
|
||||
B Bank` contracts. As all top-level actions in the ledger are
|
||||
#. Alice is a stakeholder in both the `Iou Bank A` and
|
||||
`PaintOffer A B Bank` contracts. As all top-level actions in the ledger are
|
||||
performed on one of these two contracts, Alice's projection
|
||||
includes all the transactions from the ledger intact.
|
||||
|
||||
@ -207,8 +207,9 @@ contracts should only be shown to their stakeholders. However,
|
||||
ledger projections can cause contracts to become visible to other
|
||||
parties as well.
|
||||
|
||||
In the example of `ledger projections of the paint offer
|
||||
<#da-ledgers-projections-example>`__, the exercise on the `PaintOffer`
|
||||
In the example of
|
||||
`ledger projections of the paint offer <#da-ledgers-projections-example>`__,
|
||||
the exercise on the `PaintOffer`
|
||||
is visible to both the painter and Alice. As a consequence, the
|
||||
exercise on the `Iou Bank A` is visible to the painter, and the
|
||||
creation of `Iou Bank P` is visible to Alice. As actions also contain
|
||||
|
||||
@ -65,8 +65,8 @@ ALPHA (current status)
|
||||
|
||||
That said: we highly value your feedback and input on where you find DAML software and this integration kit most useful.
|
||||
You can get into contact with us using the feedback form on this
|
||||
documentation page or by creating issues or pull-requests against the `digital-asset/daml
|
||||
<https://github.com/digital-asset/daml>`__ GitHub repository.
|
||||
documentation page or by creating issues or pull-requests against the
|
||||
`digital-asset/daml <https://github.com/digital-asset/daml>`__ GitHub repository.
|
||||
|
||||
|
||||
BETA
|
||||
@ -247,8 +247,8 @@ this section is best read jointly with the code in
|
||||
These utilities provide methods to succintly implement interfaces from
|
||||
``participant-state.jar`` on top of a key-value state storage.
|
||||
|
||||
See documentation in `package.scala
|
||||
<https://github.com/digital-asset/daml/blob/master/ledger/participant-state/kvutils/src/main/scala/com/daml/ledger/participant/state/kvutils/package.scala>`__
|
||||
See documentation in
|
||||
`package.scala <https://github.com/digital-asset/daml/blob/master/ledger/participant-state/kvutils/src/main/scala/com/daml/ledger/participant/state/kvutils/package.scala>`__
|
||||
|
||||
``ledger-api-server.jar`` (`source code for API server <https://github.com/digital-asset/daml/blob/master/ledger/sandbox/src/main/scala/com/digitalasset/platform/apiserver/StandaloneApiServer.scala>`__, `source code for indexer <https://github.com/digital-asset/daml/blob/master/ledger/sandbox/src/main/scala/com/digitalasset/platform/indexer/StandaloneIndexerServer.scala>`__)
|
||||
Contains code that implements a DAML Ledger API server and the SQL-backed indexer
|
||||
@ -366,10 +366,10 @@ For reference, you can have a look at how authorization is implemented in the sa
|
||||
Testing a DAML Ledger
|
||||
*********************
|
||||
|
||||
You can test your DAML ledger implementation using :doc:`Ledger API Test Tool
|
||||
</tools/ledger-api-test-tool/index>`, which will assess correctness of
|
||||
implementation of the :doc:`Ledger API
|
||||
</app-dev/ledger-api>`. For example, it will show you if
|
||||
You can test your DAML ledger implementation using
|
||||
:doc:`Ledger API Test Tool </tools/ledger-api-test-tool/index>`,
|
||||
which will assess correctness of implementation of the
|
||||
:doc:`Ledger API </app-dev/ledger-api>`. For example, it will show you if
|
||||
there are consistency or conformance problem with your implementation.
|
||||
|
||||
Assuming that your Ledger API endpoint is accessible at ``localhost:6865``, you can use the tool in the following manner:
|
||||
|
||||
@ -62,8 +62,8 @@ two forms:
|
||||
2. A pure expression ``expr`` of type ``a`` for some type ``a`` where
|
||||
``a`` is an instance of ``Show``. This will evaluate ``expr`` and
|
||||
print the result. If you are only interest in pure expressions you
|
||||
can also use DAML REPL :ref:`without connecting to a ledger
|
||||
<repl-no-ledger>`.
|
||||
can also use DAML REPL
|
||||
:ref:`without connecting to a ledger <repl-no-ledger>`.
|
||||
|
||||
3. A binding of the form ``pat <- expr`` where ``pat`` is pattern, e.g.,
|
||||
a variable name ``x`` to bind the result to
|
||||
|
||||
@ -20,9 +20,8 @@ the simplicity of DAML scenarios and all the benefits such as being
|
||||
able to reuse your DAML types and logic while running against an actual
|
||||
ledger in addition to allowing you to experiment in :ref:`DAML Studio <scenario-script-results>`.
|
||||
This means that you can use it to test automation logic, your
|
||||
UI but also for :ref:`ledger initialization
|
||||
<script-ledger-initialization>` where scenarios cannot be used (with
|
||||
the exception of :doc:`/tools/sandbox`).
|
||||
UI but also for :ref:`ledger initialization <script-ledger-initialization>`
|
||||
where scenarios cannot be used (with the exception of :doc:`/tools/sandbox`).
|
||||
|
||||
You can also use DAML Script interactively using :doc:`/daml-repl/index`.
|
||||
|
||||
@ -314,10 +313,10 @@ you need to specify an access token. There are two ways of doing that:
|
||||
2. If you need multiple tokens, e.g., because you only have
|
||||
single-party tokens you can use the ``access_token`` field in the
|
||||
participant config specified via ``--participant-config``. The
|
||||
section on :ref:`using DAML Script in distributed topologies
|
||||
<daml-script-distributed>` contains an example. Note that you can
|
||||
specify the same participant twice if you want different auth
|
||||
tokens.
|
||||
section on
|
||||
:ref:`using DAML Script in distributed topologies <daml-script-distributed>`
|
||||
contains an example. Note that you can specify the same participant
|
||||
twice if you want different auth tokens.
|
||||
|
||||
If you specify both ``--access-token-file`` and
|
||||
``--participant-config``, the participant config takes precedence and
|
||||
@ -329,8 +328,8 @@ have a token specified in the config.
|
||||
Running DAML Script against the HTTP JSON API
|
||||
=============================================
|
||||
|
||||
In some cases, you only have access to the :doc:`HTTP JSON API
|
||||
</json-api/index>` but not to the gRPC of a ledger, e.g., on
|
||||
In some cases, you only have access to the
|
||||
:doc:`HTTP JSON API </json-api/index>` but not to the gRPC of a ledger, e.g., on
|
||||
`project:DABL <https://projectdabl.com>`_. For this usecase, DAML
|
||||
script can be run against the JSON API. Note that if you do have
|
||||
access to the gRPC API, running DAML script against the JSON API does
|
||||
|
||||
@ -42,9 +42,9 @@ Your screen should now look like the image below.
|
||||
|
||||
6. Remove the parse error by restoring the ``=`` sign.
|
||||
|
||||
We recommend reviewing the `Visual Studio Code documentation
|
||||
<https://code.visualstudio.com/docs/editor/codebasics>`_ to learn more
|
||||
about how to use it.
|
||||
We recommend reviewing the
|
||||
`Visual Studio Code documentation <https://code.visualstudio.com/docs/editor/codebasics>`_
|
||||
to learn more about how to use it.
|
||||
To learn more about DAML, see :doc:`reference/index`.
|
||||
|
||||
Supported features
|
||||
|
||||
@ -226,7 +226,7 @@ Until Chapter 7 the only real kind of control flow introduced has been ``case``,
|
||||
If..Else
|
||||
~~~~~~~~
|
||||
|
||||
Chapter 5 also showed a seemingly self-explanatory ``if..else`` statement, but didn't explain it further. And they are actually the same thing. Let's implement the function ``boolToInt : Bool -> Int`` which in tyipcal fashion maps ``True`` to ``1`` and ``False`` to ``0`. Here is an implementation using ``case``:
|
||||
Chapter 5 also showed a seemingly self-explanatory ``if..else`` statement, but didn't explain it further. And they are actually the same thing. Let's implement the function ``boolToInt : Bool -> Int`` which in tyipcal fashion maps ``True`` to ``1`` and ``False`` to ``0``. Here is an implementation using ``case``:
|
||||
|
||||
.. literalinclude:: daml/daml-intro-9/daml/Main.daml
|
||||
:language: daml
|
||||
|
||||
@ -19,7 +19,7 @@ In :doc:`expressions`, the ``tubeSurfaceArea`` function was defined as:
|
||||
:language: daml
|
||||
:lines: 14-16
|
||||
|
||||
You can define this function equivalently using lambdas, involving `\``, a sequence of parameters, and an arrow ``->`` as:
|
||||
You can define this function equivalently using lambdas, involving ``\``, a sequence of parameters, and an arrow ``->`` as:
|
||||
|
||||
.. literalinclude:: ../code-snippets/TubeSurfaceArea2.daml
|
||||
:language: daml
|
||||
|
||||
@ -16,9 +16,9 @@ To deploy to a DAML ledger, run the following command from within your DAML proj
|
||||
$ daml deploy --host=<HOST> --port=<PORT> --access-token-file=<TOKEN-FILE>
|
||||
|
||||
where ``<HOST>`` and ``<PORT>`` is the hostname and port your ledger is listening on, which defaults
|
||||
to port ``6564``. The ``<TOKEN-FILE>`` is needed if your sandbox runs with :ref:`authorization
|
||||
<authorization>` and needs to contain a JWT token with an ``admin`` claim. If your sandbox is not
|
||||
setup to use any authentication it can be omitted.
|
||||
to port ``6564``. The ``<TOKEN-FILE>`` is needed if your sandbox runs with
|
||||
:ref:`authorization <authorization>` and needs to contain a JWT token with an ``admin`` claim.
|
||||
If your sandbox is not setup to use any authentication it can be omitted.
|
||||
|
||||
Instead of passing ``--host`` and ``--port`` flags to the command above, you can add the following
|
||||
section to the project's ``daml.yaml`` file:
|
||||
|
||||
@ -6,8 +6,8 @@
|
||||
HTTP JSON API Service
|
||||
#####################
|
||||
|
||||
The **JSON API** provides a significantly simpler way to interact with a ledger than :doc:`the Ledger
|
||||
API </app-dev/ledger-api>` by providing *basic active contract set functionality*:
|
||||
The **JSON API** provides a significantly simpler way to interact with a ledger than
|
||||
:doc:`the Ledger API </app-dev/ledger-api>` by providing *basic active contract set functionality*:
|
||||
|
||||
- creating contracts,
|
||||
- exercising choices on contracts,
|
||||
@ -24,10 +24,10 @@ complicating concerns including, but not limited to:
|
||||
For these and other features, use :doc:`the Ledger API </app-dev/ledger-api>`
|
||||
instead.
|
||||
|
||||
We welcome feedback about the JSON API on `our issue tracker
|
||||
<https://github.com/digital-asset/daml/issues/new?milestone=HTTP+JSON+API+Maintenance>`_
|
||||
`on our forum <https://discuss.daml.com>`_, or `on Slack
|
||||
<https://slack.daml.com>`_.
|
||||
We welcome feedback about the JSON API on
|
||||
`our issue tracker <https://github.com/digital-asset/daml/issues/new?milestone=HTTP+JSON+API+Maintenance>`_
|
||||
`on our forum <https://discuss.daml.com>`_, or
|
||||
`on Slack <https://slack.daml.com>`_.
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
@ -75,8 +75,8 @@ Standalone JAR
|
||||
The ``daml json-api`` command is great during development since it is
|
||||
included with the SDK and integrates with ``daml start`` and other
|
||||
commands. Once you are ready to deploy your application, you can
|
||||
download the standalone JAR from `Github releases
|
||||
<https://github.com/digital-asset/daml/releases>`_. It is much smaller
|
||||
download the standalone JAR from
|
||||
`Github releases <https://github.com/digital-asset/daml/releases>`_. It is much smaller
|
||||
than the whole SDK and easier to deploy since it only requires a JVM
|
||||
but no other dependencies and no installation process. The JAR accepts
|
||||
exactly the same command line parameters as ``daml json-api``, so to
|
||||
@ -1456,8 +1456,8 @@ Example:
|
||||
{"templateId": "Account:Account", "key": {"_1": "Alice", "_2": "def345"}}
|
||||
]
|
||||
|
||||
The output stream has the same format as the output from the `Contracts
|
||||
Query Stream`_. We further guarantee that for every ``archived`` event
|
||||
The output stream has the same format as the output from the
|
||||
`Contracts Query Stream`_. We further guarantee that for every ``archived`` event
|
||||
appearing on the stream there has been a matching ``created`` event
|
||||
earlier in the stream, except in the case of missing
|
||||
``contractIdAtOffset`` fields in the case described below.
|
||||
|
||||
@ -206,7 +206,7 @@ Developer Tools
|
||||
* - ``daml deploy`` :doc:`helper command and associated CLI </deploy/generic_ledger>` (``daml deploy --help``)
|
||||
- Stable
|
||||
-
|
||||
* - Assistant commands to start Runtime Components: ``daml json-api`, ``daml trigger``, ``daml trigger-service``, and ``daml extractor``.
|
||||
* - Assistant commands to start Runtime Components: ``daml json-api``, ``daml trigger``, ``daml trigger-service``, and ``daml extractor``.
|
||||
- See :ref:`runtime-components`.
|
||||
-
|
||||
* - **DAML Projects**
|
||||
|
||||
@ -5,8 +5,8 @@ Ledger API Test Tool
|
||||
####################
|
||||
|
||||
The Ledger API Test Tool is a command line tool for testing the correctness of
|
||||
implementations of the :doc:`Ledger API
|
||||
</app-dev/ledger-api>`, i.e. DAML ledgers. For example, it
|
||||
implementations of the :doc:`Ledger API </app-dev/ledger-api>`,
|
||||
i.e. DAML ledgers. For example, it
|
||||
will show you if there are consistency or conformance problem with your
|
||||
implementation.
|
||||
|
||||
@ -14,8 +14,8 @@ Its intended audience are developers of DAML ledgers, who are using the
|
||||
DAML Ledger Implementation Kit to develop
|
||||
a DAML ledger on top of their distributed-ledger or database of choice.
|
||||
|
||||
Use this tool to verify if your Ledger API endpoint conforms to the :doc:`DA
|
||||
Ledger Model </concepts/ledger-model/index>`.
|
||||
Use this tool to verify if your Ledger API endpoint conforms to the
|
||||
:doc:`DA Ledger Model </concepts/ledger-model/index>`.
|
||||
|
||||
Downloading the tool
|
||||
====================
|
||||
@ -157,8 +157,8 @@ specific file path using the ``--perf-tests-report`` command line option.
|
||||
Try out the Ledger API Test Tool against DAML Sandbox
|
||||
=====================================================
|
||||
|
||||
If you wanted to test out the tool, you can run it against :doc:`DAML Sandbox
|
||||
</tools/sandbox>`. To do this:
|
||||
If you wanted to test out the tool, you can run it against
|
||||
:doc:`DAML Sandbox </tools/sandbox>`. To do this:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
||||
@ -273,8 +273,9 @@ When not to use DAML triggers
|
||||
|
||||
DAML Triggers are not suited for automation that needs to interact
|
||||
with services or data outside of the ledger. For those cases, you can
|
||||
write a ledger client using the :doc:`JavaScript bindings
|
||||
</app-dev/bindings-ts/index>` running against the HTTP JSON API or the
|
||||
write a ledger client using the
|
||||
:doc:`JavaScript bindings </app-dev/bindings-ts/index>`
|
||||
running against the HTTP JSON API or the
|
||||
:doc:`Java bindings</app-dev/bindings-java/index>` running against the
|
||||
gRPC Ledger API.
|
||||
|
||||
|
||||
@ -7,8 +7,8 @@ Automating the Upgrade Process
|
||||
##############################
|
||||
|
||||
In this section, we are going to automate the upgrade of our coin
|
||||
process using :doc:`DAML Script</daml-script/index>` and :doc:`DAML
|
||||
Triggers </triggers/index>`. Note that automation for upgrades is
|
||||
process using :doc:`DAML Script</daml-script/index>` and
|
||||
:doc:`DAML Triggers </triggers/index>`. Note that automation for upgrades is
|
||||
specific to an individual application, just like the upgrade models.
|
||||
Nevertheless, we have found that the pattern shown here
|
||||
occurs frequently.
|
||||
|
||||
@ -79,8 +79,9 @@ separately. However, since the template definition for all of them is
|
||||
the same, this is usually not necessary for most
|
||||
applications. Instead, we collect agreement from the signatories only
|
||||
once and use that to upgrade all coins. Since there are multiple
|
||||
signatories involved here, we use a :ref:`Propose-Accept workflow
|
||||
<intro propose accept>`. First, we define an *UpgradeCoinProposal*
|
||||
signatories involved here, we use a
|
||||
:ref:`Propose-Accept workflow <intro propose accept>`.
|
||||
First, we define an *UpgradeCoinProposal*
|
||||
template that will be created by the issuer. This template has an
|
||||
*Accept* choice that the *owner* can exercise which will then create
|
||||
an *UpgradeCoinAgreement*.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user