* Make quickstart-java template work with canton
Also update the quickstart-java release test instructions to use the new sandbox. This is a bit more involved than before, because of the party names being different every time, but I hope this is not too much of a burden. The test here is similar to what gets tested in the assistant integration test for quickstart-java.
changelog_begin
changelog_end
* try to fix indentation
And change the relevant release test instructions to make it clear this
isn't a quickstart-java project, but a project that uses the default
template (skeleton).
changelog_begin
changelog_end
* Rename daml sandbox to daml sandbox-kv
Also drop the default sandbox on `daml start`
Part of #11831
changelog_begin
changelog_end
* update release test instructions
* try to fix a couple compat tests
* dont need special 0.0.0 logic
* buildifier-fixx
Somewhat error-prone, so please review carefully.
Reasons we need this:
- Some file types are not properly handled by the script.
- The only exclusion mechanism we currently have (`NO_AUTO_COPYRIGHT`)
is overly coarse.
CHANGELOG_BEGIN
CHANGELOG_END
* Get rid of deprecated components
Removes:
- mentions of the Node.js bindings
- mentions of the Scala bindings
- usage of the Scala codegen as an SDK tool
- Java bindings "reactive components"
changelog_begin
The Node.js bindings are no longer supported as part of the Daml SDK
The Scala bindings are no longer supported as part of the Daml SDK
The Java bindings reactive components are no longer supported as part of the Daml SDK
The `daml codegen` command has dropped support for Scala
changelog_end
* Fix typo noticed by @cocreature
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Address https://github.com/digital-asset/daml/pull/12167#issuecomment-995714093
* Remove quickstart-scala from the SDK tarballs
* Fix failing codegen test
* Address https://github.com/digital-asset/daml/pull/12167#pullrequestreview-833991243
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
See #11358.
CHANGELOG_BEGIN
- [@daml/react] Our React bindings now request the `react` library as a
peer dependency, and will accept React 17 in addition to the current
React 16. For new projects, the `create-daml-app` template now uses
React 17.
CHANGELOG_END
* Initial work-in-progress
changelog_begin
[TS bindings] When using daml-react and daml-ledger, all streaming request to the query endpoint will be multiplexed through a single web socket.
changelog_end
* Minor touches, renaming
* Handle offsets received from the JSON API
* Create state array once per downstream consumer
* Handle reconnections as streamSubmit does
* Don't share mutable state between events
* Fix compilation errors
* Remove language-support/ts/package-lock.json
* Remove --downlevelIteration option, materialize iterators, fix one test
* I will refrain from commenting on the meaning of `this` in JavaScript
* WebSocket does not have a removeAllListeners method
* Remove unnecessary docstring from `handleQueriesChange`
* Address https://github.com/digital-asset/daml/pull/10221#discussion_r670441680
* Address https://github.com/digital-asset/daml/pull/10221#discussion_r670427941
* Address https://github.com/digital-asset/daml/pull/10221#discussion_r670448474
* Address https://github.com/digital-asset/daml/pull/10221#discussion_r670473307
* Fix some failing tests and linting fixes
* fix reconnect on server close test
* fix failing tests in test.ts and create-daml-app tests
* Update language-support/ts/daml-ledger/index.ts
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update language-support/ts/daml-ledger/index.ts
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update language-support/ts/daml-ledger/index.test.ts
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update language-support/ts/daml-ledger/index.test.ts
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* changes based on code review comments
Co-authored-by: Akshay <akshay.shirahatti@digitalasset.com>
Co-authored-by: akshayshirahatti-da <86774832+akshayshirahatti-da@users.noreply.github.com>
* Factor out npm install step of create-daml-app tests
This PR speeds up the create-daml-app tests by 30s or so by factoring
out the install of the unchanged npm deps into a genrule which we then
feed in again. This is a bit ugly but given how frequently we run
those tests I do think it is worth the uglyness.
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
We’ve seen this timeout a few times on CI. The version in the compat
tests already has a 60s timeout and that seems to work better so
here’s to hoping this helps.
I’ve also added some logs to see where it stops if it times out
again (jest hides console.log by default which is why this uses
console.debug by default).
changelog_begin
changelog_end
On Windows, we run without a sandbox, which means that the `gsg-trigger`
folder might already exist and be patched, because we work directly in
the source tree.
This changes the script to work with temp dirs instead.
CHANGELOG_BEGIN
CHANGELOG_END
As I was adding support to a sample app for the third time, I decided I
might as well clean it up a bit and add support for everyone.
This is completely optional, activated by (build-time) environment
variables, and should be trivial to remove for users who don't care
about it. In an ideal world we'd have options to `daml new` and this
would be one, but I think adding it out-of-the-box is a better
alternative than letting people figure this out on their own.
CHANGELOG_BEGIN
- The `create-daml-app` template now includes support for a third
authentication scheme (in addition to the existing "dev mode" and Daml
Hub support): Auth0.
CHANGELOG_END
The current README dates back to when `create-daml-app` was its own
repo, and seems mostly written from the perspective of being the default
home page for the project. These days, `create-daml-app` serves two
purposes:
1. As the core starting point for the Getting Started Guide, we can
assume people who are totally new to Daml will be following the
getting started guide. How else would they even know about this
template? In that case, I think it's fair to assume the user will *not*
be looking to the README for guidance. Therefore, repeating the
documentation here seems a bit pointless.
2. As a template to quickstart the creation of a "custom" app that is
not the GSG. For that use-case, the README is the place where people
would look for information, but at that point the information they're
looking for are more along the lines of quick refreshers of what
commands to run than explanations on how to use the app as Alice and
Bob.
CHANGELOG_BEGIN
CHANGELOG_END
It currently has all it needs for the docs to build, but not quite for
people to use it as a useful result of the triggers docs page: without
the UI components, it's hard to see anything the triggers are supposed
to do.
CHANGELOG_BEGIN
CHANGELOG_END
* rewrite trigger docs to follow gsg
Per #10419 point 4, I've rewritten the Triggers section to build upon
the Getting Started Guide instead of inventing its own example.
Compared to #10395, this has a lot more explanations as this page must
now serve the dual purpose of being a possible "next step" from the GSG
and being the main reference page for triggers. It's also lost the "next
steps" section, which I think is a bit of a shame, but it doesn't really
make sense here.
There's also no easy way for people not interested in the GSG to follow
along; should we expose the "completed GSG" as a tempate?
CHANGELOG_BEGIN
CHANGELOG_END
* keep copy-trigger as a template
* fix copy-trigger project name
* make up gsg-trigger template
* remove awkward sentence, fix existing typo
* update code to use when{,Some}
* add to
* swap emitCommands and getCommandsInFlight
* typo
* insist on state-correction perspective
* fix copy-trigger tests
* add back copy-trigger to whitelist
* add gsg-trigger to whitelist
When opening #10342 I was only aware of the `.gitignore`; @cocreature's
comment made me find out the `.dlint.yaml`, and then, testing it, I
realized we ended up with the ignore rule twice. It does not seem to be
causing any issue in cursory tests, but still, I think it's worth
cleaning up.
CHANGELOG_BEGIN
CHANGELOG_END
This ends up transitively bumping yargs-parser which has a
vulnerability but more generally I also just like being on the latest version.
changelog_begin
changelog_end
* update Daml Hub auth in create-daml-app
Current documentation says the token is passed as a cookie. This is a
little bit more secure than passing it as a URL param, as it used to be.
Note that while it is no longer documented behaviour, the token is
actually still passed as a param (in addition to the cookie), so
existing users are not broken (yet). Still, better if the code we
generate for them matches our current docs.
CHANGELOG_BEGIN
CHANGELOG_END
* review comment
Setting this manually has resulted in #9397 where we use a scala
version that doesn’t have a silencer version. This PR changes the
quickstart template to use the scala version we also use in our builds
which should avoid them getting out of sync in the future.
changelog_begin
changelog_end
* Apply new logo to create-daml-app template
changelog_begin
[SDK Assistant] New Daml logo on create-daml-app template
changelog_end
* Fix logo alignment, change capitalization of page title
Older versions emit security warnings. I went through the getting
started guide and CI should also test this so reasonable confident it
doesn’t break things™.
changelog_begin
changelog_end
* Replace many occurrences of DAML with Daml
* Update docs logo
* A few more CLI occurrences
CHANGELOG_BEGIN
- Change DAML capitalization and docs logo
CHANGELOG_END
* Fix some over-eager replacements
* A few mor occurrences in md files
* Address comments in *.proto files
* Change case in comments and strings in .ts files
* Revert changes to frozen proto files
* Also revert LF 1.11
* Update get-daml.sh
* Update windows installer
* Include .py files
* Include comments in .daml files
* More instances in the assistant CLI
* some more help texts
This commit fixes a few copyright headers that have been missed in the
automatic update on Jan 1, as well as the generation code in the compat
workspace so it generates the right headers.
CHANGELOG_BEGIN
CHANGELOG_END
As we strive for more inclusiveness, we are becoming less comfortable
with historically-charged terms being used in our everyday work.
This is targeted for merge on Dec 26, _after_ the necessary
corresponding changes at both the GitHub and Azure Pipelines levels.
CHANGELOG_BEGIN
- DAML Connect development is now conducted from the `main` branch,
rather than the `master` one. If you had any dependency on the
digital-asset/daml repository, you will need to update this parameter.
CHANGELOG_END
This follows up on #7066 and exposes the new underlying multi-key and
multi-query stream functions through the React bindings. Following the
same reasoning as in #7066, we therefore deprecate the existing
functions (with no intention of removing them) as they become redundant.
CHANGELOG_BEGIN
* JavaScript Client Libraries: Updated React bindings to expose the
recent addition of multi-key and multi-query streams in @daml/ledger.
The singular versions are marked as deprecated as they have become
redundant.
The upgrade path for `useStreamQuery` is very straightforward: the
query factory remains optional, but if specified it should return an
array of queries instead of a single query. The array may be empty,
which will return all contracts for that template (similar as not
passing in a query factory). The return values of `useStreamQuery` and
`useStreamQueries` are the same type.
```
useStreamQuery(T) --> useStreamQueries(T)
useStreamQuery(T, () => query, ...) --> useStreamQueries(T, () => [query], ...)
```
The upgrade path for `useStreamFetchByKey` is only slightly more
involved as the return type of `useStreamFetchByKeys` is a new type
called `FetchByKeysResult` instead of the existing `FetchResult`.
`FetchByKeysResult` differs from `FetchResult` in that it contains a
`contracts` field with an array of contracts instead of a singular
`contract` field. (It differs from `QueryResult` in that each element of
the returned array can also be `null`, if there is no corresponding
active contract.) Call sites can be updated as follows:
```
const {loading, contract} = useStreamFetchByKey(T, () => k, ...);
-->
const {loading, contracts} = useStreamFetchByKeys(T, () => [k], ...));
const contract = contracts[0];
```
CHANGELOG_END
This executes the code generations specified in the daml.yaml
configuration file on every invocation of `daml start`
and hence frees the user of doing it manually.
CHANGELOG_BEGIN
- [DAML Assistant] The `daml start` now runs all the code generators
specified in the `daml.yaml` project configuration file under the
`codegen` stanza. This frees the user of doing so manually on every
change to the DAML model.
CHANGELOG_END
We deprecate specifying the template when calling `daml new` via a
positional argument, as in
```sh
daml new foo skeleton
```
The new syntax is
```sh
daml new foo --template skeleton
```
Whenever the former version is used, we now print a not that it is
deprecated and that the latter version is the recommended way.
CHANGELOG_BEGIN
[DAML Assistant]
- Deprecate specifying the template for `daml new` via a positional
argument.
CHANGELOG_END
When an error happend during decoding of JSON API answers due to missing
templates, the error was just displayed as an empty object '{}'.
CHANGELOG_BEGIN
CHANGELOG_END
* Migrate skeleton to DAML Script
Also kills the separate setup module since it’s the same thing
changelog_begin
changelog_end
* Fix test
changelog_begin
changelog_end
* Factor out tar/gzip reproducibility flags
* use mktgz in package-app
* Bazel managed tar/gzip
* Remove quiet = True
As stated in the comment this is no longer required with Bazel >= 3.0.
* Build package-app as a sh_binary
This way Bazel will manage the runtime dependencies tar, gzip, mktgz,
and patchelf.
package-app.sh changes directory so it needs to make sure that all paths
are absolute and that the runfiles tree/manifest location is forwarded
to programs called by package-app.sh.
* Avoid file path too long errors
* Fix readlink -f on MacOS
* Document abspath
changelog_begin
changelog_end
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
If a user were to follow @cocreature's [suggestions][0] for compiler
warnings, the current skeleton template would generate two warnings.
That seems like it may give a bad impression, so I believe we should fix
it, even though the warnings are not enabled by default.
[0]: https://discuss.daml.com/t/making-the-most-out-of-daml-compiler-warnings/739
CHANGELOG_BEGIN
CHANGELOG_END
* Respect project name in create-daml-app
Now `daml new foobar create-daml-app` creates a project called
`foobar` replacing the name everywhere. The tests now run twice once
with the original project name since that’s what we use in the GSG and
once with a modified one. I guess you could argue that only running
the second should be enough so I’m open to removing the first one.
fixes#6681
changelog_begin
- [DAML Assistant] `daml new foobar create-daml-app` now properly
respects the project name and creates a project called `foobar`
instead of hardcoding the name fo `create-daml-app`.
changelog_end
* .
changelog_begin
changelog_end
* Remove debugging output
changelog_begin
changelog_end
The intention was to pull in the source for the GSG but it turns out
that the templates tarball doesn’t just bundle up files, it also
includes generated scala code for the scala quickstart which depends
on damlc. This PR splits the GSG sources including the patching into a
separate rule which does not depend on damlc and only copies that in
live-preview.
changelog_begin
changelog_end
Buildifier now comes with a handy attachment to catch single `\`
characters inside strings and replace them with `\\` if the escape
sequence is invalid. Skylark/Python will do this at runtime anyway; this
just makes it clearer what the actual behavior is.
I needed to change `\` characters at the end of lines to `\\` manually
in order to stop Buildifier from simply concatenating the lines
together. Everything else was automatic.
CHANGELOG_BEGIN
CHANGELOG_END
* Remove the copyright header from the skelton
It doesn't make sense to annoy our users with our copyright for on a
template. And the over abundance of empty lines has annoyed me so many
times.
* Add NO_AUTO_COPYRIGHT file
CHANGELOG_BEGIN
CHANGELOG_END
The issue is described in a comment (since I want to preserve it) but
here’s the brief summary:
Calling `follow` twice can result in contention if we do not wait in
between. That is shown in the log of the JSON API. For some reason
that ends up propagating to a misleading Target closed error from
puppeteer.
This PR addresses the problem by waiting for the list of followers to
be updated which definitely implies that the ledger has seen the
command.
changelog_begin
changelog_end
I don’t know if this fixes the “Target closed” issues since I never
managed to reproduce them but I’d rather debug them on the latest
version :)
changelog_begin
changelog_end
`waitForSelector` returns immediately if the selector is already
present (which is documented). This means that the waitForSelector
after the second follow isn’t doing anything since we already waited
for after the first follow. `waitForFunction` seemed like the simplest
solution and doesn’t require patching the HTML which is a bit finnicky
in the compat tests.
changelog_begin
changelog_end
