Keep a stack of frames on the VM.#192
Conversation
cthulahoops
force-pushed
the
framestack
branch
from
6df4739 to
24939b9
Compare
|
|
||
| // Construct frame: | ||
| let mut frame = Frame::new(code.clone(), scope); | ||
| let frame = Frame::new(code.clone(), scope); |
There was a problem hiding this comment.
To solve this mutability issue, I think we need to wrap Frame into a PyRef rather sooner than later. Then we can refer to it from multiple places.
| if let PyObjectKind::Generator { ref mut frame } = gen.borrow_mut().kind { | ||
| frame.push_value(value.clone()); | ||
| match frame.run_frame(vm)? { | ||
| match vm.run_frame(frame.clone())? { |
There was a problem hiding this comment.
Change frame into a PyRef at this point as well.
| pub fn run_frame(&mut self, frame: Frame) -> Result<ExecutionResult, PyObjectRef> { | ||
| let frame = self.ctx.new_frame(frame); | ||
| self.frames.push(frame.clone()); | ||
| let mut frame = objframe::get_value(&frame); |
There was a problem hiding this comment.
Maybe we can seperate the frame into a part that is immutable (like the codeobject) and a part that is mutable (like the current program counter lasti). Or at least give the frame a PyRef to the codeobject.
cthulahoops
force-pushed
the
framestack
branch
from
24939b9 to
ee86229
Compare
| }, | ||
| } | ||
|
|
||
| #[derive(Clone)] |
There was a problem hiding this comment.
It doesn't work though.
I'll guess I'll have to split the frame up somehow so we don't have to keep mutable references to it around.
There was a problem hiding this comment.
Yes, I believe so too, and we should probably use more of the PyObject and PyFrame types, which are references (Rc<RefCell<>>), and we can borrow them mutably or immutably.
2 participants
No description provided.