On Thu, Dec 9, 2010 at 2:50 AM, Vitja Makarov <[email protected]> wrote: > 2010/12/9 Robert Bradshaw <[email protected]>: >> On Thu, Dec 9, 2010 at 2:10 AM, Stefan Behnel <[email protected]> wrote: >>> Robert Bradshaw, 09.12.2010 11:00: >>>> On Thu, Dec 9, 2010 at 1:46 AM, Stefan Behnel wrote: >>>>> Vitja Makarov, 08.12.2010 22:45: >>>>>> Please review this patch. It's not yet finished, and mostly doesn't work. >>>>>> But you can take a look at patch and generated code. >>>>> >>>>> *Way* cool, thanks! I'll take a close look ASAP. Please feel free to send >>>>> in a new patch when you have it. If you use hg, you can use "hg bundle" to >>>>> collect commit series. Don't know about git. >>>>> >>>>> BTW, why not set up a github branch for this? >>>> >>>> That's exactly what I was thinking. It'll make it easier to review as >>>> well, and for others to contribute without disturbing the main line. >>> >>> BTW, when this goes in, the next Cython version to release is basically >>> 1.0, right? There are some minor Python compatibility issues left, but >>> that'll be the last major feature, the way I count it. >> >> This will be the last major feature before 1.0, but I don't know that >> the first release this is in should be the 1.0 release. >> >> I also think we should set the compatibility bar a bit higher for 1.0 >> as well--I want a concrete list of all the differences between Python >> X.y and Cython (for un-annotated code) and to be able to say that, if >> you don't count on the behavior in this list (e.g. identity vs >> equality for floating point literals, maybe stack frames) then you >> should be able to compile your code and have it just work, but >> hopefully faster. At the very least, until we at least attempt to make >> such a list, we won't know where we stand (the regression tests >> presumably being somewhat of a starting point, though I'd like to get >> all of them passing (unless they deal with implementation >> details...)). >> >> - Robert >> _______________________________________________ >> Cython-dev mailing list >> [email protected] >> http://codespeak.net/mailman/listinfo/cython-dev >> > >>> - Comprehensions are now handled by OldYieldExprNode >> >>... another one of those bad names. ;) >> >>Any reason you couldn't reuse it for both? > > Didn't yet implemented ;) GenexpNode should be replaced with DefFunc > one that's easy but I want to fix refnanny first. Then fix refcount > leaks. > >>> - I don't know how to make refnanny work, should refnanny context be >>> stored in closure? >> >> Good call. That's a tricky question. >> >> What about generating a GIVEREF for every Python temp you store in the >> closure, a GOTREF for everything you take back out, and finish/restart the >> refnanny context around the yield? > > Yes, that would help. But the main problem is refnanny context > setupcontext defines local variable __pyx_refnanny, we should have one > more macro refnanny_reinitalize_context()
Yes, we'll need to split this up into two macros. This has actually bitten be before, when I was writing the profiler. Did you know that ; all by itself is considered a statement, hence one can't declare variables after it in some strict compilers? >>> BTW, why not set up a github branch for this? >> >> That's exactly what I was thinking. It'll make it easier to review as >> well, and for others to contribute without disturbing the main line. > > Should I fork cython from github? Yes, please do. > Is github insync with hg repo? I've been manually keeping the two in sync--just pushed now. > What is main repo now? It's a DVCS :). Some people have been developing on the git side of things, and some on the hg side of things, and I've been manually syncing the two now and then. Obviously this isn't a long term solution, and I think setting up an automated synchronization both ways would cause more confusion than benefit, so as soon as the buildbot starts looking at github I'll make the hg ones read-only. (Probably worth waiting until after the release to do this.) > ps: I think we should hurry with 1.0 release Yes, I'd like to hurry too, and with all the stuff you're doing it should be soon :). I just think it's important to be able to say "compiles all Python code" rather than "compiles most Python code" and have a (hopefully small) concrete lits of well-delineated caveats. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
