Process:
- `git ls-files | xargs sed -i 's/DAML/Daml/g'`
- `git add -p`
To review:
- Check for false positives by carefully reviewing the diff in this PR.
- Check for false negatives with `git grep DAML`.
CHANGELOG_BEGIN
- Removed all traces of DAML. This may affect error messages and debug
outputs.
CHANGELOG_END
We initially did not commit this since keeping it in sync is
annoying. We cannot use a symlink because Windows. However, it changes
sufficiently rarely that checking it in + a check that the two are in
sync seems less fragile than the current state.
changelog_begin
changelog_end
* dev-env: Add a symlink, `dev-env/jdk`, to the current JDK.
This makes configuring IntelliJ IDEA to use the correct JDK much easier.
CHANGELOG_BEGIN
CHANGELOG_END
* dev-env: Document setting up the JDK in IntelliJ IDEA.
* Spell out bazel directories in .gitignore
With the old `/bazel-*` pattern in there, `rg` also ignores files like
`bazel-haskell-deps.bzl`, which is quite inconvenient.
I obtained the list of what should be hidden by uncommenting the
`/bazel-*` line and adding evering `git status` showed as new files.
Thus, the list is hopefully complete.
We have a similar issue with `/compatibility/bazel-haskell-deps.bzl`.
Since I could figure out what exactly we want to ignore there, I just
added an un-ignore for that single file.
CHANGELOG_BEGIN
CHANGELOG_END
* Go with the unignore approach everywhere
CHANGELOG_BEGIN
CHANGELOG_END
* A terser .gitignore file.
I trimmed _.gitignore_ to the stuff that looked like it was still useful
(at least, to me). Most of what's in there seemed like remnants of
previous build systems (Buck, Stack, etc.). Other stuff includes
editor-specific configuration files, which you can add to your global
_.gitignore_ (`git config --global core.excludesfile ~/.gitignore`).
I left the macOS _.DS_Store_ files in, even though I believe they should
also go into your global, machine-specific _.gitignore_ file, because
eventually someone's going to check them in otherwise.
On my machine, this has exactly the same effect as the longer one.
However, it's highly likely that I've overlooked something; let me know
and I can add it back.
CHANGELOG_BEGIN
CHANGELOG_END
* Add editors back into the .gitignore file.
I guess we really don't want people checking these files in by accident.
* Include the first feature in compat tests for create-daml-app
This adds the step from the create-daml-app tests that applies the
patch for the messaging feature and tests that things will build. This
is the last step before we can actually run the puppeteer tests which
will turn this into an actual compatibility test.
changelog_begin
changelog_end
* temporarily run all tests
changelog_begin
changelog_end
* Fix exclusions
changelog_begin
changelog_end
* Revert "temporarily run all tests"
This reverts commit 7425dd09cf48f2bfd6064b55d857c76d51afc821.
* Remove accidentally committed messaging.patch
changelog_begin
changelog_end
* Make compat tests work on windows
This required some changes to the daml_sdk rule since the read-only
installation by the assistant breaks Bazel completely. We could only
apply those changes on Windows but I think I prefer the consistency
across platforms here over trying to stay close to how the SDK is
installed on user machines given that the SDK installation is not
something we’ve had issues with.
I’ve excluded the postgresql tests for now. I don’t expect them to be
particularly hard to fix but I’ve already spent almost 2 days on this
and having some tests run on Windows seems like a clear improvement
over running no tests on Windows :)
changelog_begin
changelog_end
* Remove todo
changelog_begin
changelog_end
This is a first step towards testing cross-version
compatibility. It doesn’t actuall do much yet but hopefully it should
be easier to parallelize once we have the initial boilerplate in place
so ideally I’d like to address most missing things and issues in
separate PRs.
changelog_begin
changelog_end
* Add documentation for upgrading using DAML script and triggers
This PR adds documentation for how you can automate the upgrade
process from the Coin example using DAML Script and DAML Triggers.
Having written this, I think we might want to add some integration
tests for this but it’s rather complex to setup since it ties together
so many pieces so I’d like to leave it out for now. We do at least
test that the code compiles and we all knows that code that compiles
never has bugs.
changelog_begin
changelog_end
* Apply suggestions from code review
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
Co-authored-by: associahedron <231829+associahedron@users.noreply.github.com>
* ledger-on-sql: Pull out a superclass for the various integration tests.
* ledger-on-sql: Use Flyway to migrate tables in an idempotent manner.
CHANGELOG_BEGIN
CHANGELOG_END
* ledger-on-sql: Make it easy to run it with Bazel for experimentation.
* ledger-on-sql: Test that migrations will never change in the future.
* ledger-on-sql: Add a prefix of "ledger_" to the tables.
This is so we don't accidentally conflict with the index when the
schemas are shared.
I am letting myself modify the migrations because the existing
migrations haven't been merged into `master` yet.
* ledger-on-sql: Explain why we change the pool size after migration.
* ledger-api-test-tool: Tests now specify a timeout scale, not a timeout.
Makes it easier to change the default timeout in one place.
* ledger-api-test-tool: Increase timeouts on slow tests.
These tests produce a lot of volume and can make CI flaky.
* ledger-on-sql: Only tear down PostgreSQL in tests.
For other databases, we just create a new file for each test case.
* ledger-on-sql: Reduce the log output in tests.
* ledger-on-sql: Use a separate connection pool for Flyway when possible.
Apparently `setMaximumPoolSize` doesn't really have the desired effect
after the connection pool has already been used. The new test case will
be flaky if we process more than one commit in parallel.
For SQLite, it seems to be OK.
* ledger-on-sql: Use a separate connection pool for Flyway with SQLite.
Except in memory.
* ledger-on-sql: Use a separate PostgreSQL database for each test.
Because performance, innit. Don't have to tear them down.
* ledger-on-sql: Move the `Queries` values inside the `RDBMS` objects.
* ledger-on-sql: Go into even more detail about pool size hijinks.
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
* stack setup for HLB and Nim
* build_packages.sh and daml-ledger.cabal
* update README
* export-package for daml-ledger
* export-package, run here
* find tmp daml-ledger
* update README for review comments
* ref daml instructions
* further improve the process and documentation in response to comments
* have -with-rtsopts match the bazel build
* fixes for Gary
* Initial rattle prototype
* Build the IDE core
* Ignore the Rattle directory
* Clean up the dependencies
* Require stack-1.10, since that does much better extra-dep caching
* Streamline the ghc-lib dependencies
* Compile more pieces
* Add a build.bat
* Make the Windows build use the correct stack.yaml to bootstrap
* Fix up enough to build on Windows
* Generate the dylib's on Mac
* Remove accidental -v
* Make the Haskell build driven by the Bazel metadata
* Get proto3-suite building
* Delete the unneeded haskell-dependencies
* Allow generating the proto files and compiling them
* Fix metadata to deal with """ syntax
* Fix metadata to deal with a list of globs
* More work in the direction of daml-ghc
* Use correct daml_lf proto version
* Tell GHC to use shared objects in TH
* Specify needed packages
* wip
* wip
* Switch to the fork of gRPC-haskell
* Build executables with rattle
* setup build.sbt in daml-lf
* Build binaries with rattle
* rattle-sbt, move scala build scripts out of daml-lf subdir, and into rattle subdir
* convert scala-build.sh into MainScala.hs
* Clean up rattle build
* Pre-merge clean up
* Switch to the newer version of ghc-lib-parser
* remove dev ls from MainScala.hs
* compile java generated from protos as separate projects
* Add copyright headers
* HLint fixes
* Uscrewup an HLint fix
* fix scala formatting of rattle/build.sbt
This pr addresses security concerns regarding the web ide docker container.
The bulk of the changes involve managing and coordinating docker
networks so that the proxy runs on internal docker network as well as
external one, while the web ide containers run only on the internal
network.
