Home /
Input Output /
ouroboros-consensus
May 24, 11-12 AM (2)
May 25, 12-1 AM (0)
May 25, 1-2 AM (0)
May 25, 2-3 AM (0)
May 25, 3-4 AM (0)
May 25, 4-5 AM (0)
May 25, 5-6 AM (0)
May 25, 6-7 AM (0)
May 25, 7-8 AM (2)
May 25, 8-9 AM (0)
May 25, 9-10 AM (1)
May 25, 10-11 AM (7)
May 25, 11-12 PM (1)
May 25, 12-1 PM (0)
May 25, 1-2 PM (0)
May 25, 2-3 PM (1)
May 25, 3-4 PM (9)
May 25, 4-5 PM (0)
May 25, 5-6 PM (0)
May 25, 6-7 PM (0)
May 25, 7-8 PM (0)
May 25, 8-9 PM (0)
May 25, 9-10 PM (0)
May 25, 10-11 PM (0)
May 25, 11-12 AM (0)
May 26, 12-1 AM (0)
May 26, 1-2 AM (0)
May 26, 2-3 AM (0)
May 26, 3-4 AM (0)
May 26, 4-5 AM (1)
May 26, 5-6 AM (0)
May 26, 6-7 AM (0)
May 26, 7-8 AM (0)
May 26, 8-9 AM (1)
May 26, 9-10 AM (0)
May 26, 10-11 AM (2)
May 26, 11-12 PM (2)
May 26, 12-1 PM (3)
May 26, 1-2 PM (4)
May 26, 2-3 PM (0)
May 26, 3-4 PM (0)
May 26, 4-5 PM (0)
May 26, 5-6 PM (0)
May 26, 6-7 PM (0)
May 26, 7-8 PM (0)
May 26, 8-9 PM (0)
May 26, 9-10 PM (0)
May 26, 10-11 PM (2)
May 26, 11-12 AM (0)
May 27, 12-1 AM (0)
May 27, 1-2 AM (0)
May 27, 2-3 AM (0)
May 27, 3-4 AM (0)
May 27, 4-5 AM (0)
May 27, 5-6 AM (0)
May 27, 6-7 AM (0)
May 27, 7-8 AM (0)
May 27, 8-9 AM (0)
May 27, 9-10 AM (0)
May 27, 10-11 AM (0)
May 27, 11-12 PM (0)
May 27, 12-1 PM (0)
May 27, 1-2 PM (0)
May 27, 2-3 PM (0)
May 27, 3-4 PM (0)
May 27, 4-5 PM (0)
May 27, 5-6 PM (0)
May 27, 6-7 PM (0)
May 27, 7-8 PM (0)
May 27, 8-9 PM (0)
May 27, 9-10 PM (0)
May 27, 10-11 PM (0)
May 27, 11-12 AM (0)
May 28, 12-1 AM (0)
May 28, 1-2 AM (0)
May 28, 2-3 AM (0)
May 28, 3-4 AM (0)
May 28, 4-5 AM (0)
May 28, 5-6 AM (0)
May 28, 6-7 AM (0)
May 28, 7-8 AM (0)
May 28, 8-9 AM (0)
May 28, 9-10 AM (0)
May 28, 10-11 AM (0)
May 28, 11-12 PM (0)
May 28, 12-1 PM (0)
May 28, 1-2 PM (0)
May 28, 2-3 PM (0)
May 28, 3-4 PM (0)
May 28, 4-5 PM (0)
May 28, 5-6 PM (0)
May 28, 6-7 PM (0)
May 28, 7-8 PM (0)
May 28, 8-9 PM (0)
May 28, 9-10 PM (0)
May 28, 10-11 PM (0)
May 28, 11-12 AM (0)
May 29, 12-1 AM (0)
May 29, 1-2 AM (0)
May 29, 2-3 AM (0)
May 29, 3-4 AM (0)
May 29, 4-5 AM (0)
May 29, 5-6 AM (0)
May 29, 6-7 AM (0)
May 29, 7-8 AM (0)
May 29, 8-9 AM (0)
May 29, 9-10 AM (0)
May 29, 10-11 AM (0)
May 29, 11-12 PM (0)
May 29, 12-1 PM (0)
May 29, 1-2 PM (0)
May 29, 2-3 PM (3)
May 29, 3-4 PM (4)
May 29, 4-5 PM (3)
May 29, 5-6 PM (0)
May 29, 6-7 PM (0)
May 29, 7-8 PM (0)
May 29, 8-9 PM (0)
May 29, 9-10 PM (0)
May 29, 10-11 PM (0)
May 29, 11-12 AM (0)
May 30, 12-1 AM (0)
May 30, 1-2 AM (0)
May 30, 2-3 AM (0)
May 30, 3-4 AM (0)
May 30, 4-5 AM (1)
May 30, 5-6 AM (2)
May 30, 6-7 AM (0)
May 30, 7-8 AM (2)
May 30, 8-9 AM (1)
May 30, 9-10 AM (1)
May 30, 10-11 AM (1)
May 30, 11-12 PM (0)
May 30, 12-1 PM (0)
May 30, 1-2 PM (1)
May 30, 2-3 PM (5)
May 30, 3-4 PM (3)
May 30, 4-5 PM (1)
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 (0)
May 31, 12-1 AM (0)
May 31, 1-2 AM (0)
May 31, 2-3 AM (0)
May 31, 3-4 AM (0)
May 31, 4-5 AM (0)
May 31, 5-6 AM (0)
May 31, 6-7 AM (0)
May 31, 7-8 AM (7)
May 31, 8-9 AM (7)
May 31, 9-10 AM (4)
May 31, 10-11 AM (2)
May 31, 11-12 PM (2)
May 31, 12-1 PM (0)
May 31, 1-2 PM (1)
May 31, 2-3 PM (0)
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)
88 commits this week
May 25, 2023
-
Jun 01, 2023
Merge branch 'dnadales/fix-benchmarks-workflow' into jasagredo/merge-mp-fair
Use `cryptoInit` everywhere (#120)
Follow-up to #119 that makes sure that we call `cryptoInit` before all test suites and executables. As for why we didn't notice that this was missing for e.g. db-analyser so far: According to the cardano-base maintainers, not calling `cryptoInit` does at least not cause random segfaults, but may impact performance and cryptographic security.
force new strict MVar value before calling putTMVar in updateMVar (#102)
Part of [ouroboros-network#4006](https://github.com/input-output-hk/ouroboros-network/issues/4006) Adds a strictness annotation in `Ouroboros.Consensus.Util.MonadSTM.StrictMVar.updateMVar` to force the value we're putting into the `StrictMVar` (`'a`) before checking its invariant. This function isn't commonly used in ouroboros-consensus, but was causing `Ouroboros.Consensus.Mock.Node.Praos.praosBlockForging` to violate its NoThunks invariant during tests.
Merge branch 'main' into jasagredo/merge-mp-fair
Define `HasLedgerTables` combinators in terms of `H2K` combinators.
Merge branch 'main' into jasagredo/merge-mp-fair
Make `LedgerTables` a `newtype` instead of a data family.
`LedgerTable`s have the same structure, regardless of the `l` type parameter. Instead, we now have just one `LedgerTables` `newtype`, and we can cast between `LedgerTables` with different `l` parameters as long as the types of keys and values inside the `LedgerTables` match. Also: provide instances for `H2K` classes.
Add the `H2K` module, which defines classes and utilities for
higher-order, double keyed functors over bifunctors. Later commits will define instances of these classes for `LedgerTables`.
add a description of the new updateMVar strictness tests (and describe why they aren't helpful with compiler optimizations turned on)
add more specific info to clarify why there can be unforced thunks in updateMVar
Add some tests that check the combination of StrictMVar's updateMVar with the noThunks invariant that we use in Consensus
force new value of StrictMVar before calling putTMVar in updateMVar
yes, this is an odd-looking change. it's not unreasonable to assume that forcing !(!a', b) inside the atomically block will force the new value before putting it into the MVar, but there's actually an additional closure constructed (with a dependency on a') that will only force a' when *it's* evaluated! in order to ensure that we're forcing the value inside the MVar before calling checkInvariant, we need an additional bang outside the atomically block, which will correctly force a' before checkInvariant looks to see if it's been evaluated or not. without this change, it's possible to put a lazy value inside a StrictMVar (though it's very unlikely that this has happened in the past in production environments because this intermediate unforced closure is optimized away at -O1 and above)
add a large describing the reason behind the additional bang in updateMVar
LedgerDB -> DbChangelog, LgrDB -> LedgerDB
Replace `StrictSVar` where possible by `StrictMVar` with NoThunks checks
Add `strict-mvar` dependency and `StrictMVar` with NoThunks invariants.
We depend on an unreleased version of `strict-mvar` and we create a new module for `StrictMVar`s with `NoThunks` invariants. We also add a flag `checkmvarnothunks` that acts as a switch for whether we want to run the invariant checks or not. By default, these checks are off, since we do not want to perform these checks in production.
Fix compilation after renaming.
Rename `StrictMVar` module to `StrictSVar`.
Rename definitions in the `StrictSVar` module.
add more specific info to clarify why there can be unforced thunks in updateMVar
Update Nix infra (#121)
- Update flake pins - iohk-nix: libsodium-vrf is now pinned differently - GHC 9.2.8 (fixes a segfault on some recent Linux kernels) - HLS 2.0.0.0
Update Nix infra
- Update flake pins - iohk-nix: libsodium-vrf is now pinned differently - GHC 9.2.8 (fixes a segfault on some recent Linux kernels) - HLS 2.0.0.0
Call `cryptoInit` in our utility tools
We could also share a common "setup" function across all executables, but we currently don't need it for anything else.