The call to blockingGet can lead to no progress being made in certain
scenarios. Therefore I am removing the blocking call and replacing it
with a regular "doOnSuccess".
* remove early returns
* make reference index service stop repeating last event indefinitely
* make all services follow more consistent design, no unnecessary inherits, no unnecessary methods
* scala format
* Remove long gone patch
The "shorten-source-dirs" patch was removed some time ago but was still
referenced in bazel_tools.
* Drop upstreamed rules_haskell patches
Some patches have been upstreamed to rules_haskell.
* Build haskell-ide-core on CI
* Apply buildifier
* Update rules_haskell
The latest version uses stackage's mirror of Hackage.
* ci: always use the linux-pool
reduce the difference of environment between external and internal
contributions
* infra: tweak the linux cache warmup script
Don't share the same bazel cache directory with the disk cache, which is
something else. Be more specific about the target. Clean after yourself.
* infra: bump the linux agent disk to 200GB
avoid running out of disk space
The newer version seems to segfault on MacOS quite often so let’s
downgrade for now. We should also try to see if we can find a
reasonable way of reproducing this and report it upstream.
Add Dar Traverse and Equal, replace manually written test cases with
scalaz law checks;
Add test case for multiple DARs support;
Enforcing non empty list of input files
The codegen integration tests assume a specific location atm so we
need to specify that explicitely (eventually we might want to change
them to use the default location but not for now). The reason why we
didn’t catch this before merging the package-new command is that the
PR was not rebased on top of the changes that added the codegen
integration tests.
The DAML-LF Archive Protobuf definitions, as packaged and distributed
via Bintray and the SDK, currently packages the files in a directory
structure that does not match with the actual one, causing the usage of
`protoc` on the packaged definitions to raise errors. This commit fixes
it by packaging the files in the same directory structure as the one
found in the repository.
* HOTFIX: increasing 30.sec timeout to 300.sec
this to fix SQL-backed ledger tests that currently keep timing out.
It is NOT really a fix, but a temp work-around. Tried to get rid of
this timeout, but it propogates all over the place. Need a separate
story to address this
* HOTFIX: adding a link to the issue
* language: new package command for damlc
The (internal) package-new command reads all information from the
daml.yaml file of a DAML project and also creates the .conf file for the
package database and packs it with the dar.
Considering that there is no canonical source for status.proto generated
for scalapb (for java it is pulled in via a transitive dependency of
grpc-protobuf), we should rather compile and include it in the
ledger-api-scalapb artefact.
Compared to older versions of the Engine, we do A LOT more validation
now. So when starting with a fresh engine after each reset (via
the ResetService), we also repeat the validation of the loaded packages
again and again. This is VERY expensive, especially for large DAML
packages.
Luckily, the specification of the ResetService states the following:
// Resets the ledger state. Note that loaded DARs won't be removed --
// this only rolls back the ledger to genesis.
This means that we can re-use the same Engine object and benefit from
not having "re-compile" packages via
ConcurrentCompiledPackages#addPackage, more specifically we can omit
this line: 1f2246c822/daml-lf/engine/src/main/scala/com/digitalasset/daml/lf/engine/ConcurrentCompiledPackages.scala (L56)Fixes#178
* fix various conversion functions from string to Decimal
Fixes#399.
This fixes a critical bug -- since:
* The DAML-LF spec specifies that the scale of `Decimal` is 10 --
that is, there are at most 10 digits past the decimal point:
<79bbf5c794/daml-lf/spec/value.rst (field-decimal)>.
* However, the code converting from the string representation that
we get on the wire was _not_ performing this check. This is due
to two reasons:
- `Decimal.check` is a function that checks whether a given
`Decimal` is within the upper and lower bounds of what the
DAML-LF spec specifies, but crucially it does _not_ check that
the scale is not exceeded:
<79bbf5c794/daml-lf/data/src/main/scala/com/digitalasset/daml/lf/data/Decimal.scala (L31)>.
This behavior is correct in some cases (more on that later),
but not in others. Crucially, `Decimal.fromString`, which was
supposed to check if a decimal string literal is valid, used
this function, which means that it accepted string literals
containing numbers out of the required scale, rounding them to
make them fit within the scale. This function has been renamed
to `Decimal.checkWithinBoundsAndRound`, and a new function
`Decimal.checkWithinBoundsAndWithinScale` has been added, which
fails if the number provided has data not within the scale.
`Decimal.fromString` now uses
`Decimal.checkWithinBoundsAndWithinScale`.
- `ApiToLfEngine.parseDecimal` assumed that `Decimal.fromString` _did_
fail when passed numbers that were in any way invalid, and
moreover did _not_ use the result of `Decimal.fromString`, but rather
re-parsed the string into an unconstrained `BigDecimal`:
<79bbf5c794/ledger/ledger-api-common/src/main/scala/com/digitalasset/platform/participant/util/ApiToLfEngine.scala (L96)>.
The reason for the code to work this way is that in the past
it was responsible for converting decimal strings both for the
current engine but also for an older version of the engine which
handled decimals of a different type. Both issues have been fixed.
* Therefore, `Decimal`s with scale exceeding the specified scale
made it into the engine, and contracts could be created containing
this invalid value.
* Once on the ledger, these bad numbers can be used to produce extremely
surprising results, due to how `Decimal` operations are
implemented. Generally speaking, all operations on `Decimal`
first compute the result and then run the output through
`Decimal.checkWithinBoundsAndRound`. The reason for this behavior
is that we specify multiplication and division as rounding their
output. Consider the case where the bad value 0.00000000005 made
it to the engine, and is then added to 100. The full-precision
result will be 100.00000000005, which after rounding becomes 100.
Therefore, on a ledger where such invalid values exist, it is not
the case that `y > 0 ==> x + y != x`, and so on.
Thanks a bunch to @briandbecker for the excellent bug report.
* fix failing test using to much precision
