Ecosyste.ms: Timeline
Browse the timeline of events for every public repo on GitHub. Data updated hourly from GH Archive.
ermalkaleci created a review comment on a pull request on paritytech/revive
was removed when I added the check 😅
xermicus created a review comment on a pull request on paritytech/revive
The comment is still valid though, could we leave it in place here?
ermalkaleci created a review comment on a pull request on paritytech/revive
I figured out a way to avoid generating extcodesize
xermicus created a review comment on a pull request on paritytech/revive
Yeah that's fine. A pallet PR for implementing it is already in the pipeline.
ermalkaleci created a review comment on a pull request on paritytech/revive
I had to hardcode code_size since it's not implemented on pallet-revive
xermicus created a review comment on a pull request on paritytech/revive
But by default we should optimize for size here. Storage operations are costly anyways.
xermicus created a review comment on a pull request on paritytech/revive
We will definitively check again when we have 64bit support, gas metering and everything. Also if either one is more efficient in either dimension (code size vs. execution performance), we can just...
xermicus closed an issue on paritytech/revive
Support the `extcodehash` opcode
Needs a supporting API method in the pallet.
xermicus created a review comment on a pull request on paritytech/revive
No, like this: https://github.com/paritytech/revive/blob/main/crates/integration/contracts/Immutables.sol#L37
ermalkaleci created a review comment on a pull request on paritytech/revive
you mean like we do with ext_code_hash? https://github.com/paritytech/revive/blob/cc38c374810f37a6d0a89b46681e944050a8d4d0/crates/integration/src/tests.rs#L238
xermicus created a review comment on a pull request on paritytech/revive
Would you mind using an instantiator contract to test this instead? It will make it a lot more obvious what is going on. And also be much easier to port into the upcoming new test format. The dr...
xermicus created a review comment on a pull request on paritytech/revive
Thinking about it, adding that to the Storage.sol test fixture (reading a nonexistant key and asserting it returns a zero value) wouldn't harm.
ermalkaleci created a comment on a pull request on paritytech/revive
> Very nice catch, thanks! > > So this PR fixes two problems: The storage pointer values should not be truncated to the register size so that arbitrary storage keys work, not just ones that fall...
ermalkaleci created a review comment on a pull request on paritytech/revive
We're currently reversing key on specs to make it work. It may be useful for readability on db side i.e doing query but will add more instructions. So I am not sure we need it
xermicus created a review on a pull request on paritytech/revive
Very nice catch, thanks! So this PR fixes two problems: The storage pointer values should not be truncated to the register size so that arbitrary storage keys work, not just ones that fall below...