I implemented the 'with gil:' statement, and have added error checking
for nested 'with gil' or 'with nogil' statements. For instance, with
the patch applied Cython wil issue an error when you have e.g.
with nogil:
with nogil:
...
(or the same thing for 'with gil:'). This because nest
On 03/16/2011 11:28 AM, mark florisson wrote:
I implemented the 'with gil:' statement, and have added error checking
for nested 'with gil' or 'with nogil' statements. For instance, with
the patch applied Cython wil issue an error when you have e.g.
with nogil:
with nogil:
...
(or
The PyCharm IDE (http://www.jetbrains.com/pycharm/) has granted the
Cython project a free Open Source license, which means that anyone
developing Cython may freely use PyCharm to develop Cython. They
prefer to license to remain unpublic, so if you develop Cython and
want a free PyCharm license, sen
On 16 March 2011 11:58, Dag Sverre Seljebotn wrote:
> On 03/16/2011 11:28 AM, mark florisson wrote:
>
> I implemented the 'with gil:' statement, and have added error checking
> for nested 'with gil' or 'with nogil' statements. For instance, with
> the patch applied Cython wil issue an error when y
>> Another feedback is that I wonder whether we should put the "gil" and
>> "nogil" psuedo-context managers both in cython namespace, and sort of
>> deprecate the "global" nogil, rather than introduce yet another name that
>> can't be used safely for all kinds of variables.
>
> Hmm, good catch. Act
On 16 March 2011 13:01, mark florisson wrote:
>>> Another feedback is that I wonder whether we should put the "gil" and
>>> "nogil" psuedo-context managers both in cython namespace, and sort of
>>> deprecate the "global" nogil, rather than introduce yet another name that
>>> can't be used safely f
On 03/16/2011 12:54 PM, mark florisson wrote:
On 16 March 2011 11:58, Dag Sverre Seljebotn wrote:
On 03/16/2011 11:28 AM, mark florisson wrote:
I implemented the 'with gil:' statement, and have added error checking
for nested 'with gil' or 'with nogil' statements. For instance, with
the patch
On 16 March 2011 13:37, Dag Sverre Seljebotn wrote:
> On 03/16/2011 12:54 PM, mark florisson wrote:
>>
>> On 16 March 2011 11:58, Dag Sverre Seljebotn
>> wrote:
>>>
>>> On 03/16/2011 11:28 AM, mark florisson wrote:
>>>
>>> I implemented the 'with gil:' statement, and have added error checking
>>>
On 16 March 2011 13:55, mark florisson wrote:
> On 16 March 2011 13:37, Dag Sverre Seljebotn
> wrote:
>> On 03/16/2011 12:54 PM, mark florisson wrote:
>>>
>>> On 16 March 2011 11:58, Dag Sverre Seljebotn
>>> wrote:
On 03/16/2011 11:28 AM, mark florisson wrote:
I implemented
On 03/16/2011 01:55 PM, mark florisson wrote:
On 16 March 2011 13:37, Dag Sverre Seljebotn wrote:
On 03/16/2011 12:54 PM, mark florisson wrote:
On 16 March 2011 11:58, Dag Sverre Seljebotn
wrote:
On 03/16/2011 11:28 AM, mark florisson wrote:
I implemented the 'with gil:' statement, and hav
mark florisson, 16.03.2011 13:28:
On 16 March 2011 13:01, mark florisson wrote:
Another feedback is that I wonder whether we should put the "gil" and
"nogil" psuedo-context managers both in cython namespace, and sort of
deprecate the "global" nogil, rather than introduce yet another name that
ca
Dag Sverre Seljebotn, 16.03.2011 11:58:
On 03/16/2011 11:28 AM, mark florisson wrote:
I implemented the 'with gil:' statement, and have added error checking
for nested 'with gil' or 'with nogil' statements. For instance, with
the patch applied Cython wil issue an error when you have e.g.
with n
Dag Sverre Seljebotn, 16.03.2011 13:37:
On 03/16/2011 12:54 PM, mark florisson wrote:
On 16 March 2011 11:58, Dag Sverre Seljebotn wrote:
I think we should make nested nogil-s noops, i.e.
with nogil:
with nogil: # => if True:
This is because one may want to change "with nogil" to "with gi
mark florisson, 16.03.2011 11:33:
The PyCharm IDE (http://www.jetbrains.com/pycharm/) has granted the
Cython project a free Open Source license, which means that anyone
developing Cython may freely use PyCharm to develop Cython.
Looks like they don't support Cython code, though:
http://youtrac
On 16 March 2011 15:26, Stefan Behnel wrote:
> mark florisson, 16.03.2011 11:33:
>>
>> The PyCharm IDE (http://www.jetbrains.com/pycharm/) has granted the
>> Cython project a free Open Source license, which means that anyone
>> developing Cython may freely use PyCharm to develop Cython.
>
> Looks
On 16 March 2011 15:07, Stefan Behnel wrote:
> mark florisson, 16.03.2011 13:28:
>>
>> On 16 March 2011 13:01, mark florisson wrote:
>
> Another feedback is that I wonder whether we should put the "gil" and
> "nogil" psuedo-context managers both in cython namespace, and sort of
> d
Robert Bradshaw, 11.03.2011 19:33:
On Fri, Mar 11, 2011 at 9:36 AM, Stefan Behnel wrote:
Stefan Behnel, 11.03.2011 15:08:
Vitja Makarov, 11.03.2011 15:04:
2011/3/11 Stefan Behnel:
Personally, I think it would be nice to keep up Python's semantics, but
when
I implemented this I broke quite
Wed, 16 Mar 2011 14:10:29 +0100, Dag Sverre Seljebotn wrote:
> Ah, right. I guess I agree with disallowing nested "with nogil"
> statements for the time being then.
Could you make the inner nested "with nogil" statements no-ops instead,
if the GIL is already released? Does the Cython compiler kee
mark florisson, 16.03.2011 11:28:
I implemented the 'with gil:' statement
[...]
The 'with gil:' statement can now be used in the same way as 'with
nogil:'. Exceptions raised from GIL blocks will be propagated if
possible (i.e., if the return type is 'object'). Otherwise it will
jump to the end of
mark florisson, 16.03.2011 15:29:
On 16 March 2011 15:07, Stefan Behnel wrote:
mark florisson, 16.03.2011 13:28:
On 16 March 2011 13:01, mark florisson wrote:
Another feedback is that I wonder whether we should put the "gil" and
"nogil" psuedo-context managers both in cython namespace, and s
On 03/16/2011 02:17 PM, Pauli Virtanen wrote:
Wed, 16 Mar 2011 14:10:29 +0100, Dag Sverre Seljebotn wrote:
Ah, right. I guess I agree with disallowing nested "with nogil"
statements for the time being then.
Could you make the inner nested "with nogil" statements no-ops instead,
if the GIL is al
On 16 March 2011 16:14, Stefan Behnel wrote:
> mark florisson, 16.03.2011 11:28:
>>
>> I implemented the 'with gil:' statement
>> [...]
>> The 'with gil:' statement can now be used in the same way as 'with
>> nogil:'. Exceptions raised from GIL blocks will be propagated if
>> possible (i.e., if th
>>> Could someone review the patch (which is attached)? Maybe check if I
>>> haven't missed any side cases and such?
>>
>> From a first look, the test file you added seems far too short. I would
>> expect that this feature requires a lot more testing in combination with
>> declared and undeclared l
mark florisson wrote:
I just think it is important for users
to realize that in general, they cannot unblock threads recursively.
I don't think that nested 'with nogil' blocks in any way
suggest that they can. Saying 'with nogil' means "I want
this code executed with the gil released". If it's
On 03/16/2011 01:55 PM, mark florisson wrote:
but it doesn't catch this:
cdef void func() nogil:
with nogil:
pass
with nogil:
func()
I would say that in that case, func() should acquire the
gil on entry so that it can be released in the 'with nogil'
block.
Either that or
Stefan Behnel wrote:
That means that the average
innocent future maintainer could break the code by manually rearranging
the expression in a way that's perfectly valid mathematically,
Another thing is that when the subexpressions concerned
are function arguments, it only works if the order of
Stefan Behnel wrote:
I'm not sure if this is a good idea. "nogil" blocks don't have a way to
handle exceptions, so simply jumping out of them because an inner 'with
gil' block raised an exception can have unexpected side effects.
Seems to me that the __Pyx_WriteUnraisable should be done at
th
On Wed, Mar 16, 2011 at 7:53 AM, Stefan Behnel wrote:
> Robert Bradshaw, 11.03.2011 19:33:
>>
>> On Fri, Mar 11, 2011 at 9:36 AM, Stefan Behnel
>> wrote:
>>>
>>> Stefan Behnel, 11.03.2011 15:08:
Vitja Makarov, 11.03.2011 15:04:
>
> 2011/3/11 Stefan Behnel:
>>
>> Personal
28 matches
Mail list logo
