Skip to content

Conversation

@kyrias
Copy link

@kyrias kyrias commented Nov 13, 2022

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.

Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
@kyrias kyrias force-pushed the interpreter-limiter branch from f9d0718 to c4b4815 Compare November 13, 2022 13:51
@kyrias
Copy link
Author

kyrias commented Nov 13, 2022

Though thinking about this a bit more, it would probably be nice if the limiter could return more info to the user. The Limiter trait could have an associated type, and then LimiterResult::Halt and RuntimeError::LimiterTriggered could be generic over that.

Copy link
Owner

@vstroebel vstroebel left a 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>,
},
Copy link
Owner

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;
Copy link
Owner

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.

Comment on lines +55 to +59
if let LimiterResult::Halt = self.limiter.execute_op() {
return Err(RuntimeError::LimiterTriggered {
span: span.clone(),
});
}
Copy link
Owner

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>

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