This is not intended to be the next stable release, I just want to
test the Bintray removal and publishing the protobufs to github releases.
changelog_begin
changelog_end
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
If we don't provide a license field, `yarn install` issues a warning.
Since sharing the code generated by `daml2js` with others doesn't
make sense in the current state, I've chosen the most conservative
license, namely "UNLICENSED", such that our users don't accidentally
license their code to others.
In the long run, we should make this field configurable.
This PR also improves the description of the generated packages and
makes the temporary `package.json` used by `daml2js` private.
CHANGELOG_BEGIN
CHANGELOG_END
* sandbox: Move the events page size configuration value into config.
* sandbox: Pass `config` directly into JdbcIndexerFactory.
* sandbox: Reorder `eventsPageSize` before `metrics` in parameters.
* sandbox: Move `seeding` into `ApiServerConfig`.
CHANGELOG_BEGIN
CHANGELOG_END
* sandbox: Name all parameters of `JdbcLedgerDao.writeOwner`.
Co-Authored-By: stefano.baghino@digitalasset.com
* 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
* Add snapshot version support in daml-assistant.
changelog_begin
- [DAML SDK] ``daml version`` can now list the available snapshot
versions by passing the flag ``--snapshots=yes``.
- [DAML SDK] ``daml install latest`` can now include the latest snapshot version by passing the flag ``--snapshots=yes``.
changelog_end
* Keep backward-compatible --all behavior
* Fix comment
* Delete spurious punctuation
* 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>
* Regression test for silent REPL server errors
CHANGELOG_BEGIN
CHANGELOG_END
* Fix script error test case
We get an error print out by the REPL server as well
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* Move more trigger tests to scala tests
This PR moves more tests of triggers over to the Scala test suite, in
particular:
- The existing tests there abstract over the time mode and are
instantiated once for wallclock mode and once for static time mode.
- I’ve added tests for TLS and Auth.
- I’ve removed the TLS and Auth tests outside of scala-test since they
are now redundant.
- I’ve added the time tests to the scala-tests stuff since with the
new ledger time model, that’s necessary to actually trigger a
failure if you get static time vs wallclock time wrong (MRT and LET
no longer exist).
I haven’t yet moved all the func tests over, I’ll do that separately
and then we can kill the old tests completely.
changelog_begin
changelog_end
* Factor out test utils into a library
Previously we emitted 3 lines starting with a capslock `WARNING` which
seems to scare some people. Now we emit two lines without the
`WARNING` and point to the release notes since that seems better than
explaining to users how they upgrade without telling them what
changed.
It’s still two lines, I couldn’t come up with anything shorter that
seems reasonable. We might want to reduce the frequency at which this
is displayed as well but for now this should do.
changelog_begin
changelog_end
* Implement timed command deduplication in kvutils
This adds a field deduplication_time to DamlCommandDedupValue for
deduplication timeout checking.
* Bump kvutils version to 4
* Fix CommandTracker pulling commandResultIn multiple times
Now that the timeouts are generated out of band, we have 2
"unsynchronized" places that pull on commandResultIn.
Whenever we pull, we need to check that commandResultIn hasn't been
pulled before.
* Add inStaticTimeMode flag to enable command dedup in sandbox-next with static-time
Fixes#4624.
CHANGELOG_BEGIN
[kvutils] KVUtils now respects the command deduplciation time instead of
deduplicating commands forever.
CHANGELOG_END
The `-p` flag was used to provide the path to the `package.json` which
constitutes the root of a yarn workspace. Since we don't use yarn
workspaces anymore, this flag is now useless and the PR removes the
last traces of it.
CHANGELOG_BEGIN
CHANGELOG_END
* kvutils: Remove the LedgerEntry trait; it's no longer necessary.
This was introduced to allow for heartbeats, which no longer exist.
CHANGELOG_BEGIN
CHANGELOG_END
* kvutils: Make LedgerRecord a case class again.
We used to store the envelope as an array of bytes, which doesn't have a
value-based `equals` method and therefore should not be used in a case
class. We now use a `ByteString`, so this is no longer an issue.
We saw a few issues in CI where `setup` might be called twice, which
resulted in a test fail for no good reason. Rather than crashing, we
can just do nothing the second time.
CHANGELOG_BEGIN
CHANGELOG_END
The details are in a source code comment but roughly it boils down to
`proc` vs `shell` looking things up in PATH differently.
changelog_begin
changelog_end
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
The test calls `daml new ... create-daml-app`, builds the DAR, runs
the TypeScript codegen, lints and builds the React app.
We should also run the tests for the React app but since that's most
likely tricky, I'll leave that for a followup PR so that we can land
at least some sanity checks now.
There's also a bit of cleanup to do around setting up a yarn workspace
to bring our TypeScript libraries into scope. Other test already solve
a similar problem in a way that is not general enough for this test.
I'll unify the setup in a followup PR as well.
CHANGELOG_BEGIN
CHANGELOG_END
* Migrate create_consumed_at to offset
This is a leftover from the stable offsets migration and causes issues when serving active contracts from the new schema.
changelog_begin
changelog_end
* No decoding necessary for create_consumed_at
* language: docs: fix links in README's and update docs of useQuery
This fixes the broken links to the generated documentation and updates
the docs on `useQuery`, `useStreamQuery`.
CHANGELOG_BEGIN
CHANGELOG_END
* added two examples for useQuery/useStreamQuery without a query parameter
* language: daml-ledger: emit live events on streams
We handle the 'offset' field of the JSON API correctly and inform
downstream consumers with a 'live' event once we know that the stream is
live updating.
CHANGELOG_BEGIN
CHANGELOG_END
* Update language-support/ts/daml-ledger/index.ts
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Fix tests
CHANGELOG_BEGIN
CHANGELOG_END
* Run build-and-lint-test only on Linux
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* kvutils: Use `.view` in SubmissionValidator.
CHANGELOG_BEGIN
CHANGELOG_END
* kvutils: Don't compute missing inputs unless we're asked.
* ledger-on-memory: Do less in `InMemoryLedgerStateOperations`.
* ledger-on-memory: Use `RangeSource` instead of `OneAfterAnother`.
Should be faster to just take a slice.
* ledger-on-memory: Don't bother locking when reading.
We're only reading the log, which is append-only; we never mutate
existing data. This means we don't need to lock to read it.
* ledger-on-memory: Make it impossible to construct a state with data.
This can fail in CI, especially when we're running tests in parallel,
and starting PostgreSQL as well.
I've increased the limit from 30 seconds to 1 minute.
This is hopefully not a permanent fix; I'm going to look into doing this
without an `Await.result`.
CHANGELOG_BEGIN
CHANGELOG_END
* 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>
* Replace unstable-types tests by a Haskell test suite
The JQ based test suite is absurdly slow, it takes around 60s to run
on my machine. The Haskell test suite on the other hand takes less
than 2s on my machine so this is a speedup of over 30x and I have to
read less bash.
changelog_begin
changelog_end
* Address review comments
It seems to use the default JVM options, which is 1/4 of available RAM,
or 8 GB on a machine with 32 GB of memory. This seems quite unnecessary;
it appears to work fine with much less than that.
CHANGELOG_BEGIN
CHANGELOG_END
* Refactor flat events range queries
By factoring out query routing, this logic can be re-used to serve active contracts.
changelog_begin
changelog_end
* Fix copyright notice header
- Move deployment tests (deployTest, fetchTest) out of integration-tests.
- Use DA.Test.Sandbox where appropriate.
- Split out code for useful test patterns: i.e. calling commands quietly, getFreePort.
changelog_begin
changelog_end
The details are in a comment since I want to preserve them. Please
review carefully, I don’t trust my async exception foo.
This is only an issue in the integration tests I believe since we
change files of interest all the time. As long as you stay stable at
some point for some amount of time, we will GC properly either way.
In my tests, this reduces memory usage of the scenario service in the
integration tests from 3 to 2 GiB. There is sadly
anther leak somewhere (contexts are properly GCd now, I verified that
we never have more than 3 contexts in the server). I’ll do some more
investigation but memory grows linearly to the 2GiB while it should
stay pretty much constant.
changelog_begin
changelog_end