On Sun, Aug 14, 2011 at 8:02 AM, Stefan Behnel wrote:
> Hi,
>
> I've taken another stab at #593 and changed the way decorators are currently
> evaluated.
>
> http://trac.cython.org/cython_trac/ticket/593
>
> https://github.com/cython/cython/commit/c40ff48f84b5e5841e4e2d2c6dcce3e6494e4c25
>
> We pr
Trying to silence compiler warning about taking address of variable
I've found again that when CreateControlFlow is ran lhs entries are
resolved and rhs aren't.
As I understand analyse_declarations() creates scope entries for lhs.
At this point we don't know much about scope name reference belongs
On Tue, Aug 16, 2011 at 3:49 AM, mark florisson
wrote:
> On 16 August 2011 11:39, mark florisson wrote:
>> On 15 August 2011 23:33, Dag Sverre Seljebotn
>> wrote:
>>> Would it be horribly expensive to generate a better runtime error, or even
>>> initialize the gil on demand? If the gil is not in
On 16 August 2011 12:49, mark florisson wrote:
> On 16 August 2011 11:39, mark florisson wrote:
>> On 15 August 2011 23:33, Dag Sverre Seljebotn
>> wrote:
>>> Would it be horribly expensive to generate a better runtime error, or even
>>> initialize the gil on demand? If the gil is not initialize
On 16 August 2011 11:39, mark florisson wrote:
> On 15 August 2011 23:33, Dag Sverre Seljebotn
> wrote:
>> Would it be horribly expensive to generate a better runtime error, or even
>> initialize the gil on demand? If the gil is not initialized, get the thread
>> ID of the thread calling the call
On 15 August 2011 23:33, Dag Sverre Seljebotn
wrote:
> Would it be horribly expensive to generate a better runtime error, or even
> initialize the gil on demand? If the gil is not initialized, get the thread
> ID of the thread calling the callback and check against the thread entering
> at module
On 16 August 2011 07:52, Robert Bradshaw wrote:
> On Mon, Aug 15, 2011 at 2:33 PM, Dag Sverre Seljebotn
> wrote:
>> Would it be horribly expensive to generate a better runtime error, or even
>> initialize the gil on demand? If the gil is not initialized, get the thread
>> ID of the thread calling