-
Notifications
You must be signed in to change notification settings - Fork 722
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
Transaction build in any alonzo era when on babbage testnet #4135
Conversation
|
3590002
to
2486484
Compare
11da8e5
to
df23de5
Compare
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.
Great work 👍 . I do have a suggestion for an improvement because I believe the Summon
type class is unnecessary. If you look closely, the summon type class is the same as as all of the supportedInEra
functions:
^ I have created a branch above. Feel free to cherry pick.
What are we trying to achieve with EraCast
? We want to see if a particular type is supported in another era and if it is we can convert it. We have a slew of isSupportedInEra
functions. If we add the era that we want our type to be converted to, we can simply reuse this functionality in the EraCast
instances and we can do away with the Summon
type class.
I would also like to add an error
type to the EraCast
. I have it defaulted to String
but this is atrocious. We can do better however this is complicated by some of the supportedInEra functions returning a Maybe
and some returning an Either
. I would suggest a datatype that contains the offending type and the era we are translating to. Propagate this upwards to the cli and in the cli we can include the era we are translating from. We can then render "X is supported in eraA but not eraB" or something like that.
df23de5
to
01c061e
Compare
4db7ef3
to
24866ae
Compare
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.
Almost there, one further suggestion
I think this is a better type for EraCastError
:
data EraCastError = forall toEra thing.
( IsCardanoEra toEra
, Show thing
) =>
EraCastError
{ typeName :: thing
, toEra :: CardanoEra toEra
}
Why? You get more information for free. E.g 0a12e83#diff-d2926b61bd606dc6c5e96c7607110c554a255cf353852708e0ecbbcc3ccbc4f0L1442
Previously all you were given was that you were trying to convert a ReferenceScript
script from one era to another. You have to perform some additional gymnastics to figure out which era you were converting from. However, if you propagate the data constructor and show
the offending data, it tells you exactly which reference script you were trying to convert and gives you the ReferenceTxInsScriptsInlineDatumsSupportedInEra era
type as well.
data ReferenceTxInsScriptsInlineDatumsSupportedInEra era where
ReferenceTxInsScriptsInlineDatumsInBabbageEra :: ReferenceTxInsScriptsInlineDatumsSupportedInEra BabbageEra
You immediately know you which era you were trying to convert from as this is given via the ReferenceTxInsScriptsInlineDatumsInBabbageEra
constructor.
If you want more precise control over how we render the type (instead of using Show
), implementing a typeclass to do that would be fine. Although I think show is good enough for now.
ac0a82c
to
2a7befe
Compare
|
2a7befe
to
5a84f94
Compare
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.
Minor fixes
@@ -45,6 +45,7 @@ import qualified Cardano.Binary as CBOR | |||
import Cardano.Ledger.Shelley.Scripts () | |||
import Cardano.Ledger.ShelleyMA.TxBody () | |||
|
|||
import Cardano.Api.EraCast |
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.
This should not be exposed to cardano-cli
. Whatever you need should be exposed via Cardano.Api
or Cardano.Api.Shelley
.
|
||
import qualified Cardano.Api as Api |
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.
These modules are in the wrong place
5a84f94
to
d463e01
Compare
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.
Great work @newhoggy
bors r+ |
4135: Transaction build in any era r=newhoggy a=newhoggy Resolves #3909 Co-authored-by: John Ky <[email protected]> Co-authored-by: Jordan Millar <[email protected]>
bors r- |
Canceled. |
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.
…than the current era. This is achieved by adding a new EraCast type class which allows some types such as the UTxO type to change era.
d463e01
to
71072a6
Compare
confirmed to work for buliding alonzo transactions
71072a6
to
cd0d56b
Compare
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.
LGTM! Can you squash the last 4 commits before merging?
cd0d56b
to
af2e359
Compare
Squashed. |
bors r+ |
Build succeeded: |
after IntersectMBO/cardano-node#4135 is fixed.
after IntersectMBO/cardano-node#4135 is fixed.
Resolves #3909 for building Alonzo transactions from Babbage era