Make the PAB log ~1/10_000 messages.
The way it was configured rarely if ever prints anything.
The way it was configured rarely if ever prints anything.
(hsPkgs."ouroboros-network-framework" or (errorHandler.buildDepError "ouroboros-network-framework"))
(hsPkgs."prettyprinter" or (errorHandler.buildDepError "prettyprinter"))
(hsPkgs."quickcheck-instances" or (errorHandler.buildDepError "quickcheck-instances"))
(hsPkgs."random" or (errorHandler.buildDepError "random"))
(hsPkgs."row-types" or (errorHandler.buildDepError "row-types"))
(hsPkgs."servant" or (errorHandler.buildDepError "servant"))
(hsPkgs."servant-client" or (errorHandler.buildDepError "servant-client"))
(hsPkgs."ouroboros-network-framework" or (errorHandler.buildDepError "ouroboros-network-framework"))
(hsPkgs."prettyprinter" or (errorHandler.buildDepError "prettyprinter"))
(hsPkgs."quickcheck-instances" or (errorHandler.buildDepError "quickcheck-instances"))
(hsPkgs."random" or (errorHandler.buildDepError "random"))
(hsPkgs."row-types" or (errorHandler.buildDepError "row-types"))
(hsPkgs."servant" or (errorHandler.buildDepError "servant"))
(hsPkgs."servant-client" or (errorHandler.buildDepError "servant-client"))
ouroboros-network-framework -any,
prettyprinter >=1.1.0.1,
quickcheck-instances -any,
random -any,
row-types -any,
servant -any,
servant-client -any,
import Plutus.ChainIndex.TxIdState qualified as TxIdState
import Plutus.ChainIndex.TxOutBalance qualified as TxOutBalance
import Plutus.Contract.CardanoAPI (fromCardanoTx)
import System.Random
-- | Connect to the node and write node updates to the blockchain
-- env.
-- we start logging from here to avoid spamming the terminal
-- should be removed when we have better logging to report
-- on the PAB sync status
if (n `mod` 100_000 == 0 && n > 0) || (s >= recentSlot)
stdGen <- newStdGen
let logBlock = fst (randomR (0 :: Int, 10_000) stdGen) == 0
if logBlock || (s >= recentSlot)
then do
putStrLn $ "Current block: " <> show n <> ". Current slot: " <> show s
else pure ()
Other small changes include: * Added a trace event `TDBInitialisingFromLMDBDone`. * Initialisation from an existing LMDB database does not rely on the default `LMDBLimits` anymore, and is passed a limits argument instead. TODO: We should decide whether we want to hardcode these limits to a a substantially large one, or possibly we could link these limits to a versioning number?
add cwbtc
attempt implementation
Other small changes include: * Added a trace event `TDBInitialisingFromLMDBDone`. * Initialisation from an existing LMDB database does not rely on the default `LMDBLimits` anymore, and is passed a limits argument instead. TODO: We should decide whether we want to hardcode these limits to a a substantially large one, or possibly we could link these limits to a versioning number?
Updated crypto exchange rates chapter. I tried my best to address @rdlrt concerns. I would like to add that English is just my 3rd language, so I hope it is not too bad.
Previously, the sequence number of the database is written to disk as part of the on-disk database settings on every flush/write. Conceptually however, the settings of a database should not change on every flush or write. Instead, we make a dinstinction between on-disk database "settings" and "state", where the state can be updated in every write/flush, but the settings should generally be left untouched after database initialisation or node start-up.
Fixes #217.
This works because (a) JavaScript is ultimately single-threaded, (b) there's no execution preemption happening between a 'send' and a 'wait'.
This was using the raw Show instance of queries, which looks real bad for constructors with arity > 1 like HasTx.