* store archive size in `DarReader`
* rename `SandboxTemplateStore` to `SandboxPackageStore`
* store package info in `SandboxPackageStore`
* introduce package upload / read to write / index services
not tested yet, just a ton of plumbing
* WIP test the package service
* Fix build errors after rebase
* Move packages service to v2
* Ledger API client uses ledger API types
* Fix ReflectionIT
* Correctly handle uploading invalid dar files
* Fix reading DAR entry file sizes
* Improve package management IT
* Improve handling of duplicate packages
* Fix language-support build
* Use unique party and command names
* Rename lfpackage to language
* Rename SandboxPackageStore to InMemoryPackageStore
* Remove getCurrentTime ledger method
* Improve package management IT
* Move InMemoryActiveContracts and InMemoryPackageStore
* Use case object for UploadDarResult.Ok
* Address review comments
* Update release notes
Fixes#1311
* Use BazelRunfiles in test
* encode ast in protobuf
* daml-lf parser: make defaultPackageId and languageVersion parametric
* daml-lf rewritting of AST
* test ast encoder
* copyright
* test function type encoding
* daml-lf add parameter to parser implicits
* damlfl-as stands for "damllf assembler"
* move encoder in its own private package
* Allow slashes in ledger strings
Using '/' as the divider is a natural choice for some ledger backend
implementations and in application/workflow etc. identifiers.
* Update value.proto to include slash in LedgerStrings
* Update release notes
ImmArray, FrontStack, and BackStack violated the contract between equals
and hashCode. ImmArray had a wrong implementation of hashCode, and
FrontStack and BackStack had no implementation at all.
Fixes#1623.
* Isolate daml-on-x prototype
* Implement TransactionService of index api.
Towards the first milestone of the daml-on-x integration steps
* fix compiler error after last-minute refactoring
* formatting
* remove unnecessary dependency from api-server-damlonx
* Fix some inconsistencies.
* Rename Value's ContractId to VContractId
* daml-lf: a bit more about PartyId
* daml-lf: Concatenable MatchingStringModule
* daml-lf make clear type used for Scenarios only
* daml-lf create ContractId, LedgerId, TransactionId
* sandbox-sql conversion util
* LedgerName -> LedgerString
* futher type cleanup in the sandbox
* daml-lf add test for LedgerString
* fixing tests
* a bit more safety in the DB
* Address Stephen's comments
* fix rebase
* More fixes for StringModule
* change length of LedgerString (256 -> 255)
* stub away the components of LedgerValue
* rewrite v1 api converters to produce transaction Value ADT
* a needless 'case'
* shortcut methods for ImmArraySeq and tests
* porting extractor's JSON encoders to transaction Value
- JSON object ordering now matches record field order, instead of being
its reverse
- Includes a new encoding for records missing labels, to a list of
2-tuples
* porting extractor main transaction Value
- JSON date/time is just <num>s since epoch, maybe revisit
* adapt to Decimal newtype
* use daml-lf/data stringification for decimals in JSON
* snap aliases for Cid-less LedgerValue subtypes
* snap aliases for Cid-containing LedgerValue subtypes
* remove needless indirection
* test new missing-label Record JSON encoding
* write ImmArray traverse with syntax extension
* remove RecordField; move Name parsing to former RecordField converter
* daml-lf: make Decimal type safe
* daml-lf: create Utf8String type
* daml-lf: cleanup in data package
* Address Stephen Comments
* daml-lf: remove UTF8String
* enable Return wartremover wart
* remove return keyword from various places in daml-lf
* remove return keyword from various places in ledger
* simpler ImmArray equals
* move traverseEitherStrictly to point of use
* remove return from ledger-api-server-example
* Map case of Equal[Value] was not properly recursive
* protect SortedLookupList from equals incoherence
* simplify ImmArray creation
* clean up boilerplate in Equal[Value] definition
* use match2 for isReplayedBy
* 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
* Add buildifier targets.
The tool allows to check and format BUILD files in the repo.
To check if files are well formatted, run:
bazel run //:buildifier
To fix badly-formatted files run:
bazel run //:buildifier-fix
* Cleanup dade-copyright-headers formatting.
* Fix dade-copyright-headers on files with just the copyright.
* Run buildifier automatically on CI via 'fmt.sh'.
* Reformat all BUILD files with buildifier.
Excludes autogenerated Bazel files.
