Skip to content

Conversation

@ghost
Copy link

@ghost ghost commented Feb 25, 2025

The current blanket implementation of ContextTr prevents users from implementing their custom host, with this PR it is now possible to opt in for the blanket implementation using a marker, it also explicitly trait bounds Host which is mandatory for the current flow to work

@ghost ghost changed the title allow host to be implemented on custom context feat: allow host to be implemented on custom context Feb 25, 2025
@codspeed-hq
Copy link

codspeed-hq bot commented Feb 25, 2025

CodSpeed Performance Report

Merging #2112 will not alter performance

Comparing omer-gen:feat/allow-overriding-instruction-host (5ffa508) with main (5886b9e)

Summary

✅ 8 untouched benchmarks

Copy link
Member

@rakita rakita left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do see that the blanked Host is not a good approach, but imo I would remove Host trait from the repo and directly use ContextTr functions inside instructions.

@ghost
Copy link
Author

ghost commented Feb 25, 2025

i quite liked the fact the interpreter instructions only know the Host interface, but putting it in ContextTr would allow a similar behavior to Handler so it makes sense, ill modify the PR

@ghost ghost requested a review from rakita February 25, 2025 16:02
fn error(&mut self) -> &mut Result<(), <Self::Db as Database>::Error>;
fn tx_journal(&mut self) -> (&mut Self::Tx, &mut Self::Journal);
// default implementationHost calls interface
fn set_error(&mut self, error: <Self::Db as Database>::Error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be better to remove these functions and use old context in places where for example set_error was called.

They are all one line calls, and block_hash as a more complex function is used only in one place

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i have removed set_error which is redundant, not sure i got what you mean in regards to removing the functions, if you mean that interpreter should get the journal itself and set the context error i think it just adds code to the instructions themselves, and imo interpreter shouldn't set the DB error of context so these functions make sense (maybe besides tload tstore which only proxy to journal), personally i like the fact i can hook host calls before they get to the journal by only implementing context, removing these will force me to implement journal which is a lot more work than contextTr

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Host already required ContextTr. In next PR if there is no host i could remove error field from Context and put it inside Interpreter, that error definetely looks strange, and this would allow Interpreter to return Action or Error.

Journal is kinda bloated rn and part of instructions are leaking inside Frame if all of it is contained inside instruction things become simpler.

If this is done you could still intercept journal calls but you would have few fn sstore(..) { self.inner.sstore(..) } lines

@ghost ghost requested a review from rakita February 27, 2025 19:49
@ghost ghost closed this Mar 2, 2025
@rakita
Copy link
Member

rakita commented Mar 3, 2025

hey @omer-gen this is good PR, is it okay for me to merge it and I will do follow up?

@rakita rakita reopened this Mar 3, 2025
@theinterestedr1
Copy link

Yeah feel free to, I submitted it to help, but I couldn't complete the entire change you had in mind all the way through

@rakita
Copy link
Member

rakita commented Mar 3, 2025

Yeah feel free to, I submitted it to help, but I couldn't complete the entire change you had in mind all the way through

That is okay, I can take over. Thanks for contributing!

Copy link
Member

@rakita rakita left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@rakita rakita merged commit dd7d751 into bluealloy:main Mar 3, 2025
55 checks passed
This was referenced Mar 4, 2025
@github-actions github-actions bot mentioned this pull request Mar 10, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants