Hi all, I've made progress.
First off, I'm now somewhat confident that incremental steps can be taken anyway. If I'm right, I think that pretty much puts dead the discussion about what the optimal solution is for now. I've boosted NewTempsExprNode and fixed ticket #124. Testsuite doesn't complain, so I've pushed. PrimaryCmpNode has had changes which could make it leak if everything doesn't work, but it looks ok to me. Some points: a) Now, descendants of NewTempsExprNode has the option to override generate_evaluation_code. If they do that, there's free flexibility about how the temps are allocated, juggled etc. between sub-nodes, in-line with code generation, like the primary goal of this discussion was. The "free_temps" that Stefan wanted is essentially "generate_post_assignment_code", from what I can see. b) Typically, nodes that now implement generate_evaluation_code needs to be hand-converted to the new scheme, by allocating their result (for an example, see PrimaryCmpNode in changeset [1]). c) Nodes that merely override generate_result_code usually converts without pain. d) But non-trivial allocate_temps must be dealt with manually too. (This was the problem with IteratorNode, and I ended up removing a use of a TempNode to make it work, see [2]). [1] http://hg.cython.org/cython-devel/rev/c04479fdbe6d [2] http://hg.cython.org/cython-devel/rev/15459e336874 Some comments for Robert's post: Robert Bradshaw wrote: > I think simply moving everything over to the code generation phase > will be the most beneficial. This will make things much more natural-- > when one needs a temp one can request it right there, use it, and > dispose of it when done. The "generate_disposal_code" paradigm makes > sense to me, but perhaps that's because it's what I'm used to. If > it's just used for temps, I agree the name should change. I like the In ExprNode it is used only for DECREF-ing any result temp, in NewTempExprNode it is also used for releasing temps. > idea of passing in a target (or None) when asking for the result > code, but don't like requiring the parent to do so. It seems to make > more sense to me to have the Node handle (e.g. decref/cleanup) its > own code. All one should need to handle exceptions/function exit > correctly is for the code object (from which one requests temps) to > know which temps are in use in a given block (which are started/ended > by an explicit call in the try node). Basically, the same framework > should work, just transferring from the symbol table to the code object. Return statemens and except blocks were already fixed by Stefan and myself on Thursday. You now need to pass a new manage_ref=True/False to code.funcstate.allocate_temp, and if set to True, the temp will be freed on exceptions and the right returns. (There are important situations where that shouldn't happen -- usecases that the old temp system couldn't handle, but which I've used in the buffer code.) -- Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
