* Send session ping telemetry messages
This PR adds telemetry information that is sent regularly (every 5
minutes) while users are active (they’ve opened, closed or changed a
file). This allows us to track how long user sessions are.
This PR does not include any additional information in the session
ping but we plan to add more in the future.
The ping messages can be found in big query by filtering for
`jsonPayload.type = "session_ping"`.
CHANGELOG_BEGIN
CHANGELOG_END
* add copyright header
* Move stable types from DA.Internal.Template to a separate module
This is in preparation for splitting them into a separate LF package
with a stable package id.
* Fix visualization
* Fix data dependencies
Originally, this made sense as a flag in Options since we read it
during typechecking to write out interfaces on the fly. But now, we
write this is only used in execCompile so having this be a global
option that is ignored anywhere but in `compile` is rather confusing.
This documents some of the edge cases in the packaging code that I’ve
had trouble understanding so that the next person hopefully has an
easier time with this.
There is also some minor cleanup in this PR.
* Fix package names in depends field in pkg configs
Previously, we derived this based on the DAR name which breaks if you
use -o with rather confusing error messages. Now, we read it from the
`Name` field in the manifest that we added in
https://github.com/digital-asset/daml/pull/3805.
CHANGELOG_BEGIN
- [DAML Compiler] Fix an issue where transitive package dependencies
resulted in packages not being found, if the DAR name was changed with
`-o`.
CHANGELOG_END
* Fix package dependencies
* Move all datatypes out of daml-prim
This moves the remaining two modules DA.Types and GHC.Tuple to
separate LF packages with stable identifiers.
The only data types remaining are the ones for typeclasses which will
disappear once we move this to type synonyms.
CHANGELOG_BEGIN
- [DAML Compiler] The modules DA.Types and GHC.Tuple from daml-prim
have been moved to separate packages.
CHANGELOG_END
* Fix codegen tests
* Fix DarReader test
* Fix kvutils tests
* Fix jdbcdao tests
* Fix hs ledger bindings tests
* Refactor packaging logic
This is a first step towards cleaning up the packaging logic and
adding some comments to make it clearer what is going on. There are no
functional changes in this PR.
There is more stuff here that we can and should cleanup but I will
leave that for separate PRs.
* Update compiler/damlc/lib/DA/Cli/Damlc/Packaging.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Update compiler/damlc/lib/DA/Cli/Damlc/Packaging.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Update compiler/damlc/lib/DA/Cli/Damlc/Packaging.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Update compiler/damlc/lib/DA/Cli/Damlc/Packaging.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Document topological sorting
* Undo requiredE change
* language: suffix all dalfs dependencies in a dar with the pkgid.
This makes sure that dalf dependencies are not accidentally overwritten
when two packages with equally named dalfs are imported.
* factor out parseUnitId
This is a first step towards making sure that the package ids for
types defined in daml-prim and daml-stdlib don’t change. This PR
mostly adds all the necessary infrastructure for that and moves
GHC.Types and GHC.Prim to make sure it works.
Until data-dependencies are really solid and we have verified that we
no longer have performance issues with an increasing number of Haskell
packages, we still include the source files in daml-prim and then just
rewrite the references.
We will also need to add tests that these packages really have stable
ids but I’ll leave that for separate PRs since this doesn’t make that
much sense anyway until all of the types have moved to stable
packages.
CHANGELOG_BEGIN
- [DAML Compiler] The modules GHC.Prim and GHC.Types from daml-prim
have been moved to separate packages.
CHANGELOG_END
* Introduce a simpler template desugaring without support for generic templates
This adapts the LF conversion to the new template desugaring
introduced in our GHC fork. The guiding principle is that we use the
typeclasses directly to avoid generating, typechecking and converting
redundant code caused by indirections. I updated the template
desugaring documentation so that is probably a good starting point for
reviewing this.
* Address review comments
* Fix daml doc tests
* Fix data dependency tests
* Switch to new ghc-lib release
* Set Sdk-Version in DAR Manifest to compiler SDK version.
CHANGELOG_BEGIN
- [DAML Compiler] Bugfix: The Sdk-Version field in a DAR manifest file
now matches the SDK version of the compiler, not the sdk-version field
from daml.yaml. These are usually the same, but they could be different
if you set the DAML_SDK_VERSION environment variable before running
``daml init`` or ``daml build``.
CHANGELOG_END
* Fallback to daml.yaml if env var not set
* add yaml dependency
* Always require sdk-version, and emit warning on mismatch with env var
* More explicit about where override comes from
* Add packaging regression test
* language: make only needed packages visible for cross sdk imports
This gives us more control over what packages are visible in the package
database during cross sdk imports and makes sure we're not accidentally
picking up the wrong one.
* Update compiler/damlc/lib/DA/Cli/Damlc/Packaging.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* deal with evil dalf imports
* Move packaging tests to a separate test suite
Originally, we had these as part of the integration test suite since
`bazel run damlc build` couldn’t locate `ghc-pkg` but that has been
fixed for a while.
Moving it to a separate test suite speeds things up as the integration
tests are rerun very often and also makes development much more
convenient since the new test suite supports `-p` properly to filter
to specific tests.
For now, I’ve left the upgrading tests as part of the integration
tests. I expect that we probably want to factor those out to another
test suite as well.
* fix warnings
It has grown large enough that by now it definitely deserves to be in
its own module.
This PR does not change any of the actual code, it simply moves it around.
* language: fix for tuple types in source generation
We correct the source generation from dalfs containing TupleN data
types. A test is added to the integration tests of daml assistant and
the `generate-src` command is improved to make this test possible.
* check that tuple type comes from DA.Types
* check that compilation succeeded
* pattern match golf
* check for tuples between 2 and 20
This change allows to only import `module A` from the instances package
if data dependencies are present instead of `module A` and `module
AInstances`.
I didn't really read the code around the FIXME. After spending a few moments
on it, I'm now convinces the current behaviour is the right behaviour. I
can't think of a short way to explain it in a comment without inflicting my
my previous confusion on others. Thus, I just remove the FIXME.
When buidling simple project that has our favourite large project as a
dependency, this decreased
- total allocations from 63GB to 57GB
- run time from 34.0s to 31.5s
* language: introduce data-imports
Right now the user experience for importing dalfs and dars from
different sdks is quiet confusing. This PR tries to solve this. We add
an additional field `data-imports` to daml.yaml. These imports can come
from different SDK's and we will generate interface files containing the
data types and their Template instances.
This also simplifies the migration command, as it now always imports the
respective packages as `data-imports`.
* Add support for on-disk incremental builds in damlc build
* Normalise file paths of internal modules because Windows
* stop stealing my $s hlint
* Apparently jars are also called exe
* Address review comments
* Bump to proper ghcide revision
* language: cross sdk dalf/dar imports
The final piece for cross sdk imports. With this PR we can import the
data types of packages and dalfs that were created with different sdks.
This is done by generating interface files from dalfs and an 'instances'
package that contains the template instance definitions of template data
types. The instances itself are defined via the `external` keyword,
which is inlined to proper daml-lf instance definitions given in the
respective dalf package.
We test that cross sdk imports work by importing the `simple-dalf` in
the daml-assistant integation tests and running a scenario.
* language: refactoring of iface file generation and package db setup.
This is a refactoring of the damlc part that creates the package
database and the code generation for interface files. This is a
preparation for the cross sdk imports.
We also add an internal command to damlc to generate generic instances
code and use simple copying via {..} in the migration command. An
additional test checks that migration via generics still works.
* Update compiler/damlc/daml-compiler/src/DA/Daml/Compiler/Upgrade.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* clearer description for generate-gen-src
* updated documentation
* correct copy/pasta mistake
* added a comment on different build options in migration command.
* Update compiler/damlc/lib/DA/Cli/Damlc.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* resolve dalf paths from dar manifest
* added a comment on different headers in upgrade modules.
* removed monoid instance for ExtractedDar
* Extend Priority type with Telemetry value
* Include Telemetry logging level in logger
* Log viewing of scenario results
* Update ghcide with telemetry logging level
* language: dalf imports and a test
This adds the possibility to directly import dalfs in a project. We test
that we can import the `simple-dalf` in the daml-assistant integation
tests. For now we only check that data type generation works, not yet
the template instance.
The following was fixed: When rewriting package self references, this
changes the hash of the package later on and leads to different package
hashes. Also we need to be careful to write the orignal binary
representation to this and not re-encode it because the encoding might
have changed with a different sdk.
* addressing moritz's comments.
* windows doesnt like bazel paths
This moves the creation of a package database from given dalfs out of
the migrate command and into the init command. In particular, this makes
the process of creating a package database independent of the migrate
command.
It also changes the way this package database is created to be only
dependend on given dalf files.
* language: add internal command for generating source from dalf.
We add an internal command for generating DAML source code from .dalf
packages. Also adds an internal flag to tell the compiler, that it is
compiling generated source.
The filename of the dar is not something that you should rely on as
evidenced by the fact that we have a -o option to change it to
something completely different.
The issue was actually not really related to CPP but to the lack of
sandboxing on Windows. That resulted in us overwriting Prelude.hi from
the 1.dev rule with the Prelude.hi from the 1.6 rule in some cases
which caused the error we were seeing.
fixes#2983
