-
Notifications
You must be signed in to change notification settings - Fork 1
Add generic interface for conditionally halting the interpreter #1
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
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
f9d0718 to
c4b4815
Compare
|
Though thinking about this a bit more, it would probably be nice if the limiter could return more info to the user. The |
vstroebel
left a comment
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.
Adding more ways to debug the interpreter is a good idea.
IMHO the current way the Limiter is implemented is a little bit too limited 😆
Please see my comments.
| /// The interpreter's configured [`Limiter`][crate::limiters::Limiter] triggered | ||
| LimiterTriggered { | ||
| span: Range<usize>, | ||
| }, |
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.
Adding a message: String to the variant would allow the Limiter to return more useful information
| mod backends; | ||
| mod errors; | ||
| mod ir; | ||
| pub mod limiters; |
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.
As of now all modules are implementation details and all types are explicitly exported.
Please remove the pub and add an explicit export to the pub use lines below.
| if let LimiterResult::Halt = self.limiter.execute_op() { | ||
| return Err(RuntimeError::LimiterTriggered { | ||
| span: span.clone(), | ||
| }); | ||
| } |
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.
Instead of returning LimiterResult it might be better if the limiter returns an Result<(), RuntimeError>.
this would allow the limiter to control the LimiterTriggered error. In addition i think that passing more informations to Limiter::execute_op would be usefull.
Maybe soming like
fn execute_op(&mut self, span: &Range<usize>, op: &Op, heap: &[u8], pointer: usize) -> Result<(), RuntimeError>
I was considering that it might sometimes be useful to get the actual op executed as well, but since those structs aren't public and I don't actually have a need for that right now I decided to skip that.