This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author brandtbucher
Recipients Mark.Shannon, brandtbucher, gvanrossum, jmadden, pablogsal
Date 2021-12-17.17:49:47
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1639763387.27.0.135522729655.issue46090@roundup.psfhosted.org>
In-reply-to
Content
I'm going to take a stab at making this work today. The idea is to do something like this when setting a new frame:

- Clear and pop tstate->cframe->current_frame and all of its linked predecessors.
  - These should all belong to the same CFrame, right?
- Push copies of the new InterpreterFrame and all of its predecessors (bottom to top, of course), and update all of the PyFrameObjects to point to the new copies.
  - I'm just going to assert(f->f_owns_frame) before copying each of these (and set it to 0, after). I don't think it could ever be valid to stick a new copy of an active frame onto the top of the stack?
- Set tstate->cframe->current_frame to the new, top InterpreterFrame.
  - If my understanding of the new CFrame mechanics is correct, I don't think we'd need to touch the C stack at all? Maybe I'm missing something, though... if we do need to change the size of the C stack, this whole thing becomes a *lot* more painful.

Anyone see any obvious flaws here? I'm new to a lot of this code, so any guidance would be appreciated.
History
Date User Action Args
2021-12-17 17:49:47brandtbuchersetrecipients: + brandtbucher, gvanrossum, Mark.Shannon, jmadden, pablogsal
2021-12-17 17:49:47brandtbuchersetmessageid: <1639763387.27.0.135522729655.issue46090@roundup.psfhosted.org>
2021-12-17 17:49:47brandtbucherlinkissue46090 messages
2021-12-17 17:49:47brandtbuchercreate