From faltet at pytables.org  Tue Nov  1 11:11:23 2011
From: faltet at pytables.org (Francesc Alted)
Date: Tue, 1 Nov 2011 11:11:23 +0100
Subject: [Cython] Cython 0.16
In-Reply-To: <CANg26EWhkvtLTH-wX89oURsMV_DigavtHk3WuXdz+=XOCYG1dg@mail.gmail.com>
References: <CADiQ+QB28Z566jk_LnRZYw8Op4zfmnF65xYV1W5ME-CVA4Gz5w@mail.gmail.com>
	<CANg26EXNsNsgVWHaDYNKJSsZ2cM905OvumSyok9SCgGeUzd+jw@mail.gmail.com>
	<CADiQ+QB1XyX5Lot7XdRLBboL1vT++z7UEJE49qRK2w0ZfNDoWQ@mail.gmail.com>
	<f3e0ce65-9257-47a9-aedd-68c6a87a956d@email.android.com>
	<CANg26EXDji3grAB8xuvzdnEvSm3JNhuFk=Rz4aabuWi72gt8-w@mail.gmail.com>
	<CANg26EW_c88FCYMEaJFAG5QySMenLmLAJ2qsaxx-GhEFbdyvmg@mail.gmail.com>
	<CANg26EWhkvtLTH-wX89oURsMV_DigavtHk3WuXdz+=XOCYG1dg@mail.gmail.com>
Message-ID: <CAFrp1vo9qaz_1cpuFz+yxGxZEUAKkypnubhyJYyY6aRBbXSkjA@mail.gmail.com>

2011/10/31 mark florisson <markflorisson88 at gmail.com>:
> We can now pass a chunksize argument into prange:
> https://github.com/cython/cython/commit/5c3e77d3c70686fedd5619d7267728fc819b4c60

Cool.  And very well documented too. Thank you!

-- 
Francesc Alted

From markflorisson88 at gmail.com  Thu Nov  3 21:38:41 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Thu, 3 Nov 2011 20:38:41 +0000
Subject: [Cython] Cython 0.16
In-Reply-To: <CAKGHGPRAysWt1vhHRob2ytEQP-y_oMuHuDtq1QPJScjV4YYmsw@mail.gmail.com>
References: <CADiQ+QB28Z566jk_LnRZYw8Op4zfmnF65xYV1W5ME-CVA4Gz5w@mail.gmail.com>
	<CANg26EXNsNsgVWHaDYNKJSsZ2cM905OvumSyok9SCgGeUzd+jw@mail.gmail.com>
	<4EAC12CA.5040200@behnel.de>
	<CAKGHGPRAysWt1vhHRob2ytEQP-y_oMuHuDtq1QPJScjV4YYmsw@mail.gmail.com>
Message-ID: <CANg26EXOr8p1yz24iyLjJy9GWb-RgYxdRSDQFJgy7Cj6GK1BZA@mail.gmail.com>

On 29 October 2011 17:40, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> 2011/10/29 Stefan Behnel <stefan_ml at behnel.de>:
>> mark florisson, 28.10.2011 22:59:
>>>
>>> On 28 October 2011 21:55, Robert Bradshaw wrote:
>>>>
>>>> With Mark's fused types and memory views going in, I think it's about
>>>> time for a new release.
>>
>> Agreed.
>>
>>
>>>> Thoughts?
>>
>> I still haven't investigated the decorator issue that appeared in the Sage
>> tests. I think it's related to decorators on module level def functions,
>> which would suggest that it's best to eventually fix it as part of the
>> function implementation changes that Vitja has started. But there may still
>> be a simpler work-around somewhere that I'm not seeing yet.
>>
>
> Recently I've implemented py3k-super and dynamic default args if we
> have time. I would see this in release also.
>
> Can you please point me to sage decorators related failure?
>
>
>> I basically broke the Sage tests by resolving a bug (593 IIRC), and both
>> don't currently work together. So, a variant would be to revert my changes
>> for 0.16 and just leave the bug in, if that keeps us from breaking existing
>> code for now.
>>
>> But even leaving that out, the Sage tests look seriously broken currently:
>>
>> https://sage.math.washington.edu:8091/hudson/view/All/job/sage-tests/lastCompletedBuild/consoleFull
>>
>>
>>> That'd be cool. However there are a few outstanding issues:
>>> ? ? a) the compiler is somewhat slower (possible solution: lazy utility
>>> codes)
>>> ? ? b) there's a potential memory leak problem for memoryviews with
>>> object dtype that contain themselves, this still needs investigation.
>>>
>>> As for a), Stefan mentioned code spending a lot of time in sub.
>>> Stefan, could you post the code for this that made Cython compile very
>>> slowly?
>>
>> At the time, I just ran cProfile on runtests.py with something like
>> "withstat with_stat" or so as tests - basically all with-statement related
>> ones. It took about 20 seconds or so to build the utility code, just to
>> throw it away unused afterwards. The compile/test run itself then took about
>> 3 seconds.
>>
>
>
> --
> vitja.
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

With Vitja's super() ready and with fused classmethods and
staticmethods ready, I think we're almost ready for a release. I also
supported cdef class static methods (previously it gave compiler
crashes).

I think we should also merge pull requests 'casting to template
pointer' (after a test is added), and probably 'Makefile: rework repo
creation target' (although I haven't looked at it closely). I think
cythonize() is also worth documenting better, as it's a pretty neat
feature that should be more prominent and easier to find for users
(including examples of some of the #distutils directives).

From vitja.makarov at gmail.com  Thu Nov  3 21:42:15 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Fri, 4 Nov 2011 00:42:15 +0400
Subject: [Cython] Cython 0.16
In-Reply-To: <CANg26EXOr8p1yz24iyLjJy9GWb-RgYxdRSDQFJgy7Cj6GK1BZA@mail.gmail.com>
References: <CADiQ+QB28Z566jk_LnRZYw8Op4zfmnF65xYV1W5ME-CVA4Gz5w@mail.gmail.com>
	<CANg26EXNsNsgVWHaDYNKJSsZ2cM905OvumSyok9SCgGeUzd+jw@mail.gmail.com>
	<4EAC12CA.5040200@behnel.de>
	<CAKGHGPRAysWt1vhHRob2ytEQP-y_oMuHuDtq1QPJScjV4YYmsw@mail.gmail.com>
	<CANg26EXOr8p1yz24iyLjJy9GWb-RgYxdRSDQFJgy7Cj6GK1BZA@mail.gmail.com>
Message-ID: <CAKGHGPSvvCeYHK31nNiCLPhaHPJ3NyNd2=SRoWCu19Nks_6wuw@mail.gmail.com>

2011/11/4 mark florisson <markflorisson88 at gmail.com>:
> On 29 October 2011 17:40, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>> 2011/10/29 Stefan Behnel <stefan_ml at behnel.de>:
>>> mark florisson, 28.10.2011 22:59:
>>>>
>>>> On 28 October 2011 21:55, Robert Bradshaw wrote:
>>>>>
>>>>> With Mark's fused types and memory views going in, I think it's about
>>>>> time for a new release.
>>>
>>> Agreed.
>>>
>>>
>>>>> Thoughts?
>>>
>>> I still haven't investigated the decorator issue that appeared in the Sage
>>> tests. I think it's related to decorators on module level def functions,
>>> which would suggest that it's best to eventually fix it as part of the
>>> function implementation changes that Vitja has started. But there may still
>>> be a simpler work-around somewhere that I'm not seeing yet.
>>>
>>
>> Recently I've implemented py3k-super and dynamic default args if we
>> have time. I would see this in release also.
>>
>> Can you please point me to sage decorators related failure?
>>
>>
>>> I basically broke the Sage tests by resolving a bug (593 IIRC), and both
>>> don't currently work together. So, a variant would be to revert my changes
>>> for 0.16 and just leave the bug in, if that keeps us from breaking existing
>>> code for now.
>>>
>>> But even leaving that out, the Sage tests look seriously broken currently:
>>>
>>> https://sage.math.washington.edu:8091/hudson/view/All/job/sage-tests/lastCompletedBuild/consoleFull
>>>
>>>
>>>> That'd be cool. However there are a few outstanding issues:
>>>> ? ? a) the compiler is somewhat slower (possible solution: lazy utility
>>>> codes)
>>>> ? ? b) there's a potential memory leak problem for memoryviews with
>>>> object dtype that contain themselves, this still needs investigation.
>>>>
>>>> As for a), Stefan mentioned code spending a lot of time in sub.
>>>> Stefan, could you post the code for this that made Cython compile very
>>>> slowly?
>>>
>>> At the time, I just ran cProfile on runtests.py with something like
>>> "withstat with_stat" or so as tests - basically all with-statement related
>>> ones. It took about 20 seconds or so to build the utility code, just to
>>> throw it away unused afterwards. The compile/test run itself then took about
>>> 3 seconds.
>>>
>>
>>
>> --
>> vitja.
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel at python.org
>> http://mail.python.org/mailman/listinfo/cython-devel
>>
>
> With Vitja's super() ready and with fused classmethods and
> staticmethods ready, I think we're almost ready for a release. I also
> supported cdef class static methods (previously it gave compiler
> crashes).
>

That's nice. I've also implemented support for dynamic default args

http://trac.cython.org/cython_trac/ticket/674

I think it could be merged either.

> I think we should also merge pull requests 'casting to template
> pointer' (after a test is added), and probably 'Makefile: rework repo
> creation target' (although I haven't looked at it closely). I think
> cythonize() is also worth documenting better, as it's a pretty neat
> feature that should be more prominent and easier to find for users
> (including examples of some of the #distutils directives).
>



-- 
vitja.

From stefan_ml at behnel.de  Thu Nov  3 22:26:47 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 03 Nov 2011 22:26:47 +0100
Subject: [Cython] Cython 0.16
In-Reply-To: <CAKGHGPSvvCeYHK31nNiCLPhaHPJ3NyNd2=SRoWCu19Nks_6wuw@mail.gmail.com>
References: <CADiQ+QB28Z566jk_LnRZYw8Op4zfmnF65xYV1W5ME-CVA4Gz5w@mail.gmail.com>	<CANg26EXNsNsgVWHaDYNKJSsZ2cM905OvumSyok9SCgGeUzd+jw@mail.gmail.com>	<4EAC12CA.5040200@behnel.de>	<CAKGHGPRAysWt1vhHRob2ytEQP-y_oMuHuDtq1QPJScjV4YYmsw@mail.gmail.com>	<CANg26EXOr8p1yz24iyLjJy9GWb-RgYxdRSDQFJgy7Cj6GK1BZA@mail.gmail.com>
	<CAKGHGPSvvCeYHK31nNiCLPhaHPJ3NyNd2=SRoWCu19Nks_6wuw@mail.gmail.com>
Message-ID: <4EB30717.307@behnel.de>

Vitja Makarov, 03.11.2011 21:42:
> 2011/11/4 mark florisson:
>> With Vitja's super() ready and with fused classmethods and
>> staticmethods ready, I think we're almost ready for a release. I also
>> supported cdef class static methods (previously it gave compiler
>> crashes).
>
> That's nice. I've also implemented support for dynamic default args
>
> http://trac.cython.org/cython_trac/ticket/674
>
> I think it could be merged either.
>
>> I think we should also merge pull requests 'casting to template
>> pointer' (after a test is added), and probably 'Makefile: rework repo
>> creation target' (although I haven't looked at it closely). I think
>> cythonize() is also worth documenting better, as it's a pretty neat
>> feature that should be more prominent and easier to find for users
>> (including examples of some of the #distutils directives).

That's a great list of improvements!

The one problem with cythonize() is that it doesn't (yet) have a good way 
of defining additional build options, e.g. required libraries etc. for an 
extension. Those should be keyword arguments of some sort, maybe just 
passed through into the Extension class constructor.

Stefan

From markflorisson88 at gmail.com  Fri Nov  4 09:33:11 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Fri, 4 Nov 2011 08:33:11 +0000
Subject: [Cython] Cython 0.16
In-Reply-To: <CAKGHGPSvvCeYHK31nNiCLPhaHPJ3NyNd2=SRoWCu19Nks_6wuw@mail.gmail.com>
References: <CADiQ+QB28Z566jk_LnRZYw8Op4zfmnF65xYV1W5ME-CVA4Gz5w@mail.gmail.com>
	<CANg26EXNsNsgVWHaDYNKJSsZ2cM905OvumSyok9SCgGeUzd+jw@mail.gmail.com>
	<4EAC12CA.5040200@behnel.de>
	<CAKGHGPRAysWt1vhHRob2ytEQP-y_oMuHuDtq1QPJScjV4YYmsw@mail.gmail.com>
	<CANg26EXOr8p1yz24iyLjJy9GWb-RgYxdRSDQFJgy7Cj6GK1BZA@mail.gmail.com>
	<CAKGHGPSvvCeYHK31nNiCLPhaHPJ3NyNd2=SRoWCu19Nks_6wuw@mail.gmail.com>
Message-ID: <CANg26EW46qKx1HQ8vhbgrwnyX6JcCYJ9r2o7z-MMg=81=WotcA@mail.gmail.com>

On 3 November 2011 20:42, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> 2011/11/4 mark florisson <markflorisson88 at gmail.com>:
>> On 29 October 2011 17:40, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>> 2011/10/29 Stefan Behnel <stefan_ml at behnel.de>:
>>>> mark florisson, 28.10.2011 22:59:
>>>>>
>>>>> On 28 October 2011 21:55, Robert Bradshaw wrote:
>>>>>>
>>>>>> With Mark's fused types and memory views going in, I think it's about
>>>>>> time for a new release.
>>>>
>>>> Agreed.
>>>>
>>>>
>>>>>> Thoughts?
>>>>
>>>> I still haven't investigated the decorator issue that appeared in the Sage
>>>> tests. I think it's related to decorators on module level def functions,
>>>> which would suggest that it's best to eventually fix it as part of the
>>>> function implementation changes that Vitja has started. But there may still
>>>> be a simpler work-around somewhere that I'm not seeing yet.
>>>>
>>>
>>> Recently I've implemented py3k-super and dynamic default args if we
>>> have time. I would see this in release also.
>>>
>>> Can you please point me to sage decorators related failure?
>>>
>>>
>>>> I basically broke the Sage tests by resolving a bug (593 IIRC), and both
>>>> don't currently work together. So, a variant would be to revert my changes
>>>> for 0.16 and just leave the bug in, if that keeps us from breaking existing
>>>> code for now.
>>>>
>>>> But even leaving that out, the Sage tests look seriously broken currently:
>>>>
>>>> https://sage.math.washington.edu:8091/hudson/view/All/job/sage-tests/lastCompletedBuild/consoleFull
>>>>
>>>>
>>>>> That'd be cool. However there are a few outstanding issues:
>>>>> ? ? a) the compiler is somewhat slower (possible solution: lazy utility
>>>>> codes)
>>>>> ? ? b) there's a potential memory leak problem for memoryviews with
>>>>> object dtype that contain themselves, this still needs investigation.
>>>>>
>>>>> As for a), Stefan mentioned code spending a lot of time in sub.
>>>>> Stefan, could you post the code for this that made Cython compile very
>>>>> slowly?
>>>>
>>>> At the time, I just ran cProfile on runtests.py with something like
>>>> "withstat with_stat" or so as tests - basically all with-statement related
>>>> ones. It took about 20 seconds or so to build the utility code, just to
>>>> throw it away unused afterwards. The compile/test run itself then took about
>>>> 3 seconds.
>>>>
>>>
>>>
>>> --
>>> vitja.
>>> _______________________________________________
>>> cython-devel mailing list
>>> cython-devel at python.org
>>> http://mail.python.org/mailman/listinfo/cython-devel
>>>
>>
>> With Vitja's super() ready and with fused classmethods and
>> staticmethods ready, I think we're almost ready for a release. I also
>> supported cdef class static methods (previously it gave compiler
>> crashes).
>>
>
> That's nice. I've also implemented support for dynamic default args
>
> http://trac.cython.org/cython_trac/ticket/674
>
> I think it could be merged either.

That's great, because it's a nasty bug. I see no pull request for that
though, although I see it in one of your branches. Is it ready?

>> I think we should also merge pull requests 'casting to template
>> pointer' (after a test is added), and probably 'Makefile: rework repo
>> creation target' (although I haven't looked at it closely). I think
>> cythonize() is also worth documenting better, as it's a pretty neat
>> feature that should be more prominent and easier to find for users
>> (including examples of some of the #distutils directives).
>>
>
>
>
> --
> vitja.
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

From markflorisson88 at gmail.com  Fri Nov  4 09:33:24 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Fri, 4 Nov 2011 08:33:24 +0000
Subject: [Cython] Cython 0.16
In-Reply-To: <4EB30717.307@behnel.de>
References: <CADiQ+QB28Z566jk_LnRZYw8Op4zfmnF65xYV1W5ME-CVA4Gz5w@mail.gmail.com>
	<CANg26EXNsNsgVWHaDYNKJSsZ2cM905OvumSyok9SCgGeUzd+jw@mail.gmail.com>
	<4EAC12CA.5040200@behnel.de>
	<CAKGHGPRAysWt1vhHRob2ytEQP-y_oMuHuDtq1QPJScjV4YYmsw@mail.gmail.com>
	<CANg26EXOr8p1yz24iyLjJy9GWb-RgYxdRSDQFJgy7Cj6GK1BZA@mail.gmail.com>
	<CAKGHGPSvvCeYHK31nNiCLPhaHPJ3NyNd2=SRoWCu19Nks_6wuw@mail.gmail.com>
	<4EB30717.307@behnel.de>
Message-ID: <CANg26EUVqz04D7FhxanRudi_6YuQVGawLq8VB=obH7hrs9xdCw@mail.gmail.com>

On 3 November 2011 21:26, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Vitja Makarov, 03.11.2011 21:42:
>>
>> 2011/11/4 mark florisson:
>>>
>>> With Vitja's super() ready and with fused classmethods and
>>> staticmethods ready, I think we're almost ready for a release. I also
>>> supported cdef class static methods (previously it gave compiler
>>> crashes).
>>
>> That's nice. I've also implemented support for dynamic default args
>>
>> http://trac.cython.org/cython_trac/ticket/674
>>
>> I think it could be merged either.
>>
>>> I think we should also merge pull requests 'casting to template
>>> pointer' (after a test is added), and probably 'Makefile: rework repo
>>> creation target' (although I haven't looked at it closely). I think
>>> cythonize() is also worth documenting better, as it's a pretty neat
>>> feature that should be more prominent and easier to find for users
>>> (including examples of some of the #distutils directives).
>
> That's a great list of improvements!
>
> The one problem with cythonize() is that it doesn't (yet) have a good way of
> defining additional build options, e.g. required libraries etc. for an
> extension. Those should be keyword arguments of some sort, maybe just passed
> through into the Extension class constructor.

That's what we have the directives for, i.e. you say '# distutils:
libraries = spam eggs' in your module.

> Stefan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

From vitja.makarov at gmail.com  Fri Nov  4 09:58:38 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Fri, 4 Nov 2011 12:58:38 +0400
Subject: [Cython] Cython 0.16
In-Reply-To: <CANg26EW46qKx1HQ8vhbgrwnyX6JcCYJ9r2o7z-MMg=81=WotcA@mail.gmail.com>
References: <CADiQ+QB28Z566jk_LnRZYw8Op4zfmnF65xYV1W5ME-CVA4Gz5w@mail.gmail.com>
	<CANg26EXNsNsgVWHaDYNKJSsZ2cM905OvumSyok9SCgGeUzd+jw@mail.gmail.com>
	<4EAC12CA.5040200@behnel.de>
	<CAKGHGPRAysWt1vhHRob2ytEQP-y_oMuHuDtq1QPJScjV4YYmsw@mail.gmail.com>
	<CANg26EXOr8p1yz24iyLjJy9GWb-RgYxdRSDQFJgy7Cj6GK1BZA@mail.gmail.com>
	<CAKGHGPSvvCeYHK31nNiCLPhaHPJ3NyNd2=SRoWCu19Nks_6wuw@mail.gmail.com>
	<CANg26EW46qKx1HQ8vhbgrwnyX6JcCYJ9r2o7z-MMg=81=WotcA@mail.gmail.com>
Message-ID: <CAKGHGPS-wDap66DZzoR-ZdUxstiOaLv3oh+ex5fXmYrTGwKBag@mail.gmail.com>

2011/11/4 mark florisson <markflorisson88 at gmail.com>:
>>
>> That's nice. I've also implemented support for dynamic default args
>>
>> http://trac.cython.org/cython_trac/ticket/674
>>
>> I think it could be merged either.
>
> That's great, because it's a nasty bug. I see no pull request for that
> though, although I see it in one of your branches. Is it ready?
>

Yeah, you can find it here:

https://github.com/vitek/cython/commit/175c8994ead619ce8425de8fed96ffa9adb18a88

Btw, it needs to be cleaned. Now it packs default args in C struct this way:

struct defaults {
    PyObject *objects[N];
    int int_arg; // C type args here
    ...
}

So perhaps it would be better to pack that into PyObject so it would
be easier to copy default args when creating fused functions.

-- 
vitja.

From markflorisson88 at gmail.com  Fri Nov  4 12:17:02 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Fri, 4 Nov 2011 11:17:02 +0000
Subject: [Cython] Cython 0.16
In-Reply-To: <CAKGHGPS-wDap66DZzoR-ZdUxstiOaLv3oh+ex5fXmYrTGwKBag@mail.gmail.com>
References: <CADiQ+QB28Z566jk_LnRZYw8Op4zfmnF65xYV1W5ME-CVA4Gz5w@mail.gmail.com>
	<CANg26EXNsNsgVWHaDYNKJSsZ2cM905OvumSyok9SCgGeUzd+jw@mail.gmail.com>
	<4EAC12CA.5040200@behnel.de>
	<CAKGHGPRAysWt1vhHRob2ytEQP-y_oMuHuDtq1QPJScjV4YYmsw@mail.gmail.com>
	<CANg26EXOr8p1yz24iyLjJy9GWb-RgYxdRSDQFJgy7Cj6GK1BZA@mail.gmail.com>
	<CAKGHGPSvvCeYHK31nNiCLPhaHPJ3NyNd2=SRoWCu19Nks_6wuw@mail.gmail.com>
	<CANg26EW46qKx1HQ8vhbgrwnyX6JcCYJ9r2o7z-MMg=81=WotcA@mail.gmail.com>
	<CAKGHGPS-wDap66DZzoR-ZdUxstiOaLv3oh+ex5fXmYrTGwKBag@mail.gmail.com>
Message-ID: <CANg26EW65S=rhNfBc2fSxm=h8Xum__54SenW9G7fMz9kcDwr=g@mail.gmail.com>

On 4 November 2011 08:58, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> 2011/11/4 mark florisson <markflorisson88 at gmail.com>:
>>>
>>> That's nice. I've also implemented support for dynamic default args
>>>
>>> http://trac.cython.org/cython_trac/ticket/674
>>>
>>> I think it could be merged either.
>>
>> That's great, because it's a nasty bug. I see no pull request for that
>> though, although I see it in one of your branches. Is it ready?
>>
>
> Yeah, you can find it here:
>
> https://github.com/vitek/cython/commit/175c8994ead619ce8425de8fed96ffa9adb18a88
>
> Btw, it needs to be cleaned. Now it packs default args in C struct this way:
>
> struct defaults {
> ? ?PyObject *objects[N];
> ? ?int int_arg; // C type args here
> ? ?...
> }
>
> So perhaps it would be better to pack that into PyObject so it would
> be easier to copy default args when creating fused functions.

I don't think we need dynamic default arguments for fused functions
(yet), as fused closures are not supported. But if we want those in
the future (I don't think we should necessarily support them,
especially if you nest fused functions in fused functions you get code
explosion) and if it works for CyFunction, it should work for
FusedFunction if it simply mangles the struct names. I don't think you
should worry about it.

> --
> vitja.
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

From vitja.makarov at gmail.com  Sun Nov  6 18:10:53 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Sun, 6 Nov 2011 21:10:53 +0400
Subject: [Cython] File encoding issue
Message-ID: <CAKGHGPQettZ3YaB8q=Yz7U=0ofqeCVDiR2EGssCc8yN+nfVuMw@mail.gmail.com>

When file encoding is specified cython generates two PyObject entries
for string consts one for the variable name and one for the string
constant.

Here is ticket: http://trac.cython.org/cython_trac/ticket/740

At the first time I thought that this is C++ related bug. Now I
realise that C doesn't complains about.

Here is minimal example:
$ cat cplus.pyx
# -*- coding: koi8-r -*-
wtf = 'wtf'

Generaets the following code:

/* Implementation of 'cplus' */
static char __pyx_k__wtf[] = "wtf";
static char __pyx_k____main__[] = "__main__";
static char __pyx_k____test__[] = "__test__";
static PyObject *__pyx_n_s____main__;
static PyObject *__pyx_n_s____test__;
static PyObject *__pyx_n_s__wtf;
static PyObject *__pyx_n_s__wtf;

...

static __Pyx_StringTabEntry __pyx_string_tab[] = {
  {&__pyx_n_s____main__, __pyx_k____main__, sizeof(__pyx_k____main__),
0, 0, 1, 1},
  {&__pyx_n_s____test__, __pyx_k____test__, sizeof(__pyx_k____test__),
0, 0, 1, 1},
  {&__pyx_n_s__wtf, __pyx_k__wtf, sizeof(__pyx_k__wtf), "koi8-r", 0, 1, 1},
  {&__pyx_n_s__wtf, __pyx_k__wtf, sizeof(__pyx_k__wtf), 0, 0, 1, 1},
  {0, 0, 0, 0, 0, 0, 0}
};

-- 
vitja.

From stefan_ml at behnel.de  Sun Nov  6 18:33:39 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 06 Nov 2011 18:33:39 +0100
Subject: [Cython] File encoding issue
In-Reply-To: <CAKGHGPQettZ3YaB8q=Yz7U=0ofqeCVDiR2EGssCc8yN+nfVuMw@mail.gmail.com>
References: <CAKGHGPQettZ3YaB8q=Yz7U=0ofqeCVDiR2EGssCc8yN+nfVuMw@mail.gmail.com>
Message-ID: <4EB6C4F3.3020201@behnel.de>

Vitja Makarov, 06.11.2011 18:10:
> When file encoding is specified cython generates two PyObject entries
> for string consts one for the variable name and one for the string
> constant.

That's because the content may actually become different after decoding, 
even if the encoded byte sequence is identical. Note that decoding is only 
done in Py3. In Py2, the byte sequence is used, so both values are identical.


> Here is ticket: http://trac.cython.org/cython_trac/ticket/740
>
> At the first time I thought that this is C++ related bug. Now I
> realise that C doesn't complains about.

I bet there's the usual "yes, please really tell me what I'm doing wrong" 
compiler option for that. "-Werrors" may do the trick at least.


> Here is minimal example:
> $ cat cplus.pyx
> # -*- coding: koi8-r -*-
> wtf = 'wtf'
>
> Generaets the following code:
>
> /* Implementation of 'cplus' */
> static char __pyx_k__wtf[] = "wtf";
> static char __pyx_k____main__[] = "__main__";
> static char __pyx_k____test__[] = "__test__";
> static PyObject *__pyx_n_s____main__;
> static PyObject *__pyx_n_s____test__;
> static PyObject *__pyx_n_s__wtf;
> static PyObject *__pyx_n_s__wtf;
>
> ...
>
> static __Pyx_StringTabEntry __pyx_string_tab[] = {
>    {&__pyx_n_s____main__, __pyx_k____main__, sizeof(__pyx_k____main__),
> 0, 0, 1, 1},
>    {&__pyx_n_s____test__, __pyx_k____test__, sizeof(__pyx_k____test__),
> 0, 0, 1, 1},
>    {&__pyx_n_s__wtf, __pyx_k__wtf, sizeof(__pyx_k__wtf), "koi8-r", 0, 1, 1},
>    {&__pyx_n_s__wtf, __pyx_k__wtf, sizeof(__pyx_k__wtf), 0, 0, 1, 1},
>    {0, 0, 0, 0, 0, 0, 0}
> };

Both Python object variables should have different cnames.

Stefan

From vitja.makarov at gmail.com  Mon Nov  7 19:28:51 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Mon, 7 Nov 2011 22:28:51 +0400
Subject: [Cython] File encoding issue
In-Reply-To: <4EB6C4F3.3020201@behnel.de>
References: <CAKGHGPQettZ3YaB8q=Yz7U=0ofqeCVDiR2EGssCc8yN+nfVuMw@mail.gmail.com>
	<4EB6C4F3.3020201@behnel.de>
Message-ID: <CAKGHGPRj-fj+m3wje=C7DWH62b7NTuDFsJq+muFDDFvD7FNKpA@mail.gmail.com>

2011/11/6 Stefan Behnel <stefan_ml at behnel.de>:
> Vitja Makarov, 06.11.2011 18:10:
>>
>> When file encoding is specified cython generates two PyObject entries
>> for string consts one for the variable name and one for the string
>> constant.
>
> That's because the content may actually become different after decoding,
> even if the encoded byte sequence is identical. Note that decoding is only
> done in Py3. In Py2, the byte sequence is used, so both values are
> identical.
>

If they are the identical after decoding isn't it better to have only
one of them?

>
>> Here is ticket: http://trac.cython.org/cython_trac/ticket/740
>>
>> At the first time I thought that this is C++ related bug. Now I
>> realise that C doesn't complains about.
>
> I bet there's the usual "yes, please really tell me what I'm doing wrong"
> compiler option for that. "-Werrors" may do the trick at least.
>

Totally ;)

>
>> Here is minimal example:
>> $ cat cplus.pyx
>> # -*- coding: koi8-r -*-
>> wtf = 'wtf'
>>
>> Generaets the following code:
>>
>> /* Implementation of 'cplus' */
>> static char __pyx_k__wtf[] = "wtf";
>> static char __pyx_k____main__[] = "__main__";
>> static char __pyx_k____test__[] = "__test__";
>> static PyObject *__pyx_n_s____main__;
>> static PyObject *__pyx_n_s____test__;
>> static PyObject *__pyx_n_s__wtf;
>> static PyObject *__pyx_n_s__wtf;
>>
>> ...
>>
>> static __Pyx_StringTabEntry __pyx_string_tab[] = {
>> ? {&__pyx_n_s____main__, __pyx_k____main__, sizeof(__pyx_k____main__),
>> 0, 0, 1, 1},
>> ? {&__pyx_n_s____test__, __pyx_k____test__, sizeof(__pyx_k____test__),
>> 0, 0, 1, 1},
>> ? {&__pyx_n_s__wtf, __pyx_k__wtf, sizeof(__pyx_k__wtf), "koi8-r", 0, 1,
>> 1},
>> ? {&__pyx_n_s__wtf, __pyx_k__wtf, sizeof(__pyx_k__wtf), 0, 0, 1, 1},
>> ? {0, 0, 0, 0, 0, 0, 0}
>> };
>
> Both Python object variables should have different cnames.
>

What's about adding encoding suffix?

-- 
vitja.

From stefan_ml at behnel.de  Mon Nov  7 19:53:43 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 07 Nov 2011 19:53:43 +0100
Subject: [Cython] File encoding issue
In-Reply-To: <CAKGHGPRj-fj+m3wje=C7DWH62b7NTuDFsJq+muFDDFvD7FNKpA@mail.gmail.com>
References: <CAKGHGPQettZ3YaB8q=Yz7U=0ofqeCVDiR2EGssCc8yN+nfVuMw@mail.gmail.com>	<4EB6C4F3.3020201@behnel.de>
	<CAKGHGPRj-fj+m3wje=C7DWH62b7NTuDFsJq+muFDDFvD7FNKpA@mail.gmail.com>
Message-ID: <4EB82937.2020403@behnel.de>

Vitja Makarov, 07.11.2011 19:28:
> 2011/11/6 Stefan Behnel:
>> Vitja Makarov, 06.11.2011 18:10:
>>>
>>> When file encoding is specified cython generates two PyObject entries
>>> for string consts one for the variable name and one for the string
>>> constant.
>>
>> That's because the content may actually become different after decoding,
>> even if the encoded byte sequence is identical. Note that decoding is only
>> done in Py3. In Py2, the byte sequence is used, so both values are
>> identical.
>
> If they are the identical after decoding isn't it better to have only
> one of them?

Well, yes. That's not trivial, though, because the decision is taken at C 
compile time. And the benefit tends to be negligible, because this case is 
really rare and the affected strings tend to be quite short.


>>> Here is minimal example:
>>> $ cat cplus.pyx
>>> # -*- coding: koi8-r -*-
>>> wtf = 'wtf'
>>>
>>> Generaets the following code:
>>>
>>> /* Implementation of 'cplus' */
>>> static char __pyx_k__wtf[] = "wtf";
>>> static char __pyx_k____main__[] = "__main__";
>>> static char __pyx_k____test__[] = "__test__";
>>> static PyObject *__pyx_n_s____main__;
>>> static PyObject *__pyx_n_s____test__;
>>> static PyObject *__pyx_n_s__wtf;
>>> static PyObject *__pyx_n_s__wtf;
>>>
>>> ...
>>>
>>> static __Pyx_StringTabEntry __pyx_string_tab[] = {
>>>    {&__pyx_n_s____main__, __pyx_k____main__, sizeof(__pyx_k____main__),
>>> 0, 0, 1, 1},
>>>    {&__pyx_n_s____test__, __pyx_k____test__, sizeof(__pyx_k____test__),
>>> 0, 0, 1, 1},
>>>    {&__pyx_n_s__wtf, __pyx_k__wtf, sizeof(__pyx_k__wtf), "koi8-r", 0, 1,
>>> 1},
>>>    {&__pyx_n_s__wtf, __pyx_k__wtf, sizeof(__pyx_k__wtf), 0, 0, 1, 1},
>>>    {0, 0, 0, 0, 0, 0, 0}
>>> };
>>
>> Both Python object variables should have different cnames.
>
> What's about adding encoding suffix?

Yes, I think that would fix it, although it could be a bit misleading when 
reading the C code with a Py3 context in mind. But using a counter doesn't 
make it very readable, either.

Stefan

From vitja.makarov at gmail.com  Mon Nov  7 20:44:32 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Mon, 7 Nov 2011 23:44:32 +0400
Subject: [Cython] File encoding issue
In-Reply-To: <4EB82937.2020403@behnel.de>
References: <CAKGHGPQettZ3YaB8q=Yz7U=0ofqeCVDiR2EGssCc8yN+nfVuMw@mail.gmail.com>
	<4EB6C4F3.3020201@behnel.de>
	<CAKGHGPRj-fj+m3wje=C7DWH62b7NTuDFsJq+muFDDFvD7FNKpA@mail.gmail.com>
	<4EB82937.2020403@behnel.de>
Message-ID: <CAKGHGPSUkBvKvg2OAOwbSRZMY=yDmXkaLEfhJA4cM1s2B3LarQ@mail.gmail.com>

2011/11/7 Stefan Behnel <stefan_ml at behnel.de>:
> Vitja Makarov, 07.11.2011 19:28:
>>
>> 2011/11/6 Stefan Behnel:
>>>
>>> Vitja Makarov, 06.11.2011 18:10:
>>>>
>>>> When file encoding is specified cython generates two PyObject entries
>>>> for string consts one for the variable name and one for the string
>>>> constant.
>>>
>>> That's because the content may actually become different after decoding,
>>> even if the encoded byte sequence is identical. Note that decoding is
>>> only
>>> done in Py3. In Py2, the byte sequence is used, so both values are
>>> identical.
>>
>> If they are the identical after decoding isn't it better to have only
>> one of them?
>
> Well, yes. That's not trivial, though, because the decision is taken at C
> compile time. And the benefit tends to be negligible, because this case is
> really rare and the affected strings tend to be quite short.
>
>
>>>> Here is minimal example:
>>>> $ cat cplus.pyx
>>>> # -*- coding: koi8-r -*-
>>>> wtf = 'wtf'
>>>>
>>>> Generaets the following code:
>>>>
>>>> /* Implementation of 'cplus' */
>>>> static char __pyx_k__wtf[] = "wtf";
>>>> static char __pyx_k____main__[] = "__main__";
>>>> static char __pyx_k____test__[] = "__test__";
>>>> static PyObject *__pyx_n_s____main__;
>>>> static PyObject *__pyx_n_s____test__;
>>>> static PyObject *__pyx_n_s__wtf;
>>>> static PyObject *__pyx_n_s__wtf;
>>>>
>>>> ...
>>>>
>>>> static __Pyx_StringTabEntry __pyx_string_tab[] = {
>>>> ? {&__pyx_n_s____main__, __pyx_k____main__, sizeof(__pyx_k____main__),
>>>> 0, 0, 1, 1},
>>>> ? {&__pyx_n_s____test__, __pyx_k____test__, sizeof(__pyx_k____test__),
>>>> 0, 0, 1, 1},
>>>> ? {&__pyx_n_s__wtf, __pyx_k__wtf, sizeof(__pyx_k__wtf), "koi8-r", 0, 1,
>>>> 1},
>>>> ? {&__pyx_n_s__wtf, __pyx_k__wtf, sizeof(__pyx_k__wtf), 0, 0, 1, 1},
>>>> ? {0, 0, 0, 0, 0, 0, 0}
>>>> };
>>>
>>> Both Python object variables should have different cnames.
>>
>> What's about adding encoding suffix?
>
> Yes, I think that would fix it, although it could be a bit misleading when
> reading the C code with a Py3 context in mind. But using a counter doesn't
> make it very readable, either.
>

Ok.

I've fixed it here https://github.com/vitek/cython/compare/file_encoding_T770

Now it produces the following identifiers:

static PyObject *__pyx_n_s__wtf;
static PyObject *__pyx_n_s_koi8r__wtf;


-- 
vitja.

From hagy at gatech.edu  Sun Nov 13 20:51:23 2011
From: hagy at gatech.edu (Matt Hagy)
Date: Sun, 13 Nov 2011 14:51:23 -0500 (EST)
Subject: [Cython] Generators not closed on dealloc (Cython 0.15.1+,
	current git master)
In-Reply-To: <11b6a829-04d4-4517-8b83-25591a27096b@mail6.gatech.edu>
Message-ID: <f6ae7697-cf0b-4aac-b624-49d5d35c558f@mail6.gatech.edu>

Hi,

Cython generators aren?t closed on dealloc and this can lead to cleanup code not being ran (see example below). I couldn?t find any reference to this issue on the trac or the wiki and therefore wanted to report it. If this is a know issue please disregard this post.

I believe this can easily be corrected by adding the following line to the top of each generator dealloc function:

    if (p->resume_label != -1) __Pyx_Generator_Close(o);

This explicitly closes the generator unless it?s already finished. For testing I manually added this code to the generated C file and it worked as expected.

-Matt

Example:

I found this issue in the following code that relies upon a finally block to free memory. If not explicitly closed, the cleanup code is never executed and memory is leaked.

############################################
# generate_primes.pyx

from libc.stdlib cimport malloc, realloc, free

def generate_primes(unsigned int initial_buffer_size=64):
    cdef unsigned int test_number, i, N_primes, N_allocated
    cdef unsigned int *primes

    N_primes = 0
    N_allocated = initial_buffer_size
    primes = <unsigned int*>malloc(N_allocated * sizeof(unsigned int))
    if not primes: raise MemoryError

    test_number = 2

    try:
        while 1:
            # is the current value of test_number prime?
            # i.e. is it not divisible by any of the already seen primes
            i = 0
            while i<N_primes and test_number % primes[i] != 0:
                i += 1

            if i == N_primes:
                yield test_number

                # grow primes array if needed
                if N_primes == N_allocated:
                    N_allocated = N_allocated + 64
                    primes = <unsigned int*>realloc(primes, N_allocated * sizeof(unsigned int))
                    if not primes: raise MemoryError

                primes[N_primes] = test_number
                N_primes += 1

            test_number += 1
    finally:
        print 'clean up'
        free(primes)

###############################################

From vitja.makarov at gmail.com  Sun Nov 13 22:09:05 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Mon, 14 Nov 2011 01:09:05 +0400
Subject: [Cython] Generators not closed on dealloc (Cython 0.15.1+,
 current git master)
In-Reply-To: <f6ae7697-cf0b-4aac-b624-49d5d35c558f@mail6.gatech.edu>
References: <11b6a829-04d4-4517-8b83-25591a27096b@mail6.gatech.edu>
	<f6ae7697-cf0b-4aac-b624-49d5d35c558f@mail6.gatech.edu>
Message-ID: <CAKGHGPRVDJfWA-C4s32L=An_Bwz_phs2e20QESSJosPHg+Sy3g@mail.gmail.com>

2011/11/13 Matt Hagy <hagy at gatech.edu>:
> Hi,
>
> Cython generators aren?t closed on dealloc and this can lead to cleanup code not being ran (see example below). I couldn?t find any reference to this issue on the trac or the wiki and therefore wanted to report it. If this is a know issue please disregard this post.
>

Good catch!

>
> I believe this can easily be corrected by adding the following line to the top of each generator dealloc function:
>
> ? ?if (p->resume_label != -1) __Pyx_Generator_Close(o);
>

I think that correct fix should be > 0 as we don't wanna close just
started generator
i
> This explicitly closes the generator unless it?s already finished. For testing I manually added this code to the generated C file and it worked as expected.
>
> -Matt
>

It's not that easy to fix. For convenience Closure sublasses generator type:

def foo(a):
    try:
        yield a
    finally:
        print 'cleanup'
        print '"a" might be dead at this point', a

The problem is closure's __dealloc__ is called first then generator's.
So we can't call Geneator_Close() with deallocated closure.

I see few options here:
 - do cleanup in closure type itsef
 - make closure generator's attribute

I like the second case.

-- 
vitja.

From robertwb at math.washington.edu  Tue Nov 15 10:23:13 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Tue, 15 Nov 2011 01:23:13 -0800
Subject: [Cython] relative_path_in_code_position_comments
In-Reply-To: <CAAvcK2ZjjiioW0KPVvGDKtNqtGkhaa7UF8shZs4x6Ay=04oF7w@mail.gmail.com>
References: <CAAvcK2ZjjiioW0KPVvGDKtNqtGkhaa7UF8shZs4x6Ay=04oF7w@mail.gmail.com>
Message-ID: <CADiQ+QD8XH6SjyFSisxdiEDtFceN=tNU=4NWTXbygUYL307Thw@mail.gmail.com>

On Wed, Sep 21, 2011 at 2:48 AM, Brett Calcott <brett.calcott at gmail.com> wrote:
> Hi all,
> The path in cython's error output is insensitive to the cwd where cython in
> invoked. It seems to be based on this variable in Cython/Compiler/Main.py:
> ??relative_path_in_code_position_comments = True,
> If I understand it right, the path output is relative to module it is in,
> instead of relative to the cwd.
>
> This plays havoc with my editor (Vim), as it attempts to try and load the
> file that caused the error based on parsing the output. I've just changed
> this variable to False in my install, and it works fine.
> Is there a reason for this? Am I missing some easy way around this?
> Thanks,
> Brett

This was fixed with https://github.com/cython/cython/pull/55 , wasn't
it? (I'm not sure if this has been released yet.)

- Robert

From stefan_ml at behnel.de  Tue Nov 15 10:42:29 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Tue, 15 Nov 2011 10:42:29 +0100
Subject: [Cython] relative_path_in_code_position_comments
In-Reply-To: <CAAvcK2ZjjiioW0KPVvGDKtNqtGkhaa7UF8shZs4x6Ay=04oF7w@mail.gmail.com>
References: <CAAvcK2ZjjiioW0KPVvGDKtNqtGkhaa7UF8shZs4x6Ay=04oF7w@mail.gmail.com>
Message-ID: <4EC23405.1000904@behnel.de>

Brett Calcott, 21.09.2011 11:48:
> The path in cython's error output is insensitive to the cwd where cython in
> invoked. It seems to be based on this variable in Cython/Compiler/Main.py:
>
>    relative_path_in_code_position_comments = True,
>
> If I understand it right, the path output is relative to module it is in,
> instead of relative to the cwd.
>
> This plays havoc with my editor (Vim), as it attempts to try and load the
> file that caused the error based on parsing the output. I've just changed
> this variable to False in my install, and it works fine.
>
> Is there a reason for this? Am I missing some easy way around this?

Hi,

note that the best place to discuss usage related questions is the 
cython-users mailing list.

Stefan

From l at t-0.be  Tue Nov 15 16:19:38 2011
From: l at t-0.be (Devin Bayer)
Date: Tue, 15 Nov 2011 16:19:38 +0100
Subject: [Cython] [RFE] cygdb not in entrypoints
Message-ID: <3AA138DF-F13E-4F72-971B-67BC2A377E12@t-0.be>

Hi. Could you add cypdb to the entrypoints so that I can run it after an egg installation?

Also, it would be great if you mentioned how to submit bugs in the README. It took me a while to find this list as the official bug submission channel.

Thanks,
Devin

From markflorisson88 at gmail.com  Tue Nov 15 16:47:28 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Tue, 15 Nov 2011 15:47:28 +0000
Subject: [Cython] [RFE] cygdb not in entrypoints
In-Reply-To: <3AA138DF-F13E-4F72-971B-67BC2A377E12@t-0.be>
References: <3AA138DF-F13E-4F72-971B-67BC2A377E12@t-0.be>
Message-ID: <CANg26EWUcfE9yC9Co35gPhturH2sbHirMXV7k0-mveEmeiAMVQ@mail.gmail.com>

On 15 November 2011 15:19, Devin Bayer <l at t-0.be> wrote:
> Hi. Could you add cypdb to the entrypoints so that I can run it after an egg installation?

Yeah that's a good idea, that has never been tested (it's cygdb by the
way, as it is an extension of gdb).

> Also, it would be great if you mentioned how to submit bugs in the README. It took me a while to find this list as the official bug submission channel.

Sure. If you want, you can also fork cython
(https://github.com/cython/cython) and create a pull request.

> Thanks,
> Devin
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

From vitja.makarov at gmail.com  Tue Nov 15 18:18:28 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Tue, 15 Nov 2011 21:18:28 +0400
Subject: [Cython] Generators not closed on dealloc (Cython 0.15.1+,
 current git master)
In-Reply-To: <CAKGHGPRVDJfWA-C4s32L=An_Bwz_phs2e20QESSJosPHg+Sy3g@mail.gmail.com>
References: <11b6a829-04d4-4517-8b83-25591a27096b@mail6.gatech.edu>
	<f6ae7697-cf0b-4aac-b624-49d5d35c558f@mail6.gatech.edu>
	<CAKGHGPRVDJfWA-C4s32L=An_Bwz_phs2e20QESSJosPHg+Sy3g@mail.gmail.com>
Message-ID: <CAKGHGPSPgupxCahGNMgY=fMmrCSF+nTnwe0FMkzV6QcTs_2OoA@mail.gmail.com>

2011/11/14 Vitja Makarov <vitja.makarov at gmail.com>:
> 2011/11/13 Matt Hagy <hagy at gatech.edu>:
>> Hi,
>>
>> Cython generators aren?t closed on dealloc and this can lead to cleanup code not being ran (see example below). I couldn?t find any reference to this issue on the trac or the wiki and therefore wanted to report it. If this is a know issue please disregard this post.
>>
>
> Good catch!
>
>>
>> I believe this can easily be corrected by adding the following line to the top of each generator dealloc function:
>>
>> ? ?if (p->resume_label != -1) __Pyx_Generator_Close(o);
>>
>
> I think that correct fix should be > 0 as we don't wanna close just
> started generator
> i
>> This explicitly closes the generator unless it?s already finished. For testing I manually added this code to the generated C file and it worked as expected.
>>
>> -Matt
>>
>
> It's not that easy to fix. For convenience Closure sublasses generator type:
>
> def foo(a):
> ? ?try:
> ? ? ? ?yield a
> ? ?finally:
> ? ? ? ?print 'cleanup'
> ? ? ? ?print '"a" might be dead at this point', a
>
> The problem is closure's __dealloc__ is called first then generator's.
> So we can't call Geneator_Close() with deallocated closure.
>
> I see few options here:
> ?- do cleanup in closure type itsef
> ?- make closure generator's attribute
>
> I like the second case.
>

I've fixed it here
https://github.com/vitek/cython/commits/_generators_cleanup

I've taken deallocation code from CPython it performs magic object
resurrection when it''s almost dead.

Now I'm waiting for hudson job then I'll create a pull request.

-- 
vitja.

From th30z at develer.com  Fri Nov 18 09:44:54 2011
From: th30z at develer.com (Matteo Bertozzi)
Date: Fri, 18 Nov 2011 09:44:54 +0100
Subject: [Cython] Undefined name 'entry' generate_type_import_call() 0.15.1
	and trunk
Message-ID: <1321605894.2251.3.camel@pegasus.trilan>

there's an undefined name 'entry' in ModuleNode.py
generate_type_import_call() line 2171. I think that 'entry' should be
replaced with 'type'. 

> diff --git a/Cython/Compiler/ModuleNode.py b/Cython/Compiler/ModuleNode.py
> index 13cf6c8..ff9ca56 100644
> --- a/Cython/Compiler/ModuleNode.py
> +++ b/Cython/Compiler/ModuleNode.py
> @@ -2168,7 +2168,7 @@ class ModuleNode(Nodes.Node, Nodes.BlockNode):
>          else:
>              module_name = '__Pyx_BUILTIN_MODULE_NAME'
>              if type.name in Code.non_portable_builtins_map:
> -                condition, replacement = Code.non_portable_builtins_map[entry.name]
> +                condition, replacement = Code.non_portable_builtins_map[type.name]
>                  code.putln("#if %s" % condition)
>                  code.putln('%s = __Pyx_ImportType(%s, "%s", sizeof(%s), 1); %s' % (
>                          type.typeptr_cname,


From stefan_ml at behnel.de  Mon Nov 21 19:04:22 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 21 Nov 2011 19:04:22 +0100
Subject: [Cython] Undefined name 'entry' generate_type_import_call()
 0.15.1 and trunk
In-Reply-To: <1321605894.2251.3.camel@pegasus.trilan>
References: <1321605894.2251.3.camel@pegasus.trilan>
Message-ID: <4ECA92A6.20505@behnel.de>

Matteo Bertozzi, 18.11.2011 09:44:
> there's an undefined name 'entry' in ModuleNode.py
> generate_type_import_call() line 2171. I think that 'entry' should be
> replaced with 'type'.
>
>> diff --git a/Cython/Compiler/ModuleNode.py b/Cython/Compiler/ModuleNode.py
>> index 13cf6c8..ff9ca56 100644
>> --- a/Cython/Compiler/ModuleNode.py
>> +++ b/Cython/Compiler/ModuleNode.py
>> @@ -2168,7 +2168,7 @@ class ModuleNode(Nodes.Node, Nodes.BlockNode):
>>           else:
>>               module_name = '__Pyx_BUILTIN_MODULE_NAME'
>>               if type.name in Code.non_portable_builtins_map:
>> -                condition, replacement = Code.non_portable_builtins_map[entry.name]
>> +                condition, replacement = Code.non_portable_builtins_map[type.name]
>>                   code.putln("#if %s" % condition)
>>                   code.putln('%s = __Pyx_ImportType(%s, "%s", sizeof(%s), 1); %s' % (
>>                           type.typeptr_cname,

Good catch. Thanks!

Stefan

From rauli.ruohonen at gmail.com  Wed Nov 23 19:03:26 2011
From: rauli.ruohonen at gmail.com (Rauli Ruohonen)
Date: Wed, 23 Nov 2011 20:03:26 +0200
Subject: [Cython] Segmentation fault with generator expressions in a cdef
	class (Cython 0.15.1)
Message-ID: <CAM0vgG_+-Nx4PTawG6oeTe6XjNt0Xb2UXcX1RtinRpYOhru8ng@mail.gmail.com>

Hi,

I don't know if this has been reported yet (didn't notice a ticket
with a quick look though), but I just downloaded and installed the
latest Cython tarball and got a segfault this way:

rauli at ubuntu:~/example$ ls
bar.py  foo.pyx
rauli at ubuntu:~/example$ python bar.py
Segmentation fault
rauli at ubuntu:~/example$ cat bar.py
import pyximport; pyximport.install()
import foo

foo.Foo()
rauli at ubuntu:~/example$ cat foo.pyx
cdef class Foo(object):

   cdef object bar

   def __init__(self):
       self.bar = 'baz'
       (i for i in self.bar)
rauli at ubuntu:~/example$ uname -a
Linux ubuntu 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC
2011 x86_64 x86_64 x86_64 GNU/Linux
rauli at ubuntu:~/example$ cython --version
Cython version 0.15.1
rauli at ubuntu:~/example$ python --version
Python 2.7.1+
rauli at ubuntu:~/example$

From vitja.makarov at gmail.com  Wed Nov 23 20:00:53 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Wed, 23 Nov 2011 23:00:53 +0400
Subject: [Cython] Segmentation fault with generator expressions in a
 cdef class (Cython 0.15.1)
In-Reply-To: <CAM0vgG_+-Nx4PTawG6oeTe6XjNt0Xb2UXcX1RtinRpYOhru8ng@mail.gmail.com>
References: <CAM0vgG_+-Nx4PTawG6oeTe6XjNt0Xb2UXcX1RtinRpYOhru8ng@mail.gmail.com>
Message-ID: <CAKGHGPRAvNi4JCAxMF18EYk0nOowzx8XodZspQHkoJLwOpj90g@mail.gmail.com>

2011/11/23 Rauli Ruohonen <rauli.ruohonen at gmail.com>:
> Hi,
>
> I don't know if this has been reported yet (didn't notice a ticket
> with a quick look though), but I just downloaded and installed the
> latest Cython tarball and got a segfault this way:
>
> rauli at ubuntu:~/example$ ls
> bar.py ?foo.pyx
> rauli at ubuntu:~/example$ python bar.py
> Segmentation fault
> rauli at ubuntu:~/example$ cat bar.py
> import pyximport; pyximport.install()
> import foo
>
> foo.Foo()
> rauli at ubuntu:~/example$ cat foo.pyx
> cdef class Foo(object):
>
> ? cdef object bar
>
> ? def __init__(self):
> ? ? ? self.bar = 'baz'
> ? ? ? (i for i in self.bar)
> rauli at ubuntu:~/example$ uname -a
> Linux ubuntu 2.6.38-10-generic #46-Ubuntu SMP Tue Jun 28 15:07:17 UTC
> 2011 x86_64 x86_64 x86_64 GNU/Linux
> rauli at ubuntu:~/example$ cython --version
> Cython version 0.15.1
> rauli at ubuntu:~/example$ python --version
> Python 2.7.1+
> rauli at ubuntu:~/example$
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

Fixed here
http://trac.cython.org/cython_trac/ticket/742


-- 
vitja.

From markflorisson88 at gmail.com  Wed Nov 23 21:21:17 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Wed, 23 Nov 2011 20:21:17 +0000
Subject: [Cython] memoryviews from C arrays
Message-ID: <CANg26EX-WT5b=6kkK+RCpq3KKf46-StqkfRHXMuUfj5cT5uDDg@mail.gmail.com>

Hey,

Currently when we want to convert C arrays to memoryview slices we have to
do this:

cdef int array[5][4]
cdef int[:, :] slice = <int[:5, :4]> <int *> array

I'd like to be able to write

cdef int array[5][4]
cdef int[:, :] slice

slice = <int[:, :]> array
# and
slice = array

I think that would be convenient, especially if we later on support
variable sized C arrays. I also changed semantics with the cython.array
callback, so now the data gets deallocated only if cython.array allocated
it itself, otherwise a callback may be registered.

Anyone opposed to the above semantics?

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20111123/42213f88/attachment.html>

From robertwb at math.washington.edu  Wed Nov 23 22:46:25 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Wed, 23 Nov 2011 13:46:25 -0800
Subject: [Cython] memoryviews from C arrays
In-Reply-To: <CANg26EX-WT5b=6kkK+RCpq3KKf46-StqkfRHXMuUfj5cT5uDDg@mail.gmail.com>
References: <CANg26EX-WT5b=6kkK+RCpq3KKf46-StqkfRHXMuUfj5cT5uDDg@mail.gmail.com>
Message-ID: <CADiQ+QAxwi3KLH2swtF9JRxHfJWL77E_skdhY3h1JWOrrC6xwA@mail.gmail.com>

On Wed, Nov 23, 2011 at 12:21 PM, mark florisson
<markflorisson88 at gmail.com> wrote:
> Hey,
>
> Currently when we want to convert C arrays to memoryview slices we have to
> do this:
>
> cdef int array[5][4]
> cdef int[:, :] slice = <int[:5, :4]> <int *> array
> I'd like to be able to write
> cdef int array[5][4]
> cdef int[:, :] slice
> slice = <int[:, :]> array
> # and
> slice = array
> I think that would be convenient, especially if we later on support variable
> sized C arrays. I also changed semantics with the cython.array callback, so
> now the data gets deallocated only if cython.array allocated it itself,
> otherwise a callback may be registered.
> Anyone opposed to the above semantics?

Sounds good to me. Having to explicitly set the deallocate callback
seems the better default. Did you update the docs?

- Robert

From markflorisson88 at gmail.com  Wed Nov 23 22:58:01 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Wed, 23 Nov 2011 21:58:01 +0000
Subject: [Cython] memoryviews from C arrays
In-Reply-To: <CADiQ+QAxwi3KLH2swtF9JRxHfJWL77E_skdhY3h1JWOrrC6xwA@mail.gmail.com>
References: <CANg26EX-WT5b=6kkK+RCpq3KKf46-StqkfRHXMuUfj5cT5uDDg@mail.gmail.com>
	<CADiQ+QAxwi3KLH2swtF9JRxHfJWL77E_skdhY3h1JWOrrC6xwA@mail.gmail.com>
Message-ID: <CANg26EX7=G5rJakwHySnY1W4pGRAF6E5fdhtvRj39iM504q=qQ@mail.gmail.com>

Yes, but I'm running some tests on hudson.

On 23 November 2011 21:46, Robert Bradshaw <robertwb at math.washington.edu>wrote:

> On Wed, Nov 23, 2011 at 12:21 PM, mark florisson
> <markflorisson88 at gmail.com> wrote:
> > Hey,
> >
> > Currently when we want to convert C arrays to memoryview slices we have
> to
> > do this:
> >
> > cdef int array[5][4]
> > cdef int[:, :] slice = <int[:5, :4]> <int *> array
> > I'd like to be able to write
> > cdef int array[5][4]
> > cdef int[:, :] slice
> > slice = <int[:, :]> array
> > # and
> > slice = array
> > I think that would be convenient, especially if we later on support
> variable
> > sized C arrays. I also changed semantics with the cython.array callback,
> so
> > now the data gets deallocated only if cython.array allocated it itself,
> > otherwise a callback may be registered.
> > Anyone opposed to the above semantics?
>
> Sounds good to me. Having to explicitly set the deallocate callback
> seems the better default. Did you update the docs?
>
> - Robert
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20111123/da66ddad/attachment.html>

From l at t-0.be  Thu Nov 24 16:16:03 2011
From: l at t-0.be (Devin Bayer)
Date: Thu, 24 Nov 2011 16:16:03 +0100
Subject: [Cython] [BUG] cythonize() doesn't handle relative imports
Message-ID: <5D16BCEB-1888-4D58-B42C-0A52794D8539@t-0.be>

Hi. I had a bunch of trouble with the setuptools extensions, so I wanted to try the new cythonize command, but it doesn't correctly handle dependencies. I have two files:

  src/_proto.pxd, which is empty
  src/_inrdb.pyx, which contains "from _proto cimport *"

and cythonize(['src/_inrdb.pyx']) prints this "warning":

> ('missing cimport', 'src/_inrdb.pyx')
> libc.stdint
> 	_proto
> 	libc.string
> /Library/Python/2.7/site-packages/Cython-0.15.1-py2.7-macosx-10.7-intel.egg/Cython/Includes/libc/stdint.pxd
> 	/Library/Python/2.7/site-packages/Cython-0.15.1-py2.7-macosx-10.7-intel.egg/Cython/Includes/libc/string.pxd

touching src/__init__.py and changing the cimport to src._proto resolves the issue.

Thanks,
Devin

From markflorisson88 at gmail.com  Fri Nov 25 12:12:48 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Fri, 25 Nov 2011 11:12:48 +0000
Subject: [Cython] nested prange
Message-ID: <CANg26EUXbQ0J7F-rNLY8oH1ASRxb=KtO8MH1811qpu1ztXn9NQ@mail.gmail.com>

I think we should allow nested prange()s, although it won't invoke
nested OpenMP parallelism now, it still specifies that iterations are
independent which can be useful for optimizations now (e.g. collapsing
two loops into one) and in the future with other backends. Any
thoughts or objections?

From vitja.makarov at gmail.com  Sat Nov 26 17:10:48 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Sat, 26 Nov 2011 20:10:48 +0400
Subject: [Cython] Type inference question
Message-ID: <CAKGHGPR5hWYDdpWRwaLQ-wpQ1WrdU29UWv33-OzQJnawt-iwNA@mail.gmail.com>

Hi!

I'm now trying to make inlined generator expressions work again. And I
found strange thing:

inlined_generator_expression.pyx:

def range_sum(int N):
    """
    >>> sum(range(10))
    45
    >>> range_sum(10)
    45
    """
    result = sum(i for i in range(N))
    return result

'i' is expected to be integer, but it isn't

So I tried simple example and 'i' is inferred as object:

def bar(int N):
    cdef int result = 0
    for i in range(N):
        result += i
    return result

So, I'm wondering should it be inferred as int or not?

-- 
vitja.

From robertwb at math.washington.edu  Sat Nov 26 19:35:48 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Sat, 26 Nov 2011 10:35:48 -0800
Subject: [Cython] nested prange
In-Reply-To: <CANg26EUXbQ0J7F-rNLY8oH1ASRxb=KtO8MH1811qpu1ztXn9NQ@mail.gmail.com>
References: <CANg26EUXbQ0J7F-rNLY8oH1ASRxb=KtO8MH1811qpu1ztXn9NQ@mail.gmail.com>
Message-ID: <CADiQ+QBpSOQO+EW0YZF27nf=etwkr-G69hxsVhFD+XJeNVykFw@mail.gmail.com>

I'm all for allowing it at the Cython level even though we can't emit
code for it at the C level (due to C compiler bugs, right?)

- Robert

On Fri, Nov 25, 2011 at 3:12 AM, mark florisson
<markflorisson88 at gmail.com> wrote:
> I think we should allow nested prange()s, although it won't invoke
> nested OpenMP parallelism now, it still specifies that iterations are
> independent which can be useful for optimizations now (e.g. collapsing
> two loops into one) and in the future with other backends. Any
> thoughts or objections?
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

From robertwb at math.washington.edu  Sat Nov 26 19:40:32 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Sat, 26 Nov 2011 10:40:32 -0800
Subject: [Cython] Type inference question
In-Reply-To: <CAKGHGPR5hWYDdpWRwaLQ-wpQ1WrdU29UWv33-OzQJnawt-iwNA@mail.gmail.com>
References: <CAKGHGPR5hWYDdpWRwaLQ-wpQ1WrdU29UWv33-OzQJnawt-iwNA@mail.gmail.com>
Message-ID: <CADiQ+QCnYdYUfkYr4BqjCVekgmGM390LLuGBNOtKJ5X71j3pcg@mail.gmail.com>

On Sat, Nov 26, 2011 at 8:10 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> Hi!
>
> I'm now trying to make inlined generator expressions work again. And I
> found strange thing:
>
> inlined_generator_expression.pyx:
>
> def range_sum(int N):
> ? ?"""
> ? ?>>> sum(range(10))
> ? ?45
> ? ?>>> range_sum(10)
> ? ?45
> ? ?"""
> ? ?result = sum(i for i in range(N))
> ? ?return result
>
> 'i' is expected to be integer, but it isn't
>
> So I tried simple example and 'i' is inferred as object:
>
> def bar(int N):
> ? ?cdef int result = 0
> ? ?for i in range(N):
> ? ? ? ?result += i
> ? ?return result
>
> So, I'm wondering should it be inferred as int or not?

It's not because it's used in an arithmetic expression that might
overflow. You can decorate this with @cython.infer_types(True) or use
doubles to get the inference you want.

- Robert

From vitja.makarov at gmail.com  Sat Nov 26 20:00:49 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Sat, 26 Nov 2011 23:00:49 +0400
Subject: [Cython] Type inference question
In-Reply-To: <CADiQ+QCnYdYUfkYr4BqjCVekgmGM390LLuGBNOtKJ5X71j3pcg@mail.gmail.com>
References: <CAKGHGPR5hWYDdpWRwaLQ-wpQ1WrdU29UWv33-OzQJnawt-iwNA@mail.gmail.com>
	<CADiQ+QCnYdYUfkYr4BqjCVekgmGM390LLuGBNOtKJ5X71j3pcg@mail.gmail.com>
Message-ID: <CAKGHGPQboDQSao7erobLo_q0KXD4xu6CmiB-1gPoMmanEfV0_Q@mail.gmail.com>

2011/11/26 Robert Bradshaw <robertwb at math.washington.edu>:
> On Sat, Nov 26, 2011 at 8:10 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>> Hi!
>>
>> I'm now trying to make inlined generator expressions work again. And I
>> found strange thing:
>>
>> inlined_generator_expression.pyx:
>>
>> def range_sum(int N):
>> ? ?"""
>> ? ?>>> sum(range(10))
>> ? ?45
>> ? ?>>> range_sum(10)
>> ? ?45
>> ? ?"""
>> ? ?result = sum(i for i in range(N))
>> ? ?return result
>>
>> 'i' is expected to be integer, but it isn't
>>
>> So I tried simple example and 'i' is inferred as object:
>>
>> def bar(int N):
>> ? ?cdef int result = 0
>> ? ?for i in range(N):
>> ? ? ? ?result += i
>> ? ?return result
>>
>> So, I'm wondering should it be inferred as int or not?
>
> It's not because it's used in an arithmetic expression that might
> overflow. You can decorate this with @cython.infer_types(True) or use
> doubles to get the inference you want.
>

Ok. So I guess something changed after inlined genexps was disabled:

https://github.com/cython/cython/blob/master/tests/run/inlined_generator_expressions.pyx#L16

This test relies on integer range.


I'm also a little bit concerned about MarkAssignments I think it's
better to merge it with CreateControlFlow.
For instance, type inference doesn't work for comprehensions and will
not work for inlined genexprs.

-- 
vitja.

From robertwb at math.washington.edu  Sat Nov 26 20:08:44 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Sat, 26 Nov 2011 11:08:44 -0800
Subject: [Cython] Type inference question
In-Reply-To: <CAKGHGPQboDQSao7erobLo_q0KXD4xu6CmiB-1gPoMmanEfV0_Q@mail.gmail.com>
References: <CAKGHGPR5hWYDdpWRwaLQ-wpQ1WrdU29UWv33-OzQJnawt-iwNA@mail.gmail.com>
	<CADiQ+QCnYdYUfkYr4BqjCVekgmGM390LLuGBNOtKJ5X71j3pcg@mail.gmail.com>
	<CAKGHGPQboDQSao7erobLo_q0KXD4xu6CmiB-1gPoMmanEfV0_Q@mail.gmail.com>
Message-ID: <CADiQ+QA9w=Vut-sd4kHv6tR0kRG-qd1vyuqEUYVnov7jScgJQg@mail.gmail.com>

On Sat, Nov 26, 2011 at 11:00 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> 2011/11/26 Robert Bradshaw <robertwb at math.washington.edu>:
>> On Sat, Nov 26, 2011 at 8:10 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>> Hi!
>>>
>>> I'm now trying to make inlined generator expressions work again. And I
>>> found strange thing:
>>>
>>> inlined_generator_expression.pyx:
>>>
>>> def range_sum(int N):
>>> ? ?"""
>>> ? ?>>> sum(range(10))
>>> ? ?45
>>> ? ?>>> range_sum(10)
>>> ? ?45
>>> ? ?"""
>>> ? ?result = sum(i for i in range(N))
>>> ? ?return result
>>>
>>> 'i' is expected to be integer, but it isn't
>>>
>>> So I tried simple example and 'i' is inferred as object:
>>>
>>> def bar(int N):
>>> ? ?cdef int result = 0
>>> ? ?for i in range(N):
>>> ? ? ? ?result += i
>>> ? ?return result
>>>
>>> So, I'm wondering should it be inferred as int or not?
>>
>> It's not because it's used in an arithmetic expression that might
>> overflow. You can decorate this with @cython.infer_types(True) or use
>> doubles to get the inference you want.
>>
>
> Ok. So I guess something changed after inlined genexps was disabled:
>
> https://github.com/cython/cython/blob/master/tests/run/inlined_generator_expressions.pyx#L16
>
> This test relies on integer range.

Perhaps. Or perhaps it was implemented in such as way that the
arithmetic was not detected (which would have been a bug).

> I'm also a little bit concerned about MarkAssignments I think it's
> better to merge it with CreateControlFlow.
> For instance, type inference doesn't work for comprehensions and will
> not work for inlined genexprs.

I think it makes sense to merge MarkAssignments into
CreateControlFlow; the former was a simple transform before we had any
control flow.

- Robert

From markflorisson88 at gmail.com  Mon Nov 28 20:16:48 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Mon, 28 Nov 2011 19:16:48 +0000
Subject: [Cython] nested prange
In-Reply-To: <CADiQ+QBpSOQO+EW0YZF27nf=etwkr-G69hxsVhFD+XJeNVykFw@mail.gmail.com>
References: <CANg26EUXbQ0J7F-rNLY8oH1ASRxb=KtO8MH1811qpu1ztXn9NQ@mail.gmail.com>
	<CADiQ+QBpSOQO+EW0YZF27nf=etwkr-G69hxsVhFD+XJeNVykFw@mail.gmail.com>
Message-ID: <CANg26EX3aayPy1++RKDsGzLpDb-u5pwPLFOLiCvzKq=x5AbE4w@mail.gmail.com>

Ok, great. Indeed, there is a bug in gcc 4.5, which is fixed I believe
in 4.6. For the OpenMP  backend that's not such a big issue, as it's
likely not very useful anyway.

On 26 November 2011 18:35, Robert Bradshaw <robertwb at math.washington.edu> wrote:
> I'm all for allowing it at the Cython level even though we can't emit
> code for it at the C level (due to C compiler bugs, right?)
>
> - Robert
>
> On Fri, Nov 25, 2011 at 3:12 AM, mark florisson
> <markflorisson88 at gmail.com> wrote:
>> I think we should allow nested prange()s, although it won't invoke
>> nested OpenMP parallelism now, it still specifies that iterations are
>> independent which can be useful for optimizations now (e.g. collapsing
>> two loops into one) and in the future with other backends. Any
>> thoughts or objections?
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel at python.org
>> http://mail.python.org/mailman/listinfo/cython-devel
>>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

From stefan at sun.ac.za  Tue Nov 29 00:49:24 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 28 Nov 2011 15:49:24 -0800
Subject: [Cython] Correct way of defining enums
Message-ID: <CABDkGQ=zSVyzw-N8Ee+XoY0kAExk_Nf_09-ZuUh1t_7eXzSO_A@mail.gmail.com>

Hi all,

What is currently the correct way of defining an enum?  I am trying to call
a NumPy function with an enum as its third argument, and the following does
not compile:

cimport numpy as np
np.import_array()

cdef enum NPY_SEARCHSIDE:
    NPY_SEARCHLEFT = 0
   NPY_SEARCHRIGHT = 1

cdef sort_something():
   cdef np.ndarray[double, ndim=1] sample_prob = np.empty(5, np.float64)
    cdef np.ndarray[double, ndim=1] cum_prob = np.empty(5, np.float64)

    cdef NPY_SEARCHSIDE side = NPY_SEARCHRIGHT

   results = np.PyArray_SearchSorted(cum_prob, sample_prob, side)

It fails with:

enum.c:1081:3: error: incompatible type for argument 3 of ?(struct PyObject
* (*)(struct PyArrayObject *, struct PyObject *, enum
NPY_SEARCHSIDE))*(PyArray_API + 1048u)?
enum.c:1081:3: note: expected ?NPY_SEARCHSIDE? but argument is of type
?struct PyObject *?

I tried different ways of defining the enum, e.g.

cdef extern from "ndarraytypes.h":
    cpdef enum NPY_SEARCHSIDE:
        NPY_SEARCHLEFT = 0
        NPY_SEARCHRIGHT = 1

But that doesn't work either.  Any suggestions would be appreciated.

Regards
St?fan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20111128/bd438a7b/attachment.html>

From dalcinl at gmail.com  Tue Nov 29 19:32:18 2011
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Tue, 29 Nov 2011 15:32:18 -0300
Subject: [Cython] Correct way of defining enums
In-Reply-To: <CABDkGQ=zSVyzw-N8Ee+XoY0kAExk_Nf_09-ZuUh1t_7eXzSO_A@mail.gmail.com>
References: <CABDkGQ=zSVyzw-N8Ee+XoY0kAExk_Nf_09-ZuUh1t_7eXzSO_A@mail.gmail.com>
Message-ID: <CAEcYPwCUfEk2yg6sWyEf935WDQfJOTOzN5Uc3e-0D+on16g+5A@mail.gmail.com>

2011/11/28 St?fan van der Walt <stefan at sun.ac.za>:
>
> I tried different ways of defining the enum, e.g.
>
> cdef extern from "ndarraytypes.h":
> ??? cpdef enum NPY_SEARCHSIDE:
> ??????? NPY_SEARCHLEFT = 0
> ??????? NPY_SEARCHRIGHT = 1
>

This is (near to, see below) the right way, as that NumPy enum do is
declared in NumPy headers.

>
> But that doesn't work either.? Any suggestions would be appreciated.
>

Try "ctypedef enum ..."


-- 
Lisandro Dalcin
---------------
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169

From stefan at sun.ac.za  Wed Nov 30 02:00:47 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 29 Nov 2011 17:00:47 -0800
Subject: [Cython] Correct way of defining enums
In-Reply-To: <CAEcYPwCUfEk2yg6sWyEf935WDQfJOTOzN5Uc3e-0D+on16g+5A@mail.gmail.com>
References: <CABDkGQ=zSVyzw-N8Ee+XoY0kAExk_Nf_09-ZuUh1t_7eXzSO_A@mail.gmail.com>
	<CAEcYPwCUfEk2yg6sWyEf935WDQfJOTOzN5Uc3e-0D+on16g+5A@mail.gmail.com>
Message-ID: <CABDkGQkbMdrvTaSjKKn+BXgCZ8bhXTn3BJKp9cw2__iOKMcySw@mail.gmail.com>

Hi Licandro

On Tue, Nov 29, 2011 at 10:32 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> This is (near to, see below) the right way, as that NumPy enum do is
> declared in NumPy headers.
>
> Try "ctypedef enum ..."

Unfortunately, that doesn't work either :/  (Same error message, no
matter which incantation, Cython 0.15.1+)

Thanks for the feedback.
St?fan

From greg.ewing at canterbury.ac.nz  Wed Nov 30 06:08:29 2011
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 30 Nov 2011 18:08:29 +1300
Subject: [Cython] Correct way of defining enums
In-Reply-To: <CABDkGQkbMdrvTaSjKKn+BXgCZ8bhXTn3BJKp9cw2__iOKMcySw@mail.gmail.com>
References: <CABDkGQ=zSVyzw-N8Ee+XoY0kAExk_Nf_09-ZuUh1t_7eXzSO_A@mail.gmail.com>
	<CAEcYPwCUfEk2yg6sWyEf935WDQfJOTOzN5Uc3e-0D+on16g+5A@mail.gmail.com>
	<CABDkGQkbMdrvTaSjKKn+BXgCZ8bhXTn3BJKp9cw2__iOKMcySw@mail.gmail.com>
Message-ID: <4ED5BA4D.60400@canterbury.ac.nz>

St?fan van der Walt wrote:
> Hi Licandro
> 
> On Tue, Nov 29, 2011 at 10:32 AM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>
>>Try "ctypedef enum ..."
> 
> Unfortunately, that doesn't work either :/

Did you try both together? I.e.

   cdef extern from "ndarraytypes.h":
     ctypedef enum NPY_SEARCHSIDE:
       NPY_SEARCHLEFT = 0
       NPY_SEARCHRIGHT = 1

-- 
Greg

From stefan at sun.ac.za  Wed Nov 30 06:54:13 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 29 Nov 2011 21:54:13 -0800
Subject: [Cython] Correct way of defining enums
In-Reply-To: <4ED5BA4D.60400@canterbury.ac.nz>
References: <CABDkGQ=zSVyzw-N8Ee+XoY0kAExk_Nf_09-ZuUh1t_7eXzSO_A@mail.gmail.com>
	<CAEcYPwCUfEk2yg6sWyEf935WDQfJOTOzN5Uc3e-0D+on16g+5A@mail.gmail.com>
	<CABDkGQkbMdrvTaSjKKn+BXgCZ8bhXTn3BJKp9cw2__iOKMcySw@mail.gmail.com>
	<4ED5BA4D.60400@canterbury.ac.nz>
Message-ID: <CABDkGQ=SQVCGqr0KCEprwbuB-4QRJO8C7o3aCPypm+Ei01F2Kw@mail.gmail.com>

On Tue, Nov 29, 2011 at 9:08 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Did you try both together? I.e.
>
> ?cdef extern from "ndarraytypes.h":
> ? ?ctypedef enum NPY_SEARCHSIDE:
> ? ? ?NPY_SEARCHLEFT = 0
> ? ? ?NPY_SEARCHRIGHT = 1

Yeap, no luck :(  Does this work on your system?

St?fan

From robertwb at math.washington.edu  Wed Nov 30 08:15:02 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Tue, 29 Nov 2011 23:15:02 -0800
Subject: [Cython] Correct way of defining enums
In-Reply-To: <CABDkGQ=SQVCGqr0KCEprwbuB-4QRJO8C7o3aCPypm+Ei01F2Kw@mail.gmail.com>
References: <CABDkGQ=zSVyzw-N8Ee+XoY0kAExk_Nf_09-ZuUh1t_7eXzSO_A@mail.gmail.com>
	<CAEcYPwCUfEk2yg6sWyEf935WDQfJOTOzN5Uc3e-0D+on16g+5A@mail.gmail.com>
	<CABDkGQkbMdrvTaSjKKn+BXgCZ8bhXTn3BJKp9cw2__iOKMcySw@mail.gmail.com>
	<4ED5BA4D.60400@canterbury.ac.nz>
	<CABDkGQ=SQVCGqr0KCEprwbuB-4QRJO8C7o3aCPypm+Ei01F2Kw@mail.gmail.com>
Message-ID: <CADiQ+QBPDxURsUZd_N7-k62emSv7Xoo-KVeJXsRUNcs+ah2H0w@mail.gmail.com>

The problem was with the definition of PyArray_SearchSorted, namely

    cdef object PyArray_SearchSorted (ndarray, object, NPY_SEARCHSIDE)

The problem was that NPY_SEARCHSIDE wasn't defined as a type, so it
was treating that as the argument name (implicitly typed to be
object).

https://github.com/cython/cython/commit/5ba30c45c7d3478f7b7d0490e720fb0a184c6050

There should probably be at least a mode to give warnings for untyped
arguments (and return types) of cdef functions.

- Robert

2011/11/29 St?fan van der Walt <stefan at sun.ac.za>:
> On Tue, Nov 29, 2011 at 9:08 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> Did you try both together? I.e.
>>
>> ?cdef extern from "ndarraytypes.h":
>> ? ?ctypedef enum NPY_SEARCHSIDE:
>> ? ? ?NPY_SEARCHLEFT = 0
>> ? ? ?NPY_SEARCHRIGHT = 1
>
> Yeap, no luck :( ?Does this work on your system?
>
> St?fan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

From dalcinl at gmail.com  Wed Nov 30 17:47:37 2011
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Wed, 30 Nov 2011 13:47:37 -0300
Subject: [Cython] Correct way of defining enums
In-Reply-To: <CADiQ+QBPDxURsUZd_N7-k62emSv7Xoo-KVeJXsRUNcs+ah2H0w@mail.gmail.com>
References: <CABDkGQ=zSVyzw-N8Ee+XoY0kAExk_Nf_09-ZuUh1t_7eXzSO_A@mail.gmail.com>
	<CAEcYPwCUfEk2yg6sWyEf935WDQfJOTOzN5Uc3e-0D+on16g+5A@mail.gmail.com>
	<CABDkGQkbMdrvTaSjKKn+BXgCZ8bhXTn3BJKp9cw2__iOKMcySw@mail.gmail.com>
	<4ED5BA4D.60400@canterbury.ac.nz>
	<CABDkGQ=SQVCGqr0KCEprwbuB-4QRJO8C7o3aCPypm+Ei01F2Kw@mail.gmail.com>
	<CADiQ+QBPDxURsUZd_N7-k62emSv7Xoo-KVeJXsRUNcs+ah2H0w@mail.gmail.com>
Message-ID: <CAEcYPwAE0uwodtf06sVdOuOfJXz+1u15w9ru+_KAza-OTnq-pA@mail.gmail.com>

On 30 November 2011 04:15, Robert Bradshaw <robertwb at math.washington.edu> wrote:
>
> There should probably be at least a mode to give warnings for untyped
> arguments (and return types) of cdef functions.
>

Definitely +1.


-- 
Lisandro Dalcin
---------------
CIMEC (INTEC/CONICET-UNL)
Predio CONICET-Santa Fe
Colectora RN 168 Km 472, Paraje El Pozo
3000 Santa Fe, Argentina
Tel: +54-342-4511594 (ext 1011)
Tel/Fax: +54-342-4511169

From stefan at sun.ac.za  Wed Nov 30 18:23:33 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Wed, 30 Nov 2011 09:23:33 -0800
Subject: [Cython] Correct way of defining enums
In-Reply-To: <CADiQ+QBPDxURsUZd_N7-k62emSv7Xoo-KVeJXsRUNcs+ah2H0w@mail.gmail.com>
References: <CABDkGQ=zSVyzw-N8Ee+XoY0kAExk_Nf_09-ZuUh1t_7eXzSO_A@mail.gmail.com>
	<CAEcYPwCUfEk2yg6sWyEf935WDQfJOTOzN5Uc3e-0D+on16g+5A@mail.gmail.com>
	<CABDkGQkbMdrvTaSjKKn+BXgCZ8bhXTn3BJKp9cw2__iOKMcySw@mail.gmail.com>
	<4ED5BA4D.60400@canterbury.ac.nz>
	<CABDkGQ=SQVCGqr0KCEprwbuB-4QRJO8C7o3aCPypm+Ei01F2Kw@mail.gmail.com>
	<CADiQ+QBPDxURsUZd_N7-k62emSv7Xoo-KVeJXsRUNcs+ah2H0w@mail.gmail.com>
Message-ID: <CABDkGQnRQPdfJpgLfJJ_szf0=-TphGaov=r9qziZHkHiRNCzHw@mail.gmail.com>

On Tue, Nov 29, 2011 at 11:15 PM, Robert Bradshaw
<robertwb at math.washington.edu> wrote:
> The problem was that NPY_SEARCHSIDE wasn't defined as a type, so it
> was treating that as the argument name (implicitly typed to be
> object).
>
> https://github.com/cython/cython/commit/5ba30c45c7d3478f7b7d0490e720fb0a184c6050

Thanks for the quick fix, Robert!  It works perfectly now.

Cheers
St?fan