* Properly mangle/unmangle names in the scenario service
Previously, we just passed in whatever we had in DAML land which broke
the scenario service as soon as a name needed mangling. This PR fixes
mangling when passing identifiers to the scenario service and
unmangles them again when pretty printing.
fixes#5593
changelog_begin
- [DAML Studio] Fix a bug where scenarios with names that are mangled
in DAML-LF resulted in a crash in the scenario service.
changelog_end
* Mangle module names in context updates
This is a first step in probably a series of PRs to cleanup the
packaging logic.
There is no change in functionality (or at least none that is
intended). The changes boil down to two things:
1. Add a `DependencyInfo` type that stores the various maps and has
detailed comments what exactly is in each map and hopefully somewhat
descriptive field names.
2. Move a lot of the logic in `createProjectPackageDb` into various
helper functions.
There is definitely a lot more cleanup and refactoring that we can do
here but I’ll try to keep it in manageable chunks.
changelog_begin
changelog_end
This has come up today where someone didn’t realize that removing the
field is sufficient to fix the warning.
I’ve also taken this as an opportunity to move the code out to a
helper function.
changelog_begin
changelog_end
* Fix conversion from contract to node ids in the scenario service
Previously we only included the mapping from the ledger. However, this
does not include any contracts which might have been created in a
partial transaction that failed. This caused a
`NoSuchElementException` when converting the error which is obviously
not what we want.
This PR extends the mapping to include any contracts created in the
current partial transaction.
changelog_begin
- [DAML Studio] Fix a bug where a failed transaction that included
references to a transient contract returned a gRPC error instead of
the expected error message.
changelog_end
* Update compiler/scenario-service/server/src/main/scala/com/digitalasset/daml/lf/scenario/Conversions.scala
Co-Authored-By: Remy <remy.haemmerle@daml.com>
* Update compiler/scenario-service/server/src/main/scala/com/digitalasset/daml/lf/scenario/Conversions.scala
Co-Authored-By: Remy <remy.haemmerle@daml.com>
* Update compiler/scenario-service/server/src/main/scala/com/digitalasset/daml/lf/scenario/Conversions.scala
Co-Authored-By: Remy <remy.haemmerle@daml.com>
* Update compiler/scenario-service/server/src/main/scala/com/digitalasset/daml/lf/scenario/Conversions.scala
Co-Authored-By: Remy <remy.haemmerle@daml.com>
* Update compiler/scenario-service/server/src/main/scala/com/digitalasset/daml/lf/scenario/Conversions.scala
Co-Authored-By: Remy <remy.haemmerle@daml.com>
Co-authored-by: Remy <remy.haemmerle@daml.com>
* Improve error messages in daml repl on calls to `error`
There were two issues with calls to `error`:
1. This one is harmless but somewhat annoying: When calling `error` we
run into the log statement in `stepToValue` which prints out the
error message in a fairly reasonable form (you can argue whether
Error: User abort: is a super useful prefix but that’s a relatively
minor issue). Afterwards we then call `println` on the failed
future. However, that will just print the type of the exception
which isn’t something we want to show to users. I’ve just disabled
the println statement if the exception is `SError`.
2. This one is a bigger issue: `throw x` is not the same as
`Future.failed(x)`. I only fully realized the difference fairly
recently. The former fails before it produces a future. So `(throw
x).onComplete(…)` will never execute the callback. The latter is
just a failed future. It is rather confusing to have a function
that returns a future but then throws an exception instead of a
future and it confuses the grpc library which prints out a horrible
exception. I’ve changed all calls to `throw` in `runWithClients` to
instead use `Future.failed` and `flatMap` (in the form of
for-comprehensions).
There are still a few calls in `run` left which I’ll leave for a
separate PR.
I think we need to factor out some helper functions here to make this
a bit more manageable (e.g. for the Converter.toFuture) stuff but I’ll
leave that for a separate PR. You probably want to view this with
whitespace diffs disabled.
changelog_begin
- [DAML Repl] DAML Repl now produces better error messages on calls to
`error` and `abort`.
changelog_end
* Switch stepToValue to return Either
mkConfFile was a bit of a mess before. Half of the arguments we passed
in via `PackageConfigFields` were unused as shown by the fact that we
set them to `error …` in various places where we did not have that
information. More importantly rather than passing in the unit ids
which need to end up in the GHC package config, we passed in file
names which required us to parse the DAR again and have a bunch of
hacks where file names with .dalf endings were not translated.
This PR changes this to only pass in the fields we need and pass in
dependencies directly as unit ids.
changelog_begin
changelog_end
* Fix unstableSplitOn
unstableSplitOn is supposed to behave like splitOn but fast™ but it
didn’t live up to that promise for a few reasons:
1. Java’s split method by default drops empty strings at the
end. Passing a second negative parameter avoids that.
2. Java’s split method does regex splitting so we need to quote the
string.
3. Java’s split method splits on an empty pattern whereas we want to
simply preserve the input.
I’ve added regression tests for this and for unstableDrop and a few
other functions while I was at it.
changelog_begin
changelog_end
* Update compiler/damlc/tests/daml-test-files/UnstableText.daml
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* Haskell: Add assertFileExists to DA.Test.Util
This PR adds a helper function `assertFileExists` that captures the
`doesFileExist ... >>= assertBool ...` pattern that is very common in
our Haskell test suites. It also adds the inverse
`assertFileDoesNotExist` function. Both functions are now used where
appropriate.
CHANGELOG_BEGIN
CHANGELOG_END
* Add directory dependency to test-util lib
CHANGELOG_BEGIN
CHANGELOG_END
This is a spin off from the work for making module prefixing
work. There I wanted to be able to use the `GeneratePackageMap` rule
to get access to the modules in an LF package which requires to be in
an Action rather than in IO.
This resulted in a much larger refactoring than I expected, so here is
a list of changes to ease review:
1. I’ve split off Development/IDE/Core/RuleTypes/Daml.hs into its own
Bazel targets to avoid cycles. This allows us to use a rule without
depending on the implementation of that rule.
2. Development/IDE/Core/IdeState/Daml.hs has moved into its own Bazel
target. There is a lot of stuff that needs `withDamlIdeState` now
since the `ghcide` `initialise` function does not add our Shake rule
for getting the GHC session and making all of that depend on
damlc:lib creates a mess.
3. The actual logic of the initialization has stayed the same but
moved into a rule in Development/IDE/Core/Rules/Daml.hs.
4. As mentioned above, a few things that could previously get away
with only the rules provided by ghcide now need our own rules so
they switched to `withDamlIdeState`. This mainly affects `damlc
docs`.
5. Making daml-docs work with the ofInterestRule is a bit tricky.I did
find the issue and included the fix but also disabled the
ofInterestRule since it really does not make sense to generate Core
in the background.
changelog_begin
changelog_end
* Set the `Bearer ` prefix in bindings.
* Make the `Bearer ` prefix in the authorization header mandatory.
* Bearer prefix can be removed from the token file.
CHANGELOG_BEGIN
[Extractor]: The ``Bearer `` prefix can be removed from the token file.
It is added automatically.
[Navigator]: The ``Bearer `` prefix can be removed from the token file.
It is added automatically.
[DAML Script] The ``Bearer `` prefix can be removed from the token file. It
is added automatically.
[DAML Repl] The ``Bearer `` prefix can be removed from the token file. It is
added automatically.
[Scala Bindings] The ``Bearer `` prefix can be removed from the token. It is
added automatically.
[Java Bindings] The ``Bearer `` prefix can be removed from the token. It is
added automatically.
[DAML Integration Kit] ``AuthService`` implementations MUST read the
``Authorization`` header and the value of the header MUST start with
``Bearer ``.
CHANGELOG_END
* Split up repl tests to make them faster
This PR splits up the tests into the tests for TLS and Auth and the
tests for the actual functionality.
The func tests use the repl as a library which allows them to be
significantly faster:
1. We only need to start the service process once.
2. We only need to initialize the package db once.
There is at least one other point that I did not address for now and
that is only loading the packages into the repl service once. While
loading them multiple times is a noop, it still has a performance
implication.
Sadly, this has turned out much more messy than I thought it would be
due to various issues with haskeline/repline/tasty/computers. The
details are in a comment in DA.Test.Repl.FuncTests.
changelog_begin
changelog_end
* Try to nuke cache on window selectively
* Enable cache again
Packages com.digitalasset.daml and com.daml have been unified under com.daml
Ledger API and DAML-LF DEV protos have also been moved from `com/digitalasset`
to `com/daml` on the file system.
Protos for already released DAML LF versions (1.6, 1.7, 1.8) stay in the
package `com.digitalasset`.
CHANGELOG_BEGIN
[SDK] All Java and Scala packages starting with
``com.digitalasset.daml`` and ``com.digitalasset`` are now consolidated
under ``com.daml``. Simply changing imports should be enough to
migrate your code.
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
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
* 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>
* 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
- 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
* Use repline for DAML REPL
CHANGELOG_BEGIN
CHANGELOG_END
* REPL server print error messages
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* Improve handling of exposed-modules with data-dependencies
Previously, we tried to rename all modules of a dependency via
--package. This fails if some of those modules are not exported. This
was trivial to hit as a user since the ``daml-trigger`` library made
use of this.
This PR adds a few things to improve the situation:
1. We only rename modules that are exposed. This fixes the issue if
you don’t actually reference a non-exposed module from your
data-dependency.
2. I’ve removed the exposed-modules from daml-trigger. I don’t think
they are essential here given that the module name has `Internal`
in the name and it’s too easy to have something that actually
references the non-exposed module since the types are reexported.
3. I’ve added documentation that mentions this issue.
4. I’ve added a warning if your exposed-modules are excluding some
modules. Maybe worth turning this into an error in the future.
changelog_begin
changelog_end
* Update compiler/damlc/lib/DA/Cli/Damlc/Packaging.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
Co-authored-by: associahedron <231829+associahedron@users.noreply.github.com>
Until #5294, we had some test cases for `damlc` flying around there
were never run because they had an upper bound on an unsupported
DAML-LF version. This PR makes sure we'll clean up such test cases in
the future.
CHANGELOG_BEGIN
CHANGELOG_END
* Extract package config type to a separate package.
changelog_begin
changelog_end
* update copyright headers
* run buildifier-fix
* fix src_strip_prefix
* Heres the file I accidentally deleted
* buildifier-fix again
DAML-LF 1.6 is the baseline vesion we want to support with the next
SDK release.
CHANGELOG_BEGIN
- [DAML Compiler] Drop support for reading DARs using DAML-LF 1.5.
Please recompile your DAML to a newer DAML-LF version in case you
have such DARs.
CHANGELOG_END
* Turn warnings for module name/record name mismatches into errors
The module name warning existed for ages. We started warning about the
record name mismatch in 0.13.55 so I’d like to turn it into an error
before 1.0
changelog_begin
- [DAML Compiler] File names must now match up with module names. This
already produced a warning in previous releases.
- [DAML Compiler] It is now an error to define a record with a single
constructor where the constructor does not match the type
name. To fix the error you need to change ```data X = Y { … }``` to
```data X = X { … }```. This restriction only applies to
single-constructor records. Variants and enums are not affected.
This already produced a warning in 0.13.55.
changelog_end
* Fix integration tests
* Fix docs
* Fix lsp tests
* New comamnd: daml ledger fetch-dar
`daml ledger fetch-dar [PID] [PATH]`
Download a `Package` and it's dependencies from a ledger, given a root `packageId`, and re-construct a valid `.dar` file. Addresses issue #5037.
The original package names are not reconstructed.
CHANGELOG_BEGIN
CHANGELOG_END
* address some comments
* fix spello
* attempt: recoverPackageName
* recover main package name & version
* Try to fix integration tests on Windows
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Adding more syntax is just confusing for beginners so these are not
particularly helpful and I would argue that they aren’t that useful in
general even once you move past the beginner stage.
changelog_begin
changelog_end
* Make name collision check more strict
This PR extends the name collision check to catch collisions between
A:B (type B in module A) and module A.B.C. For now this is just a
warning and not an error. Once we turn it into an error, we also need
to add this to the Scala collision checker.
There is a fair bit of plumbing required to make warnings work but on
the plus side we get multiple errors at once now instead of erroring
out on the first one.
changelog_begin
- [DAML Compiler] The name collision check has been extended to also
count the case as a collision where you have a type B in module A and a module
A.B.C (but no module A.B). This is a warning in this SDK release but
will become an error in a future release. The typescript codegen is
not usable on packages that don’t uphold this restriction.
changelog_end
* Address review comments
* Remove unused da_doc_package
The only use-site was `//compiler/daml-licenses:daml-licenses`, which
itself was unused.
* Remove unused notices-gen
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
Add keys with maintainers to Fetch nodes
The new field is populated by the interpreter whenever the fetched
contract has a key. Used for contract key reinterpretation in Canton.
CHANGELOG_BEGIN
- [DAML-LF] Add keys with maintainers to Fetch nodes in transactions.
CHANGELOG_END
* Depend on LF version specific daml-libs
* daml-script.dar build multiple LF versions
CHANGELOG_BEGIN
[DAML Script] The `daml-script` library is now available in multiple LF
versions, namely 1.7, 1.8, and 1.dev.
CHANGELOG_END
* daml-trigger.dar build multiple LF versions
[DAML Triggers] The `daml-trigger` library is now available in multiple
LF versions, namely 1.7, 1.8, and 1.dev.
* Keep daml-script.dar available for tests
* Keep daml-trigger.dar available for tests
* daml-libs LF versions integration test
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
This PR adds as `ScriptLedgerClient` trait (happy to change the name
if anyone has a better proposal) that abstracts over the interaction
with the ledger. This will allow us to plug in a different
implementation for interacting with the JSON API so we can run DAML
scripts against DABL or other environments where gRPC is not a
workable option. Note that this PR does not yet add the implementation
for interacting with the JSON API. I’ll leave that for a separate PR.
changelog_begin
changelog_end
* Tighten result type
Command execution can't result in a sequencer error
* New helper method for extracting used contracts
* New error clause
* Add a DAO query for the maximum time of contracts
* Implement algorithm for finding ledger time
CHANGELOG_BEGIN
CHANGELOG_END
* fixup ledgerTimeHelper
* Use new ledger time algorithm
* Mark LET/MRT as deprecated
CHANGELOG_BEGIN
- [Ledger API] DAML ledgers have switched to a new ledger time model.
The ledger_effective_time and maximum_record_time fields of command submission are deprecated,
the ledger time of transactions is instead set automatically by the ledger API server.
Ledger time is no longer strictly monotonically increasing, but only follows causal monotonicity:
ledger time of transactions is greater than or equal to the ledger time of any used contract.
See `#4345 <https://github.com/digital-asset/daml/issues/4345>`__.
CHANGELOG_END
* Add ledger time skew check
* Remove command updater
LET/MRT are now deprecated, this class is now useless
* Remove old time model validator
* Switch to new time model check: kvutils
* Switch to new time model check: in-memory ledger
* Switch to new time model check: SqlLedger
* Use initial ledger config
* Ignore user provided LET
* Use TimeProvider in submission services
* Use deduplication_time in daml-script runner
- Also remove unnecessary command completion output of CommandTracker.
- Remove usage of maximum record time in CommandTracker.
* Use arbitrary default value for deduplication time
* Use built-in Instant ordering
* Remove obsolete test
* Remove obsolete test: CommandStaticTimeIT
* Refactor test: TransactionMRTCompliance
* Disable test: CommandTrackerFlow timeout
* thread maxDeduplicationTime through to CommandTracker
* Improve test
* Refactor command client configuration
* Deduplication time should always use UTC
* Add missing method in TimedIndexService after rebase
* Put more details into the deduplication error response.
* Use system time for command dedup submittedAt.
* Use explicit UTC time source in command validator
* Revert CommandTracker[Flow] to previous completion-recovering-behavior
* Adapt scala client command config to new config params
Co-authored-by: Gerolf Seitz <gerolf.seitz@digitalasset.com>
* Integrate create-daml-app into the assistant
fixes#4868
changelog_begin
- [DAML Assistant] Add a new ``daml create-daml-app`` command for creating a project based on
`create-daml-app <https://github.com/digital-asset/create-daml-app>`_.
changelog_end
* Try random things hoping to fix windows
* Try random things hoping to fix things on macos
* Use MutableCompiledPackages in REPL
This avoids unnecessary recompilation of loaded packages.
CHANGELOG_BEGIN
CHANGELOG_END
* Track compiled definitions explicitly
Compile packages on load directly.
Use `PureCompiledPackages` extended with package for current line in
REPL service `runScript`.
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
changelog_begin
- [DAML Compiler] The default output DAML-LF target version is now
1.8. You can target 1.7 by specifying ``--target=1.7`` in the
``build-options`` field in your ``daml.yaml``.
changelog_end
Fix daml2ts tests
This PR bumps ghcide, haskell-lsp and haskell-lsp-types. There aren’t
really any important changes in ghcide itself but the haskell-lsp
update includes my fix for crashing completions.
One change in ghcide itself is that NormalizedFilePath got moved to
haskell-lsp. ghcide needs special treatment for empty file paths so we
use `toNormalizedFilePath'` from ghcide instead of
`toNormalizedFilePath` from `haskell-lsp`. I’ve added an hlint rule to
enforce this.
changelog_begin
changelog_end
* Support partial patterns in DAML repl
This PR improves the support for partial patterns in DAML repl by
making sure that they fail on the line itself rather than some
subsequent line and avoids the partial pattern match warnings on all
following lines.
changelog_begin
changelog_end
* Fix tests
* Support complex patterns in DAML REPL
Previously, we only supported simple variable patterns in DAML
repl. This PR extends this to support pretty much all patterns. The
main complexity here is in handling shadowing correctly but I’m
reasonably confident the solution here is sensible.
What doesn’t work properly yet is partial patterns. I’ve added a
comment describing the issue and a potential solution. Given that this
isn’t a regression apart from maybe a slightly worse error message, I
think it makes sense to merge this PR and fix that separately.
changelog_begin
- [DAML REPL - Experimental] You can now use more complex patterns in
statements, e.g., ``(x,y) <- pure (1,2)``.
changelog_end
* Update compiler/damlc/daml-compiler/src/DA/Daml/Compiler/Repl.hs
Co-Authored-By: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Update compiler/damlc/daml-compiler/src/DA/Daml/Compiler/Repl.hs
Co-Authored-By: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Improve error messages
* update documentation
Co-authored-by: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Factor out common identifier generation
For `DA.Types`, `DA.Internal.Any`, and `Daml.Script`.
* Factor out Script type for DAML scripts
* Adapt DAML script test runners
* Adapt REPL
CHANGELOG_BEGIN
CHANGELOG_END
* ./fmt.sh
* Avoid `unapply`
addressing
https://github.com/digital-asset/daml/pull/5076#discussion_r394526881
* Pure Script.fromIdentifier
* Pure Script.fromDar
* Simplify test script discovery
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
1.dev is changing in ways wich break this as predicted by the comment,
so let’s freeze this now that we have a release that supports this.
changelog_begin
changelog_end
This PR exposes the new generic comparison primitives, preferring them
to the older comparison primitives whenever they are available. It also
separates the generic comparison feature from the GenMap feature,
because that just makes sense.
changelog_begin
changelog_end
* Support authentication and TLS in DAML repl
changelog_begin
- [DAML Repl - Experimental] You can now connect to a ledger via TLS
by passing ``--tls`` to ``daml repl``
- [DAML Repl - Experimental] You can now connect to a ledger with
authentication by passing the token via ``--access-token-file`` to
``daml repl``.
changelog_end
* try to fix linking on windows
* windows is weird
* gnah
While `damlc package` should really just go away, the fix here is
simple enough that it makes sense to include it.
fixes#4994
changelog_begin
changelog_end
* Update rules_haskell
The workaround for linking against `Cffi` in the REPL has been
upstreamed in a more generalized form.
CHANGELOG_BEGIN
CHANGELOG_END
* ghcide: Use rules_haskell's hie-bios support
* Document `ghcide` Bazel integration
* Rename files to match module names
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
This makes sure that they won’t break once we switch defaults. For
consistency they are specified via `build-options` everywhere.
changelog_begin
changelog_end
We previously had 3 slightly different but consistently shitty logic
for handling this in the tests for daml-helper daml repl and the
Haskell ledger bindings. This PR introduces a module that is flexible
enough to capture all their needs and hopefully is somewhat less
shitty.
changelog_begin
changelog_end
This doesn’t really make sense since the main point of targetting an older
LF version is because your server does not support the newer LF
version but including dependencies in newer LF versions makes that
completely useless. In the current state, this also produces a bunch
of errors that look very confusing and while we might be able to fix
them, I don’t think it’s worth doing.
changelog_begin
changelog_end
fixes#4596
* Add a warning for data X = Y {..}.
Part of #4718.
changelog_begin
- [DAML Compiler] The DAML compiler now emits a warning when you declare a single-constructor record type where the constructor name does not match the type name, such as ``data X = Y {...}``. This kind of type declaration can cause problems with cross-SDK upgrades because the record constructor name cannot be recorded in the DAML-LF representation. In the future, this warning will be upgraded to an error.
changelog_end
* s/Ctor/Constructor/g
Currently the repl server is bound to 0.0.0.0, which is not great for
security and makes running the tests a bit disruptive on macOS.
This binds it to 127.0.0.1 instead.
CHANGELOG_BEGIN
- [DAML Repl - Experimental] The REPL server will now bind to 127.0.0.1
instead of 0.0.0.0.
CHANGELOG_END
* Track erased types in data-dependencies.
This PR introduces a tracker for Erased types, DA.Generics, and any type, typeclass, or typeclass instance that dependens on them transitively. This is designed to detect and cut out any such definition that will cause problems.
Apologies for the large PR. Originally this was just a small extension to the tracking of old-style typeclasses, but each bugfix uncovered a new bug, and the only way to get it to completely work was to do it all at once. That's why the tracker is so extensive -- the only thing it doesn't track is regular functions, because they will never introduce a cyclic reference to an erased type that gets exposed in the type system (until we implement dependent DAML).
Right now the tracker runs once per data-dependency module, but in a future PR I will make it run once per data-dependency package to reduce the repetitive. This was all tested on a very large DAR, and it runs fine, but it should be much faster once it runs once per package.
changelog_begin
changelog_end
* lint
* Address comments
* Add a great test case
Both were previously binding 0.0.0.0, which is inherently insecure. More
importantly to me, that meant running `bazel test //...` essentially
rendered my computer unusable for however long it took (which is
_long_), as it kept popping up focus-stealing dialogs about whether or
not I wanted to trust "java" to open an incoming network connection.
The ScenarioService does not seem to have an existing setup for CLI args
and my Scala-fu is not good enough to add one, so I just changed the
hard-coded path.
The JSON API already had an option, just with the wrong default. This is
technically a breaking change, but I'm hoping to pass it under the
"experimental" flag we still have on the JSON API.
CHANGELOG_BEGIN
- [JSON API - Experimental] As a security improvement, the JSON API
server will now bind on ``127.0.0.1`` by default. Previous behaviour was
to bind on ``0.0.0.0``; you can get that behaviour back by passing in
the (existing) flag ``--address 0.0.0.0``.
- [DAML SDK] The Scenario Service will now bind on ``127.0.0.1``. Previous
behaviour was to bind on ``0.0.0.0``.
CHANGELOG_END
This introduces a `HasSubmit` typeclass (following the naming scheme
of `HasCreate`, …) and instances for `Scenario` and `Script`. This
avoids the need to hide `submit` in every single DAML script.
changelog_begin
- [DAML Standard Library] ``submit`` and ``submitMustFail`` are now
overloaded so that they can be used in both scenarios and DAML script.
changelog_end
* Cache unmangleIdentifier
Previously we unmangled once per reference to an identifier rather
than doing the unmangling once per entry in the string interning
table. This PR fixes this which brings a pretty decent performance
improvement. On my testcase the time for converting for converting
from the low-level proto AST to the high-level Haskell AST goes down
from 13.5 to 7.5s on a certain DALF that we know very well. Max
residency also goes down from 2GB to 1.5GB (although that number is
somewhat unreliable ime) and allocations drop by 8%.
changelog_begin
changelog_end
* Move error message to unmangleIdentifier
* Remove damlc migrate
``damlc migrate`` hasn’t worked for quite a while and we emitted a
warning for months so given that we don’t have plans to make it work
again in the near future, I think it does more harm than good to keep
it around.
changelog_begin
- [DAML Compiler] After being deprecated for a while the ``damlc
migrate`` command has now been removed. See
https://docs.daml.com/upgrade/ for up to date documentation
on model upgrades.
changelog_end
fixes#3704 (by removing the tests 😇)
* yeah the windows cache is once again broken \o/
* Revert "yeah the windows cache is once again broken \o/"
This reverts commit 38d7877aa4.
* Speed up unmangleIdentifier
On my (admittedly not super scientific) benchmark, this brings the
time used to convert from the low-level proto Haskell AST to the
high-level AST from 20s down to 16s on a certain DALF that we are all
too familiar with.
changelog_begin
changelog_end
* address review comments
The `decodeValueName` code is rather confusing. It calls things
unmangled that are mangled and the other way around.
Furthermore, it unmangles twice, once in `decodeNameString` and once
directly in `decodeValueName`. The code claims that this is a
compatiblity hack but unless someone can explain to me what exactly is
failing here or CI fails, I would prefer to just kill this.
changelog_begin
changelog_end
* Make `debug` a bit more lazy
Previously `debug x >>= f` would print the debug statement when it got
evaluated rather than when the monadic execution got executed. This is
rather confusing. Now we explicitly make it lazy by wrapping the trace
statement in a lambda passed to >>=.
changelog_begin
- [DAML Standard Library] Fix a bug where ``debug`` printed the trace
statement before the action got executed. Note that this means that
``debug`` now has a slightly more restrictive type. You can use
``trace`` directly if this causes problems.
changelog_end
* Update compiler/damlc/tests/src/DA/Test/ShakeIdeClient.hs
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
Given that these two group of tests run for the same combination of LF
versions, I don’t see any reason why we should keep them
separate. Merging them, speeds up the packaging tests by > 50s on my
local machine.
changelog_begin
changelog_end
Rather than decoding everything twice, we can only rewrite references
which is measurably faster (> 5s out of 60s on the packaging tests).
changelog_begin
changelog_end
* Freeze DAML-LF 1.8
Two minor points that I did not mention in the previous PR:
We also include the renaming of structural records to `struct` and the
renaming of `Map` to `TextMap`.
There are some minor changes around the LF encoder tests which need to
be able to emit package metadata properly so I’ve added it to the
parser. Sorry for not splitting that out.
Following the process used for the DAML-LF 1.7 release, this does not
yet include the frozen proto file.
changelog_begin
- [DAML-LF] Release DAML-LF 1.8:
* Rename structural records to ``Struct``. Note that
structural records are not exposed in DAML.
* Rename ``Map`` to ``TextMap``.
* Add type synonyms. Note that type synonyms are not serializable.
* Add package metadata, i.e., package names and versions.
Note that the default output of ``damlc`` is stil DAML-LF 1.7. You
can produce DAML-LF 1.8 by passing ``--target=1.8``.
changelog_end
* Update encoder
* Update java codegen tests
* Update comment in scala codegen
* Handle TSynApp in interface reader
* Bump lf_stable_version to 1.7
* Fix kvutils tests
We will only include type synonyms and package metadata (which are
used for Cross-SDK model upgrades). Everything else stays in 1.dev for
now.
changelog_begin
changelog_end
I’m not really happy with this “fix” but after having spend way too
much time on this, this was the best I came up with. (The details are
in an inline comment). If anyone has better ideas, I’m all ears.
changelog_begin
changelog_end
Replace `daml-lf-repl validate` in packaging tests with `damlc validate-dar`.
Simplify test setup a little by passing tools (damlc,validate, etc) in a record.
changelog_begin
changelog_end
This reduces the number of GHCs to 2 on Linux (regular and DWARF) and
1 on macOS. Given that each derivation is > 1 GB this should hopefully
help a bit.
changelog_begin
changelog_end
Previously, we mapped `dependencies` under
Pkg_$pkgId.originalmodule name and imported them this way. However, we
did not map `dependencies` the same way. This PR unifies the two and
cleans up the import handling logic a bit.
This also fixes imports if we have two packages with the same name but
a different version since the package name (which is the only thing
usable in package-qualified imports) is not sufficient to
disambiguate. I’ve added a test for this.
changelog_begin
changelog_end
These commands were intended for debugging but neither @associahedron
nor I actually use them since running `daml build` and looking at the
generated files in `.daml` is a much more robust solution.
I’ve also deleted some leftover code from the old-style
data-dependencise where we generated actual template instances (not
just dummy instances). We’ve already deleted everything else around
this, this was just leftover by accident.
The only usage was a testcase which I’ve just switched over to using
`daml build`.
changelog_begin
changelog_end
Context
=======
After multiple discussions about our current release schedule and
process, we've come to the conclusion that we need to be able to make a
distinction between technical snapshots and marketing releases. In other
words, we need to be able to create a bundle for early adopters to test
without making it an officially-supported version, and without
necessarily implying everyone should go through the trouble of
upgrading. The underlying goal is to have less frequent but more stable
"official" releases.
This PR is a proposal for a new release process designed under the
following constraints:
- Reuse as much as possible of the existing infrastructure, to minimize
effort but also chances of disruptions.
- Have the ability to create "snapshot"/"nightly"/... releases that are
not meant for general public consumption, but can still be used by savvy
users without jumping through too many extra hoops (ideally just
swapping in a slightly-weirder version string).
- Have the ability to promote an existing snapshot release to "official"
release status, with as few changes as possible in-between, so we can be
confident that the official release is what we tested as a prerelease.
- Have as much of the release pipeline shared between the two types of
releases, to avoid discovering non-transient problems while trying to
promote a snapshot to an official release.
- Triggerring a release should still be done through a PR, so we can
keep the same approval process for SOC2 auditability.
The gist of this proposal is to replace the current `VERSION` file with
a `LATEST` file, which would have the following format:
```
ef5d32b7438e481de0235c5538aedab419682388 0.13.53-alpha.20200214.3025.ef5d32b7
```
This file would be maintained with a script to reduce manual labor in
producing the version string. Other than that, the process will be
largely the same, with releases triggered by changes to this `LATEST`
and the release notes files.
Version numbers
===============
Because one of the goals is to reduce the velocity of our published
version numbers, we need a different version scheme for our snapshot
releases. Fortunately, most version schemes have some support for that;
unfortunately, the SDK sits at the intersection of three different
version schemes that have made incompatible choices. Without going into
too much detail:
- Semantic versioning (which we chose as the version format for the SDK
version number) allows for "prerelease" version numbers as well as
"metadata"; an example of a complete version string would be
`1.2.3-nightly.201+server12.43`. The "main" part of the version string
always has to have 3 numbers separated by dots; the "prerelease"
(after the `-` but before the `+`) and the "metadata" (after the `+`)
parts are optional and, if present, must consist of one or more segments
separated by dots, where a segment can be either a number or an
alphanumeric string. In terms of ordering, metadata is irrelevant and
any version with a prerelease string is before the corresponding "main"
version string alone. Amongst prereleases, segments are compared in
order with purely numeric ones compared as numbers and mixed ones
compared lexicographically. So 1.2.3 is more recent than 1.2.3-1,
which is itself less recent than 1.2.3-2.
- Maven version strings are any number of segments separated by a `.`, a
`-`, or a transition between a number and a letter. Version strings
are compared element-wise, with numeric segments being compared as
numbers. Alphabetic segments are treated specially if they happen to be
one of a handful of magic words (such as "alpha", "beta" or "snapshot"
for example) which count as "qualifiers"; a version string with a
qualifier is "before" its prefix (`1.2.3` is before `1.2.3-alpha.3`,
which is the same as `1.2.3-alpha3` or `1.2.3-alpha-3`), and there is a
special ordering amongst qualifiers. Other alphabetic segments are
compared alphabetically and count as being "after" their prefix
(`1.2.3-really-final-this-time` counts as being released after `1.2.3`).
- GHC package numbers are comprised of any number of numeric segments
separated by `.`, plus an optional (though deprecated) alphanumeric
"version tag" separated by a `-`. I could not find any official
documentation on ordering for the version tag; numeric segments are
compared as numbers.
- npm uses semantic versioning so that is covered already.
After much more investigation than I'd care to admit, I have come up
with the following compromise as the least-bad solution. First,
obviously, the version string for stable/marketing versions is going to
be "standard" semver, i.e. major.minor.patch, all numbers, which works,
and sorts as expected, for all three schemes. For snapshot releases, we
shall use the following (semver) format:
```
0.13.53-alpha.20200214.3025.ef5d32b7
```
where the components are, respectively:
- `0.13.53`: the expected version string of the next "stable" release.
- `alpha`: a marker that hopefully scares people enough.
- `20200214`: the date of the release commit, which _MUST_ be on
master.
- `3025`: the number of commits in master up to the release commit
(included). Because we have a linear, append-only master branch, this
uniquely identifies the commit.
- `ef5d32b7ù : the first 8 characters of the release commit sha. This is
not strictly speaking necessary, but makes it a lot more convenient to
identify the commit.
The main downsides of this format are:
1. It is not a valid format for GHC packages. We do not publish GHC
packages from the SDK (so far we have instead opted to release our
Haskell code as separate packages entirely), so this should not be an
issue. However, our SDK version currently leaks to `ghc-pkg` as the
version string for the stdlib (and prim) packages. This PR addresses
that by tweaking the compiler to remove the offending bits, so `ghc-pkg`
would see the above version number as `0.13.53.20200214.3025`, which
should be enough to uniquely identify it. Note that, as far as I could
find out, this number would never be exposed to users.
2. It is rather long, which I think is good from a human perspective as
it makes it more scary. However, I have been told that this may be
long enough to cause issues on Windows by pushing us past the max path
size limitation of that "OS". I suggest we try it and see what
happens.
The upsides are:
- It clearly indicates it is an unstable release (`alpha`).
- It clearly indicates how old it is, by including the date.
- To humans, it is immediately obvious which version is "later" even if
they have the same date, allowing us to release same-day patches if
needed. (Note: that is, commits that were made on the same day; the
release date itself is irrelevant here.)
- It contains the git sha so the commit built for that release is
immediately obvious.
- It sorts correctly under all schemes (modulo the modification for
GHC).
Alternatives I considered:
- Pander to GHC: 0.13.53-alpha-20200214-3025-ef5d32b7. This format would
be accepted by all schemes, but will not sort as expected under semantic
versioning (though Maven will be fine). I have no idea how it will sort
under GHC.
- Not having any non-numeric component, e.g. `0.13.53.20200214.3025`.
This is not valid semantic versioning and is therefore rejected by
npm.
- Not having detailed info: just go with `0.13.53-snapshot`. This is
what is generally done in the Java world, but we then lose track of what
version is actually in use and I'm concerned about bug reports. This
would also not let us publish to the main Maven repo (at least not more
than once), as artifacts there are supposed to be immutable.
- No having a qualifier: `0.13.53-3025` would be acceptable to all three
version formats. However, it would not clearly indicate to humans that
it is not meant as a stable version, and would sort differently under
semantic versioning (which counts it as a prerelease, i.e. before
`0.13.53`) than under maven (which counts it as a patch, so after
`0.13.53`).
- Just counting releases: `0.13.53-alpha.1`, where we just count the
number of prereleases in-between `0.13.52` and the next. This is
currently the fallback plan if Windows path length causes issues. It
would be less convenient to map releases to commits, but it could still
be done via querying the history of the `LATEST` file.
Release notes
=============
> Note: We have decided not to have release notes for snapshot releases.
Release notes are a bit tricky. Because we want the ability to make
snapshot releases, then later on promote them to stable releases, it
follows that we want to build commits from the past. However, if we
decide post-hoc that a commit is actually a good candidate for a
release, there is no way that commit can have the appropriate release
notes: it cannot know what version number it's getting, and, moreover,
we now track changes in commit messages. And I do not think anyone wants
to go back to the release notes file being a merge bottleneck.
But release notes need to be published to the releases blog upon
releasing a stable version, and the docs website needs to be updated and
include them.
The only sensible solution here is to pick up the release notes as of
the commit that triggers the release. As the docs cron runs
asynchronously, this means walking down the git history to find the
relevant commit.
> Note: We could probably do away with the asynchronicity at this point.
> It was originally included to cover for the possibility of a release
> failing. If we are releasing commits from the past after they have been
> tested, this should not be an issue anymore. If the docs generation were
> part of the synchronous release step, it would have direct access to the
> correct release notes without having to walk down the git history.
>
> However, I think it is more prudent to keep this change as a future step,
> after we're confident the new release scheme does indeed produce much more
> reliable "stable" releases.
New release process
===================
Just like releases are currently controlled mostly by detecting
changes to the `VERSION` file, the new process will be controlled by
detecting changes to the `LATEST` file. The format of that file will
include both the version string and the corresponding SHA.
Upon detecting a change to the `LATEST` file, CI will run the entire
release process, just like it does now with the VERSION file. The main
differences are:
1. Before running the release step, CI will checkout the commit
specified in the LATEST file. This requires separating the release
step from the build step, which in my opinion is cleaner anyway.
2. The `//:VERSION` Bazel target is replaced by a repository rule
that gets the version to build from an environment variable, with a
default of `0.0.0` to remain consistent with the current `daml-head`
behaviour.
Some of the manual steps will need to be skipped for a snapshot release.
See amended `release/RELEASE.md` in this commit for details.
The main caveat of this approach is that the official release will be a
different binary from the corresponding snapshot. It will have been
built from the same source, but with a different version string. This is
somewhat mitigated by Bazel caching, meaning any build step that does
not depend on the version string should use the cache and produce
identical results. I do not think this can be avoided when our artifact
includes its own version number.
I must note, though, that while going through the changes required after
removing the `VERSION` file, I have been quite surprised at the sheer number of
things that actually depend on the SDK version number. I believe we should
look into reducing that over time.
CHANGELOG_BEGIN
CHANGELOG_END
* Add documentation for DAML repl and advertise it
This PR adds some simple docs for ``daml repl`` and adds it to the
release notes.
changelog_begin
- [DAML Repl - Experimental] A new ``daml repl`` command that allows
you to use the ``DAML Script`` API interactively. Take a look at the
`documentation <https://docs.daml.com/daml-repl/>`_ for more
information.
changelog_end
* Update docs/source/daml-repl/index.rst
Co-Authored-By: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* s/Repl/REPL/
Co-authored-by: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Use package metadata instead of file names to infer unit ids
This PR adds a function that abstracts over whether we get metadata
from a filename (< 1.dev) or directly from the LF metadata.
There is more work to be done here, in particular, I want to clean up
the hacks around daml-prim/daml-stdlib but I’ll leave that for a
separate PR.
changelog_begin
changelog_end
* Update compiler/daml-lf-ast/src/DA/Daml/LF/Ast/Util.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Refactor getUnitId
Co-authored-by: associahedron <231829+associahedron@users.noreply.github.com>
* Graceful error handling in `daml repl`
This PR changes `daml repl` to handle errors (parse errors, type
errors, unsupported statement errors, script errors) gracefully
and just emit an error message instead of tearing down the whole
process.
This gets the repl into a state where I think it’s sufficiently
user-friendly to be released (obviously there are tons of potential
improvements). The only thing missing before I’m comfortable
mentioning this in release notes and uninternalizing it are docs.
If you think there is something crucial that needs to be addressed
before, let me know.
changelog_begin
changelog_end
* why is windows
As mentioned in the title, this is still very experimental and needs
more work before we want to advertise it. However, the code is in a
somewhat reasonable shape, there are tests and I think even in the
current state it is already useful. Also this PR is already getting
very large so I don’t want to hold off much longer before merging this.
It is included in the SDK but hidden from `damlc --help` and `daml
--help` until the most pressing issues are addressed (primarily around
making sure that it doesn’t just shut down if you have a type error
and better error messages in general).
changelog_begin
changelog_end
This PR adds the necessary infrastructure to produce package metadata
in `damlc`.
For `damlc build` this works exactly as expected. There are a few edge
cases where we don’t have names and/or versions (namely scenarios,
damlc compile and damlc package). We don’t really care about the
metadata for those anyway, so I’ve just set it some default value.
changelog_begin
changelog_end
* Refactor handling of package names and versions
This is a preparatory refactoring PR in preparation for propagating
package metadata into DAML-LF. There are no actual changes in here.
Primarily the changes consist of 3 things:
1. In options, we split the `optMbPackageName` field which previously
contained the unit id into `optMbPackageName` and
`optMbPackageVersion`.
2. We use newtypes for names and versions and try to keep them pretty
much everywhere (the only place missing is `splitUnitId`, I’ll do that
separately).
3. We use `UnitId` where we want `name-version`.
As was probably to be expected, this surfaced some minor issues. They
are pretty much exclusively in debugging or “internal” commands so
I’ve mostly just added notes/todos.
changelog_begin
changelog_end
* cry about applicativedo
`addDays d (- r)` looks a bit confusing and it’s not obvious that
negative numbers even work.
changelog_begin
- [DAML Standard Library] Add `subtractDays` to the DAML Standard Library.
changelog_end
* Add package metadata to DAML-LF proto and the Haskell AST
This adds package metadata (currently only the package name and
version) to DAML-LF and the corresponding Haskell ASTs. This is useful
for debugging and “codegens” (typescript, damlc dependencies, …)
This PR does not yet add it to the Scala side or change the compiler
to actually produce this metadata.
Part of #4412
changelog_begin
changelog_end
* Address review comments
* Add type-level strings in DAML.
This PR adds a `PromotedText` stable package, with `PromotedText` type, which is used to encode type-level strings from DAML into DAML-LF. The reason for this is to preserve the `HasField` instance argument. This PR adds a test that `HasField` is succesfully reconstructed incontexts, during data-dependencies, which wasn't possible before.
changelog_begin
changelog_end
* adresss comments
* fix overly specific tests
* Use KeyHasher to serialize contract keys in kvutils
- Use Value instead of VersionedValue in GlobalKey as the versioning does not make sense here
and may be misleading as the a value with a different version but same meaning would still
be the same key.
- Relocate the KeyHasher to ledger-api-common so kvutils can use it (otherwise cyclic dependencies)
- Replace storing of the contract key as a VersionedValue with the hash produced by KeyHasher.
This is backwards incompatible. A compatible option would require us to query the key with both
the old way and the new way which is unattenable. We're making a calculated breaking change.
CHANGELOG_BEGIN
- [DAML Ledger Integration Kit] Serialize contract keys using a hash instead of the value in kvutils.
This is a backwards incompatible change to kvutils.
CHANGELOG_END
* Use proper hasher for contract keys and not KeyHasher
- Use Hash.scala, not KeyHasher.scala.
- Add hash to GlobalKey as we want the hash to be computed from the inside.
The use of KeyHasher will be later deprecated and replaced by this.
* Use "sealed abstract case class" trick instead of private ctor
and rebase fix
* Revert change to unsupported value version decode error
* Reformat code
* Add kvutils changelog entry and bump the version
* Make DAML's (>>) operator lazy in its second argument
Currently, when you write
```haskell
do
Left "wanted"
error "unwanted"
```
your computation fails with an exception coming from the `error "unwanted"`
call. However, `do`-notation suggests that you actually never get there but
rather bail out at the `Left "wanted"` line. The cause of this mismatch is
that GHC desugars the code above to
```haskell
Left "wanted" >> error "unwanted"
```
and since DAML is strict, we evaluate `error "unwanted"` _before_ evaluating
the application of `(>>)`.
This PR solves the problem by rewriting all expressions of the form `A >> B`,
and hence those of the form `do A; B` as well, to `A >>= \_ -> B`. This gives
the desired semantics with `(>>)` being lazy in its second argument.
However, these semantics only make sense for `Action`s (aka monads). Thus, we
need to restrict the constraint on `(>>)` from `Applicative` to `Action`.
(This is in line with what Haskell does.)
Moreover, the `Action` instance of the `Validation` applicative would lead
to undesriable behavior when using `do`-notation. Thus, we also drop this
`Action` instance and hence force the usage of the `ApplicativeDo` language
extension when using `do`-notation for `Validation`.
CHANGELOG_BEGIN
- [DAML Stdlib] Restrict the ``(>>)`` operator to instances of ``Action``
and make it lazy in its second argument. This gives expressions of the
form ``do A; B`` the desirable semantics of only running ``B`` when
``A`` is a successful action.
- [DAML Stdlib] Remove the ``Action`` and ``ActionFail`` instances for
``Validation`` in ``DA.Validation``. Please enable the ``ApplicativeDo``
language extension if you want to use ``Validation`` with ``do``-notation
and replace ``fail`` with ``DA.Validation.invalid``.
CHANGELOG_END
* Address @cocreature's remarks
CHANGELOG_BEGIN
CHANGELOG_END
We forgot to import the module that defines the duplicate instance
which causes problems if this instance is required for something else,
e.g. because it is a superclass of another instance.
This fixes the issue surfaced by the removal of the Action instance
for Validation in #4552.
changelog_begin
changelog_end
Shouldn’t really make a difference due to laziness but at least it
makes it explicit if we need to decode the archive to the AST or just
need to get the package id.
changelog_begin
changelog_end
On a simple quickstart project we spend about 0.7s in
createProjectPackageDb (all of it in the `withDamlIdeState`
part). This slows down our packaging tests significantly so for now
I’ve added some shortcircuiting if we don’t have any deps and
data-deps. We might want to find a nicer solution here in the
future but the whole code for setting up the package db is going to
move a around a fair bit so I don’t think it makes sense to do this
right now.
changelog_begin
changelog_end
I don’t have a great test case to demonstrate the problem but
`contexts = contexts + (ctxId -> ctx)` is definitely not an atomic
update which means that inserts can get lost.
changelog_begin
changelog_end
I’ve failed to reproduce this locally so far but on CI we sometimes
get the DLint warning that `True == True` is redundant before we get the
parse error which results in the tests failing. There is no reason why
we need to use `True == True` here anyway so the fix is to simply
replace it by `True`.
changelog_begin
changelog_end
If we get interrupted after updating our local view but before doing
the actual context update on the server side bad things happen. To fix
this, we first clone the context then update the clone which avoids
this and is a bit nicer than throwing an `uninterruptibleMask` around
updating the local view and sending the updateCtx gRPC request.
fixes#4525
changelog_begin
changelog_end
* Fix cross-sdk typeclass reexports in data-dependencies
Sorry for the somewhat large PR, the intermediate states sadly just
change error messages but don’t allow me to test the things they
enable (at least not without considerable effort).
There are a few things this PR fixes:
1. We did not properly expose `dependencies` while compiling
`data-dependencies`. Now they are mapped under a Pkg_$pkgId prefix.
2. We did not pass on `dependencies` to the LF typechecker and
various other places that tried to look up LF packages.
3. We did not filter out duplicate instances, e.g., `daml-prim`
defines `Eq` instances for `Either`. If we define that twice, we
will get an error.
4. The use of Generic in DA.Upgrade doesn’t work
(https://github.com/digital-asset/daml/issues/4470). For now,
I’ve added a somewhat crude hack to filter out typeclasses of a
given name. We should replace this by checking for `Erased`
but that is not yet used in 0.13.51 which I use in the test.
For the test, I’ve checked in a DAR built on 0.13.51 with DAML-LF
1.dev. Not sure if checking in DARs is a reasonable thing to do in the
long term but for now, this is small enough and let’s us move forward
with this.
changelog_begin
changelog_end
* Document envDepInstances
* Document TUnit match
* Update docs for stub binds
* Cleanup and document class rewrites
* Report assistant commands and errors via a logger.
CHANGELOG_BEGIN
CHANGELOG_END
* Hook up daml-assistant to a GCP logger.
* fix test case
* fix more tests
* Check opted in status in assistant.
* Anonimize args that have unexpected characters.
* More agressive anonimization
* add missing containers dependency
changelog_begin
- [DAML Standard Library] Add a ``subtract`` function which is useful
as a replacement for sections of ``(-)``, e.g., ``subtract 1`` is
equivalent to ``\x -> x - 1``.
changelog_end
This is a spin off from my fixes for making data-deps work with
typeclasses cross-SDK.
We only have the interface files for the main dalf so it doesn’t
really make sense to extract the other dalfs. The current behavior of
extracting all dalfs results in them being picked up by
`GeneratePackageMap` even if GHC doesn’t know about them which causes
issues in other placse.
I’ve adapted the collision check to check for transitive dependencies
when creating the project db.
changelog_begin
changelog_end
The string needs to include the full flag instead of only including
--package. Otherwise you get rather unhelpful error messages.
changelog_begin
changelog_end
* Handle multiple constraints on an instance in data-dependencies
Previously we translated `instance (Foo a, Foo b) => Foo (a, b) where`
into `instance Foo a => Foo b => Foo (a, b)` which is a syntax
error. We already did this correctly for `HasField` so this PR mostly
just shuffles things around to always use the non-HasField specific
parts.
changelog_begin
changelog_end
* Prefix fields of DFunHead wtih dfh
This adds a test for running the LSP server directly in the project
directory to make sure that we do not need to build first in that case
and that no --package flags are necessary.
changelog_begin
changelog_end
* Translate unsupported kinds to a special Erased type
This should simplify `data-dependencies` and avoid issues like #4470
since we can match on the type instead of having to guess which types
can and which cannot be translated back to DAML.
changelog_begin
changelog_end
* Switch to HashSet/HashMap for NormalizedUri/NormalizedFilePath
This matches the change to ghcide in
https://github.com/digital-asset/ghcide/pull/420. Now that we have
optimized Hashable instances it makes sense to use them as much as
possible.
changelog_begin
changelog_end
* debug windows crap
* Fix a bug in vr scenario notifications
* Revert "debug windows crap"
This reverts commit f58fdb92c1.
* attempt to fix windows
who are we kidding, this is not going to work
* Support multiple-packages in `damlc ide`
changelog_begin
- [DAML Studio] You can now open DAML Studio in the root of a
multi-package project instead of opening it separately for each
package. Take a look at the documentation for details on how to set
this up.
changelog_end
There are a few caveats here:
1. You need a ``daml.yaml`` in the root of your project directory. I
think this is somewhat sensible but we should add a warning to VSCode
if you open it in a directory that does not have a ``daml.yaml`` (in a
separate PR).
2. Changes are not picked up accross dependencies. This is a larger
undertaking and given the current setup simply impossible (we don’t
know that the source files of one package belong to the DAR referenced
in the ``dependencies`` field of the other package. We can make this a
bit better by at least detecting that the ``.dar`` has changed but
let’s do that separately.
3. Since ``daml init`` runs once on startup, it will run in the root
directory instead of initializing the package db of the individual
packages. This is fixable but will conflict with #4391 so let’s
address this separately.
I’ve added docs to the daml studio section that explain the caveats.
* Use the proper sdk version in lsp-tests
`fakeDynFlags` has been removed from ghcide. We still need it since we
set up our environment in weird ways and want it to be platform
independent so this PR just copies the definition into `daml`.
changelog_begin
changelog_end
We need to use runActionSync everywhere except for the IDE. Pretty
sure I’ve fixed all cases of those. We also need to use useE instead
of use_ since apparently exceptions shortcircuit shake meaning that
runActionSync doesn’t actually do sync. I’ve only fixed the cases that
we hit in the tests so we probably should do a more thorough pass
after this (I want to get this merged soon since it is quite flaky on
master).
changelog_begin
changelog_end
* Added checks for unit id conflicts.
changelog_begin
changelog_end
* Only report conflicting keys
* lint
* fix indentation
* Show conflicting package ids also
I’ve spend several hours trying to get them to fail on Linux and
Windows and have failed completely (apart from making my machine roun
out of memory, thanks crashplan). I also inserted explicit delays to
make the failure more often frequent without any sucess (at making it
fail). I don’t really have a satisfying explanation of why this is
gone now. My best guess is that the `ghcide` upgrade fixed this since
it included some fixes and changes around how we kill and start the
shake process.
fixes#4328
changelog_begin
changelog_end
This adds the NodeInfo trait to compute the informees of a node and the
required authorizers. This has been separated into its own trait as this
computation is also required (externally) for serialized transaction nodes
in a context where the full deserialization of the node would be prohibitively
expensive.
While doing this change and cleaning up transaction authorization it was
discovered that top-level fetches (which can only be created from scenarios)
did not include the submitter as a witnessing party.
CHANGELOG_BEGIN
[DAML SDK] Fix computation of witnesses of top-level fetch nodes in scenario results ("known to").
CHANGELOG_END
Previously, we did not send any message when users simply clicked away
the telemetry popup. Now we send a special message similar to the
opt-out message which only includes the machine id.
I’ve also changed the opt-out message to include the machine id.
changelog_begin
changelog_end
* Use a safer safeToReexport
This is much safer than the approximation from last time. The only downside is
introducing a dependency between data dependencies and our type checker,
but that seems safer than having two versions of `expandTypeSynonyms`
floating around (and perhaps this dependency is something we would end
up adding anyway).
changelog_begin
changelog_end
* Add own package to extPackages.
* Use mkTForalls
* simplify mkTForalls
* Re-export typeclasses in data-dependencies...
... whenever possible.
The `safeToReexport` over-approximation is simple but troubling, so
I'd like to get it fixed soon.
The inputs to generateSrcFromLfPkg (and the genInstances one) were
getting quite hairy, so I decided to pass a record instead.
changelog_begin
changelog_end
* Add a test
* Move generateSrcPkgFromLf to its original place
* Better docs and make envQualify more clear
* compute dependency ids in generate-src command
The packaging tests are already one of our slowest test suites and
damlc test takes quite a while since it has to spin up the scenario
service.
We already have tests for damlc tests so this PR moves the tests from
the packaging test suite that are specific to `damlc test` to those
tests which should balance things a bit better.
changelog_begin
changelog_end
Based on a comment by @cocreature in the last PR, this PR changes the
generation of typeclass instances to empty stubs, instead of adding
stub methods as well.
changelog_begin
changelog_end
Sadly my fix in https://github.com/digital-asset/daml/pull/4325 didn’t
seem to work (despite fixing the issue in my tests) so let’s mark this
as flaky until we figure it out.
changelog_begin
changelog_end
We have seen a couple of flaky tests runs on CI in the packaging test
caused by this. It is easy to reproduce if you add a delay in
diagnosticsLogger before printing the diagnostics which makes this
failure reproducible. With this patch, the diagnostics are always
printed even with a delay.
changelog_begin
changelog_end
* Remove mkOptions and defaultOptionsIO
`mkOptions` is a terrible API and this PR burns it with lots of 🔥.
The only thing that I didn’t simply move around is the validation
logic in `mkOptions` which validates that some directories
exist. Given that I’ve never actually see this be useful and the
options to set these directories (package dbs, import paths) are
internal I don’t think we actually gain anything from this.
I’ve also killed defaultOptionsIO which was a very confusing wrapper
around `mkOptions` that in addition to calling `mkOptions` also
enabled DLint. This was only used in tests, so I’ve enabled DLint in
the tests that need this.
changelog_begin
changelog_end
* newtype version header
* Generate mod refs at the same time as conversion
* Small change
changelog_begin
changelog_end
* lint
* Get rid of secondM
* Switch to Writer.CPS
* doc typo
* Added a partition function to prelude.
* Fixed partition function documentation.
* CHANGELOG_BEGIN
- Added `partition` function to prelude.
CHANGELOG_END
* Fixed partition documentation.
`initPackageDb` assumes that `Options` has not yet been initialized
and calls `mkOptions` itself. Each call to `mkOptions` appends the LF
version to the package db dir which means that calling it twice as we
did in `execIde` results in pkg dbs of the form dir/1.7/1.7 which is
obviously not what we want.
This is just the fix, I’m sufficiently annoyed by this now, that I’ll
spend some time tomorrow to kill mkOptions completely but for now this
at least fixes the SDK on master.
The reason why we didn’t catch this in our tests is that the package
dbs are located slightly differently via Bazel runfiles as they are
located in the final release tarball which ended up not breaking this
in our LSP tests.
changelog_begin
changelog_end
Unfortunately, downgrading `scalafmt` resulted in files that would be
reformatted to invalid code, because lines would be merged but trailing
commas would be left in.
I've manually run it everywhere and fixed these issues so people don't
have to fix them as they go.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
* Refactor modrefs out as a type.
This is in preparation for moving to a monadic style.
changelog_begin
changelog_end
* Update compiler/damlc/daml-compiler/src/DA/Daml/Compiler/DataDependencies.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Currently, the DAML language server use for DAML Studio crashes when the
`build-options` section of `daml.yaml` contains flags like `--package`.
This PR fixes this issue by allowing most of the flags for `damlc build`
for `damlc ide` as well.
CHANGELOG_BEGIN
- [DAML Studio] Allow all command line flags for ``daml build`` for
DAML Studio as well.
CHANGELOG_END
* Bazel test for trigger scenario
* daml-triggers: Allow testing trigger rules in scenarios
CHANGELOG_BEGIN
- [DAML Triggers - Experimental] DAML triggers can now be tested in
scenarios. Specifically, a trigger's ``rule`` can be executed in a
scenario and assertions performed on the emitted commands.
CHANGELOG_END
* Allow assertions on create commands
CHANGELOG_BEGIN
* [DAML stdlib] Add `CanAbort` instance for `Either Text`.
CHANGELOG_END
* Add convenience to construct ACS for testRule
* Add assertions for exercise and exerciseByKey
* fix assert message
* Test assertExercise(ByKey)Cmd
* unpackCommands --> flattenCommands
* Add API documentation
* Document that command ids start from "0"
* generalise command assertions to CanAbortm
* export ACSBuilder type
* Better haddocs for trigger command assertions
* explicit let
* ./fmt.sh
* Fix runfiles on Windows
* Add reference to Bazel issue
Co-authored-by: Andreas Herrmann <andreash87@gmx.ch>
fixes#3436
changelog_begin
- [DAML Compiler] ``damlc test`` now initializes the packagedb automatically which
means that it will work on projects that declare custom
``dependencies`` in ``daml.yaml`` without having to call ``damlc
init`` first.
changelog_end
* Preserve class method names during LF conversion.
This PR changes the LF conversion to pick names for dictionary
fields that will be easier to reconstruct as typeclasses
later.
For superclasses this uses "s_1", "s_2", "s_3" and so on,
and for methods this uses "m_foo", "m_bar", "m_baz" and
so on. (Is this enough C++?)
In the future we might want to distinguish between methods
that are mandatory and methods that are optional ... but
I think this should be good enough for now.
This PR also adds a test.
Fixes#4216
changelog_begin
changelog_end
* lint
* Run test in LF 1.7 as well
* Add test for superclass field.
They have been migrated to `ghcide` in
https://github.com/digital-asset/ghcide/pull/388 which is a much more
sensible place for them to live given that the code is in that repo.
changelog_begin
changelog_end
* Fail when a data-dependency fails to compile
Previously, we emitted errors but just kept on going which sometimes
kinda works but is certainly not the right thing to do.
Now we just crash and abort compilation.
changelog_begin
changelog_end
* why is windows
* undo crap
This fixes#4114 and cleans up the situation around
`data-dependencies` and `dependencies` as described in #4218.
There is still more work to be done here mostly around ironing out all
the edge cases and producing useful error messages instead of
silentely doing the wrong thing but I’ll leave that to a separate PR.
To test this, I’ve fixed the packaging tests to no longer deduplicate
package ids (which means they would return the wrong number if
daml-prim ends up in there twice) and I addded a test where we have 3
projects:
- `lib`
- `a` which depends on `lib`
- `b` which depends on `lib` via `dependencies` and 'a' via
`data-dependencies`.
changelog_begin
changelog_end
* Converting functions in data dependencies.
changelog_begin
changelog_end
* Add NoOverloadedStrings to the set of extensions in generated packages.
* Just use the fn as its own right hand side
* Restore order of package map (not that it makes a difference)
* Adjust imports
* Weird lint but ok
* Make the test pass somehow
* Dont preprocess enums in GHC.Prim
* Preprocess enums everywhere, and add mod ref as needed.
* Revert preprocessor changes
* Dont expose old-style typeclasses
* Dont convert newstyle typeclasses temporarily either
* Add test for function importing
* Support DAML-LF type synonyms in scala.
CHANGELOG_BEGIN
CHANGELOG_END
* dont create synonymns in GenerateSimpleDalf
* extend DAML-LF parser to support type synonyms
* test: expand type synonyms correctly
changelog_begin
- [DAML Compiler] Choices marked explicitly as `preconsuming` are now equivalent to a non-consuming choice that calles `archive self` at the beginning.
changelog_end
Co-authored-by: Shayne Fletcher <shayne.fletcher@digitalasset.com>
* Remove damlc.jar
We never advertised or published this externally and our only internal
user has moved off this months ago already.
changelog_begin
changelog_end
* Remove dependency from navigator test lib on damlc jar
This makes me a :sadpanda: but until we have figured out what is going
on, this seems better than forcing manual restarts.
changelog_begin
changelog_end
* Handle unserializable scenario result types
Previously, the conversions made some attempt at guarding against this
by matching on SPap and PClosure. While it would be possible to extend
this to match on STypeRep, this doesn’t actually fix the issue since
this can be nested, e.g., you can have a record with a field that is
an SPAP.
This PR changes this to simply catch any errors thrown from
`toValue`. While this feels a bit ugly, I think it’s a reasonable fix
for now.
changelog_begin
- [DAML Studio] Scenarios with unserializable result types no longer
crash the scenario service.
changelog_end
* Only run test on DAML-LF >= 1.7
* Remove intermediate PackageImport type
We can just reuse GHC’s PackageFlag directly which simplifies things a
bit.
changelog_begin
changelog_end
* windows is bad
* meh
* foobar
* why
To differentiate between "data X = X" which is translated to a DAML-LF
enum and "data X = X {}" which is translated to a DAML-LF record, we
add a datatype context with GHC.Types.DamlEnum. For
`data-dependencies` this needs to point to Currentsdk.GHC.Types.
changelog_begin
changelog_end
* Use GHC’s syntax for the --package flag
The previous syntax was just based on the Read instance of a 3-tuple
which was pretty much unusable. This changes it to GHC’s much nicer
syntax.
I deliberately did not add a changelog entry for this, since this
flag isn’t something that we have documented at all and it is
currently only useful in combination with data-dependencies.
fixes#4126
changelog_begin
changelog_end
* Fix hlint
* get it to compile 😇
* shut up hlint
* Remove the key field from pkg.conf files
We never use this and it only a legacy field that is deprecated in
favor of id in GHC.
There is also a minor change in the docs around ExposePackage which
should at most affect error messages.
changelog_begin
changelog_end
* Better error messages
The packaging tests have grown a fair bit recently and seem to hit
timeouts sometimes. We might want to split it up into multiple tests
suites but for now this should help.
changelog_begin
changelog_end
The current code has gotten out of sync with the changes to template
desugaring and is therefore simply broken. In addition to that, we
don’t need this once we can use typeclass instances in combination
with data dependencies.
Initially, we just disabled this instead of removing it since we
thought it might still be useful for older packages before typeclasses
are desugared to type synonyms. But we already have one way of
handling those as evidenced in the tests for the DAVL and once we can
call functions from older packages (which works regardless of whether
they have been built before or after the changes to how typeclasses
are desugared), we have another one so I don’t think it makes any
sense to keep this code around.
changelog_begin
changelog_end
* Refactor damldocs
* Refactor damldocs.
changelog_begin
changelog_end
* More refactoring
* Update copyright headers.
* Add export list for Templates
* Add export list to .Util
* added a little ^
* Test data-dependencies for more LF version combinations
This PR extends the cross-LF version tests to run for all
combinations where depLfVer >= targetLfVer.
changelog_begin
changelog_end
* Fix comments and add TODO
This PR fixes a minor issue where we were including more references
than we need which causes problems on older SDKs where GHC.Prim is not
a stable module since GHC.Prim cannot be imported (it’s builtin GHC
magic).
More importantly, this PR adds a test for cross-SDK data-dependencies
against the DAVL DAR which is built with SDK 0.13.32 before we started
making all the changes. The test also includes a slightly hacky but
mostly reasonable way of actually using the templates instead of just
the data types from the DAVL DAR which and a scenario to test this.
changelog_begin
changelog_end
This fixes the ZIP modification times in all DARs to a specific
value (1980-01-01) whereas they used the current time before. This
both gives us the nice property that not only our DALF builds but also
DAR builds should be deterministic (and there is a test for this). I
have a suspicion that this could help significantly with build times
and avoid rerunning half of the Scala tests on a change to damlc that
should not change the DALFs.
changelog_begin
- [DAML Compiler] The modification times in a DAR are now fixed to a
given value which makes the output of ``daml build`` deterministic
in single-threaded mode (which is the default).
changelog_end
This PR fixes a whole bunch of bugs when using data-dependencies on a
package produced by damlc rather than the handcrafted simple-dalf.
The end result is that we are able to build a package with
`--target=1.6` and use it as a data-dependency from a package with
`-target=1.7`. While the test that I’ve added for this is not
cross-SDK it is arguably even trickier since we cannot rely on the
unit id of daml-stdlib changing the version in the unit id.
The changes all fall into one of the following two categories:
- Special handling for daml-prim and daml-stdlib to avoid collisions
with the one from the current SDK.
- Special treatment of stable packages to avoid generating new code
for those.
- Remove a couple of filters for daml-prim since we do need to include
daml-prim from a data-dependency if it is a different version.
This is definitely not perfect and there are a bunch of rather hacky
parts in here but it seems like a good intermediate step (and it has a
test :))
changelog_begin
changelog_end
This was accidentally set to 1.7 before for no reason. Note that this
simply meant that we did not use the stable module when compiling with
--target=1.6 since we filter out newer stable packages.
Nevertheless, I’ve also added a test that verifies that we do not
accidentally introduce dependencies on packages in newer LF versions.
changelog_begin
changelog_end
* Try to improve the docs on DA.Internal.Template.Functions a little.
* More docs.
changelog_begin
- [DAML Standard Library] The ``Template``, ``Choice``, and
``TemplateKey`` typeclasses have been split up into many small typeclasses
to improve forward compatibility of DAML models. ``Template``,
``Choice`` and ``TemplateKey`` constraints can still be used as before.
changelog_end
* Example typo
* Bump ghcide to include bugfix
This includes a fix for a bug in completions which we introduced in
the latest ghcide bump which in turn broke the DAML IDE completely.
changelog_begin
- [DAML Studio] Fix a bug in completions that caused DAML Studio to
stop responding after the first completion was requested.
changelog_end
* Use ghcide from master branch and simplify test
* Patterns and test for new desugaring
* working on new template conversion
* Update ghc-lib
changelog_begin
changelog_end
* shut up hlint
* Update desugar stdlib
* update test
* remove unuseful templatebinds
* Add implicit qualified GHC.Types import
* Add missing primitives
* Remove chaff
* update comments
* Remove patterns that dont seem useful anymore
* Capture key data in template binds
* Dont make TypeRep/ToAny/FromAny classes conditional
* Remove some unnecessary TODOs
* Generate the template definition
* Remove new template desugaring test
* Fix jq query
* Rename makeDesugarDFunProjection to useSingleMethodDict
* Let TTypeRep and TAny be TUnit in primitives.
* Fix damlc visual wrt the new desugaring
* Fix visualization tests in shake test suite
* Fix damldocs
* Drop envTemplateKeyData
* Use the new ghc-lib release
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Allow invoking generate-src on the main dalf of a dar
Given that daml build outputs a .dar file this is much more convenient
for testing against actual build outputs of damlc rather than
handcrafted .dalf files.
The behavior matches the one of `damlc inspect` in that it detects
whether it works on a .dar or a .dalf based on the file ending.
changelog_begin
changelog_end
* Update compiler/damlc/lib/DA/Cli/Damlc.hs
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
The generation of Template instances will break horribly with
https://github.com/digital-asset/daml/pull/4030 and we don’t actually
want to use this anymore since we want to reuse old class
instances. There are some cases where we might still need or want this
in the future (see the inline comment), so for now, the code for this is still left intact and
only disabled.
changelog_begin
changelog_end
This PR adds a bunch of top-level helpers that take care of building
up the GHC AST.
I’ve also briefly played around with not using the GHC AST at all but
that doesn’t seem to really help simplify things so for now, I think
this is the better approach
changelog_begin
changelog_end
Previously, we exposed those functions from Prelude which really
doesn’t make any sense given that they are intended for the internal
implementation of daml-prim and daml-stdlib.
changelog_begin
changelog_end
* Respect build-options if project-root is used
changelog_begin
- [DAML Compiler] The ``build-options`` field from ``daml.yaml`` is
now also respected if ``--project-root`` is used.
changelog_end
* address review comments
* CHANGELOG_BEGIN
Type-check type synonyms.
CHANGELOG_END
* placate HLint
* comments
* Add an example that requires the check in kindOf
* check types containing syn-apps are well formed even when there is no expression of that type
* show type mismatch error after synonyms are expanded
* typeOf calls expandTypeSynonyms; track vars bound by TForall during expansion
* test interaction of syn-expansion and free-vars; add one bigger testcase
* extend bigger example with pointed typeclass, having functor as a super class
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Send session ping telemetry messages
This PR adds telemetry information that is sent regularly (every 5
minutes) while users are active (they’ve opened, closed or changed a
file). This allows us to track how long user sessions are.
This PR does not include any additional information in the session
ping but we plan to add more in the future.
The ping messages can be found in big query by filtering for
`jsonPayload.type = "session_ping"`.
CHANGELOG_BEGIN
CHANGELOG_END
* add copyright header
As mentioned in the comment, it doesn’t really make sense to include
the SDK version in the DALF names but I’ll address this in a separate
PR.
CHANGELOG_BEGIN
CHANGELOG_END
* Add regression test for unstable serializable types
This test verifies that we only have the serializable types in
daml-prim and daml-stdlib that we expect and don’t introduce new ones
by accident.
CHANGELOG_BEGIN
CHANGELOG_END
* Fix windows
* Ignore whitespace because windows
* optional is dead
All references to Optional are already mapped to the builtin Optional
type in LF but we forgot to filter out the type definition.
CHANGELOG_BEGIN
CHANGELOG_END
* Move most of the remaining serializable types to stable LF packages
The only serializable types left in DAML stdlib after this PR are the
following:
- DA.Upgrade:MetaEquiv
- DA.Random:Minstd
- DA.Next.Set:Set
- DA.Next.Map:Map
- DA.Generics:MetaSel0
- DA.Generics:MetaData0
- DA.Generics:DecidedStrictness
- DA.Generics:SourceStrictness
- DA.Generics:SourceUnpackedness
- DA.Generics:Associativity
- DA.Generics:Infix0
- DA.Generics:Fixity
- DA.Generics:K1
- DA.Generics:Par1
- DA.Generics:U1
- DA.Internal.Prelude:Optional
Ignoring the Generics stuff which isn’t very urgent imho and the
Upgrade stuff which is probably going to change significantly anyway,
this leaves us with the weird Random module, the wrappers around
TextMap which will go away anyway and DA.Internal.Prelude:Optional
which shouldn’t exist in the first place (I’ll address that in a
separate PR).
CHANGELOG_BEGIN
- [DAML Compiler] Move more types from daml-stdlib to standalone LF
packages. The module names for the types have also changed
slightly. This only matters over the Ledger API when you specify the
module name explicitly. In DAML you should continue to use the
existing module names.
- The types from ``DA.Semigroup` are now in a separate package under
``DA.Semigroup.Types``
- The types from ``DA.Monoid` are now in a separate package under
``DA.Monoid.Types``
- The types from ``DA.Time` are now in a separate package under
``DA.Time.Types``
- The types from ``DA.Validation` are now in a separate package
under ``DA.Validation.Types``
- The types from ``DA.Logic` are now in a separate package under
``DA.Logic.Types``
- The types from `DA.Date` are now in a separate package under
`DA.Date.Types`.
- The `Down` type from `DA.Internal.Prelude` is now in a separate
package under `DA.Internal.Down`.
CHANGELOG_end
* Fix serializability of RelTime
* fix daml-docs
* Fix tests
I managed to break our Windows CI twice already due to this so while
it makes me sad, I think hardcoding those files is the more sensible
option for now.
* Move Any wrappers and Archive to stable packages
There are no actual API or functionality changes in this PR but the
logic for locating the stable packages has slightly changed since the
Any wrappers package only makes sense for LF 1.7. To address this, we
simply filter out stable packages for newer LF versions since it
doesn’t make sense to depend on those anyway.
CHANGELOG_BEGIN
- [DAML Compiler] Move ``Archive`` type to a separate DALF.
CHANGELOG_END
* More comments
* Fix java codegen tests
* fix more tests
* Force cache reset on Windows
* Revert "Force cache reset on Windows"
This reverts commit 9f2b7d70b2.
* Fix roundCommercial
fixes#3884
Previously, we relieid on being able to convert to an Int, which
doesn’t work since there are Numeric values that cannot be represented
as an Int. Now, we avoid any conversions to Int which fixes this
issue.
We probably just want to have a primitive for this at some point but
given that this will only be available in newer LF versions, I think
it’s worth working around this for now.
* Move tests to a separate file to exclude LF 1.6
* Update compiler/damlc/daml-stdlib-src/DA/Internal/Prelude.daml
Co-Authored-By: Remy <remy.haemmerle@daml.com>
* Apply suggestions from code review
Co-Authored-By: Remy <remy.haemmerle@daml.com>
* Update comments
* Update compiler/damlc/daml-stdlib-src/DA/Internal/Prelude.daml
Co-Authored-By: Remy <remy.haemmerle@daml.com>
* Move stable types from DA.Internal.Template to a separate module
This is in preparation for splitting them into a separate LF package
with a stable package id.
* Fix visualization
* Fix data dependencies
Originally, this made sense as a flag in Options since we read it
during typechecking to write out interfaces on the fly. But now, we
write this is only used in execCompile so having this be a global
option that is ignored anywhere but in `compile` is rather confusing.
This documents some of the edge cases in the packaging code that I’ve
had trouble understanding so that the next person hopefully has an
easier time with this.
There is also some minor cleanup in this PR.
* Add Eq instances for AnyTemplate, AnyChoice and AnyContractKey
CHANGELOG_BEGIN
- [DAML Standard Library] Add ``Eq`` instances for ``AnyTemplate``, ``AnyChoice`` and ``AnyContractKey``.
CHANGELOG_END
* Add DAML_ANY_TYPE to the CPP guard
