Up node version used by docker
Home /
Input Output /
cardano-wallet
May 30, 5-6 AM (1)
May 30, 6-7 AM (1)
May 30, 7-8 AM (9)
May 30, 8-9 AM (30)
May 30, 9-10 AM (13)
May 30, 10-11 AM (0)
May 30, 11-12 PM (3)
May 30, 12-1 PM (1)
May 30, 1-2 PM (5)
May 30, 2-3 PM (0)
May 30, 3-4 PM (0)
May 30, 4-5 PM (0)
May 30, 5-6 PM (0)
May 30, 6-7 PM (0)
May 30, 7-8 PM (0)
May 30, 8-9 PM (0)
May 30, 9-10 PM (0)
May 30, 10-11 PM (0)
May 30, 11-12 AM (2)
May 31, 12-1 AM (1)
May 31, 1-2 AM (2)
May 31, 2-3 AM (0)
May 31, 3-4 AM (0)
May 31, 4-5 AM (0)
May 31, 5-6 AM (2)
May 31, 6-7 AM (1)
May 31, 7-8 AM (43)
May 31, 8-9 AM (25)
May 31, 9-10 AM (4)
May 31, 10-11 AM (0)
May 31, 11-12 PM (0)
May 31, 12-1 PM (8)
May 31, 1-2 PM (6)
May 31, 2-3 PM (10)
May 31, 3-4 PM (0)
May 31, 4-5 PM (0)
May 31, 5-6 PM (0)
May 31, 6-7 PM (0)
May 31, 7-8 PM (0)
May 31, 8-9 PM (0)
May 31, 9-10 PM (0)
May 31, 10-11 PM (0)
May 31, 11-12 AM (0)
Jun 01, 12-1 AM (0)
Jun 01, 1-2 AM (0)
Jun 01, 2-3 AM (0)
Jun 01, 3-4 AM (0)
Jun 01, 4-5 AM (29)
Jun 01, 5-6 AM (1)
Jun 01, 6-7 AM (2)
Jun 01, 7-8 AM (16)
Jun 01, 8-9 AM (0)
Jun 01, 9-10 AM (0)
Jun 01, 10-11 AM (2)
Jun 01, 11-12 PM (2)
Jun 01, 12-1 PM (9)
Jun 01, 1-2 PM (0)
Jun 01, 2-3 PM (1)
Jun 01, 3-4 PM (1)
Jun 01, 4-5 PM (0)
Jun 01, 5-6 PM (0)
Jun 01, 6-7 PM (0)
Jun 01, 7-8 PM (0)
Jun 01, 8-9 PM (5)
Jun 01, 9-10 PM (0)
Jun 01, 10-11 PM (1)
Jun 01, 11-12 AM (2)
Jun 02, 12-1 AM (0)
Jun 02, 1-2 AM (0)
Jun 02, 2-3 AM (0)
Jun 02, 3-4 AM (2)
Jun 02, 4-5 AM (33)
Jun 02, 5-6 AM (1)
Jun 02, 6-7 AM (1)
Jun 02, 7-8 AM (0)
Jun 02, 8-9 AM (0)
Jun 02, 9-10 AM (10)
Jun 02, 10-11 AM (6)
Jun 02, 11-12 PM (1)
Jun 02, 12-1 PM (4)
Jun 02, 1-2 PM (13)
Jun 02, 2-3 PM (0)
Jun 02, 3-4 PM (0)
Jun 02, 4-5 PM (0)
Jun 02, 5-6 PM (0)
Jun 02, 6-7 PM (0)
Jun 02, 7-8 PM (0)
Jun 02, 8-9 PM (0)
Jun 02, 9-10 PM (0)
Jun 02, 10-11 PM (0)
Jun 02, 11-12 AM (0)
Jun 03, 12-1 AM (0)
Jun 03, 1-2 AM (0)
Jun 03, 2-3 AM (0)
Jun 03, 3-4 AM (0)
Jun 03, 4-5 AM (0)
Jun 03, 5-6 AM (0)
Jun 03, 6-7 AM (0)
Jun 03, 7-8 AM (0)
Jun 03, 8-9 AM (0)
Jun 03, 9-10 AM (0)
Jun 03, 10-11 AM (0)
Jun 03, 11-12 PM (0)
Jun 03, 12-1 PM (0)
Jun 03, 1-2 PM (0)
Jun 03, 2-3 PM (0)
Jun 03, 3-4 PM (0)
Jun 03, 4-5 PM (0)
Jun 03, 5-6 PM (0)
Jun 03, 6-7 PM (0)
Jun 03, 7-8 PM (0)
Jun 03, 8-9 PM (0)
Jun 03, 9-10 PM (0)
Jun 03, 10-11 PM (0)
Jun 03, 11-12 AM (0)
Jun 04, 12-1 AM (0)
Jun 04, 1-2 AM (0)
Jun 04, 2-3 AM (0)
Jun 04, 3-4 AM (0)
Jun 04, 4-5 AM (0)
Jun 04, 5-6 AM (0)
Jun 04, 6-7 AM (1)
Jun 04, 7-8 AM (3)
Jun 04, 8-9 AM (0)
Jun 04, 9-10 AM (0)
Jun 04, 10-11 AM (0)
Jun 04, 11-12 PM (0)
Jun 04, 12-1 PM (0)
Jun 04, 1-2 PM (0)
Jun 04, 2-3 PM (0)
Jun 04, 3-4 PM (0)
Jun 04, 4-5 PM (0)
Jun 04, 5-6 PM (0)
Jun 04, 6-7 PM (0)
Jun 04, 7-8 PM (0)
Jun 04, 8-9 PM (0)
Jun 04, 9-10 PM (0)
Jun 04, 10-11 PM (0)
Jun 04, 11-12 AM (28)
Jun 05, 12-1 AM (10)
Jun 05, 1-2 AM (1)
Jun 05, 2-3 AM (0)
Jun 05, 3-4 AM (2)
Jun 05, 4-5 AM (0)
Jun 05, 5-6 AM (0)
Jun 05, 6-7 AM (0)
Jun 05, 7-8 AM (0)
Jun 05, 8-9 AM (1)
Jun 05, 9-10 AM (0)
Jun 05, 10-11 AM (1)
Jun 05, 11-12 PM (1)
Jun 05, 12-1 PM (0)
Jun 05, 1-2 PM (4)
Jun 05, 2-3 PM (5)
Jun 05, 3-4 PM (5)
Jun 05, 4-5 PM (0)
Jun 05, 5-6 PM (0)
Jun 05, 6-7 PM (2)
Jun 05, 7-8 PM (1)
Jun 05, 8-9 PM (0)
Jun 05, 9-10 PM (0)
Jun 05, 10-11 PM (0)
Jun 05, 11-12 AM (4)
Jun 06, 12-1 AM (0)
Jun 06, 1-2 AM (3)
Jun 06, 2-3 AM (0)
Jun 06, 3-4 AM (0)
Jun 06, 4-5 AM (21)
Jun 06, 5-6 AM (0)
402 commits this week
May 30, 2023
-
Jun 06, 2023
Update cardano-node version used in runtime to 8.0.0
Remove warning about exporting default constructor for `TokenMap`.
It's no longer necessary to worry about exporting the default constructor for `TokenMap`. The original concern was that exporting the default constructor would allow callers to break the invariant that there are no `mempty` values in the map. However, this is no longer possible, as the `MonoidMap` type handles this invariant automatically. Therefore, it's no longer necessary to have a warning. Nevertheless, this commit doesn't export the default constructor, as there currently isn't any need to do so.
Simplify implementation of `TokenMap.unsafeSubtract`.
Remove invariant tests for `TokenMap`.
The `TokenMap` type has an invariant that: - no `mempty` values appear within the internal data structure. - no `mempty` values appear within any encoding of a `TokenMap`. The `MonoidMap` type already guarantees to handle this invariant, and that type is covered by a comprehensive test suite. Therefore, there's no need to repeat those tests for the `TokenMap` type.
Simplify implementation of `TokenMap.isNotEmpty`.
Simplify implementation of `TokenMap.intersection`.
Simplify implementation of `TokenMap.isEmpty`.
Simplify implementation of `TokenMap.leq`.
Simplify implementation of `TokenMap.adjustQuantity`.
Simplify implementation of `TokenMap.subtract`.
Derive `Semigroup` and `Monoid` subclasses for `TokenMap`.
Simplify implementation of `TokenMap.maximumQuantity`.
Simplify implementation of `TokenMap.difference`.
Simplify implementation of `TokenMap.add`.
Redefine `TokenMap` in terms of `MonoidMap`.
Remove dependency on `NonEmptyMap` from `Token{Bundle,Map}`.
Derive `Semigroup` and `Monoid` for `TokenMap`.
Add dependency on `quickcheck-monoid-subclasses`.
Merge #3862
3862: Make API error expectations compiler-checkable. r=jonathanknowles a=jonathanknowles Follow-on from https://github.com/input-output-hk/cardano-wallet/pull/3824 ([ADP-2269](https://input-output.atlassian.net/browse/ADP-2269)). ## Summary This PR replaces `expectErrorCode`, which creates expectations based on string comparisons, with `expectErrorInfo`, which creates expectations based on `ApiErrorInfo` objects. This has two advantages: - expectation expressions can be checked statically by the compiler. - it's possible to express richer expectations based on internal fields of errors (not all errors are just simple values -- some have nested records), using combinators provided by `hspec`. ## Context In our test suite we test at least two kinds of mapping: - The mapping between API types and their serialised JSON representations: for all API types, the JSON encoding should be consistent with the OpenAPI specification, and the round trip property `(decode . encode == id)` should hold for all values. - The mapping from (API call, inputs, state) to API response values: i.e, that API calls return the responses we expect, given appropriate inputs and the current (implicit) wallet state. Up until now, the approach we've used in `cardano-wallet` is to separate the above two concerns into **different test suites**, i.e., to: - test expectations about our JSON serialisation logic in specialised tests for just that purpose (JSON golden round trip tests and the test suite for the OpenAPI spec). - within other test suites (such as the integration test suite), **assume** the correctness of our JSON serialisation logic, and express expectations in terms of ordinary (decoded) Haskell values. API errors have, up until now, been a sort of exception to this separation of concerns, because until recently we didn't have a good way to create structured errors. But since merging #3557, which provides support for structured errors and the accompanying [decodeErrorInfo](https://github.com/input-output-hk/cardano-wallet/blob/504774f0f08f4ec74fa91106bc004d8e7b97f875/lib/wallet/integration/src/Test/Integration/Framework/DSL.hs#L559) function, we've gradually been converting expectations about API errors to use the same style as we use for ordinary values returned by the API, which is to express expectations in terms of ordinary Haskell expressions, and to avoid writing expectations in terms of hard-coded strings. For example, for ordinary (non-error) API responses, we typically write expectations like this: https://github.com/input-output-hk/cardano-wallet/blob/7af6d54d21443146320eab04452eefb75b3d553e/lib/wallet/integration/src/Test/Integration/Scenario/API/Shelley/Transactions.hs#L297-L299 Co-authored-by: Jonathan Knowles <[email protected]>
Simplify `hasEntryForAsset`.
Redefine `UTxOIndex` in terms of `MonoidMap`.
Redefine `UTxOIndex` in terms of `MonoidMap`.
Remove unused function `expectErrorCode`.