From robertwb at math.washington.edu  Fri Sep  2 07:55:50 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Thu, 1 Sep 2011 22:55:50 -0700
Subject: [Cython] ComprehensionNode problem
In-Reply-To: <CAKGHGPQ2Ted5J23FbO2hoeSXXU6n4+WSBiU=XKBB0t85kDTd0w@mail.gmail.com>
References: <CAKGHGPQ2Ted5J23FbO2hoeSXXU6n4+WSBiU=XKBB0t85kDTd0w@mail.gmail.com>
Message-ID: <CADiQ+QBe_05N7v77sK3LwhbkiGdyFgUMbXjOp4mvtGoAsYyQ8w@mail.gmail.com>

On Sun, Aug 28, 2011 at 1:19 PM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> I've started #715 ticket investigation.
>
>
> Here is minimal test case:
>
> # cython: language_level=3
> def foo(target):
> ? ?return [(e for e in t) for t in target]
>
> Crash in the ticket is related to GeneratorExpressionScope (name is
> not correct, actually ScopedExprScope or NestedScope)
>
> If you set languange_level to 2 you will see next error:
> ...
> Compiler crash traceback from this point on:
> ?File "/home/vitja/work/cython-vitek-git/Cython/Compiler/ExprNodes.py",
> line 7732, in __init__
> ? ?if not result_type.create_from_py_utility_code(env):
> AttributeError: 'UnspecifiedType' object has no attribute
> 'create_from_py_utility_code'
>
>
> Since ComprehensionNode.append and ComprehensionNode.loop.body is the
> same generator body is created twice in MarkClosureVisitor
>
> So the issue could be solved in two ways:
>
> ?- Write special handler for ComprehensionNode in MarkClosureVisitor
> ?- Remove append child attribute from ComprehensionNode (it can be
> removed completely or just from children attribute list)

+1 to the latter option (which I see is what you did, thanks).

- Robert

From vitja.makarov at gmail.com  Fri Sep  2 08:06:50 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Fri, 2 Sep 2011 10:06:50 +0400
Subject: [Cython] ComprehensionNode problem
In-Reply-To: <CADiQ+QBe_05N7v77sK3LwhbkiGdyFgUMbXjOp4mvtGoAsYyQ8w@mail.gmail.com>
References: <CAKGHGPQ2Ted5J23FbO2hoeSXXU6n4+WSBiU=XKBB0t85kDTd0w@mail.gmail.com>
	<CADiQ+QBe_05N7v77sK3LwhbkiGdyFgUMbXjOp4mvtGoAsYyQ8w@mail.gmail.com>
Message-ID: <CAKGHGPR7jmmiL4a5rx-MZ7CO+O+PoV-=oqQ6T2rpNA2GbxOgew@mail.gmail.com>

2011/9/2 Robert Bradshaw <robertwb at math.washington.edu>:
> On Sun, Aug 28, 2011 at 1:19 PM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>> I've started #715 ticket investigation.
>>
>>
>> Here is minimal test case:
>>
>> # cython: language_level=3
>> def foo(target):
>> ? ?return [(e for e in t) for t in target]
>>
>> Crash in the ticket is related to GeneratorExpressionScope (name is
>> not correct, actually ScopedExprScope or NestedScope)
>>
>> If you set languange_level to 2 you will see next error:
>> ...
>> Compiler crash traceback from this point on:
>> ?File "/home/vitja/work/cython-vitek-git/Cython/Compiler/ExprNodes.py",
>> line 7732, in __init__
>> ? ?if not result_type.create_from_py_utility_code(env):
>> AttributeError: 'UnspecifiedType' object has no attribute
>> 'create_from_py_utility_code'
>>
>>
>> Since ComprehensionNode.append and ComprehensionNode.loop.body is the
>> same generator body is created twice in MarkClosureVisitor
>>
>> So the issue could be solved in two ways:
>>
>> ?- Write special handler for ComprehensionNode in MarkClosureVisitor
>> ?- Remove append child attribute from ComprehensionNode (it can be
>> removed completely or just from children attribute list)
>
> +1 to the latter option (which I see is what you did, thanks).
>

Thanks!

I've also found one interesting bug in genexpr implementation

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


In CPython iterator is evaluated before genexpr is created.

class Foo:
    def __iter__(self):
        print 'iter'
        return self

    def next(self):
        return 1

g = (i for i in Foo())
print g

will print in cpython:
iter
<generator ...>

and in cython:
<generator...>

Don't know how to deal with it now.

-- 
vitja.

From vitja.makarov at gmail.com  Sun Sep  4 19:12:24 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Sun, 4 Sep 2011 21:12:24 +0400
Subject: [Cython] non-virtual methods
In-Reply-To: <CADiQ+QBXjkVpz-ZiotUdKr=FkC2ewtOJeTCO4sgBT5G96bsoiA@mail.gmail.com>
References: <CAKGHGPSwMckJuxvORiSMMTR=vZcKvcphiBQR2aeLvWFL9Urn=w@mail.gmail.com>
	<4E569B3B.8060201@behnel.de>
	<CAKGHGPRq2GHAHjuH-gFy+N6sgfjvuP1JA6wGbQ05=03oBe4OYQ@mail.gmail.com>
	<CAKGHGPQvVMC9P=PJSoDdgu1EU8E9PKmPw4wBRCe-5j3MmOHJSQ@mail.gmail.com>
	<CAKGHGPQzmWRj=1O6dRSdYQ6d80HY7jhunr8vuxBuzLdc4qyHJg@mail.gmail.com>
	<CAKGHGPR2vCHoUg4qW0boBQ+hPFvPhF-hDM5A_kENDp8fmSh=cw@mail.gmail.com>
	<CAKGHGPTAsTzB4Y7B_=cgQH1SmXfxzLY8vMhS-tUk_9CUf=52LA@mail.gmail.com>
	<CAKGHGPTkJ3pEdX5hUt6NXv=ZqT=GMn3Jb7s9zOGaPk5MpcOM+g@mail.gmail.com>
	<CADiQ+QAdah5QFTdDdfg5fu4ibwo+g-U_UqTHe6BZAMVN==EZoQ@mail.gmail.com>
	<CAKGHGPQDbmmKmW6aiwEL3YGo+0EdJHb0B7iEeL1nQFrj8tfF1w@mail.gmail.com>
	<CADiQ+QCKW6Qv072LV_heDU6VQv5micq3mjQd9DSwsnnJ+7JFyg@mail.gmail.com>
	<CAKGHGPR+CeAtrqKcmDAg=cycLM4nWUsuR9izOt=fVbDfWDX1vQ@mail.gmail.com>
	<CADiQ+QDZtYE4kopOjYYLywHhE6v8NT-dE+m8K4K+F5=07NesNQ@mail.gmail.com>
	<4E5D10F0.2010803@behnel.de>
	<CAKGHGPTwKd1xLh5S61J06Hepk8hyhde_m4C=Ssy+duWifewmMQ@mail.gmail.com>
	<4E5D1521.6050704@behnel.de>
	<CAKGHGPQcD=0g3PghxgwHO325dZO9nCF4aDC53p9j+7-NcqCN4g@mail.gmail.com>
	<CADiQ+QBXjkVpz-ZiotUdKr=FkC2ewtOJeTCO4sgBT5G96bsoiA@mail.gmail.com>
Message-ID: <CAKGHGPRhu71mdcy5zsMb8wN6BLUwyoWL3qRnhe8axcxCQ_0Kjg@mail.gmail.com>

2011/8/30 Robert Bradshaw <robertwb at math.washington.edu>:
> On Tue, Aug 30, 2011 at 10:19 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>> 2011/8/30 Stefan Behnel <stefan_ml at behnel.de>:
>>> Vitja Makarov, 30.08.2011 18:39:
>>>>
>>>> 2011/8/30 Stefan Behnel:
>>>>>
>>>>> Robert Bradshaw, 30.08.2011 18:18:
>>>>>>
>>>>>> On Tue, Aug 30, 2011 at 9:14 AM, Vitja Makarov wrote:
>>>>>>>
>>>>>>> What about final classes with cpdef methods?
>>>>>>>
>>>>>>> @cython.final
>>>>>>> class Foo:
>>>>>>> ? ?cpdef bar(self):
>>>>>>> ? ? ? ?pass
>>>>>>>
>>>>>>> Should that raise an error?
>>>>>>
>>>>>> That should be perfectly fine.
>>>>>
>>>>> Well, the 'final' decorator shouldn't work on normal Python classes.
>>>>>
>>>>> Regarding extension types, CPython has a way of declaring them 'final'
>>>>> with
>>>>> a type flag, which effectively prevents them from being subclassed in
>>>>> Python. So the above works as just fine for cdef classes.
>>>>>
>>>>
>>>> Ok. So final class could have cpdef methods but non-final extension
>>>> type couldn't, am I right?
>>>
>>> All extension types can have cpdef methods, be they final or not. For final
>>> classes, cpdef methods simply mean that they have a Python wrapper and will
>>> otherwise be called directly when called from Cython.
>>>
>>> Actually, for cpdef methods in final classes, we can even drop the override
>>> check in the DefNode wrapper. I don't think that currently happens.
>>>
>>
>> Currently I drop OverrideCheckNode for all final cpdef methods, see
>> https://github.com/cython/cython/pull/59/files#L2R1751
>>
>> Final classes can have cpdef method that's ok.
>> Could non-final classes have final-cpdef methods?
>
> No, as we can't prevent them from being overridden (violating the
> semantics of final). We should raise an error when trying to declare
> final cpdef methods in non-final classes.
>

Ok. I get it!


>> Currently final class means that all its c[p]def methods are final too.
>
> Good point.
>

I've updated my branch. Please review:

https://github.com/cython/cython/pull/59

I've also added PyrexType.is_final_type attribute so now it should be
used to check whether type is final or not.

-- 
vitja.

From adriangeologo at yahoo.es  Mon Sep  5 18:25:44 2011
From: adriangeologo at yahoo.es (=?ISO-8859-1?Q?Adrian_Mart=EDnez_Vargas?=)
Date: Mon, 05 Sep 2011 12:25:44 -0400
Subject: [Cython] how to get a double** from  np.ndarray[double, ndim=2]
Message-ID: <4E64F808.2040400@yahoo.es>

Hi,

I would like to get a double** from a 2d numpy array in cython in order 
to call properly some function written in C++. Can some one to give a 
pure cython solution?

 From now I have a double* from the np.ndarray[double, ndim=2] .data. 
I'm getting the double array in C++ with:

     array2D_=new double* [nrows];
     for (int i=0; i<nrows; ++i)
     {
       array2D_[i]=ptr1D;
       ptr1D+=ncols;
     }

with that I'm responsible to delete the array from C++

//     delete [] this->array2D_[0];  // delete the memory pool
     delete [] this->array2D_;      // delete the row pointers

but this->array2D_[0];  is shared with the numpy array.

I think that it may be more elegant to get directly a double** from 
numpy and let to python the responsibility of managing the memory.


  Regards
Adrian Mart?nez Vargas

From d.s.seljebotn at astro.uio.no  Mon Sep  5 19:28:15 2011
From: d.s.seljebotn at astro.uio.no (Dag Sverre Seljebotn)
Date: Mon, 05 Sep 2011 19:28:15 +0200
Subject: [Cython] how to get a double** from  np.ndarray[double, ndim=2]
In-Reply-To: <4E64F808.2040400@yahoo.es>
References: <4E64F808.2040400@yahoo.es>
Message-ID: <5f51584c-3015-4265-b0b6-eecc1c6f58c3@email.android.com>

NumPy does not have a double** anywhere, what you did is the correct solution (as long as you make sure the array is C-contiguous). 
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

"Adrian Mart?nez Vargas" <adriangeologo at yahoo.es> wrote:

Hi, I would like to get a double** from a 2d numpy array in cython in order to call properly some function written in C++. Can some one to give a pure cython solution? From now I have a double* from the np.ndarray[double, ndim=2] .data. I'm getting the double array in C++ with: array2D_=new double* [nrows]; for (int i=0; i<nrows; ++i) { array2D_[i]=ptr1D; ptr1D+=ncols; } with that I'm responsible to delete the array from C++ // delete [] this->array2D_[0]; // delete the memory pool delete [] this->array2D_; // delete the row pointers but this->array2D_[0]; is shared with the numpy array. I think that it may be more elegant to get directly a double** from numpy and let to python the responsibility of managing the memory. Regards Adrian Mart?nez Vargas_____________________________________________
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/20110905/b20746d6/attachment.html>

From stefan_ml at behnel.de  Tue Sep  6 22:12:24 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Tue, 06 Sep 2011 22:12:24 +0200
Subject: [Cython] Jenkins jobs refactored
Message-ID: <4E667EA8.1020902@behnel.de>

Hi,

I replaced the half-a-ton of cython-devel jobs in Jenkins by three 
multi-configuration matrix jobs:

https://sage.math.washington.edu:8091/hudson/job/cython-devel-build/

https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests/

https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/

The sdist job that does the git checkouts is unchanged:

https://sage.math.washington.edu:8091/hudson/job/cython-devel-sdist/

This setup only slightly reduces the flexibility of the overall 
configuration, but it greatly reduces the maintenance overhead for the jobs 
and makes it much easier to keep their configuration aligned.

The only downside is that it that all build jobs must terminate before the 
tests are triggered. Given that the turn-over times are quite low, I don't 
think that's a problem. Quite the contrary, if one of the PyX.Y builds 
fails, none of the test jobs will run, which I think is a good thing.

I've disabled the old jobs and will eventually remove them when this setup 
proves to be acceptable for everyone.

Stefan

From robertwb at math.washington.edu  Tue Sep  6 22:21:07 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Tue, 6 Sep 2011 13:21:07 -0700
Subject: [Cython] Jenkins jobs refactored
In-Reply-To: <4E667EA8.1020902@behnel.de>
References: <4E667EA8.1020902@behnel.de>
Message-ID: <CADiQ+QATBvSYA_fJqdkO=Q=UFmxcOtz6dEA2+E9xLKG9R0S5Rg@mail.gmail.com>

On Tue, Sep 6, 2011 at 1:12 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Hi,
>
> I replaced the half-a-ton of cython-devel jobs in Jenkins by three
> multi-configuration matrix jobs:
>
> https://sage.math.washington.edu:8091/hudson/job/cython-devel-build/
>
> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests/
>
> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/
>
> The sdist job that does the git checkouts is unchanged:
>
> https://sage.math.washington.edu:8091/hudson/job/cython-devel-sdist/
>
> This setup only slightly reduces the flexibility of the overall
> configuration, but it greatly reduces the maintenance overhead for the jobs
> and makes it much easier to keep their configuration aligned.

Nice.

> The only downside is that it that all build jobs must terminate before the
> tests are triggered. Given that the turn-over times are quite low, I don't
> think that's a problem. Quite the contrary, if one of the PyX.Y builds
> fails, none of the test jobs will run, which I think is a good thing.

The one drawback is this seems to make it hard to implement the idea
of testing 2.4, 2.7, and 3.2 before building and testing all the rest
for quicker feedback?

> I've disabled the old jobs and will eventually remove them when this setup
> proves to be acceptable for everyone.
>
> Stefan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

From stefan_ml at behnel.de  Tue Sep  6 22:58:28 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Tue, 06 Sep 2011 22:58:28 +0200
Subject: [Cython] Jenkins jobs refactored
In-Reply-To: <CADiQ+QATBvSYA_fJqdkO=Q=UFmxcOtz6dEA2+E9xLKG9R0S5Rg@mail.gmail.com>
References: <4E667EA8.1020902@behnel.de>
	<CADiQ+QATBvSYA_fJqdkO=Q=UFmxcOtz6dEA2+E9xLKG9R0S5Rg@mail.gmail.com>
Message-ID: <4E668974.708@behnel.de>

Robert Bradshaw, 06.09.2011 22:21:
> On Tue, Sep 6, 2011 at 1:12 PM, Stefan Behnel wrote:
>> I replaced the half-a-ton of cython-devel jobs in Jenkins by three
>> multi-configuration matrix jobs:
>>
>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-build/
>>
>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests/
>>
>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/
>>
>> The sdist job that does the git checkouts is unchanged:
>>
>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-sdist/
>>
>> This setup only slightly reduces the flexibility of the overall
>> configuration, but it greatly reduces the maintenance overhead for the jobs
>> and makes it much easier to keep their configuration aligned.
>
> Nice.
>
>> The only downside is that it that all build jobs must terminate before the
>> tests are triggered. Given that the turn-over times are quite low, I don't
>> think that's a problem. Quite the contrary, if one of the PyX.Y builds
>> fails, none of the test jobs will run, which I think is a good thing.
>
> The one drawback is this seems to make it hard to implement the idea
> of testing 2.4, 2.7, and 3.2 before building and testing all the rest
> for quicker feedback?

Partly. All build jobs will have to terminate first, yes, but Jenkins has a 
notion of a "touchstone build", which allows to configure certain builds in 
the matrix that should run first. So, after all PyX.Y builds are ready, 
Py2.4/7 and Py3k will be tested first. That way, the feedback is a little 
slower than today, but it still prefers the important platforms.

Stefan

From robertwb at math.washington.edu  Tue Sep  6 23:03:38 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Tue, 6 Sep 2011 14:03:38 -0700
Subject: [Cython] Jenkins jobs refactored
In-Reply-To: <4E668974.708@behnel.de>
References: <4E667EA8.1020902@behnel.de>
	<CADiQ+QATBvSYA_fJqdkO=Q=UFmxcOtz6dEA2+E9xLKG9R0S5Rg@mail.gmail.com>
	<4E668974.708@behnel.de>
Message-ID: <CADiQ+QCtTm+4qgkSfaW-EmczcGAbNOh3irjaOEFP5UbXsdSNyQ@mail.gmail.com>

On Tue, Sep 6, 2011 at 1:58 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Robert Bradshaw, 06.09.2011 22:21:
>>
>> On Tue, Sep 6, 2011 at 1:12 PM, Stefan Behnel wrote:
>>>
>>> I replaced the half-a-ton of cython-devel jobs in Jenkins by three
>>> multi-configuration matrix jobs:
>>>
>>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-build/
>>>
>>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests/
>>>
>>>
>>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/
>>>
>>> The sdist job that does the git checkouts is unchanged:
>>>
>>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-sdist/
>>>
>>> This setup only slightly reduces the flexibility of the overall
>>> configuration, but it greatly reduces the maintenance overhead for the
>>> jobs
>>> and makes it much easier to keep their configuration aligned.
>>
>> Nice.
>>
>>> The only downside is that it that all build jobs must terminate before
>>> the
>>> tests are triggered. Given that the turn-over times are quite low, I
>>> don't
>>> think that's a problem. Quite the contrary, if one of the PyX.Y builds
>>> fails, none of the test jobs will run, which I think is a good thing.
>>
>> The one drawback is this seems to make it hard to implement the idea
>> of testing 2.4, 2.7, and 3.2 before building and testing all the rest
>> for quicker feedback?
>
> Partly. All build jobs will have to terminate first, yes, but Jenkins has a
> notion of a "touchstone build", which allows to configure certain builds in
> the matrix that should run first. So, after all PyX.Y builds are ready,
> Py2.4/7 and Py3k will be tested first. That way, the feedback is a little
> slower than today, but it still prefers the important platforms.

That sounds find. If the build breaks, I'm fine with forcing that to
be fixed before going on to testing.

- Robert

From romain.py at gmail.com  Thu Sep  8 06:18:24 2011
From: romain.py at gmail.com (Romain Guillebert)
Date: Thu, 8 Sep 2011 06:18:24 +0200
Subject: [Cython] CTypes backend for Cython Status
Message-ID: <20110908041824.GA29645@ubuntu>

Hi

The Google Summer of Code has ended and I didn't give the current status
to anyone yet (I was very busy with a report I had to write for my
university).

There is still work to do on the project (there was more work than I
expected, especially because of semantic differences between Cython and
ctypes) so I'll talk about what needs to be done (even if it does not
sound good compared to talking about what has been done) from the most
important to the least important in my opinion :

- Pointer vs Array, Cython mixes the two while ctypes does not, this
  can probably be fixed by using arrays everywhere (if we can convert
  pointers into arrays)
- Take into account header files declared globally
- Macros, this is probably the biggest part but it's doable, Cython has
  the types of the arguments and the return value so it's possible to
  generate a C function corresponding to a macro
- Pointer to functions

Some of them are trivial, others just require good ideas and macros
demands a big amount of work.
I'm still working on it and if someone wants to give a hand, I'll be
happy to explain what I've done.

Thanks
Romain

From cgohlke at uci.edu  Fri Sep  9 09:28:05 2011
From: cgohlke at uci.edu (Christoph Gohlke)
Date: Fri, 09 Sep 2011 00:28:05 -0700
Subject: [Cython] Error when using Intel icl compiler on Windows
Message-ID: <4E69C005.3040808@uci.edu>

Hello,

compiling Cython 0.15 generated C code on Windows using the Intel 
Compiler 11.1 icl.exe results in an "expected a type specifier" error.

For example:

/* "numpy.pxd":190
  *         # experimental exception made for __getbuffer__ and 
__releasebuffer__
  *         # -- the details of this may change.
  *         def __getbuffer__(ndarray self, Py_buffer* info, int flags): 
             # <<<<<<<<<<<<<<
  *             # This implementation of getbuffer is geared towards Cython
  *             # requirements, and does not yet fullfill the PEP.
  */

static CYTHON_UNUSED int __pyx_pf_5numpy_7ndarray___getbuffer__(PyObject 
*__pyx_v_self, Py_buffer *__pyx_v_info, int __pyx_v_flags); /*proto*/
        ^
Error: expected a type specifier.

The problem is the definition of CYTHON_UNUSED.

Please consider the attached patch. It works for me but maybe the 
problem is icl version specific, not Windows specific.

Christoph
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: icl-win.diff
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20110909/432abf16/attachment.ksh>

From robertwb at math.washington.edu  Fri Sep  9 10:26:00 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Fri, 9 Sep 2011 01:26:00 -0700
Subject: [Cython] Error when using Intel icl compiler on Windows
In-Reply-To: <4E69C005.3040808@uci.edu>
References: <4E69C005.3040808@uci.edu>
Message-ID: <CADiQ+QCp1FBWYVKibdwJX7CwDmtiwRq+wqYuQ9wCgwHU1ziw+w@mail.gmail.com>

Does it work with icc if you replace

 #   define CYTHON_UNUSED __attribute__ ((__unused__))

with

 #   define CYTHON_UNUSED __attribute__ ((unused))

?


On Fri, Sep 9, 2011 at 12:28 AM, Christoph Gohlke <cgohlke at uci.edu> wrote:
> Hello,
>
> compiling Cython 0.15 generated C code on Windows using the Intel Compiler
> 11.1 icl.exe results in an "expected a type specifier" error.
>
> For example:
>
> /* "numpy.pxd":190
> ?* ? ? ? ? # experimental exception made for __getbuffer__ and
> __releasebuffer__
> ?* ? ? ? ? # -- the details of this may change.
> ?* ? ? ? ? def __getbuffer__(ndarray self, Py_buffer* info, int flags):
> ? ? ? ? # <<<<<<<<<<<<<<
> ?* ? ? ? ? ? ? # This implementation of getbuffer is geared towards Cython
> ?* ? ? ? ? ? ? # requirements, and does not yet fullfill the PEP.
> ?*/
>
> static CYTHON_UNUSED int __pyx_pf_5numpy_7ndarray___getbuffer__(PyObject
> *__pyx_v_self, Py_buffer *__pyx_v_info, int __pyx_v_flags); /*proto*/
> ? ? ? ^
> Error: expected a type specifier.
>
> The problem is the definition of CYTHON_UNUSED.
>
> Please consider the attached patch. It works for me but maybe the problem is
> icl version specific, not Windows specific.
>
> Christoph
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>
>

From stefan_ml at behnel.de  Fri Sep  9 10:35:20 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 09 Sep 2011 10:35:20 +0200
Subject: [Cython] CTypes backend for Cython Status
In-Reply-To: <20110908041824.GA29645@ubuntu>
References: <20110908041824.GA29645@ubuntu>
Message-ID: <4E69CFC8.5080404@behnel.de>

Hi Romain,

thanks for the feedback.

Romain Guillebert, 08.09.2011 06:18:
> The Google Summer of Code has ended and I didn't give the current status
> to anyone yet (I was very busy with a report I had to write for my
> university).
>
> There is still work to do on the project (there was more work than I
> expected, especially because of semantic differences between Cython and
> ctypes) so I'll talk about what needs to be done (even if it does not
> sound good compared to talking about what has been done) from the most
> important to the least important in my opinion :
>
> - Pointer vs Array, Cython mixes the two while ctypes does not, this
>    can probably be fixed by using arrays everywhere (if we can convert
>    pointers into arrays)

Could you elaborate on this? Why can't you always use pointers?


> - Take into account header files declared globally

"globally" as in ... ?

And what exactly do you mean by "take header files into account"?


> - Macros, this is probably the biggest part but it's doable, Cython has
>    the types of the arguments and the return value so it's possible to
>    generate a C function corresponding to a macro

Agreed. I think that's the only viable solution. Won't work for all macros, 
but at least for a rather large number of them.


> - Pointer to functions

I take it this isn't implemented at all? Do you mean pointers to Cython 
cdef functions or also to external C defined functions?


> Some of them are trivial, others just require good ideas and macros
> demands a big amount of work.

Really? Apart from generating the rather straight forward wrapper functions 
for them, what else needs to be done?


> I'm still working on it and if someone wants to give a hand, I'll be
> happy to explain what I've done.

Happy to hear that.

Stefan

From cgohlke at uci.edu  Fri Sep  9 10:34:02 2011
From: cgohlke at uci.edu (Christoph Gohlke)
Date: Fri, 09 Sep 2011 01:34:02 -0700
Subject: [Cython] Error when using Intel icl compiler on Windows
In-Reply-To: <CADiQ+QCp1FBWYVKibdwJX7CwDmtiwRq+wqYuQ9wCgwHU1ziw+w@mail.gmail.com>
References: <4E69C005.3040808@uci.edu>
	<CADiQ+QCp1FBWYVKibdwJX7CwDmtiwRq+wqYuQ9wCgwHU1ziw+w@mail.gmail.com>
Message-ID: <4E69CF7A.40804@uci.edu>

No, sorry. Same error.

Christoph


On 9/9/2011 1:26 AM, Robert Bradshaw wrote:
> Does it work with icc if you replace
>
>   #   define CYTHON_UNUSED __attribute__ ((__unused__))
>
> with
>
>   #   define CYTHON_UNUSED __attribute__ ((unused))
>
> ?
>
>
> On Fri, Sep 9, 2011 at 12:28 AM, Christoph Gohlke<cgohlke at uci.edu>  wrote:
>> Hello,
>>
>> compiling Cython 0.15 generated C code on Windows using the Intel Compiler
>> 11.1 icl.exe results in an "expected a type specifier" error.
>>
>> For example:
>>
>> /* "numpy.pxd":190
>>   *         # experimental exception made for __getbuffer__ and
>> __releasebuffer__
>>   *         # -- the details of this may change.
>>   *         def __getbuffer__(ndarray self, Py_buffer* info, int flags):
>>          #<<<<<<<<<<<<<<
>>   *             # This implementation of getbuffer is geared towards Cython
>>   *             # requirements, and does not yet fullfill the PEP.
>>   */
>>
>> static CYTHON_UNUSED int __pyx_pf_5numpy_7ndarray___getbuffer__(PyObject
>> *__pyx_v_self, Py_buffer *__pyx_v_info, int __pyx_v_flags); /*proto*/
>>        ^
>> Error: expected a type specifier.
>>
>> The problem is the definition of CYTHON_UNUSED.
>>
>> Please consider the attached patch. It works for me but maybe the problem is
>> icl version specific, not Windows specific.
>>
>> Christoph
>>
>> _______________________________________________
>> 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 romain.py at gmail.com  Fri Sep  9 23:41:30 2011
From: romain.py at gmail.com (Romain Guillebert)
Date: Fri, 9 Sep 2011 23:41:30 +0200
Subject: [Cython] CTypes backend for Cython Status
In-Reply-To: <4E69CFC8.5080404@behnel.de>
References: <20110908041824.GA29645@ubuntu>
 <4E69CFC8.5080404@behnel.de>
Message-ID: <20110909214130.GA20146@ubuntu>

Hi Stefan

On Fri, Sep 09, 2011 at 10:35:20AM +0200, Stefan Behnel wrote:
> Hi Romain,
> 
> thanks for the feedback.
> 
> Romain Guillebert, 08.09.2011 06:18:
> >The Google Summer of Code has ended and I didn't give the current status
> >to anyone yet (I was very busy with a report I had to write for my
> >university).
> >
> >There is still work to do on the project (there was more work than I
> >expected, especially because of semantic differences between Cython and
> >ctypes) so I'll talk about what needs to be done (even if it does not
> >sound good compared to talking about what has been done) from the most
> >important to the least important in my opinion :
> >
> >- Pointer vs Array, Cython mixes the two while ctypes does not, this
> >   can probably be fixed by using arrays everywhere (if we can convert
> >   pointers into arrays)
> 
> Could you elaborate on this? Why can't you always use pointers?
> 

You can't do array indexing on ctypes pointers (and no straightforward
pointer arithmetic either)

> 
> >- Take into account header files declared globally
> 
> "globally" as in ... ?
> 
> And what exactly do you mean by "take header files into account"?
> 

Take into account : pass to ctypes_configure

And I didn't want to say globally, but right now I only pass to
ctypes_configure the header file given by "cdef extern from" and from my
tests it's not enough

> 
> >- Macros, this is probably the biggest part but it's doable, Cython has
> >   the types of the arguments and the return value so it's possible to
> >   generate a C function corresponding to a macro
> 
> Agreed. I think that's the only viable solution. Won't work for all
> macros, but at least for a rather large number of them.
> 
> 
> >- Pointer to functions
> 
> I take it this isn't implemented at all? Do you mean pointers to
> Cython cdef functions or also to external C defined functions?
> 

Pointer to cdefed functions and pointers to function returned by C
functions (although I don't know for the later but it would surprise me)

> 
> >Some of them are trivial, others just require good ideas and macros
> >demands a big amount of work.
> 
> Really? Apart from generating the rather straight forward wrapper
> functions for them, what else needs to be done?
> 

You have to include the right headers and take care of the types (if a type
is ctypedefed there's probably something to do)

> 
> >I'm still working on it and if someone wants to give a hand, I'll be
> >happy to explain what I've done.
> 
> Happy to hear that.
> 
> Stefan

Romain

From wesmckinn at gmail.com  Sat Sep 10 00:09:16 2011
From: wesmckinn at gmail.com (Wes McKinney)
Date: Fri, 9 Sep 2011 18:09:16 -0400
Subject: [Cython] Cython problems on OS X Lion
Message-ID: <CAJPUwMBiXUkKpYmczt0VeNGJ9CM-P0P941hqFZMq0Qq=Wq=hqA@mail.gmail.com>

Multiple users have reporting being unable to get the Cython
extensions in pandas to work:

http://github.com/wesm/pandas

Here is the traceback:

In [1]: import pandas
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)
/Users/fonnescj/<ipython-input-1-d6ac987968b6> in <module>()
----> 1 import pandas
/Library/Python/2.7/site-packages/pandas-0.4.0.dev_a2c7284_20110905-py2.7-macosx-10.7-x86_64.egg/pandas/__init__.py
in <module>()
10 from pandas.info import __doc__
11
---> 12 from pandas.core.api import *
13 from pandas.core.common import set_printoptions
14 from pandas.io.parsers import read_csv, read_table, ExcelFile
/Library/Python/2.7/site-packages/pandas-0.4.0.dev_a2c7284_20110905-py2.7-macosx-10.7-x86_64.egg/pandas/core/api.py
in <module>()
 6 import pandas.core.datetools as datetools
 7
----> 8 from pandas.core.common import isnull, notnull, set_printoptions
 9 from pandas.core.index import Index, Factor, MultiIndex
10 from pandas.core.daterange import DateRange
/Library/Python/2.7/site-packages/pandas-0.4.0.dev_a2c7284_20110905-py2.7-macosx-10.7-x86_64.egg/pandas/core/common.py
in <module>()
 9 import numpy as np
10
---> 11 import pandas._tseries as _tseries
12
13 # XXX: HACK for NumPy 1.5.1 to suppress warnings
ImportError: dynamic module does not define init function (init_tseries)

Anyone on the Cython dev team have a 10.7 Lion machine to help me
debug this? I haven't had time to backup and upgrade my laptop yet. As
far as I can tell this is the only platform which has problems-- OS X
<= 10.6, Windows 32/64, Linux 64-bit all work fine.

Are there any known issues with Lion?

Thanks,
Wes

From stefan_ml at behnel.de  Sat Sep 10 08:04:14 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 10 Sep 2011 08:04:14 +0200
Subject: [Cython] [cython-users] How best to determine what *should*
 compile properly with Cython?
In-Reply-To: <4E69BF0C.9050907@behnel.de>
References: <ab9764d4-7965-4b25-867d-f341c294e78a@h14g2000yqi.googlegroups.com>
	<4E69BF0C.9050907@behnel.de>
Message-ID: <4E6AFDDE.20300@behnel.de>

Stefan Behnel, 09.09.2011 09:23:
> I just noticed that Jenkins does not currently aggregate the test results
> for the source build job "cython-devel-sdist", which you can find here:
>
> https://sage.math.washington.edu:8091/hudson/job/cython-devel-sdist/
>
> I'll see if I can fix that somehow.

This is unfortunately an open bug in Jenkins:

https://issues.jenkins-ci.org/browse/JENKINS-7976

Stefan

From vitja.makarov at gmail.com  Sat Sep 10 17:11:41 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Sat, 10 Sep 2011 19:11:41 +0400
Subject: [Cython] Jenkins jobs refactored
In-Reply-To: <CADiQ+QCtTm+4qgkSfaW-EmczcGAbNOh3irjaOEFP5UbXsdSNyQ@mail.gmail.com>
References: <4E667EA8.1020902@behnel.de>
	<CADiQ+QATBvSYA_fJqdkO=Q=UFmxcOtz6dEA2+E9xLKG9R0S5Rg@mail.gmail.com>
	<4E668974.708@behnel.de>
	<CADiQ+QCtTm+4qgkSfaW-EmczcGAbNOh3irjaOEFP5UbXsdSNyQ@mail.gmail.com>
Message-ID: <CAKGHGPREQYfg_Q7HT9dGn1qawc7wHXAvgQX_oSn-dJKB-t_6oQ@mail.gmail.com>

2011/9/7 Robert Bradshaw <robertwb at math.washington.edu>:
> On Tue, Sep 6, 2011 at 1:58 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
>> Robert Bradshaw, 06.09.2011 22:21:
>>>
>>> On Tue, Sep 6, 2011 at 1:12 PM, Stefan Behnel wrote:
>>>>
>>>> I replaced the half-a-ton of cython-devel jobs in Jenkins by three
>>>> multi-configuration matrix jobs:
>>>>
>>>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-build/
>>>>
>>>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests/
>>>>
>>>>
>>>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/
>>>>
>>>> The sdist job that does the git checkouts is unchanged:
>>>>
>>>> https://sage.math.washington.edu:8091/hudson/job/cython-devel-sdist/
>>>>
>>>> This setup only slightly reduces the flexibility of the overall
>>>> configuration, but it greatly reduces the maintenance overhead for the
>>>> jobs
>>>> and makes it much easier to keep their configuration aligned.
>>>
>>> Nice.
>>>
>>>> The only downside is that it that all build jobs must terminate before
>>>> the
>>>> tests are triggered. Given that the turn-over times are quite low, I
>>>> don't
>>>> think that's a problem. Quite the contrary, if one of the PyX.Y builds
>>>> fails, none of the test jobs will run, which I think is a good thing.
>>>
>>> The one drawback is this seems to make it hard to implement the idea
>>> of testing 2.4, 2.7, and 3.2 before building and testing all the rest
>>> for quicker feedback?
>>
>> Partly. All build jobs will have to terminate first, yes, but Jenkins has a
>> notion of a "touchstone build", which allows to configure certain builds in
>> the matrix that should run first. So, after all PyX.Y builds are ready,
>> Py2.4/7 and Py3k will be tested first. That way, the feedback is a little
>> slower than today, but it still prefers the important platforms.
>
> That sounds find. If the build breaks, I'm fine with forcing that to
> be fixed before going on to testing.
>

https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/BACKEND=c,PYVERSION=py27/

This job shows strange results. ~3K tests and ~400 errors

In previous one it was 11K and 170

-- 
vitja.

From stefan_ml at behnel.de  Sat Sep 10 18:46:34 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 10 Sep 2011 18:46:34 +0200
Subject: [Cython] Jenkins jobs refactored
In-Reply-To: <CAKGHGPREQYfg_Q7HT9dGn1qawc7wHXAvgQX_oSn-dJKB-t_6oQ@mail.gmail.com>
References: <4E667EA8.1020902@behnel.de>	<CADiQ+QATBvSYA_fJqdkO=Q=UFmxcOtz6dEA2+E9xLKG9R0S5Rg@mail.gmail.com>	<4E668974.708@behnel.de>	<CADiQ+QCtTm+4qgkSfaW-EmczcGAbNOh3irjaOEFP5UbXsdSNyQ@mail.gmail.com>
	<CAKGHGPREQYfg_Q7HT9dGn1qawc7wHXAvgQX_oSn-dJKB-t_6oQ@mail.gmail.com>
Message-ID: <4E6B946A.6080004@behnel.de>

Vitja Makarov, 10.09.2011 17:11:
> https://sage.math.washington.edu:8091/hudson/job/cython-devel-tests-pyregr/BACKEND=c,PYVERSION=py27/
>
> This job shows strange results. ~3K tests and ~400 errors
>
> In previous one it was 11K and 170

Right. Not sure what exactly went wrong, but it seems to work better now.

Stefan

From robertwb at math.washington.edu  Sat Sep 10 22:58:11 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Sat, 10 Sep 2011 13:58:11 -0700
Subject: [Cython] Cython problems on OS X Lion
In-Reply-To: <CAJPUwMBiXUkKpYmczt0VeNGJ9CM-P0P941hqFZMq0Qq=Wq=hqA@mail.gmail.com>
References: <CAJPUwMBiXUkKpYmczt0VeNGJ9CM-P0P941hqFZMq0Qq=Wq=hqA@mail.gmail.com>
Message-ID: <CADiQ+QDRA0-Ye5uD2xSH1_eQx1UgS78yrjuhBi6_N9YQJAZXOQ@mail.gmail.com>

I don't have 10.7, but might be able to borrow a computer that does.
This sounds more like a linking/C compilation problem than a Cython
issue though. Do the programs in the Cython's demos directory work for
you?

On Fri, Sep 9, 2011 at 3:09 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
> Multiple users have reporting being unable to get the Cython
> extensions in pandas to work:
>
> http://github.com/wesm/pandas
>
> Here is the traceback:
>
> In [1]: import pandas
> ---------------------------------------------------------------------------
> ImportError Traceback (most recent call last)
> /Users/fonnescj/<ipython-input-1-d6ac987968b6> in <module>()
> ----> 1 import pandas
> /Library/Python/2.7/site-packages/pandas-0.4.0.dev_a2c7284_20110905-py2.7-macosx-10.7-x86_64.egg/pandas/__init__.py
> in <module>()
> 10 from pandas.info import __doc__
> 11
> ---> 12 from pandas.core.api import *
> 13 from pandas.core.common import set_printoptions
> 14 from pandas.io.parsers import read_csv, read_table, ExcelFile
> /Library/Python/2.7/site-packages/pandas-0.4.0.dev_a2c7284_20110905-py2.7-macosx-10.7-x86_64.egg/pandas/core/api.py
> in <module>()
> ?6 import pandas.core.datetools as datetools
> ?7
> ----> 8 from pandas.core.common import isnull, notnull, set_printoptions
> ?9 from pandas.core.index import Index, Factor, MultiIndex
> 10 from pandas.core.daterange import DateRange
> /Library/Python/2.7/site-packages/pandas-0.4.0.dev_a2c7284_20110905-py2.7-macosx-10.7-x86_64.egg/pandas/core/common.py
> in <module>()
> ?9 import numpy as np
> 10
> ---> 11 import pandas._tseries as _tseries
> 12
> 13 # XXX: HACK for NumPy 1.5.1 to suppress warnings
> ImportError: dynamic module does not define init function (init_tseries)
>
> Anyone on the Cython dev team have a 10.7 Lion machine to help me
> debug this? I haven't had time to backup and upgrade my laptop yet. As
> far as I can tell this is the only platform which has problems-- OS X
> <= 10.6, Windows 32/64, Linux 64-bit all work fine.
>
> Are there any known issues with Lion?
>
> Thanks,
> Wes
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

From wesmckinn at gmail.com  Sat Sep 10 23:15:52 2011
From: wesmckinn at gmail.com (Wes McKinney)
Date: Sat, 10 Sep 2011 17:15:52 -0400
Subject: [Cython] Cython problems on OS X Lion
In-Reply-To: <CADiQ+QDRA0-Ye5uD2xSH1_eQx1UgS78yrjuhBi6_N9YQJAZXOQ@mail.gmail.com>
References: <CAJPUwMBiXUkKpYmczt0VeNGJ9CM-P0P941hqFZMq0Qq=Wq=hqA@mail.gmail.com>
	<CADiQ+QDRA0-Ye5uD2xSH1_eQx1UgS78yrjuhBi6_N9YQJAZXOQ@mail.gmail.com>
Message-ID: <CAJPUwMBr7bnjfr2ESEQ_1XRiLuR7Mi6apjRdixu7MiBWVWd1pw@mail.gmail.com>

On Sat, Sep 10, 2011 at 4:58 PM, Robert Bradshaw
<robertwb at math.washington.edu> wrote:
> I don't have 10.7, but might be able to borrow a computer that does.
> This sounds more like a linking/C compilation problem than a Cython
> issue though. Do the programs in the Cython's demos directory work for
> you?
>
> On Fri, Sep 9, 2011 at 3:09 PM, Wes McKinney <wesmckinn at gmail.com> wrote:
>> Multiple users have reporting being unable to get the Cython
>> extensions in pandas to work:
>>
>> http://github.com/wesm/pandas
>>
>> Here is the traceback:
>>
>> In [1]: import pandas
>> ---------------------------------------------------------------------------
>> ImportError Traceback (most recent call last)
>> /Users/fonnescj/<ipython-input-1-d6ac987968b6> in <module>()
>> ----> 1 import pandas
>> /Library/Python/2.7/site-packages/pandas-0.4.0.dev_a2c7284_20110905-py2.7-macosx-10.7-x86_64.egg/pandas/__init__.py
>> in <module>()
>> 10 from pandas.info import __doc__
>> 11
>> ---> 12 from pandas.core.api import *
>> 13 from pandas.core.common import set_printoptions
>> 14 from pandas.io.parsers import read_csv, read_table, ExcelFile
>> /Library/Python/2.7/site-packages/pandas-0.4.0.dev_a2c7284_20110905-py2.7-macosx-10.7-x86_64.egg/pandas/core/api.py
>> in <module>()
>> ?6 import pandas.core.datetools as datetools
>> ?7
>> ----> 8 from pandas.core.common import isnull, notnull, set_printoptions
>> ?9 from pandas.core.index import Index, Factor, MultiIndex
>> 10 from pandas.core.daterange import DateRange
>> /Library/Python/2.7/site-packages/pandas-0.4.0.dev_a2c7284_20110905-py2.7-macosx-10.7-x86_64.egg/pandas/core/common.py
>> in <module>()
>> ?9 import numpy as np
>> 10
>> ---> 11 import pandas._tseries as _tseries
>> 12
>> 13 # XXX: HACK for NumPy 1.5.1 to suppress warnings
>> ImportError: dynamic module does not define init function (init_tseries)
>>
>> Anyone on the Cython dev team have a 10.7 Lion machine to help me
>> debug this? I haven't had time to backup and upgrade my laptop yet. As
>> far as I can tell this is the only platform which has problems-- OS X
>> <= 10.6, Windows 32/64, Linux 64-bit all work fine.
>>
>> Are there any known issues with Lion?
>>
>> Thanks,
>> Wes
>> _______________________________________________
>> 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
>

I agree it's probably a compiler/linker problem with distutils or
something of that nature. I unfortunately don't have easy access to a
Lion computer. Maybe time to upgrade my laptop.

From vitja.makarov at gmail.com  Sun Sep 11 07:32:54 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Sun, 11 Sep 2011 09:32:54 +0400
Subject: [Cython] Bugfix release
Message-ID: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>

Are we going to make a bugfix release?

There are some critical bugs in 0.15, T725 for example.
Think we should port fixes back to 0.15 and then release it as 0.15.1

-- 
vitja.

From robertwb at math.washington.edu  Sun Sep 11 07:54:36 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Sat, 10 Sep 2011 22:54:36 -0700
Subject: [Cython] Bugfix release
In-Reply-To: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>
Message-ID: <CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>

+1 to another release soon. Is there anything in the devel branch
that's not ready to go out? (I was also thinking of doing a release as
soon as fused functions and memory views got in.)

On Sat, Sep 10, 2011 at 10:32 PM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> Are we going to make a bugfix release?
>
> There are some critical bugs in 0.15, T725 for example.
> Think we should port fixes back to 0.15 and then release it as 0.15.1
>
> --
> vitja.
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

From markflorisson88 at gmail.com  Sun Sep 11 10:11:00 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Sun, 11 Sep 2011 10:11:00 +0200
Subject: [Cython] Bugfix release
In-Reply-To: <CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>
	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
Message-ID: <CANg26EU0ToAKYzkWQ+1tyxJud05_NOfEDi4dSFpktbndTJHKmQ@mail.gmail.com>

On 11 September 2011 07:54, Robert Bradshaw
<robertwb at math.washington.edu> wrote:
> +1 to another release soon. Is there anything in the devel branch
> that's not ready to go out? (I was also thinking of doing a release as
> soon as fused functions and memory views got in.)
>
> On Sat, Sep 10, 2011 at 10:32 PM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>> Are we going to make a bugfix release?
>>
>> There are some critical bugs in 0.15, T725 for example.
>> Think we should port fixes back to 0.15 and then release it as 0.15.1
>>
>> --
>> vitja.
>> _______________________________________________
>> 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
>

Once memoryviews are in I'll complete merging fused function and
CyFunction, so we can support the functionality of fused types (and
not just fused cdef functions). I also notice that the syntax
discussion was held after fused cdef support was completed, so the
syntax of fused types changed after the pull request, so I'll cancel
that pull request.

From stefan_ml at behnel.de  Sun Sep 11 13:33:50 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 11 Sep 2011 13:33:50 +0200
Subject: [Cython] Bugfix release
In-Reply-To: <CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>
	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
Message-ID: <4E6C9C9E.3000707@behnel.de>

Robert Bradshaw, 11.09.2011 07:54:
> On Sat, Sep 10, 2011 at 10:32 PM, Vitja Makarov wrote:
>> Are we going to make a bugfix release?
>>
>> There are some critical bugs in 0.15, T725 for example.

Yes, and some others.


>> Think we should port fixes back to 0.15 and then release it as 0.15.1

+1


> +1 to another release soon. Is there anything in the devel branch
> that's not ready to go out?

Yes, the current state of my decorator changes breaks code in Sage. I 
wouldn't know of anything else, so maybe it's enough to back those changes 
out from a branch and otherwise keep the state that we have now.


> (I was also thinking of doing a release as
> soon as fused functions and memory views got in.)

That would be 0.16.

Stefan

From stefan_ml at behnel.de  Sun Sep 11 13:45:13 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 11 Sep 2011 13:45:13 +0200
Subject: [Cython] Bugfix release
In-Reply-To: <4E6C9C9E.3000707@behnel.de>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
	<4E6C9C9E.3000707@behnel.de>
Message-ID: <4E6C9F49.8070804@behnel.de>

Stefan Behnel, 11.09.2011 13:33:
> Robert Bradshaw, 11.09.2011 07:54:
>> Is there anything in the devel branch that's not ready to go out?
>
> Yes, the current state of my decorator changes breaks code in Sage. I
> wouldn't know of anything else, so maybe it's enough to back those changes
> out from a branch and otherwise keep the state that we have now.

Oh, and the PEP-393 stuff isn't necessarily good for a release, given that 
the implementation in CPython is not finished and still subject to changes.

But that can easily be disabled by unsetting CYTHON_PEP393_ENABLED macro in 
the release.

Stefan

From stefan_ml at behnel.de  Sun Sep 11 15:08:15 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 11 Sep 2011 15:08:15 +0200
Subject: [Cython] Bugfix release
In-Reply-To: <4E6C9C9E.3000707@behnel.de>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
	<4E6C9C9E.3000707@behnel.de>
Message-ID: <4E6CB2BF.5000806@behnel.de>

Stefan Behnel, 11.09.2011 13:33:
> Robert Bradshaw, 11.09.2011 07:54:
>> On Sat, Sep 10, 2011 at 10:32 PM, Vitja Makarov wrote:
>>> Are we going to make a bugfix release?
>>> There are some critical bugs in 0.15, T725 for example.
>
> Yes, and some others.
>
>>> Think we should port fixes back to 0.15 and then release it as 0.15.1
>
> +1
>
>
>> +1 to another release soon. Is there anything in the devel branch
>> that's not ready to go out?
>
> Yes, the current state of my decorator changes breaks code in Sage. I
> wouldn't know of anything else, so maybe it's enough to back those changes
> out from a branch and otherwise keep the state that we have now.

... especially given that the list of fixes that are scheduled for the next 
release is not exactly short, and some fixes spread over more than one 
commit, so there'd be a lot to merge over.

http://trac.cython.org/cython_trac/query?status=assigned&status=closed&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&milestone=0.15.1&col=owner

A problem with the current master branch is that we already dropped support 
for Py2.3 in it...

I see two ways to get a release out: create a branch from the current 
master and remove from it what we don't consider stable (or 'right' for 
that release), or merge the most important and easily mergeable changes 
over to the current release branch for 0.15.1 and leave the rest to a 
not-so-far-in-the future 0.16.

Personally, I vote for the latter, because I think we should rather try to 
get 0.16 out soon and not put too much work into 0.15.1. There were enough 
changes in master (and potentially some more in the open pull requests) to 
merit a 0.16. And I certainly wouldn't mind keeping the list of changes in 
a main release a little shorter.

Stefan

From stefan_ml at behnel.de  Sun Sep 11 16:01:03 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 11 Sep 2011 16:01:03 +0200
Subject: [Cython] Bugfix release
In-Reply-To: <4E6CB2BF.5000806@behnel.de>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>	<4E6C9C9E.3000707@behnel.de>
	<4E6CB2BF.5000806@behnel.de>
Message-ID: <4E6CBF1F.9020307@behnel.de>

Stefan Behnel, 11.09.2011 15:08:
> I see two ways to get a release out: create a branch from the current
> master and remove from it what we don't consider stable (or 'right' for
> that release), or merge the most important and easily mergeable changes
> over to the current release branch for 0.15.1 and leave the rest to a
> not-so-far-in-the future 0.16.
>
> Personally, I vote for the latter, because I think we should rather try to
> get 0.16 out soon and not put too much work into 0.15.1.

I selected the list of changes that I considered safe and important, and 
transplanted them into the release branch.

Please check if there is anything missing that's should go into a bug fix 
release.

Stefan

From vitja.makarov at gmail.com  Sun Sep 11 16:13:38 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Sun, 11 Sep 2011 18:13:38 +0400
Subject: [Cython] Bugfix release
In-Reply-To: <4E6CB2BF.5000806@behnel.de>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>
	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
	<4E6C9C9E.3000707@behnel.de> <4E6CB2BF.5000806@behnel.de>
Message-ID: <CAKGHGPQ9C7q0p9qQ1XGxwKannUQzGw4ND_Msfka00uvT62n+Zg@mail.gmail.com>

2011/9/11 Stefan Behnel <stefan_ml at behnel.de>:
> Stefan Behnel, 11.09.2011 13:33:
>>
>> Robert Bradshaw, 11.09.2011 07:54:
>>>
>>> On Sat, Sep 10, 2011 at 10:32 PM, Vitja Makarov wrote:
>>>>
>>>> Are we going to make a bugfix release?
>>>> There are some critical bugs in 0.15, T725 for example.
>>
>> Yes, and some others.
>>
>>>> Think we should port fixes back to 0.15 and then release it as 0.15.1
>>
>> +1
>>
>>
>>> +1 to another release soon. Is there anything in the devel branch
>>> that's not ready to go out?
>>
>> Yes, the current state of my decorator changes breaks code in Sage. I
>> wouldn't know of anything else, so maybe it's enough to back those changes
>> out from a branch and otherwise keep the state that we have now.
>
> ... especially given that the list of fixes that are scheduled for the next
> release is not exactly short, and some fixes spread over more than one
> commit, so there'd be a lot to merge over.
>
> http://trac.cython.org/cython_trac/query?status=assigned&status=closed&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&milestone=0.15.1&col=owner
>
> A problem with the current master branch is that we already dropped support
> for Py2.3 in it...
>
> I see two ways to get a release out: create a branch from the current master
> and remove from it what we don't consider stable (or 'right' for that
> release), or merge the most important and easily mergeable changes over to
> the current release branch for 0.15.1 and leave the rest to a
> not-so-far-in-the future 0.16.
>
> Personally, I vote for the latter, because I think we should rather try to
> get 0.16 out soon and not put too much work into 0.15.1. There were enough
> changes in master (and potentially some more in the open pull requests) to
> merit a 0.16. And I certainly wouldn't mind keeping the list of changes in a
> main release a little shorter.
>


+1 for second option, What about 2.3 support in 0.15.1?


-- 
vitja.

From stefan_ml at behnel.de  Sun Sep 11 16:24:55 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 11 Sep 2011 16:24:55 +0200
Subject: [Cython] Bugfix release
In-Reply-To: <CAKGHGPQ9C7q0p9qQ1XGxwKannUQzGw4ND_Msfka00uvT62n+Zg@mail.gmail.com>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>	<4E6C9C9E.3000707@behnel.de>
	<4E6CB2BF.5000806@behnel.de>
	<CAKGHGPQ9C7q0p9qQ1XGxwKannUQzGw4ND_Msfka00uvT62n+Zg@mail.gmail.com>
Message-ID: <4E6CC4B7.8000307@behnel.de>

Vitja Makarov, 11.09.2011 16:13:
> 2011/9/11 Stefan Behnel:
>> A problem with the current master branch is that we already dropped support
>> for Py2.3 in it...
>>
>> I see two ways to get a release out: create a branch from the current master
>> and remove from it what we don't consider stable (or 'right' for that
>> release), or merge the most important and easily mergeable changes over to
>> the current release branch for 0.15.1 and leave the rest to a
>> not-so-far-in-the future 0.16.
>>
>> Personally, I vote for the latter, because I think we should rather try to
>> get 0.16 out soon and not put too much work into 0.15.1. There were enough
>> changes in master (and potentially some more in the open pull requests) to
>> merit a 0.16. And I certainly wouldn't mind keeping the list of changes in a
>> main release a little shorter.
>
> +1 for second option, What about 2.3 support in 0.15.1?

None of the fixes that I selected for 0.15.1 should break 2.3 support 
(famous last words...).

Stefan

From markflorisson88 at gmail.com  Sun Sep 11 16:35:44 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Sun, 11 Sep 2011 14:35:44 +0000
Subject: [Cython] Bugfix release
In-Reply-To: <4E6C9C9E.3000707@behnel.de>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>
	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
	<4E6C9C9E.3000707@behnel.de>
Message-ID: <CANg26EXn44QBP7HqApbDs2gAAz3D-vOED0ek06XX42OoeH6knw@mail.gmail.com>

On 11 September 2011 11:33, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Robert Bradshaw, 11.09.2011 07:54:
>>
>> On Sat, Sep 10, 2011 at 10:32 PM, Vitja Makarov wrote:
>>>
>>> Are we going to make a bugfix release?
>>>
>>> There are some critical bugs in 0.15, T725 for example.
>
> Yes, and some others.
>
>
>>> Think we should port fixes back to 0.15 and then release it as 0.15.1
>
> +1
>
>
>> +1 to another release soon. Is there anything in the devel branch
>> that's not ready to go out?
>
> Yes, the current state of my decorator changes breaks code in Sage. I
> wouldn't know of anything else, so maybe it's enough to back those changes
> out from a branch and otherwise keep the state that we have now.
>

Wouldn't it be easier if everyone went through the pull-request
process (which means you test stuff in your own branch first) for
anything but trivial fixes? Then we only ever get "stable-ish"
features in, and the pull requests will also be documented. Then I
might even know what kind of decorator changes we're talking about,
without having to dig through the commits.

>> (I was also thinking of doing a release as
>> soon as fused functions and memory views got in.)
>
> That would be 0.16.
>
> Stefan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

From stefan_ml at behnel.de  Sun Sep 11 16:53:28 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 11 Sep 2011 16:53:28 +0200
Subject: [Cython] Bugfix release
In-Reply-To: <CANg26EXn44QBP7HqApbDs2gAAz3D-vOED0ek06XX42OoeH6knw@mail.gmail.com>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>	<4E6C9C9E.3000707@behnel.de>
	<CANg26EXn44QBP7HqApbDs2gAAz3D-vOED0ek06XX42OoeH6knw@mail.gmail.com>
Message-ID: <4E6CCB68.3060805@behnel.de>

mark florisson, 11.09.2011 16:35:
> On 11 September 2011 11:33, Stefan Behnel wrote:
>> Robert Bradshaw, 11.09.2011 07:54:
>>> +1 to another release soon. Is there anything in the devel branch
>>> that's not ready to go out?
>>
>> Yes, the current state of my decorator changes breaks code in Sage. I
>> wouldn't know of anything else, so maybe it's enough to back those changes
>> out from a branch and otherwise keep the state that we have now.
>
> [...]Then I
> might even know what kind of decorator changes we're talking about,
> without having to dig through the commits.

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

Stefan

From stefan_ml at behnel.de  Sun Sep 11 16:58:24 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 11 Sep 2011 16:58:24 +0200
Subject: [Cython] development work-flow  (was: Bugfix release)
In-Reply-To: <CANg26EXn44QBP7HqApbDs2gAAz3D-vOED0ek06XX42OoeH6knw@mail.gmail.com>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>	<4E6C9C9E.3000707@behnel.de>
	<CANg26EXn44QBP7HqApbDs2gAAz3D-vOED0ek06XX42OoeH6knw@mail.gmail.com>
Message-ID: <4E6CCC90.9030001@behnel.de>

mark florisson, 11.09.2011 16:35:
> Wouldn't it be easier if everyone went through the pull-request
> process (which means you test stuff in your own branch first) for
> anything but trivial fixes? Then we only ever get "stable-ish"
> features in, and the pull requests will also be documented.

I agree. I think everyone should have a personal branch, a personal (and 
equal) set of Jenkins test jobs for his branch, and then either go through 
a pull request or merge changes directly into the master branch if they are 
safe.

I usually work on the master branch directly, but it's certainly true that 
some changes eventually turn out to be too large for a direct commit 
(series) on the master branch. That's easier to handle with personal branches.

Stefan

From vitja.makarov at gmail.com  Mon Sep 12 09:23:22 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Mon, 12 Sep 2011 11:23:22 +0400
Subject: [Cython] Bugfix release
In-Reply-To: <4E6CBF1F.9020307@behnel.de>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>
	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
	<4E6C9C9E.3000707@behnel.de> <4E6CB2BF.5000806@behnel.de>
	<4E6CBF1F.9020307@behnel.de>
Message-ID: <CAKGHGPQdkDAfaC5CriM8FaOp-V68rZy+JNhRE8oPvafyp+KWcw@mail.gmail.com>

2011/9/11 Stefan Behnel <stefan_ml at behnel.de>:
> Stefan Behnel, 11.09.2011 15:08:
>>
>> I see two ways to get a release out: create a branch from the current
>> master and remove from it what we don't consider stable (or 'right' for
>> that release), or merge the most important and easily mergeable changes
>> over to the current release branch for 0.15.1 and leave the rest to a
>> not-so-far-in-the future 0.16.
>>
>> Personally, I vote for the latter, because I think we should rather try to
>> get 0.16 out soon and not put too much work into 0.15.1.
>
> I selected the list of changes that I considered safe and important, and
> transplanted them into the release branch.
>
> Please check if there is anything missing that's should go into a bug fix
> release.
>

Your list of commits seems ok to me.

-- 
vitja.

From dalcinl at gmail.com  Tue Sep 13 04:19:09 2011
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Mon, 12 Sep 2011 23:19:09 -0300
Subject: [Cython] Error when using Intel icl compiler on Windows
In-Reply-To: <CADiQ+QCp1FBWYVKibdwJX7CwDmtiwRq+wqYuQ9wCgwHU1ziw+w@mail.gmail.com>
References: <4E69C005.3040808@uci.edu>
	<CADiQ+QCp1FBWYVKibdwJX7CwDmtiwRq+wqYuQ9wCgwHU1ziw+w@mail.gmail.com>
Message-ID: <CAEcYPwBcJuPzhgKfnGUcGcaF+E8=Rj_7ffdtCBYb9Z31EvtR_g@mail.gmail.com>

On 9 September 2011 05:26, Robert Bradshaw <robertwb at math.washington.edu> wrote:
> Does it work with icc if you replace
>
> ?# ? define CYTHON_UNUSED __attribute__ ((__unused__))
>
> with
>
> ?# ? define CYTHON_UNUSED __attribute__ ((unused))
>
> ?
>
>
> On Fri, Sep 9, 2011 at 12:28 AM, Christoph Gohlke <cgohlke at uci.edu> wrote:
>> Hello,
>>
>> compiling Cython 0.15 generated C code on Windows using the Intel Compiler
>> 11.1 icl.exe results in an "expected a type specifier" error.
>>
>> For example:
>>
>> /* "numpy.pxd":190
>> ?* ? ? ? ? # experimental exception made for __getbuffer__ and
>> __releasebuffer__
>> ?* ? ? ? ? # -- the details of this may change.
>> ?* ? ? ? ? def __getbuffer__(ndarray self, Py_buffer* info, int flags):
>> ? ? ? ? # <<<<<<<<<<<<<<
>> ?* ? ? ? ? ? ? # This implementation of getbuffer is geared towards Cython
>> ?* ? ? ? ? ? ? # requirements, and does not yet fullfill the PEP.
>> ?*/
>>
>> static CYTHON_UNUSED int __pyx_pf_5numpy_7ndarray___getbuffer__(PyObject
>> *__pyx_v_self, Py_buffer *__pyx_v_info, int __pyx_v_flags); /*proto*/
>> ? ? ? ^
>> Error: expected a type specifier.
>>
>> The problem is the definition of CYTHON_UNUSED.
>>
>> Please consider the attached patch. It works for me but maybe the problem is
>> icl version specific, not Windows specific.
>>

Robert, could you apply this patch?

-- 
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 robertwb at math.washington.edu  Tue Sep 13 05:49:31 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Mon, 12 Sep 2011 20:49:31 -0700
Subject: [Cython] Bugfix release
In-Reply-To: <CAKGHGPQdkDAfaC5CriM8FaOp-V68rZy+JNhRE8oPvafyp+KWcw@mail.gmail.com>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>
	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
	<4E6C9C9E.3000707@behnel.de> <4E6CB2BF.5000806@behnel.de>
	<4E6CBF1F.9020307@behnel.de>
	<CAKGHGPQdkDAfaC5CriM8FaOp-V68rZy+JNhRE8oPvafyp+KWcw@mail.gmail.com>
Message-ID: <CADiQ+QBqjkN_GwRGHUuULad-9UWePfAoAwQ1sn5g9B53i-KNcQ@mail.gmail.com>

On Mon, Sep 12, 2011 at 12:23 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> 2011/9/11 Stefan Behnel <stefan_ml at behnel.de>:
>> Stefan Behnel, 11.09.2011 15:08:
>>>
>>> I see two ways to get a release out: create a branch from the current
>>> master and remove from it what we don't consider stable (or 'right' for
>>> that release), or merge the most important and easily mergeable changes
>>> over to the current release branch for 0.15.1 and leave the rest to a
>>> not-so-far-in-the future 0.16.
>>>
>>> Personally, I vote for the latter, because I think we should rather try to
>>> get 0.16 out soon and not put too much work into 0.15.1.
>>
>> I selected the list of changes that I considered safe and important, and
>> transplanted them into the release branch.
>>
>> Please check if there is anything missing that's should go into a bug fix
>> release.
>>
>
> Your list of commits seems ok to me.

Yes, this looks like a safe set of worthwhile fixes to roll into a
bugfix release. Might be worth rolling in the couple of doc changes as
well:

git log 0.15..HEAD docs/

https://github.com/cython/cython/commit/8028bf20de85136e5334196ecd1057e63c81ebd3
https://github.com/cython/cython/commit/699bc1ec74f238cd3ea5b515d4e7c759a944814d
https://github.com/cython/cython/commit/37486422dd5fffae1e3ea72c58bfac4bba56144d
https://github.com/cython/cython/commit/c90378882e401a9c4e1b26cc2292138c5c728b3d

- Robert

From robertwb at math.washington.edu  Tue Sep 13 06:01:26 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Mon, 12 Sep 2011 21:01:26 -0700
Subject: [Cython] development work-flow (was: Bugfix release)
In-Reply-To: <4E6CCC90.9030001@behnel.de>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>
	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
	<4E6C9C9E.3000707@behnel.de>
	<CANg26EXn44QBP7HqApbDs2gAAz3D-vOED0ek06XX42OoeH6knw@mail.gmail.com>
	<4E6CCC90.9030001@behnel.de>
Message-ID: <CADiQ+QCk9VyZMF6mmMiOChECN5v1C0iNcngkNOCeg+cm-uv0gQ@mail.gmail.com>

On Sun, Sep 11, 2011 at 7:58 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> mark florisson, 11.09.2011 16:35:
>>
>> Wouldn't it be easier if everyone went through the pull-request
>> process (which means you test stuff in your own branch first) for
>> anything but trivial fixes? Then we only ever get "stable-ish"
>> features in, and the pull requests will also be documented.
>
> I agree. I think everyone should have a personal branch, a personal (and
> equal) set of Jenkins test jobs for his branch, and then either go through a
> pull request or merge changes directly into the master branch if they are
> safe.
>
> I usually work on the master branch directly, but it's certainly true that
> some changes eventually turn out to be too large for a direct commit
> (series) on the master branch. That's easier to handle with personal
> branches.

I'd be happy working with this model too. Github makes it much easier
than our original setup.

- Robert

From robertwb at math.washington.edu  Tue Sep 13 06:09:10 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Mon, 12 Sep 2011 21:09:10 -0700
Subject: [Cython] Error when using Intel icl compiler on Windows
In-Reply-To: <CAEcYPwBcJuPzhgKfnGUcGcaF+E8=Rj_7ffdtCBYb9Z31EvtR_g@mail.gmail.com>
References: <4E69C005.3040808@uci.edu>
	<CADiQ+QCp1FBWYVKibdwJX7CwDmtiwRq+wqYuQ9wCgwHU1ziw+w@mail.gmail.com>
	<CAEcYPwBcJuPzhgKfnGUcGcaF+E8=Rj_7ffdtCBYb9Z31EvtR_g@mail.gmail.com>
Message-ID: <CADiQ+QC4RoGX74P_7d=QshFsxXAxF_qxRnynYsqchGe9uZ2+hw@mail.gmail.com>

On Mon, Sep 12, 2011 at 7:19 PM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
> On 9 September 2011 05:26, Robert Bradshaw <robertwb at math.washington.edu> wrote:
>> Does it work with icc if you replace
>>
>> ?# ? define CYTHON_UNUSED __attribute__ ((__unused__))
>>
>> with
>>
>> ?# ? define CYTHON_UNUSED __attribute__ ((unused))
>>
>> ?
>>
>>
>> On Fri, Sep 9, 2011 at 12:28 AM, Christoph Gohlke <cgohlke at uci.edu> wrote:
>>> Hello,
>>>
>>> compiling Cython 0.15 generated C code on Windows using the Intel Compiler
>>> 11.1 icl.exe results in an "expected a type specifier" error.
>>>
>>> For example:
>>>
>>> /* "numpy.pxd":190
>>> ?* ? ? ? ? # experimental exception made for __getbuffer__ and
>>> __releasebuffer__
>>> ?* ? ? ? ? # -- the details of this may change.
>>> ?* ? ? ? ? def __getbuffer__(ndarray self, Py_buffer* info, int flags):
>>> ? ? ? ? # <<<<<<<<<<<<<<
>>> ?* ? ? ? ? ? ? # This implementation of getbuffer is geared towards Cython
>>> ?* ? ? ? ? ? ? # requirements, and does not yet fullfill the PEP.
>>> ?*/
>>>
>>> static CYTHON_UNUSED int __pyx_pf_5numpy_7ndarray___getbuffer__(PyObject
>>> *__pyx_v_self, Py_buffer *__pyx_v_info, int __pyx_v_flags); /*proto*/
>>> ? ? ? ^
>>> Error: expected a type specifier.
>>>
>>> The problem is the definition of CYTHON_UNUSED.
>>>
>>> Please consider the attached patch. It works for me but maybe the problem is
>>> icl version specific, not Windows specific.
>>>
>
> Robert, could you apply this patch?

Done. I'm still wondering if it's broken for __INTEL_COMPILER
non-windows, but don't have any way to test it out.

- Robert

From vitja.makarov at gmail.com  Tue Sep 13 06:31:59 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Tue, 13 Sep 2011 08:31:59 +0400
Subject: [Cython] Error when using Intel icl compiler on Windows
In-Reply-To: <CADiQ+QC4RoGX74P_7d=QshFsxXAxF_qxRnynYsqchGe9uZ2+hw@mail.gmail.com>
References: <4E69C005.3040808@uci.edu>
	<CADiQ+QCp1FBWYVKibdwJX7CwDmtiwRq+wqYuQ9wCgwHU1ziw+w@mail.gmail.com>
	<CAEcYPwBcJuPzhgKfnGUcGcaF+E8=Rj_7ffdtCBYb9Z31EvtR_g@mail.gmail.com>
	<CADiQ+QC4RoGX74P_7d=QshFsxXAxF_qxRnynYsqchGe9uZ2+hw@mail.gmail.com>
Message-ID: <CAKGHGPS87gEHuNa8FWf4rAfMKJCo7t7A2e12q-vvdqP+Cgu0gw@mail.gmail.com>

2011/9/13 Robert Bradshaw <robertwb at math.washington.edu>:
> On Mon, Sep 12, 2011 at 7:19 PM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>> On 9 September 2011 05:26, Robert Bradshaw <robertwb at math.washington.edu> wrote:
>>> Does it work with icc if you replace
>>>
>>> ?# ? define CYTHON_UNUSED __attribute__ ((__unused__))
>>>
>>> with
>>>
>>> ?# ? define CYTHON_UNUSED __attribute__ ((unused))
>>>
>>> ?
>>>
>>>
>>> On Fri, Sep 9, 2011 at 12:28 AM, Christoph Gohlke <cgohlke at uci.edu> wrote:
>>>> Hello,
>>>>
>>>> compiling Cython 0.15 generated C code on Windows using the Intel Compiler
>>>> 11.1 icl.exe results in an "expected a type specifier" error.
>>>>
>>>> For example:
>>>>
>>>> /* "numpy.pxd":190
>>>> ?* ? ? ? ? # experimental exception made for __getbuffer__ and
>>>> __releasebuffer__
>>>> ?* ? ? ? ? # -- the details of this may change.
>>>> ?* ? ? ? ? def __getbuffer__(ndarray self, Py_buffer* info, int flags):
>>>> ? ? ? ? # <<<<<<<<<<<<<<
>>>> ?* ? ? ? ? ? ? # This implementation of getbuffer is geared towards Cython
>>>> ?* ? ? ? ? ? ? # requirements, and does not yet fullfill the PEP.
>>>> ?*/
>>>>
>>>> static CYTHON_UNUSED int __pyx_pf_5numpy_7ndarray___getbuffer__(PyObject
>>>> *__pyx_v_self, Py_buffer *__pyx_v_info, int __pyx_v_flags); /*proto*/
>>>> ? ? ? ^
>>>> Error: expected a type specifier.
>>>>
>>>> The problem is the definition of CYTHON_UNUSED.
>>>>
>>>> Please consider the attached patch. It works for me but maybe the problem is
>>>> icl version specific, not Windows specific.
>>>>
>>
>> Robert, could you apply this patch?
>
> Done. I'm still wondering if it's broken for __INTEL_COMPILER
> non-windows, but don't have any way to test it out.
>

Maybe  __attibute__((unused)) is gcc compat option and is disabled on
windows systems by default.



-- 
vitja.

From vitja.makarov at gmail.com  Tue Sep 13 06:33:22 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Tue, 13 Sep 2011 08:33:22 +0400
Subject: [Cython] development work-flow (was: Bugfix release)
In-Reply-To: <CADiQ+QCk9VyZMF6mmMiOChECN5v1C0iNcngkNOCeg+cm-uv0gQ@mail.gmail.com>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>
	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
	<4E6C9C9E.3000707@behnel.de>
	<CANg26EXn44QBP7HqApbDs2gAAz3D-vOED0ek06XX42OoeH6knw@mail.gmail.com>
	<4E6CCC90.9030001@behnel.de>
	<CADiQ+QCk9VyZMF6mmMiOChECN5v1C0iNcngkNOCeg+cm-uv0gQ@mail.gmail.com>
Message-ID: <CAKGHGPSH0=-Uy=OYLTjXBq5ZsPps-p5gYuQihCVo0BL1V=-asg@mail.gmail.com>

2011/9/13 Robert Bradshaw <robertwb at math.washington.edu>:
> On Sun, Sep 11, 2011 at 7:58 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
>> mark florisson, 11.09.2011 16:35:
>>>
>>> Wouldn't it be easier if everyone went through the pull-request
>>> process (which means you test stuff in your own branch first) for
>>> anything but trivial fixes? Then we only ever get "stable-ish"
>>> features in, and the pull requests will also be documented.
>>
>> I agree. I think everyone should have a personal branch, a personal (and
>> equal) set of Jenkins test jobs for his branch, and then either go through a
>> pull request or merge changes directly into the master branch if they are
>> safe.
>>
>> I usually work on the master branch directly, but it's certainly true that
>> some changes eventually turn out to be too large for a direct commit
>> (series) on the master branch. That's easier to handle with personal
>> branches.
>
> I'd be happy working with this model too. Github makes it much easier
> than our original setup.
>

+1

-- 
vitja.

From cournape at gmail.com  Tue Sep 13 13:18:07 2011
From: cournape at gmail.com (David Cournapeau)
Date: Tue, 13 Sep 2011 07:18:07 -0400
Subject: [Cython] Error when using Intel icl compiler on Windows
In-Reply-To: <CAKGHGPS87gEHuNa8FWf4rAfMKJCo7t7A2e12q-vvdqP+Cgu0gw@mail.gmail.com>
References: <4E69C005.3040808@uci.edu>
	<CADiQ+QCp1FBWYVKibdwJX7CwDmtiwRq+wqYuQ9wCgwHU1ziw+w@mail.gmail.com>
	<CAEcYPwBcJuPzhgKfnGUcGcaF+E8=Rj_7ffdtCBYb9Z31EvtR_g@mail.gmail.com>
	<CADiQ+QC4RoGX74P_7d=QshFsxXAxF_qxRnynYsqchGe9uZ2+hw@mail.gmail.com>
	<CAKGHGPS87gEHuNa8FWf4rAfMKJCo7t7A2e12q-vvdqP+Cgu0gw@mail.gmail.com>
Message-ID: <CAGY4rcVZhtAvDpebL7aqT+CkPDQE7OK0+HbV+dPeeW+26Tn7fA@mail.gmail.com>

On Tue, Sep 13, 2011 at 12:31 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> 2011/9/13 Robert Bradshaw <robertwb at math.washington.edu>:
>> On Mon, Sep 12, 2011 at 7:19 PM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>>> On 9 September 2011 05:26, Robert Bradshaw <robertwb at math.washington.edu> wrote:
>>>> Does it work with icc if you replace
>>>>
>>>> ?# ? define CYTHON_UNUSED __attribute__ ((__unused__))
>>>>
>>>> with
>>>>
>>>> ?# ? define CYTHON_UNUSED __attribute__ ((unused))
>>>>
>>>> ?
>>>>
>>>>
>>>> On Fri, Sep 9, 2011 at 12:28 AM, Christoph Gohlke <cgohlke at uci.edu> wrote:
>>>>> Hello,
>>>>>
>>>>> compiling Cython 0.15 generated C code on Windows using the Intel Compiler
>>>>> 11.1 icl.exe results in an "expected a type specifier" error.
>>>>>
>>>>> For example:
>>>>>
>>>>> /* "numpy.pxd":190
>>>>> ?* ? ? ? ? # experimental exception made for __getbuffer__ and
>>>>> __releasebuffer__
>>>>> ?* ? ? ? ? # -- the details of this may change.
>>>>> ?* ? ? ? ? def __getbuffer__(ndarray self, Py_buffer* info, int flags):
>>>>> ? ? ? ? # <<<<<<<<<<<<<<
>>>>> ?* ? ? ? ? ? ? # This implementation of getbuffer is geared towards Cython
>>>>> ?* ? ? ? ? ? ? # requirements, and does not yet fullfill the PEP.
>>>>> ?*/
>>>>>
>>>>> static CYTHON_UNUSED int __pyx_pf_5numpy_7ndarray___getbuffer__(PyObject
>>>>> *__pyx_v_self, Py_buffer *__pyx_v_info, int __pyx_v_flags); /*proto*/
>>>>> ? ? ? ^
>>>>> Error: expected a type specifier.
>>>>>
>>>>> The problem is the definition of CYTHON_UNUSED.
>>>>>
>>>>> Please consider the attached patch. It works for me but maybe the problem is
>>>>> icl version specific, not Windows specific.
>>>>>
>>>
>>> Robert, could you apply this patch?
>>
>> Done. I'm still wondering if it's broken for __INTEL_COMPILER
>> non-windows, but don't have any way to test it out.
>>
>
> Maybe ?__attibute__((unused)) is gcc compat option and is disabled on
> windows systems by default.

I am actually not aware of any option to enable it on windows (a quick
check on most recent icl doc did not mention __attribute__ anywhere in
windows sections).

cheers,

David

From dalcinl at gmail.com  Tue Sep 13 18:01:00 2011
From: dalcinl at gmail.com (Lisandro Dalcin)
Date: Tue, 13 Sep 2011 13:01:00 -0300
Subject: [Cython] Error when using Intel icl compiler on Windows
In-Reply-To: <CADiQ+QC4RoGX74P_7d=QshFsxXAxF_qxRnynYsqchGe9uZ2+hw@mail.gmail.com>
References: <4E69C005.3040808@uci.edu>
	<CADiQ+QCp1FBWYVKibdwJX7CwDmtiwRq+wqYuQ9wCgwHU1ziw+w@mail.gmail.com>
	<CAEcYPwBcJuPzhgKfnGUcGcaF+E8=Rj_7ffdtCBYb9Z31EvtR_g@mail.gmail.com>
	<CADiQ+QC4RoGX74P_7d=QshFsxXAxF_qxRnynYsqchGe9uZ2+hw@mail.gmail.com>
Message-ID: <CAEcYPwCF4LU=CweAGHsD_KTUbizfS9qQeEc38VuKhDBFznC1GQ@mail.gmail.com>

On 13 September 2011 01:09, Robert Bradshaw
<robertwb at math.washington.edu> wrote:
> On Mon, Sep 12, 2011 at 7:19 PM, Lisandro Dalcin <dalcinl at gmail.com> wrote:
>> On 9 September 2011 05:26, Robert Bradshaw <robertwb at math.washington.edu> wrote:
>>> Does it work with icc if you replace
>>>
>>> ?# ? define CYTHON_UNUSED __attribute__ ((__unused__))
>>>
>>> with
>>>
>>> ?# ? define CYTHON_UNUSED __attribute__ ((unused))
>>>
>>> ?
>>>
>>>
>>> On Fri, Sep 9, 2011 at 12:28 AM, Christoph Gohlke <cgohlke at uci.edu> wrote:
>>>> Hello,
>>>>
>>>> compiling Cython 0.15 generated C code on Windows using the Intel Compiler
>>>> 11.1 icl.exe results in an "expected a type specifier" error.
>>>>
>>>> For example:
>>>>
>>>> /* "numpy.pxd":190
>>>> ?* ? ? ? ? # experimental exception made for __getbuffer__ and
>>>> __releasebuffer__
>>>> ?* ? ? ? ? # -- the details of this may change.
>>>> ?* ? ? ? ? def __getbuffer__(ndarray self, Py_buffer* info, int flags):
>>>> ? ? ? ? # <<<<<<<<<<<<<<
>>>> ?* ? ? ? ? ? ? # This implementation of getbuffer is geared towards Cython
>>>> ?* ? ? ? ? ? ? # requirements, and does not yet fullfill the PEP.
>>>> ?*/
>>>>
>>>> static CYTHON_UNUSED int __pyx_pf_5numpy_7ndarray___getbuffer__(PyObject
>>>> *__pyx_v_self, Py_buffer *__pyx_v_info, int __pyx_v_flags); /*proto*/
>>>> ? ? ? ^
>>>> Error: expected a type specifier.
>>>>
>>>> The problem is the definition of CYTHON_UNUSED.
>>>>
>>>> Please consider the attached patch. It works for me but maybe the problem is
>>>> icl version specific, not Windows specific.
>>>>
>>
>> Robert, could you apply this patch?
>
> Done. I'm still wondering if it's broken for __INTEL_COMPILER
> non-windows, but don't have any way to test it out.
>

In my Linux box, it seens to works just fine.

However, now I think that the correct guard should be:

# elif (defined(__ICC) || (defined(__INTEL_COMPILER)) && !defined(_MSC_VER)

Anyway, the __ICC definition is obsolete.





-- 
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 hagen at zhuliguan.net  Tue Sep 13 20:22:26 2011
From: hagen at zhuliguan.net (=?UTF-8?B?SGFnZW4gRsO8cnN0ZW5hdQ==?=)
Date: Tue, 13 Sep 2011 14:22:26 -0400
Subject: [Cython] Bug in inplace operators?
Message-ID: <j4o70t$bvm$1@dough.gmane.org>

Hi,

I'm new to Cython, so I don't know if this is a bug, a known limitation, 
or a misunderstanding on my part, but the following simple example 
produces C code that fails to compile:

-----------------------------------------------------------
import numpy
cimport numpy

def f(numpy.ndarray[numpy.int32_t, ndim=1] a not None, i):
     cdef numpy.ndarray[numpy.int32_t, ndim=1] b

     b = numpy.ones(10, dtype=numpy.int32)
     b[0] *= a[i]


a = numpy.array([1, 2, 3], dtype=numpy.int32)
f(a, 1)
-----------------------------------------------------------

Running this on Cython 0.15 and Python 3.2.2 with

$ python -c 'import pyximport; pyximport.install(); import x'

I get a compiler error, the essential part of which seems to be

/export/home/hagenf/.pyxbld/temp.linux-x86_64-3.2/pyrex/x.c:1105: error: 
invalid operands to binary * (have ?__pyx_t_5numpy_int32_t? and ?struct 
PyObject *?)

The problem is in the line "b[0] *= a[i]". Replacing this with "b[0] = 
b[0] * a[i]" solves it. As does typing i as an int (which of course is a 
good idea anyway).

Cheers,
Hagen


From robertwb at math.washington.edu  Tue Sep 13 20:35:44 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Tue, 13 Sep 2011 11:35:44 -0700
Subject: [Cython] Bug in inplace operators?
In-Reply-To: <j4o70t$bvm$1@dough.gmane.org>
References: <j4o70t$bvm$1@dough.gmane.org>
Message-ID: <CADiQ+QBo5p46BJmHA8tHM938gkOxZz4k3EcLumdwaeGfY4Mj7g@mail.gmail.com>

Looks like a bug to me, thanks. http://trac.cython.org/cython_trac/ticket/732

On Tue, Sep 13, 2011 at 11:22 AM, Hagen F?rstenau <hagen at zhuliguan.net> wrote:
> Hi,
>
> I'm new to Cython, so I don't know if this is a bug, a known limitation, or
> a misunderstanding on my part, but the following simple example produces C
> code that fails to compile:
>
> -----------------------------------------------------------
> import numpy
> cimport numpy
>
> def f(numpy.ndarray[numpy.int32_t, ndim=1] a not None, i):
> ? ?cdef numpy.ndarray[numpy.int32_t, ndim=1] b
>
> ? ?b = numpy.ones(10, dtype=numpy.int32)
> ? ?b[0] *= a[i]
>
>
> a = numpy.array([1, 2, 3], dtype=numpy.int32)
> f(a, 1)
> -----------------------------------------------------------
>
> Running this on Cython 0.15 and Python 3.2.2 with
>
> $ python -c 'import pyximport; pyximport.install(); import x'
>
> I get a compiler error, the essential part of which seems to be
>
> /export/home/hagenf/.pyxbld/temp.linux-x86_64-3.2/pyrex/x.c:1105: error:
> invalid operands to binary * (have ?__pyx_t_5numpy_int32_t? and ?struct
> PyObject *?)
>
> The problem is in the line "b[0] *= a[i]". Replacing this with "b[0] = b[0]
> * a[i]" solves it. As does typing i as an int (which of course is a good
> idea anyway).
>
> Cheers,
> Hagen
>
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

From vitja.makarov at gmail.com  Tue Sep 13 22:17:07 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Wed, 14 Sep 2011 00:17:07 +0400
Subject: [Cython] jenkins pyregr job problems
Message-ID: <CAKGHGPSUr9n9wd6jXAZXVow+CSZfd3_BA_3iRmtsCH4E0YNa7g@mail.gmail.com>

It seems that something have changed after recent jenkins job
refactoring. Starting from build cython-vitek-tests-pyregr-py27-c #365
I got error about creating hard links in build logs:

[workspace] $ /bin/sh -xe /levi/scratch/hudson/tmp/hudson4308307797887194909.sh
+ /levi/scratch/robertwb/hudson/hudson/Scripts/get_latest_cython.sh
cython-vitek-build-py27
ln: creating hard link `./Cython-bdist-latest.tar.gz': File exists
ln: creating hard link `./Cython-sdist-latest.tar.gz': File exists
ln: creating hard link `./Cython-tests-latest.tar.gz': File exists

In regular cython tests I've rm -rf * so they run as expected.
But in pyregr jobs I don't so tests are run against old version of cython.

I think it's better to remove old files before creating hard link.

-- 
vitja.

From stefan_ml at behnel.de  Wed Sep 14 05:43:46 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 14 Sep 2011 05:43:46 +0200
Subject: [Cython] jenkins pyregr job problems
In-Reply-To: <CAKGHGPSUr9n9wd6jXAZXVow+CSZfd3_BA_3iRmtsCH4E0YNa7g@mail.gmail.com>
References: <CAKGHGPSUr9n9wd6jXAZXVow+CSZfd3_BA_3iRmtsCH4E0YNa7g@mail.gmail.com>
Message-ID: <4E7022F2.4000708@behnel.de>

Vitja Makarov, 13.09.2011 22:17:
> It seems that something have changed after recent jenkins job
> refactoring. Starting from build cython-vitek-tests-pyregr-py27-c #365
> I got error about creating hard links in build logs:
>
> [workspace] $ /bin/sh -xe /levi/scratch/hudson/tmp/hudson4308307797887194909.sh
> + /levi/scratch/robertwb/hudson/hudson/Scripts/get_latest_cython.sh
> cython-vitek-build-py27
> ln: creating hard link `./Cython-bdist-latest.tar.gz': File exists
> ln: creating hard link `./Cython-sdist-latest.tar.gz': File exists
> ln: creating hard link `./Cython-tests-latest.tar.gz': File exists

Fixed now. Thanks.


> In regular cython tests I've rm -rf * so they run as expected.
> But in pyregr jobs I don't so tests are run against old version of cython.

Note that you can modify your build jobs at any time. I would even 
encourage you to switch to the new setup for your own build jobs.

Stefan

From stefan_ml at behnel.de  Wed Sep 14 07:01:46 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 14 Sep 2011 07:01:46 +0200
Subject: [Cython] Bugfix release
In-Reply-To: <CADiQ+QBqjkN_GwRGHUuULad-9UWePfAoAwQ1sn5g9B53i-KNcQ@mail.gmail.com>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>	<4E6C9C9E.3000707@behnel.de>
	<4E6CB2BF.5000806@behnel.de>	<4E6CBF1F.9020307@behnel.de>	<CAKGHGPQdkDAfaC5CriM8FaOp-V68rZy+JNhRE8oPvafyp+KWcw@mail.gmail.com>
	<CADiQ+QBqjkN_GwRGHUuULad-9UWePfAoAwQ1sn5g9B53i-KNcQ@mail.gmail.com>
Message-ID: <4E70353A.9050402@behnel.de>

Robert Bradshaw, 13.09.2011 05:49:
> On Mon, Sep 12, 2011 at 12:23 AM, Vitja Makarov wrote:
>> 2011/9/11 Stefan Behnel:
>>> Stefan Behnel, 11.09.2011 15:08:
>>>>
>>>> I see two ways to get a release out: create a branch from the current
>>>> master and remove from it what we don't consider stable (or 'right' for
>>>> that release), or merge the most important and easily mergeable changes
>>>> over to the current release branch for 0.15.1 and leave the rest to a
>>>> not-so-far-in-the future 0.16.
>>>>
>>>> Personally, I vote for the latter, because I think we should rather try to
>>>> get 0.16 out soon and not put too much work into 0.15.1.
>>>
>>> I selected the list of changes that I considered safe and important, and
>>> transplanted them into the release branch.
>>>
>>> Please check if there is anything missing that's should go into a bug fix
>>> release.
>>>
>>
>> Your list of commits seems ok to me.
>
> Yes, this looks like a safe set of worthwhile fixes to roll into a
> bugfix release. Might be worth rolling in the couple of doc changes as
> well:
>
> git log 0.15..HEAD docs/
>
> https://github.com/cython/cython/commit/8028bf20de85136e5334196ecd1057e63c81ebd3
> https://github.com/cython/cython/commit/699bc1ec74f238cd3ea5b515d4e7c759a944814d
> https://github.com/cython/cython/commit/37486422dd5fffae1e3ea72c58bfac4bba56144d
> https://github.com/cython/cython/commit/c90378882e401a9c4e1b26cc2292138c5c728b3d

Those were all in already. ;)

I guess we're set for a release then, right?

Stefan

From robertwb at math.washington.edu  Wed Sep 14 07:37:30 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Tue, 13 Sep 2011 22:37:30 -0700
Subject: [Cython] Bugfix release
In-Reply-To: <4E70353A.9050402@behnel.de>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>
	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
	<4E6C9C9E.3000707@behnel.de> <4E6CB2BF.5000806@behnel.de>
	<4E6CBF1F.9020307@behnel.de>
	<CAKGHGPQdkDAfaC5CriM8FaOp-V68rZy+JNhRE8oPvafyp+KWcw@mail.gmail.com>
	<CADiQ+QBqjkN_GwRGHUuULad-9UWePfAoAwQ1sn5g9B53i-KNcQ@mail.gmail.com>
	<4E70353A.9050402@behnel.de>
Message-ID: <CADiQ+QA+jox9D4xevFk030e1J=hwwqgSYZkLL6avU9cxi-EWFw@mail.gmail.com>

On Tue, Sep 13, 2011 at 10:01 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Robert Bradshaw, 13.09.2011 05:49:
>>
>> On Mon, Sep 12, 2011 at 12:23 AM, Vitja Makarov wrote:
>>>
>>> 2011/9/11 Stefan Behnel:
>>>>
>>>> Stefan Behnel, 11.09.2011 15:08:
>>>>>
>>>>> I see two ways to get a release out: create a branch from the current
>>>>> master and remove from it what we don't consider stable (or 'right' for
>>>>> that release), or merge the most important and easily mergeable changes
>>>>> over to the current release branch for 0.15.1 and leave the rest to a
>>>>> not-so-far-in-the future 0.16.
>>>>>
>>>>> Personally, I vote for the latter, because I think we should rather try
>>>>> to
>>>>> get 0.16 out soon and not put too much work into 0.15.1.
>>>>
>>>> I selected the list of changes that I considered safe and important, and
>>>> transplanted them into the release branch.
>>>>
>>>> Please check if there is anything missing that's should go into a bug
>>>> fix
>>>> release.
>>>>
>>>
>>> Your list of commits seems ok to me.
>>
>> Yes, this looks like a safe set of worthwhile fixes to roll into a
>> bugfix release. Might be worth rolling in the couple of doc changes as
>> well:
>>
>> git log 0.15..HEAD docs/
>>
>>
>> https://github.com/cython/cython/commit/8028bf20de85136e5334196ecd1057e63c81ebd3
>>
>> https://github.com/cython/cython/commit/699bc1ec74f238cd3ea5b515d4e7c759a944814d
>>
>> https://github.com/cython/cython/commit/37486422dd5fffae1e3ea72c58bfac4bba56144d
>>
>> https://github.com/cython/cython/commit/c90378882e401a9c4e1b26cc2292138c5c728b3d
>
> Those were all in already. ;)

> I guess we're set for a release then, right?

+1. Should we send a release candidate around, or just cut it (as it
is bugfix-only and hasn't been too long since the last one)?

Also, is there a parameterized jenkins target for the release branch
yet (I'm not seeing it)?

- Robert

From stefan_ml at behnel.de  Wed Sep 14 20:45:31 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Wed, 14 Sep 2011 20:45:31 +0200
Subject: [Cython] speed.python.org is up
Message-ID: <4E70F64B.4040808@behnel.de>

Hi,

http://speed.python.org is online. It doesn't have any performance numbers 
yet, and work is still being done to set up the benchmark runner, but 
eventually, I would like to see Cython run on it as well.

There's a mailing list for those who want to participate in the setup:

http://mail.python.org/mailman/listinfo/speed

Stefan

From lists at onerussian.com  Thu Sep 15 17:08:07 2011
From: lists at onerussian.com (Yaroslav Halchenko)
Date: Thu, 15 Sep 2011 11:08:07 -0400
Subject: [Cython] Bugfix release
In-Reply-To: <CADiQ+QA+jox9D4xevFk030e1J=hwwqgSYZkLL6avU9cxi-EWFw@mail.gmail.com>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>
	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
	<4E6C9C9E.3000707@behnel.de> <4E6CB2BF.5000806@behnel.de>
	<4E6CBF1F.9020307@behnel.de>
	<CAKGHGPQdkDAfaC5CriM8FaOp-V68rZy+JNhRE8oPvafyp+KWcw@mail.gmail.com>
	<CADiQ+QBqjkN_GwRGHUuULad-9UWePfAoAwQ1sn5g9B53i-KNcQ@mail.gmail.com>
	<4E70353A.9050402@behnel.de>
	<CADiQ+QA+jox9D4xevFk030e1J=hwwqgSYZkLL6avU9cxi-EWFw@mail.gmail.com>
Message-ID: <20110915150807.GK5866@onerussian.com>

just to make sure -- 0.15.1 would come out from 'release' branch, right?
(there is motion to get fresh cython into debian and I am arguing that
it would be better to take post 0.15 snapshot)

On Tue, 13 Sep 2011, Robert Bradshaw wrote:
> > I guess we're set for a release then, right?

> +1. Should we send a release candidate around, or just cut it (as it
> is bugfix-only and hasn't been too long since the last one)?

> Also, is there a parameterized jenkins target for the release branch
> yet (I'm not seeing it)?

-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic

From stefan_ml at behnel.de  Thu Sep 15 17:28:33 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 15 Sep 2011 17:28:33 +0200
Subject: [Cython] Bugfix release
In-Reply-To: <20110915150807.GK5866@onerussian.com>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>	<4E6C9C9E.3000707@behnel.de>
	<4E6CB2BF.5000806@behnel.de>	<4E6CBF1F.9020307@behnel.de>	<CAKGHGPQdkDAfaC5CriM8FaOp-V68rZy+JNhRE8oPvafyp+KWcw@mail.gmail.com>	<CADiQ+QBqjkN_GwRGHUuULad-9UWePfAoAwQ1sn5g9B53i-KNcQ@mail.gmail.com>	<4E70353A.9050402@behnel.de>	<CADiQ+QA+jox9D4xevFk030e1J=hwwqgSYZkLL6avU9cxi-EWFw@mail.gmail.com>
	<20110915150807.GK5866@onerussian.com>
Message-ID: <4E7219A1.9050606@behnel.de>

Yaroslav Halchenko, 15.09.2011 17:08:
> On Tue, 13 Sep 2011, Robert Bradshaw wrote:
>>> I guess we're set for a release then, right?
>
>> +1. Should we send a release candidate around, or just cut it (as it
>> is bugfix-only and hasn't been too long since the last one)?
>
>> Also, is there a parameterized jenkins target for the release branch
>> yet (I'm not seeing it)?
>
> just to make sure -- 0.15.1 would come out from 'release' branch,
> right?

Yes.


> (there is motion to get fresh cython into debian and I am arguing
> that it would be better to take post 0.15 snapshot)

I would hope that we get the release out rather soon, so there's no need to 
use a snapshot.

Stefan

From robertwb at math.washington.edu  Thu Sep 15 22:31:45 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Thu, 15 Sep 2011 13:31:45 -0700
Subject: [Cython] Bugfix release
In-Reply-To: <4E7219A1.9050606@behnel.de>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>
	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
	<4E6C9C9E.3000707@behnel.de> <4E6CB2BF.5000806@behnel.de>
	<4E6CBF1F.9020307@behnel.de>
	<CAKGHGPQdkDAfaC5CriM8FaOp-V68rZy+JNhRE8oPvafyp+KWcw@mail.gmail.com>
	<CADiQ+QBqjkN_GwRGHUuULad-9UWePfAoAwQ1sn5g9B53i-KNcQ@mail.gmail.com>
	<4E70353A.9050402@behnel.de>
	<CADiQ+QA+jox9D4xevFk030e1J=hwwqgSYZkLL6avU9cxi-EWFw@mail.gmail.com>
	<20110915150807.GK5866@onerussian.com> <4E7219A1.9050606@behnel.de>
Message-ID: <CADiQ+QA7JBmtZgmW0Ec7i-SK=Q1Y7WnZuERBNepsTG9WEZs6jQ@mail.gmail.com>

On Thu, Sep 15, 2011 at 8:28 AM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Yaroslav Halchenko, 15.09.2011 17:08:
>>
>> On Tue, 13 Sep 2011, Robert Bradshaw wrote:
>>>>
>>>> I guess we're set for a release then, right?
>>
>>> +1. Should we send a release candidate around, or just cut it (as it
>>> is bugfix-only and hasn't been too long since the last one)?
>>
>>> Also, is there a parameterized jenkins target for the release branch
>>> yet (I'm not seeing it)?
>>
>> just to make sure -- 0.15.1 would come out from 'release' branch,
>> right?
>
> Yes.
>
>
>> (there is motion to get fresh cython into debian and I am arguing
>> that it would be better to take post 0.15 snapshot)
>
> I would hope that we get the release out rather soon, so there's no need to
> use a snapshot.

Anything in particular we're waiting on? I put up
http://wiki.cython.org/ReleaseNotes-0.15.1

- Robert

From robertwb at math.washington.edu  Thu Sep 15 22:33:53 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Thu, 15 Sep 2011 13:33:53 -0700
Subject: [Cython] Cython 0.15.1 release candidate
Message-ID: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>

See http://wiki.cython.org/ReleaseNotes-0.15.1 This is a bugfix only
release, we hope to get it out shortly.

- Robert

From stefan_ml at behnel.de  Thu Sep 15 22:38:22 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Thu, 15 Sep 2011 22:38:22 +0200
Subject: [Cython] Bugfix release
In-Reply-To: <CADiQ+QA7JBmtZgmW0Ec7i-SK=Q1Y7WnZuERBNepsTG9WEZs6jQ@mail.gmail.com>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>	<4E6C9C9E.3000707@behnel.de>
	<4E6CB2BF.5000806@behnel.de>	<4E6CBF1F.9020307@behnel.de>	<CAKGHGPQdkDAfaC5CriM8FaOp-V68rZy+JNhRE8oPvafyp+KWcw@mail.gmail.com>	<CADiQ+QBqjkN_GwRGHUuULad-9UWePfAoAwQ1sn5g9B53i-KNcQ@mail.gmail.com>	<4E70353A.9050402@behnel.de>	<CADiQ+QA+jox9D4xevFk030e1J=hwwqgSYZkLL6avU9cxi-EWFw@mail.gmail.com>	<20110915150807.GK5866@onerussian.com>
	<4E7219A1.9050606@behnel.de>
	<CADiQ+QA7JBmtZgmW0Ec7i-SK=Q1Y7WnZuERBNepsTG9WEZs6jQ@mail.gmail.com>
Message-ID: <4E72623E.1050701@behnel.de>

Robert Bradshaw, 15.09.2011 22:31:
> On Thu, Sep 15, 2011 at 8:28 AM, Stefan Behnel wrote:
>> Yaroslav Halchenko, 15.09.2011 17:08:
>>>
>>> On Tue, 13 Sep 2011, Robert Bradshaw wrote:
>>>>>
>>>>> I guess we're set for a release then, right?
>>>
>>>> +1. Should we send a release candidate around, or just cut it (as it
>>>> is bugfix-only and hasn't been too long since the last one)?
>>>
>>>> Also, is there a parameterized jenkins target for the release branch
>>>> yet (I'm not seeing it)?
>>>
>>> just to make sure -- 0.15.1 would come out from 'release' branch,
>>> right?
>>
>> Yes.
>>
>>
>>> (there is motion to get fresh cython into debian and I am arguing
>>> that it would be better to take post 0.15 snapshot)
>>
>> I would hope that we get the release out rather soon, so there's no need to
>> use a snapshot.
>
> Anything in particular we're waiting on?

For you to do it. ;)


> I put up http://wiki.cython.org/ReleaseNotes-0.15.1

Yes, that's about it.

Stefan

From robertwb at math.washington.edu  Thu Sep 15 22:59:16 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Thu, 15 Sep 2011 13:59:16 -0700
Subject: [Cython] Bugfix release
In-Reply-To: <4E72623E.1050701@behnel.de>
References: <CAKGHGPQaqV8qsXky4t4AzzCW_8V2zQi-3GYoYB0JOcSH08wQxw@mail.gmail.com>
	<CADiQ+QCuQL4qx0fEqTnoyjgmOyjRLxqvMF+4T0m9WJ5Qn-0vMg@mail.gmail.com>
	<4E6C9C9E.3000707@behnel.de> <4E6CB2BF.5000806@behnel.de>
	<4E6CBF1F.9020307@behnel.de>
	<CAKGHGPQdkDAfaC5CriM8FaOp-V68rZy+JNhRE8oPvafyp+KWcw@mail.gmail.com>
	<CADiQ+QBqjkN_GwRGHUuULad-9UWePfAoAwQ1sn5g9B53i-KNcQ@mail.gmail.com>
	<4E70353A.9050402@behnel.de>
	<CADiQ+QA+jox9D4xevFk030e1J=hwwqgSYZkLL6avU9cxi-EWFw@mail.gmail.com>
	<20110915150807.GK5866@onerussian.com> <4E7219A1.9050606@behnel.de>
	<CADiQ+QA7JBmtZgmW0Ec7i-SK=Q1Y7WnZuERBNepsTG9WEZs6jQ@mail.gmail.com>
	<4E72623E.1050701@behnel.de>
Message-ID: <CADiQ+QB=5hUSCsHTLV1tS_wWZLbvcHhTiRD3qseVvCFn_=Kx7A@mail.gmail.com>

On Thu, Sep 15, 2011 at 1:38 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Robert Bradshaw, 15.09.2011 22:31:
>>
>> On Thu, Sep 15, 2011 at 8:28 AM, Stefan Behnel wrote:
>>>
>>> Yaroslav Halchenko, 15.09.2011 17:08:
>>>>
>>>> On Tue, 13 Sep 2011, Robert Bradshaw wrote:
>>>>>>
>>>>>> I guess we're set for a release then, right?
>>>>
>>>>> +1. Should we send a release candidate around, or just cut it (as it
>>>>> is bugfix-only and hasn't been too long since the last one)?
>>>>
>>>>> Also, is there a parameterized jenkins target for the release branch
>>>>> yet (I'm not seeing it)?
>>>>
>>>> just to make sure -- 0.15.1 would come out from 'release' branch,
>>>> right?
>>>
>>> Yes.
>>>
>>>
>>>> (there is motion to get fresh cython into debian and I am arguing
>>>> that it would be better to take post 0.15 snapshot)
>>>
>>> I would hope that we get the release out rather soon, so there's no need
>>> to
>>> use a snapshot.
>>
>> Anything in particular we're waiting on?
>
> For you to do it. ;)

:) I sent an RC out, so we'll see if we get any feedback, but I don't
see any reason to have a long wait before pushing this out.

- Robert

From arfrever.fta at gmail.com  Fri Sep 16 03:52:41 2011
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 16 Sep 2011 03:52:41 +0200
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
Message-ID: <201109160352.42849.Arfrever.FTA@gmail.com>

1 test failure with Python 2.6:

compiling (c) and running tupleunpack_T712 ... Doctest: tupleunpack_T712.__test__.single_from_set (line 12) ... ok
Doctest: tupleunpack_T712.__test__.single_from_string (line 4) ... ok
compiling (cpp) and running tupleunpack_T712 ... cc1plus: warning: command line option "-Wpointer-sign" is valid for C/ObjC but not for C++
tupleunpack_T712.cpp: In function ?PyObject* __pyx_pf_16tupleunpack_T712_1single_from_set(PyObject*, PyObject*)?:
tupleunpack_T712.cpp:681:3: error: jump to label ?__pyx_L1_error?
tupleunpack_T712.cpp:642:151: error:   from here
tupleunpack_T712.cpp:644:14: error:   crosses initialization of ?Py_ssize_t index?
tupleunpack_T712.cpp:681:3: error: jump to label ?__pyx_L1_error?
tupleunpack_T712.cpp:640:135: error:   from here
tupleunpack_T712.cpp:644:14: error:   crosses initialization of ?Py_ssize_t index?
ERROR

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20110916/7c20e4d0/attachment-0001.pgp>

From arfrever.fta at gmail.com  Fri Sep 16 05:24:22 2011
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Fri, 16 Sep 2011 05:24:22 +0200
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
Message-ID: <201109160524.22966.Arfrever.FTA@gmail.com>

1 error ("compiling (cpp) and running tupleunpack_T712") and 0 failures with Python 3.1.
1 error ("compiling (cpp) and running tupleunpack_T712") and 4 failures with Python 3.2.

The end of output of tests with Python 3.2:

======================================================================
ERROR: runTest (__main__.CythonRunTestCase)
compiling (cpp) and running tupleunpack_T712
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.2/distutils/unixccompiler.py", line 181, in _compile
    extra_postargs)
  File "/usr/lib64/python3.2/distutils/ccompiler.py", line 909, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/usr/lib64/python3.2/distutils/spawn.py", line 32, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/usr/lib64/python3.2/distutils/spawn.py", line 163, in _spawn_posix
    % (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command 'x86_64-pc-linux-gnu-g++' failed with exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "runtests.py", line 678, in run
    self.runCompileTest()
  File "runtests.py", line 490, in runCompileTest
    self.test_directory, self.expect_errors, self.annotate)
  File "runtests.py", line 665, in compile
    self.run_distutils(test_directory, module, workdir, incdir)
  File "runtests.py", line 625, in run_distutils
    build_extension.run()
  File "/usr/lib64/python3.2/distutils/command/build_ext.py", line 345, in run
    self.build_extensions()
  File "/usr/lib64/python3.2/distutils/command/build_ext.py", line 454, in build_extensions
    self.build_extension(ext)
  File "runtests.py", line 257, in build_extension
    _build_ext.build_extension(self, ext)
  File "/usr/lib64/python3.2/distutils/command/build_ext.py", line 509, in build_extension
    depends=ext.depends)
  File "/usr/lib64/python3.2/distutils/ccompiler.py", line 574, in compile
    self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)
  File "/usr/lib64/python3.2/distutils/unixccompiler.py", line 186, in _compile
    raise CompileError(msg)
distutils.errors.CompileError: command 'x86_64-pc-linux-gnu-g++' failed with exit status 1

======================================================================
FAIL: NestedWith (withstat)
Doctest: withstat.NestedWith
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.2/doctest.py", line 2118, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for withstat.NestedWith
  File "/var/tmp/portage/dev-python/cython-0.15.1_rc0/work/Cython-0.15.1/tests-3.2/run/c/withstat.cpython-32.so", line unknown line number, in NestedWith

----------------------------------------------------------------------
File "/var/tmp/portage/dev-python/cython-0.15.1_rc0/work/Cython-0.15.1/tests-3.2/run/c/withstat.cpython-32.so", line ?, in withstat.NestedWith
Failed example:
    NestedWith().runTest()
Exception raised:
    Traceback (most recent call last):
      File "/usr/lib64/python3.2/doctest.py", line 1253, in __run
        compileflags, 1), test.globs)
      File "<doctest withstat.NestedWith[0]>", line 1, in <module>
        NestedWith().runTest()
      File "withstat.pyx", line 183, in withstat.NestedWith.runTest (withstat.c:5076)
      File "withstat.pyx", line 222, in withstat.NestedWith.testEnterReturnsTuple (withstat.c:7533)
      File "withstat.pyx", line 223, in withstat.NestedWith.testEnterReturnsTuple (withstat.c:7421)
      File "withstat.pyx", line 224, in withstat.NestedWith.testEnterReturnsTuple (withstat.c:7270)
      File "/usr/lib64/python3.2/unittest/case.py", line 1169, in deprecated_func
        DeprecationWarning, 2)
      File "/usr/lib64/python3.2/warnings.py", line 18, in showwarning
        file.write(formatwarning(message, category, filename, lineno, line))
      File "/usr/lib64/python3.2/warnings.py", line 25, in formatwarning
        line = linecache.getline(filename, lineno) if line is None else line
      File "/usr/lib64/python3.2/linecache.py", line 15, in getline
        lines = getlines(filename, module_globals)
      File "/usr/lib64/python3.2/doctest.py", line 1337, in __patched_linecache_getlines
        return self.save_linecache_getlines(filename, module_globals)
      File "/usr/lib64/python3.2/linecache.py", line 41, in getlines
        return updatecache(filename, module_globals)
      File "/usr/lib64/python3.2/linecache.py", line 127, in updatecache
        lines = fp.readlines()
      File "/usr/lib64/python3.2/codecs.py", line 300, in decode
        (result, consumed) = self._buffer_decode(data, self.errors, final)
    UnicodeDecodeError: 'utf8' codec can't decode byte 0xd0 in position 24: invalid continuation byte


======================================================================
FAIL: NestedWith (withstat)
Doctest: withstat.NestedWith
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.2/doctest.py", line 2118, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for withstat.NestedWith
  File "/var/tmp/portage/dev-python/cython-0.15.1_rc0/work/Cython-0.15.1/tests-3.2/run/cpp/withstat.cpython-32.so", line unknown line number, in NestedWith

----------------------------------------------------------------------
File "/var/tmp/portage/dev-python/cython-0.15.1_rc0/work/Cython-0.15.1/tests-3.2/run/cpp/withstat.cpython-32.so", line ?, in withstat.NestedWith
Failed example:
    NestedWith().runTest()
Exception raised:
    Traceback (most recent call last):
      File "/usr/lib64/python3.2/doctest.py", line 1253, in __run
        compileflags, 1), test.globs)
      File "<doctest withstat.NestedWith[0]>", line 1, in <module>
        NestedWith().runTest()
      File "withstat.pyx", line 183, in withstat.NestedWith.runTest (withstat.cpp:5076)
      File "withstat.pyx", line 222, in withstat.NestedWith.testEnterReturnsTuple (withstat.cpp:7533)
      File "withstat.pyx", line 223, in withstat.NestedWith.testEnterReturnsTuple (withstat.cpp:7421)
      File "withstat.pyx", line 224, in withstat.NestedWith.testEnterReturnsTuple (withstat.cpp:7270)
      File "/usr/lib64/python3.2/unittest/case.py", line 1169, in deprecated_func
        DeprecationWarning, 2)
      File "/usr/lib64/python3.2/warnings.py", line 18, in showwarning
        file.write(formatwarning(message, category, filename, lineno, line))
      File "/usr/lib64/python3.2/warnings.py", line 25, in formatwarning
        line = linecache.getline(filename, lineno) if line is None else line
      File "/usr/lib64/python3.2/linecache.py", line 15, in getline
        lines = getlines(filename, module_globals)
      File "/usr/lib64/python3.2/doctest.py", line 1337, in __patched_linecache_getlines
        return self.save_linecache_getlines(filename, module_globals)
      File "/usr/lib64/python3.2/linecache.py", line 41, in getlines
        return updatecache(filename, module_globals)
      File "/usr/lib64/python3.2/linecache.py", line 127, in updatecache
        lines = fp.readlines()
      File "/usr/lib64/python3.2/codecs.py", line 300, in decode
        (result, consumed) = self._buffer_decode(data, self.errors, final)
    UnicodeDecodeError: 'utf8' codec can't decode byte 0xc0 in position 24: invalid start byte


======================================================================
FAIL: NestedWith (withstat_py)
Doctest: withstat_py.NestedWith
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.2/doctest.py", line 2118, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for withstat_py.NestedWith
  File "/var/tmp/portage/dev-python/cython-0.15.1_rc0/work/Cython-0.15.1/tests-3.2/run/c/withstat_py.cpython-32.so", line unknown line number, in NestedWith

----------------------------------------------------------------------
File "/var/tmp/portage/dev-python/cython-0.15.1_rc0/work/Cython-0.15.1/tests-3.2/run/c/withstat_py.cpython-32.so", line ?, in withstat_py.NestedWith
Failed example:
    NestedWith().runTest()
Exception raised:
    Traceback (most recent call last):
      File "/usr/lib64/python3.2/doctest.py", line 1253, in __run
        compileflags, 1), test.globs)
      File "<doctest withstat_py.NestedWith[0]>", line 1, in <module>
        NestedWith().runTest()
      File "withstat_py.py", line 228, in withstat_py.NestedWith.runTest (withstat_py.c:6128)
      File "withstat_py.py", line 267, in withstat_py.NestedWith.testEnterReturnsTuple (withstat_py.c:8585)
      File "withstat_py.py", line 268, in withstat_py.NestedWith.testEnterReturnsTuple (withstat_py.c:8473)
      File "withstat_py.py", line 269, in withstat_py.NestedWith.testEnterReturnsTuple (withstat_py.c:8322)
      File "/usr/lib64/python3.2/unittest/case.py", line 1169, in deprecated_func
        DeprecationWarning, 2)
      File "/usr/lib64/python3.2/warnings.py", line 18, in showwarning
        file.write(formatwarning(message, category, filename, lineno, line))
      File "/usr/lib64/python3.2/warnings.py", line 25, in formatwarning
        line = linecache.getline(filename, lineno) if line is None else line
      File "/usr/lib64/python3.2/linecache.py", line 15, in getline
        lines = getlines(filename, module_globals)
      File "/usr/lib64/python3.2/doctest.py", line 1337, in __patched_linecache_getlines
        return self.save_linecache_getlines(filename, module_globals)
      File "/usr/lib64/python3.2/linecache.py", line 41, in getlines
        return updatecache(filename, module_globals)
      File "/usr/lib64/python3.2/linecache.py", line 127, in updatecache
        lines = fp.readlines()
      File "/usr/lib64/python3.2/codecs.py", line 300, in decode
        (result, consumed) = self._buffer_decode(data, self.errors, final)
    UnicodeDecodeError: 'utf8' codec can't decode byte 0x90 in position 40: invalid start byte


======================================================================
FAIL: NestedWith (withstat_py)
Doctest: withstat_py.NestedWith
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python3.2/doctest.py", line 2118, in runTest
    raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for withstat_py.NestedWith
  File "/var/tmp/portage/dev-python/cython-0.15.1_rc0/work/Cython-0.15.1/tests-3.2/run/cpp/withstat_py.cpython-32.so", line unknown line number, in NestedWith

----------------------------------------------------------------------
File "/var/tmp/portage/dev-python/cython-0.15.1_rc0/work/Cython-0.15.1/tests-3.2/run/cpp/withstat_py.cpython-32.so", line ?, in withstat_py.NestedWith
Failed example:
    NestedWith().runTest()
Exception raised:
    Traceback (most recent call last):
      File "/usr/lib64/python3.2/doctest.py", line 1253, in __run
        compileflags, 1), test.globs)
      File "<doctest withstat_py.NestedWith[0]>", line 1, in <module>
        NestedWith().runTest()
      File "withstat_py.py", line 228, in withstat_py.NestedWith.runTest (withstat_py.cpp:6128)
      File "withstat_py.py", line 267, in withstat_py.NestedWith.testEnterReturnsTuple (withstat_py.cpp:8585)
      File "withstat_py.py", line 268, in withstat_py.NestedWith.testEnterReturnsTuple (withstat_py.cpp:8473)
      File "withstat_py.py", line 269, in withstat_py.NestedWith.testEnterReturnsTuple (withstat_py.cpp:8322)
      File "/usr/lib64/python3.2/unittest/case.py", line 1169, in deprecated_func
        DeprecationWarning, 2)
      File "/usr/lib64/python3.2/warnings.py", line 18, in showwarning
        file.write(formatwarning(message, category, filename, lineno, line))
      File "/usr/lib64/python3.2/warnings.py", line 25, in formatwarning
        line = linecache.getline(filename, lineno) if line is None else line
      File "/usr/lib64/python3.2/linecache.py", line 15, in getline
        lines = getlines(filename, module_globals)
      File "/usr/lib64/python3.2/doctest.py", line 1337, in __patched_linecache_getlines
        return self.save_linecache_getlines(filename, module_globals)
      File "/usr/lib64/python3.2/linecache.py", line 41, in getlines
        return updatecache(filename, module_globals)
      File "/usr/lib64/python3.2/linecache.py", line 127, in updatecache
        lines = fp.readlines()
      File "/usr/lib64/python3.2/codecs.py", line 300, in decode
        (result, consumed) = self._buffer_decode(data, self.errors, final)
    UnicodeDecodeError: 'utf8' codec can't decode byte 0x90 in position 40: invalid start byte


----------------------------------------------------------------------
Ran 5577 tests in 1422.824s

FAILED (failures=4, errors=1)
ALL DONE

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20110916/9468fce3/attachment.pgp>

From vitja.makarov at gmail.com  Fri Sep 16 06:10:28 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Fri, 16 Sep 2011 08:10:28 +0400
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <201109160352.42849.Arfrever.FTA@gmail.com>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
	<201109160352.42849.Arfrever.FTA@gmail.com>
Message-ID: <CAKGHGPRdXR6s_x=dR2kKxr4YFxWShBUe3-gHP7cyko=OP9+hgQ@mail.gmail.com>

2011/9/16 Arfrever Frehtes Taifersar Arahesis <arfrever.fta at gmail.com>:
> 1 test failure with Python 2.6:
>
> compiling (c) and running tupleunpack_T712 ... Doctest: tupleunpack_T712.__test__.single_from_set (line 12) ... ok
> Doctest: tupleunpack_T712.__test__.single_from_string (line 4) ... ok
> compiling (cpp) and running tupleunpack_T712 ... cc1plus: warning: command line option "-Wpointer-sign" is valid for C/ObjC but not for C++
> tupleunpack_T712.cpp: In function ?PyObject* __pyx_pf_16tupleunpack_T712_1single_from_set(PyObject*, PyObject*)?:
> tupleunpack_T712.cpp:681:3: error: jump to label ?__pyx_L1_error?
> tupleunpack_T712.cpp:642:151: error: ? from here
> tupleunpack_T712.cpp:644:14: error: ? crosses initialization of ?Py_ssize_t index?
> tupleunpack_T712.cpp:681:3: error: jump to label ?__pyx_L1_error?
> tupleunpack_T712.cpp:640:135: error: ? from here
> tupleunpack_T712.cpp:644:14: error: ? crosses initialization of ?Py_ssize_t index?
> ERROR
>

Robert, It seems that you created tarball from old revision.

-- 
vitja.

From robertwb at math.washington.edu  Fri Sep 16 07:02:10 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Thu, 15 Sep 2011 22:02:10 -0700
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <CAKGHGPRdXR6s_x=dR2kKxr4YFxWShBUe3-gHP7cyko=OP9+hgQ@mail.gmail.com>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
	<201109160352.42849.Arfrever.FTA@gmail.com>
	<CAKGHGPRdXR6s_x=dR2kKxr4YFxWShBUe3-gHP7cyko=OP9+hgQ@mail.gmail.com>
Message-ID: <CADiQ+QDCyAv-6WP2oXKKciOhNrfWDaWeOB_t1AMJer=Z3k8rMg@mail.gmail.com>

On Thu, Sep 15, 2011 at 9:10 PM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> 2011/9/16 Arfrever Frehtes Taifersar Arahesis <arfrever.fta at gmail.com>:
>> 1 test failure with Python 2.6:
>>
>> compiling (c) and running tupleunpack_T712 ... Doctest: tupleunpack_T712.__test__.single_from_set (line 12) ... ok
>> Doctest: tupleunpack_T712.__test__.single_from_string (line 4) ... ok
>> compiling (cpp) and running tupleunpack_T712 ... cc1plus: warning: command line option "-Wpointer-sign" is valid for C/ObjC but not for C++
>> tupleunpack_T712.cpp: In function ?PyObject* __pyx_pf_16tupleunpack_T712_1single_from_set(PyObject*, PyObject*)?:
>> tupleunpack_T712.cpp:681:3: error: jump to label ?__pyx_L1_error?
>> tupleunpack_T712.cpp:642:151: error: ? from here
>> tupleunpack_T712.cpp:644:14: error: ? crosses initialization of ?Py_ssize_t index?
>> tupleunpack_T712.cpp:681:3: error: jump to label ?__pyx_L1_error?
>> tupleunpack_T712.cpp:640:135: error: ? from here
>> tupleunpack_T712.cpp:644:14: error: ? crosses initialization of ?Py_ssize_t index?
>> ERROR
>>
>
> Robert, It seems that you created tarball from old revision.

I just downloaded http://cython.org/release/Cython-0.15.1rc0.tar.gz
and unpacked it, the latest commit is

commit 34f6211d53485df1ba25cfeb9c414045b095f57d
Author: Stefan Behnel <scoder at users.berlios.de>
Date:   Wed Sep 14 21:37:09 2011 +0200

which seems right.

- Robert

From vitja.makarov at gmail.com  Fri Sep 16 07:14:31 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Fri, 16 Sep 2011 09:14:31 +0400
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <CADiQ+QDCyAv-6WP2oXKKciOhNrfWDaWeOB_t1AMJer=Z3k8rMg@mail.gmail.com>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
	<201109160352.42849.Arfrever.FTA@gmail.com>
	<CAKGHGPRdXR6s_x=dR2kKxr4YFxWShBUe3-gHP7cyko=OP9+hgQ@mail.gmail.com>
	<CADiQ+QDCyAv-6WP2oXKKciOhNrfWDaWeOB_t1AMJer=Z3k8rMg@mail.gmail.com>
Message-ID: <CAKGHGPQMDhjQMjK8Oqi+vuxizO-NsT6HsbCRgqAWZRXCLMXb=w@mail.gmail.com>

2011/9/16 Robert Bradshaw <robertwb at math.washington.edu>:
> On Thu, Sep 15, 2011 at 9:10 PM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>> 2011/9/16 Arfrever Frehtes Taifersar Arahesis <arfrever.fta at gmail.com>:
>>> 1 test failure with Python 2.6:
>>>
>>> compiling (c) and running tupleunpack_T712 ... Doctest: tupleunpack_T712.__test__.single_from_set (line 12) ... ok
>>> Doctest: tupleunpack_T712.__test__.single_from_string (line 4) ... ok
>>> compiling (cpp) and running tupleunpack_T712 ... cc1plus: warning: command line option "-Wpointer-sign" is valid for C/ObjC but not for C++
>>> tupleunpack_T712.cpp: In function ?PyObject* __pyx_pf_16tupleunpack_T712_1single_from_set(PyObject*, PyObject*)?:
>>> tupleunpack_T712.cpp:681:3: error: jump to label ?__pyx_L1_error?
>>> tupleunpack_T712.cpp:642:151: error: ? from here
>>> tupleunpack_T712.cpp:644:14: error: ? crosses initialization of ?Py_ssize_t index?
>>> tupleunpack_T712.cpp:681:3: error: jump to label ?__pyx_L1_error?
>>> tupleunpack_T712.cpp:640:135: error: ? from here
>>> tupleunpack_T712.cpp:644:14: error: ? crosses initialization of ?Py_ssize_t index?
>>> ERROR
>>>
>>
>> Robert, It seems that you created tarball from old revision.
>
> I just downloaded http://cython.org/release/Cython-0.15.1rc0.tar.gz
> and unpacked it, the latest commit is
>
> commit 34f6211d53485df1ba25cfeb9c414045b095f57d
> Author: Stefan Behnel <scoder at users.berlios.de>
> Date: ? Wed Sep 14 21:37:09 2011 +0200
>
> which seems right.
>

Right. Sorry, I did compare it to wrong branch.

Btw I'm sure that we have seen this error before:

compiling (c) and running tupleunpack_T712 ... Doctest:
tupleunpack_T712.__test__.single_from_set (line 12) ... ok
Doctest: tupleunpack_T712.__test__.single_from_string (line 4) ... ok
compiling (cpp) and running tupleunpack_T712 ... cc1plus: warning:
command line option "-Wpointer-sign" is valid for C/ObjC but not for
C++
tupleunpack_T712.cpp: In function ?PyObject*
__pyx_pf_16tupleunpack_T712_1single_from_set(PyObject*, PyObject*)?:
tupleunpack_T712.cpp:681:3: error: jump to label ?__pyx_L1_error?
tupleunpack_T712.cpp:642:151: error:   from here
tupleunpack_T712.cpp:644:14: error:   crosses initialization of
?Py_ssize_t index?
tupleunpack_T712.cpp:681:3: error: jump to label ?__pyx_L1_error?
tupleunpack_T712.cpp:640:135: error:   from here
tupleunpack_T712.cpp:644:14: error:   crosses initialization of
?Py_ssize_t index?
ERROR


-- 
vitja.

From stefan_ml at behnel.de  Fri Sep 16 07:47:17 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 16 Sep 2011 07:47:17 +0200
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <201109160524.22966.Arfrever.FTA@gmail.com>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
	<201109160524.22966.Arfrever.FTA@gmail.com>
Message-ID: <4E72E2E5.5030303@behnel.de>

Arfrever Frehtes Taifersar Arahesis, 16.09.2011 05:24:
> 1 error ("compiling (cpp) and running tupleunpack_T712") and 0 failures with Python 3.1.
> 1 error ("compiling (cpp) and running tupleunpack_T712") and 4 failures with Python 3.2.
> ======================================================================
> FAIL: NestedWith (withstat)
> Doctest: withstat.NestedWith
> ----------------------------------------------------------------------
>      UnicodeDecodeError: 'utf8' codec can't decode byte 0xc0 in position 24: invalid start byte
> ======================================================================
> FAIL: NestedWith (withstat_py)
> Doctest: withstat_py.NestedWith
> ----------------------------------------------------------------------
>      UnicodeDecodeError: 'utf8' codec can't decode byte 0x90 in position 40: invalid start byte

Nice - that means we are compliant with Python itself here! ;)

More seriously, it also means we must test the release branch under Python 
3 on Jenkins. That's much easier to do now, I can just copy the three 
build/test jobs, so that we get complete test coverage for it. Given how 
rare it usually is that we push to the release branch, That won't hurt, but 
it will give us much better safety for releases.

Stefan

From stefan_ml at behnel.de  Fri Sep 16 08:51:30 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 16 Sep 2011 08:51:30 +0200
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <CAKGHGPQMDhjQMjK8Oqi+vuxizO-NsT6HsbCRgqAWZRXCLMXb=w@mail.gmail.com>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>	<201109160352.42849.Arfrever.FTA@gmail.com>	<CAKGHGPRdXR6s_x=dR2kKxr4YFxWShBUe3-gHP7cyko=OP9+hgQ@mail.gmail.com>	<CADiQ+QDCyAv-6WP2oXKKciOhNrfWDaWeOB_t1AMJer=Z3k8rMg@mail.gmail.com>
	<CAKGHGPQMDhjQMjK8Oqi+vuxizO-NsT6HsbCRgqAWZRXCLMXb=w@mail.gmail.com>
Message-ID: <4E72F1F2.5070400@behnel.de>

Vitja Makarov, 16.09.2011 07:14:
> Btw I'm sure that we have seen this error before:
>
> compiling (c) and running tupleunpack_T712 ... Doctest:
> tupleunpack_T712.__test__.single_from_set (line 12) ... ok
> Doctest: tupleunpack_T712.__test__.single_from_string (line 4) ... ok
> compiling (cpp) and running tupleunpack_T712 ... cc1plus: warning:
> command line option "-Wpointer-sign" is valid for C/ObjC but not for
> C++
> tupleunpack_T712.cpp: In function ?PyObject*
> __pyx_pf_16tupleunpack_T712_1single_from_set(PyObject*, PyObject*)?:
> tupleunpack_T712.cpp:681:3: error: jump to label ?__pyx_L1_error?
> tupleunpack_T712.cpp:642:151: error:   from here
> tupleunpack_T712.cpp:644:14: error:   crosses initialization of
> ?Py_ssize_t index?
> tupleunpack_T712.cpp:681:3: error: jump to label ?__pyx_L1_error?
> tupleunpack_T712.cpp:640:135: error:   from here
> tupleunpack_T712.cpp:644:14: error:   crosses initialization of
> ?Py_ssize_t index?
> ERROR

Yes, I had fixed it before - I had missed it when looking through the 
fixes, because I considered it part of the unpacking code optimisation that 
I did around that change.

I pushed the fix to the release branch.

Thanks for finding it, Arfrever (is that the first name?).

Stefan

From stefan_ml at behnel.de  Fri Sep 16 23:03:27 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 16 Sep 2011 23:03:27 +0200
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
Message-ID: <4E73B99F.5080005@behnel.de>

Robert Bradshaw, 15.09.2011 22:33:
> See http://wiki.cython.org/ReleaseNotes-0.15.1 This is a bugfix only
> release, we hope to get it out shortly.

I've added ticket 736 as a blocker, at least until I know what it takes to 
fix it (looking into it right now).

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

Stefan

From markflorisson88 at gmail.com  Fri Sep 16 23:20:13 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Fri, 16 Sep 2011 22:20:13 +0100
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <4E73B99F.5080005@behnel.de>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
	<4E73B99F.5080005@behnel.de>
Message-ID: <CANg26EX503agY8MMa8sebWbrZe131-e-eX4VBrnM--vrqXeNkg@mail.gmail.com>

On 16 September 2011 22:03, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Robert Bradshaw, 15.09.2011 22:33:
>>
>> See http://wiki.cython.org/ReleaseNotes-0.15.1 This is a bugfix only
>> release, we hope to get it out shortly.
>
> I've added ticket 736 as a blocker, at least until I know what it takes to
> fix it (looking into it right now).
>
> http://trac.cython.org/cython_trac/ticket/736
>
> Stefan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

Looking at the generated code I see


__pyx_cur_scope->__pyx_v_a = __pyx_k_1;
__pyx_cur_scope->__pyx_v_b = __pyx_k_2;

happening at unpacking time without a corresponding INCREF. Surely the
scope object should only ever own references and never borrow them?
The arguments from the args tuple are increffed however, just not the
default values.

From markflorisson88 at gmail.com  Fri Sep 16 23:21:43 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Fri, 16 Sep 2011 22:21:43 +0100
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <CANg26EX503agY8MMa8sebWbrZe131-e-eX4VBrnM--vrqXeNkg@mail.gmail.com>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
	<4E73B99F.5080005@behnel.de>
	<CANg26EX503agY8MMa8sebWbrZe131-e-eX4VBrnM--vrqXeNkg@mail.gmail.com>
Message-ID: <CANg26EUvtga48PU1_HqyGmrw=-gOhmQ6sdLkyxEL8YUcmrNLyA@mail.gmail.com>

On 16 September 2011 22:20, mark florisson <markflorisson88 at gmail.com> wrote:
> On 16 September 2011 22:03, Stefan Behnel <stefan_ml at behnel.de> wrote:
>> Robert Bradshaw, 15.09.2011 22:33:
>>>
>>> See http://wiki.cython.org/ReleaseNotes-0.15.1 This is a bugfix only
>>> release, we hope to get it out shortly.
>>
>> I've added ticket 736 as a blocker, at least until I know what it takes to
>> fix it (looking into it right now).
>>
>> http://trac.cython.org/cython_trac/ticket/736
>>
>> Stefan
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel at python.org
>> http://mail.python.org/mailman/listinfo/cython-devel
>>
>
> Looking at the generated code I see
>
>
> __pyx_cur_scope->__pyx_v_a = __pyx_k_1;
> __pyx_cur_scope->__pyx_v_b = __pyx_k_2;
>
> happening at unpacking time without a corresponding INCREF. Surely the
> scope object should only ever own references and never borrow them?
> The arguments from the args tuple are increffed however, just not the
> default values.
>

BTW, the test would be better written with a class like

class UniqueObject(object):
    def __init__(self, value):
        self.value = value
    def __repr__(self):
        return repr(self.value)

That makes it easier to track down refcount errors than (small) integers.

From stefan_ml at behnel.de  Fri Sep 16 23:29:53 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 16 Sep 2011 23:29:53 +0200
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <CANg26EUvtga48PU1_HqyGmrw=-gOhmQ6sdLkyxEL8YUcmrNLyA@mail.gmail.com>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>	<4E73B99F.5080005@behnel.de>	<CANg26EX503agY8MMa8sebWbrZe131-e-eX4VBrnM--vrqXeNkg@mail.gmail.com>
	<CANg26EUvtga48PU1_HqyGmrw=-gOhmQ6sdLkyxEL8YUcmrNLyA@mail.gmail.com>
Message-ID: <4E73BFD1.40706@behnel.de>

mark florisson, 16.09.2011 23:21:
> On 16 September 2011 22:20, mark florisson wrote:
>> On 16 September 2011 22:03, Stefan Behnel wrote:
>>> Robert Bradshaw, 15.09.2011 22:33:
>>>>
>>>> See http://wiki.cython.org/ReleaseNotes-0.15.1 This is a bugfix only
>>>> release, we hope to get it out shortly.
>>>
>>> I've added ticket 736 as a blocker, at least until I know what it takes to
>>> fix it (looking into it right now).
>>>
>>> http://trac.cython.org/cython_trac/ticket/736
>>
>> Looking at the generated code I see
>>
>> __pyx_cur_scope->__pyx_v_a = __pyx_k_1;
>> __pyx_cur_scope->__pyx_v_b = __pyx_k_2;
>>
>> happening at unpacking time without a corresponding INCREF. Surely the
>> scope object should only ever own references and never borrow them?
>> The arguments from the args tuple are increffed however, just not the
>> default values.

Yes, I noticed that. See the updated bug description. I just wasn't sure 
what the best fix was when I wrote the above.

By now, I'm quite sure that it would be best to do the same as for the 
keyword arguments, i.e. store the borrowed values in a temporary array and 
copy them over when everything has worked out correctly.


> BTW, the test would be better written with a class like
>
> class UniqueObject(object):
>      def __init__(self, value):
>          self.value = value
>      def __repr__(self):
>          return repr(self.value)
>
> That makes it easier to track down refcount errors than (small) integers.

The refnanny handles that for us quite nicely.

Stefan

From markflorisson88 at gmail.com  Fri Sep 16 23:33:59 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Fri, 16 Sep 2011 22:33:59 +0100
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <4E73BFD1.40706@behnel.de>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
	<4E73B99F.5080005@behnel.de>
	<CANg26EX503agY8MMa8sebWbrZe131-e-eX4VBrnM--vrqXeNkg@mail.gmail.com>
	<CANg26EUvtga48PU1_HqyGmrw=-gOhmQ6sdLkyxEL8YUcmrNLyA@mail.gmail.com>
	<4E73BFD1.40706@behnel.de>
Message-ID: <CANg26EXg+Mav2ZVcajwPaYwAAEBGjCSU2ROoZu9z7f=XnsBXxA@mail.gmail.com>

On 16 September 2011 22:29, Stefan Behnel <stefan_ml at behnel.de> wrote:
> mark florisson, 16.09.2011 23:21:
>>
>> On 16 September 2011 22:20, mark florisson wrote:
>>>
>>> On 16 September 2011 22:03, Stefan Behnel wrote:
>>>>
>>>> Robert Bradshaw, 15.09.2011 22:33:
>>>>>
>>>>> See http://wiki.cython.org/ReleaseNotes-0.15.1 This is a bugfix only
>>>>> release, we hope to get it out shortly.
>>>>
>>>> I've added ticket 736 as a blocker, at least until I know what it takes
>>>> to
>>>> fix it (looking into it right now).
>>>>
>>>> http://trac.cython.org/cython_trac/ticket/736
>>>
>>> Looking at the generated code I see
>>>
>>> __pyx_cur_scope->__pyx_v_a = __pyx_k_1;
>>> __pyx_cur_scope->__pyx_v_b = __pyx_k_2;
>>>
>>> happening at unpacking time without a corresponding INCREF. Surely the
>>> scope object should only ever own references and never borrow them?
>>> The arguments from the args tuple are increffed however, just not the
>>> default values.
>
> Yes, I noticed that. See the updated bug description. I just wasn't sure
> what the best fix was when I wrote the above.

Oh, sorry, I see.

> By now, I'm quite sure that it would be best to do the same as for the
> keyword arguments, i.e. store the borrowed values in a temporary array and
> copy them over when everything has worked out correctly.
>
>
>> BTW, the test would be better written with a class like
>>
>> class UniqueObject(object):
>> ? ? def __init__(self, value):
>> ? ? ? ? self.value = value
>> ? ? def __repr__(self):
>> ? ? ? ? return repr(self.value)
>>
>> That makes it easier to track down refcount errors than (small) integers.
>
> The refnanny handles that for us quite nicely.

Oh yeah, assuming that you have your gotrefs and giverefs right :)

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

From arfrever.fta at gmail.com  Sat Sep 17 00:56:25 2011
From: arfrever.fta at gmail.com (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 17 Sep 2011 00:56:25 +0200
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <4E72F1F2.5070400@behnel.de>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
	<CAKGHGPQMDhjQMjK8Oqi+vuxizO-NsT6HsbCRgqAWZRXCLMXb=w@mail.gmail.com>
	<4E72F1F2.5070400@behnel.de>
Message-ID: <201109170056.26042.Arfrever.FTA@gmail.com>

2011-09-16 08:51:30 Stefan Behnel napisa?(a):
> Vitja Makarov, 16.09.2011 07:14:
> > Btw I'm sure that we have seen this error before:
> >
> > compiling (c) and running tupleunpack_T712 ... Doctest:
> > tupleunpack_T712.__test__.single_from_set (line 12) ... ok
> > Doctest: tupleunpack_T712.__test__.single_from_string (line 4) ... ok
> > compiling (cpp) and running tupleunpack_T712 ... cc1plus: warning:
> > command line option "-Wpointer-sign" is valid for C/ObjC but not for
> > C++
> > tupleunpack_T712.cpp: In function ?PyObject*
> > __pyx_pf_16tupleunpack_T712_1single_from_set(PyObject*, PyObject*)?:
> > tupleunpack_T712.cpp:681:3: error: jump to label ?__pyx_L1_error?
> > tupleunpack_T712.cpp:642:151: error:   from here
> > tupleunpack_T712.cpp:644:14: error:   crosses initialization of
> > ?Py_ssize_t index?
> > tupleunpack_T712.cpp:681:3: error: jump to label ?__pyx_L1_error?
> > tupleunpack_T712.cpp:640:135: error:   from here
> > tupleunpack_T712.cpp:644:14: error:   crosses initialization of
> > ?Py_ssize_t index?
> > ERROR
> 
> Yes, I had fixed it before - I had missed it when looking through the 
> fixes, because I considered it part of the unpacking code optimisation that 
> I did around that change.
> 
> I pushed the fix to the release branch.
> 
> Thanks for finding it, Arfrever (is that the first name?).

Yes (First name = "Arfrever", second name = "Frehtes", surname = "Taifersar Arahesis").

-- 
Arfrever Frehtes Taifersar Arahesis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20110917/3630328c/attachment-0001.pgp>

From stefan_ml at behnel.de  Sat Sep 17 01:05:27 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sat, 17 Sep 2011 01:05:27 +0200
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <CANg26EXg+Mav2ZVcajwPaYwAAEBGjCSU2ROoZu9z7f=XnsBXxA@mail.gmail.com>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>	<4E73B99F.5080005@behnel.de>	<CANg26EX503agY8MMa8sebWbrZe131-e-eX4VBrnM--vrqXeNkg@mail.gmail.com>	<CANg26EUvtga48PU1_HqyGmrw=-gOhmQ6sdLkyxEL8YUcmrNLyA@mail.gmail.com>	<4E73BFD1.40706@behnel.de>
	<CANg26EXg+Mav2ZVcajwPaYwAAEBGjCSU2ROoZu9z7f=XnsBXxA@mail.gmail.com>
Message-ID: <4E73D637.70208@behnel.de>

mark florisson, 16.09.2011 23:33:
> On 16 September 2011 22:29, Stefan Behnel wrote:
>> mark florisson, 16.09.2011 23:21:
>>>
>>> On 16 September 2011 22:20, mark florisson wrote:
>>>>
>>>> On 16 September 2011 22:03, Stefan Behnel wrote:
>>>>>
>>>>> Robert Bradshaw, 15.09.2011 22:33:
>>>>>>
>>>>>> See http://wiki.cython.org/ReleaseNotes-0.15.1 This is a bugfix only
>>>>>> release, we hope to get it out shortly.
>>>>>
>>>>> I've added ticket 736 as a blocker, at least until I know what it takes
>>>>> to fix it (looking into it right now).
>>>>>
>>>>> http://trac.cython.org/cython_trac/ticket/736
>>>>
>>>> Looking at the generated code I see
>>>>
>>>> __pyx_cur_scope->__pyx_v_a = __pyx_k_1;
>>>> __pyx_cur_scope->__pyx_v_b = __pyx_k_2;
>>>>
>>>> happening at unpacking time without a corresponding INCREF. Surely the
>>>> scope object should only ever own references and never borrow them?
>>>> The arguments from the args tuple are increffed however, just not the
>>>> default values.
>>
>> Yes, I noticed that. See the updated bug description. I just wasn't sure
>> what the best fix was when I wrote the above.
>
> Oh, sorry, I see.

No offence taken. It's just that I wrote basically all of that code myself, 
so I tend to know rather well where to put my fingers when something goes 
wrong. ;)

I think I found a good fix - and the code even ended up a tiny bit cleaner 
than it was before.

Stefan

From stefan at sun.ac.za  Tue Sep 20 01:36:05 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Mon, 19 Sep 2011 16:36:05 -0700
Subject: [Cython] Speed of cython.compile
In-Reply-To: <CABDkGQkgGudjhUn0Ydxc9rUz0B_g7Sc7KuynxkApUDJm8jL5ag@mail.gmail.com>
References: <CABDkGQkgGudjhUn0Ydxc9rUz0B_g7Sc7KuynxkApUDJm8jL5ag@mail.gmail.com>
Message-ID: <CABDkGQkv-GCiVN-5CVUwEbcSyXrUB8gWxcBf1fSZi5R9OCXviw@mail.gmail.com>

Hi all,

I only recently found out that the mailing list had shifted, so I hope
my message reaches you this time!

On the current development version of Cython, the attached script
makes Cython go into an infinite loop, but let's hope that's just on
my machine.

Regards
St?fan

---------- Forwarded message ----------
Date: 2011/8/21
Subject: Speed of cython.compile
To: cython-dev at codespeak.net

Hi all,

I am trying to illustrate Cython's pure mode for a tutorial, and made
up a quick fibonacci example (attached). ?But when I run the timings,
I get:

Cython: 5.515417099
Python: 0.123511791229

When I compile the module by hand (.pyx -> .c -> .so) the timings are perfect:

Cython: 0.0394787788391
Python: 0.119538068771

Any idea what's going on? ?I cleared ~/.cython just to be sure, but
that didn't help.

Regards
St?fan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: s.py
Type: text/x-python
Size: 523 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20110919/758bee9a/attachment.py>

From lists at onerussian.com  Tue Sep 20 06:08:21 2011
From: lists at onerussian.com (Yaroslav Halchenko)
Date: Tue, 20 Sep 2011 00:08:21 -0400
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
Message-ID: <20110920040821.GN5866@onerussian.com>

is this regression or am I missing cython basics (which wouldn't be
surprising).

while testing 0.15.1 on Debian I have ran into fail-to-build-from-source
for dipy package in Debian, failure due to error while running tests:

    DM2 = pf.bundles_distances_mam(tracksA, tracksB, metric=metric)
  File "distances.pyx", line 504, in dipy.tracking.distances.bundles_distances_mam (dipy/tracking/distances.c:5710)
UnboundLocalError: local variable 'longest_track_lenA' referenced before assignment


which worked fine with previous cython and looking at the dipy's .pyx
code it seems to be ok (just an untyped cdef... no errors during 'compiling'):

def bundles_distances_mam(tracksA, tracksB, metric='avg'):
    ....
    # preprocess tracks
    cdef:
        size_t longest_track_len = 0, track_len
        longest_track_lenA, longest_track_lenB
        cnp.ndarray[object, ndim=1] tracksA32
        ...
    # some code ... cut ....
        if track_len > longest_track_lenA:
            longest_track_lenA = track_len

-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic

From robertwb at math.washington.edu  Tue Sep 20 06:39:48 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Mon, 19 Sep 2011 21:39:48 -0700
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <20110920040821.GN5866@onerussian.com>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
	<20110920040821.GN5866@onerussian.com>
Message-ID: <CADiQ+QAo0CJiHap7UgOvbcR7snZq3y8xRvCAve05V2CPmyHNbQ@mail.gmail.com>

On Mon, Sep 19, 2011 at 9:08 PM, Yaroslav Halchenko
<lists at onerussian.com> wrote:
> is this regression or am I missing cython basics (which wouldn't be
> surprising).
>
> while testing 0.15.1 on Debian I have ran into fail-to-build-from-source
> for dipy package in Debian, failure due to error while running tests:
>
> ? ?DM2 = pf.bundles_distances_mam(tracksA, tracksB, metric=metric)
> ?File "distances.pyx", line 504, in dipy.tracking.distances.bundles_distances_mam (dipy/tracking/distances.c:5710)
> UnboundLocalError: local variable 'longest_track_lenA' referenced before assignment
>
>
> which worked fine with previous cython and looking at the dipy's .pyx
> code it seems to be ok (just an untyped cdef... no errors during 'compiling'):
>
> def bundles_distances_mam(tracksA, tracksB, metric='avg'):
> ? ?....
> ? ?# preprocess tracks
> ? ?cdef:
> ? ? ? ?size_t longest_track_len = 0, track_len
> ? ? ? ?longest_track_lenA, longest_track_lenB
> ? ? ? ?cnp.ndarray[object, ndim=1] tracksA32
> ? ? ? ?...
> ? ?# some code ... cut ....
> ? ? ? ?if track_len > longest_track_lenA:
> ? ? ? ? ? ?longest_track_lenA = track_len

See the "Incompatible changes" section of
http://wiki.cython.org/ReleaseNotes-0.15 . This change was made to be
more compatible with Python semantics. Set this variable to None if
you want to use it before you assign it to something else. (Looking at
the code, it should probably be 0 or something else, and these
variables could be typed as size_t.)

- Robert

From robertwb at math.washington.edu  Tue Sep 20 07:49:52 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Mon, 19 Sep 2011 22:49:52 -0700
Subject: [Cython] Ahoy, Cython 0.15.1 ho!
Message-ID: <CADiQ+QBBcd+o6RrQppb-PQfw=odREa8jxdgrSgR2mF08YSXrWg@mail.gmail.com>

Aye, we be happy t' announce t' release o' Cython 0.15.1. Step to,
thar be no better time t' set sails fer http://cython.org or
http://pypi.python.org/pypi/Cython/ t' download the loot.

We be bugfixing-only this release. Arrr, behold the list o' scallywags
sent to Davy Jones' Locker:
http://trac.cython.org/cython_trac/query?group=component&milestone=0.15.1
. Ye motherload at
https://github.com/cython/cython/compare/0.15...0.15.1

We be much beholden to ye hearties fer manning ye oars: Stefan Behnel,
Robert Bradshaw, Armon Dadgar, Mark Florisson, Gordin, Angus
McMorland, Vitja Makarov, Ralf Schmitt, and Yury V. Zaytsev. We also
be most grateful to ye landlubbers reports o' sad tails o' bugs.

Fair winds!

- Robert

From lists at onerussian.com  Tue Sep 20 15:09:41 2011
From: lists at onerussian.com (Yaroslav Halchenko)
Date: Tue, 20 Sep 2011 09:09:41 -0400
Subject: [Cython] Cython 0.15.1 release candidate
In-Reply-To: <CADiQ+QAo0CJiHap7UgOvbcR7snZq3y8xRvCAve05V2CPmyHNbQ@mail.gmail.com>
References: <CADiQ+QAAOhGve4iL27RL9HoA1ZEbTdfQ=P_kmyjJiuPXk_1AGA@mail.gmail.com>
	<20110920040821.GN5866@onerussian.com>
	<CADiQ+QAo0CJiHap7UgOvbcR7snZq3y8xRvCAve05V2CPmyHNbQ@mail.gmail.com>
Message-ID: <20110920130941.GO5866@onerussian.com>


On Mon, 19 Sep 2011, Robert Bradshaw wrote:
> > ? ? ? ?longest_track_lenA, longest_track_lenB
> > ? ? ? ?...
> > ? ? ? ?if track_len > longest_track_lenA:
> See the "Incompatible changes" section of
> http://wiki.cython.org/ReleaseNotes-0.15 . This change was made to be
> more compatible with Python semantics. Set this variable to None if
> you want to use it before you assign it to something else. (Looking at

told myself -- "it is too late in the night to ask dummy questions" but
did it nevertheless... indeed variable is accessed before assignment
first and it is logical to require initialization.  Thanks!

-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic

From lists at onerussian.com  Tue Sep 20 19:22:26 2011
From: lists at onerussian.com (Yaroslav Halchenko)
Date: Tue, 20 Sep 2011 13:22:26 -0400
Subject: [Cython] Ahoy, Cython 0.15.1 ho!
In-Reply-To: <CADiQ+QBBcd+o6RrQppb-PQfw=odREa8jxdgrSgR2mF08YSXrWg@mail.gmail.com>
References: <CADiQ+QBBcd+o6RrQppb-PQfw=odREa8jxdgrSgR2mF08YSXrWg@mail.gmail.com>
Message-ID: <20110920172226.GP5866@onerussian.com>

FWIW -- 0.15.1 got uploaded to Debian unstable, thanks to Nikolaus Rath
for help.

Cheers

On Mon, 19 Sep 2011, Robert Bradshaw wrote:

> Aye, we be happy t' announce t' release o' Cython 0.15.1. Step to,
> thar be no better time t' set sails fer http://cython.org or
> http://pypi.python.org/pypi/Cython/ t' download the loot.

> We be bugfixing-only this release. Arrr, behold the list o' scallywags
> sent to Davy Jones' Locker:
> http://trac.cython.org/cython_trac/query?group=component&milestone=0.15.1
> . Ye motherload at
> https://github.com/cython/cython/compare/0.15...0.15.1

> We be much beholden to ye hearties fer manning ye oars: Stefan Behnel,
> Robert Bradshaw, Armon Dadgar, Mark Florisson, Gordin, Angus
> McMorland, Vitja Makarov, Ralf Schmitt, and Yury V. Zaytsev. We also
> be most grateful to ye landlubbers reports o' sad tails o' bugs.

> Fair winds!
-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic

From stefan at sun.ac.za  Wed Sep 21 06:07:28 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 20 Sep 2011 21:07:28 -0700
Subject: [Cython] Mailing list address on webpage
Message-ID: <CABDkGQmLFZPcMqW1mMZg11Rw5xpLrparUDt1nZHea22vunjadQ@mail.gmail.com>

Hi all,

The mailing list address on the cython.org front page still points to codespeak.

I enjoyed the release message.  Arr! :)

Regards
St?fan

From robertwb at math.washington.edu  Wed Sep 21 06:30:49 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Tue, 20 Sep 2011 21:30:49 -0700
Subject: [Cython] Mailing list address on webpage
In-Reply-To: <CABDkGQmLFZPcMqW1mMZg11Rw5xpLrparUDt1nZHea22vunjadQ@mail.gmail.com>
References: <CABDkGQmLFZPcMqW1mMZg11Rw5xpLrparUDt1nZHea22vunjadQ@mail.gmail.com>
Message-ID: <CADiQ+QDYjXwdEW=ON_Wbo8YDKKOzPJN9ci7jxsYNpOdpQSRWYA@mail.gmail.com>

Thanks and thanks. Fixed.

2011/9/20 St?fan van der Walt <stefan at sun.ac.za>:
> Hi all,
>
> The mailing list address on the cython.org front page still points to codespeak.
>
> I enjoyed the release message. ?Arr! :)
>
> Regards
> St?fan
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

From robertwb at math.washington.edu  Wed Sep 21 06:44:17 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Tue, 20 Sep 2011 21:44:17 -0700
Subject: [Cython] Speed of cython.compile
In-Reply-To: <CABDkGQkv-GCiVN-5CVUwEbcSyXrUB8gWxcBf1fSZi5R9OCXviw@mail.gmail.com>
References: <CABDkGQkgGudjhUn0Ydxc9rUz0B_g7Sc7KuynxkApUDJm8jL5ag@mail.gmail.com>
	<CABDkGQkv-GCiVN-5CVUwEbcSyXrUB8gWxcBf1fSZi5R9OCXviw@mail.gmail.com>
Message-ID: <CADiQ+QCoWSk7nndeD9q2gidHZ3iKvi2NLooLnOYZC5j3+CiGQg@mail.gmail.com>

2011/9/19 St?fan van der Walt <stefan at sun.ac.za>:
> Hi all,
>
> I only recently found out that the mailing list had shifted, so I hope
> my message reaches you this time!
>
> On the current development version of Cython, the attached script
> makes Cython go into an infinite loop, but let's hope that's just on
> my machine.
>
> Regards
> St?fan
>
> ---------- Forwarded message ----------
> Date: 2011/8/21
> Subject: Speed of cython.compile
> To: cython-dev at codespeak.net
>
> Hi all,
>
> I am trying to illustrate Cython's pure mode for a tutorial, and made
> up a quick fibonacci example (attached). ?But when I run the timings,
> I get:
>
> Cython: 5.515417099
> Python: 0.123511791229
>
> When I compile the module by hand (.pyx -> .c -> .so) the timings are perfect:
>
> Cython: 0.0394787788391
> Python: 0.119538068771
>
> Any idea what's going on? ?I cleared ~/.cython just to be sure, but
> that didn't help.

Up until https://github.com/cython/cython/commit/cc43e481654c802fb88620de45a3a14257911999
, @cython.compile didn't correctly interpret pure directives.
Statements like

@cython.compile
@cython.locals(n=int)
def fib(n):
   ...

are still on the todo list. Looks like I'm seeing the infinite loop
too; looking into it.

- Robert

From robertwb at math.washington.edu  Wed Sep 21 07:06:17 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Tue, 20 Sep 2011 22:06:17 -0700
Subject: [Cython] Speed of cython.compile
In-Reply-To: <CADiQ+QCoWSk7nndeD9q2gidHZ3iKvi2NLooLnOYZC5j3+CiGQg@mail.gmail.com>
References: <CABDkGQkgGudjhUn0Ydxc9rUz0B_g7Sc7KuynxkApUDJm8jL5ag@mail.gmail.com>
	<CABDkGQkv-GCiVN-5CVUwEbcSyXrUB8gWxcBf1fSZi5R9OCXviw@mail.gmail.com>
	<CADiQ+QCoWSk7nndeD9q2gidHZ3iKvi2NLooLnOYZC5j3+CiGQg@mail.gmail.com>
Message-ID: <CADiQ+QD4xmE=t1agjnm86M=-nyLfsF8MZcWP+9R19_TFNHC9qQ@mail.gmail.com>

On Tue, Sep 20, 2011 at 9:44 PM, Robert Bradshaw
<robertwb at math.washington.edu> wrote:
> 2011/9/19 St?fan van der Walt <stefan at sun.ac.za>:
>> Hi all,
>>
>> I only recently found out that the mailing list had shifted, so I hope
>> my message reaches you this time!
>>
>> On the current development version of Cython, the attached script
>> makes Cython go into an infinite loop, but let's hope that's just on
>> my machine.
>>
>> Regards
>> St?fan
>>
>> ---------- Forwarded message ----------
>> Date: 2011/8/21
>> Subject: Speed of cython.compile
>> To: cython-dev at codespeak.net
>>
>> Hi all,
>>
>> I am trying to illustrate Cython's pure mode for a tutorial, and made
>> up a quick fibonacci example (attached). ?But when I run the timings,
>> I get:
>>
>> Cython: 5.515417099
>> Python: 0.123511791229
>>
>> When I compile the module by hand (.pyx -> .c -> .so) the timings are perfect:
>>
>> Cython: 0.0394787788391
>> Python: 0.119538068771
>>
>> Any idea what's going on? ?I cleared ~/.cython just to be sure, but
>> that didn't help.
>
> Up until https://github.com/cython/cython/commit/cc43e481654c802fb88620de45a3a14257911999
> , @cython.compile didn't correctly interpret pure directives.
> Statements like
>
> @cython.compile
> @cython.locals(n=int)
> def fib(n):
> ? ...
>
> are still on the todo list. Looks like I'm seeing the infinite loop
> too; looking into it.

I think the "infinite loop" is re-parsing the code for each of your
n=1000 iterations.

- Robert

From robertwb at math.washington.edu  Wed Sep 21 07:26:36 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Tue, 20 Sep 2011 22:26:36 -0700
Subject: [Cython] Speed of cython.compile
In-Reply-To: <CADiQ+QD4xmE=t1agjnm86M=-nyLfsF8MZcWP+9R19_TFNHC9qQ@mail.gmail.com>
References: <CABDkGQkgGudjhUn0Ydxc9rUz0B_g7Sc7KuynxkApUDJm8jL5ag@mail.gmail.com>
	<CABDkGQkv-GCiVN-5CVUwEbcSyXrUB8gWxcBf1fSZi5R9OCXviw@mail.gmail.com>
	<CADiQ+QCoWSk7nndeD9q2gidHZ3iKvi2NLooLnOYZC5j3+CiGQg@mail.gmail.com>
	<CADiQ+QD4xmE=t1agjnm86M=-nyLfsF8MZcWP+9R19_TFNHC9qQ@mail.gmail.com>
Message-ID: <CADiQ+QCUmkrb=k+=M3yUqD6NFbu7UEtR+P2g6oobsA7f0YaCxw@mail.gmail.com>

On Tue, Sep 20, 2011 at 10:06 PM, Robert Bradshaw
<robertwb at math.washington.edu> wrote:
> On Tue, Sep 20, 2011 at 9:44 PM, Robert Bradshaw
> <robertwb at math.washington.edu> wrote:
>> 2011/9/19 St?fan van der Walt <stefan at sun.ac.za>:
>>> Hi all,
>>>
>>> I only recently found out that the mailing list had shifted, so I hope
>>> my message reaches you this time!
>>>
>>> On the current development version of Cython, the attached script
>>> makes Cython go into an infinite loop, but let's hope that's just on
>>> my machine.
>>>
>>> Regards
>>> St?fan
>>>
>>> ---------- Forwarded message ----------
>>> Date: 2011/8/21
>>> Subject: Speed of cython.compile
>>> To: cython-dev at codespeak.net
>>>
>>> Hi all,
>>>
>>> I am trying to illustrate Cython's pure mode for a tutorial, and made
>>> up a quick fibonacci example (attached). ?But when I run the timings,
>>> I get:
>>>
>>> Cython: 5.515417099
>>> Python: 0.123511791229
>>>
>>> When I compile the module by hand (.pyx -> .c -> .so) the timings are perfect:
>>>
>>> Cython: 0.0394787788391
>>> Python: 0.119538068771
>>>
>>> Any idea what's going on? ?I cleared ~/.cython just to be sure, but
>>> that didn't help.
>>
>> Up until https://github.com/cython/cython/commit/cc43e481654c802fb88620de45a3a14257911999
>> , @cython.compile didn't correctly interpret pure directives.
>> Statements like
>>
>> @cython.compile
>> @cython.locals(n=int)
>> def fib(n):
>> ? ...
>>
>> are still on the todo list. Looks like I'm seeing the infinite loop
>> too; looking into it.
>
> I think the "infinite loop" is re-parsing the code for each of your
> n=1000 iterations.

OK, I just pushed a commit that should speed things up a lot. There's
still a lot of overhead in calling a @cython.compile method that could
be trimmed, but it's nowhere near as extreem as it used to be.

- Robert

From stefan at sun.ac.za  Wed Sep 21 08:16:23 2011
From: stefan at sun.ac.za (=?ISO-8859-1?Q?St=E9fan_van_der_Walt?=)
Date: Tue, 20 Sep 2011 23:16:23 -0700
Subject: [Cython] Speed of cython.compile
In-Reply-To: <CADiQ+QCUmkrb=k+=M3yUqD6NFbu7UEtR+P2g6oobsA7f0YaCxw@mail.gmail.com>
References: <CABDkGQkgGudjhUn0Ydxc9rUz0B_g7Sc7KuynxkApUDJm8jL5ag@mail.gmail.com>
	<CABDkGQkv-GCiVN-5CVUwEbcSyXrUB8gWxcBf1fSZi5R9OCXviw@mail.gmail.com>
	<CADiQ+QCoWSk7nndeD9q2gidHZ3iKvi2NLooLnOYZC5j3+CiGQg@mail.gmail.com>
	<CADiQ+QD4xmE=t1agjnm86M=-nyLfsF8MZcWP+9R19_TFNHC9qQ@mail.gmail.com>
	<CADiQ+QCUmkrb=k+=M3yUqD6NFbu7UEtR+P2g6oobsA7f0YaCxw@mail.gmail.com>
Message-ID: <CABDkGQn-WwmtoOk2t2yT=9aLoJORTo1LKxNva081Etf7sYyr5g@mail.gmail.com>

On Tue, Sep 20, 2011 at 10:26 PM, Robert Bradshaw
<robertwb at math.washington.edu> wrote:
> OK, I just pushed a commit that should speed things up a lot. There's
> still a lot of overhead in calling a @cython.compile method that could
> be trimmed, but it's nowhere near as extreem as it used to be.

Fantastic--it's much, much better now.

(500 elements)
Cython: 0.167359113693
Python: 0.123614788055

(5000 elements)
Cython: 1.89832210541
Python: 2.36055994034

Thanks, Robert!

St?fan

From robert.rex at exasol.com  Wed Sep 21 09:32:53 2011
From: robert.rex at exasol.com (robert.rex at exasol.com)
Date: Wed, 21 Sep 2011 09:32:53 +0200
Subject: [Cython] 'local variable referenced before assignment' warnings
Message-ID: <4E799325.8070207@exasol.com>

Hi,

I got a (misleading) Cython warning from the following code example:

--------------------------------
cdef extern from "<bar.h>":
     void foo(int &a, int &b)

cdef cyfoo():
     cdef int cya, cyb
     foo(cya, cyb)
--------------------------------

Executing "cython --cplus" produced these messages:
--------------------------------
warning: example.pyx:6:11: local variable 'cya' referenced before assignment
warning: example.pyx:6:16: local variable 'cyb' referenced before assignment
--------------------------------

This started with Cython 0.15 (and 0.15.1 also issues these warnings).
I assume this warning shouldn't be produced (as in a similar issue
here: http://trac.cython.org/cython_trac/ticket/714), right?!

Thanks,
Robert

From robertwb at math.washington.edu  Wed Sep 21 09:49:43 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Wed, 21 Sep 2011 00:49:43 -0700
Subject: [Cython] 'local variable referenced before assignment' warnings
In-Reply-To: <4E799325.8070207@exasol.com>
References: <4E799325.8070207@exasol.com>
Message-ID: <CADiQ+QAtBuQ20-ji5hvm6QoZOPOTpCWHkM2XiqcozZi_j8r3cg@mail.gmail.com>

On Wed, Sep 21, 2011 at 12:32 AM,  <robert.rex at exasol.com> wrote:
> Hi,
>
> I got a (misleading) Cython warning from the following code example:
>
> --------------------------------
> cdef extern from "<bar.h>":
> ? ?void foo(int &a, int &b)
>
> cdef cyfoo():
> ? ?cdef int cya, cyb
> ? ?foo(cya, cyb)
> --------------------------------
>
> Executing "cython --cplus" produced these messages:
> --------------------------------
> warning: example.pyx:6:11: local variable 'cya' referenced before assignment
> warning: example.pyx:6:16: local variable 'cyb' referenced before assignment
> --------------------------------
>
> This started with Cython 0.15 (and 0.15.1 also issues these warnings).
> I assume this warning shouldn't be produced (as in a similar issue
> here: http://trac.cython.org/cython_trac/ticket/714), right?!

The warning seem correct to me, or is foo actually modifying the
values of cya and cyb? (I suppose this could be possible by taking the
address of the "passed by reference" arguments, but would seem like a
*very* poor API design.)

- Robert

From robert.rex at exasol.com  Wed Sep 21 10:20:31 2011
From: robert.rex at exasol.com (robert.rex at exasol.com)
Date: Wed, 21 Sep 2011 10:20:31 +0200
Subject: [Cython] 'local variable referenced before assignment' warnings
In-Reply-To: <CADiQ+QAtBuQ20-ji5hvm6QoZOPOTpCWHkM2XiqcozZi_j8r3cg@mail.gmail.com>
References: <4E799325.8070207@exasol.com>
	<CADiQ+QAtBuQ20-ji5hvm6QoZOPOTpCWHkM2XiqcozZi_j8r3cg@mail.gmail.com>
Message-ID: <4E799E4F.40908@exasol.com>

Hi Robert,

Robert Bradshaw wrote:
> The warning seem correct to me, or is foo actually modifying the
> values of cya and cyb? (I suppose this could be possible by taking the
> address of the "passed by reference" arguments, but would seem like a
> *very* poor API design.)

thanks for your fast answer! What made me came up with this issue is
that GCC/C++ will not complain in similar situations in C++ code (and
assumes foo() to initialize/change the value of cya/cyb). Thus, there
is an (arguable) difference in C++ compiler/Cython warnings.

Robert

From brett.calcott at gmail.com  Wed Sep 21 11:48:59 2011
From: brett.calcott at gmail.com (Brett Calcott)
Date: Wed, 21 Sep 2011 11:48:59 +0200
Subject: [Cython] relative_path_in_code_position_comments
Message-ID: <CAAvcK2ZjjiioW0KPVvGDKtNqtGkhaa7UF8shZs4x6Ay=04oF7w@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20110921/858f7d18/attachment.html>

From brett.calcott at gmail.com  Wed Sep 21 11:54:39 2011
From: brett.calcott at gmail.com (Brett Calcott)
Date: Wed, 21 Sep 2011 11:54:39 +0200
Subject: [Cython] cython 0.15 breaks callback code.
Message-ID: <CAAvcK2asvRt6LSTWavcBphFoUWOFfhM2z8LxDZs6PGXdMDoSug@mail.gmail.com>

Hi. I've just reverted to 0.14.1 because 0.15 breaks code that implements a
cpp callback in python. It seems to be a name-mangling problem.

I've attached a short test case that shows the problem. They both compile
fine on 14.1 and 15. But if I try and run the 15 compiled version I get
this:

Traceback (most recent call last):
  File "try_hello.py", line 1, in <module>
    import test
ImportError:
dlopen(/Users/brett/Dropbox/Code/kli-project/cython-test/test.so, 2): Symbol
not found: __Z19callback_test_helloP7_objecti
  Referenced from: /Users/brett/Dropbox/Code/kli-project/cython-test/test.so
  Expected in: dynamic lookup

Is there anything new I should be doing?

Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20110921/f8d394b9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: callbacks.cpp
Type: text/x-c++src
Size: 242 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20110921/f8d394b9/attachment-0001.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: callbacks.h
Type: text/x-chdr
Size: 320 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20110921/f8d394b9/attachment-0001.h>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.pyx
Type: application/octet-stream
Size: 937 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20110921/f8d394b9/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: try_hello.py
Type: application/octet-stream
Size: 163 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cython-devel/attachments/20110921/f8d394b9/attachment-0003.obj>

From robertwb at math.washington.edu  Thu Sep 22 01:36:20 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Wed, 21 Sep 2011 16:36:20 -0700
Subject: [Cython] 'local variable referenced before assignment' warnings
In-Reply-To: <4E799E4F.40908@exasol.com>
References: <4E799325.8070207@exasol.com>
	<CADiQ+QAtBuQ20-ji5hvm6QoZOPOTpCWHkM2XiqcozZi_j8r3cg@mail.gmail.com>
	<4E799E4F.40908@exasol.com>
Message-ID: <CADiQ+QBzy4vDc8SYjfLt11MkT6Yb+QgQydV6AAiZgapGc7tZgg@mail.gmail.com>

On Wed, Sep 21, 2011 at 1:20 AM,  <robert.rex at exasol.com> wrote:
> Hi Robert,
>
> Robert Bradshaw wrote:
>>
>> The warning seem correct to me, or is foo actually modifying the
>> values of cya and cyb? (I suppose this could be possible by taking the
>> address of the "passed by reference" arguments, but would seem like a
>> *very* poor API design.)
>
> thanks for your fast answer! What made me came up with this issue is
> that GCC/C++ will not complain in similar situations in C++ code (and
> assumes foo() to initialize/change the value of cya/cyb). Thus, there
> is an (arguable) difference in C++ compiler/Cython warnings.

Yes, in C++ the called function can modify values passed by reference,
so we need to add this exception to Cython.

- Robert

From vitja.makarov at gmail.com  Thu Sep 22 14:08:28 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Thu, 22 Sep 2011 16:08:28 +0400
Subject: [Cython] 'local variable referenced before assignment' warnings
In-Reply-To: <CADiQ+QBzy4vDc8SYjfLt11MkT6Yb+QgQydV6AAiZgapGc7tZgg@mail.gmail.com>
References: <4E799325.8070207@exasol.com>
	<CADiQ+QAtBuQ20-ji5hvm6QoZOPOTpCWHkM2XiqcozZi_j8r3cg@mail.gmail.com>
	<4E799E4F.40908@exasol.com>
	<CADiQ+QBzy4vDc8SYjfLt11MkT6Yb+QgQydV6AAiZgapGc7tZgg@mail.gmail.com>
Message-ID: <CAKGHGPR6NG2MJxQ5az49SdKbumXrdFgbNzJbzW84=ymh+49WDQ@mail.gmail.com>

2011/9/22 Robert Bradshaw <robertwb at math.washington.edu>:
> On Wed, Sep 21, 2011 at 1:20 AM, ?<robert.rex at exasol.com> wrote:
>> Hi Robert,
>>
>> Robert Bradshaw wrote:
>>>
>>> The warning seem correct to me, or is foo actually modifying the
>>> values of cya and cyb? (I suppose this could be possible by taking the
>>> address of the "passed by reference" arguments, but would seem like a
>>> *very* poor API design.)
>>
>> thanks for your fast answer! What made me came up with this issue is
>> that GCC/C++ will not complain in similar situations in C++ code (and
>> assumes foo() to initialize/change the value of cya/cyb). Thus, there
>> is an (arguable) difference in C++ compiler/Cython warnings.
>
> Yes, in C++ the called function can modify values passed by reference,
> so we need to add this exception to Cython.
>

That could be hard because we can not always resolve function to check
its args at create-control-flow stage.

-- 
vitja.

From robertwb at math.washington.edu  Fri Sep 23 01:40:45 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Thu, 22 Sep 2011 16:40:45 -0700
Subject: [Cython] 'local variable referenced before assignment' warnings
In-Reply-To: <CAKGHGPR6NG2MJxQ5az49SdKbumXrdFgbNzJbzW84=ymh+49WDQ@mail.gmail.com>
References: <4E799325.8070207@exasol.com>
	<CADiQ+QAtBuQ20-ji5hvm6QoZOPOTpCWHkM2XiqcozZi_j8r3cg@mail.gmail.com>
	<4E799E4F.40908@exasol.com>
	<CADiQ+QBzy4vDc8SYjfLt11MkT6Yb+QgQydV6AAiZgapGc7tZgg@mail.gmail.com>
	<CAKGHGPR6NG2MJxQ5az49SdKbumXrdFgbNzJbzW84=ymh+49WDQ@mail.gmail.com>
Message-ID: <CADiQ+QAg2fsHnq8YEkrc3QndJG4Vb+Cz-59sz56_KcBXcqQxCQ@mail.gmail.com>

On Thu, Sep 22, 2011 at 5:08 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> 2011/9/22 Robert Bradshaw <robertwb at math.washington.edu>:
>> On Wed, Sep 21, 2011 at 1:20 AM, ?<robert.rex at exasol.com> wrote:
>>> Hi Robert,
>>>
>>> Robert Bradshaw wrote:
>>>>
>>>> The warning seem correct to me, or is foo actually modifying the
>>>> values of cya and cyb? (I suppose this could be possible by taking the
>>>> address of the "passed by reference" arguments, but would seem like a
>>>> *very* poor API design.)
>>>
>>> thanks for your fast answer! What made me came up with this issue is
>>> that GCC/C++ will not complain in similar situations in C++ code (and
>>> assumes foo() to initialize/change the value of cya/cyb). Thus, there
>>> is an (arguable) difference in C++ compiler/Cython warnings.
>>
>> Yes, in C++ the called function can modify values passed by reference,
>> so we need to add this exception to Cython.
>>
>
> That could be hard because we can not always resolve function to check
> its args at create-control-flow stage.

Doesn't this always happen after declaration analysis?

- Robert

From vitja.makarov at gmail.com  Fri Sep 23 06:36:45 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Fri, 23 Sep 2011 08:36:45 +0400
Subject: [Cython] 'local variable referenced before assignment' warnings
In-Reply-To: <CADiQ+QAg2fsHnq8YEkrc3QndJG4Vb+Cz-59sz56_KcBXcqQxCQ@mail.gmail.com>
References: <4E799325.8070207@exasol.com>
	<CADiQ+QAtBuQ20-ji5hvm6QoZOPOTpCWHkM2XiqcozZi_j8r3cg@mail.gmail.com>
	<4E799E4F.40908@exasol.com>
	<CADiQ+QBzy4vDc8SYjfLt11MkT6Yb+QgQydV6AAiZgapGc7tZgg@mail.gmail.com>
	<CAKGHGPR6NG2MJxQ5az49SdKbumXrdFgbNzJbzW84=ymh+49WDQ@mail.gmail.com>
	<CADiQ+QAg2fsHnq8YEkrc3QndJG4Vb+Cz-59sz56_KcBXcqQxCQ@mail.gmail.com>
Message-ID: <CAKGHGPQh+GTZierV-0qoK98qq0heoCTqddB4Ktx2+8aZm4of7w@mail.gmail.com>

2011/9/23 Robert Bradshaw <robertwb at math.washington.edu>:
> On Thu, Sep 22, 2011 at 5:08 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>> 2011/9/22 Robert Bradshaw <robertwb at math.washington.edu>:
>>> On Wed, Sep 21, 2011 at 1:20 AM, ?<robert.rex at exasol.com> wrote:
>>>> Hi Robert,
>>>>
>>>> Robert Bradshaw wrote:
>>>>>
>>>>> The warning seem correct to me, or is foo actually modifying the
>>>>> values of cya and cyb? (I suppose this could be possible by taking the
>>>>> address of the "passed by reference" arguments, but would seem like a
>>>>> *very* poor API design.)
>>>>
>>>> thanks for your fast answer! What made me came up with this issue is
>>>> that GCC/C++ will not complain in similar situations in C++ code (and
>>>> assumes foo() to initialize/change the value of cya/cyb). Thus, there
>>>> is an (arguable) difference in C++ compiler/Cython warnings.
>>>
>>> Yes, in C++ the called function can modify values passed by reference,
>>> so we need to add this exception to Cython.
>>>
>>
>> That could be hard because we can not always resolve function to check
>> its args at create-control-flow stage.
>
> Doesn't this always happen after declaration analysis?
>

Sure. But before analyse expressions, so you have to manually lookup
entries for names and attributes.

I see two cases here: global function call and method call. Both are
SimpleCallNodes.


-- 
vitja.

From robertwb at math.washington.edu  Fri Sep 23 06:56:13 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Thu, 22 Sep 2011 21:56:13 -0700
Subject: [Cython] cython 0.15 breaks callback code.
In-Reply-To: <CAAvcK2asvRt6LSTWavcBphFoUWOFfhM2z8LxDZs6PGXdMDoSug@mail.gmail.com>
References: <CAAvcK2asvRt6LSTWavcBphFoUWOFfhM2z8LxDZs6PGXdMDoSug@mail.gmail.com>
Message-ID: <CADiQ+QC=gFPAs2j0F1xXRaXV8JU62L0aPBR=UB-GX6R+kKth_w@mail.gmail.com>

On Wed, Sep 21, 2011 at 2:54 AM, Brett Calcott <brett.calcott at gmail.com> wrote:
> Hi. I've just reverted to 0.14.1 because 0.15 breaks code that implements a
> cpp callback in python. It seems to be a name-mangling problem.
> I've attached a short test case that shows the problem. They both compile
> fine on 14.1 and 15. But if I try and run the 15 compiled version I get
> this:
> Traceback (most recent call last):
> ??File "try_hello.py", line 1, in <module>
> ?? ?import test
> ImportError:
> dlopen(/Users/brett/Dropbox/Code/kli-project/cython-test/test.so, 2): Symbol
> not found: __Z19callback_test_helloP7_objecti
> ??Referenced from: /Users/brett/Dropbox/Code/kli-project/cython-test/test.so
> ??Expected in: dynamic lookup
> Is there anything new I should be doing?

This is probably
https://github.com/cython/cython/commit/c9765a85e1f11a61c604890435b8cebdd49e4cca
which means your declaration of callback_test_hello in callbacks.cpp
also needs to be extern "c" to have the same (i.e. no) mangling.

- Robert

From robertwb at math.washington.edu  Fri Sep 23 07:02:18 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Thu, 22 Sep 2011 22:02:18 -0700
Subject: [Cython] 'local variable referenced before assignment' warnings
In-Reply-To: <CAKGHGPQh+GTZierV-0qoK98qq0heoCTqddB4Ktx2+8aZm4of7w@mail.gmail.com>
References: <4E799325.8070207@exasol.com>
	<CADiQ+QAtBuQ20-ji5hvm6QoZOPOTpCWHkM2XiqcozZi_j8r3cg@mail.gmail.com>
	<4E799E4F.40908@exasol.com>
	<CADiQ+QBzy4vDc8SYjfLt11MkT6Yb+QgQydV6AAiZgapGc7tZgg@mail.gmail.com>
	<CAKGHGPR6NG2MJxQ5az49SdKbumXrdFgbNzJbzW84=ymh+49WDQ@mail.gmail.com>
	<CADiQ+QAg2fsHnq8YEkrc3QndJG4Vb+Cz-59sz56_KcBXcqQxCQ@mail.gmail.com>
	<CAKGHGPQh+GTZierV-0qoK98qq0heoCTqddB4Ktx2+8aZm4of7w@mail.gmail.com>
Message-ID: <CADiQ+QAYGxViM22zQdhUyPh8W5Obn_4cnZB-Yf7qOj9vMhWRXA@mail.gmail.com>

On Thu, Sep 22, 2011 at 9:36 PM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> 2011/9/23 Robert Bradshaw <robertwb at math.washington.edu>:
>> On Thu, Sep 22, 2011 at 5:08 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>> 2011/9/22 Robert Bradshaw <robertwb at math.washington.edu>:
>>>> On Wed, Sep 21, 2011 at 1:20 AM, ?<robert.rex at exasol.com> wrote:
>>>>> Hi Robert,
>>>>>
>>>>> Robert Bradshaw wrote:
>>>>>>
>>>>>> The warning seem correct to me, or is foo actually modifying the
>>>>>> values of cya and cyb? (I suppose this could be possible by taking the
>>>>>> address of the "passed by reference" arguments, but would seem like a
>>>>>> *very* poor API design.)
>>>>>
>>>>> thanks for your fast answer! What made me came up with this issue is
>>>>> that GCC/C++ will not complain in similar situations in C++ code (and
>>>>> assumes foo() to initialize/change the value of cya/cyb). Thus, there
>>>>> is an (arguable) difference in C++ compiler/Cython warnings.
>>>>
>>>> Yes, in C++ the called function can modify values passed by reference,
>>>> so we need to add this exception to Cython.
>>>>
>>>
>>> That could be hard because we can not always resolve function to check
>>> its args at create-control-flow stage.
>>
>> Doesn't this always happen after declaration analysis?
>>
>
> Sure. But before analyse expressions, so you have to manually lookup
> entries for names and attributes.

Ah, yes.

> I see two cases here: global function call and method call. Both are
> SimpleCallNodes.

Yep, and the function could be an arbitrary expression... Ugly.

- Robert

From markflorisson88 at gmail.com  Fri Sep 23 10:59:23 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Fri, 23 Sep 2011 09:59:23 +0100
Subject: [Cython] 'local variable referenced before assignment' warnings
In-Reply-To: <CADiQ+QAYGxViM22zQdhUyPh8W5Obn_4cnZB-Yf7qOj9vMhWRXA@mail.gmail.com>
References: <4E799325.8070207@exasol.com>
	<CADiQ+QAtBuQ20-ji5hvm6QoZOPOTpCWHkM2XiqcozZi_j8r3cg@mail.gmail.com>
	<4E799E4F.40908@exasol.com>
	<CADiQ+QBzy4vDc8SYjfLt11MkT6Yb+QgQydV6AAiZgapGc7tZgg@mail.gmail.com>
	<CAKGHGPR6NG2MJxQ5az49SdKbumXrdFgbNzJbzW84=ymh+49WDQ@mail.gmail.com>
	<CADiQ+QAg2fsHnq8YEkrc3QndJG4Vb+Cz-59sz56_KcBXcqQxCQ@mail.gmail.com>
	<CAKGHGPQh+GTZierV-0qoK98qq0heoCTqddB4Ktx2+8aZm4of7w@mail.gmail.com>
	<CADiQ+QAYGxViM22zQdhUyPh8W5Obn_4cnZB-Yf7qOj9vMhWRXA@mail.gmail.com>
Message-ID: <CANg26EWX9+-thCXaxCmXXp_3Ey=ytpj2nPTBq=zdARz3i_gx8A@mail.gmail.com>

On 23 September 2011 06:02, Robert Bradshaw
<robertwb at math.washington.edu> wrote:
> On Thu, Sep 22, 2011 at 9:36 PM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>> 2011/9/23 Robert Bradshaw <robertwb at math.washington.edu>:
>>> On Thu, Sep 22, 2011 at 5:08 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>>> 2011/9/22 Robert Bradshaw <robertwb at math.washington.edu>:
>>>>> On Wed, Sep 21, 2011 at 1:20 AM, ?<robert.rex at exasol.com> wrote:
>>>>>> Hi Robert,
>>>>>>
>>>>>> Robert Bradshaw wrote:
>>>>>>>
>>>>>>> The warning seem correct to me, or is foo actually modifying the
>>>>>>> values of cya and cyb? (I suppose this could be possible by taking the
>>>>>>> address of the "passed by reference" arguments, but would seem like a
>>>>>>> *very* poor API design.)
>>>>>>
>>>>>> thanks for your fast answer! What made me came up with this issue is
>>>>>> that GCC/C++ will not complain in similar situations in C++ code (and
>>>>>> assumes foo() to initialize/change the value of cya/cyb). Thus, there
>>>>>> is an (arguable) difference in C++ compiler/Cython warnings.
>>>>>
>>>>> Yes, in C++ the called function can modify values passed by reference,
>>>>> so we need to add this exception to Cython.
>>>>>
>>>>
>>>> That could be hard because we can not always resolve function to check
>>>> its args at create-control-flow stage.
>>>
>>> Doesn't this always happen after declaration analysis?
>>>
>>
>> Sure. But before analyse expressions, so you have to manually lookup
>> entries for names and attributes.
>
> Ah, yes.
>
>> I see two cases here: global function call and method call. Both are
>> SimpleCallNodes.
>
> Yep, and the function could be an arbitrary expression... Ugly.
>
> - Robert
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

Can't you run the entire CF analysis after analyse expressions? I
think only the code generation needs the cf_* attributes?

From vitja.makarov at gmail.com  Fri Sep 23 16:38:50 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Fri, 23 Sep 2011 18:38:50 +0400
Subject: [Cython] 'local variable referenced before assignment' warnings
In-Reply-To: <CANg26EWX9+-thCXaxCmXXp_3Ey=ytpj2nPTBq=zdARz3i_gx8A@mail.gmail.com>
References: <4E799325.8070207@exasol.com>
	<CADiQ+QAtBuQ20-ji5hvm6QoZOPOTpCWHkM2XiqcozZi_j8r3cg@mail.gmail.com>
	<4E799E4F.40908@exasol.com>
	<CADiQ+QBzy4vDc8SYjfLt11MkT6Yb+QgQydV6AAiZgapGc7tZgg@mail.gmail.com>
	<CAKGHGPR6NG2MJxQ5az49SdKbumXrdFgbNzJbzW84=ymh+49WDQ@mail.gmail.com>
	<CADiQ+QAg2fsHnq8YEkrc3QndJG4Vb+Cz-59sz56_KcBXcqQxCQ@mail.gmail.com>
	<CAKGHGPQh+GTZierV-0qoK98qq0heoCTqddB4Ktx2+8aZm4of7w@mail.gmail.com>
	<CADiQ+QAYGxViM22zQdhUyPh8W5Obn_4cnZB-Yf7qOj9vMhWRXA@mail.gmail.com>
	<CANg26EWX9+-thCXaxCmXXp_3Ey=ytpj2nPTBq=zdARz3i_gx8A@mail.gmail.com>
Message-ID: <CAKGHGPRuo=Mar5Gt0ui9Zz_cCzx=nhQ8havDfAu2a5NHLiFzFg@mail.gmail.com>

2011/9/23 mark florisson <markflorisson88 at gmail.com>:
> On 23 September 2011 06:02, Robert Bradshaw
> <robertwb at math.washington.edu> wrote:
>> On Thu, Sep 22, 2011 at 9:36 PM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>> 2011/9/23 Robert Bradshaw <robertwb at math.washington.edu>:
>>>> On Thu, Sep 22, 2011 at 5:08 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>>>> 2011/9/22 Robert Bradshaw <robertwb at math.washington.edu>:
>>>>>> On Wed, Sep 21, 2011 at 1:20 AM, ?<robert.rex at exasol.com> wrote:
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>> Robert Bradshaw wrote:
>>>>>>>>
>>>>>>>> The warning seem correct to me, or is foo actually modifying the
>>>>>>>> values of cya and cyb? (I suppose this could be possible by taking the
>>>>>>>> address of the "passed by reference" arguments, but would seem like a
>>>>>>>> *very* poor API design.)
>>>>>>>
>>>>>>> thanks for your fast answer! What made me came up with this issue is
>>>>>>> that GCC/C++ will not complain in similar situations in C++ code (and
>>>>>>> assumes foo() to initialize/change the value of cya/cyb). Thus, there
>>>>>>> is an (arguable) difference in C++ compiler/Cython warnings.
>>>>>>
>>>>>> Yes, in C++ the called function can modify values passed by reference,
>>>>>> so we need to add this exception to Cython.
>>>>>>
>>>>>
>>>>> That could be hard because we can not always resolve function to check
>>>>> its args at create-control-flow stage.
>>>>
>>>> Doesn't this always happen after declaration analysis?
>>>>
>>>
>>> Sure. But before analyse expressions, so you have to manually lookup
>>> entries for names and attributes.
>>
>> Ah, yes.
>>
>>> I see two cases here: global function call and method call. Both are
>>> SimpleCallNodes.
>>
>> Yep, and the function could be an arbitrary expression... Ugly.
>>
>> - Robert
>> _______________________________________________
>> cython-devel mailing list
>> cython-devel at python.org
>> http://mail.python.org/mailman/listinfo/cython-devel
>>
>
> Can't you run the entire CF analysis after analyse expressions? I
> think only the code generation needs the cf_* attributes?

I'm not sure here. CF solution could be used to improve type inference
in the future.
May be it's possible to split analyse expressions transform into
parts: entry lookup and rest expression analysis.


-- 
vitja.

From markflorisson88 at gmail.com  Fri Sep 23 17:50:42 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Fri, 23 Sep 2011 16:50:42 +0100
Subject: [Cython] 'local variable referenced before assignment' warnings
In-Reply-To: <CADiQ+QAYGxViM22zQdhUyPh8W5Obn_4cnZB-Yf7qOj9vMhWRXA@mail.gmail.com>
References: <4E799325.8070207@exasol.com>
	<CADiQ+QAtBuQ20-ji5hvm6QoZOPOTpCWHkM2XiqcozZi_j8r3cg@mail.gmail.com>
	<4E799E4F.40908@exasol.com>
	<CADiQ+QBzy4vDc8SYjfLt11MkT6Yb+QgQydV6AAiZgapGc7tZgg@mail.gmail.com>
	<CAKGHGPR6NG2MJxQ5az49SdKbumXrdFgbNzJbzW84=ymh+49WDQ@mail.gmail.com>
	<CADiQ+QAg2fsHnq8YEkrc3QndJG4Vb+Cz-59sz56_KcBXcqQxCQ@mail.gmail.com>
	<CAKGHGPQh+GTZierV-0qoK98qq0heoCTqddB4Ktx2+8aZm4of7w@mail.gmail.com>
	<CADiQ+QAYGxViM22zQdhUyPh8W5Obn_4cnZB-Yf7qOj9vMhWRXA@mail.gmail.com>
Message-ID: <CANg26EX8MzhH5wfyfgf0VDKE+Y-yvcEBqFxZxtMWr6J+QMCE-w@mail.gmail.com>

On 23 September 2011 06:02, Robert Bradshaw
<robertwb at math.washington.edu> wrote:
> On Thu, Sep 22, 2011 at 9:36 PM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>> 2011/9/23 Robert Bradshaw <robertwb at math.washington.edu>:
>>> On Thu, Sep 22, 2011 at 5:08 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>>> 2011/9/22 Robert Bradshaw <robertwb at math.washington.edu>:
>>>>> On Wed, Sep 21, 2011 at 1:20 AM, ?<robert.rex at exasol.com> wrote:
>>>>>> Hi Robert,
>>>>>>
>>>>>> Robert Bradshaw wrote:
>>>>>>>
>>>>>>> The warning seem correct to me, or is foo actually modifying the
>>>>>>> values of cya and cyb? (I suppose this could be possible by taking the
>>>>>>> address of the "passed by reference" arguments, but would seem like a
>>>>>>> *very* poor API design.)
>>>>>>
>>>>>> thanks for your fast answer! What made me came up with this issue is
>>>>>> that GCC/C++ will not complain in similar situations in C++ code (and
>>>>>> assumes foo() to initialize/change the value of cya/cyb). Thus, there
>>>>>> is an (arguable) difference in C++ compiler/Cython warnings.
>>>>>
>>>>> Yes, in C++ the called function can modify values passed by reference,
>>>>> so we need to add this exception to Cython.
>>>>>
>>>>
>>>> That could be hard because we can not always resolve function to check
>>>> its args at create-control-flow stage.
>>>
>>> Doesn't this always happen after declaration analysis?
>>>
>>
>> Sure. But before analyse expressions, so you have to manually lookup
>> entries for names and attributes.
>
> Ah, yes.
>
>> I see two cases here: global function call and method call. Both are
>> SimpleCallNodes.
>
> Yep, and the function could be an arbitrary expression... Ugly.

As a simple hack, couldn't you in case of a SimpleCallNode where the
function is a NameNode check if the arguments are passed by reference,
and if so not issue the warning. If the callnode.function is an
arbitrary expression (like casting a pointer to such a function), then
you just issue the warning. Then you will cover probably at least 95%
of the cases.

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

From vitja.makarov at gmail.com  Sat Sep 24 10:08:34 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Sat, 24 Sep 2011 12:08:34 +0400
Subject: [Cython] 'local variable referenced before assignment' warnings
In-Reply-To: <CANg26EX8MzhH5wfyfgf0VDKE+Y-yvcEBqFxZxtMWr6J+QMCE-w@mail.gmail.com>
References: <4E799325.8070207@exasol.com>
	<CADiQ+QAtBuQ20-ji5hvm6QoZOPOTpCWHkM2XiqcozZi_j8r3cg@mail.gmail.com>
	<4E799E4F.40908@exasol.com>
	<CADiQ+QBzy4vDc8SYjfLt11MkT6Yb+QgQydV6AAiZgapGc7tZgg@mail.gmail.com>
	<CAKGHGPR6NG2MJxQ5az49SdKbumXrdFgbNzJbzW84=ymh+49WDQ@mail.gmail.com>
	<CADiQ+QAg2fsHnq8YEkrc3QndJG4Vb+Cz-59sz56_KcBXcqQxCQ@mail.gmail.com>
	<CAKGHGPQh+GTZierV-0qoK98qq0heoCTqddB4Ktx2+8aZm4of7w@mail.gmail.com>
	<CADiQ+QAYGxViM22zQdhUyPh8W5Obn_4cnZB-Yf7qOj9vMhWRXA@mail.gmail.com>
	<CANg26EX8MzhH5wfyfgf0VDKE+Y-yvcEBqFxZxtMWr6J+QMCE-w@mail.gmail.com>
Message-ID: <CAKGHGPRib+nzLv9zph8J31KBJjzS-omzQwdqBYRhzx40vhjwyQ@mail.gmail.com>

2011/9/23 mark florisson <markflorisson88 at gmail.com>:
> On 23 September 2011 06:02, Robert Bradshaw
> <robertwb at math.washington.edu> wrote:
>> On Thu, Sep 22, 2011 at 9:36 PM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>> 2011/9/23 Robert Bradshaw <robertwb at math.washington.edu>:
>>>> On Thu, Sep 22, 2011 at 5:08 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>>>> 2011/9/22 Robert Bradshaw <robertwb at math.washington.edu>:
>>>>>> On Wed, Sep 21, 2011 at 1:20 AM, ?<robert.rex at exasol.com> wrote:
>>>>>>> Hi Robert,
>>>>>>>
>>>>>>> Robert Bradshaw wrote:
>>>>>>>>
>>>>>>>> The warning seem correct to me, or is foo actually modifying the
>>>>>>>> values of cya and cyb? (I suppose this could be possible by taking the
>>>>>>>> address of the "passed by reference" arguments, but would seem like a
>>>>>>>> *very* poor API design.)
>>>>>>>
>>>>>>> thanks for your fast answer! What made me came up with this issue is
>>>>>>> that GCC/C++ will not complain in similar situations in C++ code (and
>>>>>>> assumes foo() to initialize/change the value of cya/cyb). Thus, there
>>>>>>> is an (arguable) difference in C++ compiler/Cython warnings.
>>>>>>
>>>>>> Yes, in C++ the called function can modify values passed by reference,
>>>>>> so we need to add this exception to Cython.
>>>>>>
>>>>>
>>>>> That could be hard because we can not always resolve function to check
>>>>> its args at create-control-flow stage.
>>>>
>>>> Doesn't this always happen after declaration analysis?
>>>>
>>>
>>> Sure. But before analyse expressions, so you have to manually lookup
>>> entries for names and attributes.
>>
>> Ah, yes.
>>
>>> I see two cases here: global function call and method call. Both are
>>> SimpleCallNodes.
>>
>> Yep, and the function could be an arbitrary expression... Ugly.
>
> As a simple hack, couldn't you in case of a SimpleCallNode where the
> function is a NameNode check if the arguments are passed by reference,
> and if so not issue the warning. If the callnode.function is an
> arbitrary expression (like casting a pointer to such a function), then
> you just issue the warning. Then you will cover probably at least 95%
> of the cases.
>

Yeah, most popular cases would be function call and method call. We
can handle both of them but I'm still not sure that this is a good
idea.
Maybe it's better to disable this warning by default.

-- 
vitja.

From robertwb at math.washington.edu  Sat Sep 24 22:20:15 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Sat, 24 Sep 2011 13:20:15 -0700
Subject: [Cython] 'local variable referenced before assignment' warnings
In-Reply-To: <CAKGHGPRib+nzLv9zph8J31KBJjzS-omzQwdqBYRhzx40vhjwyQ@mail.gmail.com>
References: <4E799325.8070207@exasol.com>
	<CADiQ+QAtBuQ20-ji5hvm6QoZOPOTpCWHkM2XiqcozZi_j8r3cg@mail.gmail.com>
	<4E799E4F.40908@exasol.com>
	<CADiQ+QBzy4vDc8SYjfLt11MkT6Yb+QgQydV6AAiZgapGc7tZgg@mail.gmail.com>
	<CAKGHGPR6NG2MJxQ5az49SdKbumXrdFgbNzJbzW84=ymh+49WDQ@mail.gmail.com>
	<CADiQ+QAg2fsHnq8YEkrc3QndJG4Vb+Cz-59sz56_KcBXcqQxCQ@mail.gmail.com>
	<CAKGHGPQh+GTZierV-0qoK98qq0heoCTqddB4Ktx2+8aZm4of7w@mail.gmail.com>
	<CADiQ+QAYGxViM22zQdhUyPh8W5Obn_4cnZB-Yf7qOj9vMhWRXA@mail.gmail.com>
	<CANg26EX8MzhH5wfyfgf0VDKE+Y-yvcEBqFxZxtMWr6J+QMCE-w@mail.gmail.com>
	<CAKGHGPRib+nzLv9zph8J31KBJjzS-omzQwdqBYRhzx40vhjwyQ@mail.gmail.com>
Message-ID: <CADiQ+QD9d7sR7ZHpRaHNLYcxu+2dyqM5WQ8bzNfo3z-KdkV6OQ@mail.gmail.com>

On Sat, Sep 24, 2011 at 1:08 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> 2011/9/23 mark florisson <markflorisson88 at gmail.com>:
>> On 23 September 2011 06:02, Robert Bradshaw
>> <robertwb at math.washington.edu> wrote:
>>> On Thu, Sep 22, 2011 at 9:36 PM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>>> 2011/9/23 Robert Bradshaw <robertwb at math.washington.edu>:
>>>>> On Thu, Sep 22, 2011 at 5:08 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
>>>>>> 2011/9/22 Robert Bradshaw <robertwb at math.washington.edu>:
>>>>>>> On Wed, Sep 21, 2011 at 1:20 AM, ?<robert.rex at exasol.com> wrote:
>>>>>>>> Hi Robert,
>>>>>>>>
>>>>>>>> Robert Bradshaw wrote:
>>>>>>>>>
>>>>>>>>> The warning seem correct to me, or is foo actually modifying the
>>>>>>>>> values of cya and cyb? (I suppose this could be possible by taking the
>>>>>>>>> address of the "passed by reference" arguments, but would seem like a
>>>>>>>>> *very* poor API design.)
>>>>>>>>
>>>>>>>> thanks for your fast answer! What made me came up with this issue is
>>>>>>>> that GCC/C++ will not complain in similar situations in C++ code (and
>>>>>>>> assumes foo() to initialize/change the value of cya/cyb). Thus, there
>>>>>>>> is an (arguable) difference in C++ compiler/Cython warnings.
>>>>>>>
>>>>>>> Yes, in C++ the called function can modify values passed by reference,
>>>>>>> so we need to add this exception to Cython.
>>>>>>>
>>>>>>
>>>>>> That could be hard because we can not always resolve function to check
>>>>>> its args at create-control-flow stage.
>>>>>
>>>>> Doesn't this always happen after declaration analysis?
>>>>>
>>>>
>>>> Sure. But before analyse expressions, so you have to manually lookup
>>>> entries for names and attributes.
>>>
>>> Ah, yes.
>>>
>>>> I see two cases here: global function call and method call. Both are
>>>> SimpleCallNodes.
>>>
>>> Yep, and the function could be an arbitrary expression... Ugly.
>>
>> As a simple hack, couldn't you in case of a SimpleCallNode where the
>> function is a NameNode check if the arguments are passed by reference,
>> and if so not issue the warning. If the callnode.function is an
>> arbitrary expression (like casting a pointer to such a function), then
>> you just issue the warning. Then you will cover probably at least 95%
>> of the cases.
>>
>
> Yeah, most popular cases would be function call and method call. We
> can handle both of them but I'm still not sure that this is a good
> idea.

The NameNode is probably worth handling, anything more and it's hard
to know where to stop.

> Maybe it's better to disable this warning by default.

Note it's always valid in C.

- Robert

From stefan_ml at behnel.de  Sun Sep 25 18:46:47 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Sun, 25 Sep 2011 18:46:47 +0200
Subject: [Cython] 'local variable referenced before assignment' warnings
In-Reply-To: <CAKGHGPRuo=Mar5Gt0ui9Zz_cCzx=nhQ8havDfAu2a5NHLiFzFg@mail.gmail.com>
References: <4E799325.8070207@exasol.com>	<CADiQ+QAtBuQ20-ji5hvm6QoZOPOTpCWHkM2XiqcozZi_j8r3cg@mail.gmail.com>	<4E799E4F.40908@exasol.com>	<CADiQ+QBzy4vDc8SYjfLt11MkT6Yb+QgQydV6AAiZgapGc7tZgg@mail.gmail.com>	<CAKGHGPR6NG2MJxQ5az49SdKbumXrdFgbNzJbzW84=ymh+49WDQ@mail.gmail.com>	<CADiQ+QAg2fsHnq8YEkrc3QndJG4Vb+Cz-59sz56_KcBXcqQxCQ@mail.gmail.com>	<CAKGHGPQh+GTZierV-0qoK98qq0heoCTqddB4Ktx2+8aZm4of7w@mail.gmail.com>	<CADiQ+QAYGxViM22zQdhUyPh8W5Obn_4cnZB-Yf7qOj9vMhWRXA@mail.gmail.com>	<CANg26EWX9+-thCXaxCmXXp_3Ey=ytpj2nPTBq=zdARz3i_gx8A@mail.gmail.com>
	<CAKGHGPRuo=Mar5Gt0ui9Zz_cCzx=nhQ8havDfAu2a5NHLiFzFg@mail.gmail.com>
Message-ID: <4E7F5AF7.4070701@behnel.de>

Vitja Makarov, 23.09.2011 16:38:
> 2011/9/23 mark florisson:
>> Can't you run the entire CF analysis after analyse expressions? I
>> think only the code generation needs the cf_* attributes?
>
> I'm not sure here. CF solution could be used to improve type inference
> in the future.

Yes, CF analysis should run rather early - definitely before type analysis.


> May be it's possible to split analyse expressions transform into
> parts: entry lookup and rest expression analysis.

Yes, this has been proposed a couple of times before. I think it's worth 
doing. There should be something like an "early typing" step where types 
are resolved as far as possible, including names defined elsewhere but 
"within reach", and especially references to builtins. Some of the 
optimisation steps can benefit from not having to figure out types themselves.

Eventually, type inference will have to be a global, iterative process, 
certainly when we start inferring things like return types of functions.

Stefan

From brett.calcott at gmail.com  Sun Sep 25 23:40:01 2011
From: brett.calcott at gmail.com (Brett Calcott)
Date: Sun, 25 Sep 2011 23:40:01 +0200
Subject: [Cython] cython 0.15 breaks callback code.
In-Reply-To: <CADiQ+QC=gFPAs2j0F1xXRaXV8JU62L0aPBR=UB-GX6R+kKth_w@mail.gmail.com>
References: <CAAvcK2asvRt6LSTWavcBphFoUWOFfhM2z8LxDZs6PGXdMDoSug@mail.gmail.com>
	<CADiQ+QC=gFPAs2j0F1xXRaXV8JU62L0aPBR=UB-GX6R+kKth_w@mail.gmail.com>
Message-ID: <CAAvcK2Zn1MhjxGCDJc5OBObS1QCYkHOsLWkiWMiwwF-hx9Sv-Q@mail.gmail.com>

> which means your declaration of callback_test_hello in callbacks.cpp
> also needs to be extern "c" to have the same (i.e. no) mangling.
>

That was it!

Thanks,
Brett

From stefan_ml at behnel.de  Mon Sep 26 19:56:06 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 26 Sep 2011 19:56:06 +0200
Subject: [Cython] crash bug for closures on extension type methods
Message-ID: <4E80BCB6.5080301@behnel.de>

Hi,

yes, I know - right after a release is the best time to find crash bugs. 
Here is one that I find particularly unpleasant:

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

Given that this was broken for basically forever without anyone noticing, 
this won't qualify for an emergency release, but I think we shouldn't wait 
too long with a follow-up release to get this out.

Stefan

From stefan_ml at behnel.de  Mon Sep 26 21:45:19 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Mon, 26 Sep 2011 21:45:19 +0200
Subject: [Cython] adding support for __dict__ in extension types
In-Reply-To: <AANLkTimsNLAP9DU0DsMNSXpQCq2akkvqDhjqsTPvEBtF@mail.gmail.com>
References: <AANLkTik1Rk0Z2BRR0OwwgDtT32coktQuQ7-5PkDnqmv3@mail.gmail.com>	<5E596740-6D0C-4AB9-9149-A28698DA1789@math.washington.edu>	<AANLkTi=_aMAyujMqJn3jy0uj2nuaBck87CkU2ObMHquW@mail.gmail.com>	<AANLkTimDKiZaq4pOTG=4OROFNjNTb+XYOZPOP2QU+VPf@mail.gmail.com>
	<AANLkTimsNLAP9DU0DsMNSXpQCq2akkvqDhjqsTPvEBtF@mail.gmail.com>
Message-ID: <4E80D64F.800@behnel.de>

Lisandro Dalcin, 28.02.2011 19:45:
> On 28 February 2011 15:09, Robert Bradshaw wrote:
>> On Mon, Feb 28, 2011 at 8:33 AM, Lisandro Dalcin wrote:
>>> Bringing up this old post...
>>>
>>> On 21 June 2010 15:41, Robert Bradshaw wrote:
>>>> On Jun 17, 2010, at 9:31 AM, Lisandro Dalcin wrote:
>>>>
>>>>> If we special case a __dict__ attribute in extension types, i.e:
>>>>>
>>>>> cdef class Foo:
>>>>>     cdef dict __dict__
>>>>>
>>>>> and fill type->tp_dictoffset, then we can support __dict__ in
>>>>> extension types.
>>>>>
>>>>> What do you think?
>>>>
>>>> Sounds like a good idea to me. Note that we check tp_dictoffset for
>>>> fast dispatching for cpdef methods (which would be correct as a dict
>>>> lookup *would* be needed if __dict__ is available).
>>>
>>> I still have this patch lying around in my disk. I remember Stefan had
>>> some objections. For example, when the user ask for __dict__, a new
>>> dict is unconditionally created (in CPython, type dict are allocated
>>> on-demand).  I propose to get this patch pushed now, and optimize
>>> later (however, I really don't know how to safely implement this
>>> optimization).
>>
>> Note there's also the issue of cpdef methods--if the instance has a
>> __dict__ then a dict lookup must be performed for every method call
>> (to make sure it's not overridden).
>
> But if the type do have a __dict__, then tp_dictoffset will be filled
> (this is in my patch), and cpdef methods should always go the dict
> lookup... Am I missing something?
>
> Now that you mention it, my patch should include tests for all this.
> I'll work on that.

Has anything come out of this?

I also can't find a ticket for this, although it certainly is a worthy feature.

Stefan

From vitja.makarov at gmail.com  Tue Sep 27 18:41:00 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Tue, 27 Sep 2011 20:41:00 +0400
Subject: [Cython] Can't login into my trac account
Message-ID: <CAKGHGPQm6vp=NAwZXJ=qgWt1Ccf7KWRJzF8YmdDjBTrgDH-HxQ@mail.gmail.com>

Hi!

Today I found that I can't login into my trac account. Is that common
problem or only mine?

-- 
vitja.

From robertwb at math.washington.edu  Wed Sep 28 10:48:22 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Wed, 28 Sep 2011 01:48:22 -0700
Subject: [Cython] Can't login into my trac account
In-Reply-To: <CAKGHGPQm6vp=NAwZXJ=qgWt1Ccf7KWRJzF8YmdDjBTrgDH-HxQ@mail.gmail.com>
References: <CAKGHGPQm6vp=NAwZXJ=qgWt1Ccf7KWRJzF8YmdDjBTrgDH-HxQ@mail.gmail.com>
Message-ID: <CADiQ+QDJr7bn2r4kZo+o+ozwgrPWgM_7oy6htXp2cDPRiSrAyw@mail.gmail.com>

I can't log in either, though I haven't had a chance to investigate.

On Tue, Sep 27, 2011 at 9:41 AM, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> Hi!
>
> Today I found that I can't login into my trac account. Is that common
> problem or only mine?
>
> --
> vitja.
> _______________________________________________
> cython-devel mailing list
> cython-devel at python.org
> http://mail.python.org/mailman/listinfo/cython-devel
>

From vitja.makarov at gmail.com  Wed Sep 28 19:52:28 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Wed, 28 Sep 2011 21:52:28 +0400
Subject: [Cython] CyFunction refactoring plan
Message-ID: <CAKGHGPRbKR576nTorj24G4YLNBMC_MS2CL6vjSbsC+2DRyKJkA@mail.gmail.com>

I tried to build simple plan for ongoing cython function refactoring

* Replace assignment synthesis with SingleAssignmentNode, where LHS is
NameNode and RHS is PyCFunctionNode
* Split function body into python wrapper and C function
http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring

Then we can implement some features and optimizations:

* Reduce difference between cdef and def functions
* Store runtime evaluated default values inside CyFunction, ticket #674
* Implement no-args super(), ticket #696
* Function call inlining

-- 
vitja.

From vitja.makarov at gmail.com  Fri Sep 30 06:41:25 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Fri, 30 Sep 2011 08:41:25 +0400
Subject: [Cython] CyFunction refactoring plan
In-Reply-To: <CAKGHGPRbKR576nTorj24G4YLNBMC_MS2CL6vjSbsC+2DRyKJkA@mail.gmail.com>
References: <CAKGHGPRbKR576nTorj24G4YLNBMC_MS2CL6vjSbsC+2DRyKJkA@mail.gmail.com>
Message-ID: <CAKGHGPTm12o+vdaG8-JPdL_o2tMN4BehFoun9b8Ewe=vBUmB_Q@mail.gmail.com>

2011/9/28 Vitja Makarov <vitja.makarov at gmail.com>:
> I tried to build simple plan for ongoing cython function refactoring
>
> * Replace assignment synthesis with SingleAssignmentNode, where LHS is
> NameNode and RHS is PyCFunctionNode
> * Split function body into python wrapper and C function
> http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring
>
> Then we can implement some features and optimizations:
>
> * Reduce difference between cdef and def functions
> * Store runtime evaluated default values inside CyFunction, ticket #674
> * Implement no-args super(), ticket #696
> * Function call inlining
>

If nobody don't mind I would start with first one.

-- 
vitja.

From stefan_ml at behnel.de  Fri Sep 30 07:43:03 2011
From: stefan_ml at behnel.de (Stefan Behnel)
Date: Fri, 30 Sep 2011 07:43:03 +0200
Subject: [Cython] CyFunction refactoring plan
In-Reply-To: <CAKGHGPTm12o+vdaG8-JPdL_o2tMN4BehFoun9b8Ewe=vBUmB_Q@mail.gmail.com>
References: <CAKGHGPRbKR576nTorj24G4YLNBMC_MS2CL6vjSbsC+2DRyKJkA@mail.gmail.com>
	<CAKGHGPTm12o+vdaG8-JPdL_o2tMN4BehFoun9b8Ewe=vBUmB_Q@mail.gmail.com>
Message-ID: <4E8556E7.7050007@behnel.de>

Vitja Makarov, 30.09.2011 06:41:
> 2011/9/28 Vitja Makarov:
>> I tried to build simple plan for ongoing cython function refactoring
>>
>> * Replace assignment synthesis with SingleAssignmentNode, where LHS is
>> NameNode and RHS is PyCFunctionNode
>> * Split function body into python wrapper and C function
>> http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring
>>
>> Then we can implement some features and optimizations:
>>
>> * Reduce difference between cdef and def functions
>> * Store runtime evaluated default values inside CyFunction, ticket #674
>> * Implement no-args super(), ticket #696
>> * Function call inlining
>
> If nobody don't mind I would start with first one.

Please go ahead. :)

Note that you will encounter some problems when enabling name assignments 
for all named functions. I tried that at least once and it "didn't work", 
but I didn't take the time yet to investigate them further.

I assume you are going to work on this in your own repo?

Stefan

From robertwb at math.washington.edu  Fri Sep 30 08:16:47 2011
From: robertwb at math.washington.edu (Robert Bradshaw)
Date: Thu, 29 Sep 2011 23:16:47 -0700
Subject: [Cython] CyFunction refactoring plan
In-Reply-To: <4E8556E7.7050007@behnel.de>
References: <CAKGHGPRbKR576nTorj24G4YLNBMC_MS2CL6vjSbsC+2DRyKJkA@mail.gmail.com>
	<CAKGHGPTm12o+vdaG8-JPdL_o2tMN4BehFoun9b8Ewe=vBUmB_Q@mail.gmail.com>
	<4E8556E7.7050007@behnel.de>
Message-ID: <CADiQ+QATMMGFjgdD9GgxiNjRWyYymdKFkcrtfKZz3-mwDRCvsw@mail.gmail.com>

On Thu, Sep 29, 2011 at 10:43 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Vitja Makarov, 30.09.2011 06:41:
>>
>> 2011/9/28 Vitja Makarov:
>>>
>>> I tried to build simple plan for ongoing cython function refactoring
>>>
>>> * Replace assignment synthesis with SingleAssignmentNode, where LHS is
>>> NameNode and RHS is PyCFunctionNode
>>> * Split function body into python wrapper and C function
>>> http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring
>>>
>>> Then we can implement some features and optimizations:
>>>
>>> * Reduce difference between cdef and def functions
>>> * Store runtime evaluated default values inside CyFunction, ticket #674
>>> * Implement no-args super(), ticket #696
>>> * Function call inlining
>>
>> If nobody don't mind I would start with first one.

I would love to see this happen.

> Please go ahead. :)
>
> Note that you will encounter some problems when enabling name assignments
> for all named functions. I tried that at least once and it "didn't work",
> but I didn't take the time yet to investigate them further.
>
> I assume you are going to work on this in your own repo?

Please also coordinate with Mark's work on function dispatching for
fused types.

- Robert

From vitja.makarov at gmail.com  Fri Sep 30 08:27:00 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Fri, 30 Sep 2011 10:27:00 +0400
Subject: [Cython] CyFunction refactoring plan
In-Reply-To: <4E8556E7.7050007@behnel.de>
References: <CAKGHGPRbKR576nTorj24G4YLNBMC_MS2CL6vjSbsC+2DRyKJkA@mail.gmail.com>
	<CAKGHGPTm12o+vdaG8-JPdL_o2tMN4BehFoun9b8Ewe=vBUmB_Q@mail.gmail.com>
	<4E8556E7.7050007@behnel.de>
Message-ID: <CAKGHGPTgjRcD2LVG3eM5Ab+fTQ0hni=hMA4-Tgr--qzKNFKR7g@mail.gmail.com>

2011/9/30 Stefan Behnel <stefan_ml at behnel.de>:
> Vitja Makarov, 30.09.2011 06:41:
>>
>> 2011/9/28 Vitja Makarov:
>>>
>>> I tried to build simple plan for ongoing cython function refactoring
>>>
>>> * Replace assignment synthesis with SingleAssignmentNode, where LHS is
>>> NameNode and RHS is PyCFunctionNode
>>> * Split function body into python wrapper and C function
>>> http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring
>>>
>>> Then we can implement some features and optimizations:
>>>
>>> * Reduce difference between cdef and def functions
>>> * Store runtime evaluated default values inside CyFunction, ticket #674
>>> * Implement no-args super(), ticket #696
>>> * Function call inlining
>>
>> If nobody don't mind I would start with first one.
>
> Please go ahead. :)
>
> Note that you will encounter some problems when enabling name assignments
> for all named functions. I tried that at least once and it "didn't work",
> but I didn't take the time yet to investigate them further.
>

I can guess that there were some problems with analyse expressions and
friends recently I've fixed them for lambdas.


> I assume you are going to work on this in your own repo?
>

Sure :)


-- 
vitja.

From vitja.makarov at gmail.com  Fri Sep 30 08:42:12 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Fri, 30 Sep 2011 10:42:12 +0400
Subject: [Cython] CyFunction refactoring plan
In-Reply-To: <CADiQ+QATMMGFjgdD9GgxiNjRWyYymdKFkcrtfKZz3-mwDRCvsw@mail.gmail.com>
References: <CAKGHGPRbKR576nTorj24G4YLNBMC_MS2CL6vjSbsC+2DRyKJkA@mail.gmail.com>
	<CAKGHGPTm12o+vdaG8-JPdL_o2tMN4BehFoun9b8Ewe=vBUmB_Q@mail.gmail.com>
	<4E8556E7.7050007@behnel.de>
	<CADiQ+QATMMGFjgdD9GgxiNjRWyYymdKFkcrtfKZz3-mwDRCvsw@mail.gmail.com>
Message-ID: <CAKGHGPQPZqtE_CHRorVoC0nVS8qss-zzsnpULsZrCeF7mmVMXg@mail.gmail.com>

2011/9/30 Robert Bradshaw <robertwb at math.washington.edu>:
> On Thu, Sep 29, 2011 at 10:43 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
>> Vitja Makarov, 30.09.2011 06:41:
>>>
>>> 2011/9/28 Vitja Makarov:
>>>>
>>>> I tried to build simple plan for ongoing cython function refactoring
>>>>
>>>> * Replace assignment synthesis with SingleAssignmentNode, where LHS is
>>>> NameNode and RHS is PyCFunctionNode
>>>> * Split function body into python wrapper and C function
>>>> http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring
>>>>
>>>> Then we can implement some features and optimizations:
>>>>
>>>> * Reduce difference between cdef and def functions
>>>> * Store runtime evaluated default values inside CyFunction, ticket #674
>>>> * Implement no-args super(), ticket #696
>>>> * Function call inlining
>>>
>>> If nobody don't mind I would start with first one.
>
> I would love to see this happen.
>
>> Please go ahead. :)
>>
>> Note that you will encounter some problems when enabling name assignments
>> for all named functions. I tried that at least once and it "didn't work",
>> but I didn't take the time yet to investigate them further.
>>
>> I assume you are going to work on this in your own repo?
>
> Please also coordinate with Mark's work on function dispatching for
> fused types.
>

I assume that that fused type functions are cdef ones so I think that
should be easy to merge.
On the other hand it's better to have Mark's branch merged into master.

Mark, what is the state of your fused types branch?
Is it possible to break it into smaller parts to ease reviewing and merging?

-- 
vitja.

From vitja.makarov at gmail.com  Fri Sep 30 08:47:06 2011
From: vitja.makarov at gmail.com (Vitja Makarov)
Date: Fri, 30 Sep 2011 10:47:06 +0400
Subject: [Cython] CyFunction refactoring plan
In-Reply-To: <CAKGHGPQPZqtE_CHRorVoC0nVS8qss-zzsnpULsZrCeF7mmVMXg@mail.gmail.com>
References: <CAKGHGPRbKR576nTorj24G4YLNBMC_MS2CL6vjSbsC+2DRyKJkA@mail.gmail.com>
	<CAKGHGPTm12o+vdaG8-JPdL_o2tMN4BehFoun9b8Ewe=vBUmB_Q@mail.gmail.com>
	<4E8556E7.7050007@behnel.de>
	<CADiQ+QATMMGFjgdD9GgxiNjRWyYymdKFkcrtfKZz3-mwDRCvsw@mail.gmail.com>
	<CAKGHGPQPZqtE_CHRorVoC0nVS8qss-zzsnpULsZrCeF7mmVMXg@mail.gmail.com>
Message-ID: <CAKGHGPQxR1mK6oKiYGNj+DAaruyZ9naATA=JYJw7Ej69BWYX1A@mail.gmail.com>

2011/9/30 Vitja Makarov <vitja.makarov at gmail.com>:
> 2011/9/30 Robert Bradshaw <robertwb at math.washington.edu>:
>> On Thu, Sep 29, 2011 at 10:43 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
>>> Vitja Makarov, 30.09.2011 06:41:
>>>>
>>>> 2011/9/28 Vitja Makarov:
>>>>>
>>>>> I tried to build simple plan for ongoing cython function refactoring
>>>>>
>>>>> * Replace assignment synthesis with SingleAssignmentNode, where LHS is
>>>>> NameNode and RHS is PyCFunctionNode
>>>>> * Split function body into python wrapper and C function
>>>>> http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring
>>>>>
>>>>> Then we can implement some features and optimizations:
>>>>>
>>>>> * Reduce difference between cdef and def functions
>>>>> * Store runtime evaluated default values inside CyFunction, ticket #674
>>>>> * Implement no-args super(), ticket #696
>>>>> * Function call inlining
>>>>
>>>> If nobody don't mind I would start with first one.
>>
>> I would love to see this happen.
>>
>>> Please go ahead. :)
>>>
>>> Note that you will encounter some problems when enabling name assignments
>>> for all named functions. I tried that at least once and it "didn't work",
>>> but I didn't take the time yet to investigate them further.
>>>
>>> I assume you are going to work on this in your own repo?
>>
>> Please also coordinate with Mark's work on function dispatching for
>> fused types.
>>
>
> I assume that that fused type functions are cdef ones so I think that
> should be easy to merge.
> On the other hand it's better to have Mark's branch merged into master.
>
> Mark, what is the state of your fused types branch?
> Is it possible to break it into smaller parts to ease reviewing and merging?
>

It seems I meant memview branch not fusedtypes.

-- 
vitja.

From markflorisson88 at gmail.com  Fri Sep 30 09:40:02 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Fri, 30 Sep 2011 08:40:02 +0100
Subject: [Cython] CyFunction refactoring plan
In-Reply-To: <CAKGHGPQxR1mK6oKiYGNj+DAaruyZ9naATA=JYJw7Ej69BWYX1A@mail.gmail.com>
References: <CAKGHGPRbKR576nTorj24G4YLNBMC_MS2CL6vjSbsC+2DRyKJkA@mail.gmail.com>
	<CAKGHGPTm12o+vdaG8-JPdL_o2tMN4BehFoun9b8Ewe=vBUmB_Q@mail.gmail.com>
	<4E8556E7.7050007@behnel.de>
	<CADiQ+QATMMGFjgdD9GgxiNjRWyYymdKFkcrtfKZz3-mwDRCvsw@mail.gmail.com>
	<CAKGHGPQPZqtE_CHRorVoC0nVS8qss-zzsnpULsZrCeF7mmVMXg@mail.gmail.com>
	<CAKGHGPQxR1mK6oKiYGNj+DAaruyZ9naATA=JYJw7Ej69BWYX1A@mail.gmail.com>
Message-ID: <CANg26EUnsO7GvXG+vBmLjWEotDVNOPqbqf=4rghpx9YWUmKg-w@mail.gmail.com>

On 30 September 2011 07:47, Vitja Makarov <vitja.makarov at gmail.com> wrote:
> 2011/9/30 Vitja Makarov <vitja.makarov at gmail.com>:
>> 2011/9/30 Robert Bradshaw <robertwb at math.washington.edu>:
>>> On Thu, Sep 29, 2011 at 10:43 PM, Stefan Behnel <stefan_ml at behnel.de> wrote:
>>>> Vitja Makarov, 30.09.2011 06:41:
>>>>>
>>>>> 2011/9/28 Vitja Makarov:
>>>>>>
>>>>>> I tried to build simple plan for ongoing cython function refactoring
>>>>>>
>>>>>> * Replace assignment synthesis with SingleAssignmentNode, where LHS is
>>>>>> NameNode and RHS is PyCFunctionNode
>>>>>> * Split function body into python wrapper and C function
>>>>>> http://wiki.cython.org/enhancements/generators#Pythonfunctionrefactoring
>>>>>>
>>>>>> Then we can implement some features and optimizations:
>>>>>>
>>>>>> * Reduce difference between cdef and def functions
>>>>>> * Store runtime evaluated default values inside CyFunction, ticket #674
>>>>>> * Implement no-args super(), ticket #696
>>>>>> * Function call inlining
>>>>>
>>>>> If nobody don't mind I would start with first one.
>>>
>>> I would love to see this happen.
>>>
>>>> Please go ahead. :)
>>>>
>>>> Note that you will encounter some problems when enabling name assignments
>>>> for all named functions. I tried that at least once and it "didn't work",
>>>> but I didn't take the time yet to investigate them further.
>>>>
>>>> I assume you are going to work on this in your own repo?
>>>
>>> Please also coordinate with Mark's work on function dispatching for
>>> fused types.
>>>
>>
>> I assume that that fused type functions are cdef ones so I think that
>> should be easy to merge.
>> On the other hand it's better to have Mark's branch merged into master.
>>
>> Mark, what is the state of your fused types branch?
>> Is it possible to break it into smaller parts to ease reviewing and merging?
>>
>
> It seems I meant memview branch not fusedtypes.

There are 2 pending branches, _memview_rebase, which has support for
memoryviews, and fusedtypes. The former is ready for merge, it's
waiting to be reviewed. The fused types branch needs to subclass
CyFunction (it basically modified the old binding function). There was
also some duplicate functionality there, so I thought it'd be easier
and more convenient to use the utility code loading there.

Since it's not a strict dependency and it will be blocking progress, I
will try to find some time to get it merge-ready for master.

But no, it does cdef, cpdef and def methods, and it has some changes
to all function nodes (FuncdefNode, CFuncdefNode and DefNode). These
changes shouldn't be major though, but the logic in FusedFuncdefNode
does differentiate between all the different functions in order to
support them. Feel free to ask me about specifics any time.

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

From markflorisson88 at gmail.com  Fri Sep 30 21:34:40 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Fri, 30 Sep 2011 20:34:40 +0100
Subject: [Cython] [cython-users] Re: callback function pointer problem
In-Reply-To: <CADiQ+QAT0ubtbdLL+mnOWAkGziL_dNusu2dZQXddHkUis4-v7g@mail.gmail.com>
References: <4E835336.1060800@gmail.com> <4E8398B5.6050905@gmail.com>
	<CAKGHGPTUn=g1VxpfMXaETgFXEu=sjbz=2gZRz7W-o4ggQ+-2bw@mail.gmail.com>
	<4E8421D0.5010007@gmail.com> <4E844BD0.4040207@gmail.com>
	<4E845B24.6060102@astro.uio.no> <4E845BAE.307@astro.uio.no>
	<CANg26EWDmkbunP+4ezuN9ggk1MPe-6b6oPu7tgRJ1G0y1wTuXQ@mail.gmail.com>
	<4E8460E8.5050701@gmail.com>
	<CANg26EWL1uZfPAe1HcCaGDqTx9VkLwYhLhGGicx-ytO6K00oqQ@mail.gmail.com>
	<CADiQ+QAT0ubtbdLL+mnOWAkGziL_dNusu2dZQXddHkUis4-v7g@mail.gmail.com>
Message-ID: <CANg26EUquDZQqiEf0ppFoiOJHj2z7asnp3T8eCa=ynkAu6RDPA@mail.gmail.com>

On 29 September 2011 22:48, Robert Bradshaw
<robertwb at math.washington.edu> wrote:
> On Thu, Sep 29, 2011 at 5:29 AM, mark florisson
> <markflorisson88 at gmail.com> wrote:
>> On 29 September 2011 13:13, Miguel Angel <skuda21 at gmail.com> wrote:
>>>>
>>>> Structs already coerce to python dicts. In the memoryview branch it
>>>> also does the reverse, i.e. coerce a dict to a struct (you have to be
>>>> careful with strings, making sure you hold a reference to the string
>>>> object as long as you use the pointer in the struct). You have to be
>>>> sure to declare every struct attribute though.
>>>
>>> Could i see an example usage of this in any repository or the documentation? I
>>> can't find any.
>>>
>>> Regards,
>>> Miguel Angel.
>>>
>>
>> It's not in the documentation yet, I updated that in a branch that
>> still needs to be merged (which hopefully will be in 0.16). The
>> functionality from struct -> object is there though:
>>
>> cdef extern from *:
>> ? ?ctypedef struct MyStruct:
>> ? ? ? ?int attrib
>>
>> cdef MyStruct s = {'attrib':10} # Note, this is NOT object->struct
>> conversion, it only eats compile-time expressions here
>
> or even
>
> ? ?s = MyStruct(attrib=10)

That looks very nice, a lot more intuitive than the dict assignment.

> It would be natural to support array -> list conversion for slices the
> baseclass is convertable, e.g.
>
> ? ?cdef double* data = ...
> ? ?print data[:10]
>
> Converting an int[10] to a Python object without slicing is a bit odd as
>
> ? ?cdef int a[10]
> ? ?[compute a]
> ? ?cdef object o = a
> ? ?a[0] = something else
> ? ?o[1] = another thing
>
> is non-initiative, as arrays can't be assigned in C and "assignment"
> of lists in Python are by reference, not by copy. "o = a[:]" is plenty
> clear that there's a copy, so that's better. The other way is a bit
> messier, but
>
> ? ?a[:n] = [python list]
>
> could certainly be supported via an implicit loop. Another
> consideration is that with primitive data types we're venturing into
> memory view territory, which might be a more useful representation
> than Python lists.
>
> - Robert
>

Indeed. Currently you can only cast pointers to memoryview slices, but
there's no reason to not support arrays as well (without also needing
to first cast the array to a pointer). So if arrays have shape
information, you could immediately coerce to memoryview (cython.array)
objects without needing a cast. This would also work for arrays in
structs, as they can only ever have a static size (known at C compile
time).

Shall we support that? I won't be hard as the infrastructure for
casting pointers is already there.

From d.s.seljebotn at astro.uio.no  Fri Sep 30 22:50:34 2011
From: d.s.seljebotn at astro.uio.no (Dag Sverre Seljebotn)
Date: Fri, 30 Sep 2011 22:50:34 +0200
Subject: [Cython] [cython-users] Re: callback function pointer problem
In-Reply-To: <CANg26EUquDZQqiEf0ppFoiOJHj2z7asnp3T8eCa=ynkAu6RDPA@mail.gmail.com>
References: <4E835336.1060800@gmail.com> <4E8398B5.6050905@gmail.com>
	<CAKGHGPTUn=g1VxpfMXaETgFXEu=sjbz=2gZRz7W-o4ggQ+-2bw@mail.gmail.com>
	<4E8421D0.5010007@gmail.com> <4E844BD0.4040207@gmail.com>
	<4E845B24.6060102@astro.uio.no> <4E845BAE.307@astro.uio.no>
	<CANg26EWDmkbunP+4ezuN9ggk1MPe-6b6oPu7tgRJ1G0y1wTuXQ@mail.gmail.com>
	<4E8460E8.5050701@gmail.com>
	<CANg26EWL1uZfPAe1HcCaGDqTx9VkLwYhLhGGicx-ytO6K00oqQ@mail.gmail.com>
	<CADiQ+QAT0ubtbdLL+mnOWAkGziL_dNusu2dZQXddHkUis4-v7g@mail.gmail.com>
	<CANg26EUquDZQqiEf0ppFoiOJHj2z7asnp3T8eCa=ynkAu6RDPA@mail.gmail.com>
Message-ID: <3bb8db3d-513a-481f-8608-5a222a0e162d@email.android.com>

Note: The last field in a C struct can be of variable size, decided at malloc-time. I can't think of a clear syntax for that, except perhaps a builtin function cython.coercevariablesizestruct...



Dag Sverre
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

mark florisson <markflorisson88 at gmail.com> wrote:

On 29 September 2011 22:48, Robert Bradshaw <robertwb at math.washington.edu> wrote: > On Thu, Sep 29, 2011 at 5:29 AM, mark florisson > <markflorisson88 at gmail.com> wrote: >> On 29 September 2011 13:13, Miguel Angel <skuda21 at gmail.com> wrote: >>>> >>>> Structs already coerce to python dicts. In the memoryview branch it >>>> also does the reverse, i.e. coerce a dict to a struct (you have to be >>>> careful with strings, making sure you hold a reference to the string >>>> object as long as you use the pointer in the struct). You have to be >>>> sure to declare every struct attribute though. >>> >>> Could i see an example usage of this in any repository or the documentation? I >>> can't find any. >>> >>> Regards, >>> Miguel Angel. >>> >> >> It's not in the documentation yet, I updated that in a branch that >> still needs to be merged (which hopefully will be in 0.16). The >> functionality from struct -> object is there though: >> >> cdef extern from *: >>    ctypedef struct MyStruct: >>  
     int attrib >> >> cdef MyStruct s = {'attrib':10} # Note, this is NOT object->struct >> conversion, it only eats compile-time expressions here > > or even > >    s = MyStruct(attrib=10) That looks very nice, a lot more intuitive than the dict assignment. > It would be natural to support array -> list conversion for slices the > baseclass is convertable, e.g. > >    cdef double* data = ... >    print data[:10] > > Converting an int[10] to a Python object without slicing is a bit odd as > >    cdef int a[10] >    [compute a] >    cdef object o = a >    a[0] = something else >    o[1] = another thing > > is non-initiative, as arrays can't be assigned in C and "assignment" > of lists in Python are by reference, not by copy. "o = a[:]" is plenty > clear that there's a copy, so that's better. The other way is a bit > messier, but > >    a[:n] = [python list] > > could certainly be supported via an implicit loop. Another > consideration is that with primitive data types we're venturing
into > memory view territory, which might be a more useful representation > than Python lists. > > - Robert > Indeed. Currently you can only cast pointers to memoryview slices, but there's no reason to not support arrays as well (without also needing to first cast the array to a pointer). So if arrays have shape information, you could immediately coerce to memoryview (cython.array) objects without needing a cast. This would also work for arrays in structs, as they can only ever have a static size (known at C compile time). Shall we support that? I won't be hard as the infrastructure for casting pointers is already there._____________________________________________
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/20110930/eca5abae/attachment.html>

From d.s.seljebotn at astro.uio.no  Fri Sep 30 23:14:57 2011
From: d.s.seljebotn at astro.uio.no (Dag Sverre Seljebotn)
Date: Fri, 30 Sep 2011 23:14:57 +0200
Subject: [Cython] [cython-users] Re: callback function pointer problem
In-Reply-To: <CANg26EUquDZQqiEf0ppFoiOJHj2z7asnp3T8eCa=ynkAu6RDPA@mail.gmail.com>
References: <4E835336.1060800@gmail.com> <4E8398B5.6050905@gmail.com>
	<CAKGHGPTUn=g1VxpfMXaETgFXEu=sjbz=2gZRz7W-o4ggQ+-2bw@mail.gmail.com>
	<4E8421D0.5010007@gmail.com> <4E844BD0.4040207@gmail.com>
	<4E845B24.6060102@astro.uio.no> <4E845BAE.307@astro.uio.no>
	<CANg26EWDmkbunP+4ezuN9ggk1MPe-6b6oPu7tgRJ1G0y1wTuXQ@mail.gmail.com>
	<4E8460E8.5050701@gmail.com>
	<CANg26EWL1uZfPAe1HcCaGDqTx9VkLwYhLhGGicx-ytO6K00oqQ@mail.gmail.com>
	<CADiQ+QAT0ubtbdLL+mnOWAkGziL_dNusu2dZQXddHkUis4-v7g@mail.gmail.com>
	<CANg26EUquDZQqiEf0ppFoiOJHj2z7asnp3T8eCa=ynkAu6RDPA@mail.gmail.com>
Message-ID: <588dc249-8f0b-49f2-bf42-23978ea95ddf@email.android.com>

Are you saying that when coercing a struct to an object, one would copy scalar fields by value but reference array fields? -1, that would be confusing. Either the whole struct through a view, or copy it all.

It bothers me that structs are passed by value in Cython, but it seems impossible to change that now. (i.e, once upon a time one could have required the use of a copy method to do a struct assignment and give a syntax error otherwise, which would have worked nicer with Python semantics).


-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

mark florisson <markflorisson88 at gmail.com> wrote:

On 29 September 2011 22:48, Robert Bradshaw <robertwb at math.washington.edu> wrote: > On Thu, Sep 29, 2011 at 5:29 AM, mark florisson > <markflorisson88 at gmail.com> wrote: >> On 29 September 2011 13:13, Miguel Angel <skuda21 at gmail.com> wrote: >>>> >>>> Structs already coerce to python dicts. In the memoryview branch it >>>> also does the reverse, i.e. coerce a dict to a struct (you have to be >>>> careful with strings, making sure you hold a reference to the string >>>> object as long as you use the pointer in the struct). You have to be >>>> sure to declare every struct attribute though. >>> >>> Could i see an example usage of this in any repository or the documentation? I >>> can't find any. >>> >>> Regards, >>> Miguel Angel. >>> >> >> It's not in the documentation yet, I updated that in a branch that >> still needs to be merged (which hopefully will be in 0.16). The >> functionality from struct -> object is there though: >> >> cdef extern from *: >>    ctypedef struct MyStruct: >>  
     int attrib >> >> cdef MyStruct s = {'attrib':10} # Note, this is NOT object->struct >> conversion, it only eats compile-time expressions here > > or even > >    s = MyStruct(attrib=10) That looks very nice, a lot more intuitive than the dict assignment. > It would be natural to support array -> list conversion for slices the > baseclass is convertable, e.g. > >    cdef double* data = ... >    print data[:10] > > Converting an int[10] to a Python object without slicing is a bit odd as > >    cdef int a[10] >    [compute a] >    cdef object o = a >    a[0] = something else >    o[1] = another thing > > is non-initiative, as arrays can't be assigned in C and "assignment" > of lists in Python are by reference, not by copy. "o = a[:]" is plenty > clear that there's a copy, so that's better. The other way is a bit > messier, but > >    a[:n] = [python list] > > could certainly be supported via an implicit loop. Another > consideration is that with primitive data types we're venturing
into > memory view territory, which might be a more useful representation > than Python lists. > > - Robert > Indeed. Currently you can only cast pointers to memoryview slices, but there's no reason to not support arrays as well (without also needing to first cast the array to a pointer). So if arrays have shape information, you could immediately coerce to memoryview (cython.array) objects without needing a cast. This would also work for arrays in structs, as they can only ever have a static size (known at C compile time). Shall we support that? I won't be hard as the infrastructure for casting pointers is already there._____________________________________________
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/20110930/59300f92/attachment-0001.html>

From markflorisson88 at gmail.com  Fri Sep 30 23:42:13 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Fri, 30 Sep 2011 22:42:13 +0100
Subject: [Cython] [cython-users] Re: callback function pointer problem
In-Reply-To: <588dc249-8f0b-49f2-bf42-23978ea95ddf@email.android.com>
References: <4E835336.1060800@gmail.com> <4E8398B5.6050905@gmail.com>
	<CAKGHGPTUn=g1VxpfMXaETgFXEu=sjbz=2gZRz7W-o4ggQ+-2bw@mail.gmail.com>
	<4E8421D0.5010007@gmail.com> <4E844BD0.4040207@gmail.com>
	<4E845B24.6060102@astro.uio.no> <4E845BAE.307@astro.uio.no>
	<CANg26EWDmkbunP+4ezuN9ggk1MPe-6b6oPu7tgRJ1G0y1wTuXQ@mail.gmail.com>
	<4E8460E8.5050701@gmail.com>
	<CANg26EWL1uZfPAe1HcCaGDqTx9VkLwYhLhGGicx-ytO6K00oqQ@mail.gmail.com>
	<CADiQ+QAT0ubtbdLL+mnOWAkGziL_dNusu2dZQXddHkUis4-v7g@mail.gmail.com>
	<CANg26EUquDZQqiEf0ppFoiOJHj2z7asnp3T8eCa=ynkAu6RDPA@mail.gmail.com>
	<588dc249-8f0b-49f2-bf42-23978ea95ddf@email.android.com>
Message-ID: <CANg26EWa53aybCn+aFCVwvYAFiqRQp7EbtVV=LgaecVdO0-h5Q@mail.gmail.com>

On 30 September 2011 22:14, Dag Sverre Seljebotn
<d.s.seljebotn at astro.uio.no> wrote:
> Are you saying that when coercing a struct to an object, one would copy
> scalar fields by value but reference array fields? -1, that would be
> confusing. Either the whole struct through a view, or copy it all.

Hmm, yeah it might be confusing. To me it makes sense though, as
scalars are immutable but arrays are not, although by that logic the
struct should be a view. So perhaps a list makes more sense. Making
arrays in structs lists means you likely want to do the same for the
normal case, i.e. arrays as variables. I'm not sure you'd want normal
arrays to object conversion to be implicit though, I'd rather see an
explicit cast for that.

> It bothers me that structs are passed by value in Cython, but it seems
> impossible to change that now. (i.e, once upon a time one could have
> required the use of a copy method to do a struct assignment and give a
> syntax error otherwise, which would have worked nicer with Python
> semantics).
>
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>
> mark florisson <markflorisson88 at gmail.com> wrote:
>>
>> On 29 September 2011 22:48, Robert Bradshaw <robertwb at math.washington.edu>
>> wrote: > On Thu, Sep 29, 2011 at 5:29 AM, mark florisson >
>> <markflorisson88 at gmail.com> wrote: >> On 29 September 2011 13:13, Miguel
>> Angel <skuda21 at gmail.com> wrote: >>>> >>>> Structs already coerce to python
>> dicts. In the memoryview branch it >>>> also does the reverse, i.e. coerce a
>> dict to a struct (you have to be >>>> careful with strings, making sure you
>> hold a reference to the string >>>> object as long as you use the pointer in
>> the struct). You have to be >>>> sure to declare every struct attribute
>> though. >>> >>> Could i see an example usage of this in any repository or
>> the documentation? I >>> can't find any. >>> >>> Regards, >>> Miguel Angel.
>> >>> >> >> It's not in the documentation yet, I updated that in a branch that
>> >> still needs to be merged (which hopefully will be in 0.16). The >>
>> functionality from struct -> object is there though: >> >> cdef extern from
>> *: >> ? ?ctypedef struct MyStruct: >> ? ? ? ?int attrib >> >> cdef MyStruct
>> s = {'attrib':10} # Note, this is NOT object->struct >> conversion, it only
>> eats compile-time expressions here > > or even > > ? ?s =
>> MyStruct(attrib=10) That looks very nice, a lot more intuitive than the dict
>> assignment. > It would be natural to support array -> list conversion for
>> slices the > baseclass is convertable, e.g. > > ? ?cdef double* data = ... >
>> ? ?print data[:10] > > Converting an int[10] to a Python object without
>> slicing is a bit odd as > > ? ?cdef int a[10] > ? ?[compute a] > ? ?cdef
>> object o = a > ? ?a[0] = something else > ? ?o[1] = another thing > > is
>> non-initiative, as arrays can't be assigned in C and "assignment" > of lists
>> in Python are by reference, not by copy. "o = a[:]" is plenty > clear that
>> there's a copy, so that's better. The other way is a bit > messier, but > >
>> ? ?a[:n] = [python list] > > could certainly be supported via an implicit
>> loop. Another > consideration is that with primitive data types we're
>> venturing into > memory view territory, which might be a more useful
>> representation > than Python lists. > > - Robert > Indeed. Currently you can
>> only cast pointers to memoryview slices, but there's no reason to not
>> support arrays as well (without also needing to first cast the array to a
>> pointer). So if arrays have shape information, you could immediately coerce
>> to memoryview (cython.array) objects without needing a cast. This would also
>> work for arrays in structs, as they can only ever have a static size (known
>> at C compile time). Shall we support that? I won't be hard as the
>> infrastructure for casting pointers is already there.
>> ________________________________
>> 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 markflorisson88 at gmail.com  Fri Sep 30 23:42:43 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Fri, 30 Sep 2011 22:42:43 +0100
Subject: [Cython] [cython-users] Re: callback function pointer problem
In-Reply-To: <3bb8db3d-513a-481f-8608-5a222a0e162d@email.android.com>
References: <4E835336.1060800@gmail.com> <4E8398B5.6050905@gmail.com>
	<CAKGHGPTUn=g1VxpfMXaETgFXEu=sjbz=2gZRz7W-o4ggQ+-2bw@mail.gmail.com>
	<4E8421D0.5010007@gmail.com> <4E844BD0.4040207@gmail.com>
	<4E845B24.6060102@astro.uio.no> <4E845BAE.307@astro.uio.no>
	<CANg26EWDmkbunP+4ezuN9ggk1MPe-6b6oPu7tgRJ1G0y1wTuXQ@mail.gmail.com>
	<4E8460E8.5050701@gmail.com>
	<CANg26EWL1uZfPAe1HcCaGDqTx9VkLwYhLhGGicx-ytO6K00oqQ@mail.gmail.com>
	<CADiQ+QAT0ubtbdLL+mnOWAkGziL_dNusu2dZQXddHkUis4-v7g@mail.gmail.com>
	<CANg26EUquDZQqiEf0ppFoiOJHj2z7asnp3T8eCa=ynkAu6RDPA@mail.gmail.com>
	<3bb8db3d-513a-481f-8608-5a222a0e162d@email.android.com>
Message-ID: <CANg26EXER_S7PjF4ALDvC8cXdCQ9mk=HyOTQK5gbgtE9SufQKg@mail.gmail.com>

On 30 September 2011 21:50, Dag Sverre Seljebotn
<d.s.seljebotn at astro.uio.no> wrote:
> Note: The last field in a C struct can be of variable size, decided at
> malloc-time. I can't think of a clear syntax for that, except perhaps a
> builtin function cython.coercevariablesizestruct...
>
>
>
> Dag Sverre
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.

That's really more of a hack right, not something that's technically
legal in C. If the user want to use hacked data structures, he/she
should not rely on built-in conversion, but convert manually, by
building a dict manually or whatever (and by casting like
<int[:variable_length]> mystruct.my_last_overallocated_field).

> mark florisson <markflorisson88 at gmail.com> wrote:
>>
>> On 29 September 2011 22:48, Robert Bradshaw <robertwb at math.washington.edu>
>> wrote: > On Thu, Sep 29, 2011 at 5:29 AM, mark florisson >
>> <markflorisson88 at gmail.com> wrote: >> On 29 September 2011 13:13, Miguel
>> Angel <skuda21 at gmail.com> wrote: >>>> >>>> Structs already coerce to python
>> dicts. In the memoryview branch it >>>> also does the reverse, i.e. coerce a
>> dict to a struct (you have to be >>>> careful with strings, making sure you
>> hold a reference to the string >>>> object as long as you use the pointer in
>> the struct). You have to be >>>> sure to declare every struct attribute
>> though. >>> >>> Could i see an example usage of this in any repository or
>> the documentation? I >>> can't find any. >>> >>> Regards, >>> Miguel Angel.
>> >>> >> >> It's not in the documentation yet, I updated that in a branch that
>> >> still needs to be merged (which hopefully will be in 0.16). The >>
>> functionality from struct -> object is there though: >> >> cdef extern from
>> *: >> ? ?ctypedef struct MyStruct: >> ? ? ? ?int attrib >> >> cdef MyStruct
>> s = {'attrib':10} # Note, this is NOT object->struct >> conversion, it only
>> eats compile-time expressions here > > or even > > ? ?s =
>> MyStruct(attrib=10) That looks very nice, a lot more intuitive than the dict
>> assignment. > It would be natural to support array -> list conversion for
>> slices the > baseclass is convertable, e.g. > > ? ?cdef double* data = ... >
>> ? ?print data[:10] > > Converting an int[10] to a Python object without
>> slicing is a bit odd as > > ? ?cdef int a[10] > ? ?[compute a] > ? ?cdef
>> object o = a > ? ?a[0] = something else > ? ?o[1] = another thing > > is
>> non-initiative, as arrays can't be assigned in C and "assignment" > of lists
>> in Python are by reference, not by copy. "o = a[:]" is plenty > clear that
>> there's a copy, so that's better. The other way is a bit > messier, but > >
>> ? ?a[:n] = [python list] > > could certainly be supported via an implicit
>> loop. Another > consideration is that with primitive data types we're
>> venturing into > memory view territory, which might be a more useful
>> representation > than Python lists. > > - Robert > Indeed. Currently you can
>> only cast pointers to memoryview slices, but there's no reason to not
>> support arrays as well (without also needing to first cast the array to a
>> pointer). So if arrays have shape information, you could immediately coerce
>> to memoryview (cython.array) objects without needing a cast. This would also
>> work for arrays in structs, as they can only ever have a static size (known
>> at C compile time). Shall we support that? I won't be hard as the
>> infrastructure for casting pointers is already there.
>> ________________________________
>> 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 markflorisson88 at gmail.com  Fri Sep 30 23:46:34 2011
From: markflorisson88 at gmail.com (mark florisson)
Date: Fri, 30 Sep 2011 22:46:34 +0100
Subject: [Cython] [cython-users] Re: callback function pointer problem
In-Reply-To: <CANg26EWa53aybCn+aFCVwvYAFiqRQp7EbtVV=LgaecVdO0-h5Q@mail.gmail.com>
References: <4E835336.1060800@gmail.com> <4E8398B5.6050905@gmail.com>
	<CAKGHGPTUn=g1VxpfMXaETgFXEu=sjbz=2gZRz7W-o4ggQ+-2bw@mail.gmail.com>
	<4E8421D0.5010007@gmail.com> <4E844BD0.4040207@gmail.com>
	<4E845B24.6060102@astro.uio.no> <4E845BAE.307@astro.uio.no>
	<CANg26EWDmkbunP+4ezuN9ggk1MPe-6b6oPu7tgRJ1G0y1wTuXQ@mail.gmail.com>
	<4E8460E8.5050701@gmail.com>
	<CANg26EWL1uZfPAe1HcCaGDqTx9VkLwYhLhGGicx-ytO6K00oqQ@mail.gmail.com>
	<CADiQ+QAT0ubtbdLL+mnOWAkGziL_dNusu2dZQXddHkUis4-v7g@mail.gmail.com>
	<CANg26EUquDZQqiEf0ppFoiOJHj2z7asnp3T8eCa=ynkAu6RDPA@mail.gmail.com>
	<588dc249-8f0b-49f2-bf42-23978ea95ddf@email.android.com>
	<CANg26EWa53aybCn+aFCVwvYAFiqRQp7EbtVV=LgaecVdO0-h5Q@mail.gmail.com>
Message-ID: <CANg26EUph_cTcbwufKY86QbV2_x6wet5s+0Zf545K9s=2y3-2A@mail.gmail.com>

On 30 September 2011 22:42, mark florisson <markflorisson88 at gmail.com> wrote:
> On 30 September 2011 22:14, Dag Sverre Seljebotn
> <d.s.seljebotn at astro.uio.no> wrote:
>> Are you saying that when coercing a struct to an object, one would copy
>> scalar fields by value but reference array fields? -1, that would be
>> confusing. Either the whole struct through a view, or copy it all.
>
> Hmm, yeah it might be confusing. To me it makes sense though, as
> scalars are immutable but arrays are not, although by that logic the
> struct should be a view. So perhaps a list makes more sense. Making
> arrays in structs lists means you likely want to do the same for the
> normal case, i.e. arrays as variables. I'm not sure you'd want normal
> arrays to object conversion to be implicit though, I'd rather see an
> explicit cast for that.

I suppose none of it makes me very happy, maybe I'll just forget about
it for now.

>> It bothers me that structs are passed by value in Cython, but it seems
>> impossible to change that now. (i.e, once upon a time one could have
>> required the use of a copy method to do a struct assignment and give a
>> syntax error otherwise, which would have worked nicer with Python
>> semantics).
>>
>>
>> --
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>>
>> mark florisson <markflorisson88 at gmail.com> wrote:
>>>
>>> On 29 September 2011 22:48, Robert Bradshaw <robertwb at math.washington.edu>
>>> wrote: > On Thu, Sep 29, 2011 at 5:29 AM, mark florisson >
>>> <markflorisson88 at gmail.com> wrote: >> On 29 September 2011 13:13, Miguel
>>> Angel <skuda21 at gmail.com> wrote: >>>> >>>> Structs already coerce to python
>>> dicts. In the memoryview branch it >>>> also does the reverse, i.e. coerce a
>>> dict to a struct (you have to be >>>> careful with strings, making sure you
>>> hold a reference to the string >>>> object as long as you use the pointer in
>>> the struct). You have to be >>>> sure to declare every struct attribute
>>> though. >>> >>> Could i see an example usage of this in any repository or
>>> the documentation? I >>> can't find any. >>> >>> Regards, >>> Miguel Angel.
>>> >>> >> >> It's not in the documentation yet, I updated that in a branch that
>>> >> still needs to be merged (which hopefully will be in 0.16). The >>
>>> functionality from struct -> object is there though: >> >> cdef extern from
>>> *: >> ? ?ctypedef struct MyStruct: >> ? ? ? ?int attrib >> >> cdef MyStruct
>>> s = {'attrib':10} # Note, this is NOT object->struct >> conversion, it only
>>> eats compile-time expressions here > > or even > > ? ?s =
>>> MyStruct(attrib=10) That looks very nice, a lot more intuitive than the dict
>>> assignment. > It would be natural to support array -> list conversion for
>>> slices the > baseclass is convertable, e.g. > > ? ?cdef double* data = ... >
>>> ? ?print data[:10] > > Converting an int[10] to a Python object without
>>> slicing is a bit odd as > > ? ?cdef int a[10] > ? ?[compute a] > ? ?cdef
>>> object o = a > ? ?a[0] = something else > ? ?o[1] = another thing > > is
>>> non-initiative, as arrays can't be assigned in C and "assignment" > of lists
>>> in Python are by reference, not by copy. "o = a[:]" is plenty > clear that
>>> there's a copy, so that's better. The other way is a bit > messier, but > >
>>> ? ?a[:n] = [python list] > > could certainly be supported via an implicit
>>> loop. Another > consideration is that with primitive data types we're
>>> venturing into > memory view territory, which might be a more useful
>>> representation > than Python lists. > > - Robert > Indeed. Currently you can
>>> only cast pointers to memoryview slices, but there's no reason to not
>>> support arrays as well (without also needing to first cast the array to a
>>> pointer). So if arrays have shape information, you could immediately coerce
>>> to memoryview (cython.array) objects without needing a cast. This would also
>>> work for arrays in structs, as they can only ever have a static size (known
>>> at C compile time). Shall we support that? I won't be hard as the
>>> infrastructure for casting pointers is already there.
>>> ________________________________
>>> 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
>>
>>
>