On Sep 25, 2008, at 3:33 AM, Dag Sverre Seljebotn wrote: > I keep running into issues with making struct buffer access > work :-) As > the temps part of result_code is not moved to generation yet (and that > is a change that perhaps cannot happen very quickly),
I'm hopeful that there is away to move the temps out in an incremental fashion (using a different prefix to avoid conflict). > I get problems > with CloneNode, even if my node is NOT a temp (as it makes it a temp). > > I've tried to wrap my head around InPlaceAssignmentNode for over an > hour > now without making any headway, so I'm prone to instead splitting it > into CInPlaceAssignmentNode and PyInPlaceAssignmentNode in a > transform. > This should get rid of the need for CloneNodes in the C version and > sidestep the issue. What do you think? I don't see how this would help--the CloneNodes are created before analysis of whether or not it is a C operation is performed. It might be easier to simply unwrap the CloneNodes when you detect that it can be done safely and would cause problems. The whole inplace assignment node could probably be re-written using the better temps. > However I am slightly worried: If the result of a buffer lookup cannot > be put in a CloneNode, will other things/obscure usecases suddenly > start > breaking? I.e. *must* CloneNode be fixed before one can make use of > result_code being moved to code generation? > > Robert: > > This applies to your recent changes too. "isinstance(x, y) += 2" is > not > legal, but are there other situations in which an isinstance could be > put in a CloneNode? If so we have a bug already. Perhaps. I think all the CloneNode stuff could go away with better handling of temps (as in your previous email). - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
