On Thu, Jun 18, 2009 at 7:29 PM, Ondrej Certik<[email protected]> wrote: > On Tue, Jun 16, 2009 at 11:22 PM, Robert > Bradshaw<[email protected]> wrote: >> On Jun 10, 2009, at 5:45 PM, Ondrej Certik wrote: >> >>> On Wed, Apr 29, 2009 at 4:00 PM, Robert >>> Bradshaw<[email protected]> wrote: >>>> On Apr 29, 2009, at 2:49 PM, Ondrej Certik wrote: >>>> >>>>>>> >>>>>>> Not sure--have you tried without the locals decorator in the >>>>>>> Python >>>>>>> source? I hope this isn't a regression. >>>>>> >>>>>> Yes, as you can see, the locals is commented out. I'll try to >>>>>> bisect >>>>>> it to see which commit broke it. >>>>> >>>>> Ok, so it never worked. I am a bit confused, because I thought the >>>>> pure python mode worked fine for me before. >>>>> >>>>> In the current cython --- is there any way to keep a pure python >>>>> code, >>>>> and create an accompanying pxd file that would annotate the cdef >>>>> functions and classes? >>>> >>>> This should work, that's how I implemented this a long time ago. If >>>> it's not working now it's because something broke (or, I'm not >>>> promising that it's completely bug-free, but it should be good--we >>>> use it to bootstrap Cython itself). >>> >>> So I made it to work by observing how things are done in Cython >>> itself. >>> >>> If you do: >>> >>> git clone git://github.com/certik/cython-test.git >>> cd cython-test >>> cython fact.pyx >>> >>> then it produces nicely optimized fact.c file. However, if you do: >>> >>> cython fact.py >>> >>> it produces a fact.c, that compiles, but it is not optimized --- the >>> "i" and "r" variables are python objects, not ints, even though my >>> fact.pxd file contains: >>> >>> import cython >>> >>> @cython.locals(i=cython.int, r=cython.int) >>> cdef int factorial(int n) >>> >>> >>> Do you see anything wrong with my files? Is this supposed to work? >>> >>> I think it is not implemented yet, because when I looked at the cython >>> sources, it doesn't work there either. This is the relevant part of >>> Scanning.pxd: >>> >>> @cython.locals(current_level=cython.long, new_level=cython.long) >>> cpdef indentation_action(self, text) >>> >>> and here is the declaration in the generated Scanning.c: >>> >>> PyObject *__pyx_v_new_level; >>> >>> >>> And consider for example the following chunk: >>> >>> /* "/home/ondrej/repos/cython-devel/Cython/Compiler/Scanning.py":398 >>> * new_level = len(text) >>> * #print "Changing indent level from", current_level, "to", >>> new_level ### >>> * if new_level == current_level: # <<<<<<<<<<<<<< >>> * return >>> * elif new_level > current_level: >>> */ >>> __pyx_t_4 = PyObject_RichCompare(__pyx_v_new_level, >>> __pyx_v_current_level, Py_EQ); if (unlikely(!__pyx_t_4)) >>> {__pyx_filename = __pyx_f[0]; __pyx_lineno = 398; __pyx_clineno = >>> __LINE__; goto __pyx_L1_error;} >>> __Pyx_GOTREF(__pyx_t_4); >>> __pyx_t_3 = __Pyx_PyObject_IsTrue(__pyx_t_4); if (unlikely(__pyx_t_3 >>> < 0)) {__pyx_filename = __pyx_f[0]; __pyx_lineno = 398; __pyx_clineno >>> = __LINE__; goto __pyx_L1_error;} >>> __Pyx_DECREF(__pyx_t_4); __pyx_t_4 = 0; >>> if (__pyx_t_3) { >>> >>> >>> both the new_level and current_level are declared as long, but above >>> you can see that Cython is calling lots of Python C/API methods... >> >> Looks like a bug to me. >> >> http://trac.cython.org/cython_trac/ticket/330 > > Do you have some idea where the problem is? You wrote "Parsing" in the > ticket. This pure Python mode is very important for me, so I tried to > get it fixed, but I need to invest more time to learn Cython internals > to produce something useful, hopefully over the weekend I'll find time > to dig into it.
Let me know if there is any progress on this one. We are slowly approaching the state with sympy, when I will need this. Or any hints how I could fix this myself. Ondrej _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
