>>>>> "CT" == Christian Tismer <tismer at appliedbiometrics.com> writes: [Tim Peters] >> This is clearer in Scheme because its "stack" holds *only* >> control-flow info (bindings follow a chain of static links, >> independent of the current "call stack"), so there's no >> temptation to run off copying bindings too. CT> The Python stack, besides its intermingledness with the machine CT> stack, is basically its chain of frames. The value stack pointer CT> still hides in the machine stack, but that's easy to change. So CT> the real Scheme-like part is this chain, methinks, with the CT> current bytecode offset and value stack info. CT> Making a copy of this in a restartable way means to increase the CT> refcount of all objects in a frame. Would it be correct to undo CT> the effect of fast locals before splitting, and redoing it on CT> activation? Wouldn't it be easier to increase the refcount on the frame object? Then you wouldn't need to worry about the recounts on all the objects in the frame, because they would only be decrefed when the frame is deallocated. It seems like the two other things you would need are some way to get a copy of the current frame and a means to invoke eval_code2 with an already existing stack frame instead of a new one. (This sounds too simple, so it's obviously wrong. I'm just not sure where. Is the problem that you really need a seperate stack/graph to hold the frames? If we leave them on the Python stack, it could be hard to dis-entangle value objects from control objects.) Jeremy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4