* REPL: Factor out Dar loading
* REPL accept multiple DARs
* REPL CLI take multiple packages
CHANGELOG_BEGIN
- [DAML REPL] The REPL now supports loading multiple DARs specified at
the command line. The DARs are loaded as data-dependencies, and the
modules of each DAR's main DALF will be imported into the REPL session
at startup.
CHANGELOG_END
* REPL test loading multiple DARs
* REPL Load packages from current session
* REPL func-test test symbols from two DARs
* Update compiler/damlc/daml-compiler/src/DA/Daml/Compiler/Repl.hs
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Revert ANF changes and add a testcase for evaluation order
After careful consideration, we decided that the change in evaluation
order that was accidentally introduced by the ANF changes should be
considered a breaking change or arguably even a bug and should not
land in 1.3.0.
Therefore, this PR reverts the following commits:
1. 353d0da6f7
2. a45b51042f
3. 04c7b2af7f
4. a624dd7242
5. b3aab72cee
Other PRs mostly had trivial merge conflicts that I resolved. The two
most interesting ones here are probably
1. https://github.com/digital-asset/daml/pull/6576 which was easy to
resolve and the change to return SEValue instead of SExpr is still
nice and useful even if we do not need the guarantees.
2. it https://github.com/digital-asset/daml/pull/6542 which required
some changes since the constructors changed. If you want to review
those changes in detail (they are pretty straightforward so not too
important), it’s probably easiest to check out this PR and run
```
git diff 2cd2a8f2a8
daml-lf/interpreter/src/main/scala/com/digitalasset/daml/lf/speedy/Compiler.scala
```
to see the diff to the parent commit of the first commit that
introduced ANF.
changelog_begin
changelog_end
* Update rules_haskell
- Fixes the issue where a `sh_test` wrapping a `haskell_binary` couldn't
add runfiles as is the case with other Bazel rules.
CHANGELOG_BEGIN
CHANGELOG_END
* Save the runfiles environment at start-up
To work around the fact that `withProgName` overwrites `argv[0]`.
See https://gitlab.haskell.org/ghc/ghc/-/issues/18418.
* damlc_compile_test include damlc runfiles
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
Buildifier now comes with a handy attachment to catch single `\`
characters inside strings and replace them with `\\` if the escape
sequence is invalid. Skylark/Python will do this at runtime anyway; this
just makes it clearer what the actual behavior is.
I needed to change `\` characters at the end of lines to `\\` manually
in order to stop Buildifier from simply concatenating the lines
together. Everything else was automatic.
CHANGELOG_BEGIN
CHANGELOG_END
* Fix record update evaluation order.
This PR only fixes the evaluation order for single-constructor record
types. Fixing it for variant records, if we do, will be a major
challenge.
This PR also adds a regression test.
changelog_begin
changelog_end
* fix daml-lf-verify
As requested by @shaul-da, this PR hides the information added by
@hurryabit in #6571 behind a checkbox, and reverts to plain "X"s by
default (checkbox unchecked).
CHANGELOG_BEGIN
- [DAML Studio] The new S/O/W/D information is hidden behind a top-level
checkbox (next to Show archived). When that checkbox is not checked
(which is the default), we display X's as before.
CHANGELOG_END
'.' is not a valid character in a mangled name which caused unmangling
to fail. Sadly the scenario service does not properly distinguish
between dotted an undotted names but for now everything we unmangle is
dotted anyway so I’ve taken the easy approach of simply changing our
unmangling to take that into account.
We might want to change the scenario service here but I’ll leave that
for a separate PR.
changelog_begin
- [DAML Studio] Fix a crash in scenarios that referenced records
originating from definitions like `data T = T1 { f1 : Int } | T2 { f2
: Int }`.
changelog_end
Currently, the scenario service ships the disclosure information of a
transaction twice. One of the two copies is completely unused. This PR
simply deletes it. I hope this reduces confusion in the future.
CHANGELOG_BEGIN
CHANGELOG_END
* Split damlc integration tests per DAML-LF version
Currently, we have one test for all stable DAML-LF versions. This test
takes quite a while to run and times out occasionally. This PR splits
the big test into one test per stable DAML-LF version.
CHANGELOG_BEGIN
CHANGELOG_END
* Address some feedback
* Distinguish witnesses and divulgences in scenario table view
Currently, we display a "D" (for "Disclosure/Divulgence") in the table
view of the scenario view when a party can see a contract because they
have learnt about it via disclosure.
This change further refines this visibily indicators for disclosure:
We display a "W" for "Witness" (i.e. the party has witnessed the
creation of the contract) and "D" for "Divulgence".
Help for the reviewer: In the scenario service server, witnessing is
called explicit disclosure whereas divulgence is called implicit
disclosure.
CHANGELOG_BEGIN
* [DAML Studio]
When displaying scenario results in table view in DAML Studio, we now
indicate _why_ a party knows about the existence of a contract:
- `S` means the party is a signatory.
- `O` means the party is an observer.
- `W` means the party has witnessed the creation of the contract.
- `D` means the party has learned about the contract via divulgence.
CHANGELOG_END
* Address @cocreature's feedback
The whole instPrSelf thing is just repeating what DecodeAsDependency
does. Handling unqualified TypeConNames also sounds very questionable
so I changed that as well. Sadly this doesn’t fix the issue I was
hoping to fix.
changelog_begin
changelog_end
Implementing substitution once is scary enough, let’s not implement it
twice.
Sadly this is also does not fix the bug I was hoping to address.
I would not be surprised if it does fix some bugs but given that I
don’t know which there is no new testcase.
changelog_begin
changelog_end
* Fix haddock typo
* Daml REPL - use data dependencies
Without this a DAR that has a transitive dependency on another DAR
cannot be loaded into the REPL since the interfaces are missing, with
data-dependencies they are reconstructed.
CHANGELOG_BEGIN
- [DAML REPL] The provided DAR is now loaded as a data-dependencies,
meaning that the REPL supports loading DARs with transitive
dependencies.
CHANGELOG_END
* REPL test - use indirect DAR dependency
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* ANF transformation in Speedy.
The idea behind this PR is to transform speedy expressions into a simpler form where all non-atomic sub-expressions are made explicit by the introduction of let-forms. In particular, for the function-application form. These simpler forms allow the execution engine to take advantage of the atomic assumption, and often removes many additional execution steps. In particular the pushing of continuations to allow execution to continue after a compound expression has been reduced to a value.
changelog_begin
changelog_end
* improve comment
* inline functions relocateA/L
* remove comment about scalafmt
* remove commented out alterative def for transformLet1
* improve code by adding incr methods to DepthA/E
* remove (n == 0) special case in trackBindings
* clarify comment further
* improve validate/go to not consume stack for deeply right-nested let-expressions
* address comments from Remy: be private; use final case case; etc
* rename to unsafeCompilationPipeline
* add back some trailing commas
* remove commented-out debug line
* improve comment
* remove dev/debug code in compilationPipeline
* remove commented out code in SEAppGeneral.execute
* undo unrelated code improvement in SValue.scala
* fix compile. object Anf cannot be private
Verification tool update:
- Support for recursion and mutual recursion.
- Significant code cleanup and bugfixes.
- Minor improvements: keep track of more typing information, handle updates properly when called multiple times, support additional operators, more test cases etc.
For `damlc test` and `damlc ide`, `optScenarioService` is (correctly)
enabled. However, every call to `withDamlIdeState` will spawn a
scenario service. This means that during package initialization we
will spawn at least one extra scenario service (potentially) more. On
a simple project this gets `damlc test` from 10s down to 7s and I see
a noticeable (although hard to measure) speedup in IDE startup time.
changelog_begin
changelog_end
Returning the original relative path from withProjectRoot makes no
sense since we change the directory in there so this PR fixes this to
return the canonicalized project root.
fixes#6245
changelog_begin
- [DAML Compiler] damlc test --project-root now works with relative
paths as well.
changelog_end
* add simplifier tests
* add some lambda constant lifting tests
changelog_begin
changelog_end
* update copyright
* clarify that the subexpression is a lambda
* Explicit export list in tests module
* don't use lambda in test names :-(
* DAML REPL --static-time regression test
* damlc repl --static-time|--wall-clock-time flags
CHANGELOG_BEGIN
- [DAML REPL] The time mode can now be specified using the
``--static-time`` and ``--wall-clock-time`` flags.
CHANGELOG_END
* Update compiler/damlc/lib/DA/Cli/Damlc.hs
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Verify the effect of setTime using getTime
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Display why a party knows about a contract in table view
When displaying scenario results in table view in DAML Studio, we now
indicate _why_ a party knows about the existence of a contract:
- `S` means the party is a signatory.
- `O` means the party is an observer.
- `D` means the party has learned about the contract via disclosure or
divulgence.
With the information we get from the scenario service there is no
straightforward way of distinguishing between disclosed (you
witnessed the `create`) and divulged (you witnessed a `fetch`)
contracts. Fortunately, both words start with a "D" and we're fine. :)
This addresses the first point of
https://github.com/digital-asset/daml/issues/6412 for the table view.
CHANGELOG_BEGIN
* [DAML Studio]
When displaying scenario results in table view in DAML Studio, we now
indicate _why_ a party knows about the existence of a contract:
- `S` means the party is a signatory.
- `O` means the party is an observer.
- `D` means the party has learned about the contract via disclosure or
divulgence.
CHANGELOG_END
* Add tooltips
CHANGELOG_BEGIN
CHANGELOG_END
* Add test
CHANGELOG_BEGIN
CHANGELOG_END
* Remove tooltip for invisible contracts
CHANGELOG_BEGIN
CHANGELOG_END
* Move parties to then end
CHANGELOG_BEGIN
CHANGELOG_END
* Support multiple auth tokens in DAML Script
This piggy backs on top of the already existing --participant-config
feature. While you can argue that it might be slightly confusing that
you have to specify the same participant twice to specify different
auth tokens, I think this actually makes sense: In an ideal
world (ignoring any performance issues) you have one participant per
party anyway and one connection per participant specified in the
config file still seems like a very reasonable model.
changelog_begin
- [DAML Script] You can now use DAML Script with multiple auth
tokens. This is particularly useful if you are working with the JSON
API where you can only have one party per token or with an IAM that
only provides single-party tokens. The tokens are specified in the
participant configuration passed via `--participant-config` in a new
``access_token`` field. The existing `--acess-token-file` flag is still supported if you want to use the same token for all connections. See
https://docs.daml.com/daml-script/index.html#running-daml-script-against-authenticated-ledgers
for more details.
changelog_end
* I will never understand rst
changelog_begin
changelog_end
* Prefix IDE include paths with project root
As described in #6174, `--include` is broken pretty badly in the IDE
atm. LSP works based on absolute file paths so if you have a relative
include dir you run into two issues:
1. You end up with two GHC sessions e.g, one for `/multidir` and one
for `.`. That results in fun type errors like “Couldn’t match expected
type `Text` with actual type `Text`”.
2. The same file can end up being represented twice. Apart from being
horribly inefficient, this breaks as soon as we try to build a DALF
since the function for constructing that (correctly) explodes when
there are two files with the same module name.
This change does not break `daml build` since the project root is
relative there.
fixes#6174
changelog_begin
- [DAML Studio] Fix an issue where use of the `--include` option
resulted in various confusing type errors. See
https://github.com/digital-asset/daml/issues/6174
changelog_end
* Stop wasting my time hlint
changelog_begin
changelog_end
* Consistently display stakeholders for key visibility errors
fixes#6404
As pointed out by Bernhard in #6404, the previous behavior was pretty
weird. If the committer was only a divulgee, we only displayed
stakeholders. If the committer was neither a stakeholder nor a
divulgee, we displayed stakeholders + parties the contract has been
divulged to. Given that only stakeholders can do lookups it makes much
more sense to display them consistently which is what this PR
achieves. I’ve also renamed “disclosed to” to “stakeholders” to make
it very explicit what is shown there.
changelog_begin
changelog_end
* Apply suggestions from code review
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* fmt
changelog_begin
changelog_end
* lalala
changelog_begin
changelog_end
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
fixes#6403
I am not entirely sure why I thought that using `missingWith` makes
sense here but it clearly doesn’t make sense and resulted in a pretty
bad bug where a transaction both succeeded via `submit` as well as
failed via `submitMustFail` which is clearly the wrong thing to do.
This PR fixes this issue and introduces a `notVisibleWith` function
that does the right thing. I’ve also added some comments and an extra
assertion to clarify things a bit.
changelog_begin
changelog_end
* support external anchors
changelog_begin
- `daml docs` now supports an `--input-anchor` argument specifying the
path to a database of external anchors
changelog_end
* Add daml-base-anchors.json to the damlc-dist target
* First draft of constant lifting
changelog_begin
changelog_end
* refactoring
* doing stuff
* run simplifier on template exprs
* remove merge artifact
* Fix ExerciseWithoutActors
* add comments
* fix trace order test
* prefix generated val names with their provenance
* Verification tool bugfix
During the value collection phase, when encountering a record projection on a (yet) undefined value, stop searching this branch instead of throwing an error.
* Bump pattern-match-perf memory limit with cocreature`s blessing
* bump again
* Filter generated identifiers from daml script test runner
changelog_begin
changelog_end
* Fix party literals
* Remove inlineClosedExpr for now.
* Improve comments
* Reset script test locations
* Unhashmap
* disable daml-lf-verify quickstart tests for now
Co-authored-by: Gert-Jan Bottu <gertjan.bottu@kuleuven.be>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
This integrates the time service into DAML script thereby covering the
main piece of scenarios that was missing from DAML script.
This PR does two things (they are very related and doing them together
makes it much easier to test):
1. It “fixes” `getTime` to return the ledger time in static mode by
querying the ledger time service instead of defaulting to the Unix
epoch which is pretty useless and I would consider the old behavior
a bug. We keep the old behavior via the JSON API since there is no
time service.
2. It adds `setTime` to set the ledger time via the time service. This
is only supported in static time mode (sadbonx and other ledgers do
not expose the time service in wallclock mode because changing time
makes it not wallclock) or via the JSON API (no time service).
fixes#6220
changelog_begin
- [DAML Script] DAML Script’s `getTime` now correctly handles time
changes in static time mode and returns the current time by querying
the time service rather than defaulting to the Unix epoch. Note that
when run via the JSON API, it still returns the Unix epoch.
- [DAML Script] Add `setTime` to DAML Script which sets the ledger
time via the ledger API time service. Note that this is only
supported when running over gRPC in static time mode.
changelog_end
In this PR we cleanup the constructor for the speedy Machine.
* We remove the `case` keyword since `Machine` is a stateful class,
* We replace the pre-existing builders with
+ one generic builder `Machine.apply`,
+ scenario specific builder,
CHANGELOG_BEGIN
CHANGELOG_END
The upgrade to various nodejs libraries in
b03cf7b598
seems to have gotten in an inconsistent state (what even are version
boundaries). This PR updates vscode-languageclient to the latest
version which fixes the issue. Apparently that requires a newer
version of @types/vsode as well (even 6.0.x requires that) so I had to
bump that and the engine. This does mean that we now require vscode
1.39.0. Given that this version was released in September 2019 that
seems very reasonable.
changelog_begin
- [DAML Studio] DAML Studio now requires VSCode 1.39 or newer.
changelog_end
fixes#3150
This PR introduces a patch to GHC to fix the performance of the
pattern match checker in the presence of multiple packages which
is currently significantly (orders of magnitude) slower than having
everything in a single package. I also added a test case that hits
this. Here’s what you need to hit this issue:
1. A typeclass with a functional dependency. `HasField` is the obvious
candidate for this.
2. A lot of instances of this typeclass in a separate package (this is
the only part where the separate package matters).
3. A reasonably large ADT with a bunch of strict fields.
4. A pattern match in the context of some constraints of the
typeclass. The constraints can be completely unused.
In that case, you will get a significant slowdown in the number of
instances, number of constructors and number of constraints (didn’t
verify if it’s linear but it is significant which is all that
matters).
Here’s why this happens:
1. The pattern match checker checks for strict fields if the type is
inhabited.
2. This calls `pmTopNormaliseType_maybe` to normalize a type (the details don’t
matter) which in turn calls into the typechecker. This function is
called very often (presumably linear in the number of constructors
but didn’t verify.)
3. The typechecker has some logic in `improveFromInstEnv` for
generating additional equations by unifying functional
dependencies `a -> b` with constraints in scope
and thereby deducing information about `b`.
4. In the pattern match checker the list of instances of the home
package is empty since the pattern match checker (apparently)
doesn’t actually care about those extra equations. However, the
list of instances in the EPS is not empty. This is the issue here:
By moving it to an external package we suddenly end up with
thousands of instances that we try to unify with the functional
dependencies every time we normalize which happens very often.
Proposed fix:
The solution is rather simple: Since the pattern match checker
apparently does not care about the instances of the home package, it
almost certainly doesn’t care about instances in general so we just
empty the instances of external packages explicitly.
Is the fix correct?
1. I verified that the GHC test suite passes with this patch which
gives me a reasonable level of confidence.
2. I verified that our own test suite passes.
3. The most dodgy part is actually emptying the instance since the
whole EPS stuff is a mutable mess. What could in theory happen is that
the PM ends up loading an interface file that mutates this
again. However, afaiu it is impossible for the PM to need an
interface that the typechecker didnt already need. I did do a bunch
of debugging and this is exactly what I observed in my experiments.
Alternative ideas and upstreaming:
The other option would be to not try and mess with the EPS but somehow
have a conditional flag somewhere in the typechecker env to disable
this logic in the pattern match checker. However, that sounds
significantly more complex so I don’t think it’s worth the effort.
GHC 8.10 has a new pattern match checker that has different
performance characteristics and seems to do much better here so there
is little reason to try and upstream this. I strongly want to avoid
upgrading DAML to 8.10 at this point (too much risk, let’s wait until
things calm down)
changelog_begin
- [DAML Compiler] Fix an issue where compilation slowed down
significantly when code was split up into several packages. See
https://github.com/digital-asset/daml/issues/3150
changelog_end
Doctests generate a temporary file in .daml/generated. This works fine
as long as you only run one instance at the same time. However, those
tests here run in parallel and they run in the same working directory
even though we create a temporary directory for the source file. This
means that occasionally (very rarely, I still haven’t managed to
reproduce it locally) the two tests overwrote each other’s file and
you end up with a mess.
There are two solutions here:
1. Disable parallel tests.
2. Remove the working directory as global state and instead use tmpDir
as the working directory.
Nobody likes global state so I went with 2.
I ran 500 iterations of this test on CI on all 3 platforms and got not
a single failure so I’m reasonably confident this fixes the issue.
changelog_begin
changelog_end
* damlc: Run simplifier on templates as well
Currently, the simplifier only runs on top-level value definitions.
However, there's no good reason for not running it on all expressions
within templates as well.
This does not significantly improve the `CollectAuthority` benchmark,
but there's not much code in the templates.
CHANGELOG_BEGIN
CHANGELOG_END
* Verification tool bugfix in variable projection and substitution with… (#6344)
* Verification tool bugfix in variable projection and substitution within let expressions
* Remove redundant substitution ; apply feedback Martin
Co-authored-by: Gert-Jan Bottu <gertjanbottu@hotmail.com>
* update various lock files
CHANGELOG_BEGIN
CHANGELOG_END
Signed-off-by: Brian Healey <brian.healey@digitalasset.com>
* further version upticks from yarn upgrade
* Add option based constructor for LedgerIdRequirement
changelog_begin
changelog_end
* Make option based consructor the default, deprecate old constructor
* Update with review comments
* damlc inspect: Add output modes with less details
This PR adds two new detail levels to `damlc inspect`:
* `--detail=-1` omits all package ids from the pretty printed output.
* `--detail=-2` omits all package ids, type information and kind
annotations from the output.
We also slightly change the existing detail level `--detail=0`, which
is the default when the `--detail` flag is omitted, to make the output
more consistent:
* Kind annotations are no longer omitted when the kind is `*` (star).
* All location information is now omitted. To get location information,
use `--detail=1`.
This is part of https://github.com/digital-asset/daml/issues/5756.
CHANGELOG_BEGIN
CHANGELOG_END
* Improve explanatory comment
CHANGELOG_BEGIN
CHANGELOG_END
* damlc: Avoid immediately invoked closures
We add rules to the simplifier which rewrite expressions of the form
```
(\x1 ... xn -> E) A1 ... An
```
into
```
let x1 = A1 in ... let xn = An in E
```
provided that `xi` is not free in `Aj` for any `i < j`.
In cases where `E` is _not_ a lambda, this rewriting is beneficial
since it removes a costly closure allocation and the immediate entering
of the closure. If `E` is a closure itself, this rewriting is not
detrimental since the only difference it makes is that the values for
`A1, ..., An` end up in the list of captured variables rather than in
the list of already applied variables.
Even though users might not write expressions like the one we're
simplifying here themselves, various desugarings produce them
nevertheless. A common pattern is to define multiple auxiliary
functions that a only used once in a where cluase. For instance, with
the help these new rewriting rules the function
```haskell
f: Int -> Int -> Int
f x y = g (h x) y
where
g x y = x+y
h x = 2*x
```
gets translated to
```
def f : Int64 -> Int64 -> Int64 =
\(x : Int64) (y : Int64).
let x2 : Int64 =
let x2 : Int64 = x
in MUL_INT64 2 x2
y2 : Int64 = y
in ADD_INT64 x2 y2
```
Without the simplification, `g` and `h` would each allocate a closure:
```
def f : Int64 -> Int64 -> Int64 =
\(x : Int64) (y : Int64).
(\(x2 : Int64) (y2 : Int64). ADD_INT64 x2 y2)
((\(x2 : Int64). MUL_INT64 2 x2) x)
y
```
The `collect-authority` benchmarck is sped up by 1.03x by this change.
This is not a huge improvement but the change is simple enough to
merge it nevertheless.
CHANGELOG_BEGIN
CHANGELOG_END
* Let code speak not comments
CHANGELOG_BEGIN
CHANGELOG_END
* Improve explanations
CHANGELOG_BEGIN
CHANGELOG_END
Clean up the DAML-LF pretty printer used by `damlc inspect` (and
others).
Most of the changes are around using `pPrintPrec` or `pPrint` instead
of `pretty` and fixing some naming inconsistencies. In many places we
now use `pPrintPrec` because I'd like to support multiple levels of
details in a follow-up PR. This requires passing the `PrettyLevel` down
the AST.
We also remove 4 leading spaces from almost every line since they cost
precious screen space and don't add any value.
This is part of https://github.com/digital-asset/daml/issues/5756.
CHANGELOG_BEGIN
CHANGELOG_END
We split the object com.daml.lf.types.ledger in three:
- one part in `com.daml.lf.ledger.` (in //daml-lf/transaction) for the part relative to EventId (shares between scenario service and sandbox)
- one part in `com.daml.lf.ledger.` (in //daml-lf/interpreter) for the part common to Blinding and Scenario
- one part in `com.daml.lf.scenario.` (in //daml-lf/interpreter) for the part specific to Scenario
fixes#6260
CHANGELOG_BEGIN
CHANGELOG_END
This is just not general enough to be useful. In particular, it
completely falls apart for somethin like submit x (exercise …) in
scenarios.
changelog_begin
changelog_end
This rule is repeated for every file. While we cache the computation,
we still forced it to NF which is super slow. On my (realworld)
testcase, this is a speedup of > 1.7x, cuts allocations to 1/3 and max
residency also goes down to 1/3.
changelog_begin
changelog_end
* replace NodeExercises#controllers with controllersDifferFromActors
* remove controllers from ActorMismatch and scenario service exercise
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
* remove reserved ID #s in scenario-service grpc
As discussed, we don't need to worry about
version mismatches.
Co-authored-by: Remy <remy.haemmerle@daml.com>
Previously, we just crashed the scenario service instead of throwing a
proper scenario error. This meant that you had to look at the
debugging output to figure out what is going wrong. This is both a
shitty UX and also inconsistent with how we handle this for fetch and
exercise on contract ids that are not visible. This PR adds a new
error type that matches the one for invisible contract ids.
changelog_begin
- [DAML Studio] Fetches and exercises of contract keys associated with
contracts not visible to the submitter are now handled properly
instead of showing a low-level error.
changelog_end
fixes#5903
* Add a module-prefixes field to rename all modules in a pkg
This PR adds a `module-prefixes` field to `daml.yaml` a a shorthand
for specifying a `--package` flag that renames all modules in a
package to have the same prefix.
The docs are updated to describe how you can use this field and there
is a test case that makes sure it works.
fixes#4948
changelog_begin
- [DAML Compiler] You can now use the new ``module-prefixes`` field in
``daml.yaml`` to add a prefix to all modules from a dependency. This
is particularly useful for handling colliding module names during
upgrades. See
https://docs.daml.com/daml/reference/packages.html#handling-module-name-collisions
for more information.
changelog_end
* Update compiler/damlc/daml-opts/daml-opts-types/DA/Daml/Options/Packaging/Metadata.hs
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* Improve docs and fix broken suggestion
changelog_begin
changelog_end
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* Add JSON output to `damlc inspect-dar`
fixes#3117, fixes#5563
This PR adds a `--json` flag to `damlc inspect-dar` that does pretty
much what you expect. So far it mainly exposes the same information
that you already got from `inspect-dar` but it’s easy to add more as
needed.
I’ve also finally added some documentation for `inspect-dar`.
changelog_begin
- [DAML Compiler] ``damlc inspect-dar`` now has a `--json`` flag to
produce machine-readable output. See
https://docs.daml.com/daml/reference/packages.html#inspecting-dars
for more information.
changelog_end
* Sort packages in human-readable output
changelog_begin
changelog_end
* Update docs/source/daml/reference/packages.rst
Co-authored-by: Rohan Jacob-Rao <rohanjr@gmail.com>
Co-authored-by: Rohan Jacob-Rao <rohanjr@gmail.com>
Choices for `stacktracing` are `NoStackTrace` / `FullStackTrace`.
Adapt code so the selection is made by the original caller:
- `engine`
- `scenario-service`
- `repl-service`
- `daml-script` runner
etc
Currently, all callers pass `FullStackTrace` (the existing behaviour), except for the
exploration dev-code: `daml-lf/interpreter/perf/src/main/scala/com/daml/lf/explore`.
The idea is that once this control is in place, we can discuss if we can change how we
might expose it to the user, and/or perhaps change the default behaviour to have
`stacktracing` disabled.
changelog_begin
changelog_end
First version of static verification tool.
The current state of the tool:
- Reads DAR files.
- Partially evaluates the code.
- Generates constraints for the field and choice to be verified.
- Passes the constraints to an SMT solver.
- Some basic tests.
* REPL record dot syntax regression test
* REPL: Apply record preprocessor to expressions
CHANGELOG_BEGIN
- [DAML REPL] Record dot syntax is now handled in expressions entered
into the REPL.
CHANGELOG_END
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* Implement a simple profiler for DAML scenarios
The profiler runs a single scenario and records timing information when
each function (and some other closures) are entered and left. The
resulting information can be visualized as a flamegraph using
[speedscope](https://www.speedscope.app/).
The profiler works by instrumenting the CEK machine at the heart of
DAML Engine. Unfortunetaly, this causes a very small overhead on
non-profiling runs too. However, in my benchmarks I could not measure
any significant impact on the overall runtime at all. More precisely,
the overhead is as follows:
Every closure now has an additional field called `label`. In
non-profiling runs this field is always set to `null`. This field needs
to be allocated, copied whenever we copy a closure and scanned during
garbage collection. Additionally, whenever we enter a closure, we check
this field and whenever it is _not_ `null`, i.e. never during
non-profiling runs, we record an "open event" and set up a hook for the
corresponding "close event". Thus, the additional cost during
non-profiling runs are a single pointer comparison and a jump beyond
the "then branch".
Since this is still very much in active development, there are no
documentation, other than an entry in a README, and no tests yet. They
will come before we promote this. However, the UX will look very
different then since we already have plans to significantly change it.
CHANGELOG_BEGIN
CHANGELOG_END
* Run scalafmt
* Make profiling argument to PureCompiledPackges optional
* Fix a bunch of tests
CHANGELOG_BEGIN
CHANGELOG_END
* scalafmt is so annoying
CHANGELOG_BEGIN
CHANGELOG_END
* Apply simple suggestions
CHANGELOG_BEGIN
CHANGELOG_END
fixes#6005
Take a look at #6005 for details. I verified manually that things
still work as expected. It does require bumping the vscode version to
1.38 which was released almost a year ago so hopefully that should be
safe.
changelog_begin
changelog_end
Fixes#5592
The CLI syntax and the defaults follow the JSON API here.
changelog_begin
- [DAML Script] The maximum inbound message size can now be configured
using `--max-inbound-message-size``. This matches the flag in the JSON
API.
- [DAML REPL] The maximum inbound message size can now be configured
using `--max-inbound-message-size``. This matches the flag in the JSON API.
changelog_end
changelog_begin
dlint: Change references to replicateM to replicateA; remove some Haskell-based rules that do not currently apply in DAML.
changelog_end
* Inline typeclasses and apply projections.
This draft PR:
* adds a Subst module for substitution within LF expressions.
This implementation piggybacks on the existing type
substition. But there are not enough tests yet.
* passes World data into the simplifier, in order to have
have the ability to inline functions (selectively)
* inlines typeclass dictionaries and projection functions
* beta reduces type lambdas (which are just ignored by
speedy afaik)
* beta reduces lambdas that are passed units or dictionaries
* runs the simplifier twice so it has a change to
perform the inlining, reduction, AND projection
-- this is probably avoidable by sequencing the
simplifier steps in a specific order, but running
the simplifier twice is simple enough for now.
* together, these fix#5748 (see result on a toy module)
TODO:
* add lots of tests for Subst
* run this on a benchmark to see how big of a difference it makes.
* reduce the jankiness of running the simplifier twice.
Results:
DAML input:
```
module Main where
hello : Int
hello = 10 + 30
```
Original DAML-LF output:
```
module Main where
@location(7:0-7:5)
def hello : Int64 =
a284919a95c4a515cd1efac0d89be302d0e9d61e692a2176128c871ad8067e36:GHC.Num:+
@Int64
a284919a95c4a515cd1efac0d89be302d0e9d61e692a2176128c871ad8067e36:GHC.Num:$fAdditiveInt
10
30
```
Current DAML-LF output:
```
module Main where
@location(7:0-7:5)
def hello : Int64 = ADD_INT64 10 30
```
changelog_begin
changelog_end
* Update copyright header
* Lint
* More direct typeclass simplification
* extendWorldSelf + getTypeClassDictionary
* Fix visual
* Fix visual comment
* Disable cross-module inlining for incremental builds
* Cleanup subst/freevars.
* copyright header
* Alpha equivalence for LF expressions.
* copyright header
* lots of tests
* fix comment
* Apply review suggestions
Fixes#5786.
CHANGELOG_BEGIN
[DAML Standard Lib] ``DA.Text.splitOn`` will now correctly handle the
case where the separator appears at the end but should not be matched,
as in ``splitOn "aa" "aaa" == ["", "a"]`` (previously this was
erroneously returning ``["", "a", ""]``). See #5786 for more details.
CHANGELOG_END
* Simplify and clarify the public interface to Speedy.
- Remove `isFinal`. A client just uses `run()`.
- Remove `toSValue`. The value in available in `SResultFinalValue(v: SValue)`.
- A client never directly access the `.ctrl` (or `.returnValue`) components.
- A client may use `setExpressionToEvaluate(expr)` to evaluate a new expression on an existing machine.
changelog_begin
changelog_end
* remove while loop which executes just once
* avoid unnecessary mutation when running speedy
--project-root is a bit confusing when using the assistant since it
will choose the SDK version before going to the project
directory. This is almost never what you intend to do so setting
DAML_PROJECT seems like a better option in most cases.
See https://github.com/digital-asset/daml/issues/5769 for details
changelog_begin
changelog_end
* CHANGELOG_BEGIN
Added filterA to Prelude.
* Update compiler/damlc/daml-stdlib-src/DA/Internal/Prelude.daml
Co-authored-by: Shayne Fletcher <shayne@shaynefletcher.org>
* Removed not so useful comment.
* Moved filterA from Prelude to Action.
* filterA is a one-liner now.
* Provided more meaningful example to filterA.
* Added test for filterA.
* Removed failing doctest.
CHANGELOG_END
Co-authored-by: Shayne Fletcher <shayne@shaynefletcher.org>
* Fix handling of packages in damlc visual
Previously we just ran the analysis on the modules of the main
package. This failed for obvious reasons as soon as you reference a
template from another package which happens pretty
frequently (e.g. for anything that uses finlib).
This PR fixes this to run the analysis on the whole World which is
self-contained. This required a bunch of reshuffling to make sure that
we always reference fully qualified identifiers but most of it is
very mechanical.
Note that currently you cannot distinguish between templates with
identical names in the resulting graph (they will be separate but you
have no idea which one is which). This was already an issue
before if you have the same template name in different modules so I
consider this an orthogonal issue.
This fixes the expected failure we already had and I added another
test that checks that colliding template names do at least show up as
separate nodes in the graph. I also manually tested this against
ex-bond-issuance.
Disclaimier: I’m aware that the code is very messy but I tried to
resist the urge to rewrite it completely and only change what was
necessary.
fixes#5776
changelog_begin
- [DAML Compiler] ``damlc visual`` now works properly in projects
consisting of multiple packages.
changelog_end
* Rename templateChoiceId to templateId
changelog_begin
changelog_end
All functions in `DA.Numeric` take the scale of the result as their
first type argument. IMO, this is a nice API since you usually only
want to specify the scale of the result since the scale of the
term arguments is most of the times inferred.
However, the current type signatures in `DA.Numeric` bear quite some
risk of being confusing. For instance, in
```haskell
mul : NumericScale n3 => Numeric n1 -> Numeric n2 -> Numeric n3
```
the naming of the type variables suggests that the order of the
type parameters is `n1 n2 n3` when it actually is `n3 n1 n2`.
I consider the knowledge of implicit `forall`s are filled in quite
expert and hence think we should make the order of these type arguments
explicit.
There is also a related mistake in the docs of `shift`. Running a
scenario confirmed that
```haskell
shift @1 @2 1.0 == 10.0
```
Hence, `shift` has multiplied its argument by `10^(2-1)`, which is
`10^(n1 - n2)`.
CHANGELOG_BEGIN
CHANGELOG_END
This moves the code from the Shake testing module to a separate
module. This is required since the Shake test setup is not really
intended to test multiple packages. I’ve added a new test suite that
makes use of this and has an expected failure for the issue with
multiple packages. The issue is not actually fixed in this PR, I just
wanted to keep the refactoring separate since it is quite large and
noisy.
changelog_begin
changelog_end
* extend visual for exerciseByKey
Fair warning: I have no idea what I'm doing here. Please review
carefully.
This commit extends the `daml damlc visual` command to draw a line for
exerciseByKey choices. This fixes#5726.
I have not been able to find any existing test for the visualizer. If
non exist, I think we should at least turn #5726 into a test case,
checking that the expected dot file gets generated. I suggest doing that
as a separate PR though.
If there is already a suite of tests, please point me to it and I'll
happily add one for this.
CHANGELOG_BEGIN
[Visualization] Fix a bug where `exerciseByKey` was not properly
recognized. See #5726.
CHANGELOG_END
* add test
* Fix ./fmt.sh check
We accidentally introduced hlint lints when we added the compatibility
workspace. The hlint code in ./fmt.sh correctly detects that there is
a hint but then exits with 0 since it uses the exit code from `echo`
rather than the one from `hlint`. The info that we printed with
`echo` didn’t actually make any sense so I added a new comment as to
why we run hlint here. This requires some setup changes so that the
compatibility workspace gets the same Haskell flags since otherwise
using the same hlint rules obviously does not make sense.
Fixes#5701
changelog_begin
changelog_end
* Update fmt.sh
Co-Authored-By: Samir Talwar <samir.talwar@digitalasset.com>
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
* Fix all DAML hoogle links.
This PR changes how the hoogle database is rendered in damldocs, so it has access to the mapping of anchors to URLs that is produced during rendering of rst docs. This way these will not get out of sync.
I also added an --output-anchor option in preparation for fixing external/cross-package references.
changelog_begin
changelog_end
* Update settings.json
undo accidental vscode settings change.
* Update README.md
* One module per page in stdlib docs.
changelog_begin
- [DAML Docs] The standard library docs have been split up per module.
changelog_end
* Adjust stdlib annotations
* Update compiler/damlc/daml-stdlib-src/DA/Generics.daml
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update compiler/damlc/base-rst-index-template.rst
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Move to daml/stdlib
* Update daml-doc tests
* Remove the Module prefix in the index/toctree
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* DLint: Fix hint for nubBy
We don't have `nubBy` and `nub` but rather `dedupBy` and `dedup` in
DAML. Let's fix the hints accordingly.
CHANGELOG_BEGIN
CHANGELOG_END
* Acknowledge hint in test for dedupBy
CHANGELOG_BEGIN
CHANGELOG_END
This PR finally puts together the refactorings from the last two PRs:
1. We now write out a JSON file (because JSON seems like a reasonable
choice and it doesn’t really matter) containing the main unit ids
when setting up the package db.
2. When initializing the GHC session, we now simply read that file
instead of reading the daml.yaml again and parsing all
dependencies and data-dependencies again.
changelog_begin
changelog_end
This is another refactoring PR for createProjectPackageDb. There are
no actual changes but the `DependencyInfo` now includes the list of
main unit ids. This is not used in this PR but the plan is to start
emitting a file here containing those and then we only have to parse
that file instead of reading all DARs again just to figure out the
--package flags. (The reason why it needs to be written to a file
instead of simply returned is that this needs to work even with
--init-package-db=no which is going to become more important for
incremental package db initialization).
changelog_begin
changelog_end
* Upgrade rules_nodejs to version 1.6.0
closes#5367
This includes the fixes for the issues in jest that we’ve been seeing.
changelog_begin
changelog_end
* Fix eslint rules
* A bit of progress
* Try to add LinkablePackageInfo (doesn’t seem to work yet)
* Add rootDirs
* revert da_ts_library
* da_ts_library: add LinkablePackageInfo info
* Remove react hook workaround
Since rules_nodejs 1.6.0 this fails with the following error:
```
● Test suite failed to run
Configuration error:
Could not locate module react mapped as:
/.../execroot/com_github_digital_asset_daml/bazel-out/k8-opt/bin/language-support/ts/daml-react/test.sh.runfiles/com_github_digital_asset_daml/node_modules/react/umd/react.development.js.
Please check your configuration for these entries:
{
"moduleNameMapper": {
"/^react$/": "/.../execroot/com_github_digital_asset_daml/bazel-out/k8-opt/bin/language-support/ts/daml-react/test.sh.runfiles/com_github_digital_asset_daml/node_modules/react/umd/react.development.js"
},
"resolver": null
}
49 | // like a promis without being one.
50 | /* eslint-disable @typescript-eslint/no-floating-promises */
> 51 | var react_1 = __importStar(require("react"));
| ^
52 | var react_hooks_1 = require("@testing-library/react-hooks");
53 | var index_1 = __importStar(require("./index"));
54 | var events_1 = require("events");
at createNoMappedModuleFoundError (../../../../../../../../../../../node_modules/jest-resolve/build/index.js:501:17)
at Object.<anonymous> (index.test.js:51:28)
Test Suites: 1 failed, 1 total
Tests: 0 total
Snapshots: 0 total
Time: 1.88s
Ran all test suites within paths "language-support/ts/daml-react/DamlLedger.d.ts", "language-support/ts/daml-react/DamlLedger.js", "language-support/ts/daml-react/context.d.ts", "language-support/ts/daml-react/context.js", "language-support/ts/daml-react/hooks.d.ts", "language-support/ts/daml-react/hooks.js", "language-support/ts/daml-react/index.d.ts", "language-support/ts/daml-react/index.js", "language-support/ts/daml-react/index.test.d.ts", "language-support/ts/daml-react/index.test.js".
=
```
* rootDirs is not needed for tsc
This is only required for ts_project
* Update yarn Bazel packages
* docs/theme add missing dependencies
* Remove unused attribute module_root
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* 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
