-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Connect Primitives to Layers #73
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks reasonable so far...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tons of name changing (very good ones like entropyToByteString
-> entropyToBytes
, using put
, read
rathaer than implementation suggesting enqueue
, dequeue
), relocating stuff (like wallet types from Cardano.WalletLayer
to Cardano.Wallet
) and a number of more precision types application : like using ScrubbedBytes
rather than ByteString
in generation key functions. I am especially fond of introducing of GetArg
class.
Still, do not understand why we forbid using more than one block per tick ... All "gaps" are going to be tackled elsewhere?
be59ed3
to
93e0605
Compare
93e0605
to
e77531a
Compare
putStrLn "" | ||
exitWithUsage cli | ||
|
||
class GetArg from where |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 Why not getArg
and getAllArgs
?
Side-note, previously I thought about (and wanted) to write the cli code like lift decode <$> getArg option
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually. I have been perhaps a bit too far. Having two functions would work as well. Once the Decodable
instance have been adjusted, we could rely on that and have two getArg
and getAllArgs
functions.
e77531a
to
fb60be2
Compare
Issue Number
#69
Overview
Comments
This is a rather big PR, I'll split that in multiple smaller ones as I also introduce various tests. I wanted to test the full pipeline and it's rather okay so far. The wallet processes blocks from the chain producer at a rather decent pace (~4000 blocks per second).
The memory usage looks also quite okay: