2010/12/9 Robert Bradshaw <rober...@math.washington.edu>:
> On Thu, Dec 9, 2010 at 2:50 AM, Vitja Makarov <vitja.maka...@gmail.com> wrote:
>> 2010/12/9 Robert Bradshaw <rober...@math.washington.edu>:
>>> On Thu, Dec 9, 2010 at 2:10 AM, Stefan Behnel <stefan...@behnel.de> 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
>>> Cython-dev@codespeak.net
>>> 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
> Cython-dev@codespeak.net
> http://codespeak.net/mailman/listinfo/cython-dev
>

I've created github repo https://github.com/vitek/cython/

And changed __Pyx_Generator to __CyGenerator...

-- 
vitja.
_______________________________________________
Cython-dev mailing list
Cython-dev@codespeak.net
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to