-
Notifications
You must be signed in to change notification settings - Fork 381
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
pallet-xvm
refactor
#980
pallet-xvm
refactor
#980
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.
I see both pros & cons here.
The pros:
- should make development, testing & integration much easier
- removes lot of the unnecessary code, which was just dragging on for over a year
- clarity
The cons:
- makes everything tightly coupled
We should be able to achieve benchmarking with the old approach too, I guess.
All that being said, IMHO we should focus on the functionality & usability instead of making various abstractions to cover whatever possible future scenarios might require but without even properly implementing support for the 2 VMs we have.
If required, we can always refactor in the future, when we have more knowledge & actually understand the problems of potential future VMs.
Agreed. We need to make a compromise between pragmatism and "design patterns". The previous design could be abstracted further to replace The complexity multi-VMs brings is already quite a mental burden for devs. Personally, I prefer to make the XVM impl dead simple so that everyone can review it easily, without hopping through extra traits, macros, crate features, and runtime configs to understand what is happening. As you mentioned, if more decoupling is required in the future, I'm always ready to refactor it again to fit the needs. |
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.
It's much cleaner and readable than before for sure.
As I state in my previous reviews for pallet_ethereum_checked
, I'm still not comfortable with extra if-else
for serving runtime benchmarks only.
Is there a way to completely keep runtime-benchmarks logic behind a feature gate or something more cleaner? but if that's the only way to do this then it's fine
I did try feature gates, but unfortunately, they either don't work or would make the code difficult to read. One of the main issues is that if the behavior is different under different features, unit tests would fail with some features on. They can be solved with more feature gates added to unit tests, but believe me, you don't want to read that kind of code. I'm happy to update if any doable nice clean solution is suggested. |
/bench shibuya-dev pallet_xvm |
Benchmarks job is scheduled at https://github.com/AstarNetwork/Astar/actions/runs/5667322955. |
Benchmark job failed. |
/bench shibuya-dev pallet_xvm |
Benchmarks job is scheduled at https://github.com/AstarNetwork/Astar/actions/runs/5669003650. |
Benchmarks have been finished. |
/bench shibuya-dev pallet_xvm |
Benchmarks job is scheduled at https://github.com/AstarNetwork/Astar/actions/runs/5679384396. |
Benchmarks have been finished. |
/bench shibuya-dev pallet_xvm |
Benchmarks job is scheduled at https://github.com/AstarNetwork/Astar/actions/runs/5680132481. |
Benchmarks have been finished. |
Minimum allowed line rate is |
Pull Request Summary
Refactor
pallet-xvm
.API (re)design goal:
VmId
to executeIn addition to API design changes, there are some notable improvements:
XvmExecutionResult::UnknownError
is expanded to detailed error codes.Design overview:
Check list