On 28 February 2012 21:38, Stefan Behnel wrote:
> mark florisson, 28.02.2012 22:19:
>> On 28 February 2012 21:08, Stefan Behnel wrote:
>>> mark florisson, 28.02.2012 21:20:
On 28 February 2012 19:58, Stefan Behnel wrote:
> mark florisson, 28.02.2012 16:35:
>> Basically, the cleanup co
mark florisson, 28.02.2012 22:19:
> On 28 February 2012 21:08, Stefan Behnel wrote:
>> mark florisson, 28.02.2012 21:20:
>>> On 28 February 2012 19:58, Stefan Behnel wrote:
mark florisson, 28.02.2012 16:35:
> Basically, the cleanup code only needs a matching release because the
> corre
On 28 February 2012 21:22, Stefan Behnel wrote:
> mark florisson, 28.02.2012 22:09:
>> On 28 February 2012 21:08, mark florisson wrote:
>>> On 28 February 2012 20:19, Stefan Behnel wrote:
Stefan Behnel, 28.02.2012 20:58:
> mark florisson, 28.02.2012 16:35:
>> Basically, the cleanup co
mark florisson, 28.02.2012 22:09:
> On 28 February 2012 21:08, mark florisson wrote:
>> On 28 February 2012 20:19, Stefan Behnel wrote:
>>> Stefan Behnel, 28.02.2012 20:58:
mark florisson, 28.02.2012 16:35:
> Basically, the cleanup code only needs a matching release because the
> corre
On 28 February 2012 21:08, Stefan Behnel wrote:
> mark florisson, 28.02.2012 21:20:
>> On 28 February 2012 19:58, Stefan Behnel wrote:
>>> mark florisson, 28.02.2012 16:35:
Basically, the cleanup code only needs a matching release because the
corresponding acquire is in EnsureGILNode, wh
On 28 February 2012 21:08, Stefan Behnel wrote:
> mark florisson, 28.02.2012 21:20:
>> On 28 February 2012 19:58, Stefan Behnel wrote:
>>> mark florisson, 28.02.2012 16:35:
Basically, the cleanup code only needs a matching release because the
corresponding acquire is in EnsureGILNode, wh
On 28 February 2012 21:08, mark florisson wrote:
> On 28 February 2012 20:19, Stefan Behnel wrote:
>> Stefan Behnel, 28.02.2012 20:58:
>>> mark florisson, 28.02.2012 16:35:
Basically, the cleanup code only needs a matching release because the
corresponding acquire is in EnsureGILNode, w
mark florisson, 28.02.2012 21:20:
> On 28 February 2012 19:58, Stefan Behnel wrote:
>> mark florisson, 28.02.2012 16:35:
>>> Basically, the cleanup code only needs a matching release because the
>>> corresponding acquire is in EnsureGILNode, which wraps the function
>>> body in case of a nogil func
On 28 February 2012 20:19, Stefan Behnel wrote:
> Stefan Behnel, 28.02.2012 20:58:
>> mark florisson, 28.02.2012 16:35:
>>> Basically, the cleanup code only needs a matching release because the
>>> corresponding acquire is in EnsureGILNode, which wraps the function
>>> body in case of a nogil func
On 28 February 2012 19:58, Stefan Behnel wrote:
> mark florisson, 28.02.2012 16:35:
>> Basically, the cleanup code only needs a matching release because the
>> corresponding acquire is in EnsureGILNode, which wraps the function
>> body in case of a nogil function with a 'with gil' block. Any chang
Stefan Behnel, 28.02.2012 20:58:
> mark florisson, 28.02.2012 16:35:
>> Basically, the cleanup code only needs a matching release because the
>> corresponding acquire is in EnsureGILNode, which wraps the function
>> body in case of a nogil function with a 'with gil' block. Any changes
>> to the con
mark florisson, 28.02.2012 16:35:
> Basically, the cleanup code only needs a matching release because the
> corresponding acquire is in EnsureGILNode, which wraps the function
> body in case of a nogil function with a 'with gil' block. Any changes
> to the conditions in FuncDefNode will have to be
2012/2/28 Vitja Makarov :
> 2012/2/28 mark florisson :
>> On 28 February 2012 18:57, Vitja Makarov wrote:
>>> 2012/2/28 mark florisson :
On 28 February 2012 18:19, Lisandro Dalcin wrote:
> This is something I really have no idea about how to fix, so I'll ask
> any of you to do it.
>>
mark florisson, 28.02.2012 16:35:
> On 28 February 2012 13:50, Stefan Behnel wrote:
>> mark florisson, 28.02.2012 12:20:
>>> On 28 February 2012 10:53, Stefan Behnel wrote:
mark florisson, 28.02.2012 11:28:
> On 28 February 2012 10:25, Stefan Behnel wrote:
>> mark florisson, 28.02.2012
2012/2/28 mark florisson :
> On 28 February 2012 18:57, Vitja Makarov wrote:
>> 2012/2/28 mark florisson :
>>> On 28 February 2012 18:19, Lisandro Dalcin wrote:
This is something I really have no idea about how to fix, so I'll ask
any of you to do it.
How to reproduce. The qui
On 28 February 2012 18:57, Vitja Makarov wrote:
> 2012/2/28 mark florisson :
>> On 28 February 2012 18:19, Lisandro Dalcin wrote:
>>> This is something I really have no idea about how to fix, so I'll ask
>>> any of you to do it.
>>>
>>> How to reproduce. The quick example below should fail in the
2012/2/28 mark florisson :
> On 28 February 2012 18:19, Lisandro Dalcin wrote:
>> This is something I really have no idea about how to fix, so I'll ask
>> any of you to do it.
>>
>> How to reproduce. The quick example below should fail in the second to
>> last line in test_cinit.py, but it succeed
On 28 February 2012 18:19, Lisandro Dalcin wrote:
> This is something I really have no idea about how to fix, so I'll ask
> any of you to do it.
>
> How to reproduce. The quick example below should fail in the second to
> last line in test_cinit.py, but it succeeds:
>
> $ cat cinit.pyx
> cdef clas
This is something I really have no idea about how to fix, so I'll ask
any of you to do it.
How to reproduce. The quick example below should fail in the second to
last line in test_cinit.py, but it succeeds:
$ cat cinit.pyx
cdef class A:
def __cinit__(self, A a=None):
pass
$ cat test_
On 28 February 2012 13:50, Stefan Behnel wrote:
> mark florisson, 28.02.2012 12:20:
>> On 28 February 2012 10:53, Stefan Behnel wrote:
>>> mark florisson, 28.02.2012 11:28:
On 28 February 2012 10:25, Stefan Behnel wrote:
> mark florisson, 28.02.2012 11:16:
>> On 28 February 2012 09:54
mark florisson, 28.02.2012 12:20:
> On 28 February 2012 10:53, Stefan Behnel wrote:
>> mark florisson, 28.02.2012 11:28:
>>> On 28 February 2012 10:25, Stefan Behnel wrote:
mark florisson, 28.02.2012 11:16:
> On 28 February 2012 09:54, Stefan Behnel wrote:
>> I'm going to reimplement t
On 28 February 2012 10:53, Stefan Behnel wrote:
> mark florisson, 28.02.2012 11:28:
>> On 28 February 2012 10:25, Stefan Behnel wrote:
>>> mark florisson, 28.02.2012 11:16:
On 28 February 2012 09:54, Stefan Behnel wrote:
> I'm going to reimplement this, but not for 0.16 anymore, I'd say.
mark florisson, 28.02.2012 11:28:
> On 28 February 2012 10:25, Stefan Behnel wrote:
>> mark florisson, 28.02.2012 11:16:
>>> On 28 February 2012 09:54, Stefan Behnel wrote:
I'm going to reimplement this, but not for 0.16 anymore, I'd say.
>>>
>>> That's ok, I fixed it to not acquire the GIL se
On 28 February 2012 10:25, Stefan Behnel wrote:
> mark florisson, 28.02.2012 11:16:
>> On 28 February 2012 09:54, Stefan Behnel wrote:
>>> I'm going to reimplement this, but not for 0.16 anymore, I'd say.
>>
>> That's ok, I fixed it to not acquire the GIL seeing that control flow
>> obsoletes None
mark florisson, 28.02.2012 11:16:
> On 28 February 2012 09:54, Stefan Behnel wrote:
>> I'm going to reimplement this, but not for 0.16 anymore, I'd say.
>
> That's ok, I fixed it to not acquire the GIL seeing that control flow
> obsoletes None initialization. So you might as well move it into the
On 28 February 2012 09:54, Stefan Behnel wrote:
> I'm going to reimplement this, but not for 0.16 anymore, I'd say.
That's ok, I fixed it to not acquire the GIL seeing that control flow
obsoletes None initialization. So you might as well move it into the
setup function if you care, the thing is t
I'm going to reimplement this, but not for 0.16 anymore, I'd say.
Original-Message
Betreff: Re: [cython-users] What's up with PyEval_InitThreads() in python 2.7?
Mike Cui, 28.02.2012 10:18:
>> Thanks for the test code, you hadn't mentioned that you use a "with gil"
>> block. Cou
27 matches
Mail list logo
