2010/12/9 Vitja Makarov <[email protected]>:
> 2010/12/9 Robert Bradshaw <[email protected]>:
>> 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
>>
>
> I've created github repo https://github.com/vitek/cython/
>
> And changed __Pyx_Generator to __CyGenerator...
>
> --
> vitja.
>

I've fixed refnanny. Now regr are okay:

----------------------------------------------------------------------
Ran 4058 tests in 1520.368s

FAILED (failures=18, errors=611, skipped=4)

Not that much, genexpr aren't still supported.

Git isn't so bad btw ;)

-- 
vitja.
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev

Reply via email to